The Arbitrum Security Council used emergency governance powers to transfer roughly 74.5 million ARB tokens and 8,426 ETH out of a wallet it says was tied to a Binance exploit — without ever holding that wallet's private key. The operation, executed through a temporary override of the Arbitrum One inbox contract, is the second time in seven months that the same 9-of-12 multisig has exercised this power. That repetition, not the individual transfer, is the story.
The cast matters, because the labels carry legal weight. Arbitrum One is the L2 where the assets sat. The Inbox, UpgradeExecutor, and Timelock contracts on Ethereum supply the authority and the execution entry point. ArbitrumDAO and the twelve-member Security Council hold the mandate. A 9-of-12 Safe does the actual work. The assets were ARB and ETH. Binance is the alleged victim, Offchain Labs the developer, Zealynx the technical explainer, and the April KelpDAO exploiter address the closest precedent. None of this is a hack, and none of it is a protocol vulnerability; it belongs under L2 governance and trust assumptions, where the exploit is background rather than subject.
What actually happened
The operation did not exploit a bug. It used the upgrade path that Arbitrum's architecture has always contained. According to on-chain verification first reported by Unchained and a technical explainer circulated by security firm Zealynx on the Ethereum Magicians forum, the council's 9-of-12 Safe called into the UpgradeExecutor on Ethereum, temporarily replaced the Inbox contract's code, and injected messages that appeared on Arbitrum One to originate from the target address itself. The original code was then restored, and the process repeated for the next asset class.

The result: assets moved. No key was used. No signature was forged in any cryptographic sense, because none was required.
The normal cross-chain path aliases the L1 sender's address — appending a fixed suffix — specifically to prevent one chain from impersonating an address on the other. The override path skips that aliasing. On L2, the transaction looks like the address acting on its own behalf.
The forensic fingerprints
Four observable artifacts distinguish this from ordinary activity.

First, the transaction type is 0x65, which in Arbitrum's encoding corresponds to an L1-to-L2 system message rather than a user deposit. Second, the signature fields are empty — r, s, and v carry no values, because L1 messages require no L2 private key. Third, the transactions consumed nonce 2 and nonce 3, meaning the address had already sent two transactions on Arbitrum One. Fourth, the ARB token contract and every indexer saw a standard Transfer event, because at the EVM level the sender genuinely was that address.
One point widely misread: consuming a nonce does not lock anyone out. An attacker holding the key could query the chain, re-sign, and keep using the address. What stopped further use was that the assets were gone, not that the nonce was spent. And what happened was a seizure, not a freeze. Blockchains have no primitive for freezing an account — only for moving assets elsewhere. The distinction matters for whether funds can be returned.
Not everything here ages the same way. The on-chain record — block height, nonce values, transaction type, signature fields, the roughly nine-minute-forty-five-second delay in execution — is permanent and independently checkable. The incident's characterization, the loss figure, and the question of who owned the address were still moving afterward and have likely been revised. A reader returning to this material should treat the chain data as the anchor and the narrative as provisional. That asymmetry is normal, and it is why the mechanical detail is worth more than the narrative wrapped around it.
The trust model
The council's own framing is that this is how the system was designed. Steven Goldfeder, co-founder of Offchain Labs, characterized the authority as residing with a broadly elected external body rather than with the developers.
Formalized, the security boundary for an Arbitrum One account is not the private key alone. It is the private key plus whoever controls the upgrade path — a 9-of-12 multisig operating alongside a DAO timelock on Ethereum. For a self-custodied Ethereum L1 account, the boundary is cryptography. For an exchange account, it is corporate governance and law. The L2 case sits between them, and "non-custodial" turns out to be a layered claim rather than a binary one. The key protects the ordinary path. Governance controls the extraordinary one.
This is not unique to Arbitrum; every L2 with an upgradeable bridge contract carries the same property. What is unique is that Arbitrum has now used it twice — once in April against an address tied to the KelpDAO exploiter, which held 30,765 ETH, and again now. The real question is not whether Arbitrum is centralized. It is whether a power exercised repeatedly and proven effective stops being an exception clause and becomes a routine governance instrument. The available material supports the question but does not answer it.
The number that does not add up
The most urgent item for any reader is a discrepancy the coverage has not resolved.
The exchange was reported to have described losses of approximately $6.3 billion. Against that, the transferred assets compute to a far smaller figure. At a plausible $0.20 to $0.50 per ARB, 74,559,805 tokens are worth roughly $15 million to $37 million. At $3,000 to $4,000 per ETH, 8,426 ETH are worth roughly $25 million to $34 million. The combined range is about $40 million to $70 million — a gap of roughly two orders of magnitude. Even reading the figure as $630 million leaves a tenfold gap, which "only part of the funds were bridged to Arbitrum" could partially explain but not close.
No exchange has suffered a single theft approaching $6.3 billion. The number is almost certainly a transcription error introduced during summarization, or a different metric entirely — total assets affected rather than funds stolen. It should not be cited until checked against the original text.
Whose address was it?
The council described the address as "related to" the day's Binance exploit. "Related" admits three possibilities with entirely different legal and ethical weight.
If the address was controlled by the attacker, the operation is recovery of stolen property and carries strong justification. If it was Binance's own hot wallet, the operation is custodial intervention and requires a defined return procedure. If it was an uninvolved third party — an exchange or mixer used as a pass-through — the operation carries real risk of collateral harm to an innocent holder. The public record does not distinguish among them, and that gap is the single most consequential unresolved question in the entire episode.
Authorization after the fact
There is a second, quieter tension. The council's notice stated that funds "can only be moved through an ArbitrumDAO governance vote." By the time that sentence was read, the funds had already moved, without a prior vote.
Two readings are possible. The notice may mean that final disposition or return requires a vote, in which case the language is accurate but easy to misread as authorization for the transfer itself. Or the notice may genuinely claim that transfers require a vote, in which case it contradicts what occurred. Either way, the procedural structure was execution first and ratification afterward — the same sequence as the April case. If that pattern holds, its institutional significance exceeds any single seizure.
What "jointly" means
The council and the DAO timelock were described as jointly controlling the upgrade path. "Jointly" could mean joint control, requiring both parties to agree, or independent trigger authority, where either can act alone. The two architectures have opposite security implications: the first is a check and balance, the second is a unilateral emergency power held by twelve people. The public materials do not resolve which exists, and the answer determines whether the power is constrained at all. Arbitrum's constitution and governance documentation should settle it.
What the coverage missed
The technical claims in the reporting hold up. They rest on reproducible on-chain data — block 26301886, the nonce sequence, the transaction type, the empty signature fields — and anyone can verify them independently.
The framing is weaker. Every interpretive voice in the record belongs to a stakeholder: the council, Offchain Labs, and a technical firm offering a developer's caution. No critic is quoted anywhere. For an exercise of power that bypasses private keys, a single-sided source structure is a substantive imbalance even when the author's stated position is neutral. The normative question — should this power exist — is converted into a technical one — how was it implemented — and the governance legitimacy discussion never happens.
The headline carries its own problem. "Can move a wallet's funds without its key" implies a general threat to any holder. The actual case was law-enforcement-style action against allegedly stolen funds. Readers' instinctive alarm and the event's real character are not the same thing, and nothing in the text reconciles them.
What to watch
Four checks would settle most of what remains. Verify the loss figure and the address attribution against the original reporting. Read Arbitrum's governance documents to establish whether the emergency path can bypass the timelock. Trace where the April KelpDAO funds went — whether they were returned is the best available evidence on whether the precedent is benign. And pull block 26301886 and the following transactions to confirm the 0x65 type and empty signature fields directly.
Several questions remain open. Who controls the receiving address, the one ending in 0DA0? What is the return process and on what timetable? Were the April KelpDAO funds ever returned, and if not, why not? How are Security Council members elected, how long do they serve, and by what mechanism can they be removed? None of these are technical puzzles. All of them determine whether the power just used is accountable.
The transfer itself is verifiable and, in mechanical terms, unremarkable. The pattern is what deserves attention: a power used twice in seven months, each time announced after it had already been exercised. Exceptions that work tend to get used again.