Binance disclosed that an attacker reached an internal wallet transaction-signing service on October 29, 2026, then used it to push transactions outside the normal withdrawal process. Five XRP hot wallets sent 233.46 million XRP to attacker-controlled addresses between 20:05 and 20:09 UTC. Binance puts the total at about $6.34 billion in affected digital assets across multiple chains. Solana’s weekly news podcast called the Binance hack the largest crypto hack on record, though Binance stresses that its figure measures affected assets, not a final unrecovered loss.

Two weeks on, the useful question is mechanical. How does an exchange running multi-party computation (MPC) wallets, the design pitched as the cure for single-key theft, lose control of hot wallets in minutes? Binance’s preliminary report gives a partial answer. The attacker did not need to steal a private key. Control of the signing service was enough, and a feature of Ethereum’s EIP-7702 let that control outlive Binance’s first containment moves. Analysts have already mapped the Binance heist timeline hour by hour, so the engineering underneath it is the story worth reading now.

Don't miss new tech stories on Google

Add Shattered once in the Google app and our stories show up in your news suggestions.

The Binance Hack in Numbers

Most of the confirmed figures come from Binance’s own incident report, published November 3 and still the main primary document. The company calls the event a serious and highly sophisticated security incident. Its statement includes the line “This should not have happened,” which is unusually blunt for an exchange post-mortem. Binance also says users did not bear the loss and that the company will absorb the financial impact.

The table below separates what Binance has stated from what remains unsettled. The $6.34 billion number is the headline, but the available official material does not establish that it equals the final unrecovered loss.

How the Attackers Reached the Wallet-Signing Service

Binance describes a multi-stage campaign that ran for months, not a single phishing click. The techniques it lists include fake job interviews, malware disguised as developer tools, compromised software packages, a compromised internal AI tool and device takeover. The chain matters because every step used ordinary developer workflow as the entry point, and none of it touched the blockchains themselves.

June 2026: A Modified Homebrew Install

The first stage dates to June. According to Binance, an engineer on the wallets DevOps team searched for a popular AI-powered programming tool and downloaded a modified Homebrew installation. Binance’s security team spotted the anomaly, replaced the device and rotated related credentials. The catch was incomplete, though. The report says that engineer’s workstation, plus those of colleagues on the wallets infrastructure team, had already been exposed to the attacker.

September 2026: The Fake Job Interview

In September, a different software engineer was approached through a legitimate job-search platform by someone posing as a project manager. The profile mentioned experience at Binance. A live video call with a purported HR representative followed, then a second interview with someone claiming to be the CEO of a fictitious company. At the end, the engineer was told to download a technical test onto a work computer. That repository carried malware that swapped a legitimate component of a development tool for a malicious one. Binance says the zero-day malware was not caught by device protection at the time.

October 20 to 29: An Internal AI Tool and a Deploy Token

On October 20, the attacker used the compromised computer and an internal AI tool to gain control over the DevOps engineer and a second wallets engineer. The attacker then found a token on the DevOps engineer’s machine with permission to deploy containers. On October 29, per the report, the attacker logged into the second engineer’s computer with the stolen credentials, deployed a container and ran a malicious script to launch the attack. That detail lines up with Binance’s statement that the initial investigation may involve a compromised DevOps laptop and a service container. A separate analysis of AI governance gaps in the Binance heist argues that the internal AI tool deserves as much scrutiny as the malware.

What EIP-7702 Does, in Plain Terms

A standard Ethereum account controlled by a private key cannot run code. EIP-7702 changes that by letting the account owner sign an authorization that points the account at a smart contract. While that delegation stands, the account behaves like a contract wallet. Wallets use it for batched transactions and sponsored gas. Binance’s own description is that EIP-7702 allows an account to delegate certain execution rights to a smart contract without exposing its private key. A ChainCatcher explainer on EIP-7702 frames the same feature as the key link in the Binance case.

The feature cuts both ways. An authorization is just a signed message. Whoever can pull valid signatures out of a signing service can delegate the account to a contract they wrote. Binance says the attacker did exactly that, using the signing service to grant a contract under their control partial execution rights over a hot wallet. The wallet commonly called Binance14 is the one whose delegation Binance later cleared.

Readers who hold their own Ethereum accounts can check whether a stray delegation exists. The step-by-step EIP-7702 delegation audit covers how to read an account’s delegation state and clear it.

Earlier cases show the same primitive on the consumer side. Phishing kits have used signed delegations to drain individual users, a pattern documented in coverage of EIP-7702 wallet drainers. Binance’s case moves that primitive inside the signing infrastructure of a large exchange, where the delegation came from a compromised service rather than from a tricked user.

Why MPC Wallets Did Not Stop the Sweep

MPC splits a signing key into shares held by separate parties, so no single device holds the whole key. That defeats the classic theft in which an attacker copies a key file. It does not defeat an attacker who controls the service that asks the shares to sign. If the policy layer says yes, the shares cooperate and produce a valid signature. Binance confirms that the affected hot wallets used MPC, and the attacker still initiated transactions outside the usual withdrawal process.

The same design hurt Binance during cleanup. Its report says the attacker sent a series of signing transactions to manipulate the account nonce and set up malicious delegations. Once those delegations existed on-chain, they worked independently of Binance’s withdrawal infrastructure. Suspending withdrawals and shutting down hot wallet services did not invalidate them. Because the wallet used MPC, there was no single private key Binance could use to revoke the delegations quickly. The team had to build and run a specialized procedure, which took more time.

That sequence is the technical lesson. Binance’s kill switch (suspend withdrawals) acted on its own application layer, while the attacker’s foothold now lived on Ethereum. Operators who rehearse incident response for stolen keys usually have no runbook for stolen signing authority. The baseline in any crypto wallet security checklist still helps at the user level, but exchange-grade defenses need policy enforcement below the application that requests signatures.

A Four-Minute XRP Drain Across Ten Chains

The first visible damage came fast. Between 20:05 and 20:09 UTC on October 29, five Binance hot wallets sent 233.46 million XRP to an address controlled by the attacker. Binance says it then received an internal alert tied to large-volume transfers and opened an investigation. Transfers from Solana and Optimism wallets, a Bitcoin wallet and an Ethereum wallet followed. Public analyses name outflows on at least Ethereum, the XRP Ledger, Solana, Optimism, Bitcoin, Tron, Arbitrum, Base, Avalanche and Polygon, with NEAR possible. An S2W incident analysis and a Shieldworkz threat report both describe the multi-chain spread, and one industry analysis put the cumulative count at 10 blockchains.

One large Ethereum sweep involving the wallet commonly called Binance 14 reportedly covered about 167,464 ETH and 63 ERC-20 tokens, including roughly $1.615 billion in USDT at the time. That figure comes from a single reporting source and Binance has not confirmed it. Treat it as indicative.

The chain-side picture is quiet. Neither the XRP Ledger nor Solana has reported a protocol exploit, halt or rollback tied to the incident. The thefts happened at the exchange’s edge, not inside the chains. That distinction matters for anyone worried that the underlying networks are weaker than they were a month ago. On the available evidence, they are not.

What Issuers Could Freeze and What They Could Not

Binance reports that about $2.85 billion in assets had been frozen or intercepted, subject to reconciliation and market price volatility. Other reporting put the figure near $3 billion within hours. The gap between $6.34 billion affected and $2.85 billion frozen is the practical measure of what the attacker kept control of, at least on paper.

Freezing works where an issuer controls a token contract. Stablecoin issuers can blacklist addresses, so stolen stablecoins can be locked quickly. Native assets such as Bitcoin, Ether and XRP have no issuer with that power. No official Binance result confirms that the native XRP taken from the hot wallets was frozen or recovered. That asymmetry shapes where an attacker wants value to end up. It also explains why the first minutes of an exchange breach decide how much comes back.

For a wider view of where this event sits among record thefts, a ranked look at the biggest crypto hacks compares the Binance incident with earlier exchange breaches. Binance’s own wording on the loss stays careful. It reports 98% of affected token assets replenished by October 31 and says the remaining assets, which are less liquid, were still being acquired.

Laundering and Attribution: What Is Known

Binance’s report says the latest information from the US Federal Bureau of Investigation indicates North Korea is responsible. Elliptic’s analysis reaches a similar view, with a headline saying North Korea is likely behind the hack. A BBC live page reported that the US Secret Service is helping to track the stolen funds. Binance adds that its security team detected and prevented 57 potential cyber threats linked to North Korea during 2026. The fake interview, the malicious developer tools and the fake video apps on its list match tradecraft long tied to that group.

Movement of the proceeds has started. Blockchain-analytics reporting said the attacker’s identifiable XRP holdings had fallen to about 60 million XRP by November 10, after roughly 35 million XRP was reportedly exchanged through THORChain, largely for Bitcoin. That detail comes from a single source and has not been independently confirmed. It does fit a known pattern, where thieves convert assets that can be frozen into assets that cannot. A closer read of how TRM Labs tied the theft to North Korea covers the blockchain-forensics side.

Attribution does not change the engineering lesson. Whether a state group or a criminal crew drove the intrusion, the entry route was developer endpoints and internal tooling, which any exchange or custodian also runs.

Binance’s Response and Recovery Timeline

Binance suspended withdrawals on October 30 while it ran security checks and revoked the affected address authorization. A Binance incident announcement dated October 30 covers the suspension. The company then recorded a new Proof of Reserves snapshot on October 31 at 00:00 UTC, giving users an updated view of assets after the incident.

The remediation list in the report is concrete. Binance says it rebuilt the affected wallet system in a new environment, rebuilt the internal AI tool with tighter access controls, replaced affected devices, deactivated credentials and tokens tied to the engineers, scanned all employee devices, expanded AI-based behavioral anomaly detection and strengthened risk controls for wallet services. It is also engaging independent cybersecurity experts to validate its findings and plans a security research fund. Binance says some technical details will stay confidential so attackers cannot reuse them.

Separately, Binance Pool services ended on November 10. Nothing available links that closure to the incident, so the two should not be read as cause and effect.

How the Binance Hack Compares With Earlier Exchange Breaches

Older exchange thefts mostly followed two patterns. Attackers either stole a hot-wallet key, or they tricked operators into approving a malicious transaction through a manipulated signing interface. Both put the weakness at the key or the human approver. The Binance incident sits in a third category. The keys stayed split, and the human approvers were never the target. The attacker took over the automation that requests signatures and then used a protocol feature to make the foothold durable.

Custody designs respond differently to that threat. A hot wallet with MPC and a weak policy layer is fast and exposed to signing-service compromise. A multisig wallet with independent hardware signers raises the cost of control because each signer needs a separate compromise, but it slows legitimate withdrawals. Cold storage keeps most reserves offline and limits the blast radius, though hot wallets still hold the balances customers expect to withdraw instantly. No design wins on every axis. The question is where the policy check sits and who can change it.

Whether the industry can ever shrink this kind of systemic risk is the subject of a separate analysis asking whether crypto risk can be solved. The engineering answer in this case is narrower. Defenders can close specific gaps, and EIP-7702 delegation is one of them.

Controls Hot-Wallet Teams Should Change Now

The incident points to a short list of changes for any team that runs exchange or treasury wallets. None of them are exotic. Most are policy decisions that were optional a month ago.

  • Block delegation by default. Treasury and hot-wallet accounts rarely need to run delegated code. A signing policy that refuses authorization signatures unless an allowlisted contract is named would have narrowed the attacker’s options.
  • Enforce policy below the app. If a single service can both approve and request signatures, compromising it is enough. Put destination, amount and transaction-type limits in a layer the requesting service cannot edit.
  • Pre-build on-chain revocation. Binance had to improvise a procedure to clear delegations on an MPC wallet. Write and test that runbook before an incident, not during one.
  • Watch nonces and authorization events. Unexpected nonce movement and new delegation records on hot-wallet addresses are early signals.
  • Shrink deploy tokens. The attacker found a token that could deploy containers sitting on a laptop. Short-lived, scoped credentials limit that jump.
  • Treat internal AI tools as privileged systems. Binance says the attacker used an internal AI tool to take over two engineers’ machines. Apply the same access reviews as for production tooling.
  • Verify developer tool installers. The first stage used a modified Homebrew install pulled from a search result. Pin installers to verified sources.

Smart-contract wallet builders face a related question. Account-abstraction systems add their own attack surface, as shown in a walkthrough of ERC-4337 paymaster exploits. Teams adopting delegated execution for efficiency should test the abuse case as carefully as the happy path. More coverage sits in the site’s cryptocurrency section.

What Exchange Users Should Do After the Binance Hack

Binance says user funds were safe and that affected assets were replenished with its own money. Reportedly, the company said BTC, ETH, USDT, BNB, SOL, USDC, XRP, USD1, RLUSD and ZEC were fully backed as of its latest statement, a claim users can check against the Proof of Reserves page. Official material does not establish that customer balances were lost.

Still, users have reasonable moves available. Review withdrawal allowlists, turn on phishing-resistant two-factor authentication and decide how much sits on any exchange at all. The 12-step guide to crypto exchange account security walks through those settings. Users who self-custody on Ethereum should also check their own accounts for unexpected delegations, since the same primitive is now common knowledge among attackers.

One more point for traders: withdrawal reopening has been phased and subject to security checks, so networks may come back at different speeds. Binance began reopening on November 1 and said on November 3 that additional assets and networks would follow in phases.

Market Impact and the Balance-Sheet Test

The financial test is whether Binance’s reserves can carry the hit without a run. Its report says it set aside more than 100% of the funds needed to cover the losses and restored 98% of affected token assets by October 31. If that holds, the headline loss becomes a balance-sheet event, not a solvency event. The less liquid remainder is the part to watch, since Binance says it is still acquiring those assets.

Token prices reflected the stress. XRP was reportedly trading near $1.05 on November 12, down about 19.57% over seven days, according to InvestIn.News market data. That figure comes from one source and other recaps show different seven-day moves, so it should not be read as a precise measure of the incident’s effect. XRP was the first asset named in Binance’s account of the outflows, and a stolen stockpile that gets sold into the market adds supply pressure.

The deeper market effect is on trust in custody claims. Exchanges sell safety on the strength of their wallet architecture. A case in which MPC wallets were drained through an authorized-looking path will push institutional counterparties to ask for details on signing policies, not just reserve attestations.

Five Predictions for the Next Six Months

  • Independent findings will land. Binance committed to an outside review that validates its account. Expect a second, more technical report that either confirms or revises the signing-service narrative.
  • Delegation controls become standard. Custodians will add explicit refusal rules for EIP-7702 authorizations on hot-wallet addresses. Wallet-infrastructure vendors will market policy engines that understand delegation.
  • Proof of Reserves expands. Pressure will grow for exchanges to attest to signing-policy controls alongside balances.
  • Developer endpoints get audited. Security reviews at exchanges will treat engineer laptops, deploy tokens and internal AI tools as in-scope assets, not afterthoughts.
  • Fake-recruiter attacks rise. Other crypto firms will report more job-interview lures as the technique gets attention, and staff training will shift toward verifying recruiters and take-home tests.

These are analyst judgments, not confirmed plans. Binance has not announced a timeline for the independent review.

What Is Still Unconfirmed

Several points remain open as of November 12. Binance has not published a final independently verified accounting of assets affected, frozen, recovered and permanently lost. Its official wording confirms unauthorized access to the signing service but does not conclusively name EIP-7702 as the root cause. The company has said some technical details will stay confidential. Secondary coverage, including Solana’s podcast, repeats reports that the attack involved AI, while Binance’s own account centers on the fake interview, the malicious repository and a compromised internal AI tool.

The exact asset split across chains is also unpublished, and so is a complete list of which hot wallets were retired, replaced or returned to service. Until those details arrive, headline loss comparisons with other breaches carry error bars. Readers should expect the numbers to move as reconciliation finishes.

Frequently Asked Questions

How much did the Binance hack involve? Binance reports about $6.34 billion in affected digital assets, with about $2.85 billion frozen or intercepted. It says 98% of affected token assets were replenished by October 31. The affected figure is not the same as a final unrecovered loss.

Did attackers steal Binance’s private keys? Binance describes unauthorized access to an internal wallet transaction-signing service, not a conventional theft of cold-storage keys. The affected hot wallets used MPC, so no single key existed to steal or to use for fast revocation.

What is EIP-7702 and why did it matter? EIP-7702 lets an Ethereum account delegate execution to a smart contract through a signed authorization. Binance says the attacker used the signing service to grant a contract under their control partial execution rights over a hot wallet, and that access kept working after Binance suspended withdrawals.

Were customer funds lost? Binance says user funds were safe and that it will bear the financial impact. The available official material does not establish that customer balances were lost. Users can compare balances against Binance’s Proof of Reserves page.

Who is behind the Binance hack? Binance’s report says the latest FBI information indicates North Korea is responsible, and Elliptic’s analysis points the same way. The US Secret Service is reportedly helping track the funds.

Is Binance operating normally now? Binance began reopening withdrawals on November 1 and said further networks would return in phases after security checks. The investigation remains active, and the company has rebuilt the affected wallet system in a new environment.

Did the XRP Ledger or Solana get hacked? No. The available official results show no XRP Ledger consensus failure, protocol exploit, halt or rollback, and no confirmed Solana protocol breach. The thefts came from exchange-controlled wallets.

Daniel Roth covers cryptocurrency and the cryptography behind provably-fair systems, explaining how commitment schemes and verification actually work rather than how they are marketed.