This is the kind of bug that keeps protocol teams up at night. A $5M exploit on ZKSwap, enabled by a single statement left in the wrong place. Here’s a deep dive into how it happened, and how onchain monitoring could’ve stopped it. 🧵

1/ On July 9th, GMX was hacked for $42M. But something else happened that day and barely anyone noticed: ZKSwap's bridge was quietly drained for $5M. The interesting part? There was no fancy exploit involved. Just a critical function that did… nothing.

2/ ZKSwap is a zk-rollup built on Ethereum. Like many rollups, it uses a bridge to move assets between L1 and L2. As a safeguard, the bridge includes an “Exodus Mode”, a way for users to reclaim funds without needing the operator. In theory, that’s a great idea. In practice…

3/ Exodus Mode lets users manually prove they owned tokens in the last verified L2 state. It’s a fallback mechanism: trustless, self-custodial, non-interactive. But ZKSwap's implementation had one fatal flaw: The function responsible for verifying proofs didn’t verify anything. Literally.

4/ Here’s the code that should’ve stopped the attack 👇 At first glance, it looks like a real zk-proof verifier. But look closely at the first line: return true; That’s it. Nothing else runs.

5/ The result? Every withdrawal “proof” (no matter how fake) passed validation. The contract accepted arbitrary claims about token balances…and credited them as if they were real. It turned a trustless fallback mechanism into an unguarded faucet.

6/ The attacker didn’t need fancy exploits - just repeated calls to exit() with made-up data. They bypassed balance checks, withdrew across multiple tokens, and abused weak nullifier logic to avoid detection. All while the contract said: ✅

7/ This wasn’t some obscure edge case. This was the core logic for asset recovery, left completely open. And because Exodus Mode is rarely triggered, the broken path went unnoticed… for months.

8/ Here’s what should’ve triggered alarms: • Exodus Mode being triggered after long dormancy • Dozens of withdrawal calls happening all at once • Sudden spike in balancesToWithdraw changes All of it was visible and could’ve been stopped with real-time onchain monitoring.

9/ So what’s the lesson? • Emergency code is still production code • Fallback paths don’t help if they don’t work • Real-time monitoring isn’t optional, it’s survival-critical