The attack on Binance on October 29, 2026, resulted in the theft of approximately $6.3 billion in assets. On Ethereum, the attackers used the delegation features introduced by EIP-7702 to make one of the exchange’s wallets execute code under their control. Once recorded on the network, the delegation allowed funds to be moved through calls to the wallet without new signatures from that account, including funds received afterward. This control persisted until the delegation was removed or replaced, regardless of the exchange’s suspension of withdrawals. The incident brings renewed attention to custody security and the powers a signature can grant beyond an individual transaction.
Signing as the point of compromise
The attack combined ordinary transfers and delegation authorizations, both based on valid signatures attributable to Binance wallets. In its preliminary report published on November 3, the exchange described unauthorized access to an internal signing service used to initiate operations outside its normal withdrawal process. Transfers affected several networks, including Bitcoin, Tron, and Solana, while EIP-7702 was also used on Ethereum. Delegation was therefore one of the mechanisms used in the attack and does not, by itself, explain the thefts on the other blockchains. Verifiable signatures link the authorizations to the wallets involved, while reconstructing access to the systems requires evidence from the internal infrastructure.
Protecting the material required to sign and controlling the requests submitted to the signer are distinct layers of security. A compromised service can obtain signatures on unauthorized instructions without directly extracting a private key. Binance clarified that the affected wallet used a system based on multiparty computation (MPC), in which several components contribute to producing a signature. Distributed signing does not replace checks on requests, which can be correctly formatted while violating the custodian’s operating rules. The preliminary report dated November 3 describes a campaign involving multiple devices and services, with the investigation and independent review still ongoing.
How control over an account changes
EIP-7702, introduced with the Pectra upgrade on May 7, 2025, allows an Ethereum account directly controlled by a private key to execute smart contract code. The holder can add wallet functionality while keeping the same address and without moving funds elsewhere. This makes it possible to bundle several operations into one transaction, have another party pay the fees, or define specific rules for using funds. Spending limits and restricted permissions depend on the code chosen to manage the wallet, because the upgrade enables these features without enforcing them automatically. Delegation allows the code to act in the account’s context, with access to its balances and the rights it can exercise against other contracts.
The signed authorization specifies the contract whose code will be used, the chain identifier, and the account’s nonce, the counter checked by the protocol when applying the delegation. A reference to that code is recorded in the account, allowing the code to execute when the wallet receives a call. The delegation persists beyond the transaction that introduced it, until it is replaced or removed through a new valid authorization. The delegation signature is separate from the signature on the transaction that publishes it, which another party can submit and pay for. Anyone able to produce a valid signature for the account retains the power to authorize transfers and change the delegation, even when the code requires multiple approvals. Using distributed signing remains a separate design choice, requiring its own controls over the components involved.
From delegation to draining the wallet
According to TRM Labs’ analysis, the attackers submitted a single transaction containing fifty EIP-7702 authorizations signed with the key associated with Binance 14, one of the exchange’s Ethereum wallets. The authorizations covered consecutive nonce values to accommodate an account that was still processing transactions. One authorization was applied, recording the reference to the attacker’s code and enabling it to execute in the wallet’s context. A valid signature alone does not make a delegation applicable, since the requirements concerning the chain, nonce, and account state must also be met. The number of authorizations documents preparation of the operational sequence without, by itself, establishing how the signatures were obtained.
Blockaid estimated that the assets moved in the first major operation from Binance 14 were worth approximately $2.5 billion at prices prevailing at the time. In its reconstruction, the code allowed the attacker to issue instructions and call other contracts through the compromised account. The delegated wallet also held control rights over a separate Binance smart account, enabling additional USDC transfers. The persistent delegation allowed subsequent thefts of funds received after the initial drain, through further calls to the wallet. A new Binance 14 signature was not required for every transfer executed through that code. The exposure therefore included new balances and rights exercisable over other accounts, in addition to the original holdings.
Signature controls and wallet permissions
An authorization that changes the code executed by a wallet requires a different review from the one applied to withdrawals. That review covers the designated contract’s behavior, any mechanisms for updating it, and the network on which the signature can be used. A chain identifier of zero allows the authorization to be reused on other networks supporting EIP-7702, provided the account conditions allow it to be applied. Reviewing the signed data precedes signing and concerns the delegation itself, which does not specify amounts or recipients for subsequent transfers. A transaction’s zero value therefore does not imply zero financial exposure when it changes the account’s permissions. Separation of duties extends to the systems that prepare, verify, and sign requests, reducing approvers’ dependence on a single representation of the operation.
Monitoring covers changes to delegation and the powers each wallet exercises over other accounts. Suspending withdrawals through the service does not remove an active delegation, because external calls can continue to execute its code. Removal requires a new valid authorization specifying the zero address instead of the delegated contract. Emergency signing procedures therefore remain important in MPC systems, where the components needed to produce that signature must be coordinated. Revocation neither reverses completed transfers nor cancels any spending permissions granted within token contracts, which require separate checks. Preventing further unauthorized signing and suspending treasury transfers to exposed addresses also remain necessary, because revocation alone does not restore the infrastructure’s integrity.
Conclusions
In the Binance attack, EIP-7702 delegation extended the effects of the compromise beyond individual transfers, granting the attackers persistent powers over funds. The upgrade provided an execution mechanism, while the exchange’s preliminary report places the unauthorized access within its internal signing service. These findings concern distinct layers and do not establish a breach of Ethereum’s protocol rules. For custody, controls therefore encompass signature production, the powers granted through delegation, and permissions that can remain active after delegation is removed. The system’s robustness is measured by its ability to maintain independent checks and containment procedures that remain usable during an incident, reducing the risk that compromising one component leads to control over assets.
