Dit is het soort bug dat protocollenteams 's nachts wakker houdt. Een $5M exploit op ZKSwap, mogelijk gemaakt door een enkele verklaring die op de verkeerde plaats is achtergelaten. Hier is een diepgaande analyse van hoe het is gebeurd en hoe on-chain monitoring het had kunnen stoppen. 🧵

1/ Op 9 juli werd GMX gehackt voor $42M. Maar er gebeurde die dag nog iets anders en bijna niemand merkte het op: de brug van ZKSwap werd stilletjes leeggehaald voor $5M. Het interessante deel? Er was geen ingewikkelde exploit bij betrokken. Gewoon een kritische functie die... niets deed.

2/ ZKSwap is een zk-rollup gebouwd op Ethereum. Net als veel rollups gebruikt het een brug om activa tussen L1 en L2 te verplaatsen. Als een waarborg bevat de brug een "Exodus Mode", een manier voor gebruikers om fondsen terug te vorderen zonder de operator nodig te hebben. In theorie is dat een geweldig idee. In de praktijk...

3/ Exodus-modus stelt gebruikers in staat om handmatig te bewijzen dat ze tokens bezaten in de laatst geverifieerde L2-status. Het is een fallback-mechanisme: vertrouwenloos, zelfbewarend, niet-interactief. Maar de implementatie van ZKSwap had één fatale fout: de functie die verantwoordelijk was voor het verifiëren van bewijzen verifieerde helemaal niets. Letterlijk.

4/ Hier is de code die de aanval had moeten stoppen 👇 Op het eerste gezicht lijkt het een echte zk-proof verifier. Maar kijk goed naar de eerste regel: return true; Dat is het. Niets anders wordt uitgevoerd.

5/ Het resultaat? Elke opname "bewijs" (ongeacht hoe nep) doorstond de validatie. Het contract accepteerde willekeurige claims over tokenbalansen... en crediteerde ze alsof ze echt waren. Het veranderde een vertrouwensloze fallback-mechanisme in een onbewaakte kraan.

6/ De aanvaller had geen fancy exploits nodig - alleen herhaalde aanroepen naar exit() met verzonnen gegevens. Ze omzeilden balanscontroles, trokken geld terug via meerdere tokens en misbruikten zwakke nullifier-logica om detectie te vermijden. Dat alles terwijl het contract zei: ✅

7/ Dit was geen obscure randgeval. Dit was de kernlogica voor activa-herstel, volledig open gelaten. En omdat Exodus-modus zelden wordt geactiveerd, bleef het gebroken pad... maandenlang onopgemerkt.

8/ Dit zijn de dingen die alarmen hadden moeten laten afgaan: • Exodus-modus die wordt geactiveerd na lange inactiviteit • Tientallen opnameverzoeken die tegelijkertijd plaatsvinden • Plotselinge piek in wijzigingen van balancesToWithdraw Dit alles was zichtbaar en had kunnen worden gestopt met realtime on-chain monitoring.

9/ Wat is de les? • Noodcode is nog steeds productiecoded • Terugvalpaden helpen niet als ze niet werken • Real-time monitoring is geen optie, het is cruciaal voor overleving