A Lesson in Ten Billion Dollars: DeFi Security Focus Shifts from Code to Operational Governance

Original Compilation: 登链社区

Content Summary and Guide:

In the past year, nearly $1 billion has been lost in DeFi, and major losses are no longer primarily due to smart contract bugs, but stem from permission management, signature workflows, social engineering attacks, third-party infrastructure, and cross-chain composability risks. Drawing lessons from TradFi’s operational resilience, the three lines of defense, emergency freezes, risk data governance, and asset onboarding reviews, combined with AI-assisted security analysis, are necessary to enhance user fund safety while maintaining openness and composability.

We didn’t have to lose that billion dollars

Over the past twelve months, nearly $1 billion was lost due to DeFi incidents, but most of it could have been avoided.

Starting with the most recent exploit: April 18, Kelp DAO’s $292 million exploit.

AAVE dropped 15%. Aave froze the rsETH market in all deployments, then also froze WETH lending as a precaution. Aave’s own contracts were never exploited, but within hours, the utilization rate of Aave’s WETH market hit 100%. WETH suppliers who had never touched rsETH suddenly couldn’t withdraw.

Then came the common crypto Twitter sentiment: Bridge is broken. DeFi is broken. That’s why real funds don’t flow in.

I believe these statements miss the point.

Most of this $1 billion loss was due to attack vectors that had long been discussed and had known mitigation strategies. The largest losses are driven mainly by privilege access, signature workflows, social engineering, and third-party infrastructure, not isolated smart contract bugs. However, these fixes are not documented in DeFi whitepapers but are found in bank risk management manuals, engineering resilience research, and decades of operational playbooks from TradFi.

Kelp is the clearest example.

A verifier. A single point of failure.

The Kelp exploit was not a smart contract bug. The root cause was that @KelpDAO chose a 1-of-1 decentralized validator network (DVN) configuration on LayerZero bridge. The attacker, allegedly linked to North Korea’s Lazarus Group, did not breach the DVN itself. First, they identified which RPC providers LayerZero’s DVN depended on. Then, they compromised two of them to return forged data. Next, they launched DDoS attacks on the remaining providers, forcing the system to failover to the compromised ones. Under good-faith signing, the DVN signed a forged cross-chain message—since no other verifier verified the result, this signature was sufficient.

One verifier. One failure point.

116,500 rsETH was released from LayerZero’s OFT Adapter (which manages tokens across multiple chains) on Ethereum to the attacker, causing the rsETH OFTs on sixteen L2s to lose backing. The attacker collateralized rsETH on Ethereum into Aave, Compound, and Euler, then borrowed $236 million in WETH until the breach was discovered. Now, everyone holding rsETH on any L2 holds a claim on an emptied lockbox.

This explicit risk was flagged twelve days ago.

On April 6, engineer @liliangjya5 from @get_truenorth published an open-source Claude Code skill, highlighting the opacity of DVN configurations, marking the single point of failure across 16 chains as the biggest risk vector, and comparing this setup to the 2022 Ronin and Harmony bridge exploits. The commit timestamp is public—anyone can see it.

[]

Kelp has never disclosed their DVN threshold. LayerZero’s integration checklist explicitly recommends multi-DVN configurations. Kelp still chose 1-of-1. No one forced them to publish, no one forced them to change.

Twelve days later, $292 million gone.

The past twelve months do not negate DeFi

Kelp’s exploit is the largest, but not the only one.

• Just two weeks ago, on April 1, Drift lost $285 million after months of social engineering attacks. The attacker exploited Solana’s durable nonces to obtain valid admin signatures, whitelisted a worthless token as collateral, and drained real assets. At least 20 other protocols reported impacts. Drift itself, in its post-incident reconstruction, added dedicated signer devices, admin operation timelocks, and rebuilt governance multisig.

• On March 22, Resolv was attacked via offchain infrastructure. The attacker infiltrated third-party project entry points into Resolv’s GitHub and cloud environment, gaining signing rights for minting, and minted 80 million unbacked USR tokens, stealing $25 million in ETH. The smart contract itself was not compromised; the vulnerability was in privileged keys and operational stack.

• On March 10, Aave’s risk tooling triggered about $26 million in liquidations after a mismatch between two oracle parameters, involving 34 accounts. The mismatch caused wstETH’s price to drop 2.85%. No malicious actor or exploit occurred. The loss resulted from a well-meaning configuration update that was not tested against hostile scenarios.

• Before 2026, we also saw Cetus lose $223 million on Sui, Cork lose $12 million after multiple audits due to wstETH, Balancer lose over $120 million in November, and Aerodrome lose over $1 million due to DNS hijack—not because of smart contract exploits, but because their domain registrar was compromised. Once again, the contracts themselves were unaffected; a phishing page delivered the final blow.

Altogether, these nearly sum up to $1 billion in losses. Each incident has a different direct cause, but a pattern is emerging.

These exploits have shifted offchain

The risk from smart contracts has not disappeared—Cetus, Cork, and Balancer all suffered real onchain logic failures. Any protocol still dismissing invariant testing, adversarial simulation, and formal verification as optional will learn their lesson after a single release. But that is no longer the main story.

Looking across crypto, Chainalysis estimates over $6.5 billion stolen in 2025, with the top three hacks accounting for 69% of losses. As previously mentioned, the largest losses are driven by privilege access, signature workflows, social engineering, and third-party infrastructure, not isolated smart contract bugs.

I see three failure modes:

These exploits have moved offchain

Smart contract risks have not vanished—Cetus, Cork, and Balancer are real onchain logic failures. Any protocol that still considers invariant testing, adversarial simulation, and formal methods optional will learn the hard way after one release. But that’s no longer the main focus.

In the entire crypto space, Chainalysis estimates over $6.5 billion stolen in 2025, with the top three hacks accounting for 69%. The main drivers remain privilege access, signature workflows, social engineering, and third-party infrastructure, not just smart contract bugs.

I categorize these as three different failure modes: Code layer, Control plane, and Composability.

2. Code is the layer where DeFi is actually most capable of defending itself, yet it remains incompletely solved. We have fuzzing, static and dynamic analysis, formal verification, bug bounties, audits, invariant testing—every serious team knows how to implement these now.

3. Control plane is where DeFi lags at least a decade behind TradFi. Signer devices, key rotation, privilege access review, CI/CD provenance, DNS hardening, domain registrar security. Most protocols lack even an inventory of these surfaces, let alone control over them.

4. Composability, while one of DeFi’s greatest strengths, also introduces the newest and most underestimated risk—when a lending market lists a wrapped asset, it turns the bridge’s failure mode into its own. When a collateralized debt position accepts a liquid staking token, it inherits the issuer’s governance delays. Aave did not write a single line of Kelp’s code but still suffered damage from Kelp’s failure—exposing governance issues of its own.

If a protocol lists collateral that it cannot independently value, freeze, haircut, or liquidate under stress, it effectively embeds the tail risk of that asset into its own balance sheet, regardless of whether the treasury has signed off.

TradFi has long written the playbook

The debate about making DeFi “more like TradFi” often goes off track at the same step. The intuition in crypto is that becoming more like TradFi means slower, more custodial, permissioned, and heavily regulated.

[]

I believe that’s wrong.

While TradFi is far from perfect, it has devised many tools far more useful than permissioning. It has figured out how to operate critical systems during disruptions—these frameworks already exist. They have been stress-tested through decades of bank failures, trading halts, cyberattacks, and operational incidents.

Relevant examples:

• NIST Cybersecurity Framework 2.0 elevates Governance to a core function alongside Identify, Protect, Detect, Respond, and Recover.

• Basel Committee on Banking Supervision defines operational resilience as the ability to deliver critical operations during disruption.

• UK Financial Conduct Authority requires firms to identify critical business services, set impact tolerances, and test whether disruptions breach these thresholds.

• Institute of Internal Auditors’s Three Lines model separates management, risk challenge, and independent assurance.

All these do not require TradFi’s balance sheet or permission. They can be ported into DeFi. Safe DeFi does not mean surrendering to banks; it means maintaining open, user-facing access and composability while adopting bank-level discipline at the control layer.

When Lazarus targeted LayerZero’s RPC providers, they used the same playbook as for SWIFT and enterprise software supply chain attacks. TradFi has thirty years of experience in this area. Yet, DeFi seems to believe it can ignore its history.

Privilege power is a systemic utility

Privilege power must be harder to use than regular protocol functions. Any key, multisig, or service account capable of listing collateral, moving reserves, updating oracles, changing bridge peers, or modifying liquidation logic is a systemic financial utility. The minimum standards:

• Hardware wallets

• Phishing-resistant authentication

• Independent signer machines

• Out-of-band transaction decoding

• Quorum separation

• Timelocks on all non-emergency operations

• Explicit rejection of convenience features that could weaponize dormant signatures in the future

Drift’s post-incident reconstruction is a good minimum standard.

Offchain infrastructure is also part of the protocol. Source code management, CI/CD, cloud IAM, package registries, domains, DNS, WalletConnect surfaces, and browser-delivered frontends are within real threat boundaries. Engineering standards include least privilege access, hardware-backed identities, secretless deployment, reproducible builds with SBOM, and dependency pinning. At the boundary, registrar locks, DNS hardening, and decentralized mirror frontends can ensure continuity during incidents.

Aerodrome’s DNS hijack reminds us that boundaries are much larger than most teams assume.

Every change should be tested against hostile scenarios. Cross-chain verifiers should verify proofs, not attestations. Canonical bridges verify signed block headers via merkle proofs—cryptographic guarantees: compromised nodes can refuse to provide data but cannot forge it. Proof verification is stronger than attestation, but proof-based bridges still inherit consensus, implementation, and upgrade risks. The question is: what failures are excluded, and which are retained?

Attestation-based verifiers do not provide the same guarantees. They sign whatever RPC endpoints return, expanding the attack surface. If attestation is used for speed or chain compatibility, quorum reflects independence, not just number. Five validators reading the same poisoned RPC can sign the same lie five times. Security only emerges when quorum members have truly independent data sources, ideally mixing private and trusted public nodes. Kelp exemplifies how attackers exploit this gap.

Not all collateral should enter shared assets. Bridge assets, liquid staking tokens, vault shares, synthetic dollars, and wrapper tokens should be treated as structured products. They require separate onboarding memos covering broad risk profiles and conservative limits. Most should be isolated markets rather than shared core pools.

Aave paused rsETH in April 2025 due to Kelp’s over-minting bug. A year later, rsETH returned to shared markets—this warrants stricter scrutiny.

Detection and response must operate at machine speed. When a protocol can be drained in minutes, manual intervention is governance theater. Automated controls—detecting admin actions, mint/burn events, utilization spikes, oracle depegging, bridge traffic anomalies—are the norm: combined with native rate limits, borrow throttles, and pre-agreed, governance-reviewable auto-freeze triggers.

We must prioritize user fund safety. The inconvenience of occasional automated triggers is far less than the cost of having no automation at all.

Governance must define what cannot fail

To help teams set safety goals, governance must specify what absolutely cannot fail. Boards, foundations, councils, or DAOs should explicitly list their critical business services: user deposits and withdrawals, liquidations, oracle updates, governance execution, bridge in/out, front-end access, incident communication.

For each, impact tolerances should be set—max tolerable user harm, solvency loss, downtime, data uncertainty—and tested against severe but plausible scenarios to ensure they hold.

This is the essence of operational resilience in banking, and it can be directly ported to DeFi.

DeFi should adopt a true Three Lines model:

• First line: product, engineering, treasury, and operations are responsible for risks they create and controls they implement.

• Second line: independent risk and security functions with clear authority challenge listings, parameters, upgrades, and counterparties, and slow or block unsafe changes.

• Third line: independent assurance reports on whether the first and second lines are effective.

Independence is the key to preventing growth incentives from self-approving.

Asset onboarding should resemble credit underwriting, not business development. Listing memos should cover liquidity, concentration, governance centralization, bridge pathways and upgradeability, redemption mechanisms, circuit breakers, oracle construction, and legal packaging. If any assumption is broken, each memo must have a clear downgrade process.

Emergency permissions should be narrow, predefined, and sunsetted. The Cetus and Sui recovery votes demonstrate that emergency intervention can save hundreds of millions. They also raise serious questions: who can override these systems, and on what basis? The answer is: before launch, not during a crisis—by defining trigger conditions, authorized actors, evidence standards, maximum duration, transparency obligations, and pathways back to normal governance.

Every protocol needs a pre-approved resolution plan. Drift is assembling a recovery pool post-incident. Aave shifted to compensate users after oracle misalignment. Resolv reimbursed holders at 1:1 before the hack. These are reasonable responses, but higher standards call for pre-authorized waterfalls: user protection first, then treasury buffers, insurance or safety modules, service-provider liabilities, and clear thresholds for socialized losses.

Distinguishing protocols that take governance seriously from those that do not involves three questions: who can block an unsafe launch? who can freeze markets under predefined conditions? and when a delegated service provider causes loss, who pays?

A protocol that cannot specify relevant personnel, trigger conditions, and responsibility pathways has not properly defined governance—it’s just hoping exploits never happen.

Risk data determines the success or failure of controls

Secure DeFi requires a live data plane: onchain and offchain signals that drive every freeze, cap, and liquidation decision. The control plane acts; the data plane tells it whether to act.

Data standards and data quality are equally critical. Inputs to oracles, freezes, and parameter changes must have clear freshness windows, recorded provenance, confidence scores, and cross-validation with independent feeds. When feeds diverge, fallback behaviors must be predefined, not improvised.

Aave’s USDe risk-managed oracle proposal and its time-weighted Slope2 Risk Oracle point in the right direction. The wstETH incident reminds us that every automated control loop needs safeguards against misconfiguration.

Disclosure itself is a form of control. Users should have a public status page, attacker address watchlists, real-time incident logs, quick and factual initial statements, and post-mortems that distinguish confirmed facts from hypotheses, quantify losses, list control changes, and explain payout paths. Drift’s recovery update, Resolv’s post-mortem, and Aave’s oracle explanations are all much better than the vague tweets and silence typical of past DeFi incidents. Industry standards should include a communication playbook rehearsed before crises.

Risk data’s purpose is to drive action. Throttling lending, lowering caps, pausing markets, upgrading manually, proving a market can safely stay open—these are the real controls. Analytics that cannot feed into control, limit, or assurance processes do not deserve the label “risk infrastructure.”

AI threat models have changed

In April 2026, AI threat models shifted. Anthropic’s Claude Mythos Preview has demonstrated the ability to identify and exploit zero-day vulnerabilities across mainstream operating systems and browsers. Over 99% of the vulnerabilities it finds remain unpatched, because no one has fixed them yet. UK, US, and German banks and regulators now regard Mythos-level capabilities as real cyber risks.

DeFi protocols should do the same.

From a practical perspective, spear-phishing becomes cheaper, exploit development faster, reconnaissance more autonomous, and low-signal edge cases are detected earlier. Defensive responses should include:

• Developer workstations hardened like privileged endpoints

• Code reviews with AI-assisted adversarial analysis under controlled access

• Signer workflows with default phishing resistance

• Anomaly detection and limited auto-responses assuming attackers can iterate faster than human teams

Kelp’s story is actually a more optimistic version of this scenario. The same AI capabilities threatening protocols can also defend them. An open-source auditing tool running on Claude Code flagged Kelp’s precise risk surface twelve days before the attack. The tool isn’t perfect: it rated the risk as medium when it should have been critical; it can’t penetrate configuration layers without onchain verification; and it missed that DVN configurations can be queried onchain via LayerZero’s EndpointV2 contracts.

But it posed the right questions others did not.

This is the model we should adopt going forward. AI as an independent security layer, any LP, protocol, or auditor can leverage to outrun malicious actors.

Secure DeFi does not mean slow DeFi

The consensus after the Kelp incident was that DeFi has security issues. I believe that framing is itself mistaken.

DeFi’s real issues are control plane vulnerabilities, composability pricing, and governance discipline. All have known solutions, many of which are documented in bank risk manuals from thirty years ago. The only barrier between DeFi and vastly improved user security is whether founders will implement them.

Secure DeFi does not mean slow DeFi. Slow and safe are different attributes. Open access, composability, 24/7 global settlement; bank-level discipline, independent challenge, machine-speed controls, and continuous assurance—these can coexist.

Tools exist. Playbooks exist. Capital for safe DeFi already exists.

DeFi is just beginning. Let’s ensure it remains here in ten years.