Airdrops and points are mechanisms for distributing tokens to users based on protocol activity. Airdrops are typically retroactive and one-shot; points programs can run before TGE to capture pre-token activity, after TGE in recurring seasons, or both. In 2026 both function more as regulatory mechanisms than marketing: allocation size and recipient selection are legal inputs as much as distribution choices. Designing them well means accepting that 30% to 60% of recipients will sell within a week, sizing the allocation so liquidity can absorb the dump, and budgeting real money for sybil filtering.
What an airdrop actually does in 2026
Most writing on airdrops still treats them as marketing campaigns. They are not, or at least, not primarily. The original Uniswap drop in September 2020, 400 UNI per eligible wallet, set a template that every major airdrop since has followed: Arbitrum, Optimism, ENS, LayerZero, EigenLayer. Each is technically a community reward.
Functionally, each one serves to decentralize token distribution enough to argue the resulting token is not a security under the Howey test. The SEC's 2025 commentary on staking explicitly references distribution as a factor in the broader classification question. Founders should understand this clearly: airdrop design is a regulatory question first, and a marketing question second.
The typical 5% to 15% allocation, and which wallets get included, are legal inputs as much as growth inputs. Treating them as a marketing budget line item is how projects end up with airdrops that do not actually solve the problem they were meant to solve. The airdrop has to do regulatory work, distribution work, and growth work simultaneously, and most of the design failures I have seen come from optimizing for only one of those three.
Retroactive worked because nobody knew it was coming
Uniswap's airdrop worked because it was a surprise. Users had organically used the protocol over months, and the tokens arrived without warning. The moment airdrops became expected, recipient behavior shifted. Users now interact with new protocols specifically to farm, sybil farms multiply, and the airdrop's ability to reward genuine users degrades.
Every project launching after 2021 has run into this problem. The only real fix is to airdrop for behaviors the team has not publicly advertised as qualifying. Detailed pre-announced eligibility criteria almost always produce worse outcomes than vague retroactive selection. I have watched founders agonise over publishing the eligibility table, and most of the time the unintended consequence is that the table becomes the farming playbook.
Vague is better here. The downside is that users complain about not knowing what counts. The upside is that you actually filter, and the wallets you reward are closer to the ones you wanted to reward in the first place. If you cannot bring yourself to be vague about eligibility, at least be vague about the snapshot date and the weighting; one of those two needs to stay opaque or the program is just a public RFP for farming.
The points era
Points programs became the default pre-TGE bootstrapping mechanism somewhere around 2024. Blast, EigenLayer, Ethena, Berachain, Hyperliquid, and a few hundred smaller protocols ran on points rather than tokens for at least part of their lifecycle. Some programs finished at TGE; others, like Hyperliquid, kept running points in seasons after TGE, distributing additional supply on a recurring basis. The post-TGE seasonal model is closer to a retention loop than a launch mechanic, and the design tradeoffs differ accordingly.
The structural advantages of pre-TGE points are real. Points create no securities classification exposure pre-redemption, the supply schedule stays flexible until TGE, the team controls the redemption ratio, and there is no on-chain dilution visible during the growth phase. The structural disadvantages are equally real. Users bear uncompensated risk during the points phase, with no clear conversion ratio and no enforceable claim. TGE redemption disappointment is common, and this is where the points crash pattern tends to play out: the implied valuation users priced into their farming activity does not match what the team can actually deliver, and the post-TGE chart looks like a confidence collapse. The program also concentrates airdrop farmers whose exit at TGE creates predictable sell pressure on day one.
The advice I give most projects is straightforward: announce a future point system as early as possible, and make it retroactive. Even if you have no idea what the system will look like yet, the announcement drives user behaviour. Users will try to figure out the most valuable actions and start farming them. Then you design the system based on the data they generate. This has been done more than you think in crypto.
That move only works if you accept that the eventual system is shaped by what users actually do, not by what you wished they would do. If the data shows farmers concentrating on a single trivial action, the system has to weight that down, or you ship a points program that rewards the wrong thing. Letting the data shape the design is the entire point. Locking the design first and hoping users will follow it is the path that produces the points crash.
Sybil filtering is now a cost center
Sybil resistance has become an arms race, and there is finally enough public data to know what the arms race looks like. LayerZero's June 2024 ZRO airdrop filtered 803,273 wallets out of its claimant pool. That is 59% of total claimants removed, via a combination of community-submitted sybil reports and on-chain clustering analysis run by Chaos Labs and Nansen.
Optimism's first airdrop removed 17,000 sybil addresses, a smaller but still meaningful filter for an earlier era. ZKsync filtered aggressively and was criticized publicly for false positives, which is the failure mode at the other end of the spectrum. The common sybil signals are predictable by now:
- Wallets funded from the same source address
- Identical transaction patterns and sequences
- Single-protocol activity history with no other on-chain footprint
- Same-block timing across multiple wallets
- Graph-connected wallet clusters by token transfers
None of this filtering work is free. Founders running airdrops should budget for sybil filtering as a real cost center, typically six to twelve weeks of analyst work plus a community report window. Skipping this step is the fastest way to destroy your token's distribution quality before it has a price. I have seen teams treat sybil filtering as an optional polish step, and the result is always the same: a Gini coefficient that looks fine on paper because the farmer wallets are spread across thousands of addresses, and a chart that opens 40% below the implied valuation.
Plan for the sell-off, because it is coming
The empirical data on airdrop sell pressure is brutal. An academic study posted to arXiv and revised in July 2025 analyzed nine major airdrops, including 1inch, Arbitrum, Arkham, dYdX, ENS, Lido, Optimism, Tornado Cash, and Uniswap. Up to 66% of 1inch recipients transferred their tokens to exchanges within 24 hours. ENS and Lido saw over half of recipients interact with exchanges in the same window. LayerZero's estimated 50% to 60% initial sell pressure turned out to be roughly accurate.
Founders should model airdrops with the baseline assumption that more than half of distributed tokens will be sold within a week, and size the allocation relative to available liquidity to avoid an immediate price collapse. The early sell pressure mitigation playbook covers the design levers in detail, but the headline is operationally simple: assume the sell-off, then design around it instead of pretending it will not happen.
LayerZero's mechanism for partially absorbing this was a proof-of-donation filter. Claimants paid $0.10 in USDC, USDT, or ETH per ZRO to the Protocol Guild, the fund that supports Ethereum core developers. The economic logic is clean: a donation cost imposes a self-selection filter, and because the per-wallet cost scales with allocation size, farmers running hundreds of wallets face amplified costs.
The mechanism reduced sell pressure relative to comparable airdrops in the same quarter. The downsides are also real. Users resist paying to claim what they consider earned, and the filter does not work for projects where even a small per-wallet cost would exclude legitimate retail users with small allocations. I treat proof-of-donation as a design option worth considering, not a default. If your airdrop is large per wallet and you want price stability through the first month, it earns its place. If allocations are small and the user base is retail, it shifts demand away from the wallets you actually wanted to reward.
How big should the allocation be
There is no settled consensus on airdrop allocation size, but the observed ranges are clear enough to plan against. Conservative or VC-heavy projects allocate 3% to 8% of total supply to airdrops. Typical DeFi launches sit at 8% to 15%. Community-first protocols and DePIN networks run 20% to 40%. Memecoin-adjacent or purely community launches go above 50%.
Hyperliquid's 70%+ community allocation, with no VC participation, was an outlier that worked because the product had real fit before the token; very few projects can replicate that, and trying to copy the allocation without the underlying demand is how teams end up with a circulating supply nobody actually wants. LayerZero's 38.3% community allocation across multiple rounds sits at the aggressive end of normal for an infrastructure project.
When sizing the airdrop, model three things. First, the percentage you actually need to achieve your distribution objectives, not the percentage that feels generous. Second, what the market expects for your protocol category; under-allocating relative to category norm draws criticism, over-allocating wastes treasury. Third, the post-airdrop circulating float and whether available liquidity can absorb it. If your liquidity is thin and your airdrop is 30% of supply, you have not designed an airdrop, you have designed a price collapse with a press release attached.
For founders weighing whether to run an airdrop, a points program, or both, the architecture decision, the sizing inputs, and the sybil filtering plan are usually one piece of work, not three; a tokenomics review treats them that way.
The tax problem nobody warns recipients about
Airdrops are taxable income in most jurisdictions at fair market value on receipt. In the United States, IRS guidance from 2019 treats them as ordinary income at FMV on the day of receipt. In the EU, treatment varies, but most jurisdictions classify them as miscellaneous income. The UK applies income tax at receipt.
The recurring problem this creates is mechanical. Recipients owe tax at the TGE price, which is usually the highest price the token will see for months, and the token often drops 50% or more before they can realize the gain to pay the bill. A user who receives $5,000 of tokens at TGE and watches the value fall to $2,000 still owes US tax on the $5,000 figure. Founders running airdrops should time TGE and liquidity carefully so they do not create tax obligations recipients cannot discharge.
Disclose the tax status of tokens in airdrop communications instead of assuming users have read the IRS guidance. And consider the structural problem in the US specifically, where retail users often cannot receive large allocations without triggering tax bills they have no liquid path to pay. This is also one of the reasons projects sometimes geofence claims out of the US, and most readers do not realize that geofencing is a tax-protection move as much as a securities-law move. Worth covering this honestly in your launch communications before users find out the hard way.
How to know if your airdrop worked
The post-airdrop activity drop is the most reliable signal that separates real adoption from farming. LayerZero's weekly messaging volume fell from a 2 million to 4 million range pre-airdrop down to 200,000 to 250,000 after the June 2024 distribution. That is roughly a 90% drop. This pattern is typical, not exceptional.
Arbitrum saw a similar collapse after its March 2023 airdrop, and the same dynamic shows up in almost every dataset I have looked at. The interpretation is straightforward: most airdrop-driven activity is farming, and real adoption is the residual that stays after farmers exit. Founders measuring airdrop success should track 30-day and 90-day post-airdrop active addresses, not peak airdrop-day metrics, because the peak day is exactly the moment when the metric is least informative.
An airdrop that produces 200,000 sustained users and 1 million farmers is more successful than one producing 2 million farmers and 50,000 retained users, even though the second one looks bigger in the launch press release. Pick your reporting metric before TGE, not after, or the team will rationalize whichever number happens to look best.
One-shot or multi-season
LayerZero confirmed a second airdrop for 2025, redistributing unclaimed tokens from round one and rewarding post-TGE activity. This multi-season model is becoming more common: it lets teams use airdrops as a retention mechanism rather than a one-shot launch event. The downside is that it encourages continued farming and never gives users a clean closure point.
The alternative, a single airdrop that finishes, is operationally cleaner but wastes the surprise value of later rounds. Founders should choose explicitly between the two, not drift into multi-season because the first round underperformed and the team wants a do-over. Drift produces the worst version of both options.
Single-event airdrops work for projects that want a clear launch signal and a defined community size. Multi-season works for retention-driven protocols where ongoing user activity is the actual product, and the airdrop is just the recurring incentive. Picking either one badly is worse than picking either one well.
More from the 101 series
Frequently Asked Questions
01Are airdrops considered securities by regulators?
+
02What happens to unclaimed airdrop tokens?
+
03When are points taxable, and how does that differ from airdrops?
+
04Should a new project run an airdrop, a points program, or both?
+
