Arbitrum moved stolen Binance funds. Returning them takes a vote

Arbitrum’s Security Council used a temporary contract upgrade to move cryptocurrency linked to the Binance hack. Its emergency action stopped the attacker from moving those assets, but deciding their destination belongs to a separate governance process.

Arbitrum’s Security Council has moved 8,425 ETH and 74,559,805.2 ARB linked to the Binance hack into a holding address whose funds require a DAO governance vote to move again.

Arbitrum’s emergency-action notice says the intervention took place at 08:08 HKT on October 30. Contributors prepared a temporary change to the network’s Ethereum inbox contract, council members verified and signed it, and the original implementation was restored after the transfers.

The action has drawn attention because it did not require the attacker’s private key. Arbitrum used authority over its own infrastructure to create messages that moved the assets on Arbitrum One.

Its public notice describes the outcome as a freeze and reserves further movement to ArbitrumDAO governance. Moving funds away from an exploiter and returning them to an entitled recipient are therefore separate decisions.

Arbitrum’s intervention used a permission above the wallet

An ordinary cryptocurrency payment is authorised by the account sending it. Arbitrum’s incident notice describes an exceptional route: a change to infrastructure that determines how messages from Ethereum are handled on the rollup.

The added function, sendUnsignedTransactionOverride, could imitate a cross-chain transaction while impersonating its sender. Two messages transferred the ETH and ARB from the identified address into the holding address ending 0DA0.

The distinction is between compromising the attacker’s key and using administrative authority over the system in which that account exists. Arbitrum’s published explanation describes the latter.

Its constitution gives chain-owner privileges to the DAO and the Security Council. Those privileges include changing core protocol implementations and parameters, including associated contracts on Ethereum.

The chain-owner role sits above a particular app’s rules. It is part of Arbitrum’s governance architecture, so the powers available to it cannot be inferred solely from the permissions visible in a user’s wallet.

Ethereum provided the venue for the administrative transaction, while the assets were held on Arbitrum One. The event did not demonstrate a power to rewrite unrelated Ethereum accounts or take native bitcoin from another network.

Arbitrum’s developer documentation explains that parent-chain messages enter the rollup through inbox infrastructure. Users can send transactions through a delayed inbox when the sequencer is unavailable or does not include them.

That ordinary message path and the incident’s temporary override should be distinguished. A normal user’s access to a delayed inbox does not grant the special sender-impersonation authority created for the emergency action.

The Security Council’s intervention was possible because it could approve an upgrade to the relevant contract. The code change supplied the exceptional functionality; the attacker’s wallet did not voluntarily approve the transfer.

A wallet owner’s possession of a private key therefore describes only one part of the security arrangement. On an upgradeable system, users depend on how administrative permissions are distributed and constrained as well.

The temporary upgrade bundled the rescue and restoration

Arbitrum said the upgrade, transfers and restoration formed an atomic action. In transaction terms, the operations were bundled so that the emergency implementation was not intended to remain the active implementation after the operation completed.

Arbitrum’s notice identifies the administrative transaction as 0xb69c81774f507d46ce776aeaed8b4d31df96dd66ce6fd05073481011835355d6. The statement identifies the operations and the destination separately from any interpretation of their legal effect.

Restoring the earlier implementation removed the special function from the active implementation used after that transaction. It did not remove the underlying upgrade authority which allowed the council to introduce it.

An analogy is useful if kept within those limits: withdrawing a temporary instruction does not abolish the office empowered to issue another instruction. Users assessing future intervention risk need the standing governance rules as well as the temporary code’s lifespan.

The foundation’s governance architecture describes upgrade executors and the entities authorised to call them. Emergency authority and the slower DAO route are different ways of reaching privileged contract operations.

The technical record can establish which implementation was installed and restored, and which messages were created. It does not independently decide whether an address was correctly identified as holding stolen property.

That identification depends on the incident evidence and the actors who assessed it. Arbitrum’s notice identifies the address as associated with the Binance exploit and states that other users’ funds and applications were unaffected.

The narrow scope of the published action is relevant. The council targeted identified assets on its governed chain; it did not announce a network-wide rollback of all activity during the theft.

For a reader checking the recovery, three pieces of information belong together: the executed administrative transaction, the transfers it caused and the state of the holding contract afterwards. A screenshot of a balance alone cannot explain the permission that moved it.

The same approach applies to any subsequent release. A governance result, executable instructions and completed transfer form a chain of evidence; approval at one stage is not proof that all later stages have happened.

Nine signers can act before a full DAO vote

The Security Council has 12 members, and emergency actions require 9 approvals. The governance FAQ distinguishes this immediate route from the longer sequence used for ordinary proposals.

Nine out of 12 is a 75% signing threshold. It allows an action to proceed with 3 members unavailable or opposed, while 4 members withholding approval would prevent that threshold from being reached if the other 8 supported it.

This arithmetic describes the approval rule, not the independence of the people involved. Independence depends on affiliations, conflicts, key control and whether supposedly separate signers can in practice be directed by the same party.

Arbitrum publishes its council membership, including members’ professional backgrounds and cohort assignments. The roster allows users to identify the decision-makers instead of treating “the council” as an anonymous technical service.

Its constitution calls for transparency reporting after emergency actions and limits the emergency mandate to genuine security emergencies. The DAO can amend or eliminate the council’s powers through the constitutional proposal process.

JUST IN: Arbitrum Security Council recovers $70.9M ETH from KelpDAO exploiter addresses and sends it to a dedicated recovery wallet pic.twitter.com/JJrt8LNVeD

— crypto.news (@cryptodotnews) April 21, 2026

The faster route has an explicit operational rationale. Waiting for a full token vote can leave funds available to an attacker while delegates discuss a proposal and the voting window runs.

Arbitrum’s progressive-decentralisation account describes the council as a mechanism for critical emergencies while governance develops. It presents rapid response and distributed governance as parts of the same architecture.

The opposing concern is recorded in L2BEAT’s Arbitrum assessment, which treats immediate upgrade authority as a material trust assumption. Its Stage 1 classification permits security-council intervention; it does not mean that every important operation is beyond human discretion.

Those accounts describe the same permission from different perspectives. Arbitrum emphasises the ability to respond to a critical event, while the risk assessment identifies the consequences if the privileged decision-makers act maliciously or their keys are compromised.

The Binance operation demonstrates an intervention directed at suspected stolen assets. Assessing the architecture requires considering who could approve another intervention and what enforceable limits apply to that authority.

Freezing funds and choosing a recipient have different deadlines

An emergency freeze answers an immediate question: can the identified assets be kept from leaving the system? A release answers a different one: which recipient should receive them, on what evidence and through what instructions?

The Binance notice specifies the governance requirement but does not set a customer reimbursement deadline. A DAO vote must be prepared around a proposed destination and an executable action before it can settle that next step.

The timing of the initial intervention can nevertheless be calculated from the two incident notices. Binance placed the theft’s start at 20:05 UTC on October 29; 08:08 HKT on October 30 is 00:08 UTC, an interval of approximately 4 hours and 3 minutes.

The calculation concerns the start of the reported theft and Arbitrum’s stated action time. It is not a measurement of how long the council took to act after receiving an alert, because the notice does not specify when that alert arrived.

Nor does it establish that all assets from the wider hack remained recoverable during those hours. The intervention addressed the identified holdings on Arbitrum One, while the theft and subsequent transfers involved other networks.

JUST IN: Gate freezes two accounts linked to the Binance hacker after $250K in deposits

The exchange says it identified the accounts following an alert from Lookonchain and has begun due diligence, pledging full cooperation with law enforcement and the ongoing investigation. pic.twitter.com/x9PfwaD2BP

— crypto.news (@cryptodotnews) November 2, 2026

Elapsed time to the freeze and elapsed time to restitution therefore need separate starting and ending events. The latter would require a completed return to the authorised recipient, not merely an announcement that the assets have been immobilised.

A dated proposal would supply the next part of that chronology, followed by its vote, applicable waiting periods and execution. Until those events occur, the freeze timestamp supplies no automatic payment date for customers.

Arbitrum’s proposal-voting guide distinguishes discussion, off-chain signalling and formal on-chain voting. A positive discussion thread or temperature check is not the same event as execution through governance contracts.

The constitution separately classifies proposals that change software or require chain-owner powers as constitutional. It gives those proposals voting, waiting and implementation stages, with the applicable route determined by what the proposal actually does.

A transfer proposal consequently needs more detail than a statement that funds should be returned. The recipient address, amount, authority and any conditions have to match the instructions which voters are asked to approve.

That precision is particularly relevant for a recovery involving an exchange. Binance has promised to cover customers using company resources, so the recipient of recovered assets may be the exchange or another authorised recovery arrangement, rather than each account holder receiving a direct on-chain distribution.

Its asset replacement programme proceeded while original assets remained frozen elsewhere. Recovery proceeds and customer liabilities therefore need to be reconciled so that the same amount is not represented as two separate reimbursements.

Consider a hypothetical exchange that replaces 100 stolen tokens using its treasury. If a DAO later returns 20 original tokens, customers have not received 120 tokens of restitution; the exchange has recovered part of the cost of restoring the original 100-token liability.

If the tokens have not yet been replaced, the same recovery might instead reduce the outstanding customer shortfall. The correct description depends on the actual liability and repayment arrangements when the transfer occurs.

The decision process should make those arrangements visible. A recovery address identifies where assets go on-chain, while the accompanying documentation explains who controls it and whose claim the transfer is intended to satisfy.

The KelpDAO rescue already showed what can delay a return

Arbitrum used a comparable intervention after the April KelpDAO exploit. Its April action notice identified 30,765.667501709008927568 ETH moved into the same holding address and said governance would need to authorise a release.

As crypto.news previously reported, the council immobilised the Kelp-linked ETH without announcing a general interruption to other users or applications. The value cited at the time was approximately $71 million.

The following stages involved a proposed coordinated recovery for rsETH holders. Aave Labs, KelpDAO, LayerZero, EtherFi and Compound co-authored an April 25 release proposal.

Its stated objective was to direct the immobilised ETH towards restoring rsETH backing. The proposal specified that the assets were already frozen and that their destination was the remaining governance question.

Legal claims then complicated the process. A May 1 restraining notice, described in coverage of the court restraint, concerned claims by terrorism judgment creditors who argued the assets could satisfy judgments against North Korea.

The important historical distinction is between that allegation and an established ownership ruling. Attribution of an exploit to a state-linked actor does not, by itself, answer every property question about assets taken from another party.

The May 8 governance vote coverage described strong support for a recovery proposal and indemnification provisions. Support for the plan and legal exposure for the people implementing it were being addressed through separate arrangements.

The amended discussion in the public forum subsequently referred to transfer into Aave LLC custody under judicial oversight. That May discussion is historical context, rather than evidence that the Binance assets now face the same claim or court procedure.

The comparison identifies a demonstrated source of delay: a council can remove assets from an attacker’s immediate control before the rightful recipient and lawful transfer route are settled. No fixed return timetable follows automatically from the speed of the initial freeze.

It would therefore be premature to attach the KelpDAO recovery’s legal status to the new Binance holding. The applicable proposal and any actual legal orders must identify which assets and parties they concern.

A holding address can contain more than one recovery

Arbitrum’s notices identify the same destination ending 0DA0 for the Binance and KelpDAO actions. That makes the transfer records and asset attribution especially relevant when readers try to follow a recovery through an explorer.

A displayed ETH balance is a total for the address at the time of the query. It does not, without transaction history and the relevant restrictions, identify which portion belongs to which incident or whether an earlier allocation has already changed.

The Binance notice’s 8,425 ETH is therefore the incident-specific quantity to follow. Substituting the holding address’s entire current ETH balance could combine unrelated inflows, residual holdings or later transactions.

The ARB balance requires its own token transfer record. Adding native ETH and a token count produces no useful single quantity unless both are valued using a disclosed price and timestamp.

For example, a valuation of the Binance allocation would be 8,425 multiplied by the selected ETH price, plus 74,559,805.2 multiplied by the selected ARB price. The amount changes when either price changes, even if no token leaves the holding address.

At an illustrative ETH price of $2,200 and ARB price of $0.16, the formula produces approximately $30.46 million. Those are hypothetical valuation inputs, not quoted market prices or Arbitrum’s accounting of the loss.

The calculation explains why a dollar headline can move while the quantity recovered remains fixed. Reporting the token amounts preserves a stable reference for the recovery record.

A similar distinction applies to fees and transaction counts. One administrative Ethereum transaction can create multiple messages and transfers on a rollup, so counting only the parent-chain transaction does not describe every resulting asset movement.

The network’s transaction-lifecycle documentation separates submission and inclusion across the parent and child chain. Examining an intervention requires following that relationship, not treating the two chains as independent evidence of duplicate recoveries.

The useful record for readers is therefore incident-specific: original address, transferred quantities, holding destination, release authorisation and final recipient. Each item answers a different part of where the assets went.

Self-custody and network governance cover different powers

Self-custody means that a user controls the credentials normally required to authorise transactions from an account. It does not promise that every blockchain on which the account exists has immutable rules or no administrative permissions.

Arbitrum’s published architecture includes a sequencer, validation and dispute mechanisms, upgrade permissions and governance. Each component addresses a different part of how transactions are accepted and the system changes.

Its sequencer documentation describes alternative inclusion arrangements when the sequencer fails or censors messages. Those protections address transaction ordering and availability within the protocol’s rules.

An emergency software upgrade concerns the rules and privileged contracts themselves. A route around an unavailable sequencer does not remove the separate ability of authorised governance actors to change an upgradeable implementation.

OpenZeppelin’s access-control documentation makes a related distinction at the contract level. Ownership and roles determine which accounts may call privileged functions, and a timelock can delay operations assigned to it.

The practical security question is where those permissions lead. An app can use a multisig while a higher-level network contract remains upgradeable through a separate set of signers, each with its own rules.

Aave provides a useful contrast in its governance documentation. It distinguishes protocol emergency guardians from governance emergency guardians, assigning different intervention mandates to different bodies.

That separation does not establish that every system using a guardian is equally safe. It shows why the name of the role is less informative than the exact functions it can call, the approvals required and the process for replacing it.

The Binance exploit itself involved another kind of authority. Investigators described valid wallet authorisations in the Ethereum attack sequence, while Arbitrum’s recovery used a network administration path after assets reached its chain.

The two events should not be compressed into a claim that private keys no longer matter. They demonstrate that signing authority, delegated account behaviour and network upgrade permissions are distinct parts of an asset’s security environment.

Council membership and signing keys require separate scrutiny

The public roster identifies people, while the multisig requires signatures from particular keys. Both records are relevant: a name on a membership page does not itself show that a key is securely held or available during an incident.

Arbitrum’s member duties call for operational security, including a fresh hardware wallet dedicated to the role. The published expectations include diversity across organisations, locations and time zones to support independence and rapid response.

The two objectives can pull in different operational directions. Signers need sufficient separation to resist common compromise, while enough of them must be reachable to achieve the threshold when an emergency occurs.

A 9-of-12 rule does not eliminate that coordination problem. If 3 members are unavailable, every remaining member must approve for the action to proceed; if 4 are unavailable, the immediate signing threshold cannot be reached.

That is an availability calculation, not evidence that either event occurred during the Binance response. The published transaction records an intervention which did proceed.

The council overview describes election and removal arrangements. It says a member can be removed through a DAO vote meeting the applicable participation and supermajority conditions, or through approval by at least 9 council members.

Removal of a decision-maker and removal of a contract permission are different acts. The administrative system must ensure the permissions correspond to the authorised membership after an election, resignation or replacement.

Arbitrum publishes a deployment-address register identifying governance contracts, including election and removal infrastructure. It lets readers distinguish a voting interface from the contracts which record and implement the result.

An election announcement is consequently not the entire installation record. The relevant on-chain change establishes which keys can exercise the role afterwards.

The same distinction applies when a signer rotates a key. The person can remain a council member while the authorised signing credential changes, so comparing names alone would miss an important security event.

Arbitrum’s governance documents describe separate multisig instances across Ethereum and governed chains. Their permissions apply to the relevant contracts, so the listed council addresses are not interchangeable across every operation.

For the Binance action, the published notice identifies a contract upgrade on Ethereum and transfers on Arbitrum One. That relationship determines which permissions and transaction records are relevant to the intervention.

There is a further difference between an affiliation and control of a signature. A public employer relationship can help readers assess concentration, but it does not prove that the employer controls the person’s key or instructed a particular vote.

Evidence of an actual instruction, shared custody arrangement or common signing infrastructure would answer a different question from a professional biography. The analysis should not convert one into the other without supporting information.

A transparency report can make those boundaries easier to examine by identifying the signers, action, timing and reason for urgency. The report’s account can then be compared with the administrative transaction and the stated constitutional mandate.

Changing the council’s longer-term authority would be a governance decision of its own. It would not automatically determine where the already immobilised Binance assets should go, because the release still needs a defined recipient and instructions.

A vote needs to identify exactly what will be executed

For token holders, the next concrete recovery event is a proposal specifying the Binance allocation and its destination. The current notice assigns that decision to governance but does not itself provide a completed transfer back to the exchange.

Arbitrum’s constitution recommends that proposals set out specifications, implementation steps, costs and timing. A proposal involving a third party should include the applicable legal documentation and procedures as well.

Voters need to compare the descriptive text with the executable instructions. A proposal can state an amount in prose while the transaction payload calls a contract with its own asset, recipient and permission parameters.

OpenZeppelin’s governance guide distinguishes vote counting, quorum, proposal execution and timelock components. A vote’s headline result is only one stage of a system built from those separate contracts and rules.

The recovery proposal should make clear whether its destination is an exchange-controlled wallet, a recovery multisig or an intermediary subject to further conditions. The party controlling the destination determines who can act after the DAO transfer has completed.

Any separate custody or indemnification arrangement should be attributed to its actual terms. The KelpDAO discussion shows that such arrangements can be part of a recovery process, but it does not supply default terms for a new incident.

Signers’ accountability continues after the emergency transfer. The constitutional transparency requirement concerns why the action was justified as well as what the code did.

That report can be compared with the transaction record, the stated identification of the exploiter-linked address and the limits described in the public notice. A final release adds another observable event to that sequence.

Arbitrum’s October 30 statement places the Binance-linked assets at 0x0000000000000000000000000000000000000DA0 and says a governance vote is required to move them.

What to watch

• Release proposal: The incident-specific quantities, proposed recipient and executable instructions submitted to governance.
• Council report: The documented basis for the emergency action and the approvals involved.
• Holding movements: Transfers attributable to the Binance allocation, separately from other assets at the same address.
• Legal conditions: Any actual order or custody arrangement governing the proposed release.
• Execution: The final transaction transferring funds after approval and completion of applicable waiting periods.

FAQ

Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of November 3, 2026. Legal questions should be discussed with qualified counsel.