In 2026, DeFi lost more to keys than to code

Trackers disagree on the totals for 2026, but they agree on the shape. Smart contract bugs remain the most common kind of incident. Compromised keys, infrastructure and governance account for most of the money. Two incidents from April 2026 show why.

Two exploits, no contract bug

Drift Protocol, 1 April 2026. Attackers, attributed by TRM Labs to North Korean operators, gained control of the protocol's admin keys after off-chain social engineering. Reports describe a 2-of-5 multisig with no timelock. With admin rights, the attacker listed a worthless token as valid collateral, raised withdrawal limits to an absurd ceiling, deposited the token and borrowed out real assets in a few dozen transactions. Estimates of the loss range up to about $285 million; vault assets fell from roughly $309 million to $41 million in about an hour. USDC was moved off Solana through Circle's cross-chain transfer protocol while the attack was still running.

Kelp DAO, 18 April 2026. About 116,500 rsETH, roughly $292 million, was released on the strength of a forged cross-chain message. LayerZero's post-mortem says attackers poisoned RPC nodes used by its verifier and knocked clean nodes offline, and that Kelp's route was configured with a single verifier. Kelp replied that the single-verifier setting was the platform default, used by a large share of applications. LayerZero later apologised and moved to stricter multi-verifier defaults.

In both cases the contracts did what they were told. The failure was in who could tell them, and how quickly.

Why audits did not catch it

A typical audit scopes the Solidity or Rust. It rarely asks:

• how many signers there are, on what devices, and whether any of them are reachable by a fake recruiter or a poisoned dependency;
• whether a parameter change takes effect instantly or after a delay;
• what a single compromised oracle, RPC node or verifier can do;
• whether anyone is watching outflows at three in the morning, with the power to stop them.

The proposal: design as if a key is already stolen

1. 01Split admin powers by blast radius. Listing collateral, changing limits, upgrading code and pausing are different roles held by different signer sets. The role that can pause should not be the role that can drain.
2. 02Timelock everything that moves risk. New collateral, raised limits and upgrades wait 24 to 72 hours on chain, visible to users and monitors. Only pausing is instant.
3. 03Rate-limit outflows. Per-block and per-hour withdrawal caps, per asset, turn a total loss into a bounded one. Drift's treasury emptied in about an hour; a cap of a few percent per hour would have bought time.
4. 04Make new collateral earn trust. A new asset starts with a tiny cap, an oracle with several sources and a minimum liquidity requirement before it can back meaningful borrowing.
5. 05Never rely on one verifier. Cross-chain routes need several independent verifiers, run on independent infrastructure, with value caps per route. A verifier that reads from one provider's RPC is not independent.
6. 06Harden the humans. Hardware keys, dedicated signing devices, transaction simulation before every signature and a rule that no signer approves what they cannot read.
7. 07Monitor with authority. Alerts on admin actions, oracle deviations and unusual outflows, wired to a guardian that can pause, and an incident plan rehearsed before it is needed.

None of this is exotic. It is what banks call segregation of duties and limits, written into contracts.

What to measure

• Time to effect. For each privileged action, the delay between proposal and execution. Zero should appear only next to pause.
• Maximum hourly outflow. The most value that can leave the protocol in an hour under current caps, against total value locked.
• Signer independence. Signers per role, the devices and organisations they sit on, and how many share an attack surface.
• Time to pause. From the first anomalous transaction to a confirmed pause, measured in drills, not assumed.

How we would start

Write down every privileged action in your protocol, who can take it, and how long it takes to take effect. That one table usually shows the problem. We do this as part of every security review and build the controls into new DeFi protocols and cross-chain systems from the start. If you are evaluating someone else's contract, our article on what a contract can do to your money covers the code side.