At 00:08:35 UTC on October 30, 2026, an Ethereum transaction in block 26,301,886 executed Arbitrum’s emergency response to funds linked to the Binance exploit. The Security Council’s notice says it froze 8,425 ETH and 74,559,805.2 ARB by transferring them to a holding address. The mechanism let it act as the exploiter’s address without obtaining that address’s signature.
The council temporarily replaced the implementation of Arbitrum’s Ethereum Inbox contract, sent cross-chain messages impersonating the target, and restored the original implementation. The notice says the funds can leave the holding address only through an ArbitrumDAO governance vote. It also states: “No other user’s funds or applications were affected.”
What the transactions show
The Ethereum execution receipt, read through public RPC, records successful execution. Its destination is 0xf06e95ef589d9c38af242a8aaee8375f14023f85. The Inbox at 0x4dbd4fc535ac27206064b68ffcf827b0a60bab3f emitted four implementation-change events during that transaction.
Those events alternate between 0x980d1f93fc5809c828539c46084801673fa6a859 and 0x7c058ad1d0ee415f7e7f30e62db1bcf568470a10. They record a temporary replacement and restoration for each message, all within the same Ethereum transaction. The receipt also contains the corresponding message events, both naming 0x3e2bf1ac6bf0934bbba6456c341c2ecbced632d5 as the sender. The same address is the sender of the verified $ARB transfer.
The $ARB leg appears on Arbitrum One in transaction 0x75e81a…eeedb6, included in block 519,514,683 at 00:18:20 UTC. Its destination is the $ARB token contract, 0x912ce59144191c1204e64559fe8253a0e49e6548. The input calls the token’s transfer function with the holding address as recipient.
The transaction receipt reports success and emits a Transfer event from the exploiter-linked address to 0x0000000000000000000000000000000000000DA0. The encoded amount corresponds to 74,559,805.2 ARB, matching the council’s disclosure. The transaction itself has type 0x65, nonce 2, and zero values for all three signature fields, r, s and v.
The receipt verifies the token transfer at its execution block, not the holding address’s current balances. The 8,425 ETH amount is the council’s reported figure; the transaction reading described here independently checks only the $ARB leg. Historical contract-state requests to the public endpoints used for this review were unavailable or required an archive token. This article therefore presents no fresh measurement of the holding address’s balances.
How the sender was substituted
The council calls its added function sendUnsignedTransactionOverride. Its notice says the function imitated a standard cross-chain transaction while allowing the transaction sender to be impersonated. Arbitrum contributors prepared the payload, and council members verified it before signing and execution. The notice describes both fund-transfer messages as part of the atomic upgrade action.
The ordinary Inbox source code shows where sender handling occurs. Its _deliverToBridge function passes the sender through AddressAliasHelper.applyL1ToL2Alias before calling the bridge’s message-enqueue function. The sender recorded in the cross-chain message is an input to subsequent execution on Arbitrum.
In the corresponding Nitro parser source, the unsigned-user-transaction path constructs an ArbitrumUnsignedTx with From set to poster. It separately reads the nonce, destination, value and calldata from the message. In this path, the sender comes from the incoming message metadata. It is not recovered from the signature of an ordinary signed transaction.
An indexer can check the authorization path by reading the enclosing transaction alongside the token log. The token’s Transfer event contains the holder, recipient and amount. The enclosing transaction contains the unsigned type and empty signature fields. An application reading only the token log would see the same sender and recipient as an ordinary transfer, without examining the authorization that produced it.
Upgrade monitors can read the Ethereum events to track the temporary implementations and restorations within the transaction. A monitor following implementation-change events can retain the sequence, including code installed and removed before execution finished. Restoring the original implementation, as the council described, leaves those events in the receipt.
The chain-level operation was separate from Aave’s market freeze after the Binance breach. In its response account, LlamaRisk says Aave blocked new supply and borrowing while preserving repayments, withdrawals and liquidations. Frozen reserves could no longer accept added collateral, leaving repayment as the way to improve a borrower’s health factor during the restriction. Those controls applied inside Aave’s markets. The council transferred assets from a specified address through the chain’s message system.
Aave’s responders chose a freeze because guardians could reverse it; lowering caps would have required a governance vote to restore them. They left the Horizon market open because its permissioned collateral could not be used by the exploiter. The response account says no market was paused. Aave made these containment decisions through the lending protocol’s own controls, separately from the council’s Ethereum contract upgrade and the DAO-controlled release process for the seized assets.
The authority behind the emergency action
Arbitrum’s constitution assigns chain-owner privileges on Arbitrum One and Arbitrum Nova to both the DAO and the Security Council. Those privileges include changes to core protocol code and parameters, as well as upgrades to associated Ethereum contracts. The Inbox intervention used that administrative authority, above the token contract that ultimately processed the transfer.
The council consists of 12 multisig signers. Emergency action requires approval from nine members and can execute without a delay. The constitution restricts that route to a true security emergency, giving a critical vulnerability threatening a governed chain’s integrity, confidentiality or availability as an example. It also requires a full transparency report after the emergency has passed, explaining the action and its justification.
Some constitutional restrictions are governance obligations without smart-contract enforcement. The constitution explicitly says some rules are enforced by smart contracts and others are not, while making both categories binding. The October notice describes the affected funds, the override mechanism, the execution transaction and the requirement for a later release vote. It attributes the target address to the Binance exploit.
Routine council upgrades follow a different schedule. Non-emergency actions also require nine approvals, but then pass through the waiting and execution stages of the proposal process. They bypass the initial proposal and voting phases while retaining the subsequent delays. The constitution permits the DAO to change the council’s powers or eliminate the council through a constitutional proposal.
Depositors’ exit assumptions depend on which upgrade route the council uses. The constitution authorizes immediate emergency upgrades, while ordinary governance includes waiting periods intended to let users withdraw or take other action. Holding the wallet key leaves that chain-level authority intact. In this incident, the emergency path produced a successful transfer from the holder’s address without the holder’s signature.
The constitution also provides removal mechanisms for individual council members. A DAO removal vote needs participation from at least 10% of votable tokens voting in favor or abstaining, with at least five-sixths of votes cast supporting removal. Alternatively, nine council members can vote to remove a member. A removed member cannot be reappointed by the council and must return through the election system. These provisions govern removal of signers, separately from a vote changing the council’s powers.
Signing keys can be rotated, but the constitution requires that process to pass through the waiting and implementation phases used for an L2-to-L1 governance message. It also provides for equivalent council multisigs on Ethereum and each DAO-governed chain. A member changing a key must follow that delayed process, even though the emergency-action threshold authorizes immediate intervention.
Release requires another decision
Movement from the holding address requires an ArbitrumDAO governance vote coordinated with relevant parties, according to the council’s notice. The completed containment transaction verifies that the $ARB moved into custody; the notice leaves subsequent distribution to that separate process.
The ordinary proposal framework requires a proposer with at least 1,000,000 delegated votable tokens. After submission, the constitution provides a three-day period before the voting snapshot and voting begin. Voting normally lasts 14 days, with an extension if the participation threshold is reached late. These are the published governance rules, not an announced timetable for releasing the Binance-linked assets.
Execution delays then depend on the proposal’s route. The constitution provides a three-day waiting period for treasury actions and eight days for an L2-to-L1 message. A cross-chain route also waits for that message to finalize on Ethereum, followed by an additional three-day Ethereum waiting period. The document says these intervals protect the ordering of withdrawals relative to governance changes. Any release proposal must identify its actual execution steps before a completion date can be established.
The constitution also requires proposals to comply with applicable law, specifically mentioning sanctions regulations. The emergency notice leaves coordination with relevant parties to the release process. It identifies no legal claimant and does not settle entitlement to the assets. An eventual proposal would need to supply the recipient and executable disposition that the freeze notice lacks.
The notice leaves the destination of a later distribution, the release proposal and the execution date unspecified.
