ZRC2 interop exploit: PlunderSwap pools drained (2026-10-22/23)

From 2026-10-22 21:57 UTC, four PlunderSwap V3 pools holding ZRC2-backed tokens were drained of their real assets. The attacker paid for swaps with ZRC2 tokens whose transfers were visible during the transaction but discarded when the transaction committed, so the same tokens could be "spent" again and again. The cause was a bug in the Zilliqa node (zq2 v0.21.10), not in the PlunderSwap contracts. Each claim below can be checked on-chain or in Zilliqa's public source code.

Status (checked 2026-11-12, block 40,209,093)

• The bug is closed. A hard fork at block 39,242,023 (2026-10-30 07:52 UTC), shipped in zq2 v0.22, turned on unified_scilla_state. One block later it permanently disabled the interop precompiles for three ZRC2 contracts: SEED (0xfa254e12…), gZIL (0xa845c103…) and 0x173ca677…. SEED's ERC-20 proxy now reverts on totalSupply(). Mainnet reports zilliqa2/v0.22.1.
• None of the four drained pools was restored. Their token balances and prices are exactly as they were on 2026-10-24. The mainnet fork list (zq2-mainnet.toml) has no restore entry for any PlunderSwap pool, although zq2 has used targeted restore forks before (restore_xsgd_contract, restore_ignite_wallet_contracts, restore_denylisted_accounts_v1).
• LP positions in those pools now mostly resolve to tokens the pools don't hold. The first LPs to withdraw take whatever real tokens are left; the rest get nothing.

What Zilliqa says, and what the chain shows

How it worked

A ZRC2 transfer made from an EVM contract through the interop precompile (scilla_call, 0x5a494c53) is visible for the rest of the transaction. In zq2 v0.21.10 it is thrown away at commit if the ZRC2 contract's address is also present in the transaction's EVM state. The attacker put it there with a single BALANCE(<zrc2 address>):

sequenceDiagram
  participant A as Attacker contract
  participant P as V3 pool
  participant T as ZRC2 proxy (e.g. SEED)
  participant N as Node at commit
  A->>P: swap()
  P->>A: pays out the real token (kUSD, WZIL)
  P->>A: uniswapV3SwapCallback
  A->>T: transfer(pool, 3000 SEED) via scilla_call
  P->>T: balanceOf(pool): +3000, check passes
  A->>A: BALANCE(SEED ZRC2): address enters EVM state
  N-->>N: EVM delta skips the untouched ZRC2 account
  N-->>N: Scilla delta skips it because the EVM "has" it
  Note over N: The 3000 SEED transfer is lost. The attacker still holds it

In every transaction checked, the same 3000 SEED was "spent" again. Example: tx 0x90e5ec2b…d631d0 (block 38,747,068). The pool's SEED balance is unchanged across the block, the swap event and the ZRC2 TransferSuccess event both say +3000 SEED, the attacker contract still holds its 3000 SEED, and the pool paid out 9.244 kUSD of real tokens.

The bug (zq2 v0.21.10, exec.rs). After an EVM transaction the node applies the EVM delta, then the Scilla delta produced by interop calls. apply_delta_scilla skips any account the EVM state contains:

// Modified addresses by EVM are skipped
if dont_overwrite_evm_accounts_from_stale_scilla_state
    && let Some(evm) = evm_state
    && evm.contains_key(&address)
{
    continue;
}

evm_state holds every account the EVM loaded, not only the ones it changed, so BALANCE, EXTCODESIZE and EXTCODEHASH all add an entry. apply_delta_evm skips accounts that weren't modified. So neither delta writes the ZRC2 account, and the transfer disappears. The comment says "modified", which suggests the intended check was is_touched().

Why the safety net didn't fire. apply_transaction_evm has a deltas_overlap check that would fail exactly this transaction, but it only runs while the precompile-caller allowlist is empty:

From block 29,108,584 until the fix, every allowlisted ZRC2 proxy could be exploited this way. Normal users were not affected: EIP20ZRC2Proxy only passes the ZRC2 address as calldata and never touches it from the EVM. A contributing factor: the proxy's transfer/transferFrom ignore the precompile result and always return true.

Losses

Real assets that left the four pools, from each pool's last block before its first phantom-credited swap to block 38,814,118 (2026-10-24 01:20 UTC). ZIL at $0.00207 (Binance, 22:00 UTC on 10-22); zUSDT at its $1 peg; SEED and kUSD at pre-exploit on-chain prices.

Another ≈ 0.68M ZIL (≈ $1.4k) was lost on net in pools that stayed solvent, through arbitrage against the manipulated prices: SEED fell from 3.378 to 0.070 ZIL. Total ≈ 42.9M ZIL ≈ $89.0k.

On 10-22, before the exploit, zUSDT and zUSDC halved in price on-chain while Binance ZIL stayed flat. The pool was fully backed through that slide, which came from two sell-offs paid in real zUSDT by two arbitrage bots with no link to the attacker. That is why zUSDT is valued at its $1 peg here and not at the dislocated ~$0.50.

Why the pools stay broken

Uniswap-V3-style pools keep no reserve accounting an admin could correct. LP positions are claims on liquidity at the pool price, and the attacker moved each pool's price with tokens that never arrived. WZIL/SEED, for example, owes its LPs about 2.04M SEED and holds 4.5. The pools can't be redeployed either. A V3 pool's address is fixed by (factory, token0, token1, fee), and createPool reverts once it exists. Sending tokens back alone wouldn't help, because the prices and fee growth were moved by the phantom swaps. Putting LPs back exactly needs the pools' storage and balances restored at chain level, which only takes 4–5 storage slots per pool plus their balances. The 2026-10-30 fork did not do this.

The attacker

flowchart TD
  MEXC[("Exchange hot wallet 0x4224ed94
(very likely MEXC)")] -- "4 withdrawals, 52.8k ZIL" --> F["Funder 0xedfbf2d3
(new on 10-22)"]
  F -- "deploys 16 contracts, then the exploit" --> C["Attack contracts
0x8dccf8d1, 0x69b5ec91, 0x151897e2"]
  F --> E["Attack EOA 0x380c44a5"]
  C -. "real WZIL, kUSD, zUSDT out of the pools" .-> F
  F --> I["Intermediates
0xef1aa242, 0xcf15d3a9, 0xb628dc5b"]
  E --> I
  E --> D["6 deposit addresses"]
  I --> D
  F --> D
  D -- "≈ 14.04M ZIL" --> MEXC

Funded from, and cashed out to, one exchange. The funder 0xedfbf2d3… was unused before 2026-10-22 16:40 UTC, 5h17m before the first phantom swap. Every inbound transfer it ever received came from one exchange hot wallet, 0x4224ed94…: about 20.6k ZIL (≈ $43) in three withdrawals before the attack, and 32.1k after. About 14.04M ZIL of proceeds went back into that same hot wallet through six single-use deposit addresses:

Why MEXC (circumstantial). 0x4224ed94… had three transactions before 2026-09-08, and its real deposit sweeps begin at 10:16 UTC that day. Public reporting of MEXC's announcements puts the resumption of ZIL deposits and withdrawals on its new Zilliqa EVM integration at 2026-09-08 10:00 UTC. MEXC holds the account records for both ends: the withdrawals that funded the attack and the deposits of the proceeds.

Timeline (UTC, Oct 22–23).

What the behaviour suggests (inference).

• Iterating live. A fresh wallet, about $43 of seed money, and 16 contracts in five hours before a working exploit. Nothing was tested on mainnet beforehand. Whether the attacker already knew where the bug was can't be told on-chain; the zq2 code is public.
• An experienced on-chain trader. The 17.8KB contract is a general trading and flash-swap bot, redeployed rather than written that afternoon.
• Little laundering effort. The proceeds went straight back to the same KYC exchange the attack was funded from, through one or two throwaway hops.

Links to other incidents. The attacker cluster has no transfers with, and no shared counterparties (other than the exchange and DEX contracts) with, the X-Bridge deployer, owner, validators, ops/treasury wallet or drain chain, or the treasury wallets. None of its addresses is active on Ethereum. Its tooling also differs from the X-Bridge drainer's. That drainer used Foundry forge script gas limits (130% of the estimate); the ZRC2 attacker used a wallet with estimated limits and a script with hand-picked round limits (300k / 400k / 700k / 900k / 1.2M) at 3× the minimum gas price.

Leads

1. MEXC: the account or accounts behind the six deposit addresses and the four withdrawals to 0xedfbf2d3…, with KYC and login records, and a freeze on anything left.
2. Restoration: the pools' pre-hack storage and balances are fully determined by the chain (4–5 slots per pool plus token balances). A targeted restore fork, of the kind zq2 has done before, would return every LP position exactly.