The April 18, 2026 attack on KelpDAO’s rsETH bridge put a basic security question back in focus: not just whether a signature is valid, but who had the authority to produce it, what information they relied on, and whether the state behind that signature actually existed.
In the incident, 116,500 rsETH were released abnormally, worth about $292 million at the time. LayerZero’s incident report said the attacker obtained a developer session key through social engineering, poisoned an internal RPC used by LayerZero Labs’ Decentralized Verifier Network, or DVN, and then used a denial-of-service attack to suppress external RPC endpoints. That caused the signing service to issue proof for forged messages based on false data. KelpDAO had changed its validation path from 2-of-2 to 1-of-1 DVN, which meant a wrong proof from the single designated DVN no longer needed an independent second DVN to cross-check the same message. CrowdStrike and Mandiant attributed the incident with high confidence to TraderTraitor, the North Korea-linked group also tracked as UNC4899.
What the KelpDAO incident exposed
The article argues that this kind of failure is not unusual. In many major onchain security incidents, the cryptographic assumptions are not what collapse first. The weak points tend to be key control, data sources, validator configuration, protocol implementation, and operational permissions. A system has to answer more than whether a signature verifies. It also has to answer who was allowed to sign, what facts informed that signature, and whether the signed state transition truly happened.
That question becomes sharper as more AI agents gain onchain execution rights through smart accounts, strategy wallets, or constrained signing services. A valid signature can prove that an authorized route was called. It cannot prove that the data the agent used was reliable, that the decision matched a preset strategy, or that the transaction should have been executed at that specific moment. In that framing, the object of verification is expanding from signature authenticity to whether inputs, decisions, and execution are aligned.
What existing models solve, and what they still leave behind
The piece goes through several existing approaches and argues that each resolves part of the trust problem while leaving the rest in the hands of a different actor.
Oracles and dispute resolution
On Polymarket, market outcomes are first proposed by participants. Only if a result is challenged during the challenge period does it move to a vote by UMA token holders. The issue is not the absence of review. The issue is whether that review is dependable. If rules are ambiguous, real-world events can be interpreted in multiple ways, or voting power is concentrated in a small number of addresses, then the system has effectively passed the question of who defines reality to another governance structure.
Cross-chain bridge multisig and DVN
Multisig bridges and DVN systems work differently, but both require applications to define a validator set and threshold in advance. Once KelpDAO set the route to 1-of-1 DVN, the entire validation path depended on a single verifier service. The data sources behind that service, and the way it handles outages, could then become the next single point of failure.
MPC custody
Threshold signing is often presented as a way to avoid holding a full key in one place. The article notes that cryptographic sharding does not automatically create organizational decentralization. According to disclosures from the Multichain team at the time, once the founder was detained by police in China, the team immediately lost access to the MPC node servers tied to the system because those servers were running under the founder’s personal cloud account. If cloud accounts, operations access, and emergency response authority are concentrated in one person, an MPC threshold design can still leave a single point of failure at the organizational layer.
TEE
Trusted execution environments can isolate code and sensitive data, but they do not remove trust. They shift where that trust sits. The hardware root of trust and microcode updates usually depend on the chip maker, while enclave code, upgrade authority, and attestation policy may be controlled by the project team or operator. TEE can protect computation. It does not automatically distribute governance power.
The failure modes differ, but the article’s point is the same across all of them: the threshold assumptions and decentralization claims written in a white paper only become a real security boundary when they are carried through into data sources, account permissions, upgrade keys, and governance procedures.
CRVA and a different way to assign validation power
DeepSafe was renamed from Bool Network in 2025. Its CRVA design continues a line of work proposed by researchers associated with Bool Network in 2022. The related paper appeared in IEEE Transactions on Information Forensics and Security, or IEEE TIFS, under Document ID 9903072, and described a cross-chain notarization platform based on an evolving hidden committee.
In that design, nodes enter a random selection process through Ring-VRF. Selected participants submit proof and temporary public keys. Outside observers can verify that they qualify, but have difficulty identifying their long-term identities. The temporary committee then signs collectively through threshold MPC, so no single node can produce a result alone. Key management and other critical steps are designed to run inside a TEE, with Intel SGX used as the example in the paper, to reduce the chance that a host operator can read or tamper with key shares.
The committee rotates by epoch. A new committee receives fresh shares through a verifiable key handoff, and the old shares expire. The actual rotation interval depends on network parameters in production.
The project also aims to use TEE to hide the committee’s working state, making it difficult for node operators to know whether their machines took part in a specific verification task. The article is careful on that point. It says the extent to which this goal can be achieved depends on production code, remote attestation, host-side metadata, and side-channel protections. TEE by itself does not settle the matter.
Even then, the mechanism solves who verifies and how a result can be issued safely in a shared manner. It does not automatically define what the correct result is. In an AI agent setting, the committee still has to rely on preset policies, data sources, and executable judgment rules. If those rules are flawed, if the data source is unreliable, or if the target being verified has no objectively determinable answer, then a well-protected committee can still collectively confirm the wrong conclusion.
For that reason, the article says CRVA may reduce the risks tied to long-term exposure of fixed validators and concentration of signing authority, but it cannot eliminate single points of failure in governance or implementation. Node admission, protocol upgrades, TEE attestation, and software security still require continuing audits. Committee rotation can shorten the attack window against a fixed signing group if old shares really expire and the new committee remains sufficiently independent, yet it does not cover systemic risks such as software supply-chain compromise or upgrade authority.
Academic basis and deployment progress
The technical lineage of CRVA traces back to a Bool Network paper published in IEEE TIFS Volume 17 in 2022, with DOI 10.1109/TIFS.2022.3209546. The protocol model, security proofs, and prototype evaluation in that paper went through peer review, which the article cites as academic support for dynamic hidden committees, Ring-VRF, threshold key management, and TEE-based protection.
It also draws a distinction: peer review applies to the model and implementation described in the paper. How DeepSafe’s current CRVA deployment maps to that design still has to be judged against the current technical specification, code audits, and network parameters.
DeepSafe said in October 2025 that the network had processed nearly 120 million verifications and had more than 2.65 million active accounts. The project also said it had built more than 70 ecosystem relationships across wallet compatibility, technical integration, investment, and marketing partnerships.
Also in October 2025, DeepSafe announced a $3 million seed round backed by Antalpha Global, ViaBTC Capital, and Gate, among others. Based on the timeline in the article, that financing corresponded mainly to post-rebrand technical development and ecosystem expansion.
From validation design to shared infrastructure
As blockchain infrastructure becomes more modular, consensus, execution, data availability, interoperability, and account systems are increasingly handled by different components. The article’s view is that modularity has not removed the trust problem. It has made the security boundary at each layer easier to see. Developers are not only choosing technology stacks. They are also deciding who provides the security guarantees for that layer and who bears responsibility when something fails.
Once AI agents gain onchain execution power, the next set of questions follows quickly: who confirms that the data they read is trustworthy, that their decisions stay within delegated authority, and that the final transaction matches user authorization? A valid signature does not answer those questions on its own.
DeepSafe’s goal is to turn validation from an internal module attached to a single application into infrastructure that can be called by different protocols and AI agents. The slogan cited in the article is “Proof, Not Promises,” replacing operator assurances with verifiable evidence. CRVA already combines anonymous selection, threshold coordination, and TEE into one technical route. Whether it can extend across oracles, cross-chain systems, and AI agent use cases, and grow into a general-purpose verification layer, will depend on live network capability, independent audits, and the accumulation of real integrations.
The submission notes that the article represents a contributed piece and does not reflect the views of BlockBeats.