Home  >  Article  >  Understand the airdrop mechanism in one article: How to design a satisfactory airdrop?

Understand the airdrop mechanism in one article: How to design a satisfactory airdrop?

WBOY
WBOYOriginal
2024-06-10 16:32:13452browse

Understand the airdrop mechanism in one article: How to design a satisfactory airdrop?

Original title: "Understanding Airdrop Mechanics"

Original compilation: Luccy, BlockBeats

By this time, I have probably researched more airdrop cases than most people in this space. So I started to formulate some general observations about what kind of airdrops are good and what kind are bad. EigenLayer is a recent high-profile example of an unsuccessful airdrop that I think we can all learn some lessons from, but there are countless other examples and we could go on and on.

Intentions and Expectations

Zooming in, I think first and foremost the attitude of the team is critical in evaluating how to successfully conduct an airdrop. If there are any underlying motives for greed, they will show up very clearly. So, as cliché as it sounds, it’s important to stay calm. Your users are not fools, the broader crypto community is not fools, and investors are not fools. Every action you take will be analyzed and your intentions will be tested whether they were positive or negative. I'm writing this because I have a feeling teams think we're in 2021 and they can run a fraudulent strategy and no one will know what the hell you're up to. The market is much smarter and we have seen most of the scams as well as Ponzi schemes in various forms.

You should participate in the airdrop with the mentality that "cryptocurrency tokens are a novel and unprecedented way to drive value growth and benefit everyone." If you can stick to this mindset as long as possible, your actions should be guided on a fairly healthy trajectory.

The disconnect between reality and expectations may be the reason for the outrage in these airdrops. The less teams say, the greater the risk of a disconnect between them and users and the community, such as some common examples of teams not meeting expectations and examples of them leading to poor outcomes.

Airdrop Amount

This is the first thing that should be made clear to people: how much of the token supply is actually allocated to the airdrop. If you don’t disclose this up front, you run the risk of raising doubts about how much you value their contribution. In EigenLayer’s case, they touted the airdrop to the sky, only revealing a paltry 5% of the supply to the earliest backers. While they've gotten away with it by amassing $15 billion in TVL, they've violated their users' trust and left themselves exposed to competition. The decline in TVL will be an interesting metric that I will be watching closely. If you're not sure what the correct amount is, discussing it with as many stakeholders as possible will give you a good guide. I don't think 5% is the wrong number, just expectations exceeding reality.

Country Eligibility

What are the countries where people are eligible to participate in the airdrop and the countries where they are not eligible. This was probably the biggest mistake EigenLayer made, they wanted to appeal to people around the world for their TVL, but didn't want to take on the legal risks associated with those countries. This is a classic case of wanting the best of both worlds, but in an unfair way. Either they have to draw a line in the sand and be upfront with U.S. and Asian users that they don't qualify, or accept the legal risks that come with it. Many teams are so afraid of the legal risks in cryptocurrency that they undermine their own chances of success. No matter what you do, if you're successful to a certain extent, you're going to have to fight Gary eventually.

Token Distribution

This part is about the minutiae of how the tokens are actually distributed, which is a metric that makes the challenge exponential. Common dilemmas at this stage are:

· Whales should not get all the tokens just because they invested a lot of capital

· The smallest users should get some base amount anyway Token

However, these two goals are in direct conflict. If you decided to give something to small users anyway, there is now a strong incentive to split your wallet and meet the minimum eligibility criteria to receive the airdrop. This will work against whales (your largest customers) because you encourage them to divide their wallets as well. I have a theory on how to solve this problem, but that will be discussed at another time. At the moment, the best approach for industry standards seems to be:

· Implement a tiered system

For "large" users, the amount allocated is slightly less linear (more liquidity, more more tokens);

For "medium" users, allocate a linear amount;

For "small" users, allocate a fixed amount;

· Use some rough criteria To implement this tiering system

While this leaves a lot of room for improvement, this is the best the team can do at the moment. While there is no right way to do this, the worst way is to remain opaque about the structure and how it is determined.

Sybil Dealing

The problem with a token distribution scheme that is hierarchical and not entirely linear is how to differentiate between small users and Sybil? Many items are difficult to distinguish between them. Every team seems to approach this problem differently. Some of these ways include but are not limited to:

· Establishing "self-reporting" schemes, schemes like LayerZero or Hop, where users inform each other, or projects get help from the community

· Using on-chain Clustering (Only for large-scale industrial farms laundering money from Binance)

· Select attributes based on reputation, most Sybil is not eligible

The selections are ordered from easy to difficult. Unfortunately, all of these problems are really just data segmentation problems, and not just ordinary data, but big data. I'll talk more about this later.

Claim vs Direct to Wallet

This is another choice that affects your airdrop. To clarify, claim mode is where users have to obtain the airdrop themselves, whereas going directly to the wallet is where the airdrop magically ends up being associated with you. The convenience of the latter is great, but it can also lead to more instant selling by users, as those who don't know they qualify or aren't even paying close attention will sell to get funds. This argument can also be made in reverse, namely that it is more difficult for non-token holders to generate awareness.

A comprehensive solution to this dilemma would be to split the airdrop into claims and directly to the wallet, but I haven’t seen that happen yet, it’s just an idea.

Unlock Date/Unlock Schedule

If I were to pick one thing that is most important, it would be the price and subsequent valuation of the token. One thing that teams should be aware of is the terms on which other holders receive liquidity and whether locked tokens can be staked. The more favorable the terms are to insiders, the more the airdrop will be viewed as a liquidity event and encourage others to adopt a short-term orientation. A few years ago, there were a lot of tricks teams could pull off, but the market then got smarter. If you need to restructure things with investors, do it. Bad airdrops are never worth it.

Conclusion

In short, this article ends here. My purpose in writing this article is to synthesize the many different approaches I see on the market and put together information for others who may be considering airdropping. One thing that holds true in all cases is that there is a severe lack of tools to perform good airdrops, which is something I'm very much looking forward to sharing as our data stack at 0xArc allows us to perform high-level analysis on millions of wallets across numerous chains. Large-scale analysis of quality. Until then, I'll go ahead and reveal a few tips on how I think this problem will be best solved.

The above is the detailed content of Understand the airdrop mechanism in one article: How to design a satisfactory airdrop?. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn