50 signed authorizations, one Binance wallet takeover

A wallet takeover can leave incoming deposits exposed long after the initial theft. The critical question is what authority the attacker acquired—and whether that authority remains active (source: AnChain.AI).

How did 50 signed authorizations lead to one Binance wallet takeover?

AnChain.AI’s reconstruction links 50 signed authorizations carrying different account nonces to an attacker-controlled delegation on the wallet labeled Binance 14. A matching authorization installed the delegate; the sequence does not demonstrate a bypass of Ethereum’s signature verification. It shows how valid signing authority can enable malicious account control .

Quick Answer: According to AnChain.AI, a transaction carrying 50 signed authorizations installed attacker-controlled code on a Binance wallet when an authorization matched its nonce. The batch accommodated uncertainty about the account’s transaction counter; it did not bypass signature checks. The resulting delegation enabled a later sweeper call .

EIP-7702 delegation is a mechanism that lets an externally owned account—an account controlled by a signing key—execute designated smart-contract code while retaining its address. Legitimate uses include batching transactions and sponsored gas payments. The security consequence is substantial: delegated code operates in the account’s context, making this an account-level authorization rather than merely permission to spend a particular token (source: Ethereum specification).

AnChain.AI reconstructs the Ethereum sequence as follows:

• Delegation installed: On October 29, 2026, at 20:20:59 UTC, an authorization-bearing transaction installed the attacker’s sweeper contract as the delegate for Binance 14 .
• Sweeper called: At 20:24:23 UTC, a subsequent call triggered transfers including approximately 167,464.25 ETH and 1.615 billion USDT. These amounts describe transfers in this sequence, not the entire incident .
• Time between steps: The reported timestamps place the sweeper call three minutes and 24 seconds after delegation was installed .

A nonce is an account counter used to validate transaction and authorization sequencing. A busy wallet’s counter can change while an attacker prepares a submission. Signing authorizations for different counter values accommodated that uncertainty: a matching entry could satisfy the nonce check. The batch of 50 authorizations therefore does not imply 50 compromised wallets or 50 successful delegations . Signature verification still applied; varying the nonce did not eliminate the need for valid signatures.

The transaction evidence establishes the delegation sequence, but AnChain.AI says it cannot distinguish stolen private keys from compromised signing systems. That unresolved access question matters because clearing malicious delegation cannot restore exclusive control while an attacker retains signing authority. Ethereum’s implementation guidance explains that the original account key retains overriding authority even after delegation.

For traders, the decision is whether the convenience of account delegation justifies its authority, which controls must accompany approval, and how to respond if either the delegate or the signer becomes compromised. Evaluate the code’s permissions and the signing system’s integrity separately: removing delegated code addresses a different problem from securing an exposed key.

What does the Binance evidence establish—and what remains unresolved?

The Binance evidence supports a compromise of signing authority affecting multiple blockchains, with account delegation forming part of the Ethereum attack. It does not establish a final root cause or a failure of Ethereum’s signature verification. TRM Labs estimates approximately $6.36 billion left wallets across ten blockchains; that is an investigator estimate, not a final audited loss . For traders, the distinction matters: observed transfers, assessments of how access was obtained, and the amount ultimately recovered answer different questions.

• Observed scope and reporting window: TRM reports that most outflows occurred within roughly 20 minutes beginning October 29, 2026, at 20:05 UTC. Its observations extended through October 30 at 00:30 UTC, making the estimate a snapshot of the incident at that cutoff .
• Assessment of signing access: TRM assesses that Binance’s hot-wallet signing infrastructure was compromised. Separately, Hacken’s account of Binance’s investigation describes a potentially compromised DevOps laptop, service-container access and subsequently identified additional breach points. It also relays Binance’s statement that it found no evidence of leaked wallet private keys. These accounts do not settle whether an attacker extracted keys, abused signing systems, or combined access paths.
• Limits of the delegation explanation: TRM reports ordinary signed transfers on the other nine chains, alongside Ethereum activity without delegation . Consequently, EIP-7702 cannot explain the entire breach. AnChain.AI’s reconstruction likewise states that transaction evidence cannot distinguish stolen private keys from compromised signing systems.
• Frozen assets versus recovery: TRM reports approximately $2.7 billion frozen through issuer and network interventions at its reporting cutoff . A freeze restricts asset movement; it does not establish that those assets have been returned to users. Treating the frozen amount as completed reimbursement would overstate the recovery evidence.

Headline discrepancies also require care. The Hidden Economy video headline uses $5.7 billion (video: Hidden Economy). That headline should not replace TRM’s explicitly bounded estimate. Comparing amounts without their observation windows can make different reporting snapshots look like directly competing measurements.

Attribution requires a similar separation. TRM attributes the Binance attack to North Korea’s TraderTraitor with high confidence, but this remains an investigator assessment. The FBI’s February 26, 2025 announcement attributes approximately $1.5 billion stolen from Bybit around February 21 to North Korean TraderTraitor activity . That announcement concerns Bybit; it is not FBI confirmation of the Binance attribution.

The practical implication is to evaluate signing access and delegated authority independently. An absence of evidence that keys were leaked does not establish that signing systems remained secure. Equally, identifying malicious delegated code does not explain how the attacker obtained valid authorizations. Neither finding supports treating delegation removal alone as a complete response to compromised signing authority.

How does EIP-7702 delegation differ from a token approval or ordinary transfer?

EIP-7702 delegation authorizes contract code to execute in a wallet account’s context; a token allowance authorizes a spender to move a particular token, while an ordinary transfer moves assets without granting continuing access. Delegation therefore requires evaluating account-level behavior, including how the delegated code authenticates later instructions. An externally owned account, or EOA, is an account controlled by a private key. Ethereum’s Pectra upgrade activated on May 7, 2025, at 10:05 UTC, introducing delegation that lets an EOA retain its address while using features such as transaction batching and sponsored gas payments . These are legitimate usability improvements: applications can combine actions, and another account can pay transaction fees. The security question is which implementation receives authority and what restrictions it enforces. (Sources: Ethereum’s Pectra overview and the delegation specification.)

The comparison below separates a completed asset movement from permissions that remain active. Inspecting a recipient address is appropriate for a simple transfer; reviewing a delegate requires understanding executable behavior and access controls.

The account-level distinction and delegation-clearing mechanism follow the specification; AnChain.AI’s incident analysis explains why that distinction matters for asset protection. Revocation must target the authority actually granted: an allowance control and a delegation control address different permissions.

Malicious delegated code can move the account’s own assets without obtaining a separate token allowance because it executes as the account. For a token transfer, the account can act as the token holder rather than as an outside spender using an allowance. That does not mean every legitimate delegate allows unrestricted execution. A properly designed implementation authenticates instructions and constrains permitted actions. The authorization signature installs the delegate; it should not be treated as permission for arbitrary callers to execute arbitrary actions afterward. (Sources: delegation security considerations and AnChain.AI.)

Persistence changes the exposure after an initial theft. If malicious delegation remains installed, incoming deposits can become accessible to the same code. Revoking token allowances does not itself remove that code, so an allowance review cannot establish that an account is safe to fund. Clearing or replacing delegation addresses the installed authority; whether the signer remains trustworthy is a separate question. (Source: AnChain.AI’s delegation analysis.)

The original private key also retains overriding authority. Delegating to code with a multisignature-style policy does not eliminate that key’s ability to bypass the policy, according to Ethereum’s implementation guidance. Evaluate the key and delegate together: secure code cannot neutralize a compromised underlying signer, and careful key custody cannot make malicious delegated behavior safe. Choose delegation only when its execution rules and the custody of the original key both fit the assets you intend to hold.

Which checks should determine whether you sign an EIP-7702 authorization?

Sign an EIP-7702 authorization only when you understand the requesting application, the delegate implementation, the chain scope and why account-level authority is necessary. Treat an unexpected or unexplained request as a reason to stop and verify through an independently opened official channel. TRM Labs recommends rejecting unexpected signing requests; Ethereum’s implementation guidance warns that malicious delegation can expose an account’s assets. A familiar interface is not enough to justify approval.

1. Identify the application and intended action. Write down what you expect the wallet to do: enable sponsored fees, batch operations or configure wallet functionality. Ask why that action requires delegation. If the prompt arrives unexpectedly, or the explanation does not match your intended action, decline it while you verify. Do not let an urgent trading opportunity substitute for understanding the permission.
2. Inspect the delegate address and implementation. Compare the complete address with the wallet provider’s official documentation for the selected network. Look for a security review covering the actual deployed implementation and its execution controls. An address match establishes identity, not safety; recognizable branding does not demonstrate that the code correctly restricts access. Ethereum’s guidance on delegation risks makes implementation quality central to account security.
3. Check the chain identifier and nonce. The authorization signs a chain identifier, delegate address and nonce. Chain ID zero permits acceptance on other supporting chains when their validation conditions match; a chain-specific identifier limits that scope. The nonce must match the authorizing account during processing . Ask for an explanation of unexpected nonce batches. A different account may submit the authorization-bearing transaction, so the submitter’s address alone cannot establish safety, according to the specification.
4. Decide whether the authority is necessary. Require a clear benefit that justifies changing the account’s execution behavior. If the application cannot explain that benefit and the controls limiting later use, choose a workflow without delegation. Convenience is a reason to evaluate the feature, not a reason to skip evaluation.

The distinction to examine is between selecting code and permitting that code’s later actions. The specification’s authors state in its Security Considerations:

“Replay protection (e.g., a nonce) should be implemented by the delegate and signed over.” — The EIP-7702 specification authors, Ethereum Improvement Proposals.

Use the specification’s security requirements to ask the wallet provider for evidence of these implementation controls:

• Authenticate later execution: verify who may authorize calls after delegation is installed.
• Bind execution parameters: protect the intended destination, call data, value and gas against substitution.
• Protect initialization: authenticate setup instructions so an observer cannot race to install attacker-controlled settings.
• Prevent replay: ensure an execution signature cannot be reused to repeat its effects.
• Check storage compatibility: review how replacement code interprets existing account storage before changing delegates.

These are questions for the implementation’s maintainers and reviewers, not a demand that every trader audit contract code. If the wallet cannot make the answers understandable and verifiable, postpone signing. Approve delegation only when its purpose, scope and execution safeguards are clear enough to justify the assets exposed.

Which wallet setup fits your trading activity and security needs?

The right wallet setup depends on whether you control the signer, need delegated features and can limit the assets exposed. Occasional self-custody users should require a clear benefit before approving delegation; frequent traders should assess delegate controls, balances and signer separation together. Exchange-only customers need custody-specific checks, while treasury operators need infrastructure controls. These recommendations apply the security guidance in the EIP-7702 specification, Ethereum’s implementation guidance and TRM Labs’ incident analysis.

For occasional users, convenience should justify the permission. Rejecting an unnecessary delegation request closes that particular authorization path, but it does not eliminate phishing, malicious ordinary transactions or signing compromise. Delegation also leaves the original account key with overriding authority: a delegate’s spending policy cannot protect against an attacker who can bypass it through that key. This distinction matters when choosing security features, according to Ethereum’s implementation guidance.

For active traders, a dedicated activity wallet is a practical way to limit exposure, provided the reserve has genuinely separate signing control. A small current balance is insufficient protection if valuable deposits keep arriving at an account with malicious delegated code. Assess the delegate’s execution safeguards, expected inflows and signer access as a combined decision. Persistent delegation and execution authentication are central concerns in the specification.

Exchange customers generally cannot inspect or revoke treasury-wallet permissions through their exchange account. Public blockchain visibility does not confer signing authority. Their actionable checks concern authenticated deposit instructions and incident communications; a token-approval tool connected to a personal wallet cannot change an exchange-controlled signer. AnChain.AI’s reconstruction concerns permissions on the exchange’s blockchain account, a different control boundary from a customer login.

For treasury operators, TRM Labs recommends isolation by chain and wallet tier, alerts for unexpected delegation changes, detection of authorization batches spanning many nonces and tested revocation procedures. Delegation monitoring addresses persistent execution rights; signer isolation limits broader compromise across custody systems. Choose a setup that can enforce both, because removing delegated code does not restore exclusive control while an attacker retains signing access.

What should you do if your wallet has an unexpected delegation?

An unexpected delegation calls for containment and a signer assessment before recovery. Stop unfamiliar signing requests, pause deposits and inspect the account’s delegated code through trusted tooling. Clearing unwanted code addresses delegated execution, but restoring exclusive control also depends on whether anyone else can still sign for the account. Ethereum’s delegation guidance explains that the original account key retains overriding authority .

1. Stop approving unfamiliar requests. Do not sign an unexpected authorization presented as a repair or verification step. Use a trusted route to your wallet’s support documentation. TRM Labs recommends rejecting unexpected delegation requests and maintaining a tested revocation procedure.
2. Avoid adding deposits to the affected address. Redirect planned incoming transfers while the account’s control remains uncertain. TRM reported subsequent sweeps of new Binance deposits following the October 29, 2026 incident . Treat this as a reason to pause funding, including attempts to add gas without first assessing the recovery path.
3. Inspect the current delegation state. Use trusted tooling to check whether delegation is present, identify its target implementation and review the affected chain. A disconnected application is not proof that delegated code has been removed: delegation persists until replaced or cleared, as explained in AnChain.AI’s reconstruction.
4. Assess the original key and signing environment. Consider whether the authorization resulted from a misleading request or whether the device, key or signing service itself may be compromised. AnChain.AI states that transaction evidence alone cannot distinguish stolen private keys from compromised signing systems. An unfamiliar delegation establishes a problem requiring investigation; it does not identify the access route.

Clear delegation through the appropriate authorization mechanism. Under EIP-7702, a valid authorization pointing to the zero address clears delegation . This is separate from revoking token allowances or disconnecting an application. The protocol specifies the mechanism, not a shared recovery interface across wallets. Follow trusted documentation for an implementation that supports the required operation, and verify the resulting account state.

Choose recovery according to signer control. If the signer remains exclusively yours, clearing or replacing malicious delegation addresses that delegated-code path. If an attacker retains the key or signing access, clearing alone cannot restore exclusive control: the attacker can authorize another delegation or sign transfers. The security implication of Ethereum’s retained-key-authority model is that a replacement account must use an independently secured signer.

Check residual permissions and state. Delegation changes do not erase existing account storage, and previous token allowances need separate review. The specification’s security considerations also identify storage collisions during delegation changes. Treat attempted recovery as potentially contested while attacker access remains possible; a successful clearing transaction is not sufficient evidence that the signer is safe or that unwanted authority cannot be reinstated.

What should your EIP-7702 security checklist include after setup?

Your EIP-7702 security checklist should track the code authorized to act for your account and the signer that can replace that authorization. Delegation remains a continuing security responsibility: the original account key retains overriding authority, so a trusted delegate cannot compensate for an unsafe signer (source: Ethereum implementation guidance).

For a personal wallet, make these checks part of routine account maintenance:

• Record the intended configuration. Keep the delegate address, its intended purpose and the authorized chain scope alongside your wallet records. Compare later requests against that baseline.
• Monitor delegation changes. Investigate an unfamiliar delegate or an unexplained replacement before continuing to use the account.
• Review every new signing request. Confirm that its target and scope match the action you initiated. Familiar application branding is insufficient evidence of authorization safety.
• Keep a tested clearing procedure. Know how your wallet supports clearing delegation through an authorization targeting the zero address (source: EIP-7702 specification).
• Reassess the signer when behavior changes. Unexpected account activity should trigger a review of signing devices, connected software and access paths, alongside the delegate itself.

Infrastructure operators need additional controls around signing systems. TRM Labs recommends separating signing infrastructure by chain and wallet tier, monitoring treasury delegation changes and maintaining a tested revocation procedure. Translate those controls into actionable alerts:

• Unexpected authorization requests: investigate who initiated the request and whether its purpose was approved.
• Batches spanning many nonces: inspect their origin and intended execution; unusual breadth deserves review.
• Treasury delegation changes: reconcile each change against an authorized operational action.
• New deposits swept after an incident: investigate whether unwanted execution authority or signer access remains active.

Each alert warrants investigation; none alone proves theft. Correlate it with signing logs, transaction behavior and approved workflows before drawing conclusions.

The reported sequence of 50 signed authorizations illustrates how already-compromised signing authority can become persistent delegated execution . AnChain.AI’s reconstruction does not establish whether the attacker obtained private keys or access to signing systems. The decision therefore remains twofold: assess what the delegated code can do and who can still authorize changes.

Evidence status: November 2, 2026. Findings that would warrant an update include an audited loss figure, a confirmed initial access mechanism, revised attribution or evidence that frozen assets were returned. The accounts from TRM Labs, AnChain.AI and Hacken leave those outcomes unresolved.

Keep your delegation baseline and clearing instructions accessible. If account behavior departs from that baseline, pause new signing and investigate both the delegate and the signer before resuming normal use.

Frequently asked questions

Did the Binance incident prove that EIP-7702 bypasses signature verification?

No. AnChain.AI’s reconstruction describes 50 signed authorizations with different account nonces; a matching authorization installed the attacker’s delegate . The nonce range accommodated uncertainty about the wallet’s transaction counter. It did not bypass signature verification, and the transaction evidence cannot distinguish stolen private keys from compromised signing systems.

Was the reported Binance loss $5.7 billion or $6.36 billion?

The Hidden Economy video headline gives $5.7 billion . TRM Labs estimated approximately $6.36 billion in outflows, based on observations through October 30, 2026, at 00:30 UTC . Neither figure should be treated as a final audited loss. Frozen assets are a separate category and should not be counted as funds returned to users.

Does revoking token approvals remove an EIP-7702 delegation?

No. Token allowances and account delegation are separate permissions. Revoking an allowance does not remove delegated code. The EIP-7702 specification clears delegation through a valid authorization pointing to the zero address. If the underlying key or signing system remains compromised, clearing delegation alone cannot restore exclusive control: the attacker may still authorize transactions or install another delegate.

Can an EIP-7702 authorization apply across multiple chains?

Yes, depending on its chain identifier. Under the EIP-7702 specification, chain ID zero permits an authorization to be accepted on other supporting chains when their remaining validation conditions match . This does not cause automatic execution on every chain. The authorization must still be submitted and validated on each relevant chain.

Does delegating to multisignature-style code protect against a stolen EOA key?

Delegated multisignature-style controls do not eliminate the authority of the original externally owned account (EOA) key. Ethereum’s implementation guidance explains that the original key retains overriding authority and can bypass the delegated policy. Evaluate protection of the underlying signer separately from the approval rules implemented by delegated code.

Enjoyed this article? Subscribe to get new stories by email whenever they're published.

Subscribe