Binance's $6.3 Billion Hot Wallet Theft: How North Korea's TraderTraitor Pulled Off the Largest Crypto Hack in History

On October 29, 2026, an attacker drained approximately $6.3 billion from Binance hot wallets, setting a new record for the largest crypto theft in history. Binance confirmed the incident and put the impact at around $6.3 billion. TRM Labs valued the outflows at $6.36 billion at the time of transfer, roughly four times the $1.5 billion stolen from Bybit in February 2025, which is now the second-largest hack on record.

The theft was fast and wide. According to Bitquery's investigation, funds left 17 Binance hot wallets between 20:04 and 23:56 UTC, with the bulk moved in the first twenty minutes. TRM counted activity across ten chains. The largest pieces were approximately $3.79 billion on Ethereum, 18,270 BTC (about $1.47 billion) from a single Bitcoin hot wallet, 612.7 million USDT and 46.4 million TRX on Tron, 233.46 million XRP, and 970,500 SOL. The main Ethereum drain moved 167,464 ETH, about 1.6 billion USDT, and dozens of other tokens in a single transaction.

Stablecoin issuers moved quickly. Early figures cited approximately $971 million frozen by Tether and $823 million by Circle, and Tether CEO Paolo Ardoino soon said the company had frozen more than 1.567 billion USDT. TRM's later tally put Tether's freezes at roughly 1.77 billion USDT across several networks, against approximately 1.875 billion USDT stolen on Ethereum alone plus 612.7 million USDT on Tron. Circle's total reached about 825 million USDC, including the main 823 million USDC balance and a later conversion. Ripple, World Liberty Financial, and Arbitrum's Security Council added smaller freezes.

Binance estimated that around $3 billion was frozen in total. TRM's independent count stood at about $2.7 billion as of 00:30 UTC on October 30, including about $2.67 billion in stablecoins and $30 million on Arbitrum. Frozen is not the same as returned: these assets have been stopped from moving, but they should not yet be described as back in Binance's hands. Some sit on networks that can block the attacker from cashing out but may not be able to easily restore the funds to Binance.

Binance founder Changpeng Zhao, who is not legally permitted to run the exchange, posted early estimates of the freezes and wrote, "I don't manage Binance (.com) anymore, but as a shareholder, I expect all user funds will be fully covered." He later added, "Loss might be a bit higher than [$1 billion], but will cover." Binance paused deposits and withdrawals, said user funds were safe, and pledged to cover losses through its SAFU fund and company funds. It later disclosed that it believed the attack began with the compromise of a DevOps engineer's laptop. These are preliminary findings and commitments, not a completed technical post-mortem or proof of reimbursement.

TRM Labs attributed the attack with high confidence to TraderTraitor, a North Korean state-sponsored unit linked to the Lazarus Group. The same group was behind the Bybit theft. Chainalysis, ZachXBT, and Blockaid also pointed to North Korea.

Binance has not published a full root cause. Its preliminary account is that a compromised DevOps engineer's laptop may have allowed access to a service container and, from there, unauthorized withdrawals. Binance says it found no evidence that wallet private keys leaked. Bitquery found valid signatures on every drain but cannot show who requested them. TRM's assessment is that the most likely cause is a compromise of Binance's hot wallet signing infrastructure.

These accounts describe different layers of the same event. Binance's laptop explanation is a preliminary account of how access may have been obtained. TRM's analysis describes how that access appears to have been exercised on-chain. If the attacker could get the signing system to approve their requests, they would not need to steal a key: the keys stayed where they were, and the system holding them signed what the attacker asked for. Neither source suggests the underlying blockchains themselves were compromised.

Staged well in advance

The theft was not improvised. TRM traced an operator wallet funded by three small Tornado Cash withdrawals on the morning of October 28. Early on October 29, the attacker deployed and tested its attack code on two wallets, rehearsed the final version on a third, and routed the test funds back to the operator. About four hours later, the code was in place on a Binance hot wallet. TRM notes that this pattern of Tornado Cash funding, long staging, and pre-obtained signatures executed in one burst matches the Bybit and KelpDAO incidents.

EIP-7702 turned a hot wallet into the attacker's contract

On Ethereum, the attacker used EIP-7702, introduced in the Pectra upgrade in May 2025. It lets an ordinary account delegate its execution to smart contract code. Binance's busiest Ethereum hot wallet signed delegations pointing to a sweeper contract that only the attacker controlled. Because each authorization is valid only at one exact nonce, the attacker prepared 50 authorizations for consecutive nonces, guaranteeing that one would match when the transaction landed.

// The signing system produces authorizations for the hot wallet.
// Each one says: "run the code at this address as my own code"
// and is valid only at a single nonce.

for (n = current_nonce; n < current_nonce + 50; n++) {
    auth[n] = sign_7702_authorization(
        chain_id,
        delegate = attacker_sweeper_contract,
        nonce    = n
    )
}

// 20:20 UTC: one type-4 transaction carries all 50 authorizations.
// Exactly one matches the wallet's live nonce and is applied.

// From then on, the hot wallet's code IS the sweeper.
// Any call from the attacker's caller wallet runs it:
sweeper.sweepAll(hot_wallet)
//   -> 167,464 ETH
//   -> ~1.6B USDT
//   -> 60+ other tokens
// One transaction. No further signatures required.

// The delegation stayed active for 3h 50m and was called seven times,
// until Binance revoked it at 00:10:35 UTC on October 30.

EIP-7702 was only part of the attack. A separate Binance smart account had an executor role that let the attacker pull the 823 million USDC. A second Ethereum hot wallet sent 28,006 ETH, 55.7 million USDT, and 25.9 million RLUSD through ordinary signed transfers with no delegation at all. On the other nine chains, funds left through plain signed transfers too. That is why TRM assesses that Binance's cross-chain signing infrastructure was compromised, rather than attributing the theft to an Ethereum-specific vulnerability. EIP-7702 explains how one wallet was emptied so efficiently, but the common factor across every chain was a signing system that would sign for the attacker.

A window that stayed open

While the delegation was active, the sweeper contract did not stop at the wallet's initial balance: it repeatedly swept funds that arrived later. Bitquery's timeline shows the Ethereum delegation remained live for 3 hours 50 minutes, and more than 1.5 hours of that window came after Binance paused withdrawals. A withdrawal pause stops the exchange's own withdrawal pipeline. It does nothing to a wallet whose code now belongs to someone else. Only revoking the delegation closed the door.

usdt_taken            = 2,488M USDT   // Ethereum + Tron

frozen_by_tether      = 1,759M USDT   // 71%, across 11 freezes
swapped_to_eth        =   495M USDT   // UniswapX, 1inch Fusion, Uniswap, Aave loan
swapped_to_trx        =   234M USDT   // SunSwap

// The attacker paid roughly $119M over market prices
// to convert USDT before more freezes landed.

• Never let hot wallet signers produce EIP-7702 authorizations. An exchange hot wallet has no routine need to delegate its code to a contract. The signing policy should reject type-4 authorizations outright, or require a separate, heavily guarded approval path for them. A single delegation to an attacker's contract is equivalent to handing over the wallet.
• Enforce withdrawal policy inside the signer, not only upstream. If the signing system signs whatever a trusted internal service submits, compromising that service is enough. Signers should independently check destinations, amounts, velocity, and transaction type against policy, so that a request from a compromised machine to send 18,270 BTC to a new address is refused at the point of signing.
• Cap hot wallet balances to what operations actually need. Hot wallets holding billions of dollars turn any signing compromise into a historic loss. Keeping hot balances small and replenishing them from cold storage through a slower, multi-party process limits how much a single breach can reach.
• Treat engineer endpoints as part of the custody perimeter. A DevOps laptop with a path to production withdrawal services is a custody device and should be secured like one: hardware-backed authentication, isolated privileged access workstations, short-lived credentials, and no direct route from a general-use machine to signing infrastructure.
• Build kill switches that cover every way funds can leave. Pausing withdrawals did not stop a delegated wallet from being swept. Incident playbooks need a fast path to revoke delegations, rotate executor roles, and move remaining balances to cold storage, and these steps should be rehearsed so they take minutes, not hours.
• Pre-arrange freeze channels with issuers and networks. Tether, Circle, Ripple, World Liberty Financial, and Arbitrum's Security Council locked up billions within hours. Tether's first freeze still landed 37 minutes after the main Ethereum drain, and one wallet passed on 130 million USDT less than a minute before its freeze. Standing agreements and direct alerting with issuers can shrink that gap.