The on-chain DeFi world has once again experienced a security incident amounting to hundreds of millions of dollars.

On April 18, attackers exploited the 1-of-1 DVN configuration of the LayerZero routing in Kelp DAO, which lacked optional verifiers, to forge cross-chain messages, causing the contract to erroneously release 116,500 rsETH. This resulted in Aave facing a potential bad debt range of approximately $123.7 million to $230.1 million under various loss-sharing scenarios.

Objectively speaking, this is not only the largest DeFi security event since 2026, but more critically, it has breached an architectural assumption that the entire industry had previously accepted: for the sake of efficiency, liquidity, and yield, increasingly more security has quietly been wagered on a handful of default-trusted intermediaries.

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

If the Kelp DAO incident is only understood as a typical on-chain security event, it is easy to underestimate its significance in highlighting the structural risks of the entire DeFi ecosystem.

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

In other words, the cross-chain contracts on the Ethereum mainnet retain all the ETH reserves, while the rsETH on other chains is essentially just a "delivery order against the mainnet reserves," which means that the premise upon which this system relies is that the relationship "the amount locked on the mainnet is always greater than or equal to the amount minted on the L2 chain" must not be broken.

What the attackers breached was precisely this seemingly simple yet critically important underlying constraint—they directly forged a "legitimate" LayerZero cross-chain message, convincing the mainnet bridge contract that it was a compliant redemption instruction from other chains, thus releasing 116,500 rsETH.

The key issue lies in LayerZero's verification setup; Kelp DAO adopted a 1/1 DVN (Decentralized Validator Network) configuration, which allows a single validation node's signature to suffice to approve a cross-chain message! However, LayerZero itself actually recommends a 2/2 or even multi-validator redundancy, and this 1/1 risk had been publicly flagged by security researchers as early as January 2025, yet it remained unchanged for 15 months!

That is why this incident is difficult to simply classify as a "bridge was hacked" or "a certain protocol's risk control was insufficient"; it reveals a layered combination of single-point risks:

• The first layer is a verification single point: DVN was theoretically designed as a composable X-of-Y-of-N security model, supporting multiple independent verifications to meet different security needs; however, the legality of the entire KelpDAO message was compressed into the assumption "one validation node does not malfunction";
• The second layer is a reserve single point: once the mainnet reserve pool is breached, rsETH on other chains immediately ceases to be a cross-chain asset, exposing its essence as merely an IOU built on a single mainnet anchor;

When the verification single point and the reserve single point are layered together, the risk is no longer confined within a single protocol but spills over along the composability of DeFi.

This is also why Aave urgently froze the rsETH/wrsETH markets on multiple chains following the incident, adjusted the WETH interest rate model, and further froze multiple WETH markets to prevent pressure from spreading to more assets. Although Aave itself was not hacked, the distortion of collateral, difficulties in liquidation, and close monitoring of borrower health ultimately led the protocol to bear substantial bad debt risk.

Moreover, raising the perspective a bit higher reveals that this logic of "outsourcing security to a single point" does not only exist in bridges and validators; it also lurks in a place that users face daily yet is rarely discussed explicitly—interfaces.

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

The Web3 community has an old saying: Don't trust, Verify.

The Ethereum official explanation of running a node for this saying is actually quite straightforward: running your own node means you do not need to trust the results presented by others, because you can verify the data yourself, rather than outsourcing your judgment of the network's truth to centralized data providers.

This principle also applies to interactions between wallets and DeFi.

Non-custodial wallets like imToken are essentially tools for users to access their accounts; they are the windows through which you "see assets, send transactions, and log into applications." The wallet itself does not custody your funds, and the private keys are not held by the platform. Over the past few years, the industry has gradually accepted the importance of "self-custody of assets," and more people have begun to understand that true decentralization is not just about putting coins on the chain but also about returning control of assets 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 covert outsourcing at the interaction level, assigning the understanding of transaction implications, judgments of call results, and trust in the authenticity of the interface to the front end right in front of us.

This precisely reveals the most easily overlooked layer of risk in today's DeFi: Is the transaction that the user signs really what they think they are signing?

In daily on-chain interactions, users are almost never facing the chain itself but rather a layer upon layer of wrapped interfaces, such as the web front end of DApps, wallet pop-ups, and path instructions given by aggregators. In the future, it will also include calls and result confirmations automatically generated by agents; they will tell you, "You are depositing 100 ETH into a certain strategy," "You will earn a certain annualized yield," "You are just making a regular authorization."

However, what is ultimately signed, broadcast, and executed on-chain is not clearly visible to most users, and they do not have the capability to independently verify whether the front-end description aligns strictly with the underlying execution.

This is also why historically recurring incidents of front-end hijacking, address replacement, and malicious authorization masquerades may superficially appear as different types of security incidents; at the core, they all point to the same problem: what users sign does not always correspond to what they think they are signing.

From this perspective, the Kelp DAO incident exposes more than just a single-point verification problem in the bridging path; it also reminds the entire industry of another long-underestimated fact: in many on-chain interactions, the interface itself is a single point of trust that is automatically trusted yet seldom verified. When you click "confirm," you are effectively betting the correctness of this call on the assumption that "the interface is not lying."

This brings forth the concept of "Verifiable UI."

"Verifiable UI," translated literally, means "verifiable interface." Its core is not to make the front end prettier or to rephrase signature pop-ups in simpler language, but rather to attempt to establish a connection that can be verified by the user, validated by the wallet, and traced back later, between the content presented by the interface and the actual execution of calls on the chain.

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

• Before signing, wallets should not only show users a string of hexadecimal data, nor should they merely relay a passage of explanation generated unilaterally by the front end; instead, they should restore calldata to human-readable, semantically clear operation intents as much as possible;
• Every step described by the interface should be able to map to verifiable evidence on-chain, rather than resting on an explanation logic where "user belief suffices";
• Only then will there no longer be an insurmountable cognitive gap between "what you think you are doing" and "what actually happens on-chain";

Once this holds true, the interface will no longer be a transparent window users must blindly trust yet cannot independently verify, but rather a manual that users can personally confirm and trace back.

Looking solely at today's DeFi, interface verifiability remains a significantly underestimated topic; however, if we extend the time scale a little, it will quickly transform from "a safety optimization worth discussing" into "a fundamental capability that cannot be delayed any longer." Because the interaction paths on Ethereum are undergoing a quiet yet profoundly significant shift.

3. Why Verifiable UI Will Become a New Security Boundary

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

The ETHUX Ethereum UX map has clearly articulated the core issues at play in today's on-chain interactions: Transaction Clarity, Cross-chain Flow, Safety & Security have always been the most critical pain points, with problems like blind signing, signing fatigue, bridging pain, and asset fragmentation being familiar to almost every veteran user.

This points to a more fundamental fact: in the on-chain world, UX and security are never two separate matters.

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

As the interaction paradigm shifts from "users clicking through steps in a DApp front end" to "users expressing intent while the system automatically completes execution," this problem will only be further amplified, not diminished.

After all, during the traditional DApp front end era, users could at least see buttons, pages, and authorization pop-ups; even if their understanding was not complete, they could at least vaguely perceive "I'm performing a few operations," "this is an authorization or a transfer," "I'm bridging or depositing."

However, once we enter the Agent era, that sense of visible process will be significantly compressed. Users will no longer individually click on Router, Bridge, Vault, or Lending Market to confirm each step of the call; instead, they are much more likely to just tell an AI wallet, "Swap my ETH for a more stable yield strategy," "Bridge to Base, control maximum slippage," "Only allow this Agent to spend 100 USDT within 24 hours," and then wait for a "completed" result.

This undoubtedly signifies a substantial increase in efficiency but also results in the paths, parameters, authorizations, and execution sequences becoming increasingly easy to fold out of users' sight. It is in this context that imToken once proposed two parallel directions: one is to continue exploring intent-based interaction paths, allowing users to express "what I want," while the system is responsible for finding paths and completing execution; the other is advancing "Unified & Verifiable UI," elevating the recognition that "the interface itself may also become an attack surface" to a long-term proposition at the product level.

This precisely touches on the critical shift in the responsibilities of the next generation of wallets.

In the past, wallets were more like signing tools, responsible for sending users' confirmations to the chain; but in the phase where Agents gradually intervene in the interaction process, wallets cannot just be a channel; they must become the final deterministic checkpoint before execution. AI can be responsible for understanding needs, generating plans, and planning paths, but wallets must ensure that these probabilistic generated results are translated into deterministic execution contents that users can verify, systems can validate, and rules can constrain.

In this sense, "Verifiable UI" does not merely correspond to a more advanced interface design concept but represents a new interaction security model. It can even be said that it is almost an essential piece of the underlying puzzle that self-custody wallets must complete as they enter the next phase.

The industry has long emphasized "Not your keys, not your coins"; but in an era where intent-driven and Agent execution are gradually becoming mainstream, we must also add: your interface should also be a verifiable interface.

Final Thoughts

After the Kelp DAO incident, a large number of discussions quickly emerged in the industry regarding DVN configurations, LRT risk control, bridging paths, and single-point risk screening.

These discussions all hold their value.

However, if an incident with a price tag of hundreds of millions of dollars is ultimately summarized as "who configured the multi-signature wrong this time," then it has not been truly understood. To put it bluntly, the efficiency, liquidity, and yield of many on-chain products today still rely on single-point assumptions that users cannot see or verify.

This is why decentralization has never been the opposite of efficiency, but rather the bottom line of security.

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。