The on-chain DeFi world has once again seen a nine-figure security incident.
On April 18, an attacker exploited Kelp DAO’s LayerZero routing configuration—specifically a 1-of-1 DVN (Decentralized Verifier Network) setup with no optional verifiers—to forge cross-chain messages. This caused the contract to release 116,500 rsETH without proper authorization. Depending on how losses are distributed, Aave faces potential bad debt ranging from $123.7 million to $230.1 million.
This is not only the largest DeFi security incident so far in 2026—it also shatters a long-standing architectural assumption across the industry: for the sake of efficiency, liquidity, and yield, more and more security has been concentrated in a small number of implicitly trusted intermediaries.
1. Behind the Kelp DAO Incident: A Breakdown in Decentralization
If we treat the Kelp DAO incident as just another on-chain exploit, we risk underestimating the structural risk signals it exposes across DeFi.
As a liquid restaking protocol in the Ethereum ecosystem, Kelp DAO allows users to deposit ETH and receive rsETH as a receipt token. This token circulates on Ethereum mainnet and, via LayerZero’s OFT standard, is deployed across more than 20 chains, including Base, Arbitrum, Linea, Blast, Mantle, and Scroll.
In essence, the Ethereum mainnet holds the full ETH reserves, while rsETH on other chains functions as IOUs—claims on that reserve. The system relies on a critical invariant: the amount locked on mainnet must always be greater than or equal to the total rsETH minted across L2s.
The attacker effectively broke this fundamental constraint.
By forging a “valid” cross-chain message through LayerZero, the attacker tricked the mainnet bridge contract into believing a legitimate redemption request had been issued from another chain—resulting in the release of 116,500 rsETH.
The root cause lies in the verification configuration. Kelp DAO used a 1/1 DVN setup, meaning a single verifier signature was sufficient to approve a cross-chain message. In contrast, LayerZero officially recommends 2/2 or multi-verifier redundancy. The risks of a 1/1 setup had already been flagged by security researchers as early as January 2025—yet remained unaddressed for over 15 months.
This is why the incident cannot be simplistically categorized as “a bridge hack” or “insufficient protocol risk control.” It exposes two overlapping single points of failure:
- Single-point verification: DVN is designed as a composable X-of-Y-of-N model, allowing multiple independent verifiers. Yet in this case, message validity was effectively reduced to the assumption that one verifier would not fail.
- Single-point reserves: Once the mainnet reserve is compromised, rsETH on other chains immediately loses its nature as a cross-chain asset and reveals that it is fundamentally just an IOU backed by a single anchor.
When these two risks stack, the impact is no longer contained within a single protocol—it propagates outward through DeFi composability.
This is why Aave quickly froze rsETH/wrsETH markets across multiple chains, adjusted WETH interest rate models, and further froze several WETH markets. Even though Aave itself was not directly exploited, distorted collateral, impaired liquidations, and borrower health approaching liquidation thresholds still resulted in real bad debt risk.
Zooming out, this pattern—outsourcing security to a single point—extends beyond bridges and validators. It also exists in a place users interact with every day, yet rarely question: the interface.
2. From “Self-Custody of Assets” to “Verifiable Interaction”
The Web3 community has long embraced a simple principle: Don’t trust, verify.
In Ethereum’s own explanation of running a node, the idea is straightforward: by running your own node, you don’t need to trust others—you verify the data yourself instead of relying on centralized providers.
This principle applies equally to wallets and DeFi interactions.
Non-custodial wallets like imToken are essentially access tools—they are the window through which users view assets, sign transactions, and interact with applications. They do not hold user funds, nor do they control users’ private keys. Over the past few years, the importance of self-custody has become widely accepted: decentralization is not just about putting assets on-chain, but about returning control to users.
However, while we emphasize self-custody at the asset layer, we still implicitly outsource trust at the interaction layer in a more subtle way.
Users often rely on the interface to interpret transaction meaning, explain execution results, and present what they are signing. This creates a subtle but critical risk:
Are users really signing the transaction they think they are signing?
In practice, users rarely interact with the blockchain directly. Instead, they engage through multiple layers of abstraction—DApp frontends, wallet pop-ups, aggregator routes, and increasingly, AI-generated actions. These interfaces tell users things like:
- “You are depositing 100 ETH into a strategy”
- “You will receive a certain APY”
- “This is just a standard approval”
But the actual calldata being signed and executed may differ—and most users cannot independently verify it.
This explains why recurring incidents like frontend hijacking, address replacement, and malicious approval disguises all point to the same underlying issue: users are not always signing what they believe they are signing.
From this perspective, the Kelp DAO incident is not just about cross-chain validation—it also highlights another overlooked reality: interfaces themselves are a default trust assumption that is rarely verified.
When users click “Confirm,” they are effectively betting that the interface is telling the truth.
This leads to the concept of Verifiable UI.
“Verifiable UI” refers to interfaces whose displayed content can be verified against actual on-chain execution.
Its goal is not better design or clearer wording—but to establish a verifiable link between what the interface shows and what the blockchain will execute.
In other words, it aims to ensure that what is presented truly corresponds to what is about to happen on-chain. This means:
- Before signing, wallets should not only display raw hex data or frontend-generated descriptions, but reconstruct calldata into human-readable, semantically clear intent.
- Every step described by the interface should map to verifiable on-chain evidence—not rely on explanations that only hold if users choose to trust them.
- Only then can the gap between “what you think you are doing” and “what actually happens on-chain” be closed.
In such a model, the interface is no longer a black box—it becomes an auditable execution guide.
Today, verifiable UI remains an underexplored topic in DeFi. But over a longer horizon, it is likely to shift from a “nice-to-have security improvement” to a “non-negotiable baseline capability.”
Because Ethereum interaction patterns are undergoing a fundamental shift.
3. Why Verifiable UI Is Becoming the New Security Boundary
If the Kelp DAO incident reveals long-standing trust assumptions in traditional DeFi architecture, Verifiable UI corresponds to a new phase already underway.
The ETH UX map has already made current pain points clear: transaction clarity, cross-chain flow, and safety remain core challenges. Issues like blind signing, signing fatigue, bridging friction, and asset fragmentation are familiar to nearly every experienced user.
This is not simply a matter of insufficient user education—it reflects a deeper truth: In Web3, UX and security are inseparable.
In many cases, not understanding what you are signing is the biggest risk.
As interaction paradigms shift from step-by-step frontend clicks to intent-based execution, this issue will only intensify.
In traditional DApp flows, users could at least see buttons, pages, and prompts—providing some sense of process. But in the era of AI agents, this visibility collapses.
Users may simply say:
- “Swap my ETH into a more stable yield strategy”
- “Bridge to Base with controlled slippage”
- “Allow this agent to spend up to 100 USDT within 24 hours”
—and receive a “completed” result.
This dramatically improves efficiency—but also hides intermediate steps, parameters, approvals, and execution logic.
In this context, imToken has proposed two parallel directions:
- Exploring intent-based interaction, where users express goals and the system handles execution
- Advancing Unified & Verifiable UI, recognizing that the interface itself can be an attack surface
This reflects a critical shift in wallet responsibilities.
Previously, wallets were signing tools. Now, as agents become involved, wallets must act as the final deterministic checkpoint before execution.
AI can generate plans—but wallets must translate them into verifiable, enforceable, and auditable execution.
From this perspective, Verifiable UI is not just a design upgrade—it is a new security model, and a necessary piece of infrastructure for the next stage of self-custodial wallets.
The industry once emphasized: Not your keys, not your coins. In an intent-driven, agent-executed world, we must add: Your interface should also be verifiable.
Conclusion
Following the Kelp DAO incident, discussions have focused on DVN configurations, LRT risk controls, and bridge vulnerabilities.
These discussions are valuable.
But if a nine-figure incident is ultimately reduced to “misconfigured multisig,” then its deeper implications are being missed.
Today, much of DeFi’s efficiency, liquidity, and yield still rest on invisible, unverifiable single-point assumptions.
That is precisely why decentralization is not the opposite of efficiency—it is the baseline of security.
The era of building security on single points of trust needs to end.