
ZKSync Airdrop Sparks Controversy: Examining the Challenges of Web3 Project Cold Starts
TechFlow Selected TechFlow Selected

ZKSync Airdrop Sparks Controversy: Examining the Challenges of Web3 Project Cold Starts
Who are the core value users for Web3 projects during the cold start phase today?
Author: @Web3Mario
Abstract: The hottest topic last week was undoubtedly the public airdrop eligibility verification event surrounding ZKsync. Originally, I was studying and writing about TON's DApp development experiences, but seeing this controversial incident and the extensive community discussions it sparked gave me some reflections, prompting me to write this article for sharing.
Overall, ZKSync’s airdrop design adopted an asset-proofs-based distribution approach, focusing more on rewarding developers, core contributors, and native ZKSync degen whales—resulting in a scenario where native degen whales are laughing while farming studios are crying.
The Community Debate: Is Interaction Key or Is Capital Size Key?
For a long time, the Web3 industry has seemingly established a paradigm of using airdrops to attract users to adopt products, thereby achieving project cold starts. This is especially true in the Layer2 space, where projects guide developers and users by shaping expectations around potential airdrops, stimulating active DApp development and maintenance by builders, while encouraging early-stage users to bridge funds to the target Layer2 and actively engage with its DApps—thus boosting ecosystem vitality. This has become standard practice.
Therefore, historically, users generally expected ZKSync’s airdrop to follow the models of its two direct competitors, Arbitrum and Optimism. Logically speaking, whether considering industry influence, VC backing, or fundraising scale, such an assumption made sense. However, the actual outcome turned out vastly different, leaving many users who applied past strategies to participate in ZKSync disappointed with their rewards, sparking widespread controversy within the community.
To understand the root of this debate and extract lessons for the future, we need to revisit the airdrop designs of Arbitrum and Optimism. Let's first look at Arbitrum’s airdrop event, which dates back to March 2023. It distributed 11.62% of the total supply as $ARB tokens to Arbitrum users and allocated another 1.13% to DAOs operating within the Arbitrum ecosystem. The snapshot date was February 6, 2023, and the user-specific criteria were as follows:
l Bridge to Arbitrum: Users needed to transfer funds to Arbitrum One or Arbitrum Nova.
l Transactions across different months: Having transacted during two, six, or nine distinct months.
l Transaction frequency and interaction: Completing over 4, 10, 25, or 100 transactions, or interacting with a corresponding number of smart contracts.
l Transaction value: Total transaction volume exceeding $10,000, $50,000, or $250,000.
l Providing liquidity: Depositing more than $10,000, $50,000, or $250,000 in liquidity.
l Arbitrum Nova activity: Conducting more than 3, 5, or 10 transactions on Arbitrum Nova.
Each criterion had a specific scoring method, capped at 15 points, used to determine the amount of $ARB a user could claim. The relationship between score and reward was roughly linear, starting from 3 points and capping at 10,200 $ARB. For DAOs, rewards were determined directly based on activity assessments. Ultimately, 137 DAOs received airdrops, with Treasure and GMX receiving the largest allocations—8 million $ARB each—a substantial return by any measure.
Now let's turn to Optimism. Unlike Arbitrum, Optimism conducted its airdrop in multiple rounds, distributing a total of 19% of the token supply. The first round dates back to June 2022, when 5% of the supply was distributed to 260,000 addresses. To date, four rounds have been completed, with the following rules:
l Round 1: Ordinary users (1 transaction) vs. active users (>4 transactions), plus participants in Ethereum DAOs, users of Ethereum multisig wallets, Gitcoin donors, and cross-chain bridge users. Each identity received a fixed reward, with the latter three being stackable.
l Round 2: Users with total gas fees > $6.1 or staked governance tokens for over 2,000 days shared 11,742,277 $OP.
l Round 3: Users with staked governance tokens for over 18,000 days shared 19,411,313 $OP.
l Round 4: 10,343,757 $OP were allocated to NFT creators.
From this review, it's clear that interaction frequency served as a key metric—users with higher engagement typically received larger rewards. However, ZKSync appears to have abandoned this implicit rule. In ZKSync’s airdrop design, user eligibility and allocation were calculated through four sequential steps, with general rules as follows:
l Eligibility Screening: Every address that conducted transactions on ZKsync Era and ZKsync Lite was evaluated against seven qualification criteria—for example, interacting with more than 10 non-token contracts, each required to have at least 30 days of activity, or sending at least five transactions on ZKsync Era.
l Allocation: For qualified addresses, the reward amount was calculated using a value-scaling formula based on the weighted average of funds sent to ZKsync Era and how long those assets remained in the wallet. Participation in DApp protocols received a 2x multiplier—meaning users who bridged large amounts, held them long-term, and actively used them in risky activities like providing DEX liquidity would receive greater rewards.
l Multipliers: Addresses meeting certain conditions received multipliers in the allocation, typically involving holding high-risk ZKSync-native altcoins or NFTs.
l Sybil Detection: Finally, ZKSync performed Sybil attack detection to filter out most bots. The detection focused on two aspects: the source of the first ETH deposit after an EOA address creation, and interactions between the EOA and CEX deposit addresses—effectively leveraging CEX KYC characteristics.
From these rules, it's evident that interaction count was not factored into the reward calculation. Instead, the focus shifted squarely to account capital size and willingness to hold risk-weighted assets. As a result, many users who followed previous patterns—engaging in frequent interactions across ZKSync—were shocked by their minimal rewards. This became the core trigger of the controversy. These “airdrop farmers” or studios often spread large funds across hundreds or even thousands of addresses, using small amounts to interact with protocols via automated scripts or manual task completion, anticipating behaviors likely to be rewarded. ZKSync’s new model rendered this strategy ineffective—many highly active addresses ended up paying more in gas fees than they received in rewards, naturally leading to dissatisfaction.
Moreover, we can easily observe numerous airdrop hunter KOLs on X—individuals whose content revolves around helping others earn project airdrops, often commanding large, influential followings. They leveraged social media to pressure ZKSync’s team into changing course. Yet, the official stance remained firm, refusing to revise the rules under pressure—leading to the current situation. Accusations and rebuttals regarding potential malicious behavior further fueled this public relations battle.
In hindsight, both sides’ positions are understandable—the right or wrong depends entirely on perspective. But what’s worth reflecting on is this: at this stage, who exactly are the core value users for Web3 project cold starts? Or rather, which types of users should truly be incentivized during the early phases?
Heavy Interaction Breeds Sybil Attacks; Asset Proofs Breed Monopolization
Rewarding early adopters via airdrops has proven effective for Web3 project cold starts. A well-designed airdrop mechanism helps efficiently attract seed users in the early stages and educates them by incentivizing key protocol behaviors, enhancing product stickiness. This is precisely why most Web3 projects have historically emphasized rewarding interaction—the primary drawback, however, is lowered entry barriers, making campaigns vulnerable to Sybil attacks. Since interactions can be easily automated and scaled, professional teams gain significant operational advantages. When massive bot accounts flood in, they create temporary artificial prosperity. But these "users" are nomadic, offering no real support for long-term growth. After claiming rewards, most immediately sell to recycle capital and boost returns—diluting rewards meant for genuine value users, ultimately counterproductive.
Why did this mechanism work well initially? Simply because such specialized teams were fewer, and most users hadn’t yet developed habitual strategies around incentive mechanics. Interactions were relatively pure and organic—authentic user behavior—which allowed rewards to be efficiently distributed. The resulting wealth effect benefited both users and projects. But as profit-driven motives intensified, this model clearly struggles to attract genuine users today. In my view, the effectiveness of interaction-centric airdrops peaked around the time of Arbitrum’s airdrop.
This explains why ZKSync chose to shift focus from interaction counts to relative asset size as a proxy for identifying valuable users. However, this asset-proofs approach isn’t without flaws. While it effectively mitigates Sybil risks, it introduces a new problem: wealth concentration and unequal distribution.
We must remember that a core tenet of Web3 projects is bottom-up, decentralized governance. Grassroots support—from small-balance real users—is the foundation of sustainable growth. Only when there is a strong base of retail users do whales find meaningful incentives to join, creating a self-reinforcing cycle. After all, whales benefit most when the ecosystem is broad and deep. But under an asset-proofs model, whale users gain disproportionately high rewards from day one, weakening motivation for grassroots participation and making it difficult to build a cohesive community.
Ultimately, when designing cold-start mechanisms, Web3 projects must carefully define their ideal value-user profile and tailor incentive structures accordingly—maximizing genuine engagement while minimizing Sybil vulnerabilities. How to design such mechanisms remains a deeply important and valuable question. I welcome everyone to join the discussion on my X and brainstorm creative solutions together.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News









