Key Takeaways

• Attackers stole approximately $6.3 billion by obtaining valid signatures through Binance’s infrastructure. Binance reported no evidence of leaked wallet private keys, illustrating how access to a signing service can enable theft even when the keys remain protected.

• A malicious Ethereum delegation exposed both existing funds and future deposits. The attacker used EIP-7702, a feature that lets a wallet execute smart contract code, to drain a Binance wallet and another account it controlled.

• Hot wallet balances should reflect operational needs and an explicit limit on potential losses. Reserves should sit behind separate signing and approval controls so that one compromised service cannot access the entire treasury.

• Signing systems must check transactions independently of the applications requesting them. Controls should restrict destinations, limit individual and cumulative transfers, and require additional approval for unusual transactions or changes to wallet authority.

• Changes to signing policies and permissions should require multiple administrators. An attacker who compromises one account or service should also face independent approval requirements before changing the controls that govern asset movements.

The Binance Hot Wallet Compromise

On 29 October 2026, attackers drained Binance hot wallets across multiple blockchains, including Bitcoin, Ethereum and Tron. Binance estimated the stolen assets at approximately $6.3 billion. Valuing each transfer at the asset’s price when it occurred puts the total at approximately $6.36 billion, according to TRM Labs, while Elliptic’s analysis puts the value at $6.431 billion. In any case, the hack exceeds every previously reported cryptocurrency theft by a wide margin.

Binance’s initial investigation suggested that a compromised DevOps engineer’s laptop gave the attacker access to a service container used to submit withdrawals. A subsequent update identified additional points of breach and reiterated that investigators had found no evidence of leaked wallet private keys.

Access to a withdrawal service can allow an attacker to request malicious transactions and have the institution’s own infrastructure sign them. The blockchain then accepts those transactions because they carry valid signatures. Protecting the private key therefore needs to be accompanied by controls over which requests that key can authorise.

A signing system must enforce transaction rules even when the application requesting a signature has been compromised.

This article assesses the reported attack sequence, the weaknesses that allowed the theft to spread and the controls that could have interrupted it. It also examines how institutions can apply wallet segregation, transaction policies and quorum-protected administration through Utila to reduce the risks associated with automated withdrawals, payments and treasury operations.

How the Attack Unfolded

The attacker combined access to Binance’s signing infrastructure with two methods of moving funds. On Ethereum, a signed delegation allowed malicious code to act through a hot wallet. Other affected wallets issued ordinary transfers to attacker-controlled addresses. The sequence explains both how the Ethereum delegation increased the damage and why the compromise extended across several networks.

Preparation and Access to Signing

TRM’s investigation traced preparation to at least 36 hours before the theft. The attacker funded an operational wallet through Tornado Cash, deployed malicious code and rehearsed the transaction sequence on wallets under its control.

When the theft began, wallets using different blockchains and signing schemes produced valid signatures within a short period. TRM assessed that the attacker had most likely gained the ability to request signatures through Binance’s hot wallet infrastructure.

Delegation to Attacker-Controlled Code

EIP-7702 allows an Ethereum wallet to authorise a smart contract’s code to execute through that wallet. This supports functions such as batching transactions and sponsoring gas fees. It also gives the chosen code access to the wallet’s assets, making the choice of contract security-critical.

At approximately 20:20 UTC, the attacker submitted 50 signed delegation authorisations for the Ethereum wallet known as Binance 14. Each covered a different transaction counter, or nonce, to account for the wallet’s continuing withdrawal activity. One matched the current counter and activated the malicious delegation, according to Blockaid.

Draining Balances and Connected Accounts

Once the delegation took effect, the attacker could instruct the malicious code to transfer funds through Binance 14. At approximately 20:24 UTC, a single transaction moved 167,464 ETH and 63 tokens, including around 1.6 billion USDT.

Binance 14 also controlled a separate smart account. The attacker used that ownership permission to withdraw approximately 823 million USDC from it. Hypernative’s reconstruction shows repeated sweeps of later deposits into Binance 14 before the delegation was revoked. The theft therefore reached the wallet’s existing balance, incoming funds and assets held in an account under its control.

Coordinated Withdrawals Across Other Networks

Alongside the Ethereum delegation, other wallets signed direct transfers to the attacker. Blockaid documented withdrawals involving another Ethereum wallet and wallets on Optimism, Arbitrum and Avalanche.

These transfers required no malicious delegation. Access to ordinary signing functions also allowed funds to leave, so preventing the EIP-7702 authorisation alone would have addressed only part of the reported attack.

From Human Approvals to Automated Blind Signing

The attacker’s ability to obtain ordinary withdrawal signatures connects Binance to earlier attacks on Bybit and Drift. Across all three incidents, attackers obtained valid signatures for actions the asset owner had not intended to approve. Protecting the private keys did not prevent the signing process from authorising harmful transactions.

In this context, blind signing means approving a transaction without independently checking its actual effect. Human signers can be misled by a compromised interface or an apparently routine request. An automated signer can authorise equally harmful actions if it treats access to an internal service as sufficient authority to move funds.

At Binance, the automated signing system became the blind signer. The reported mechanism allowed the attacker to obtain signatures through compromised infrastructure without deceiving a human approver for each transaction. Signing controls therefore need to check what a request will actually permit, including immediate transfers and permissions that enable future withdrawals, even when the request comes from an internal service.

Signing and Governance Control Failures

The attack succeeded in obtaining signatures for actions that fell outside legitimate withdrawal activity. On Ethereum, it also established continuing authority over a wallet and the account that wallet controlled. These outcomes expose four areas that institutions need to examine when assessing whether their signing controls can contain a compromised service:

• A compromised service could request harmful transactions. The reported access to withdrawal infrastructure allowed the attacker to obtain valid signatures. Independent checks on the purpose, destination and amount of each request need to remain effective after the requesting service has been compromised.

• A signed delegation granted broad wallet authority. EIP-7702 authorisation can permit code to act through an account long after the original request. Reviewing the immediate transfer amount alone would miss the authority granted over later transactions.

• One wallet provided access to additional funds. Binance 14 held substantial balances and controlled a separate account. An assessment limited to the assets held at one address would understate the funds accessible through its ownership permissions.

• Malicious permissions continued to operate. The delegation remained active until revoked, allowing further withdrawals without a new signature from Binance 14. Disabling the compromised application would therefore need to be accompanied by revocation of the authority already established onchain.

Related failures appeared in the Drift attack, where signers authorised transactions that transferred administrative control, and the Resolv exploit, where compromised minting authority enabled excessive issuance. Together, these incidents demonstrate the consequences of granting a valid signature more authority than the intended business operation requires.

Movement and Containment of Stolen Assets

After moving funds out of Binance, the attacker sought to reduce the amount that token issuers could freeze. This created a race between converting stolen stablecoins and identifying the addresses holding them.

Chainalysis reported that the attacker exchanged $325 million in stablecoins for approximately $285 million in ETH over nearly 20 minutes. Accepting that loss allowed the attacker to obtain assets beyond stablecoin issuers’ freezing powers.

Elliptic identified further activity through decentralised exchanges, cross-chain bridges and borrowing ETH against stolen stablecoin collateral. Repeated transfers suggested automated laundering and spread the proceeds across more addresses.

Issuers and other responders nevertheless contained a substantial portion of the stolen funds. Using onchain data from around 05:50 UTC on 1 November, Elliptic verified approximately $2.85 billion in frozen or seized assets, close to Binance’s estimate of around $3 billion. Returning those assets requires additional recovery processes.

The speed of conversion makes the interval between detection and intervention critical. Institutions need current address intelligence and established escalation contacts so that security teams can notify issuers and service providers while stolen assets remain within their reach.

Binance Response and Asset Recovery

Binance’s response combined containment of the compromised infrastructure with replenishment of stolen assets. The exchange suspended withdrawals, revoked affected authorisations and engaged law enforcement and blockchain intelligence partners. It also committed to absorbing the losses through its SAFU fund and corporate resources.

Its 1 November announcement outlined a phased restoration of withdrawal services. By the 2 November update, Binance reported replenishing approximately 95% of the impacted amount, with purchases of less liquid tokens continuing. Replenishment used Binance’s resources; it should be assessed separately from the recovery of stolen funds.

Binance also announced completion of the zero-knowledge proof for its 31 October reserve snapshot, covering ten major assets. It planned broader coverage in a 4 November snapshot and further restoration of withdrawals.

These measures address the immediate need to restore balances and access to funds. Assessing the security of the rebuilt withdrawal service also requires an explanation of how the attacker obtained signing access and which controls now constrain it. Binance has committed to publishing a detailed incident report following its investigation.

Lessons for Institutional Wallet Operations

The scale of the theft reflects both the funds accessible to the attacker and the transactions the signing infrastructure authorised. Institutions should address those risks in that order: limit the amount exposed to one compromise, then enforce independent restrictions on how it can move. Those restrictions need to cover routine transfers, changes to wallet authority and the actions required during an incident.

Limit Funds Accessible to One Service

Hot wallets support continuous withdrawals and payments, so their balances should reflect expected demand and the time needed to replenish them. Treasury teams should set an explicit maximum amount that one compromised wallet or service could lose, with reserves held under separate signing and approval controls.

No single hot wallet, signing path or automated service should have unrestricted access to an institution’s treasury.

Creating additional wallet addresses helps only when access to them also differs. If one service can request signatures across every wallet, an attacker who compromises it may reach all of those balances. Institutions maintaining very large operational holdings should therefore assess separate signing environments and, where appropriate, multiple technologies, with clear responsibility for each.

Enforce Independent Checks Before Signing

A compromised application can submit requests using credentials and interfaces that normally support legitimate payments. The signing system must evaluate what each request authorises, including its destination and financial effect, before producing a signature.

Destination restrictions, per-transfer ceilings and cumulative limits over defined periods constrain automated activity. Higher-value transactions and exceptions should require independent approval. The application submitting a request should have no unilateral ability to change those rules or approve its own exceptions.

Require Approval for Wallet Authority Changes

Delegations and ownership changes can expose future balances even when the authorisation itself transfers little or no value. Institutions should subject these actions to dedicated approval requirements that identify the contract receiving authority, the network involved and the permissions being granted.

The same review should cover token approvals and offchain messages that establish spending rights. A payment limit can govern an immediate transfer; a separate authorisation policy must govern permissions that allow subsequent transfers.

Test Containment and Recovery Procedures

Persistent permissions can continue operating after the initial breach has been contained. Incident exercises should therefore test both the ability to stop new signing requests and the ability to revoke authority already granted onchain.

Teams should rehearse disabling compromised services, suspending treasury replenishment and revoking dangerous permissions, with named decision-makers for each action. Exercises should also cover compromised engineering devices, deployment pipelines and service credentials so that responders can preserve independent access while restoring affected systems.

How Utila Strengthens Signing Governance

The controls required to address this class of attack underpin Utila’s architecture: protection of hot wallet keys, policies that constrain signing, and quorum requirements that protect changes to those policies. Together, they allow institutions to automate transactions within limits that remain independently governed.

Utila’s MPC architecture distributes key shares between the customer and Utila. Transaction policies then govern which requests can proceed and which require additional approval. This separation allows an institution to protect the signing material while also restricting how an automated application can use it.

The policy engine supports destination restrictions, per-transfer thresholds and cumulative amount limits. Its dedicated EVM Delegation category allows institutions to set approval requirements for delegations separately from routine transfers. Function and parameter controls add more granular restrictions for supported smart contract interactions.

These policies also govern automated signing. The Co-Signer must hold the appropriate role, be designated to sign and operate under a policy that permits the transaction. Where that policy requires human approval, the approval must precede signing.

Protecting the rules requires a separate administrative control. Institutions can configure admin quorum so that changes to transaction policies, address-book entries and user permissions require approval from multiple administrators. This limits the changes a single compromised administrator can make.

Transaction policies must constrain automated signing, and independent approvals must protect changes to those policies.

Applied to the reported Binance attack, an independently enforced rule rejecting an unapproved delegation could have stopped that authorisation before signing. Amount limits and approval requirements could also have restricted direct withdrawals. Effective protection depends on configuring these controls across every signing route and maintaining separate authority over policy changes.

Utila’s integrations with Chainalysis, Elliptic and TRM Labs support transaction screening and exposure assessment, helping teams connect preventive controls with the intelligence needed during an incident.

Persistent attackers also require continuous improvement in product security and internal operational security. The Binance incident reinforces the need to test existing safeguards against severe compromise scenarios and strengthen them as new evidence emerges. Wallet segregation, endpoint protection and rehearsed response procedures remain part of that work.

Review Institutional Wallet Controls With Utila

Institutions operating exchanges, payment services and digital asset treasuries can use the Binance incident to review how much authority each automated service holds. That review should cover the balances it can reach, the transactions it can request and the approvals required to change its permissions.

Contact the Utila team to map those requirements to wallet structures, transaction policies and administrative controls. A working session can identify where routine operations can remain automated and where independent approval or stronger segregation would reduce exposure to a compromised service.