The number that matters first: April 2026 surpassed every previous month in dollar losses to DeFi exploits. The immediate causes vary — compromised admin keys, overbroad keepers, unsafe configurations, oracle manipulation, novel parser bugs — but the underlying pattern is striking once you cluster them.
We spent the month reading incident write-ups, on-chain forensics threads, and post-mortems. What follows is a taxonomy of the incidents we tracked, an honest accounting of which classes onchain policy enforcement bounds, and which it doesn’t.
The taxonomy
We cluster the incidents into eleven attack classes. The top six share a common shape: authority that could do more than it should. The bottom five are contract-design and protocol-design failures.
Top: compromised or overbroad authority
- Compromised privileged key / admin wallet. Stolen or coerced credentials with unbounded execution scope. Affected: Purrlend, Volo Vault, Zerion Wallet, Grinex, a Drift-like governance compromise.
- Overbroad keeper / signer / automation authority. Operational keys with more capability than the operation actually required. Affected: Giddy, possibly Aftermath depending on root cause.
- Unsafe admin or protocol configuration. Sensitive parameters changed without sufficient gating. Affected: Singularity Finance, Silo V2, partly ZetaChain, possibly Aethir.
- Custodial / opaque MPC vault risk. Off-chain custody where investor protections depended on the custodian’s word. Affected: Goliath Ventures off-chain fraud, MPC-managed vaults as a structural analogue.
- Unlimited approvals / wallet blast radius. Operational wallets that could approve too much, too broadly. Affected: ZetaChain, bridge/operator-wallet incidents.
- Signing-interface or signature-binding failures. The signature didn’t fully bind what the signer thought they were authorizing. Affected: Giddy.
Bottom: contract and protocol design failures
- Bridge verifier / cross-chain message validation failure. Affected: KelpDAO, Hyperbridge, partly ZetaChain.
- Oracle manipulation / price manipulation / AMM reserve abuse. Affected: Judao, BSC TMM/USDT, LML/USDT staking, MONA, Silo V2 partly.
- Contract logic / access-control bugs. Affected: SubQuery Network, Juicebox V3, Dango, Scallop Lend, Kipseli, Thetanuts Finance, Rhea Lend.
- Deprecated / forgotten contract with residual funds. Affected: Scallop Lend, old reward pools and abandoned modules.
- First-depositor / vault share inflation. Affected: Thetanuts Finance.
What onchain policy bounds — and what it doesn’t
Being honest about scope is more useful than overclaiming. Zodiac’s smart-account policy layer addresses the entire top half. It does not address the bottom half — those need audits, formal verification, robust oracle design, and defensive contract code.
The split, attack class by attack class:
What onchain policy bounds
- Compromised privileged key. High relevance. Restrict the role’s callable contracts, functions, parameters, time windows, and amount caps. A stolen key drains nothing outside its mandate.
- Overbroad keeper / automation authority. High relevance. Convert a broad keeper into a narrowly scoped capability — approved aggregators, approved tokens, capped amounts, expiring permissions.
- Unsafe admin configuration. Medium-high relevance. Sensitive config changes can require stricter roles, timelocks, multisig thresholds, or parameter allowlists.
- Unlimited approvals / wallet blast radius. Medium relevance. Scope operational wallets so they cannot grant unlimited allowances or interact with arbitrary contracts.
- Custodial / opaque MPC vault risk. High conceptual relevance. Replace off-chain trust with onchain enforcement: managers operate within predefined permissions; investors verify positions and NAV-like state on the chain.
- Signing-interface or signature-binding failures. Medium alone; high with scoped execution. Better EIP-712 design helps. Scoped execution helps more: the chain refuses calldata using unapproved routers, token pairs, or amounts even if the signer was tricked.
What onchain policy doesn’t bound
- Bridge verifier failures. Low-medium relevance. We can govern bridge configuration and limit emergency/admin powers, but we don’t fix weak proof verification or single-verifier trust assumptions.
- Oracle manipulation. Low relevance. Needs robust oracle design, TWAPs, liquidity checks, and manipulation-resistant accounting.
- Contract logic and access-control bugs. Low relevance. Needs audits, invariant tests, and defensive contract design. We don’t fix a public function that’s incorrectly coded.
- Deprecated contracts with residual funds. Low-medium. We can limit operator access to legacy contracts; the real fix is deprecation hygiene.
- First-depositor / vault share inflation. Low relevance. Needs minimum liquidity, virtual shares, guarded initialization.
The common thread is operational
Strip out the contract-design bugs and a single pattern dominates what’s left: authority that could do more than it should, governed by a procedure someone was trusted to follow. An admin wallet that could drain after a breach. A keeper that could route funds anywhere. A signer who could be tricked into authorizing an arbitrary call. In each case a rule existed — in a runbook, an approval policy, an operating procedure — and in each case the rule was only as good as everyone’s willingness and ability to honor it.
That’s the part worth sitting with. The largest cluster of these losses wasn’t cryptographic, and for the most damaging ones it wasn’t even a contract bug you could audit away. It was operational: the controls meant to bound authority lived in a document, and a document is only a hope that everyone — every operator, every interface, every counterparty — behaves.
The defense isn’t to make keys harder to steal; we’ve spent fifteen years on that. The defense is to stop trusting people and interfaces to honor the rules and to make the rules unskippable — every operational policy expressed as onchain bytecode the chain enforces before any state changes. A procedure in a runbook is a hope. The same procedure as a smart-account policy is a guarantee.
This is the operational-security shift the most damaging incidents of this cycle keep making the case for. The Bybit hack made it obvious. April 2026 made it urgent. The taxonomy makes it concrete: the losses cluster where authority outran the controls meant to bound it — and onchain enforcement is how you close that gap.
If you’re evaluating
If your organization runs any operating model where compromised authority would be catastrophic — a treasury, a vault, an automated agent stack, a protocol you operate — let’s talk. We can walk through your specific threat model and which classes from the taxonomy above you’re currently exposed to.