Anatomy of the October 29 Polymarket Drain: 737 Wallets, One Script, 60 Minutes
How does a hijacked script drain $2.73M from 737 wallets in under an hour? By reusing permissions those wallets had already granted. No contract exploit, no wallet bug — just standing approvals meeting a compromised vendor script. Here's the anatomy, question by question.
What actually happened on October 29?
Polymarket's trading interface loaded a third-party script that had been compromised. For users with active sessions, the script acted with everything those sessions could reach: it requested approvals and executed drains while users watched balances move. Polymarket halted trading within the hour. The same day, separately, Binance lost $6.3B in the largest exchange theft on record — two incidents, one news cycle, maximum panic.
The full minute-by-minute analysis covers both, with the response timeline.
Why did approvals make it possible?
Every "connect wallet" flow you've ever approved left a standing permission. Most wallets carry a dozen or more — several unlimited, from apps half-forgotten. Unlimited approvals don't expire and don't ask again: once signed, the spender can move tokens whenever it wants, within the allowance.
The October 29 script didn't need to trick anyone into signing anything new where an unlimited allowance already existed. That's the part people miss: the drainer reused old signatures. The revoke guide shows how to audit and clear them in about ten minutes.
Was EIP-7702 involved?
Delegation — the mechanism EIP-7702 enables — was part of the 2026 drainer pattern all year: the October 10 attack moved $1.54M through delegation chains, and CrimeEnjoyor's sweeper contract cleared 97% of EIP-7702 drains before that. A delegation is more powerful than an approval: instead of token-specific allowances, your whole account points at someone else's code.
Check yours: an account with no delegation has empty code at its address; a 0xef0100 prefix means delegated — and if you didn't delegate, treat it as compromise. The check-and-revoke walkthrough covers both browser and CLI paths.
What should I do if I traded before October 29?
Run the audit even if nothing looks wrong. Approvals signed long before the breach stayed valid through it. The sequence, if you find something:
- Revoke the allowance or delegation from your own wallet interface.
- Move remaining funds to a fresh wallet — not a new account on the same compromised session.
- Document everything before you touch it; you may need it for claims.
The first-24-hours playbook has the full ordering, and the mistakes that cost people their recovery windows.
And if any "recovery service" contacts me?
It's the second scam. No legitimate Polymarket recovery exists — no seed-phrase requests, no upfront fees, no "verification" payments. The fake recovery services breakdown documents the script they run.
The one-line takeaway
The drainer didn't beat 737 wallets. It collected on 737 wallets' old promises. Audit yours before someone else does.
Sources: October 29 double-breach analysis · 2026 Binance hack · BleepingComputer's incident coverage.
Top comments (1)
"The drainer reused old signatures" is the part everyone should take away. Nobody needed to be tricked into anything new where an unlimited allowance already existed. A compromised third-party script plus standing approvals is a nasty combination, and it argues for exact-amount approvals and regular revokes even on apps you trust.