Worked example · 2025-04

ZKsync unclaimed-airdrop pool drain — Ethereum / ZKsync Era — 2025-04-15

Loss: approximately $5M extracted from the ZKsync unclaimed-airdrop merkle distribution contract on April 15, 2025, with the on-chain extraction continuing through April 16. The extracted balance corresponds to the residual ZK token allocation that had been provisioned for airdrop recipients but had not been claimed within the post-airdrop window — i.e., the pool of allocations that the merkle distributor still held as a withdrawable balance after the official claim window closed. ZKsync is the Matter Labs–operated zk-rollup brand; the affected contract was the unclaimed-allocation custodian for the June 2024 ZKsync airdrop (ZK token).
Recovery: approximately full recovery on-chain via attacker-acceptance of a public bug-bounty-framed return offer issued by the Matter Labs / ZKsync security team within ~24 hours of detection. The attacker returned the funds against the published return-address in exchange for the agreed bounty share, with the residual funds re-credited to the ZKsync Foundation treasury under the foundation's communicated post-incident plan. Per the public disclosure, no end-user airdrop allocations were affected because the drained pool consisted exclusively of allocations that had not been claimed within the original window.
OAK Techniques observed: OAK-T11.002 in the broad construction (admin-key compromise to a privileged distribution contract — see Discussion for the taxonomy-mapping note), with OAK-T9.004 (access-control misconfiguration) as the contributory on-chain class — the merkle distributor's privileged sweep / admin function was a real authority surface that, once held by the attacker, produced an authorised-looking extraction. The ZKsync case is the canonical 2025 worked example for the post-airdrop unclaimed-pool exposure window as a distinct attack surface — the period between airdrop-window-close and treasury-sweep during which a single privileged key still controls an outsized residual balance.
Attribution: pseudonymous. No public named-individual attribution; on-chain investigators traced the attacker-controlled deployment / return wallet and the funding source, but no named-actor identification has been published as of the date of this example. The bounty-acceptance interaction was conducted in pseudonymous form on-chain. There is no public OAK-G01 attribution and no FBI / OFAC notice for this incident.
Key teaching point: the unclaimed-airdrop pool is a first-class custody surface, not a bookkeeping leftover. Most airdrop programs treat the post-window residual balance as a low-priority operational item — the airdrop is "done", the headline communications have moved on, and the privileged-key management around the residual contract is allowed to drift to the same hygiene level as any other mid-priority contract. The ZKsync case is the strongest 2025 demonstration that this is a category error: a single residual balance of $5M was extractable in a single transaction by whoever held the merkle distributor's admin role, and the operational attention applied to that role had decayed substantially since the airdrop launch in June 2024. Defenders running airdrop programs should treat the residual pool's admin key with the same key-management rigour as any other custody key controlling a comparable balance, including for the entire interval between window-close and treasury-sweep.

Summary

In June 2024, Matter Labs / the ZKsync Foundation conducted the ZK token airdrop, with eligible-address allocations distributed via a merkle-distributor contract. As is standard for airdrop programs, a non-trivial fraction of the allocated tokens went unclaimed within the official claim window — recipient wallets that did not initiate a claim transaction before the cut-off retained an on-chain entitlement that the distributor would not honour after window-close. Per the program rules, those unclaimed allocations were earmarked for return to the ZKsync Foundation treasury, but the residual balance continued to sit in the merkle distributor for an extended period after window-close.

On April 15, 2025, the privileged admin key controlling the merkle distributor was used to invoke a sweep / admin-extraction function and direct the entire residual balance — approximately $5M in ZK tokens — to an attacker-controlled address. The transaction was authorised-looking on-chain: it was issued by the legitimate admin role, called a real admin function, and produced a state transition the contract was designed to permit. From a contract-state perspective there was no bug; from a custody perspective the key controlling that role had been compromised.

The ZKsync security team detected the anomalous sweep within the same UTC day, suspended further claim-related activity at the operations layer, and within ~24 hours issued a public on-chain return-address offer framed as a bounty negotiation. The attacker accepted the framing, returned the funds against the published address, and retained an agreed bounty share. The ZKsync Foundation re-credited the recovered residual to its treasury and published a post-incident statement clarifying that no end-user airdrop entitlements had been affected.

For OAK's purposes the structurally novel feature is not the on-chain exploit pattern — admin-key-driven extraction via a privileged sweep function is a known T11 / T9.004 sibling pattern with prior worked examples — but the specific custody surface: the unclaimed-allocation pool of a completed airdrop, sitting in a merkle distributor whose admin-key hygiene had drifted from the airdrop-launch baseline. This is the post-airdrop-window unclaimed-pool exposure pattern, and the ZKsync case is its canonical 2025 example.

Timeline (UTC)

When	Event	OAK ref
2024-06	ZKsync airdrop launches; ZK token allocations distributed via merkle distributor on Ethereum L1; admin role configured for residual-sweep operations	(pre-event design)
2024-06 onward	Official claim window proceeds; a non-trivial residual fraction of allocations is not claimed by the deadline; balance accrues in the distributor as the post-window unclaimed pool	T11.002 surface (latent)
Pre-event (2024-06 → 2025-04)	Admin-key custody hygiene around the residual-sweep role drifts as operational attention shifts to other priorities; the residual balance remains in the merkle distributor	(latent custody surface)
2025-04-15	Privileged sweep / admin-extraction function on the merkle distributor is invoked by the attacker-controlled key; ~$5M in ZK tokens directed to an attacker-controlled address	T11.002 broad / T9.004 contributory extraction
2025-04-15	ZKsync security team detects the anomalous sweep; pauses further claim-related activity at the operations layer; begins on-chain investigation	(operator response)
2025-04-15 → 2025-04-16	ZKsync security team publishes public on-chain return-address offer with bounty framing; attacker engages with the offer	(recovery negotiation)
2025-04-16	Attacker returns funds against the published return address; agreed bounty share retained by the attacker; residual re-credited to ZKsync Foundation treasury	L1-equivalent recovery via bounty negotiation
2025-04 onward	ZKsync Foundation publishes post-incident statement clarifying that no end-user airdrop allocations were affected; community discussion of the post-window custody-hygiene gap	(transparency)

What defenders observed

The extraction transaction was authorised-looking on-chain. The sweep was not a smart-contract bug in the canonical T9.005 sense — the merkle distributor's admin function was a legitimate authority surface, designed to move the residual balance under the protocol team's control. The attack was a custody compromise of the key holding that authority, not a contract compromise of the function it called. Defenders attempting to triage with a smart-contract-vulnerability lens (audit replay, static analysis, formal verification of the contract code) would not have flagged this as anomalous because the contract was operating as designed.
The detection signal was anomalous-sweep-by-admin-role, not anomalous-state-transition. The merkle distributor produced exactly the state transition it was supposed to produce when its admin invoked the sweep. The detection signal that fired was operational: the ZKsync security team noticed an admin-role transaction at an unexpected time, going to an unexpected address, executing in an unexpected pattern. This is closer to a custody-monitoring signal than a contract-monitoring signal, and the relevant defender control is admin-key custody hygiene, not contract-side detection logic.
The bounty-negotiation outcome held because the attacker had no laundering urgency. The ~$5M balance was in ZK tokens, not stablecoins or BTC; the laundering surface for ZK is thin — bridges out of ZKsync are limited, the token's external liquidity is concentrated on a small number of venues, and aggressive attempts to liquidate would have produced visible price impact and immediate exchange-side cooperation. The attacker's expected-value calculation for accepting a bounty offer versus attempting to launder $5M of a single non-stablecoin asset converged toward acceptance. Defenders running bounty negotiations after admin-key compromise should expect the negotiation surface to be most productive when the extracted asset has thin external liquidity; the surface is much narrower for ETH / stablecoin / BTC drains.
End-user impact was zero, and the disclosure framed it accordingly. The ZKsync Foundation's post-incident statement was careful to clarify that no end-user airdrop allocations had been affected — the drained pool consisted exclusively of allocations that recipients had not claimed within the window. This is a substantively different communications posture from a typical exchange or protocol drain, and defenders running airdrop programs should pre-build this messaging shape: the post-window residual is a foundation-treasury asset, not a user-balance asset, and the user-impact disclosure should reflect that distinction explicitly.
The drift in admin-key hygiene over the 10-month interval is the actionable lesson. At airdrop-launch in June 2024, the merkle distributor's admin key was, by all available evidence, managed at the same rigour as the rest of the high-attention airdrop launch surface. By April 2025, ten months after window-close, the operational attention applied to that key had drifted. Whether the compromise was via key-storage decay, personnel rotation without proper key-rotation, or a discrete intrusion into the storage system, the necessary precondition was the prolonged exposure of a high-value privileged key that the program's day-to-day attention had moved past.

What this example tells contributors writing future Technique pages

The post-airdrop unclaimed-pool exposure window deserves an explicit defender-handbook section. ZKsync is the strongest 2025 case for treating the interval between airdrop-window-close and treasury-sweep as a distinct phase with its own custody-control requirements. Contributors writing OAK Mitigation pages around airdrop programs should call this out: the residual balance should be swept to a more conservative custody arrangement (multi-sig, time-locked, or hardware-backed) immediately after window-close, not held in the live merkle distributor under the same admin key that ran the launch.
OAK v0.1's T11.002 mapping is imperfect for admin-key compromise of a non-wallet privileged contract; the user-supplied mapping is honoured here, with a taxonomy-gap note. The published T11.002 page is scoped to wallet-software distribution compromise (Atomic-Wallet-pattern). The ZKsync incident is admin-key compromise of a protocol-side privileged contract — structurally closer to a T11.x admin-key-compromise sub-Technique that does not yet exist in v0.1 than to either T11.001 (third-party signing vendor) or T11.002 (wallet distribution). Contributors writing the OAK v0.x update should consider promoting "admin-key compromise of a protocol-side privileged contract" to its own T11 sub-Technique; ZKsync, alongside the Infini case at examples/2025-02-infini.md, provides the 2025 worked-example pair for that promotion.
T9.004 is the right contributory mapping for the on-chain manifestation. The merkle distributor's admin function existed and was functioning correctly; the access-control issue was that the role-holder's authority extended past the operationally-defensible window (i.e., the residual sweep was still callable months after window-close, by a key whose hygiene had drifted). The T9.004 framing here is "authority-window misconfiguration" — the contract permitted the action because the role still held; the defender control is to ensure the role no longer holds an outsized balance once the operational need has passed.
pseudonymous is the correct attribution status, even with the bounty-acceptance interaction. The attacker's engagement with the public return address — including the bounty acceptance and the on-chain return — produced no off-chain identification. Contributors writing the worked-example layer should not over-claim attribution simply because the actor was responsive to negotiation; bounty acceptance is a behavioural signal, not an identity signal. The pseudonymous marker is correct.
~100% recovery is achievable but conditional, and the conditions matter. The ZKsync recovery worked because (a) the asset was thin-liquidity ZK, (b) the protocol team published a credible bounty offer within ~24 hours, (c) the attacker's expected-value calculation converged toward acceptance. The KiloEx case at examples/2025-04-kiloex.md recovered under a similar pattern (attacker accepted a 10% bounty); the Loopscale case at examples/2025-04-loopscale.md recovered only partially under a similar negotiation. Contributors writing recovery-rate documentation should treat full-recovery-via-bounty as a real but conditional outcome, not a default expectation.

Public references

[zksyncpostmortem2025] — ZKsync Foundation / Matter Labs official post-incident disclosure of the merkle-distributor admin-key compromise, the affected balance scope, and the bounty-mediated recovery.
[peckshieldzksync2025] — PeckShield on-chain analytics for the extraction transactions and the bounty-return transactions, used as the cumulative-loss reference.
[slowmistzksync2025] — SlowMist incident analysis covering the attack surface (post-window unclaimed-pool exposure) and the admin-key compromise framing.
[chainalysis2025rug] for category-level context on 2025 DeFi-incident loss totals (used as the broad-context citation).

Discussion

The ZKsync incident is OAK's canonical 2025 case for the post-airdrop unclaimed-pool exposure window as a distinct attack surface. The 2024–2025 worked-example corpus contains a substantial number of airdrop-related cases — Sybil farming (T3.001), bundled-launch wash trading (T3.002), and locked-liquidity spoofs around airdrop-paired token launches — but the specific surface of the residual unclaimed pool after window-close has been under-documented. ZKsync is the case that establishes this surface as first-class.

The mechanism is straightforward to state and structurally hard to defend against without a deliberate operational shift. An airdrop program at launch holds the operational attention of the protocol's security team, communications team, and engineering team. The merkle-distributor admin key is hot, monitored, and protected at the level appropriate for its role. As the claim window proceeds, attention naturally shifts to other priorities: the next product launch, the next governance vote, the next protocol upgrade. The merkle distributor remains live, holding the residual balance, with an admin key whose attention-budget has decayed. The ZKsync interval — ~10 months from airdrop launch (June 2024) to compromise (April 2025) — is consistent with the hygiene-decay timescale observed across the broader corpus of admin-key compromises on protocol-side privileged contracts.

The bounty-mediated recovery is a second-order observation worth preserving. The 2024–2025 corpus contains a small but growing cluster of incidents in which the attacker accepted a public bounty offer and returned the funds: KiloEx (April 2025, ~100% recovery via 10% bounty), Loopscale (April 2025, partial recovery via negotiation), ZKsync (April 2025, near-complete recovery), and a handful of earlier cases (Euler, Mango Markets, Poly Network). The conditions that make this outcome reachable are not random: thin external liquidity for the extracted asset, fast and credible bounty offer from the protocol team, and an attacker whose expected-value calculation converges toward acceptance. Defenders running incident-response playbooks should treat the bounty-offer surface as a real first-tier response option, not a fallback — but should also recognise that the surface narrows substantially when the extracted asset is BTC / ETH / stablecoin and the laundering surface is wide.

The ZKsync case pairs directly with the Infini case at examples/2025-02-infini.md as the 2025 worked-example pair for admin-key compromise of a privileged contract. Infini is the confirmed-by-prosecution case (former-developer credential, court-ordered freeze recovery); ZKsync is the pseudonymous case with bounty-mediated recovery. Together they bracket the recovery-outcome range for this attack class: at one end, a pseudonymous attacker who accepts a bounty and returns nearly everything; at the other end, an identifiable insider whose recovery requires a court order. The taxonomy-gap that both examples expose — admin-key compromise of a protocol-side privileged contract being unmapped at the Technique level in OAK v0.1 — is the strongest 2025 case for promoting this entry vector to its own T11.x Technique in a future v0.x update.