April 22, 2026
By Arifa Khan
Six questions every governance body should answer before approving a bridged asset as collateral — yet no one is asking!
Recently, I saw a tweet that warned Aave users asking them to withdraw funds and analyse the warning later. Sure enough, we learn $290 million left DeFi yesterday, drained from Aave due to a hack that affected LayerZero. Funds left DeFi in a way that no smart contract audit could have prevented. Because the vulnerability wasn’t the contract! As DeFi space matures, the exploits are also maturing in line with the sophistication of AI to help engineer and reverse engineer anything. What is scarce is only the ability to frame the question, which anyone with adequate domain expertise can. As fears sparked by the release of Claude Mythos suggest, the days of lazy engineers and smugness in security of legacy architecture are over. AI will keep you on your toes.
The rsETH exploit — attributed by some to North Korea’s Lazarus Group — did not exploit a bug in smart contract code. It inflitrated the infrastructure.
What happened?
Bridges are essentially vulnerable, because they rely on messages between chains and chains have to trust these messages before issuing bridged assets.
Software binaries were replaced on infrastructure servers, which forced a bridge verifier onto compromised nodes via DDoS attacks of the real nodes, and used that compromised verifier to forge a cross-chain message that released 116,500 rsETH that had no backing. Within 46 minutes the exploit was complete. Within an hour that rsETH was sitting as collateral on Aave, and $266+ million in real ETH had been borrowed against it.
The vulnerability? One publicly readable on-chain variable — a 1-of-1 DVN (Decentralized Verifier Network) configuration — that the risk manager signed off on in over confidence.
This should concern every governance participant, protocol risk officer, and institutional allocator in the DeFi space.
The accountability gap that produced this exploit
Chaos Labs was paid $2.4M annually to risk-manage Aave’s collateral exposure. They approved rsETH at 75% Loan-To-Value, meaning Aave would lend 75 cents against every dollar of rsETH posted as collateral.
The DVN configuration of the rsETH bridge — the parameter that determined whether one compromised server was sufficient to forge messages worth $290 million — is readable via a single function call: getAppConfig(). It is public. It is on-chain. It requires no special access, no forensics, no technical sophistication beyond knowing the call exists.
Nobody made that call.
The reason nobody made it is structural, not individual. Chaos Labs had no financial liability for the quality of their approvals. No clawback provisions. No performance bond. No mechanism by which Aave governance could recover fees paid for approvals that produced protocol losses. The incentive was to approve collateral — because approvals grew TVL, kept the client relationship active, and maintained the contract. Rigorous due diligence that results in rejection costs deals. In the absence of downside liability, the incentive structure reliably produces under-diligence.
This is the accountability gap that the industry needs to close, and it is worth emphasizing: it is a governance design problem, not a technology problem. The technology to check DVN configurations existed before the exploit. The governance structure that would have required someone to check it did not.
Four layers that failed
The rsETH incident required four systems to fail simultaneously. Understanding each one points toward a specific fix.
1. Decentralization Fail — Decentralization as aspiration not in practice. LayerZero marketed itself as a trustless, decentralized cross-chain messaging layer. In practice, a significant share of its activity ran through DVN nodes operated by LayerZero Labs — a single company — on shared infrastructure. When that infrastructure was targeted, there was no independent verification layer to catch the forged messages. Real decentralization requires independent node operators, independent RPC providers, and genuine redundancy. It costs more to build. When decentralisation is reduced to a mere tagline, and not real redundancy — then the costs are real too!
2. Audit Fail — Audit coverage that stops at the code. Smart contract audits are valuable and necessary. They are not sufficient. The rsETH exploit bypassed audited contracts entirely — because no audit covers DVN configuration, node operator identity, RPC provider diversity, or binary integrity of validator software. The audit creates a confidence signal that governance processes treat as broader than it is. It is the entire infrastructure and the architecture that must be ascertained for robustness not a piecemeal audit of contracts. That false confidence is itself a risk factor.
3. Governance fail — Governance that rewards throughput over scrutiny. Approving collateral grew TVL and kept risk manager contracts active. Rejecting it, or demanding bridge configuration improvements as a condition of approval, required doing forensic work that no individual actor was compensated to do. Every actor in the governance chain was behaving rationally given their incentives. The aggregate result was catastrophic. Incentive design is not addressing the systemic risk or the societal cost. Tragedy of the Commons. No one is incentivised to build the dams or barriers that prevent the losses, while everyone enjoys the spoils of frothy good times.
4. OpSec Fail — Missing operational basics. SparkLend has run rolling 12-hour supply caps since 2024 — a feature that limits new deposits in any single asset per time window, calibrated to insurance fund depth. During the rsETH event however, SparkLend maintained full ETH withdrawal liquidity. Aave’s ETH markets on mainnet, Arbitrum, Plasma, Mantle, and Base locked at or near 100% utilization. A feature that has been production-validated for two years was not deployed where it was most needed. So Aave is now left with a bad debt of over $200 million.
The 47 protocols that should be reading this carefully
The rsETH configuration was not unique. At the time of this writing, dozens of protocols are running identical 1-of-1 DVN setups across LayerZero deployments: Theoriq, Orderly Network, Swell Network, Aethir, and remaining KelpDAO bridges across multiple chains, among others.
Every one of these is vulnerable to the same attack class. The prerequisite is not a novel zero-day. It is the same condition: a single DVN node that can be compromised and made to emit forged messages without independent verification catching it.
Aave v4’s new collateral framework, scheduled to go live April 30, 2026, will require proof of 3/5 DVN minimum configuration for bridged assets to remain eligible. Estimates suggest $4–6 billion in current bridged assets will face forced deleveraging unless the protocols responsible upgrade their configurations.
For protocols on this list: the time to upgrade is before your governance body gets its version of the 46-minute window. As DeFi industry matures, the attacks will grow sophisticated with novel attack vectors, so it is never sufficient to close all known attack surfaces, but one needs to be vigilant and actively surveil new vulnerabilities, and set aside sufficient bounties and respect warnings from hackers who care to warn. Protocols are foolish to dismiss or taunt them with — “Exploit if you can”.
Six questions governance should require before any bridged asset approval
None of these require novel technology. Every one of them could have been answered before the rsETH approval vote. The checklist is a governance decision, not an engineering decision.
1. What is the DVN configuration? Run getAppConfig() on the OFT contract. If the answer is 1-of-1 or 2-of-2 with a single operator, the application should be rejected or contingent on configuration upgrade. Table stakes: 3-of-5 minimum with genuinely independent operators.
2. Are the DVN operators actually independent? Node count is not the same as operator independence. Three nodes from the same company with different labels is a 1-of-1 security model. Verification should confirm separate corporate entities, separate RPC infrastructure providers, separate jurisdictions.
3. Has a bridge security audit been conducted? A smart contract audit is not a bridge security audit. The latter should cover DVN configuration, operator identity, RPC provider diversity, binary integrity attestation, and deployment key management. If this audit has not been published, it should be required as a condition of approval.
4. Does the lending protocol have rolling supply caps for this asset? Maximum new deposits per asset per time window, calibrated to insurance fund depth. Not a risk reduction — a risk ceiling. If this is not in place, the governance body should be approving not just the asset but the operational change required to deploy it safely.
5. Are circuit breakers in place? Protocol-level pauses triggered by anomaly detection — unusual deposit velocity, oracle price deviation, correlated activity across multiple asset markets. If not, the gap between detection and response in the event of an exploit will be measured in losses, not minutes.
6. Is the protocol’s frontend deployed with ENS+IPFS, or is it DNS-dependent? DNS hijacking requires no smart contract exploit. It requires controlling a DNS record for a few hours. ENS+IPFS deployment with governance-linked content hash attestation closes this attack surface. If the answer to this question is “we use a standard CDN with centralized DNS,” the attack surface is the frontend, not the contracts.
What institutional participants should be asking right now
For anyone allocating capital to DeFi protocols or evaluating them as counterparties: the rsETH incident just gave us a due diligence checklist.
The questions above are the minimum.
Beyond them:
- Does the protocol have a published security council with defined emergency pause authority?
- Does it publish time-to-response metrics for past security incidents?
- Does the risk manager have performance bond provisions in their contract?
- Are supply cap parameters published and independently verifiable?
- Has the insurance fund depth been disclosed relative to current TVL?
These are questions that institutional participants in traditional finance ask as a matter of standard practice. DeFi protocols competing for institutional allocation should expect them.
The window is open
Aave v4’s new collateral framework creates a governance-forced DVN upgrade cycle across dozens of protocols in the next weeks and months. That is a meaningful forcing function — but forcing functions produce minimum compliance, not an in-built security culture.
The industry knows what the problems are. The problems are not technically complex to fix. The constraint is whether governance structures can be redesigned to require the checklist, accountability frameworks can be built to make negligence costly, and operational primitives can be deployed before rather than after the next incident.
The only question worth asking in the aftermath of $290 million is whether this window gets used, or whether the industry waits to learn the lesson again.
This piece draws on publicly available incident documentation from LayerZero Labs, KelpDAO, Aave, and forensic analysis published by Innora.ai and DeFiPrime. Attribution to Lazarus Group is described as preliminary by LayerZero Labs. Figures are estimates based on available data as of April 20, 2026. This is not investment advice.
About the author:
Author Arifa Khan is a Web3 & AI Safety builder & researcher. She is a Pioneer of Decentralised Capital Markets and is building the capital markets automation protocol. She has filed for several patents related to AI safety, Privacy & Verification in DeFi. She will be speaking at Frontier Ai Summit Series London on 1st May & 5th June 2026.
