It's the Keys,
Not the Chain
Why Key Compromise Drives Most Crypto Losses

As of October 30, 2026, DefiLlama tracks $26.977 billion in total value hacked, of which $9.286 billion was in DeFi protocols and $3.691 billion in bridges. Losses in 2026 alone stand at $8.154 billion across 322 incidents, with the Binance CEX incident logged as the largest. The more revealing view is the platform's breakdown of all-time value hacked by attack technique. Converting each slice into dollars makes the pattern hard to ignore:

Direct key failures
  Hot wallet + weak generation + signer phishing
  + private key + validator key            = 60.36%  ≈ $16.28B

Key + credential / authorization failures
  (adds improper access control + phishing) = 68.61%  ≈ $18.51B

Named code-logic failures
  Price manipulation + verifier + arithmetic =  7.30%  ≈ $1.97B

Ratio, direct key failures : named code bugs ≈ 8.3 : 1

Robustness check — remove Binance's $5.78B entirely:
  Key failures   = (16.28 − 5.78) / (26.977 − 5.78) ≈ 49.5%
  Named code bugs = 1.97 / 21.197                    ≈  9.3%
  → keys still outweigh named code bugs by > 5 : 1

The robustness check is worth dwelling on. A single incident accounting for over a fifth of all-time losses could, in principle, distort the picture. It doesn't. Even with Binance excluded completely, roughly half of every dollar ever stolen in this dataset left through a key that was weak, stolen, phished, or held by too few independent parties. The 24% "Others" bucket also contains further key-adjacent categories, so 60% is a floor on the key-driven share, not a ceiling.

2026 alone makes the point more sharply. Of the $8.154 billion lost so far this year, the Binance entry accounts for about 71%. Add the roughly $387 million Bitget incidentof September 24 — reported as a compromise of backend systems and internal credentials that tricked the exchange's withdrawal authorization into approving transfers — and three-quarters of the year's losses came from two centralized exchanges whose signing authority was hijacked, not from any public blockchain behaving incorrectly.

The wallet at the center of the incident is the address labelled "Binance 14" — one of the exchange's best-known Ethereum hot wallets and, according to CoinDesk's reading of Binance's own proof-of-reserves data, one of the wallets listed as backing customer balances on October 1, when it held about 1.26 billion USDT and 89,475 ETH among 37 assets. The attack did not exploit a contract bug. Based on public on-chain analysis, it used the account's own signing key to change what the account is.

The mechanism was EIP-7702, the Ethereum upgrade that lets an externally owned account (EOA) delegate its execution to contract code. An EOA signs an authorization tuple naming a delegate contract; once a set-code transaction (type 0x04) carrying that authorization is included, any call to the EOA runs the delegate's code in the EOA's own context, with full access to its balances. The feature exists for good reasons — batching, gas sponsorship, and smart-account UX for ordinary wallets. In the hands of anyone holding the key, it turns a passive address into programmable infrastructure.

T − days   Operator address funded via Tornado Cash; delegate
           contract with a sweep() function deployed shortly before.

~20:20     EIP-7702 authorization signed by Binance 14's key
           (digest = keccak256(0x05 || rlp([chain_id, delegate, nonce])))
           and included on-chain. Binance 14 now executes delegate code.

~20:24     Operator calls sweep() on Binance 14.
           ~167,464 ETH + >1.6B USDT + other ERC-20s → attacker EOA
           in effectively one transaction. Binance 16 drained
           (~28,005 ETH) in the same window.

+15 min    ~195,460 ETH forwarded to a secondary address.

Later      An inbound USDT transfer to Binance 14 is swept again —
           the delegation persists until the key holder overwrites it.

Response   Tether freezes >1.567B USDT, Circle ~$823M USDC,
           Ripple ~$200M, World Liberty ~$27M USD1.
           Native ETH cannot be frozen.

Three architectural facts follow directly from that sequence, and none of them is specific to Binance. First, the delegation required a valid signature from the hot wallet's key, so the attacker either held that key, controlled infrastructure able to request signatures from it, or induced an authorized signer to produce one. Threat Landscape's analysis lists shared key material, a compromised common signing service, or sequential compromise of several operational keys as the plausible explanations — all three are key-management failures. Second, there was no rate limit between the key and the balance: billions moved in one transaction. Third, the account stayed weaponised after the first sweep, because a 7702 delegation is persistent state, not a one-off call.

Lined up chronologically, the industry's largest incidents read less like a series of novel exploits and more like the same failure arriving through different doors. The attack surface moved — from server-resident hot keys to multisig signers' browsers to compromised signing UIs to account-delegation messages — but the target never changed.

The LuBian entry explains why "Weak Key Generation" is the second-largest slice in DefiLlama's breakdown: one pool, one bad random-number generator, roughly $3.5 billion at the time of the theft. Arkham's 2025 analysisfound the theft had gone unnoticed publicly for nearly five years. Bitcoin's secp256k1 curve was never at risk; a 256-bit keyspace populated from 32 bits of entropy is a 32-bit keyspace, whatever the curve.

Note also where the losses concentrate. The biggest entries are centralized exchanges and bridges — the parts of the ecosystem that reintroduced a small set of operational keys controlling pooled customer funds. Self-custodied assets and well-audited, immutable protocols appear far less often at the top of the table. The largest losses happen precisely where crypto rebuilt the custodial, single-operator model it was designed to remove, and then ran it without the controls that model has always required.

"Key compromise" is too blunt a label to design against. In practice a key passes through five stages in its life, and each stage has its own characteristic failure and its own control. Most incident post-mortems map cleanly onto exactly one of them.

Stage five deserves a formal definition because it is the one most often misreported. A "5-of-9 multisig" sounds like it requires five independent compromises. Ronin's did not: four of the nine validator keys were operated by Sky Mavis, and a fifth signature was obtainable through an allowlist arrangement Sky Mavis still had access to. The real security of a threshold scheme is the minimum number of independent failure domains an attacker must breach.

k_eff = min | D' |  over all sets of failure domains D' ⊆ D
        such that  Σ_{d ∈ D'} keys(d)  ≥  t

D  = failure domains (organisation, cloud account, HSM vendor,
     device fleet, admin identity provider, signing software build)
t  = signature threshold

Ronin, March 2022:   t = 5,  n = 9
  keys(Sky Mavis, incl. allowlist path) = 5   →  k_eff = 1

Design target for operational wallets:  k_eff ≥ 3
  with no domain holding ≥ t keys and no shared software supply chain

The usual reaction to a multi-billion-dollar crypto hack is that the asset class is too dangerous to hold. It helps to put the losses next to what the regulated banking system has lost over the same period of living memory:

The comparison needs to be made honestly, because the categories differ. Bank losses are overwhelmingly credit, market, and liquidity losses — bad loans, mispriced risk, asset-liability mismatch — not theft. Crypto's headline losses are mostly theft. The point is not that one number is bigger than the other. It is that the IMF's 2008 estimate alone is more than 150 times DefiLlama's entire all-time crypto hack total, and the global response was never to abandon banking. It was to engineer controls on top of it: Basel III capital and liquidity rules, stress testing, resolution regimes, deposit insurance funded by special assessments, and the four-eyes, maker-checker operational discipline that every bank treasury now takes for granted.

Banking also has its own key-compromise history, and its response is the most directly useful precedent. In February 2016, attackers used Bangladesh Bank's legitimate SWIFT credentials to send fraudulent payment instructions worth nearly $1 billion; about $81 million was ultimately lost. The messages were perfectly valid to the network — exactly like a validly signed blockchain transaction. SWIFT did not redesign its messaging protocol. It launched the Customer Security Programme: mandatory controls on the endpoints that originate messages, segregation of the operator environment, and independent attestation. That is the template crypto custody needs: the ledger stays, and the controls move to where the authority sits.

The design principle that would have stopped most incidents in the table above fits in one sentence: no single key, signer, server, or human should be able to move material value on their own."Key equals authority" is the bug. The architecture below replaces it with layers, each of which assumes the layer before it has already failed.

MPC and HSM architectures are covered in depth in our institutional custody architecture teardown; the point here is narrower. MPC removes the "key exists whole somewhere" failure. It does not, by itself, remove the "key signs whatever it is asked to sign" failure. An MPC quorum that co-signs any digest the hot-wallet service submits is a single key with extra latency. The policy engine is what converts distributed key material into distributed authority.

Concretely, the signing boundary should run a preflight like the following before it contributes a single share. Note what it refuses outright: opaque digests and EIP-7702 delegations to anything outside an explicit allowlist. An operational hot wallet has no legitimate reason to change its own code.

// Runs inside each MPC node / HSM policy module — never in the
// application backend that requests the signature.
function preflight(req: SignRequest, p: Policy, s: State): Decision {
  // 1. No blind signing. A bare 32-byte digest is undecidable.
  if (req.kind === "raw_digest") return deny("opaque digest");

  // 2. EIP-7702 authorizations hash over 0x05 || rlp([chainId, addr, nonce]).
  //    Recognise the domain and refuse delegation by operational wallets.
  if (req.kind === "eip7702_auth" && !p.allowedDelegates.has(req.delegate))
    return deny("set-code delegation to non-allowlisted contract");

  // 3. Decode and simulate against current chain state.
  const tx  = decode(req.payload);
  const sim = simulate(tx, s.chain);

  // 4. Anything that changes code, owners, modules or thresholds
  //    is governance, not operations — route to the cold quorum.
  if (sim.changesCodeOwnersOrThreshold)
    return escalate("governance-quorum", { approvals: 4, delayHours: 48 });

  // 5. Destination and velocity controls.
  if (!p.allowlist.has(sim.recipient) && sim.outflowUsd > p.newDestCapUsd)
    return deny("unknown destination above cap");
  if (s.velocity.rolling(3600) + sim.outflowUsd > p.hourlyCapUsd)
    return hold("hourly velocity exceeded", { reviewers: 2 });

  return approve();
}

Prevention eventually fails; mature security programmes plan for that. The useful question is not whether a hot key can be compromised but how much it can move before someone notices and stops it. That can be written down and engineered against:

L_max = min( B_reach ,  r_max × (t_detect + t_contain) )

B_reach    balance reachable by that signing authority
r_max      max outflow rate the policy layer permits  (USD / min)
t_detect   first malicious signature → alert
t_contain  alert → keys revoked / wallet paused / issuers notified

Optimal hot float:
B_hot* = Q_0.99( net withdrawals over T_refill ) × (1 + m)
  T_refill  time to replenish from warm storage (e.g. 4 h)
  m         safety margin (e.g. 0.25)

Binance 14, as reported:
  B_reach ≈ 1.26B USDT + ~170k ETH        → billions
  r_max   = unbounded (single sweep tx)
  ⇒ L_max = B_reach

Same wallet with r_max = $5M/min, t_detect + t_contain = 20 min:
  ⇒ L_max = $100M — a bad night, not an existential event

Two parameters do most of the work. The first is B_reach: if 99% of a day's withdrawals can be met from a few hundred million dollars with four-hourly refills, there is no operational reason for billions to sit behind one signing authority. Tiered custody — hot, warm, and cold, each with stricter quorum and longer delays — is old advice because it works. The second is r_max. A plain EOA has no rate limit; whoever holds the key can move everything in one block. Enforcing a rate limit requires either a policy engine in the signer (Layer 3 above) or putting the limit on-chain.

On-chain limits are the stronger guarantee, because they still hold even if the off-chain policy layer itself is compromised. A smart-contract wallet — a Safe with guard and module controls, or an ERC-4337 account — can enforce per-period spending caps, destination allowlists, and timelocks for any change to owners, modules, or implementation, with a separate guardian key able to freeze or cancel during the delay window. The same principle drives the policy-bound agent wallets of ERC-8196: authority to spend is narrower than authority over the account.

tiers:
  hot:
    float_target: "Q99(4h net withdrawals) × 1.25"
    signing: mpc 2-of-3       # nodes in 3 clouds, 2 HSM vendors
    per_tx_cap_usd: 2_000_000
    hourly_cap_usd: 25_000_000
    destinations: user-withdrawal | allowlist
    forbidden: [eip7702_auth, delegatecall, owner_change, raw_digest]
  warm:
    signing: mpc 3-of-5       # ≥ 3 independent failure domains
    destinations: [hot]       # can only refill hot
    delay: 2h                 # cancellable by guardian quorum
  cold:
    signing: hsm 4-of-7, air-gapped, geographically split
    destinations: [warm]
    delay: 48h
governance:                   # code, owners, thresholds, modules
  approvals: 4-of-7 cold signers + security officer
  delay: 72h, publicly visible on-chain

The most capable adversaries in this space — the North Korean groups the FBI and industry investigators have tied to Ronin, Bybit, and a long list of exchange incidents — rarely break cryptography. They break people and endpoints: fake recruiters sending weaponised job offers to engineers, poisoned npm packages, compromised developer machines at a wallet vendor, a manipulated web UI served to multisig signers. Bybit's signers reportedly approved what their screens showed as a routine transfer; the payload replaced the wallet's logic.

Controls at this layer are mostly unglamorous discipline, and they are where the remaining risk concentrates once Layers 1–4 are in place:

In the containment formula above, t_detect and t_contain are the parameters an operations team controls directly. Mempool and block monitoring of an institution's own addresses is cheap; failing to do it is expensive. The detection rules that matter most are those that fire on structural changes, which legitimate operations almost never make:

Response is a rehearsed playbook, not an improvised call. It includes pre-negotiated contacts at stablecoin issuers and major exchanges (the Binance freezes show how much can be recovered when issuers act within hours), pre-built transactions to rotate keys and move remaining balances to cold storage, and a public communication template. Response capacity also has a balance-sheet dimension: an insurance or protection fund sized against L_max, not against a guess. Bitget's User Protection Fund absorbed a $387 million loss; it would not have absorbed a Binance-sized one. Monthly proof-of-reserves combined with proof-of-liabilities is what lets customers verify, rather than take on trust, that a shortfall has been covered.

Presenting the architecture above as a solved problem would be the same mistake as presenting blockchain as broken. Each layer carries its own costs and unresolved weaknesses.

For an exchange, custodian, or protocol treasury that recognises its own architecture in the incident table, sequencing matters. The order below puts the largest reduction in L_max first.