From the Kelp DAO incident to Verifiable UI: Why is "Verifiable Interface" the new decentralized security baseline?

On-chain DeFi world, once again, a security incident involving over one hundred million dollars has occurred.

On April 18th, an attacker exploited the LayerZero routing in Kelp DAO with a 1-of-1 DVN configuration and no optional verifiers, forging cross-chain messages that caused the contract to erroneously release 116,500 rsETH, resulting in a potential bad debt range for Aave of approximately $123.7 million to $230.1 million under different loss-sharing scenarios.

Objectively speaking, this is not only the largest DeFi security incident since 2026 but also critically exposes a previously accepted architectural assumption in the industry: For efficiency, liquidity, and yield, more and more security is quietly being bet on a few default-trusted intermediary layers.

1. The Collapse of Decentralization Behind the Kelp DAO Incident

If you only interpret the Kelp DAO incident as a typical on-chain security mishap, it’s easy to underestimate its warning significance for the entire DeFi structural risk.

Kelp DAO, as a liquid restaking protocol within the Ethereum ecosystem, theoretically allows users to deposit ETH and receive rsETH as proof. This proof can circulate on the mainnet and, after being wrapped into LayerZero’s OFT standard, be deployed across more than 20 chains including Base, Arbitrum, Linea, Blast, Mantle, Scroll, etc.

In other words, the cross-chain contracts on the Ethereum mainnet hold all ETH reserves, while rsETH on other chains is essentially just “redeem tickets” against the mainnet reserves. This also means that the fundamental premise for this system’s operation is that the “mainnet lock-in amount always remains greater than or equal to the total minted on L2 chains,” an anchoring relationship that must not be broken.

The attacker exploited precisely this seemingly simple yet extremely critical underlying constraint — forging a “legitimate” LayerZero cross-chain message that convinced the mainnet bridge contract it was a compliant payout instruction from another chain, thus releasing 116,500 rsETH.

The core issue lies in LayerZero’s verification configuration: Kelp DAO used a 1/1 DVN (decentralized validator network) setup, which means a single validator’s signature is enough to approve a cross-chain message! LayerZero’s official recommendation is actually 2/2 or even multi-validator redundancy. This 1/1 risk was publicly warned by security researchers as early as January 2025, yet it remained unmodified for 15 months!

This is why this incident cannot simply be categorized as “a bridge hack” or “insufficient protocol risk control.” It reveals two layers of single-point risk stacking:

• The first layer is verification single point: DVN is theoretically designed as a composable X-of-Y-of-N security model, supporting multiple independent validations to meet different security needs. But in Kelp DAO, the entire message validity was compressed into the assumption that “a single validator does not issue a problem.”
• The second layer is reserve single point: if this mainnet reserve pool is compromised, rsETH on other chains immediately ceases to be a cross-chain asset and instead exposes its nature as an IOU built solely on a single mainnet anchor.

When verification single point and reserve single point are combined, the risk no longer stays within a single protocol but can spill over along the entire DeFi composability chain.

This is also why, after the incident, Aave urgently froze rsETH/wrsETH markets across multiple chains, adjusted WETH interest rate models, and further froze several WETH markets to prevent pressure from spreading to more assets. Although Aave itself was not hacked, collateral distortions, liquidation blockages, and borrower health margins pushed the protocol into substantial bad debt risk.

Looking at a higher level, this “outsourcing security to a single point” logic is not limited to bridges and validators but also lurks in a place users face daily yet rarely discuss openly — the interface.

2. From “Asset Self-Custody” to “Interaction Verifiability”: The Overlooked Single Point of Trust

The Web3 community has long held the saying: Don’t trust, Verify.

Ethereum’s official explanation of running nodes is straightforward: operating your own node means you don’t need to trust others’ results because you can verify the data yourself, rather than outsourcing judgment of the network’s truth to centralized data providers.

This principle applies equally to wallet and DeFi interactions.

Non-custodial wallets like imToken are fundamentally tools for users to access their accounts — a window to “see assets, send transactions, log into apps.” The wallet itself does not custody your funds, nor does it hold your private keys. Over recent years, the industry has increasingly recognized the importance of “asset self-custody,” and more people understand that true decentralization is not just about putting coins on-chain but also about returning control of assets to the user.

However, the problem is that while we emphasize “self-custody” at the asset level, at the interaction layer, we still largely default to a more covert outsourcing: trusting the front-end to interpret transaction meaning, call results, and interface authenticity.

This is precisely the most overlooked layer of risk in today’s DeFi: Does the user’s signature truly correspond to the transaction they think they are signing?

In daily on-chain interactions, users are almost never facing the chain itself but rather a series of layered, wrapped interfaces — such as DApp web frontends, wallet pop-ups, aggregator route explanations, and in the future, agent-generated calls and result confirmations. These will tell you: “You are depositing 100 ETH into a strategy,” “You will earn a certain annualized yield,” “You are just doing a normal approval.”

But what exactly is the calldata being signed, broadcasted, and executed on-chain? Do the front-end descriptions match the underlying execution strictly? Most users lack the ability to verify independently.

This is why, throughout history, front-end hijacking, address replacement, malicious authorization, and impersonation attacks, though seemingly different, all point to the same core issue: the user’s signature does not always correspond to what they think they are signing.

From this perspective, the Kelp DAO incident not only exposes a single-point verification flaw in the bridge path but also highlights a long-underestimated fact: in many chain interactions, the interface itself is a default-trusted, rarely-verified single point. The moment you click “Confirm,” you are essentially betting that the interface is truthful.

This leads to the concept of “Verifiable UI.”

3. Why Verifiable UI Will Become the New Security Boundary

If the Kelp DAO incident revealed a long-standing single-point trust problem in the old DeFi architecture, then “Verifiable UI” corresponds to a new phase that has already begun.

Ethereum UX map (ETHUX) has clearly outlined the core pain points: Transaction Clarity, Cross-chain Flow, Safety & Security. Issues like blind signing, signing fatigue, bridging pain, asset fragmentation are familiar to almost every veteran user.

This indicates that the problem isn’t just “user education,” but a more fundamental truth: in the on-chain world, UX and security have never been two separate things.

In other words, the inability to understand what you are doing is itself the greatest security risk.

As interaction paradigms shift from “users click step-by-step in DApp frontends” to “users express intent, system automatically executes,” this problem will only intensify.

In traditional DApp frontends, users can at least see buttons, pages, approval pop-ups. Even if their understanding is incomplete, they can vaguely perceive: “I am doing several steps,” “This is an approval or a transfer,” “I am cross-chain or depositing.”

But in the Agent era, this visibility will be greatly reduced. Users will no longer open Router, Bridge, Vault, Lending Market step-by-step to verify each call. Instead, they might just tell an AI wallet: “Swap my ETH for a more stable yield,” “Cross to Base with max slippage,” “Allow this Agent to spend 100 USDT within 24 hours,” and then wait for a “completed” result.

This greatly improves efficiency but also makes the intermediate paths, parameters, authorizations, and execution sequences increasingly invisible to the user. In this context, imToken has proposed two parallel directions: one is to explore intent-based interaction paths, where users only specify “what I want,” and the system finds the path and executes; the other is to promote “Unified & Verifiable UI,” explicitly elevating “interface as a potential attack surface” to a product-level long-term goal.

This points to the most critical role change for next-generation wallets.

In the past, wallets were mainly signature tools, responsible for sending user confirmations to the chain. As Agent-based interactions become mainstream, wallets can no longer be just channels but must serve as the final deterministic checkpoint before execution. AI can understand needs, generate plans, and design paths, but wallets must translate these probabilistic outputs into verifiable, system-checked, rule-constrained executable instructions.

In this sense, “Verifiable UI” is not just a more advanced interface concept but a new interaction security model — arguably, a fundamental piece that self-custody wallets will almost inevitably need to complete in the next phase.

The industry has long emphasized “Not your keys, not your coins,” but in an era where intent-driven and agent-executed interactions dominate, a new phrase is needed: your interface should also be verifiable.

Final Words

After the Kelp DAO incident, many discussions emerged around DVN configurations, LRT risk controls, bridging path risks, and single-point risk screening.

These discussions are valuable.

But if a multi-hundred-million-dollar incident is ultimately summarized as “someone misconfigured multisig,” then it’s not truly understood. Frankly, many on-chain products today still rely on single-point assumptions for efficiency, liquidity, and yield, which users cannot see or verify.

This is why decentralization has never been opposed to efficiency but is fundamentally a security baseline.

The era of building security on single-point assumptions must come to an end.