On 30 October the Arbitrum Security Council froze 8,425 ETH and 74,559,805.2 ARB that an address tied to the Binance exploit held on Arbitrum One (notice). It was the second time this year. On 21 April they did the same with 30,765 ETH from the KelpDAO exploiter (notice).
When we review drafts here we usually take it as given that an address only moves when its key signs. A few drafts this month come from teams building on Arbitrum chains, so I went through the October transaction to see what actually happens on chain.
One transaction on Ethereum
Everything is in 0xb69c81…35d6, block 26301886. The council’s 9 of 12 Safe calls the L1 UpgradeExecutor, which points the Inbox proxy at another implementation, delivers a message and points it back. It does that once for the ARB and once for the ETH.
Normally the Inbox aliases whoever calls it before the message reaches the Bridge (_deliverToBridge), and ArbOS uses the sender the Bridge recorded as the from of the L2 transaction (parseUnsignedTx). The override implementation (the notice calls the new function sendUnsignedTransactionOverride) records the target address itself, with no alias. You can see it in the two MessageDelivered events: kind 3, sender 0x3e2b…32d5.
About ten minutes later both messages landed on Arbitrum One as type 0x65 transactions (ArbitrumUnsignedTx) with r, s and v all zero. The one at nonce 2 calls transfer on the ARB token to 0x…0DA0, the one at nonce 3 sends 8,425.998 ETH to the same address. The address has a 7702 delegation on Arbitrum One and that made no difference: the transactions come from the address, so the delegate’s code never runs.
What a contract or an indexer sees
To the ARB token it was a normal transfer from the holder, with a normal Transfer event. A reputation score or an income record that counts an address’s transactions or its Transfer logs as its own acts would count this one too. On Arbitrum chains the difference is in the transaction itself (type 0x65, empty signature), not in the token’s logs.
The forced transactions also used the address’s next nonces, so anything the holder had signed in advance for nonce 2 or 3 can’t land any more.
If you watch proxies by reading the EIP-1967 implementation slot, this upgrade never shows up. The Inbox slot reads 0x7c05…0a10 at block 26301885 and again at 26301886. What shows it ran other code inside that transaction are the four Upgraded events on the Inbox and the two UpgradeExecuted events on the executor. April and October used the same override implementation (0x980d…a859) and the same action contract (0x3d45…a322), so an alert on Upgraded to that implementation is cheap to add.
Who can do it
On Arbitrum One the UpgradeExecutor owns the Inbox’s ProxyAdmin, and both the council’s emergency Safe (9 of 12) and the DAO’s L1 Timelock (3 day delay, after the vote) hold its EXECUTOR_ROLE. On other Arbitrum chains the same contracts are upgraded through that chain’s own UpgradeExecutor, by its chain owner (Arbitrum docs). ERC-8470 and ERC-8472 come from teams building on Robinhood Chain, which is an Arbitrum chain, so for drafts like those the answer depends on that chain’s owner, not on the Arbitrum DAO.
I don’t see a bug in any of this. The council used powers the DAO gave it and published both actions within an hour and a half. What I’d change in drafts is small. When a spec says “only the agent’s key can move its wallet” or “the stake only leaves through withdraw”, on these chains that holds up to whoever controls the upgrade path, and one line in Security Considerations naming it would help readers who deploy on chains with different owners.
If you build on an Arbitrum chain, does your indexer or your pre-sign check treat a type 0x65 transaction from an address as that address’s own act?