At 04:39:35 UTC on October 16, 2026, Ethereum block 26,202,756 processed a Multicall3 bundle that finalized fifteen stale positions in one transaction. Most belonged to ordinary users who had forgotten to claim bridge withdrawals months earlier. Five of them did not.
Three transactions later, 86 ETH, 109,000 USDT and 0.9 WBTC had been delivered to 0x89012a55cd6b88e407c9d4ae9b3425f55924919b — the Ethereum address that public incident analyses have attributed to the Cetus attacker since May 2025. The submitter was not the hacker. It was an automated “unclaimed funds” bot run under the ENS name lostandfound.eth, whose stated business is finishing other people’s stuck withdrawals and asking for a 5–10% tip.
The incident was first reconstructed in detail by SigIntZero and PandaSecurity, and we independently re-verified every transaction, amount and the wallet’s current state on Etherscan before writing this. Here is what happened, why the freeze never covered this money, and what it says about how bridges handle the aftermath of an exploit.
What the Sui Bridge Claim Bot Actually Did
The bot’s externally owned account, 0x7f2ee458d58e61345ad61a70e8072511bf9f6671, submitted three Multicall3 bundles between 04:39:35 and 04:40:11 UTC. Decoding the bridge’s TokensClaimed events — both research teams did this, and the raw transfers confirm it — the attacker-linked deliveries were:
| Transaction | Time (UTC) | Assets delivered |
|---|---|---|
0x89ca33…dde89 | 04:39:35 | 84 ETH (3 × 28) + 93,000 USDT + 0.9 WBTC |
0xce494e…36ac | 04:39:59 | 16,000 USDT (2 × 8,000) |
0xe63cb0…1fc8 | 04:40:11 | 2 ETH |
Every TokensClaimed event carries the same 32-byte sender — the attacker’s Sui address 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06 — and the same recipient on Ethereum. The two signals that would have identified these claims as attacker funds were sitting in the event data the whole time. Nobody looked.
The same bundles also settled legitimate stale withdrawals for unrelated users, including a WithdrawQueue position that burned ezETH and an Optimism portal withdrawal. That is the point: this was a general-purpose “finish what others left unfinished” bot, and the attacker’s messages simply looked like more stale funds — same shape, same vault, no face.
The $392K figure deserves a caveat both write-ups also make: it comes from the operator’s own on-chain message, which priced each asset at claim time. The token amounts are on-chain fact; the dollar total is an estimate.
Sixty Seconds on the Cetus Hack
On May 22, 2025, Cetus — then the largest concentrated-liquidity DEX on Sui — was drained of roughly $220 million through an arithmetic overflow in its liquidity math (the same class of bug we cover in integer overflow attacks). SlowMist’s teardown put the haul at over $230M across pools; other tallies landed between $220M and $223M.
Within hours, Sui validators took the extraordinary step of freezing the attacker’s on-chain accounts — about $162M by DL News’ accounting — and the community later voted through a protocol upgrade that moved the frozen funds into a recovery multisig without the hacker’s signature. Victims were eventually made close to whole.
That response is remembered as a success. It is. But it had a blind spot, and this month the bill for that blind spot came due.
Ten Bridge Deposits, One Claim, and a Nine-Message Time Bomb
Here is the part that matters for bridge security, and the reason this story is about architecture rather than one careless operator.
On the day of the exploit, the attacker bridged funds off Sui toward Ethereum. SigIntZero’s query of the bridge’s deposit events shows ten transfers, all made on May 22, 2025, all naming the attacker’s own Ethereum address as recipient — nonces 7020 through 7034.
At 11:12 UTC, the attacker claimed exactly one of them: 3,000 USDT, nonce 7034 (we confirmed the inbound transfer and the outbound move eight minutes later on Etherscan). Then it stopped. The bridge committee paused the Ethereum contract at 12:52 UTC and unpaused it at 22:13 the same night.
Why the attacker took one small transfer and left nine larger ones on the table is not in the public record — rate limits, the pause, or simple distraction are all plausible, and SigIntZero rightly refuses to guess. What is on record is the result: once the bridge reopened, nine approved messages remained valid claims on the vault, payable to the attacker, executable by anyone, forever.
How the Claim Works: A Bearer Instrument With the Payee Written On It
The Ethereum side of Sui Bridge finalizes a Sui-to-Ethereum transfer through transferBridgedTokensWithSignatures(): anyone can submit a message plus enough committee signatures, and the contract pays the recipient encoded in the message — never the submitter. PandaSecurity’s write-up walks the code path in detail.
Think of an approved bridge message as a bearer instrument with the payee already written on it. Whoever walks up to the counter with a valid note gets it processed, and the vault pays the name on the note. That design is sound and common — it is what makes bridge claims censorship-resistant and keeps users’ funds from being stranded if a relayer dies. The nonce prevents replay; each message settles exactly once.
The catch is that “safe for the user” assumes the recipient should be paid. When the recipient is an exploiter, a permissionless claim is a one-way valve that anyone in the world can open — a rescue bot, an MEV bot hunting gas refunds, or a script run by anyone at all. The Sui validator freeze could not touch these messages: claiming them requires nothing from the frozen Sui address, because the committee’s signatures had already left Sui attached to the message.
The Bot Even Asked the Hacker for a Tip
The detail that turns this from an accident into an absurdist artifact: at 04:42 UTC, under three minutes after the last claim, the bot did what it does for every wallet it “helps.” It sent an on-chain message to the attacker listing the eight unclaimed amounts, describing them as bridge transfers “that were approved but never claimed,” and suggesting an optional tip of 5% to 10% — somewhere between $19,598 and $39,196 by the bot’s own arithmetic, requested from an address that had been publicly identified as the Cetus attacker for 17 months.
Then it added, of the funds: “The funds are already in your wallet; there is nothing to approve."
"You’re Right, Our Mistake”
The first person to notice was not the operator, Cetus, Sui, or Tether. It was a stranger. At 05:08 UTC, an address signing as tanuki42 messaged the bot on-chain that its claims had sent roughly $390K of stale Sui Bridge withdrawals to “an address publicly associated with the Cetus exploit.”
Thirty minutes later the operator replied on-chain: “you’re right, our mistake.” The reply acknowledged the operator had not known the recipient was the Cetus attacker, noted nothing had moved yet, asked for help routing the case to Tether and Cetus so the USDT could be frozen, and said the bot now screens every recipient against known exploit and sanctioned addresses.
To the operator’s credit, the response was fast, public, and on-chain. But the ordering is the story: the screening existed only after a random bystander supplied it.
We Checked the Chain Ourselves — Including an Update Neither Write-up Has
Per our own verification standard for on-chain forensics, we re-ran the numbers on Etherscan before publishing:
- All three claim transactions exist at the stated times, sent by the bot EOA via Multicall3, delivering exactly 86 ETH, 109,000 USDT and 0.9 WBTC to
0x89012a55…919b— matching both write-ups to the token. - The May 22, 2025 self-claim of 3,000 USDT (nonce 7034) is visible in the wallet’s token-transfer history.
- New as of October 20: both published analyses (October 16–19) reported the address not yet on Tether’s on-chain blacklist. Our direct contract call to USDT’s
getBlackListStatus()today returns true — Tether has since blacklisted the address. The 109,000 USDT (still in the wallet, per its balance) is now frozen in place, which is the freeze the bot operator asked for on October 16. The 0.9 WBTC also remains in the wallet; native ETH, of course, cannot be blacklisted by anyone.
In other words: the one asset here with an issuer-level kill switch is now contained. The rest is not, and never can be.
The Delivery Nobody Noticed
SigIntZero’s reconstruction surfaced something neither the operator nor the bystanders caught: this was actually the second time someone delivered the attacker’s stale claims.
Of the ten May 2025 bridge messages, the bot settled eight in October 2026. The tenth — nonce 7029, 1 LBTC — was claimed back on August 31, 2025, paid to the attacker’s Ethereum address, by a submitter (0xCa8d0B47…839B) whose transaction history mixes committee-signed pause operations with many claim submissions. SigIntZero reads it as a relay account; whether that August delivery was deliberate or one more unscreened item in a queue is not public. Either way, someone other than the attacker moved Cetus proceeds out of the bridge 14 months before anyone flagged it.
With all ten messages now settled, nothing from that Sui address is left to claim. The time bomb has fully detonated.
Why Dormant Is Not Safe
It is tempting to file this under “operator error” and move on. Three broader lessons say otherwise, and they apply far beyond this bridge.
1. Dormant is not the same as safe. After an exploit, incident response chases funds that are moving. Signed-but-unexecuted messages get none of that attention, yet they are live liabilities — anyone, at any time, can turn them into spendable assets. The same holds for queued withdrawals, pending governance actions, and approvals that never expire. PandaSecurity drew the parallel to the NEAR Intents hack, where balances that looked inert turned out to be withdrawable through the same “nobody checked whose money this was” pattern.
2. Permissionless relaying moves the screening burden off-chain. When a protocol lets anyone finalize anything, the protocol does no screening — so whatever screening exists lives in the relayers. A careful relayer can be undone by a careless one. “Nobody will bother” is not a control.
3. Recovery tooling is security-sensitive software. Read-only “what can I claim?” checkers are harmless. A bot that executes claims on others’ behalf is a payment system with no compliance checks, and it deserves the same threat model as any contract that moves value.
What Bridge Teams and Relayer Operators Should Do
For protocol and bridge teams, the concrete additions to an incident-response runbook:
- Enumerate attacker-linked pending messages as part of the freeze. When you pause and freeze after an exploit, list every signed-but-unexecuted outbound message from attacker addresses and decide its fate — committee hold, coordinated issuer freeze at the destination, or explicit burn — before an outside bot decides for you.
- Consider a delay-list on the claim path. A narrowly scoped, governance-controlled list that delays (rather than permanently blocks) claims involving known exploit addresses preserves permissionless relaying for everyone else. It trades against censorship resistance, so it must be governed transparently — but “no check at all” is what just paid a hacker $392K.
- Expose message provenance clearly. The source-chain sender and recipient were in the claim events all along. Make them impossible to miss in explorer views, so relayers and monitors can screen.
For anyone running a relayer or recovery bot: screen both ends of every transfer, cap what can be claimed without human review, and fail closed when your screening source is unavailable. The check is one API call. The October 16 incident is what skipping it looks like.
Timeline
| # | When (UTC) | Actor | What happened |
|---|---|---|---|
| 1 | 2025-05-22, morning | Cetus attacker | Drains Cetus pools (~$220M), starts moving proceeds off Sui |
| 2 | 2025-05-22, before 11:12 | Cetus attacker | Locks 10 transfers in Sui Bridge (nonces 7020–7034), self as recipient |
| 3 | 2025-05-22, 11:12 | Cetus attacker | Claims one message (3,000 USDT, nonce 7034), leaves nine |
| 4 | 2025-05-22, 12:52 | Bridge committee | Emergency pause on the Ethereum contract |
| 5 | 2025-05-22 | Sui validators | Freeze ~$162M on Sui; already-signed bridge messages untouched |
| 6 | 2025-05-22, 22:13 | Bridge committee | Unpause; the nine unclaimed messages are claimable by anyone |
| 7 | 2025-08-31 | Relay account | Claims nonce 7029 (1 LBTC) to the attacker’s address |
| 8 | 2026-10-16, 04:39–04:40 | lostandfound.eth bot | Submits the remaining eight in three multicalls, no recipient check |
| 9 | 2026-10-16, 04:42 | Bot | On-chain note to the attacker suggesting a 5–10% tip |
| 10 | 2026-10-16, 05:08 | tanuki42 | Flags the recipient as the Cetus exploiter |
| 11 | 2026-10-16, 05:38 | Bot operator | ”Our mistake” — adds recipient screening, asks for a USDT freeze |
| 12 | by 2026-10-20 | Tether | Blacklists the address; 109,000 USDT frozen in place (our on-chain check) |
The Bottom Line
Nobody hacked anything on October 16. A contract executed valid messages, exactly as written, and paid a sanctioned-in-spirit recipient because the only party positioned to notice — an automated middleman — had no idea whose money it was moving, and even the “rescue” tip request went to the hacker.
The uncomfortable takeaway for every chain that has ever frozen attacker funds: a freeze covers what attackers still control. It says nothing about claims attackers have already signed and abandoned. Those are open valves on the other side of the cross-chain bridge, waiting for the first bot — helpful or otherwise — to turn them. If your incident response ended at the freeze, it ended too early.
For users, the practical echo is the same one from our bridge security guide: abandoned claims are valuable, and tooling around them will find them before you do. If you have old, unclaimed bridge transfers anywhere, claim them or cancel them — because someone else eventually will.
Frequently Asked Questions
Did a Sui Bridge claim bot really pay the Cetus hacker?
Yes. On October 16, 2026, an automated bot run under the ENS name lostandfound.eth submitted eight stale Sui Bridge withdrawal messages in three Ethereum transactions. Every message paid out to the address publicly attributed to the Cetus attacker, delivering 86 ETH, 109,000 USDT and 0.9 WBTC — about $392K at claim time by the operator's own estimate. We independently confirmed all three transactions and the recipient wallet on Etherscan.
Was the Sui Bridge hacked in this incident?
No. The bridge contract behaved exactly as designed. Its claim function lets anyone submit a committee-signed bridge message, and the funds always go to the recipient encoded in that message — not to the submitter. The bot submitted valid messages without checking who the recipient was. The failure was in the bot's missing screening, not in the bridge's code.
Why didn't the Sui validator freeze stop the funds from moving?
The freeze operated on Sui and blocked the attacker's Sui address from signing new transactions. But these withdrawals were already-signed messages that had left Sui with the bridge committee's approval attached. Claiming them on Ethereum requires nothing from the frozen Sui address — anyone can relay the message, and the vault pays the named recipient. That is why funds frozen on one chain can still be one permissionless claim away from spendable.
Where are the funds now?
As of October 20, 2026, our on-chain checks show the 109,000 USDT and 0.9 WBTC still sitting in the attacker's Ethereum wallet, and Tether's on-chain blacklist now includes the address — so the USDT is frozen and cannot be moved. Native ETH has no issuer and cannot be blacklisted. At the time the original analyses were published on October 16–19, the address had not yet been blacklisted.
What is the lesson for bridge and protocol teams?
Treat signed-but-unexecuted messages from attacker addresses as part of incident response. After an exploit, enumerate every pending outbound message, queued withdrawal and live approval tied to attacker wallets and decide how to handle them before an outside bot does it for you — through committee action, emergency pause coordination, or advance coordination with token issuers like Tether who can freeze at the destination.