Andrew Hong

Posted on Aug 18, 2021Read on Mirror.xyz

$WRITE Airdrop Proposal: Incentivizing a More Diverse Creator Crowd on Mirror

A (very) short history on token airdrops:

Airdrops have come a long way in the last year, most notably starting from Uniswap's 400 UNI token airdrop in September of 2020. From there, we've grown into airdrops that are calculated based on the frequency and volume of interactions with different facets of a protocol. Below is one such example:

We've also seen NFT drops recently that rely on more standardized tools built for quickly setting rules/requirements and rewards/distribution. None of these methodologies are bad, but I do believe there's still a lot of room for improvement. This could come from the distribution model, drop frequency, or even the token rules themselves. In this proposal, I'll be focusing on a new distribution model, one that combines data from user interactions in the Mirror $WRITE race, on Twitter, and in Mirror-related Ethereum transactions.

Rewards, Incentives, and Governance:

The Mirror $WRITE race is a vote-based competition that occurs once a week, where the top ten writers get 1 $WRITE token. This gives them access to the platform as well as 1000 votes for the future rounds of the race. The structure is not dissimilar from most Sybil-resistant approaches where a validated party votes in a new party, however, the propagation of rounds is a lot slower as it only happens once a week. This means it takes a lot longer to really diversify away from the friends/communities of the genesis writers of the $WRITE race. For new participants who aren't very close to that initial circle, it becomes harder and harder to win as the top 10 vote floor continues to rise:

While increasing the # of winners and base vote allocation or gamifying the prompt system could incrementally improve the race, an airdrop of $WRITE tokens would offer a much faster method of reducing the influence of the starter group and increase the diversity of writers (winners) on the platform.

A key first decision here is that airdropped tokens should not affect the current vote allocation for each participant in the $WRITE race. But, they can still be redeemed for publications**, at 1 $WRITE token per publication.

My first thoughts when structuring this airdrop model were around "what should an airdrop really be targeting?" The three pillars that came to mind were:

  1. Rewards: How can we fairly compensate early users for their support and risks that were taken? They chose to publish on Mirror rather than their existing publishing platform, carrying both new funnel and smart contract risks.
  2. Incentives: Knowing that this model will set a precedent for rewards distribution criteria, how will that affect voter/creator/contributor behaviors going forward?
  3. Governance: How can the balance of power be shifted in a way that diversifies the writer community much faster?

From there, I set three goals for the token formula:

  1. Rewards: Creators should be rewarded for their usage of web3 platform features, and contributors should be rewarded for the value (ETH) they've provided to creator projects
  2. Incentives: We should also incentivize contributors to support a larger array of creators, rather than just the same two or three creators (or a single community).
  3. Governance: We should try to amplify anyone who bridges different communities by giving them more tokens.

We know that for Mirror to thrive long-term, there needs to be diversity in creators with an equally diverse set of contributors. However, with over 7000 users it can be hard to choose who gets what allocation off of usage alone. This is where the social graphs enter the picture, as we can use that data to identify who might be best from a community perspective to allocate greater or fewer airdrop tokens to.

Token Reward Formula:

For all of the following, $W$ stands for a weight between 0-1 and $T$ stands for $WRITE token.

  1. First, let's take care of the community diversification weighting based on centrality:

  • Betweenness centrality is a measure that highlights the nodes that bridge the most communities. This serves to incentivize everyone to support and collaborate with more diverse communities in the future. See this post for details on this metric and the methodology. We multiply it by 50 to give it more weight.
  • While the linked post above does not account for the difference in edge/relationship data type, so a mention and a 1 ETH contribution would have the same non-scaled weight), for this airdrop, we converted the multi-edge graph into a weighted directional graph. This means normalizing each edge by total mentions/contributions/votes a certain user has given, and then weighting mentions, contributions, and votes by 15x, 40x, 40x respectively. Another important change from the original post is the use of a directional graph.
  1. We still want to make sure creators and contributors are getting fairly rewarded. Let's define the T_baseReward formula as:

  • V_votesAllocated represents the current allocation of votes someone has in the $WRITE race. This is divided by 1000 to represent the $WRITE token balance. This is weighted by W_voted which represents the total votes used out of votes allocated each week (cumulatively).
  • B_hasCreated represents a Boolean (1 or 0 value) for if someone has created at least one entry or block (edition, split, crowdfund, auction).
  • V^n_contributed is the value of ETH contributed to creators (across n different block types). This is weighted by the unique # of creators someone has contributed to, max_min scaled into W_contributed. This means if the maximum number of unique creators someone has contributed to is 10, and I've also contributed to 10 creators, then I would have a W_contributed of 1. Depending on the distribution of contributors, if I've only contributed to 1 creator, I would have a W_contributed of something like 0.0833. Thus, we are rewarding those who both contribute to creators and support many creators, in an effort to incentivize that behavior.
  • The constants of 0.65 and 0.15 were chosen based on how many total tokens we wanted to distribute.
  1. Putting it all together, we get our total $WRITE token reward formula:

Airdrop Results:

The results of the airdrop can be found in the following CSV file.

mirror_finalAirdrop_cleaned_w.csv

The data dictionary for this file can be found below:

Mirror $WRITE Airdrop Data Dictionary

What a Reputation-based Airdrop Enables for the Community:

I believe this airdrop has iterated upon everything we built in web2 and web3, mainly due to its combined use of multiple social graphs alongside tokenized ownership. As I've covered before, betweenness centrality is a measure that helps us target a more resilient and diverse network. Tokens are a great way to reward those who have fulfilled that behavior historically, and also as an incentive mechanism to further that diversity and resilience (support) in the future.

This proposal indirectly tackles the issue of long-term ownership of tokens, where many receivers (other than core investors and the product team) sell the tokens soon after the drop. My hope is that if the tokens are distributed to an aligned subset of the community, we won't see this issue appear as strongly. I think the Ohmies are a great example of this done well.

While this airdrop is at a protocol level, there's no reason why we couldn't go more micro in our approach and provide creators and DAOs betweenness scores for their specific social graph of contributors, voters, and Twitter interactors. They could leverage that data to then airdrop their own tokens as well. Ultimately, I think that what has been done here can be further expanded and productized to help all of us gain better visibility into and reward/incentivize each step of the community flywheel created by the team at 0xSTATION:

https://station.mirror.xyz/xlPSC6PYsazGxjo-pqyaV8M4ujtWapxhCmVQfBjmN9o

Sources and Methods:

  • All data (besides identity mappings) were publicly sourced. Please see the data dictionary for details on sources.
  • Data analysis and visualization were performed in Python, using a mix of Pandas, Numpy, Scikit-learn, Networkx, Matplotlib, Seaborn, Plotly, Cdlib, Gephi, and Neo4j. The Neo4j Dashboard, Bloom, and Graph Data Science (GDS) packages were used as well for ancillary analysis. Desmos was used for early exploration and tuning of the reward formula.