Binance hack 2026: withdrawals, reserves and what happened

Can you withdraw from Binance again?

On 5 November Binance announced further phased reopening of withdrawals from 04:00 UTC. The list does not mean all token–network pairs become available at once; check the precise status through official access.

On 4 November Binance reported replenishing approximately 98% of the affected amount using company funds. This is not a return rate for stolen assets.

Binance says its 4 November 00:00 UTC reserve snapshot covers 44 tokens. Its full cryptographic proof was still being generated when announced. A snapshot is neither a complete financial audit nor evidence of the attack’s root cause. [28] [29] [17]

Frozen does not mean returned

Binance’s earlier $2.54 billion figure was an interim snapshot. It now reports roughly $3 billion frozen. A freeze may restrict further movement of particular tokens. It does not mean those assets have already been returned to Binance or its users.

The estimated overall impact of about $6.3 billion is not a final net loss either. The figures come from an ongoing investigation and describe different quantities. Subtracting $3 billion from $6.3 billion therefore does not establish a confirmed coverage gap or final loss. [11] [14] [15]

Multiple breach points, rather than a single-laptop explanation

Binance’s first preliminary account described a compromised DevOps laptop and access to a service container. Its later account identifies additional breach points. Richard Teng says the incident involved more than one machine or one engineer’s permissions. The initial lead therefore remains short of a fully reconstructed cause.

Teng says the EIP-7702 delegation did not pass through normal approval controls. That raises a concrete question: which path allowed this authorisation when the regular controls should have examined it? The statement does not publish the complete logs, identities or technical bypass paths. It does not establish a particular phishing technique or a container escape.

The delegation observed on Ethereum and access to operational infrastructure describe different layers. The blockchain shows processed authorisations and transactions; the operational investigation must explain earlier access. EIP-7702 enables code delegation. It is not a multisignature rule, regardless of an interview’s simplified description. [5] [14] [22] [23]

What can users and organisations do?

Check the current status through the familiar Binance app or by entering the official address yourself. Ignore unsolicited compensation or unlocking links; never share passwords, one-time codes or recovery phrases. Organisations can review ownership of external platforms, approval processes and incident communications, and document relevant balances and transactions through official channels. Avoid rushed transactions based on unconfirmed claims. [6]

Why a compromised laptop does not automatically mean stolen keys

An attacker need not always take a private key away as a file to trigger an unauthorised transaction. In infrastructure with signing services, what matters may be which requests can reach the protected signer. Misuse of that path can produce technically valid signatures for business actions that were never approved. This is technical analysis, not an additional confirmed Binance finding.

Binance currently reports no evidence of wallet private-key leakage. That increases the importance of examining identities, container access and approval policies. The question remains open: an initial company finding does not replace reconstruction of the full sequence or independent review. The cause, asset reconciliation and any reimbursement require separate evidence. [5] [14] [16]

EIP-7702: what an authorisation actually permits

EIP-7702 is an Ethereum feature that lets an account delegate code execution to a smart contract. It requires a valid authorisation from that account. Another party can include the authorisation in a suitable transaction and pay the gas; the outer transaction need not originate from the delegating account.

Once accepted, the account points to the selected code. A later call can execute that code in the account’s context and thereby affect its assets. The delegation persists until a new valid authorisation changes or clears it. EIP-7702 is a feature, not a vulnerability proven to have caused this incident.

Code can be called in the execution phase of the same transaction; a later call is not a prerequisite. A cryptographically valid authorisation does not prove the action was intended by the organisation. If the subsequent execution phase reverts, an already processed delegation is not rolled back with it. [5]

What the initial blockchain analysis shows

Security company Blockaid reports a transaction containing 50 EIP-7702 authorisations for the address labelled Binance 14. One authorisation was reportedly accepted and the account delegated to a contract. An authorisation’s nonce must match the account’s current nonce. This is a preliminary external analysis, not a completed Binance incident report.

An independent 808bits analysis dates the delegation to 29 October at 20:20:59 UTC and a subsequent call involving token and ether movements to 20:24:23 UTC. These times refer to the examined Ethereum transactions, not every network or a final overall loss. A valid authorisation does not reveal how it was produced: stolen key material, a misused signing workflow or another access path cannot be established from those observations alone.

Source: 808bits and drk.vc; times describe individual examined transactions, not a confirmed total loss. [4] [7] [8]

Swipe or scroll sideways to read the table.

What organisations can examine in their signing process

For custody and wallet infrastructure, the crucial question is what a signature actually authorises. Signing and approval systems should display the request type, chain identifier, target contract and nonce clearly and evaluate them against a documented policy. Where feasible, prevent blind approval of unknown hashes and delegations that are not needed.

Teams can also restrict approved delegation targets, alert on changes and unusual authorisation batches, and independently review critical changes. Assign owners, rehearse a pause and recovery process, and preserve signing and system logs for investigation. There is not yet evidence that any one of these controls would have prevented the specific Binance incident.

These controls are Cyberkern’s technical analysis. Policies need to check the actual signing preimage before signing; blind hash approval can hide its purpose. An on-chain alert after execution cannot prevent that transaction. An approved destination alone does not guarantee safe code. [5] [9]

What the 50 authorisations and the nonce reveal

The number 50 initially describes entries in an authorisation list. It is neither a count of affected customers nor proof of 50 stolen keys. For each entry, Ethereum checks matters including the signature, chain identifier and account nonce. An entry that fails a check is skipped while processing of the list continues.

The nonce is an account counter. On a busy wallet it can change quickly as transactions are processed. Authorisations for different counter values can therefore cover a moving window. External analyses report one accepted authorisation in the examined Binance transaction. That is a finding about this case, not a protocol limit: a list can contain several valid entries, and each accepted authorisation increments the account’s nonce. [5] [7] [12]

How could this happen despite signature protection?

The initial DevOps lead does not explain the full sequence. Richard Teng identifies additional breach points and says the delegation did not pass through normal approval controls. The announced review spans endpoints, cloud, key management and signing. Operators therefore need evidence of control over each critical authorisation path, alongside protection of individual devices.

Three control questions follow for operators. They are Cyberkern’s technical analysis; the preliminary statement does not establish which specific control would certainly have prevented this incident:

A reliable reconstruction connects access logs, container activity, withdrawal requests, approvals and actual signatures. On-chain, the reported revocation must be distinguished from the historical state. An account or session action alone is not general proof that an earlier blockchain delegation has been cleared. [5] [12] [14] [22] [23]

• Identity and request: Which identity could submit critical requests from the affected device, and were the displayed action and actual signing content independently compared?
• Container permissions: Which services and withdrawal functions were reachable? Were permissions, service access and exception paths limited to what was needed?
• Containment and evidence: When were device and service access blocked, affected authorisations revoked and the changes verified against logs or on-chain state?

Would a hardware or cold wallet have prevented it?

Offline keys and suitable hardware can substantially reduce exposure to key theft. That protection matters. It addresses a different question from checking intent, however: a well-protected key can still sign a dangerous request if the wrong delegation or destination is approved.

Exchanges also need operational balances and frequent withdrawals. Limited hot-wallet inventories, separate responsibilities and clear, enforceable rules for critical signatures therefore matter alongside key protection. The reviewed sources do not fully establish the hardware, key-sharing or offline arrangements Binance used in the affected systems. This incident proves neither that hardware wallets are useless nor that a particular product would certainly have prevented it. [5] [13]

Three questions for users and the incident review

Does this mean my own wallet is compromised? An incident at Binance does not establish access to an independently managed personal wallet. An exchange balance and self-custodied keys are different situations. Check the status of your exchange account through the familiar app or an official address you enter yourself; a general report cannot establish your individual balance.

Should I approve a compensation claim or a wallet repair? No. News of an exchange incident is not a reason to approve an unfamiliar contract, disclose a recovery phrase or pay someone offering help. Such offers can turn a public hack into another loss. Technical changes to an actually affected wallet belong in a verified recovery plan.

What must a full incident review establish? A technical and chronological connection between access, signing and asset movements, followed by a reconciliation that separates transfers, frozen assets, returns and remaining loss. A promise to cover losses addresses financial responsibility. It does not replace evidence of the cause or of reimbursements already completed. Proof of reserves alone does not replace a full financial audit or an investigation of the cause and internal security controls. [5] [6] [13] [14] [17]