ZKsync airdrops: a closed drop and the lessons it left

Anatomy of the ZK airdrop

The numbers below come from the ZK Nation post and claim FAQ. Everything is historical: the window closed on 3 January 2025, and the original portal at claim.zknation.io now redirects to the FAQ. Our full record is on the ZKsync airdrop page.

Snapshot

24 March 2024, 00:00 UTC, covering ZKsync Era and ZKsync Lite activity

Scale

17.5% of total ZK supply to 695,232 wallets, with no vesting or lockup

Per-address cap

100,000 ZK on the usage-based path; allocations below 450 ZK were recycled, lifting the minimum to 917 ZK

Claim window

17 June 2024 to 3 January 2025

Unclaimed

Never minted; added to the mintable supply controlled by the Token Assembly and distributable only through governance

Part of the contributor share, stated as 5.8% of supply, was directed to the treasuries of ZKsync-native projects. The rest went to groups such as Ethereum client developers, GitHub contributors, educators, audit researchers and community members. GitHub contributors had to link their address to their account by 25 June 2024.

What the filters tell us

The ZK Nation post describes a human-first approach that avoids strict Sybil rules, because such rules can exclude real users. Allocations were scaled by the value of activity rather than by the number of transactions, which kept most Sybil allocations small, and a final step used conservative heuristics to remove the most obvious swarms. The post openly says some sophisticated bots may still have qualified.

Our reading, which is judgement and not an official statement, is that this design trades precision for fairness to small users. It also tells you what not to do. Splitting capital across many wallets did not increase value-scaled allocations, and the minimum and maximum bounds meant neither tiny nor huge wallets moved the outcome much. Compare the contrasting approach of a staking-based drop in our Bitcoin ecosystem page, or the thresholds used by Starknet.

A worked example of reading a value-scaled rule

Take two hypothetical wallets, labelled here as an illustration and not as real data. Wallet A made a few hundred small transactions that moved little value. Wallet B made a handful of transactions that moved far more value. Under a rule that scales allocations by the value of activity, B's raw score is higher despite doing less. The published bounds then squeeze both outcomes: nobody on the usage path could receive more than 100,000 ZK, and recycling allocations below 450 ZK lifted the floor to 917 ZK. So the question to ask of any future rule is not "how many transactions?" but "what is being measured, and where are the floor and ceiling?".

When a project publishes none of that, the sensible reading is that you do not know. Do not fill the gap with a forum guess, and do not pay for a "score checker". The same logic applies to GitHub-linked and other contributor routes in this drop, which required an explicit link step before 25 June 2024. An action that is required but never announced is, by definition, one you cannot plan for.

Native account abstraction: what it means for you

ZKsync's documentation says accounts can initiate transactions like an externally owned account and can also have arbitrary logic, like a smart contract. It does not state that every account is a contract, so we avoid saying that. Smart accounts can add custom signature schemes, native multi-sig, spending limits and application-specific restrictions. Accounts declare a version, and choose sequential or arbitrary nonce ordering. The docs note arbitrary ordering can cause rejected or stuck transactions.

For airdrop participants the relevant effect is that gas can be abstracted away. The project said the ZK claim was designed to be gas-free through this mechanism. The mechanism itself, a paymaster, is general. A paymaster can sponsor fees or let you pay in an ERC-20, and it is not specific to airdrops.

Fees and paymasters

The fee model page is an overview. It says L2 prices depend on volatile L1 gas prices, because pubdata, meaning state diffs, deployed bytecode and L2-to-L1 messages, must be published to Ethereum. Opcodes are priced by how expensive they are to prove, so some, like keccak256, cost more than on Ethereum. Storage access is pre-charged at the cold cost and the operator refunds the difference for warm slots. The page does not give a typical fee, and we are not going to estimate one.

Two further notes from the docs. Paymaster transactions generally use more gas than standard ones, and the first token allowance can cost up to about 400,000 gas at a 50 gwei L1 gas price. Paymaster verification rules are also not fully enforced yet, and non-compliant paymasters may stop working. In plain terms, "someone else pays" has its own costs and constraints.

The unclaimed-token incident, step by step

This is a rare case where an airdrop's risk sat on the project side. Per the ZK Nation forum update:

1. 1

   Compromised admin account

   The forum announced that an admin account for three airdrop distribution contracts had been compromised.

2. 2

   Sweep function called

   The attacker called a sweep function and minted about 111 million unclaimed ZK, roughly 0.45% of total supply.

3. 3

   Scope of impact

   ZKsync stated the protocol and the ZK token contract were not affected.

4. 4

   Response

   Transaction filtering was applied to the attacker addresses, and the Security Council offered a bounty for returning most of the funds.

5. 5

   Resolution

   On 25 April 2025 the team reported that the funds had been returned and the case closed. The recovered assets are held by the Security Council, and governance decides their use.

The lesson for participants is limited but real. A claim contract is code controlled by people. After a claim window closes, leftover tokens can become a target, so projects should lock down admin keys. As a participant you cannot fix that. What you can do is avoid holding more in one wallet than you need and keep an eye on official channels after any incident. Also see revoking token approvals.

Projects on ZKsync in our database

The campaign list at the top of this page is generated from verified project files and currently contains two entries that touch ZKsync. The first is ZKsync itself, closed. The second is GRVT, which its Help Center describes as settling through a zkSync-based rollup to Ethereum. GRVT's airdrop registration closed on 6 August 2026, and registered users receive a fixed 280 million GRVT pool in tranches over 12 months. We list it as ended for new participants.

It is worth knowing where the next real announcement would appear. The ZK Nation blog, claim documentation and governance forum are the places the sources above came from, and the unclaimed supply can only be distributed through governance. So a future distribution of that supply would have to pass a governance process in public before anyone could claim it. A rumour that skips that step is a rumour.

Neither entry gives you an open action today. Our ended campaigns list shows how we keep closed records, and the claims page explains how to treat claim windows that are still open elsewhere.

Explorer and bridge from official docs

The Era network details page names explorer.zksync.io as the official block explorer and bridge.zksync.io as the official portal bridge between Ethereum and ZKsync Era. The page did not list a chain ID or an official RPC endpoint in the text we could read, so we leave those out. Get network settings only from the official docs.

We have not verified which wallets the ZKsync docs recommend, so we name none. Check the wallet's own site and its ZKsync support statement. For why custody matters, see our custody guide.

Fake claim sites and how they differ from the real thing

Our scam guide covers the full set of patterns, and the legit airdrops guide explains how we separate real from fake.

What we would check first

1. Source: zknation.io or the project's own docs, with a date.
2. Type: airdrop, grant or incentive, and who funds it.
3. Mechanism: who pays gas, and does a paymaster or allowance prompt appear?
4. Signature: does the prompt match the promise?
5. Exposure: would losing the wallet's contents matter?
6. Deadline: is the window written down by the project, not a summary site?

Browse the other ecosystems or see Ethereum, which ZKsync settles to.

Written by the airdrop.promo Editorial Team. See how we verify. Educational content only, not financial advice.