Throughout the years that people have been assessing this problem, we've gone from ICOs, to liquidity mining, to airdrops.

The airdrop criteria have continued to evolve from targeting basic on-chain users who interacted with the system once or twice, to GitHub contributors, NFT owners, Ethereum stakers and basically anyone who in some way could seem aligned with the goals of the project.

One of the key challenge is the avoid getting the token into the hands of those who are purely trying to game and predict the airdrop criteria, the airdrop farmers. While some argue that airdrop farmers who game the system are owed a reward for doing things like creating transactional volumes in the system (which helps the project gain a high valuation etc.), there is no reason to reward a group who will dumb your token and just move on to the next system to extract value from.

So the goal is to get the tokens into the hands of as many genuine users as possible, with the hope that some of those users will hold on to those tokens, participate in the governance decisions (usually though delegation) and make the system more decentralized in its decision-making.

The other key challenge is that it is very hard to copy the successes of other successful governance token airdrops since by the time that airdrop has been considered a "success", it will immediately become the target for airdrop farming strategies and get exploited in the later iterations.

So what you really want to optimize for are three things:

• Unpredictability
• Novelty
• Fairness

Celestia is considered a wildly successful airdrop that made many users happy. One of the things Celestia (and also Starknet) did was awarding GitHub contributors—not specifically to just its own GitHub repo, but to core infrastructure repos they considered have constributed to Celestia existing, such as Ethereum core repos and Bitcoin core repos.

However, as a consequence, teams like Scroll now have to deal with "GitHub repo spammers" that are trying to fix basic typos and other extremely minor or unnecessary things, such that this can't be used as a strategy anymore lest the Scroll airdrop designers either manually select commits that are eligible (lots of work) or use cut-off dates (which could work now but will be harder for future projects).

One thing that Starknet did was airdropping to Ethereum stakers. This was a nice idea I believe, but relied on data from third party providers that did not distinguish well enough between solo stakers and staking pools, and ended up leading to more irritation than appreciation.

The lesson that I've learnt from this (although I was not a part of the provisions committee and did not experience it first-hand) is that when you're trying to reward different groups of people it is extremely important that you work with data sets that are clear and legible—otherwise you'll end up with a lot of frustrated users and negative PR despite how good your intentions were. Therefore I'd opt for more simple data sets to work with rather than those that depend on obtuse heuristics.

There's no clear answer as to how one should do an airdrop because the goal posts will always keep moving here. Strive for originality. Personally, I do thing mixed approaches are probably still the best (mix of onchain users of your own product and external users to your system, both onchain and not).

The reason NFT communities have lately become more popular target groups for airdrops is probably because NFT projects already do spend massive amounts of resources at trying to avoid Sybil attacks on their through whitelisted mints (through quests, collabs with other collections, and other things) in order to build a real community that that is something you can piggyback off, however this will be more like the sprinkles ontop rather than the ice cream itself in terms of your distribution.

Designing an airdrop today is hard work! We don't get away with sloppiness on this part anymore like in the old liquidity mining days. It will require a serious effort from your team, months of thinking, data collection and preparation.

The airdrop moment is one of the most crucial moments for your project because it could very well be the moment when most users interact with your system for the first time, and they will judge you very harshly for your execution and never let you forget it if you somehow didn't reward real long-time contributors and instead chose some other easier way, or if it somehow slighted someone in fairness even in the minutiae.

It is worth to spend some serious time and consideration into this, perhaps way more than you think or you're prepared to deal with, atleast if you're a large protocol with a highly anticipated airdrop.

Best of luck!

One other thing to keep in mind is that regardless of how you do this, there's always a chance that some people will be very disappointed or very upset. There is no perfect airdrop. That's not an excuse to not try to make the best effort you can, but you're just going to have to accept some flack regardless.

P.S. The more info you can provide around which type of project you're thinking of, the more I can help with the brainstorming.