When AI Agents Gain On-Chain Execution: Who Verifies the Information They See and the Commands They Issue?

More and more AI agents are gaining on-chain execution capabilities through smart accounts, policy wallets, or restricted signing services.

I. What the KelpDAO Incident Exposed

On April 18, 2026, KelpDAO's rsETH cross-chain bridge was attacked, and 116,500 rsETH were abnormally released, worth approximately $292 million at the time. LayerZero's incident report showed that the attacker obtained developer session keys through social engineering, poisoned the internal RPC relied upon by 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 incorrect data. KelpDAO had changed the verification path from 2-of-2 to 1-of-1 DVN. Once the sole designated DVN issued an incorrect proof, the system no longer required a second independent DVN to cross-verify the same message. CrowdStrike and Mandiant attributed the incident with high confidence to North Korea-linked TraderTraitor (UNC4899).

Such incidents are not isolated. In many major on-chain security events, the problem often lies not in the cryptographic assumptions being overturned, but in key control, data sources, validator configuration, protocol implementation, and operational permissions—the system must answer not only "is this signature valid?" but also "who is authorized to sign, based on what information, and whether the state corresponding to the signature actually occurred."

More and more AI agents are gaining on-chain execution capabilities through smart accounts, policy wallets, or restricted signing services. A valid signature only proves that a certain authorization path was invoked; it cannot prove that the data the agent relied on is reliable, that the decision complies with established policies, or that the transaction 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 solutions each address part of the trust problem, and each places the remaining trust in different roles:

Oracles and dispute resolution: Polymarket's market outcomes are first proposed by participants, and only enter UMA's token holder voting resolution if challenged during the challenge period. The problem is not "lack of review," but whether the review is reliable—when rules are ambiguous, real-world events have multiple interpretations, or voting power is concentrated in a few addresses, the system effectively hands the question of "who defines the facts" to another governance structure.

Cross-chain bridge multisig and DVN: The two differ in implementation, but both require the application to explicitly configure the validator set and threshold. After KelpDAO configured the path as 1-of-1 DVN, the entire verification path depended on a single verification service; and the data sources and failure response mechanisms that service relies on may form another layer of single point of failure.

MPC custody: The selling point of threshold signatures is that the key never exists in full in one place, but cryptographic sharding does not automatically bring organizational decentralization. According to disclosures by the Multichain team at the time, after the founder was detained by Chinese police, the team immediately lost access to the relevant MPC node servers, which were running under the founder's personal cloud account. If cloud accounts, operational permissions, and emergency response are concentrated in one person, MPC's threshold design may still leave an organizational single point of failure.

TEE: Trusted execution environments can isolate code and sensitive data, but they do not eliminate trust; they only change where trust is placed. Hardware root of trust and microcode updates typically depend on the chip manufacturer, while enclave code, upgrade permissions, and attestation policies may be controlled by the project or operator. TEE can protect the computation process, but cannot automatically decentralize these governance permissions.

These solutions have different failure modes, but they point to the same type of problem: the thresholds and decentralization written in whitepapers only constitute real security boundaries when they are actually implemented in data sources, account permissions, upgrade keys, and governance processes.

III. CRVA: Redesigning the Distribution of Verification Authority

DeepSafe was renamed from Bool Network in 2025. CRVA continues the technical approach proposed by Bool Network-related 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 through Ring-VRF, and 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 selected temporary committee then jointly signs through threshold MPC, and no single node can independently produce the result. Key management and other critical processes run in TEE (using Intel SGX as an example) according to the paper's design, aiming to reduce the possibility of the host operator reading or tampering with key shares. The committee also rotates by epoch, with the new committee obtaining new shares through verifiable key handover and old shares becoming invalid; the specific rotation period is determined by actual network parameters.

The project also hopes to use TEE to hide the committee's working status, making it difficult for node operators to determine whether their node participated in a particular verification. The extent to which this goal can be achieved depends on the live network code, remote attestation, host-side metadata, and side-channel defenses; it is not a conclusion that automatically holds just because "TEE is used."

But these mechanisms address "who verifies and how to securely jointly produce results," and do not automatically define "what result is correct." In the AI agent scenario, the committee still must reach conclusions based on pre-set policies, data sources, and executable judgment rules—if these rules themselves are flawed, the data sources relied upon are unreliable, or the verification object has no objectively determinable answer, even the most secure committee may jointly confirm an incorrect conclusion.

CRVA attempts to reduce the risks of long-term exposure of fixed validators and concentration of signing authority, but cannot completely eliminate single points at the governance and implementation levels. Node admission, protocol upgrades, TEE attestation, and software security still require continuous auditing. Under the premise that old shares reliably become invalid and the new committee remains sufficiently independent, rotation can shorten the attack window against a fixed signing group, but cannot cover systemic risks such as software supply chain or upgrade permissions.

IV. Technical Foundation and Implementation Progress

CRVA's technical lineage 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 committees, Ring-VRF, threshold key management, and TEE protection. It should be distinguished that peer review targeted the model and implementation in the paper; how the currently deployed CRVA by DeepSafe corresponds to the paper's scheme still needs to be assessed in conjunction with 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, with over 2.65 million active accounts. The project also stated that its ecosystem relationships exceeded 70, involving wallet compatibility, technical integration, investment, and market cooperation, among other types.

In October 2025, DeepSafe announced the completion of a $3 million seed round, with investors including Antalpha Global, ViaBTC Capital, and Gate 1. From the timeline, this round of financing mainly corresponds to technology research and development and ecosystem expansion after the rebranding.

V. From Verification Solution to General Infrastructure

As blockchain infrastructure becomes increasingly modular, consensus, execution, data availability, interoperability, and account systems are being handled by different components. Modularity does not make trust problems disappear; it 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 that layer and who is responsible when problems occur. After AI agents gain on-chain execution capabilities, new questions arise: who confirms that the data they read is trustworthy, that decisions do not exceed authority, and that final transactions are consistent with user authorization? These questions will not be automatically answered just because of a valid signature.

DeepSafe hopes to abstract verification capabilities from an auxiliary module within a single application into infrastructure that can be called 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 such as oracles, cross-chain, and AI agents, and develop into general verification infrastructure, will depend on the continuous accumulation of live network capabilities, independent audits, and real integrations.