From the Kelp DAO Incident to Verifiable UI: Why 'Verifiable Interfaces' Could Be the New Baseline for Decentralized Security?

In the on-chain DeFi world, a security incident exceeding the hundred-million-dollar mark has occurred yet again.

On April 18, an attacker exploited a 1-of-1 DVN configuration in Kelp DAO's LayerZero route, which lacked optional verifiers, to forge a cross-chain message. This caused the contract to incorrectly release 116,500 rsETH, leading to potential bad debt for Aave ranging from approximately $123.7 million to $230.1 million, depending on different loss-sharing scenarios.

Objectively, this is not only the largest DeFi security incident since 2026, but more critically, it has shattered an architectural assumption that the entire industry had previously tacitly accepted: In pursuit of efficiency, liquidity, and yield, we have quietly been shifting more and more security onto a small number of implicitly trusted middle layers.

1. Behind the Kelp DAO Incident: The Failure of Decentralization Mechanisms

If we merely interpret the Kelp DAO incident as just another on-chain security mishap, it's easy to underestimate its significance in highlighting the structural risks within DeFi.

Kelp DAO, as a Liquid Restaking protocol within the Ethereum ecosystem, theoretically allows users to deposit ETH and receive rsETH as a receipt. This receipt can not only circulate on the mainnet but is also wrapped using LayerZero's OFT standard and deployed across over 20 chains, including Base, Arbitrum, Linea, Blast, Mantle, and Scroll.

This means that the cross-chain contract on the Ethereum mainnet retains all the ETH reserves, while the rsETH on other chains are essentially just "IOUs for the mainnet reserves." Consequently, the system's viability hinges on the inviolability of the pegging relationship where "the amount locked on the mainnet is always greater than or equal to the amount minted on L2 chains."

What the attacker breached was precisely this seemingly simple yet critically fundamental constraint. He directly forged a "legitimate" LayerZero cross-chain message, convincing the mainnet bridge contract that it was a compliant redemption instruction from another chain, and thereby released 116,500 rsETH.

The crux of the issue lies in LayerZero's verification configuration. Kelp DAO used a 1/1 DVN (Decentralized Verifier Network) configuration, meaning a single verifier node's signature was sufficient to approve a cross-chain message! LayerZero officially recommends a 2/2 configuration or even multiple verifier redundancy. The risk of this 1/1 setup was publicly highlighted by security researchers as early as January 2025, yet it remained unaddressed for 15 months.

This is why this incident is difficult to simply categorize as a "bridge hack" or "poor protocol risk management." It exposes a two-tiered, compounded single point of failure:

• First Tier: Single Point of Verification. The DVN is theoretically designed as a composable X-of-Y-of-N security model, supporting multiple independent verifications to meet different security needs. However, the legitimacy of an entire message for KelpDAO was compressed into a single assumption: "that one verifier node does not fail."
• Second Tier: Single Point of Reserve. Once this mainnet reserve pool is compromised, the rsETH on other chains instantly cease to be cross-chain assets, revealing their true nature as IOUs anchored solely to a single mainnet point.

When a single point of verification overlaps with a single point of reserve, the risk no longer remains confined to a single protocol but cascades outward along DeFi's composability.

This is precisely why Aave, post-incident, urgently froze the rsETH/wrsETH markets on multiple chains, adjusted the WETH interest rate model, and subsequently froze several WETH markets to prevent the stress from spreading to more assets. Although Aave itself wasn't hacked, the distorted collateral value, blocked liquidations, and borderline borrower health scores ultimately subjected the protocol to substantial bad debt risk.

If we zoom out further, we find that this logic of "outsourcing security to a single point" doesn't only exist in bridges and verifiers; it also lurks in a place users interact with daily but rarely discuss critically—the interface.

2. From "Self-Custody of Assets" to "Verifiable Interactions": The Most Overlooked Single Point of Trust

The Web3 community has an old adage: Don't Trust, Verify.

When introducing nodes, the Ethereum Foundation offers a very straightforward explanation: running your own node means you don't have to trust the results others tell you, because you can verify the data yourself, instead of outsourcing the judgment of the network's truth to a centralized data provider.

This principle holds true for wallet interactions with DeFi as well.

A non-custodial wallet like imToken is essentially a tool for users to access their accounts—a window through which you "see assets, send transactions, and log into applications." The wallet itself does not custody your funds, nor does the platform hold your private keys. Over the past few years, the industry has gradually come to accept the importance of "self-custody of assets," and more people understand that true decentralization isn't just about putting coins on-chain, but about returning asset control to the users themselves.

However, the problem is that while we increasingly emphasize "self-custody" at the asset level, we still largely default to a more subtle form of outsourcing at the interaction level. We outsource the understanding of transaction semantics, the judgment of call results, and the trust in the interface's authenticity to the front-end layer we see.

This is precisely the most overlooked risk in DeFi today: Is the transaction the user signs really the transaction they think they are signing?

It can be said that in daily on-chain interactions, users almost never face the chain itself, but rather a series of packaged interfaces: the DApp's web front-end, the wallet pop-up, the route explanation from an aggregator, and in the future, even calls and result confirmations generated by Agents. These interfaces tell you: "You are depositing 100 ETH into a strategy," "You will earn a certain APY," "You are just making a simple approval."

But what is the actual calldata that gets signed, broadcast, and executed on-chain? Is the front-end description strictly consistent with the underlying execution? The vast majority of users lack the ability to independently verify this.

This is why historically, repeated incidents like front-end hijacking, address replacement, and malicious approval camouflage, while appearing as different types of security accidents, all fundamentally point to the same issue: the transaction the user signs is not always the transaction they believe they are signing.

From this perspective, the Kelp DAO incident exposes not just the single-point verification problem in the bridging path. It also serves as a timely reminder to the entire industry of another long-underestimated fact: in many on-chain interactions, the interface itself is a single point that is trusted by default but rarely verified. The moment you click "Confirm," you are essentially betting the correctness of that call on the assumption that "the interface is not lying."

This leads us to the concept of "Verifiable UI."

The core of a "Verifiable UI" is not about making the front-end prettier or the signature pop-ups more user-friendly. Instead, it aims to establish a connection between what the interface presents and the actual call executed on-chain—a connection that users can verify, wallets can validate, and can be traced after the fact.

In other words, it seeks to solve not the problem of "whether information is displayed," but "whether the displayed information truly corresponds to what is about to happen on-chain." This means:

• Before signing, a wallet should not just show users a string of hexadecimal data or simply relay a description generated unilaterally by the front-end. It should strive to decode the calldata into a human-readable, semantically clear operation intent.
• Every step described by the interface should be mappable to verifiable evidence on-chain, rather than remaining within a logic framework that only holds true as long as "the user trusts it."
• Only then can the cognitive gap between "what you think you are doing" and "what actually happens on-chain" be bridged.

When this is achieved, the interface is no longer a pane of glass that users can only trust by default but cannot independently verify. Instead, it becomes an execution manual that users can personally confirm and later trace back.

Looking at DeFi today, interface verifiability remains a severely underestimated topic. But if we extend the timeline slightly, it will quickly evolve from a "security optimization worth discussing" into a "fundamental capability that can no longer be delayed." This is because the interaction paradigm for Ethereum is undergoing a quiet but profoundly significant migration.

3. Why Verifiable UI is Becoming the New Security Frontier

If the Kelp DAO incident exposed the long-standing single-point trust issues within the older DeFi architecture, then "Verifiable UI" corresponds to a new phase that has already begun to arrive.

The ETHUX map of Ethereum user experience has already clearly charted the core pain points of today's on-chain interactions. Transaction Clarity, Cross-chain Flow, and Safety & Security consistently remain the most critical pain points. Issues like blind signing, signing fatigue, bridging pain, and asset fragmentation are all too familiar to almost any veteran user.

This indicates not that "user education is insufficient," but a more fundamental truth: in the on-chain world, UX and security have never been separate things.

In other words, often, not understanding is the biggest security risk itself.

As the interaction paradigm shifts from "users clicking step-by-step in a DApp front-end" to "users expressing intent, and the system automatically executing," this problem will only be amplified, not diminished.

In the traditional DApp front-end era, users could at least see buttons, pages, and approval pop-ups. Even if their understanding was incomplete, they could vaguely perceive "I am performing several steps," "this is an approval or a transfer," "I am bridging or depositing."

But once we enter the Agent era, this visible sense of process will be greatly compressed. Users will no longer click through Router, Bridge, Vault, and Lending Market interfaces to confirm each step. Instead, they will likely just say to an AI wallet: "Swap my ETH for a more stable yield strategy," "Bridge to Base with max slippage control," "Allow this Agent to spend only 100 USDT within 24 hours," and then wait for a "Completed" result.

This naturally implies a huge leap in efficiency, but it also means that the intermediary path, parameters, approvals, and execution order become increasingly folded out of the user's sight. It is against this backdrop that imToken has proposed two parallel directions: one is to continue exploring intent-based interaction paths, where users only express "what they want," and the system is responsible for finding the path and completing the execution; the other is to advance a "Unified & Verifiable UI," elevating the fact that "the interface itself can become an attack surface" into a long-term product proposition.

This highlights the most critical change in the role of the next-generation wallet.

In the past, the wallet was more like a signing tool, responsible for sending the user's confirmation action to the chain. As Agents gradually become involved in the interaction flow, the wallet cannot just be a channel; it must become the final checkpoint of certainty before execution. The AI can be responsible for understanding requirements, generating plans, and planning routes, but the wallet must be responsible for translating these probabilistic generation results into deterministic execution content that users can verify, systems can validate, and rules can constrain.

In this sense, "Verifiable UI" truly corresponds not to a more advanced interface design concept, but to a new interactive security model. It could even be said that it is a foundational piece of the puzzle that self-custodial wallets almost inevitably need to fill as they enter the next stage.

The industry has long emphasized "Not your keys, not your coins." But in an era where intent-driven and Agent-executed interactions are becoming mainstream, we must add another line: Your interface should also be an interface you can verify.

Final Thoughts

Following the Kelp DAO incident, the industry quickly saw a flurry of discussions regarding DVN configuration, LRT risk management, bridging paths, and single-point risk audits.

These discussions all have their value.

But if an incident costing hundreds of millions of dollars is ultimately summarized only as "who misconfigured the multi-sig this time," then it hasn't truly been understood. To put it bluntly, the efficiency, liquidity, and yield of many on-chain products today still rest upon single-point assumptions that users cannot see and cannot verify.

This is precisely why decentralization has never been the enemy of efficiency, but the baseline of security.

The era of building security on single-point assumptions truly needs to end.