DEV Community: Srey Leak

e October 29 Polymarket Drain: 737 Wallets, One Script, 60 Minutes

Srey Leak — Sun, 01 Nov 2026 18:45:14 +0000

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.

Auditing Permit2 Allowances with Python: A Practical Walkthrough

Srey Leak — Tue, 20 Oct 2026 16:48:29 +0000

Wallet audits sound like an enterprise security product, but the core of one is a script you can run in a few minutes: enumerate what your address has permitted, through which contracts, and at what limits. This walkthrough covers the Permit2 layer — the approval hub most DEX users have approved at least once — plus a delegation check for EIP-7702, the 2026 drain vector.

The conceptual background (why Permit2 centralizes risk and how 7702 delegation abuse works) is in two research posts: https://brainresearchhub.net/research/security/eip-7702-vs-permit2-comparison and https://brainresearchhub.net/research/security/revoke-approvals-guide

What we are checking

Permit2 allowances. The Permit2 contract (0x000000000022D473030F116dDEE9F6B43aC78BA3) stores per-token, per-spender allowances for every user who approved it. The canonical way to enumerate them is to scan Approval events emitted by Permit2 where owner = your address, then re-read current amounts (events show the last write, not the current state).
EIP-7702 delegation. An EOA under 7702 delegation has runtime code starting with the 0xef01 designator. eth_getCode returning anything for a "normal" wallet is a red flag unless you set the delegation yourself.

The script

Read-only. Works against any JSON-RPC endpoint you trust (your own node or a reputable provider).

"""
permit2_audit.py - read-only Permit2 allowance + EIP-7702 delegation audit.
Usage: python permit2_audit.py 0xYourAddress [--rpc https://your.node]
Deps: pip install requests
"""
import argparse, json
import requests

PERMIT2 = "0x000000000022D473030F116dDEE9F6B43aC78BA3"
APPROVAL_TOPIC = "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925"
TRANSFER_TOPIC = "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"

rpc_id = 0

def rpc(url, method, params):
    global rpc_id
    rpc_id += 1
    r = requests.post(url, json={"jsonrpc": "2.0", "id": rpc_id,
                                 "method": method, "params": params}, timeout=30)
    r.raise_for_status()
    out = r.json()
    if "error" in out:
        raise RuntimeError(out["error"])
    return out["result"]

def topic_addr(t):        # last 20 bytes of a 32-byte topic
    return "0x" + t[-40:]

def check_delegation(rpc_url, addr):
    code = rpc(rpc_url, "eth_getCode", [addr, "latest"])
    if code in ("0x", "", None):
        print("[OK]   no EIP-7702 delegation (EOA has no code)")
    else:
        prefix = code[:10]
        marker = "DELEGATED" if prefix.startswith("0xef01") else "HAS-CODE"
        print(f"[!!]   {marker}: code prefix {prefix}, size {len(code)//2 - 1} bytes")
        print("       -> inspect the delegation target NOW if you did not set this up")

def permit2_allowances(rpc_url, addr, from_block="0x0", max_logs=200):
    pad = "0" * 24
    params = {
        "fromBlock": from_block, "toBlock": "latest",
        "address": PERMIT2,
        "topics": [APPROVAL_TOPIC, None,
                   "0x" + pad + addr.lower().removeprefix("0x")],
    }
    logs = rpc(rpc_url, "eth_getLogs", [params])[-max_logs:]
    print(f"[i]    {len(logs)} Permit2 Approval events found")
    seen = {}
    for log in logs:
        token = log["address"]
        spender = topic_addr(log["topics"][2])
        seen[(token.lower(), spender.lower())] = log["blockNumber"]
    for (token, spender), block in sorted(seen.items(), key=lambda kv: -int(kv[1], 16)):
        print(f"       token {token} -> spender {spender} (last write at block {int(block, 16)})")
    print("[i]    re-read current amounts via eth_call to Permit2.allowance()")
    print("       near-unlimited + unused = revoke candidate")

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("address")
    ap.add_argument("--rpc", default="http://127.0.0.1:8545")
    ap.add_argument("--from-block", default="0x0")
    a = ap.parse_args()
    addr = a.address if a.address.startswith("0x") else "0x" + a.address
    check_delegation(a.rpc, addr)
    permit2_allowances(a.rpc, addr, a.from_block)

if __name__ == "__main__":
    main()

Reading the output

A delegation you did not set is the highest-severity finding. The sweeper patterns we profiled move funds on schedules; time matters more than tidy reporting.
Permit2 events with near-unlimited amounts to spenders you do not recognize are revocation candidates. Event logs only show the last write per (token, spender), so always re-read the current allowance before deciding.
Print your own address in the spender column: that is normal (internal permit flows).

The Polygon side of this matters for prediction-market users specifically — approvals you signed there are live there, regardless of what your mainnet wallet shows. General scam-pattern catalog for 2026: https://brainresearchhub.net/research/security/scam-catalog-2026

For neutral background: Ethereum's own intro at https://ethereum.org/en/what-is-ethereum/ and the Wikipedia overview https://en.wikipedia.org/wiki/Ethereum

Educational content only, not security advice. Read-only script, but verify everything against official documentation before acting.

Five red flags of crypto "recovery" scams

Srey Leak — Mon, 12 Oct 2026 01:13:25 +0000

After the June 2026 Polymarket frontend hack, the victims got their money back — and then the real scam started. DMs flooded in from "recovery specialists" who had watched the same on-chain transfers everyone else did.

I teach scam-prevention workshops in Long Beach, and this pattern shows up in every language community I work with. Here are the five red flags I drill.

1. They contact YOU. Real support never initiates a DM. Polymarket, Coinbase, MetaMask — none of them cold-message users about stolen funds.

2. They ask for a seed phrase or private key. There is no legitimate reason for anyone to need it. Not for "verification", not for "safe-keeping", not to "recover" anything.

3. They promise guaranteed recovery. On-chain theft is not reversible by a third party. If someone claims otherwise, they are selling you a story.

4. They manufacture urgency. "Your funds expire in 24 hours." Urgency exists to stop you from checking.

5. Their links look official but aren't. Check the domain character by character. Polymarket support does not live at polymarketsupport[.]xyz.

One sentence to remember: Polymarket refunded every June-hack victim directly. No third party was ever needed — and none will ever be.

I'm a security researcher, not a recovery service. I write guides: session keys, multilingual scam patterns, pre-trading checklists. Links on my profile.

Learn more about crypto security

security #crypto #scams #polymarket

Session Keys: the one Polymarket feature most traders ignore

Srey Leak — Sun, 11 Oct 2026 21:31:32 +0000

Most people sign every trade with their main wallet key. That's like carrying your house deed to the grocery store.

Polymarket's Session Keys exist to solve exactly this: a scoped signer with limited permissions, so your master key stays cold. At Coinbase, account-takeover incidents almost always started the same way — a hot key with too much power, phished once.

Three rules I follow:

Trading key != storage key. Never mix them.
The key that signs daily trades should hold only what you can afford to lose this week.
Hardware wallet for anything long-term. Browser extensions are for convenience, not custody.

None of this is exotic. It's boring hygiene — the kind that saves accounts.

(Full breakdown coming in my next post: how to set up scoped signers step by step.)

Not financial advice. Security is your responsibility.