The billion-dollar lesson: The focus of DeFi security is shifting from code to operational governance

Original translation: Deng Chain Community

Content Summary and Guide:

In the past year, DeFi has incurred nearly $1 billion in losses, with significant losses no longer primarily stemming from contract code vulnerabilities, but rather from permission management, signature processes, social engineering attacks, third-party infrastructure, and cross-chain composability risks. By drawing on the operational resilience, three lines of defense, emergency freezes, risk data governance, and asset admission reviews of TradFi, combined with AI-assisted security analysis, we can enhance user fund security while maintaining openness and composability.

The billion dollars we should not have lost

In the past twelve months, nearly $1 billion has been lost due to DeFi incidents, most of which could have been avoided.

Let’s start with a recent exploit: the $292 million exploit of Kelp DAO on April 18.

AAVE dropped by 15%. Aave froze the rsETH market across all deployments and subsequently froze WETH lending for precautionary purposes. Aave's own contracts were never exploited, but within hours, the utilization rate of Aave's WETH market reached 100%. Those who had never interacted with rsETH suddenly found themselves unable to withdraw.

Then came the common crypto Twitter sentiment: The Bridge is broken. DeFi is broken. This is why real money won't come in.

I believe these statements miss the point.

Most of the $1 billion loss was due to attack vectors that had already been discussed for fixes. The largest losses were primarily driven by privileged access, signature workflows, social engineering, and third-party infrastructure, rather than isolated smart contract bugs. However, these fixes are not found in DeFi documentation but in bank risk management manuals, engineering resilience studies, and the operational playbooks that TradFi has honed over decades.

Kelp is the clearest example.

One verifier. One 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 the LayerZero bridge. The attackers, allegedly linked to the North Korean cybercrime group Lazarus Group, did not breach the DVN itself. First, they identified which RPC providers LayerZero's DVN relied on. Then, they compromised two of them to return forged data. Next, they launched a DDoS attack on the remaining providers, forcing the system to failover to those that had been compromised. The DVN signed a forged cross-chain message in good faith—since there were no other verifiers to validate the result, this signature was sufficient.

One verifier. One point of failure.

116,500 rsETH were released to the attackers from the LayerZero OFT Adapter on Ethereum (which manages tokens across multiple blockchains), causing rsETH OFTs on sixteen L2s to lose backing. The attackers deposited the rsETH on the Ethereum side as collateral into Aave, Compound, and Euler, borrowing $236 million in WETH until someone noticed. Now, everyone holding rsETH on some L2 holds a claim to an already emptied lockbox.

This clear risk was flagged twelve days ago.

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

[https://x.com/liliangjya5/status/2045751262222885193]

Kelp never disclosed their DVN threshold. LayerZero explicitly recommends using a multi-DVN configuration in their integration checklist. Kelp still chose 1-of-1. No one forced them to disclose, and no one forced them to change.

Twelve days later, $292 million was gone.

The past twelve months do not negate DeFi

The Kelp exploit is the largest, but not the only one.

• Just two weeks ago, on April 1, Drift lost $285 million after a months-long social engineering attack. The attackers exploited Solana's durable nonces to obtain valid admin signatures, whitelisting a worthless token as collateral and draining real assets. At least 20 other protocols reported being affected. Drift itself included dedicated signer devices, timelocks on admin operations, and a rebuilt governance multisig in its post-incident reconstruction plan.

• On March 22, Resolv was attacked through offchain infrastructure. The attackers gained access to Resolv's GitHub and cloud environment from a third-party project's entry point, obtaining signing authority for the minting process, minting 80 million unbacked USR, and stealing $25 million in ETH. The smart contract did not fail; the weak link was the privileged key and the surrounding operational stack.

• On March 10, Aave itself triggered approximately $26 million in liquidations involving 34 accounts due to a configuration mismatch between two paired oracle parameters, causing the price of wstETH to drop by 2.85%. In this case, there were no malicious actors and no exploit. This loss stemmed from a benign configuration update that was not tested against hostile scenarios.

• Just before 2026 began, we also experienced Cetus losing $223 million on Sui, Cork losing $12 million due to wstETH after multiple audits, Balancer losing over $120 million in November, and Aerodrome losing over $1 million not due to a smart contract exploit, but because its domain registrar suffered a DNS hijack. Again, the contract itself was not compromised. A phishing page delivered the final blow.

In total, this is nearly $1 billion in losses. The direct causes of each incident differ, but a pattern is forming.

These exploits have shifted to offchain

Smart contract risks have not disappeared—Cetus, Cork, and Balancer all represent real onchain logic failures. Any protocol that still considers invariant testing, adversarial simulation, and formal methods as optional is just one release away from learning a lesson. But this is no longer the main story.

Looking across the crypto landscape, Chainalysis estimates that over $6.5 billion will be stolen by 2025, with the top three hacks alone accounting for 69% of the losses. As mentioned earlier, the largest losses are driven by privileged access, signature workflows, social engineering, and third-party infrastructure, rather than isolated smart contract bugs.

I see this as three different failure modes: Code layer, Control plane, Composability.

1. Code is actually the layer that DeFi is best at defending, yet even so, it has not been fully resolved. We have fuzzing, static and dynamic analysis, formal verification, bug bounties, audits, invariant testing—now every serious team knows how to do these.

2. Control plane is where DeFi is at least a decade behind TradFi. Signing devices, key rotation, privileged access reviews, CI/CD provenance, DNS hardening, domain registrar security. Most protocols don’t even have an inventory of these surfaces, let alone control over them.

3. Composability, while one of DeFi's greatest strengths, also brings the newest and most underestimated risks—when a lending market lists a wrapped asset, it turns the bridge's failure mode into its own failure mode. When a collateralized debt position accepts a liquid staking token, it inherits the issuer's governance delays. Aave did not write any of Kelp's code, yet still inherited the damage caused by Kelp's failure—this also exposed its own governance issues.

If a protocol lists collateral that it cannot independently value, freeze, haircut, or liquidate under pressure, it effectively places the tail risk of that asset onto its own balance sheet, regardless of whether the treasury signs off.

TradFi has long written the playbook

The debate about DeFi becoming "more like TradFi" often goes astray at the same step. The intuition in crypto is that becoming more like TradFi means being slower, more custodial, more permissioned, and more regulated.

[https://x.com/mert/status/2045875457359220928]

I believe this is incorrect.

While TradFi is certainly not perfect, it has come up with things that are 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 interruptions, cyberattacks, and operational incidents.

Relevant examples:

• NIST Cybersecurity Framework 2.0 elevates Govern 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 disruptions.

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

• The Institute of Internal Auditors separates management, risk challenge, and independent assurance through its Three Lines model.

None of the above requires TradFi's balance sheet or permission. All of this can be transplanted into DeFi. Safe DeFi does not mean becoming a bank; it means adopting bank-level discipline at the control layer while keeping the user layer open and composable.

When Lazarus targeted LayerZero's RPC providers, they used the same playbook as attacking SWIFT and enterprise software supply chains. TradFi has thirty years of experience on this issue. However, DeFi seems to think it has nothing to learn from TradFi's history.

Privileged power is a systemically important utility

Privileged power must be harder to use than ordinary protocol functions. Any key, multisig, or service account that can list collateral, move reserves, update oracles, change bridge peers, or alter liquidation logic is a financial utility of systemic importance. Minimum standards:

• Hardware wallets

• Anti-phishing authentication

• Independent signer machines

• Out-of-band transaction decoding

• Quorum separation

• Timelocks on all non-emergency operations

• Explicitly reject features that would weaponize dormant signatures in the future

Drift's post-incident reconstruction plan is a good minimum benchmark.

The offchain stack is also part of the protocol. Source code management, CI/CD, cloud IAM, package registries, domains, DNS, wallet-connect surfaces, and frontends delivered by browsers are all within the real threat boundary. Engineering standards include least privilege access, hardware-backed identity, no secret deployments, reproducible builds with a software bill of materials, and dependency pinning. At the boundary layer, registrar locks, DNS hardening, and decentralized mirror front ends can provide continuity during incidents.

Aerodrome's DNS hijack reminds us that the boundary is much larger than most teams delineate.

Every change should be tested against hostile scenarios. Cross-chain verifiers should check proofs, not attestations. Canonical bridges will verify merkle proofs of signed block headers, which is a cryptographic guarantee: compromised nodes can refuse to provide data but cannot forge it. Proof-verification is stronger than attestation, but proof-based bridges still inherit consensus risk, implementation risk, and upgrade risk. The question is which failures this design excludes and which it retains.

Attestation-based verifiers do not have the same guarantees. They sign anything returned by RPC endpoints, making those endpoints themselves an attack surface. If using attestation is for speed or chain compatibility, then quorum represents independence, not quantity. Five validators reading the same poisoned RPC will 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 is the result of sophisticated attackers exploiting this gap.

Not all collateral is worth entering a shared balance sheet. Bridge assets, liquid restaking tokens, vault shares, synthetic dollars, and wrapper tokens should be treated as structured products. They require independent onboarding memos covering a broad risk profile and conservative limits. In most cases, they should enter isolated markets rather than a shared core pool.

Aave had already suspended rsETH due to Kelp's over-minting bug back in April 2025. rsETH returned to the shared market a year later, which deserves stricter scrutiny.

Detection and response must operate at machine speed. When a protocol can be drained in minutes, relying solely on human intervention is governance theater. Limited automation should be the norm: anomaly detection for admin operations, mint and burn events, utilization spikes, oracle dislocations, and bridge traffic, combined with the protocol's native rate limits, borrow throttles, and narrowly scoped auto-freezes triggered by pre-agreed conditions that can be reviewed by governance afterward.

We need to start prioritizing the safety of user funds. The slight inconvenience of occasional automated triggers is far less than the cost of having none of these automations in place from the start.

Governance must define what cannot fail

To help teams backtrack security goals, governance must define what absolutely cannot fail. The board, foundation council, or DAO should explicitly list its critical business services: user deposits and withdrawals, liquidations, oracle updates, governance execution, bridge ingress and egress, frontend access, incident communication.

For each item, impact tolerances should be set, including the maximum tolerable user harm, solvency loss, downtime, and data uncertainty, and then test whether these tolerances still hold under severe but reasonable scenarios.

This is precisely what operational resilience means in banking and can be directly transplanted into DeFi.

DeFi should adopt a true Three Lines model:

• First line: Product, engineering, treasury, and operations are responsible for the risks they create and the controls to mitigate those risks.

• Second line: Independent risk and security functions have clearly defined authority to challenge listings, parameters, upgrades, and counterparties, and to slow or block unsafe changes.

• Third line: Independent assurance reports on whether the first and second lines are truly working.

Independence is the way to prevent growth incentives from grading their own homework.

Asset onboarding should resemble credit underwriting rather than business development. Listing memos should cover liquidity and concentration, governance centralization, bridge paths and upgradability, redemption mechanisms, circuit breakers, oracle construction methods, and legal packaging. If any of these assumptions are broken, each memo needs a clear downgrade procedure.

Emergency permissions should be narrow, pre-defined in scope, and sunsetted. The Cetus and Sui recovery votes illustrate two aspects of this—emergency interventions can save hundreds of millions of dollars. It also raises serious questions: who can override those theoretically unassailable systems, and on what basis? The answer is to define trigger conditions, authorized actors, evidence standards, maximum duration, transparency obligations, and the path back to normal governance before going live, not in a crisis.

Every protocol needs to have a resolution plan ready before a crisis occurs. Drift is retroactively forming a recovery pool. Aave turned to compensating users after the oracle misalignment. Resolv compensated holders at a 1:1 ratio before the hack. These are all reasonable responses, but a higher standard is pre-authorized waterfalls: first user protection, then treasury buffer, followed by insurance or safety modules, then service-provider liability, and setting clear thresholds for socialized loss.

Distinguishing protocols that take governance seriously from those that do not involves three questions: Who can stop an unsafe launch? Who can freeze the market under predefined conditions? When a delegated service provider causes a loss, who pays?

A protocol that cannot articulate relevant personnel, trigger conditions, and liability pathways has not defined its governance properly; it is merely praying that an exploit will never occur.

Risk data determines the success or failure of controls

Safe DeFi requires a live data plane: onchain and offchain signals that drive every freeze, cap, and liquidation control in the protocol. The control plane is responsible for action, while the data plane tells the control plane whether it should act.

Data standards are as important as the data itself. Data input into oracles, freezes, and parameter changes requires clear freshness windows, documented provenance, confidence scoring, and cross-validation with independent feeds. When feeds diverge, fallback behaviors must be predefined, not decided on the fly.

Aave's proposed risk-managed oracle for USDe 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 its own configuration errors.

Disclosure itself is a form of control. Users should have a public status page, an attacker-address watchlist, a real-time incident log, a quick and factually clear initial statement, and a post-mortem that distinguishes confirmed facts from assumptions, accurately quantifies losses, lists changed controls, and explains the compensation path. Drift's recovery update, Resolv's post-mortem, and Aave's oracle explanation are all far better than the past DeFi practice of going silent after vague tweets. The industry standard should be a communication playbook that has been rehearsed before it is needed.

The purpose of risk data is to drive action. Rate-limited lending, lowering caps, pausing markets, escalating to manual handling, proving that a market can safely continue to operate. Analytics that cannot be input into control, limit, or assurance processes do not deserve the title of risk infrastructure.

The AI threat model has changed

The AI threat model changed in April 2026. Anthropic's Claude Mythos Preview has proven capable of identifying and exploiting zero-day vulnerabilities in all mainstream operating systems and browsers. Over 99% of the vulnerabilities it discovered remain undisclosed because no one has patched them yet. Banks and regulators in the UK, US, and Germany have already regarded Mythos-level capabilities as real-world cyber risks.

DeFi protocols should do the same.

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

• Developer workstations should be hardened like privileged endpoints

• Code reviews should include AI-assisted adversarial analysis under controlled access

• Signer workflows should default to anti-phishing capabilities

• Anomaly detection and limited auto-responses should assume that the attacker's iteration speed far exceeds any human team

The story of Kelp is actually a more optimistic version of this. The same AI capabilities that threaten protocols can also defend them. An open-source auditing tool running on Claude Code flagged Kelp's precise risk surface twelve days before the hack. This tool is not perfect: it rated the risk as medium when it should have been critical; it cannot penetrate the configuration layer without onchain verification; and it also missed the point that the DVN configuration can actually be queried on-chain through LayerZero's EndpointV2 contracts.

But it asked the right questions that others did not.

This is the model that should be adopted going forward. AI as an independent security layer, where any LP, any protocol, or any auditor can race to move funds ahead of it.

Safe DeFi does not mean slow DeFi

The consensus view after the Kelp incident is that DeFi has security issues. I believe this framing is itself wrong.

DeFi has control plane issues, composability pricing issues, and governance discipline issues. All three have known solutions. Most of these were already written in bank risk manuals thirty years ago. The only barrier between DeFi and significantly improved user safety is whether founders will implement them.

Safe DeFi does not mean slow DeFi. Slow and safe are different attributes. User-facing open access, composability, and 24/7 global settlement; bank-level discipline in the control layer, independent challenges, machine-speed controls, and continuous assurance. Both can coexist.

The tools already exist. The playbooks already exist. The capital for safe DeFi already exists.

DeFi has only just begun. Let’s ensure it still exists a decade from now.