When considering the future of airdrops, it's easy to feel optimistic about their potential for aligning users of crypto networks. It’s just as valid to express skepticism based on the current state of the instrument. While it's clear that more experimentation is necessary in order to properly harness their power, the required overhead and lack of tooling to execute airdrops are prohibitive. But what are they, anyway?
Simply put, airdrops distribute tokens to past, present, or future network participants. Airdrops are part of a broader subset of 'token incentives.' Token incentives reward network participants for contributing resources like attention, labor, or capital.
Incentives, themselves, are not a new concept, nor are they limited to crypto. Traditional companies have long been utilizing them in some form to drive growth, engagement, and organizational alignment.
Likewise, incentives drive various participation patterns in crypto like user acquisition, retention, and engagement. They are also used to align long-term protocol contributors and governance participants. Crypto-native incentives, like airdrops, offer unique ways to reward users with ownership or governance rights in a given network.
While airdrops can be a powerful tool for driving network health results, to date most airdrop designs have been noted for their lack of effectiveness.
For airdrops to realize their potential, project teams must come to an understanding of what kind of participation their protocol values, and to what extent. The inability to answer these questions leads to inefficient airdrop distributions, including the following problems:
Before examining how airdrops can be better configured to drive network health results, let's take a deeper look at past and present design patterns.
Most are familiar with airdrops on Ethereum and EVM-compatible chains. But, the first airdrops occurred well before Ethereum had gone live.
The first known airdrop was Auroracoin, a cryptocurrency meant to challenge the Icelandic krona. Each Icelandic citizen was eligible for a pre-mined airdrop worth ~$385 at the time of distribution.
Following Auroracoin, some of the earliest airdrops were proof-of-work forks and child chain airdrops delivered to holders on centralized exchanges like Bittrex. For example, Bitcoin Private (a fork of Bitcoin) was distributed to holders of Zclassic, a fork of Zcash. The intention of token creators was to distribute tokens to holders who had a similar belief about crypto.
During the initial coin offering (ICO) craze, high-profile projects like OmiseGo would airdrop a portion of their supply to prospective network participants. They even began to experiment with criteria filters such as distributing to Ethereum addresses holding 0.1 ETH or more.
One could say that the early days of airdrops were relatively crude, but on to something. The shift to on-chain distribution and eligibility requirements enabled more creative airdrop design principles. Once on-chain, airdrop designers could segment based on user behavior for more impact.
The next wave featured large distributions from crypto giants like Uniswap. This kicked off the era of ‘Retroactive Airdrops'. Retroactive distributions introduced more design sophistication, as past usage could determine eligibility and reward tiers.
While these initial on-chain airdrops were innovative, they suffered from several flaws. First, they were very often one-time distributions. These distributions also tended to be untenably large in USD-value terms and in the amount of a given token’s supply distributed. This design limited the ability to iterate and optimize before making large outlays.
Participants would often become eligible for having only completed a basic action pre-drop. Over time, an expectation of future airdrop eligibility for using pre-token networks developed. This led to airdrop farming, a practice where individuals would create many accounts to use a project in anticipation of them all receiving a future airdrop. Farming practices tanked the efficiency of early on-chain airdrops and likely make up most on-chain transaction activity today.
These and other flaws caused airdrop-attributable growth to be underwhelming relative to the value distributed. Here, one can see the large figures behind UNI and other distributions from the ‘Retroactive’ airdrop era:
The next design iteration following the Retroactive airdrop era was ‘Conditional’ airdrops. The core innovation was the rule that a recipient completes some defined action to claim their reward. On top of these conditions, projects maintained the ability to segment and tier based on past behavior.
The highest-profile airdrops from this era came from projects like dYdX and Osmosis. For dYdX, trading history determined one's airdrop eligibility, but new trading volume was an additional requirement for claiming.
Ultimately, conditional airdrops improved upon the retroactive design philosophy by promoting retentive activity. However, they suffered from similar cost-efficiency problems due to their large, singular outlays. As with prior designs, large initial distributions removed the capacity to apply minimum viable rewards – an approach that would allow teams to get fast feedback loops on their distributions to determine success.
Conditional airdrops compressed profits for Sybil farmers due to increased overhead. Yet, some level of Sybil farm activity remained unchecked. This, too, damaged the efficiency of these designs. Below, one can see more data on the dYdX airdrop:
The next era of airdrop innovation introduced new philosophies around their frequency. In 2022, projects began taking a phased approach while also integrating prior airdrop design elements.
Recurrence or phasing allows for incorporating more feedback into each incremental design. Projects can efficiently drive network health by iterating on the parameters, optimizing, and testing new hypotheses. Additionally, they are able to somewhat avoid the wasteful practice of large initial outlays.
Recurring airdrop designs also improve upon the ability to mitigate Sybil farming. Projects can update eligibility requirements to filter out Sybil farming in successive iterations and lower initial airdrop amounts to demotivate potential farmers.
With that said, there is room for improving the design choices in the recurring airdrop era. Recurring airdrops have used smaller initial outlays than in previous eras. Yet, the early phases of recurring airdrops have still produced suboptimal results with sums that are too large.
There’s nothing inherently wrong with the baseline of a series of experiments producing suboptimal results (in fact, it is to be expected!). But, projects should be using a minimum viable rewards approach to early iterations to mitigate waste.
The Optimism $OP phased airdrop is a great example of these principles. They utilized a phased approach while maintaining retroactive eligibility requirements (bonus points for the multiplier scheme!).
However, as seen below, the value distributed in the initial phase was prohibitively large. Let’s take a look at some of the figures from the initial distribution of the OP airdrop from the current ‘Recurring’ era:
So what comes next in airdrop design philosophies? This is the billion-dollar question.
The key is velocity.
Recurring distributions, conditional claiming, and retrospective eligibility requirements encompassed the past and present of airdrop design. RabbitHole believes the next era of airdrop programs will come in the form of high-velocity experiments called 'quests'.
This design philosophy would allow for a phased approach with minimum viable rewards for initial distributions, driving faster feedback cycles between projects and their token holders. Projects could continue to iterate until they can achieve attractive results. At that point, deploying larger amounts to fuel growth becomes more efficient.
These programs will expand the scope for segmenting eligible recipients from on-chain behavior. Building on a mechanic made popular in NFT communities, allowlists will become a powerful tool for establishing eligibility criteria and staying ahead of airdrop farmers.
Quests will also expand the use of on-chain conditions for claiming. Projects will require users to take specific on-chain actions in order to claim their airdrop.
Transitioning into this era will require an improvement in the available tools. With RabbitHole, non-technical operators can spin up a quest in minutes to create a reward for any on-chain action. This frees up engineering resources to focus on improving core products.
While running a high-velocity, low-cost experimentation framework, project teams using RabbitHole will have the ability to analyze and report results in real-time, iterating based on the gathered data. Projects can also leverage a built-in audience of on-chain RabbitHole users.
Once teams are running a process where they can hypothesize, deploy, observe, measure, and iterate based on the results of experiments, they can then begin to optimize for relevant network health metrics like retention, CAC, payback period, and user:token holder ratio.
RabbitHole V2 is right around the corner. Subscribe to hear more about what’s new in RabbitHole V2 and more Airdrop case studies.