1. What the KelpDAO Incident Revealed
On April 18, 2026, KelpDAO's rsETH cross-chain bridge was compromised, with 116,500 rsETH tokens being fraudulently released, amounting to approximately $292 million at the time of the incident. A postmortem report by LayerZero revealed that the attacker socially engineered their way into obtaining the developer session key, tainted LayerZero Labs DVN's internal RPC that the system relied on, conducted a DDoS attack to cripple the external RPC, and manipulated the signature service to produce attestations based on incorrect data. KelpDAO had modified its verification path from a 2-of-2 to a 1-of-1 DVN. Once a single designated DVN produced a faulty attestation, the system no longer required a second independent DVN to cross-validate the same message. CrowdStrike and Mandiant attributed the event to a North Korea-affiliated group known as TraderTraitor (UNC4899) with high confidence.
Such incidents are not isolated cases. Many significant on-chain security events are often not due to a breach of cryptographic assumptions but rather stem from key compromise, data sources, validator configurations, protocol implementations, and operational permissions—systems must not only answer "Is this signature valid?" but also address "Who has the authority to sign, based on what information, and whether the state corresponding to the signature actually occurred."
An increasing number of AI agents are gaining on-chain execution capabilities through smart accounts, policy wallets, or restricted signing services. A single valid signature can only prove that a certain authorization path was invoked, without guaranteeing the reliability of the data upon which the agent acted, whether the decision aligns with established policies, or if the transaction should even occur at that moment. Verification is transitioning from merely validating the "authenticity of a signature" to ensuring that "inputs, decisions, and executions are consistent."
2. What Existing Solutions Addressed and Left Unresolved
Existing sets of solutions have each tackled a portion of the trust issues while implicitly trusting the remaining trust in different roles:
Oracle and Dispute Resolution: In systems like Polymarket, market outcomes are initially proposed by participants and only enter UMA's token-holder vote if challenged during a dispute period. The challenge lies not in the "lack of verification" but in the reliability of verification—when rules are ambiguous, real-world events have multiple interpretations, or voting power is concentrated in a few addresses, the system effectively shifts the question of "who defines facts" to another governance structure.
Cross-Chain Bridge Multisigs and DVNs: While these two have different implementation approaches, they both require the application to explicitly configure a set of validators and a threshold. After KelpDAO set up its path as a 1-of-1 DVN, the entire validation path relied on a single validation service, which, in turn, could introduce a single point of failure based on its data sources and fault-tolerance mechanisms.
MPC Custodianship: The key selling point of threshold signatures is that the key does not exist in its entirety in one place. However, the cryptographic sharding does not automatically bring about organizational decentralization. According to the Multichain team's disclosure at the time, after the founder was detained by the Chinese police, the team immediately lost access to the relevant MPC node servers, which were running on the founder's personal cloud account. Once cloud accounts, operational permissions, and emergency responses are concentrated in one person, the threshold design of MPC may still leave a single point at the organizational level.
TEE: Trusted Execution Environments can isolate code and sensitive data, but they do not eliminate trust; they simply shift the trust locus. Hardware root of trust and firmware updates usually rely on the chip manufacturer, while enclave code, upgrade permissions, and authentication policies may be controlled by the project or operator. TEE can protect the computing process but cannot automatically distribute these governance permissions.
While the failure modes of these schemes are not the same, they point to the same class of problems: the thresholds and decentralization written in the whitepaper can only constitute a real security boundary when truly implemented in data sources, account permissions, upgrade keys, and governance processes.
III. CRVA: Redesigning the Validation Rights Allocation
DeepSafe was renamed from Bool Network in 2025. CRVA carries on the technical ideas proposed by Bool Network researchers in 2022. The relevant paper was published in the IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072) and introduced a cross-chain notarization platform based on the "Evolving Hidden Committee."
The specific approach is as follows: nodes participate in random selection through Ring-VRF, selected nodes submit proofs and temporary public keys, external observers can verify their eligibility but find it difficult to identify their long-term identity. The temporarily selected committee then jointly signs through threshold MPC, where no single node can independently produce results. Critical processes such as key management run in a TEE (using Intel SGX as an example) according to the paper's design, aiming to reduce the likelihood of the host operator reading or tampering with key shares. The committee also rotates by epoch, with the new committee receiving new shares through verifiable key handover, rendering the old shares invalid. The specific rotation period is determined by the actual network parameters.
The project team also hopes to use the working state of the TEE hidden committee to make node operators unsure whether their nodes participated in a specific validation round. The extent to which this goal can be achieved depends on the live code, remote attestation, host-side metadata, and side-channel protection and does not automatically establish the conclusion of "used TEE."
However, these mechanisms address the question of "who validates and how to securely reach a consensus," but do not automatically define "what result is correct." In the context of an AI Agent, the committee still needs to draw conclusions based on pre-established policies, data sources, and executable judgment rules—if these rules themselves are flawed, the relied-upon data source is unreliable, or the validation subject itself lacks an objectively determinable answer, even the most secure committee may jointly confirm an incorrect conclusion.
CRVA seeks to reduce the risks of long-term exposure of fixed validators and the centralization of signing permissions, but it cannot completely eliminate single points of failure at the governance and implementation levels. Node admission, protocol upgrades, TEE authentication, and software security still need to undergo continuous auditing. Assuming reliable failure of old shares and sufficient independence of the new committee, rotation can shorten the attack window against a fixed signature group, but it cannot cover systemic risks such as the software supply chain or upgrade permissions.
Four, Technological Foundation and Implementation Progress
The technological lineage of CRVA can be traced back to the Bool Network paper published in Volume 17 of IEEE TIFS (2022), with a DOI of 10.1109/TIFS.2022.3209546. The protocol model, security proofs, and prototype evaluation in the paper underwent peer review, providing an academic basis for designs such as dynamic committee concealment, Ring-VRF, threshold key management, and TEE protection. It is important to note that peer review pertained to the model and implementation in the paper; how the CRVA deployed by DeepSafe aligns with the paper's scheme still needs to be assessed based on the current technical specifications, code audits, and network parameter judgments.
According to DeepSafe's disclosure in October 2025, the network had processed nearly 120 million validations by then, with over 2.65 million active accounts. The project team also stated that its ecosystem had expanded to over 70 items, involving different types such as wallet compatibility, technical integration, investment, and marketing cooperation.
In October 2025, DeepSafe announced the completion of a $3 million seed round, with investors including Antalpha Global, ViaBTC Capital, and Gate, among others1. From a timeline perspective, this round of funding mainly corresponds to technological development and ecosystem expansion post rebranding.
Five, From Validation Solutions to General Infrastructure
As blockchain infrastructure gradually modularizes, consensus, execution, data availability, interoperability, and account systems are beginning to be handled by different components. Modularization has not made the trust issue disappear but has made the security boundaries of each layer clearer—developers not only have to choose which technology to use but also have to determine who provides the security guarantee for this layer and who is responsible in case of issues. After an AI Agent obtains on-chain execution capabilities, new issues arise: Who confirms that the data it reads is trustworthy, that decisions are not overreaching, and that the final transaction aligns with user authorization? These questions do not automatically receive answers just because of a single valid signature.
DeepSafe aims to elevate the verification capability from a within-app submodule to an infrastructure that can be invoked by different protocols and AI agents — "Proof, Not Promises," replacing the executor's commitment with verifiable evidence. CRVA has already combined anonymous shuffling, threshold collaboration, and TEE into a technical roadmap; whether it can further cover scenarios such as oracle, cross-chain, and AI agent and evolve into a universal verification infrastructure will depend on the capabilities of the current network, independent audits, and the continuous accumulation of real-world integration.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
