How Arbitrum's freezes send transactions from an address without its key

What it is

An Ethereum Magicians post that walks through the Arbitrum Security Council's freeze of 30 October 2026 and lists what it means for indexers, pre-signed transactions and EIP drafts. The L1 transaction is 0xb69c81…35d6 in block 26301886. The council had done the same on 21 April 2026, moving 30,765 ETH from the KelpDAO exploiter.

How it works

The 9 of 12 Safe calls the L1 UpgradeExecutor. That points the Inbox proxy at an override implementation, delivers a message, and points it back. It runs once for the ARB and once for the ETH. The override (the notice calls the function sendUnsignedTransactionOverride) records the target address as sender with no alias. Both MessageDelivered events show kind 3, sender 0x3e2b…32d5.

About ten minutes later the messages landed on Arbitrum One as type 0x65 (ArbitrumUnsignedTx) transactions with r, s and v all zero. The nonce 2 transaction calls transfer on the ARB token to 0x…0DA0. The nonce 3 transaction sends 8,425.998 ETH to the same address.

The address has a 7702 delegation on Arbitrum One. It made no difference, because the transactions come from the address and the delegate's code never runs.

Preconditions / Affected

On Arbitrum One the UpgradeExecutor owns the Inbox's ProxyAdmin. Two parties hold its EXECUTOR_ROLE: the council's emergency Safe (9 of 12) and the DAO's L1 Timelock (3 day delay, after a vote). On other Arbitrum chains the chain owner upgrades through that chain's own UpgradeExecutor. ERC-8470 and ERC-8472 come from teams building on Robinhood Chain, so for them the answer depends on that chain's owner, not the Arbitrum DAO.

What to do

• Alert on Upgraded events on the Inbox pointing at the override implementation 0x980d…a859. April and October used the same implementation and the same action contract (0x3d45…a322).
• Do not rely on reading the EIP-1967 implementation slot. It read 0x7c05…0a10 at both block 26301885 and 26301886. The evidence is four Upgraded events on the Inbox and two UpgradeExecuted events on the executor.
• Indexers and reputation or income scoring that count an address's transactions or Transfer logs as its own acts will count these. The ARB token emitted a normal Transfer event. The difference is in the transaction (type 0x65, empty signature), so check for that on Arbitrum chains.
• Transactions pre-signed for nonce 2 or 3 can no longer land, because the forced transactions used those nonces.
• In specs that say "only the agent's key can move its wallet" or "the stake only leaves through withdraw", add one line to Security Considerations naming whoever controls the upgrade path.

Caveats

The author sees no bug. The council used powers the DAO gave it and published both actions within an hour and a half. The post gives no list of other Arbitrum chains' owners.