On April 18, 2026, KelpDAO's rsETH cross-chain bridge was attacked, resulting in the abnormal release of 116,500 rsETH, valued at approximately $292 million at the time. According to LayerZero's incident report, the attacker obtained the developer's session key through social engineering, poisoned the internal RPC relied upon by the LayerZero Labs DVN, and suppressed external RPCs with a denial-of-service attack, causing the signing service to issue proofs for forged messages based on erroneous data. At that time, KelpDAO had changed its verification path from a 2-of-2 to a 1-of-1 DVN configuration. Once the sole designated DVN issued an erroneous proof, the system no longer required a second independent DVN for cross-verification of the same message. CrowdStrike and Mandiant attributed the incident with high confidence to the North Korea-linked TraderTraitor (UNC4899).
Such incidents are not isolated cases. Many major on-chain security incidents often stem not from the overturning of cryptographic assumptions themselves, but from issues in key control, data sources, verifier configuration, protocol implementation, and operational permissions—the system must answer not only "Is this signature valid?" but also "Who has the authority to sign, on what information is the signing based, and does the state corresponding to the signature truly occur?"
An increasing number of AI Agents are gaining on-chain execution capabilities through smart accounts, policy wallets, or restricted signing services. A valid signature can only prove that a certain authorized path was invoked; it cannot prove that the Agent's data is reliable, its decision aligns with established policies, or that the transaction itself should have occurred at that moment. The object of verification is expanding from "signature authenticity" to "consistency among input, decision, and execution."
II. What Existing Solutions Solve and What They Leave Behind
Existing sets of solutions each address part of the trust problem, but also leave the remaining trust to different roles:
Oracles and Dispute Resolution: Polymarket's market outcomes are first proposed by participants and only enter UMA's token holder voting for arbitration if challenged within the challenge period. The problem is not the "lack of review," but the reliability of the review—when rules are ambiguous, real-world events have multiple interpretations, or voting power is concentrated among a few addresses, the system essentially hands the question of "who defines the facts" to another governance structure.
Cross-Chain Bridge Multisig and DVNs: While implemented differently, both require application-side explicit configuration of verifier sets and thresholds. After KelpDAO configured its path to 1-of-1 DVN, the entire verification path relied on a single validation service; the data sources and fault response mechanisms relied upon by that service could then form the next layer of single point of failure.
MPC Custody: The selling point of threshold signatures is that the key never exists fully in one place, but cryptographic sharding does not automatically bring organizational decentralization of power. According to disclosures from the Multichain team at the time, after the founder was detained by Chinese police, the team lost access to the relevant MPC node servers, which were running on the founder's personal cloud account. When cloud accounts, operational permissions, and emergency response are concentrated in one individual, the threshold design of MPC can still leave a single point of failure at the organizational level.
TEE: Trusted Execution Environments can isolate code and sensitive data, but they do not eliminate trust; they merely shift the trust anchor. Hardware root of trust and microcode updates typically rely on chip manufacturers, while enclave code, upgrade permissions, and attestation policies may be controlled by the project or operator. TEE can protect the computation process but does not automatically decentralize these governance permissions.
The failure modes of these solutions differ, yet they point to the same type of problem: the thresholds and decentralization written in whitepapers only constitute a real security boundary when they are genuinely implemented in data sources, account permissions, upgrade keys, and governance processes.
III. CRVA: Redesigning the Allocation of Verification Rights
DeepSafe was renamed from Bool Network in 2025. CRVA continues the technical direction proposed by Bool Network researchers in 2022. The related paper was published in IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072), proposing a cross-chain notarization platform based on an "evolving hidden committee."
The specific approach is: Nodes participate in random selection via Ring-VRF, selected nodes submit proofs and temporary public keys, and external observers can verify their eligibility but find it difficult to identify their long-term identities. The selected temporary committee then signs collectively through threshold MPC, preventing any single node from independently producing the result. Critical processes like key management are designed to run in TEE (using Intel SGX as an example) to reduce the possibility of the host operator reading or tampering with key shares. The committee also rotates by epoch; a new committee obtains new shares through verifiable key handover, and old shares become invalid, with the specific rotation period determined by actual network parameters.
The project also aims to leverage TEE to conceal the working status of the committee, making it difficult for node operators to determine if their node participated in a particular verification. To what extent this goal can be achieved depends on production code, remote attestation, host-side metadata, and side-channel protections; it is not a conclusion automatically guaranteed by "using TEE."
However, these mechanisms address "who verifies and how to securely produce results collectively," not automatically "what result is correct." In the context of AI Agents, the committee must still draw conclusions based on predefined policies, data sources, and executable judgment rules—if these rules themselves are flawed, the data sources are unreliable, or the object of verification lacks an objectively determinable answer, even the most secure committee may collectively confirm an erroneous conclusion.
CRVA attempts to mitigate risks arising from long-term exposure of fixed verifiers and centralized signing authority, but cannot completely eliminate single points of failure at the governance and implementation levels. Node admission, protocol upgrades, TEE attestation, and software security still require continuous auditing. Under the premise of reliable invalidation of old shares and sufficient independence of new committees, rotation can shorten the attack window targeting a fixed signing group but cannot cover systemic risks like software supply chains or upgrade permissions.
IV. Technical Foundation and Progress
The technical lineage of CRVA can be traced back to the Bool Network paper published in IEEE TIFS Volume 17 (2022), DOI: 10.1109/TIFS.2022.3209546. The protocol model, security proofs, and prototype evaluation in the paper underwent peer review, providing academic basis for designs such as dynamic hidden committee, Ring-VRF, threshold key management, and TEE protection. It is important to distinguish that peer review addressed the model and implementation in the paper; how DeepSafe's currently deployed CRVA corresponds to the paper's proposal still requires judgment based on the current technical specifications, code audits, and network parameters.
According to DeepSafe's disclosure in October 2025, the network had cumulatively processed nearly 120 million verifications by then, with over 2.65 million active accounts. The project also stated it had established over 70 ecosystem relationships involving different types such as wallet compatibility, technical integration, investment, and market partnerships.
In October 2025, DeepSafe announced the completion of a $3 million seed round, with investors including Antalpha Global, ViaBTC Capital, and Gate. Timeline-wise, this round of financing primarily corresponds to post-rebranding technology development and ecosystem expansion.
V. From Verification Solutions to General-Purpose Infrastructure
As blockchain infrastructure gradually modularizes, consensus, execution, data availability, interoperability, and account systems are beginning to be handled by different components. Modularization does not make trust problems disappear but makes the security boundaries of each layer clearer—developers must not only choose which technology to use but also determine who provides the security guarantee for this layer and who bears responsibility when problems arise. After AI Agents gain on-chain execution capabilities, new questions emerge: Who confirms that the data they read is trustworthy, their decisions do not overstep authority, and the final transaction aligns with user authorization? These questions are not automatically answered by a single valid signature.
DeepSafe hopes to abstract verification capability from an ancillary module within a single application into infrastructure that can be invoked by different protocols and AI Agents—"Proof, Not Promises," replacing the executor's promises with verifiable evidence. CRVA has already combined anonymous selection, threshold collaboration, and TEE into a technical path; whether it can further cover different scenarios like oracles, cross-chain, and AI Agents, and evolve into general-purpose verification infrastructure, will depend on the continuous accumulation of production capabilities, independent audits, and real-world integrations.
This article is contributed and does not represent the views of BlockBeats.
