Intro and general remarks
After reading Eli’s Airdrop Reflections cc @elibensasson , Benido, an acknowledged delegate in the ecosystem and community member, took the initiative to gather feedback on improving upcoming provision. So, this post is a collaborative post from several members of the ETHFinance community on reddit, which includes Starknet delegates. While our feedback is not based on scientific research (and quantitative data is hard to get anyway), the community discusses airdrop design a lot. Hence we hope our feedback is valuable.
Airdrops have been farmed since the fall of 2021 after UNI did their airdrop, but we believe it’s fair to assume they have never been farmed as intensively as these days. What started as some crypto natives farming with multiple wallets instead of one is now an industry with professional solutions. The result is a cat-and-mouse game between protocols without a token and farmers.
Basically, every airdrop of the past 6 months has received overwhelmingly negative feedback, but obviously, incentives allow professional players to invest a lot of money to put pressure on protocols to influence airdrop design and potential changes that favour their business (both for recent airdrops, but also future airdrops of other protocols).
Interestingly most airdropping protocols apparently did not ask for or exchange sybil reports from earlier airdrops. This was criticised a lot, especially when sybil reports from airdrop A received a lot of tokens from airdrop B.
Technically linear airdrops would be fair, but even those have received some negative feedback (“the rich getting richer”). A linear design potentially leads to centralization in governance and runs counter to the (Starknet) goal of distributing to a broad set of individuals. Technically it of course could be distributed linearly, but then a very high percentage of the addresses would have no relevant stake in governance.
In the case of EigenLayer the airdrop design was first a linear airdrop which was amended with a min allocation for all addresses. This was from our point of view a good decision for EL at that point in time, but likely will be exploited in the future similarly to how Uniswap started the “one interaction” farming in 2021.
On top a linear airdrop design is harder for L1s and L2s, since there is not a single metric (like amount deposited in the case of EigenLayer) that could be used. Transaction fees could be one metric, volume bridged, transaction volume onchain or a combination could be others.
The best airdrops of the past 12 months were likely part of the Solana ecosystem and were successful because Solana was not farmed as much after the FTX collapse. Jito ($JTO) was only distributed to 9852 addresses. The success is not a result of airdrop design, but more a lucky coincidence of missing focus of farmers and a surprisingly strong ecosystem rising from the ashes of FTX and Sam Bankman-Fried.
Feedback Starknet Provisions Part I
We will focus on the requirements for Starknet users since that accounted for 87% of the first airdrop.
From our point of view, there are indeed two design choices that should have been made differently:
-
The ETH minimum balance of 0.005 ETH was discussed extensively. We believe that the biggest issue here was that choosing the ETH balance was a strategic mistake and runs counter to the USP for layer 2s like Starknet. The value proposition is that gas fees are low, hence you can make hundreds of transactions with next to 0 ETH
-
A second design decision that wasn’t discussed as much as taking a snapshot at a certain block height. Two extreme examples: a user that had funds on Starknet and was active for months bridges out at block height snapshot -1 and is now not eligible for the airdrop. A second user that bridges in after being inactive for months (but has conducted the minimal viable activity to be eligible) bridges in at block heights snapshot -1 and is now eligible. In our opinion, the first user is a (more) valuable user for the Starknet ecosystem, but because of the snapshot based design, only the less valuable Starknet user is eligible and rewarded.
Suggestions on how to make subsequent rounds of Starknets better
Every requirement should be aligned with Starknet’s strategic approach and goals. We don’t believe in crafting requirements that might filter out some farmers, but contradict what Starknet is and has been building.
To make sure that is the case and also to get a realistic temperature check we suggest sharing provision requirements with trusted delegates and/ or trusted users (who potentially have to sign an NDA beforehand). Outsider feedback is valuable and could catch a possible 0.005 ETH balance v2 or at least give feedback to improve details.
As a rule of thumb, we believe that the fewer rumours about Starknet Provision part II (or III or IV) the better. Since every token can only be airdropped once and some competitors have already fully allocated the corresponding token supply, spending these tokens later could even be a strategic advantage. Still timing this is hard, since being too late could mean that the airdrop doesn’t have any positive effect either.
For more detailed design recommendations there are two core questions to consider:
What are the requirements to identify “real users”, as unique human beings?
What are the requirements to identify “good users”, so users that show alignment with Starknet?
The challenge to identify real users/ people and “proof of personhood” is hard, and likely even harder or connected to a lot of effort for Starknet because it’s not EVM based and making use of solutions like Gitcoin Passport likely needs additional development (to be e.g. able to link a Gitcoin Passport not just to a 0xEVM address, but also a Starknet address).
On top Starknet should ask all major protocols which airdropped tokens in the past 12-18 months for sybil reports. This will require a lot of effort for Starknet, but it is necessary because of the transparency of the space.
At the same time, we believe that there are metrics that raise the likelihood of a certain address being a real user. You can’t fake funds onchain. A user that has >X USD in assets onchain is likely a real user. Finding X is not easy, but could likely be derived from the sybil farm reports from other protocols and analytics platforms.
In other words: How does farming work? Users/ services split their capital into small parts and push it to a lot of addresses. To have assets worth >X USD in all sybilling addresses you would need a lot of capital.
Of course not all addresses with funds <X USD are farms, so this approach likely only finds real users, but doesn’t identify farmers - but it should be a step in the right direction and could lead to better distribution by potentially being more confident to giving out tokens to these users without going strictly linear.
These metrics then need to be measured in connection with a time-based metric instead of a snapshot. That makes sure it can’t be game easily and users aren’t disqualified by chance/ bad luck with regards to snapshot timing.
Addresses that were funded via FIAT onramps are likely both “real” and “good users”. Farms are usually funded via CEX withdrawals. FIAT onramps are likely used mainly by real users, because the onramp fees would eat profit from farms and there is usually a KYC process connected to using an onramp and farms will likely avoid these. These are good users, because they have more skin in the game than just sending / bridging old funds back and forth.
On top we believe the following metrics are valid to identify good/ aligned users:
- Users that still hold their $STKR airdrop, both in vSTRK, but also in defi protocols like AMMs and borrowing and lending. The defi spring campaign offered great incentives to put the STRK to work, so these would have been tracked accordingly.
- Users who did not receive a $STRK airdrop but have bought tokens on the secondary market
- Users paying gas in $STRK (though this one is likely being farmed already, so likely not the perfect signal)
- Users that have increased their net balance on Starknet (so not in USD, but more in STRK / ETH)
Sybil is a difficult challenge and the only way possible to counter this is to gather collective feedback iteratively. I invite you to share your input and feedback.
Also, assuming that I am not breaking any rules and guidelines on this forum by sharing link(s) or tag.