The story begins September 16th, when the protocol governing the decentralized exchange Uniswap, launched their governance token, UNI. Faced with a decentralized governance dilemma, they ultimately decided to provide these tokens to those interested in participating in future proposals affecting the Protocol. Once the decision to move towards a truly decentralized protocol was made, Uniswap was confronted with another dilemma, but this time in regards to distribution.
How do you distribute a large number of tokens to a select group of people while minimizing spamming disinterested or abandoned accounts in a cost-effective manner?
Uniswap answers the question above with a Merkle Distributor, but I decided to take things one step further. Read more to see what I did and how I did it, so you may integrate such a tool for your community. In this article, I discuss how to replicated this process and introduced a number of elements unseen in any other Merkle Airdrop smart contract to date.
Why Governance Matters
Governance is perhaps the single most important topic in the crypto industry. The reason for this is in order for decentralization to exist in a sustainable manner, there must also exist a set of rules to which all participants must agree, otherwise there truly is nothing to enter into when participants consent to being members of a protocol.
This is the reason why so many tokens can exist without a clear purpose — because purpose has, as of late, come secondary to profits. Those tokens with a coherent purpose tend to succeed simply because inherent in that purpose is the utility of the token.
What do you get from being a participant in Bitcoin?
Being the potential for “gains”, you gain access to a token economy that consists of miners, developers, and users. Each member in this economy has a role and, as such, ought to have a clear understanding of their role and thus their impact on the sustainability of the project (token) in question.
In this case, the purpose of designing an airdrop was two-fold: one to “unrug” the CBDAO Community and two, to encourage participation in an ecosystem without stakeholders having to provide a direct, upfront, monetary investment. The second component is made possible by a set of configurations I integrated into the MerkleDistributor.sol smart contract, which we will discuss in-depth when reviewing the components of the smart contract itself.
These components are designed to account for (and solve) the misfortune we witnessed with the UNI airdrop wherein which users were rushing to collect on their gains instead of considering the benefit of being an active participant in the ecosystem.
As is the case with developing smart contracts of any kind, my recommendation is to truly understand the purpose of your design and thus the elements you need to make the design come to life. In the case of the airdrop, we had a few goals in mind, but we were unsure about implementation and wanted to construct a cohesive strategy to the benefit of the community, for other projects to replicate.
We needed a means to prevent harm to the community, first and foremost, as it is often the case that airdrop recipients are incentivized to be amongst the first to sell because they were awarded money today at a value that is not guaranteed tomorrow. This is especially true in the case of a new project.
We had to design a solution to mitigate or eliminate the following:
- Price Impact: we had to design a mechanism that would prevent a massive “dump” on Airdrop Day, as is typically the case.
- Bad Actor Security: due to the nature of the airdrop distribution as one with an increasing available amount each day, one could theoretically claim on another’s behalf so as to cut that person off from being able to claim their entire airdrop and have to settle for just a portion.
- Hack Insurance: a mechanism that would disallow one bad actor from accessing all of the $2.3M in assets in a hack for themselves.
- Limit Access and Immutability: we need to ensure only those who were rug pulled were provided with an airdrop and that the list cannot change.
As with any cogent strategy, a two-pronged approach is vital to ensuring one accounts not just for reasons not to do something but, on the flip side, reasons to do something — aka incentives. We needed to inspire airdrop recipients to not claim (and subsequently dump) what is rightfully theirs. However, we realize penalties without rewards is a bit harsh, especially when doing so to the purported benefit of an entire community that experienced a rug pull event. As such, we hypothesized a number of ways to incentivize not only forestalling one’s tendencies to “dump”, but to encourage users to actually add value to the ecosystems without having the ordinary sense of “skin in the game” via money shelled out to the ecosystem upfront.
We implemented a number of incentives, including:
- Incentives to HODL: a reason to wait the full duration of the airdrop in order to secure a more smooth allocation of the reward.
- Incentives to Trust: we needed participants to believe us when we said the money will be theirs and cannot be scooped up by just anyone, so we identified a trustless manner of verifying claims and that enables anyone to verify that, in fact, only those listed are eligible to receive their share and that each user’s share is limited to only what they are due.
Granted, much more was taken into consideration, but these are a few examples of things that were relevant to us in our design and ones for which we were able to take into account when creating our final Airdrop smart contract.
At first glance, the MerkleDistributor.sol smart contract seemed like a fit solution for us and we considered forking it and calling it a day, but I could not get passed the very-likely scenario that recipients of the airdrop would behave in a self-interested manner. Being an economist at heart (and by degree), I knew there had to be safeguards in place to prevent the former CBDAO Community from being rug pulled (for a second time), but this time rug-pulling themselves.
In order to do so, we had to find a way to organically introduce 1.2M+ tokens into the ecosystem, which requires claiming tokens in a manner that smooths distribution. As we all know, Econ101 supply and demand, introducing new supply with demand held constant means “price go down”, so I designed a way to smooth distribution of supply (sell pressure) so as to better align with demand (buy pressure). Doing so would, ideally, enable us to protect the current price, but we needed to also ensure this was at the will of the user and not simply a forced distribution method, which comes with a bad taste in the mouths of those who were promised access to an airdrop in just a matter of a month from our liquidity generation event.
We ultimately decided to modify our original proposal and enable users to make a choice that made the most sense for them.
Are you willing to claim less of your tokens today or wait for later down the line to claim more of your tokens?
While a simple question, a much deeper psychological component is at play here that some may have missed. Users are being provided what they already consider to be “free money”, so if they are highly disinterested in the project’s success and do not believe in its potential, they may leave and take with them a much smaller piece of the pie on their way out. Alternatively, if they believe in the project and are interested in participating in its outcome, then they will stick around. Not only are users incentivized to stick around, but they are also incentivized to add value to the community via contributing to the stack that will inevitably be theirs.
In this way, by allowing members to claim a larger share of what they are due by sticking it out for longer, we manage to organically “unrug” a community while, at the same time, incentivizing the community to make use of the first 90 days of inception to really get their act together and do their absolute best to add value to what very-well may be their last chance to make right all (or more) of they have been wronged. It is my belief that we will rise.
Original Post on Medium
About Buns Enchantress
0xBuns is the operated by Web3 developer Buns Enchantress, who is an experienced full-stack developer and Cofounder of SoulSwap Finance and Luxor Money.