Det här är den typ av bugg som håller protokollteamen vakna om nätterna. En exploatering på 5 miljoner dollar på ZKSwap, som aktiveras av ett enda uttalande som lämnas på fel plats. Här är en djupdykning i hur det hände och hur onchain-övervakning kunde ha stoppat det. 🧵

Den 9 juli hackades GMX för 42 miljoner dollar. Men något annat hände den dagen och knappt någon märkte det: ZKSwaps bro tömdes i tysthet för 5 miljoner dollar. Den intressanta delen? Det var ingen fancy exploit inblandad. Bara en kritisk funktion som gjorde... ingenting.

2/ ZKSwap är en zk-rollup byggd på Ethereum. Liksom många sammanslagningar använder den en brygga för att flytta tillgångar mellan L1 och L2. Som en säkerhetsåtgärd innehåller bron ett "Exodus-läge", ett sätt för användare att återkräva pengar utan att behöva operatören. I teorin är det en bra idé. I praktiken...

3/ Exodus Mode låter användare manuellt bevisa att de ägde tokens i det senast verifierade L2-tillståndet. Det är en reservmekanism: pålitlig, självvårdande, icke-interaktiv. Men implementeringen av ZKSwap hade ett ödesdigert fel: Funktionen som ansvarar för att verifiera bevis verifierade ingenting. Bokstavligen.

4/ Här är koden som borde ha stoppat attacken 👇 Vid första anblicken ser det ut som en riktig zk-säker verifierare. Men titta noga på den första raden: return true; Det är allt. Inget annat körs.

5/ Resultatet? Varje "bevis" för uttag (oavsett hur falskt) godkändes av valideringen. Kontraktet accepterade godtyckliga påståenden om tokensaldon... och krediterade dem som om de vore verkliga. Det förvandlade en pålitlig reservmekanism till en obevakad kran.

6/ Angriparen behövde inga avancerade exploits - bara upprepade anrop till exit() med påhittade data. De kringgick saldokontroller, drog sig tillbaka över flera tokens och missbrukade svag nullifier-logik för att undvika upptäckt. Allt medan kontraktet sa: ✅

7/ Det här var inte något obskyrt kantfall. Detta var den grundläggande logiken för tillgångsåterställning, som lämnades helt öppen. Och eftersom Exodus Mode sällan utlöses, gick den trasiga vägen obemärkt förbi... i månader.

8/ Här är vad som borde ha utlöst larm: • Exodus-läge som utlöses efter lång dvala • Dussintals uttagssamtal sker på en gång • Plötslig ökning av saldonToDraw-ändringar Allt var synligt och kunde ha stoppats med övervakning i realtid på kedjan.

9/ Så vad är lärdomen? • Nödkod är fortfarande produktionskod • Reservvägar hjälper inte om de inte fungerar • Övervakning i realtid är inte valfritt, det är överlevnadskritiskt