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

In the world of on-chain DeFi, yet another security incident involving hundreds of millions of dollars has occurred.

On April 18, an attacker exploited Kelp DAO's LayerZero routing configuration, which used a 1-of-1 DVN without optional verifiers, to forge a cross-chain message. This caused the contract to erroneously release 116,500 rsETH. Under different loss-sharing scenarios, the potential bad debt range faced by Aave was estimated between $123.7 million and $230.1 million.

Objectively speaking, 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 returns, an increasing amount of security has been quietly staked on a small number of default-trusted middle layers.

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

If the Kelp DAO incident is merely understood as a typical on-chain security mishap, its significance as a warning about the structural risks within the broader DeFi ecosystem is easily underestimated.

As a Liquid Restaking protocol within the Ethereum ecosystem, Kelp DAO theoretically allows users to deposit ETH and receive rsETH as a receipt. This receipt is not only transferable 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.

In other words, the cross-chain contract on the Ethereum mainnet holds all the ETH reserves, while rsETH on other chains are essentially just "claims" against those mainnet reserves. This means the system's viability hinges on the inviolability of the pegging relationship: the amount locked on the mainnet must always be greater than or equal to the amount minted on L2 chains.

What the attacker breached was precisely this seemingly simple yet critically fundamental constraint. They directly forged a "legitimate" LayerZero cross-chain message, tricking the mainnet bridge contract into believing it was a compliant redemption instruction from another chain, and subsequently releasing 116,500 rsETH.

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

This is why this incident is difficult to simply categorize as "a bridge being hacked" or "a protocol lacking risk controls." What it reveals is a two-layered single point of failure:

• The first layer is the verification single point: 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 the entire message for Kelp DAO was compressed into a single assumption: "this one verification node will not fail."
• The second layer is the reserve single point: Once this mainnet reserve pool is compromised, rsETH on other chains immediately cease to be genuine cross-chain assets, exposing their nature as IOUs anchored solely to a single mainnet point.

When the verification single point and the reserve single point are combined, the risk no longer remains confined to a single protocol but spills over along the composability rails of DeFi.

This explains why Aave, after the incident, urgently froze the rsETH/wrsETH markets on multiple chains, adjusted the WETH interest rate model, and further froze several WETH markets to prevent the pressure from spreading to more assets. Although Aave itself was not hacked, the distortion of collateral value, blocked liquidations, and borrowers' health factors nearing the threshold ultimately exposed the protocol to substantial bad debt risk.

Stepping back for a broader perspective, one finds that this logic of "outsourcing security to a single point" is not limited to bridges and verifiers. It also lurks in a place users interact with daily, yet is rarely discussed openly: the interface.

2. From "Asset Self-Custody" to "Verifiable Interaction": The Most Easily Overlooked Single Point of Trust

The Web3 community has a longstanding mantra: Don't Trust, Verify.

When introducing nodes, the Ethereum Foundation offers a very straightforward explanation for this phrase: Running your own node means you don't need to trust results reported by others because you can verify the data yourself, instead of outsourcing the judgment of network truth to a centralized data provider.

This principle holds equally true for wallet and DeFi interactions.

Non-custodial wallets like imToken are essentially tools for users to access their accounts. They are windows through which users "view assets, send transactions, and log into applications." The wallet itself does not custody user funds, nor does the platform hold the private keys. Over the past few years, the industry has increasingly recognized the importance of "asset self-custody," and more people understand that true decentralization means not just putting coins on the chain, but returning control of assets to the users themselves.

However, the problem lies in the fact 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 intent, 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 easily overlooked layer of risk in today's DeFi: Is the transaction the user signs truly the transaction they believe they are signing?

It can be said that in daily on-chain interactions, users almost never interact directly with the chain itself, but rather with layers of packaged interfaces: the DApp's web frontend, wallet pop-ups, path descriptions from aggregators, and, in the future, Agent-generated calls and result confirmations. These interfaces tell the user: "You are depositing 100 ETH into a strategy," "You will receive a certain APY," or "You are just performing a simple approval."

But what is the actual calldata that gets signed, broadcast, and executed on-chain? Can the average user independently verify if the frontend description strictly matches the underlying execution? The vast majority cannot.

This is why historically recurring issues like frontend hijacking, address replacement, and malicious approval disguises, while seemingly different types of security incidents, all fundamentally point to the same problem: the user does not always sign the transaction they think they are signing.

From this perspective, the Kelp DAO incident exposed not just the single-point verification problem in bridging paths. It also served 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. At the moment you click "Confirm," you are effectively staking the correctness of that call on the premise that "the interface is not lying."

This leads to the concept of "Verifiable UI."

The so-called "Verifiable UI" literally translates to a "verifiable interface." Its core aim is not to make the frontend prettier or the signature pop-ups more user-friendly, but to establish a connection between what the interface displays and the actual call executed on-chain—a connection that can be verified by the user, validated by the wallet, and traced back to after the event.

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

• Before signing, a wallet should not just present users with a string of hexadecimal data or merely relay a description generated unilaterally by the frontend. Instead, it should strive to decode the calldata into human-readable, semantically clear operational intents.
• Every step described by the interface should be mappable to verifiable evidence on the chain, rather than remaining within a logical framework of "it's valid because the user trusts it."
• Only then can the cognitive gap between "what you think you are doing" and "what is actually happening on the chain" be bridged.

Once this is achieved, the interface ceases to be a pane of glass that users must trust blindly without independent verification. It becomes more like an execution manual that the user can personally confirm and later trace back.

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

3. Why Verifiable UI Becomes the New Security Frontier

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

The ETHUX roadmap, which maps the Ethereum user experience, has clearly outlined the core pain points of today's on-chain interactions: Transaction Clarity, Cross-chain Flow, and Safety & Security remain