Coinbase Ventures’ recently published 2026 Investment Outlook highlights “unsecured credit money markets” as the next frontier for DeFi. Behind this prediction lies a sharp observation: today’s decentralized financial architecture is fundamentally constrained by its reliance on over-collateralization.

According to Coinbase’s data, the U.S. alone has $1.3 trillion worth of revolving unsecured credit lines. In contrast, the entire on-chain lending market is under $20 billion, and nearly all of it requires borrowers to post 150–200% collateral. Protocols like Aave and Compound only serve users who already hold a large amount of crypto assets — effectively turning DeFi into a “rich person’s game.” Those who need credit the most are excluded.

Coinbase makes a blunt point: if DeFi wants to surpass the traditional banking system, it must break free from over-collateralization.

But that raises a fundamental question:

How can a decentralized system offer unsecured credit without the traditional credit infrastructure — credit bureaus, FICO scores, centralized identity verification — that banks rely on?

Coinbase’s full report is here:
https://www.coinbase.com/zh-cn/blog/Coinbase-Ventures-Ideas-we-are-excited-for-in-2026

The Core Paradoxes of On-Chain Credit

Even if we tried to rebuild a credit system entirely on-chain, three structural paradoxes emerge:

1. Privacy vs. Disclosure

Traditional underwriting requires detailed personal information — bank statements, payroll data, consumption records.

Web3 users, however, fiercely protect their privacy and do not want to expose sensitive off-chain identity and financial data on a public ledger.

Lenders need information; borrowers don’t want to reveal it. A fundamental conflict.

2. Decentralization vs. Data Authenticity

Assume a user is willing to provide their data.
Who verifies its authenticity in a decentralized system?
Without a centralized authority to validate documents, how do we stop forged credit reports or faked asset proofs?

If we rely on a trusted institution, we lose decentralization.

3. Cross-chain Reality vs. Data Fragmentation

A user’s financial footprint is scattered across multiple chains — BTC, Ethereum, Solana — and across traditional banking systems. How do we merge these into a single credit profile? Different chains use different data formats and privacy models, making verifiable cross-chain fusion extremely challenging.

Together, these form the “Trilemma of On-Chain Credit.”
Coinbase gestures at a solution: combining on-chain reputation with off-chain data. But this immediately raises two deeper questions:

• How do we prove identity and credit without sacrificing privacy?
• In a decentralized world, who performs these verifications?

This is where Zero-Knowledge Identity (ZKID) and decentralized verification networks enter the picture.

From ZKID to Decentralized Verification: A Complete Trust Stack

Zero-Knowledge Identity has become a buzzword in Web3 circles, often reduced to the idea of “privacy protection.” But ZKID is much more profound — it redefines the very meaning of proof.

In traditional systems, proving something means revealing the underlying data. To prove your income exceeds $3,000, you hand over your bank statements — exposing your spending habits, cash flows, and balances.

Zero-knowledge proofs flip this paradigm. They allow a user to prove a statement is true without revealing any raw data.

Examples in credit lending:

• Prove “my total on-chain assets exceed $100k” without showing which tokens you hold.
• Prove “my bank credit score > 700” without sharing your full credit report.
• Prove “I interacted with 50+ DeFi protocols without defaults” without revealing your transaction history.

ZKID solves the privacy side. But it does not solve the trust side.

Because any DeFi protocol evaluating a ZK proof must still ask:

1. Is the proof mathematically valid?
2. Was the underlying data authentic (e.g., did it really come from a bank)?
3. Is the verification process decentralized, not controlled by a single actor?
4. Can the verification be audited without exposing sensitive data?

These needs point to a missing piece in the Web3 stack:

a decentralized, privacy-preserving, censorship-resistant verification network.

This is precisely where networks like DeepSafe come in.

DeepSafe: Redefining Trust in Decentralized Verification

DeepSafe’s mission is ambitious:
Enable trustworthy, privacy-preserving, and censorship-resistant verification in a fully decentralized environment.

Traditional verification systems sit at two extremes:

• Centralized verification: Banks, institutions, and KYC vendors verify data. But this creates single points of failure.
• Fully public verification: All data is on-chain. But this destroys privacy.

DeepSafe’s architecture finds a third path by combining cryptography with hardware-secured computation — creating a distributed yet trustworthy verification layer.

Its trust model is built on four core principles:

Principle 1: Verifiers Must Be Random and Hidden

If verifier identities are public, they can be bribed, coerced, or attacked.

DeepSafe uses Ring VRF (ring-signature Verifiable Random Functions) to select verification committees:

• Each request triggers a random draw from hundreds of nodes
• Committee members remain anonymous
• Attackers cannot predict or target them

This makes bribery and collusion economically infeasible.

Principle 2: Verification Must Occur in a Secured, Isolated Environment

Even if nodes are honest, their operators should not see user data.

DeepSafe requires all verification logic to run inside a Trusted Execution Environment (TEE) — Intel SGX, AMD SEV, ARM TrustZone.

TEE ensures:

• Raw data is only accessible inside the secure enclave
• Node operators cannot access or extract sensitive data
• All computation is integrity-protected

Thus, off-chain financial data (bank scores, identity documents) remains confidential.

Principle 3: Results Must Be Confirmed by Multiple Parties

No single node should decide the outcome.

DeepSafe uses MPC and threshold signatures:

• Multiple nodes verify the proof independently
• Their partial signatures are combined into a final result
• Only sufficiently large agreement (e.g., 5 out of 7) yields an output
• Malicious minority cannot forge results

This establishes distributed trust, not trust in a single actor.

Principle 4: The Process Must Be Auditable Without Exposing Data

Decentralization requires transparency. Privacy requires confidentiality.

DeepSafe resolves this through zero-knowledge attestation:

• Every verification generates a ZK proof
• Anyone can verify the process followed the rules
• But the underlying private data remains hidden

Auditability without surveillance.

A Full Example: Unsecured Credit in DeFi

An example illustrates DeepSafe’s architecture:

A user, Alice, wants an unsecured loan. A DeFi protocol requires proof that her bank credit score > 750.

Step 1:

Alice uses a ZKID tool off-chain to generate a ZK proof:

“My bank score > 750.”

She submits the proof to DeepSafe.

Step 2:

Ring VRF selects an anonymous 7-node committee.

Step 3:

Inside each node’s TEE:

• The verifier accesses Alice’s real bank score via a secure API
• Checks that the ZK proof reflects the real data
• Without the operator ever seeing the raw data

Step 4:

Nodes produce partial signatures.
If 5 out of 7 agree, MPC aggregates them into a valid result.

Step 5:

The result + a ZK proof of correct execution is posted on-chain.
The lending protocol reads it and approves the unsecured loan.

Throughout:

• Alice’s data remains private
• Verifiers cannot collude
• The process is fully auditable
• No centralized trust is needed

This is the value of a decentralized verification layer:
it enables trust without compromising privacy or decentralization.

Why Verification Infrastructure Matters Beyond Credit

Zooming out, Coinbase’s 2026 themes all point toward a single foundational requirement:
trustable verification of off-chain information.

RWA Perpetuals

Bringing real-world asset prices on-chain requires robust verification.
Current oracle systems rely on a small number of data providers — susceptible to manipulation.

DeepSafe enables:

• Multi-source data validation
• Anomaly detection and cross-checking inside TEE
• Integrity proofs via ZK

Critical for high-value RWA markets.

AI Agent Verification

As AI agents manage on-chain assets and execute strategies, a new trust problem emerges:
How do we verify an AI model’s output without revealing its parameters?

DeepSafe’s TEE+ZK approach enables:

• Running AI models privately inside TEE
• Proving outputs are genuine
• Ensuring models and inputs were not tampered with

This is foundational for “verifiable AI.”

On-chain Privacy with Regulatory Compliance

Blockchain transparency exposes users to MEV attacks, front-running, and privacy loss.

But full privacy (à la Tornado Cash) conflicts with compliance.

DeepSafe enables “selective transparency”:

• Users submit ZK proofs showing a transaction meets compliance rules
• Verifiers check proofs inside TEE
• Mark compliance on-chain
• Without revealing transaction details

Privacy + compliance, not a zero-sum game.

The Missing Layer in Web3: Verification-as-a-Service

The industry solved decentralized ledger keeping (Bitcoin) and decentralized computation (Ethereum). But decentralized verification remains unsolved.

This gap explains:

• Over-collateralized DeFi
• Fragile RWAs
• Centralized stablecoin issuers
• Oracle dependency
• Lack of trust in AI-generated actions

A true Web3 economy requires decentralized verification of:

• Identity
• Creditworthiness
• Data authenticity
• AI outputs
• Regulatory compliance
• Cross-chain state
• Off-chain truth

This is why networks like DeepSafe may become as fundamental as blockchains themselves. Blockchains decentralize state. Verification networks decentralize trust.

$1.3 Trillion Awaits — But Trust Infrastructure Must Come First

The U.S. unsecured credit market is $1.3 trillion.
DeFi today accesses 0% of it.

Not because we lack:

• smart contracts
• tokens
• incentive designs
• governance models

But because we lack trust infrastructure.

Coinbase’s 2026 outlook is ultimately a call for foundational infrastructure. Without decentralized verification, unsecured lending remains a centralized game. With it, DeFi’s ceiling is far higher than anything we’ve seen.

The future of Web3 will be shaped not just by decentralized ledgers — but by decentralized verification layers like DeepSafe.

They are the missing piece enabling Web3 to finally break past the limits of traditional finance.

1. Vitalik Signs The Trustless Manifesto

On November 13, 2025, Ethereum co-founder Vitalik Buterin, together with Yoav Weiss and Marissa Posner, officially signed and published The Trustless Manifesto.

The manifesto is not a technical whitepaper — it is a fundamental critique of the current trust assumptions embedded in the Web3 ecosystem.

The opening statement sets the tone:

“Trustlessness is not a feature you can add later — it must be the foundation of the system’s design.”

The manifesto warns that the erosion of decentralization rarely happens through explicit power grabs. Instead, it emerges through incremental compromises in convenience:

• one custodial RPC node,
• one permissioned relayer,
• one fixed validator committee…

Each decision may seem harmless, but together they create systemic reliance on centralized intermediaries.

To judge whether a system is truly trustless, the manifesto提出 three fundamental laws:

1. No Critical Secrets
2. No Indispensable Intermediaries
3. No Unverifiable Outcomes

These laws function like a truth-revealing lens, exposing the hidden trust assumptions buried in today’s Web3 infrastructure — and many of the industry’s most dramatic failures align perfectly with these violations.

2. First Law — No Critical Secrets

The manifesto states:

“No step of the protocol should rely on private information held by any single actor — except the user themselves.”

This law aims to eliminate key-person risk. Any secret information (especially cryptographic private keys) controlled by a single entity becomes a single point of failure.

The Bybit Incident

In September 2024, Bybit suffered a $1.5B cold wallet breach. Although Bybit claimed to use multi-signature schemes, investigators discovered that the cold wallet private keys were effectively controlled by only a handful of executives. Through social engineering and internal infiltration, attackers obtained enough signatures to drain the funds.

This exposed the fatal flaw of traditional multisig:

• signer identities are fixed and public
• private keys exist in software stacks
• server intrusion = key extraction

Most importantly, users had no way to verify how private keys were actually managed — nor prevent insider collusion.

The Multichain Incident

In July 2023, Multichain froze over $1B in assets after the CEO went missing. Although claiming MPC (multi-party computation), all node server access was controlled by a single internal team. Without organizational decentralization, technical decentralization collapses back into “trust the key person.”

“10·11” Flash Crash & MMT Dumping

The October 11 liquidity crash exposed internal authorization bottlenecks. The MMT top-10 wallet dump revealed covert collusion among multisig signers. Different events, same root cause — centralized, unverifiable key management.

FTX as the Ultimate Negative Case

FTX, while claiming multisig and cold storage, secretly centralized private key control within Sam Bankman-Fried’s inner circle. Customer funds — $8B — were diverted via backdoor access.

Users had no ability to verify how keys were actually managed. The multisig scheme existed only as a narrative, not an auditable truth.

This perfectly illustrates the First Law’s warning: If private key practices cannot be verified, the system is not trustless.

3. Second Law — No Indispensable Intermediaries

The manifesto emphasizes:

“‘Anyone can run a node’ is not enough — participation must be open in practice, not only in theory.”

This addresses the gap between theoretical openness and practical accessibility.

Email as a Cautionary Tale

SMTP was designed to allow anyone to run a mail server. But spam filters & reputation systems made small servers effectively unusable. Email became an oligopoly (Google, Microsoft, etc.), despite being an open protocol.

Web3 is repeating this history.

Centralized Sequencers in Layer 2 Rollups

Arbitrum and Optimism use a single sequencer who:

• decides which transactions enter the block
• decides ordering
• can censor users
• can delay inclusion

Sequencer decentralization is always “coming soon,” yet two years have passed with no deployment. These single choke points violate the Second Law outright.

RPC Centralization

Although anyone can theoretically run a node, most DApps rely on:

• Infura
• Alchemy
• QuickNode

When Infura went down in 2022, MetaMask globally failed.

Even deeper: most blockchain nodes run on AWS / Google Cloud. If cloud providers censor or suffer outages, entire chains are crippled.

LayerZero & Permissioned Bridging

LayerZero claims “anyone can be a relayer,” but:

• high capital requirements
• multi-chain node maintenance
• complex DevOps
• governance approval

all mean relayers are, in reality, a small group of professional institutions.

Ronin Bridge — the Perfect Counterexample

Ronin used a “9-node verifier committee,” but control was centralized within Sky Mavis and a few partners.

North Korea’s Lazarus Group hacked just 5 keys — enough to steal $620M.

Despite being “open,” participation was restricted by:

• high staking requirements
• identity disclosure
• governance approval

The Second Law’s lesson: If economic and operational barriers make participation impractical, decentralization exists only on paper.

4. Third Law — No Unverifiable Outcomes

The manifesto states:

“Every state transition must be reproducible and independently checkable from public data.”

Recent events show how badly this law is violated.

10·11 Crash & MMT Dump

We can see what happened on-chain. But we cannot verify:

• internal liquidation triggers
• off-chain liquidity agreements
• wallet ownership relationships
• insider coordination signals

Visibility is not verifiability.

Terra/Luna Collapse — the Ultimate Failure of Verifiability

UST’s peg depended on Anchor’s 20% yield subsidies. The chain shows:

• TVL collapse from $40B to near zero
• Luna hyperinflation > 6000%

But users could NOT verify:

• who controlled the reserve injections
• how Jump handled whale hedging
• what liquidation logic was used
• off-chain agreements
• emergency thresholds

All critical logic occurred in opaque, off-chain environments.

Centralized Exchanges and Their Fake Proof-of-Reserve

Merkle-tree proofs only confirm reserves at a single moment.

They cannot answer:

1. Were reserves borrowed temporarily for the snapshot?
2. Were assets moved immediately after the proof?
3. Are liabilities fully disclosed?

FTX proved PoR alone cannot prevent systemic fraud.

AI Oracles — The New Black Box

When oracles rely on LLMs to judge off-chain facts (“Did Tesla beat Q2 expectations?”), the reasoning is entirely opaque:

• hallucination risk
• biased training data
• unprovable logic
• manipulation possibility

AI black boxes are fundamentally incompatible with blockchain transparency.

5. Engineering the Three Laws — A Real-World Attempt

After dissecting how today’s Web3 infrastructure violates all three laws, we must ask:

Is it even possible to build a system that satisfies them?

A recent example provides a concrete engineering attempt: DeepSafe, a decentralized verification network that recently announced a $3M seed round.

DeepSafe is not a new blockchain, but a trustless verification layer across chains and systems. It attempts to satisfy the manifesto’s laws via a four-layer architecture built on cryptography and distributed systems.

For Law 1 — No Critical Secrets: MPC + TEE

• Keys are split into N shards (e.g., 10)
• Only t are needed to sign (e.g., 7)
• No single node ever holds the full key
• Each shard lives inside a hardware-enforced TEE (Intel SGX)

Even node operators cannot extract key shards. Rotating committees erase temporary shards, preventing insider abuse.

For Law 2 — No Indispensable Intermediaries: Ring VRF + ZK

• Validators selected by on-chain randomness
• Selection proven via ZKP
• Identity hidden with Ring VRF
• Low staking threshold → universal accessibility
• Committees rotate hourly/daily

No one knows who the committee members are — not even each other. No fixed operators → no fixed attack targets.

For Law 3 — No Unverifiable Outcomes: ZK for Everything

Every step produces:

• ZK proof of correct execution
• On-chain record of committee selection
• On-chain record of final signatures
• On-chain verifiable data availability

For off-chain data, DeepSafe uses a multi-node AI retrieval and cross-verification model (“Deep Search”), preventing single-node hallucinations.

Practical Applications

• Cross-chain bridges (Ronin-style attacks become impossible)
• BTC mapping assets (2-of-2 Taproot with Timelock ensures unilateral recovery)
• CEX custody (exchanges cannot access user funds — only operate them)
• Market-making transparency (on-chain rule enforcement eliminates insider collusion)

When the next scandal happens, users would check on-chain verification records, not wait for “official explanations.”

6. The Ultimate Question of The Trustless Manifesto

“If your protocol requires faith in intermediaries, change it. If it relies on private gateways, replace them. If it hides critical logic off-chain, expose it.”

Looking back at FTX, Ronin, Terra — investors waited for “official explanations” because the systems offered no way to verify the truth independently.

The blockchain recorded what happened. But users could not verify why it happened.

The manifesto ends with a powerful statement:

“Success is not measured in TPS, but in the amount of trust removed from each transaction.”

While the industry obsesses over TPS, TVL, user numbers, trust creep is silently returning through:

• temporary “training wheels”
• transitional centralized components
• convenience-driven architectures

Rollups’ “temporary sequencers” never decentralize. Bridges keep fixed committees. Market-making logic stays off-chain.

Every compromise pulls us farther from trustlessness.

The three laws of the manifesto are not optional features — they are the test of whether a system is truly decentralized.

Today, most Web3 infrastructure fails this test.

This is not condemnation — it is a warning.

DeepSafe’s significance lies not in inventing something new, but in proving that the manifesto’s principles are engineering-feasible:

• MPC + TEE for Law 1
• Ring VRF + ZK for Law 2
• ZKP transparency for Law 3

Trustlessness doesn’t need to remain a whitepaper fantasy. It can be built.

When the next FTX or Terra happens, we should no longer hear:

“Please wait for the official explanation.”

We should hear:

“Please check the on-chain verification record.”

That is what Web3 was supposed to be.

Source: Shew & Noah, DeepSafe Research

Since the inception of Bitcoin and Ethereum, the concept of the “Blockchain Trilemma” has been widely discussed within the crypto community. This well-known principle highlights the inherent conflict between trustlessness and high efficiency. Although a range of innovative solutions — such as payment channels, rollups, and modular blockchains — have emerged over time, none have achieved full generalizability. When it comes to building use cases tailored for specific scenarios, such as customized programmable signatures, alternative technical approaches become necessary.

Now, as the industry continues to evolve and mature, Trusted Execution Environments (TEE) are increasingly being integrated into the Web3 ecosystem. By providing hardware-level data isolation and integrity guarantees, TEE not only ensures security but also introduces new possibilities for applications within the crypto space.

In this report, DeepSafe Research explores TEE’s role in Web3 through several key cases, including TEE-Boost, Rollup-Boost, and CRVA. We aim to demonstrate its tremendous potential and the emerging scenarios where TEE could play a pivotal role. We believe that TEE has the capacity to reshape the entire blockchain industry — especially in areas such as MEV mitigation, base-layer performance scaling, and trustless signature schemes — and establish itself as a fundamental component in all privacy-sensitive applications.

What is TEE?

In simple terms, a Trusted Execution Environment (TEE) is a secure area within a processor or data center that is isolated from the rest of the system. Programs can be executed inside the TEE, and they are shielded from interference by any external processes — including the host operating system.

Unlike software-based security mechanisms, TEEs provide hardware-enforced protection, ensuring that no external entity can observe or access the data inside the TEE. Neither the host OS nor the cloud service provider can view sensitive data within the TEE. This forms the basis of one of TEE’s two core features: security, which acts as a protective barrier for sensitive computation and data.

The second key feature is integrity. This means that code running inside the TEE will execute exactly as it was originally programmed, without the possibility of external tampering. TEE hardware generates a cryptographic hash of the code being executed and provides a signature of that hash. Anyone interacting with the TEE can verify this signature and confirm whether the correct code is running.

This signature is generated using a root key embedded in the TEE by the hardware manufacturer. There are multiple methods for key generation. One is called key injection, where the key is generated externally by the manufacturer and then embedded into the chip during production. Intel SGX uses this approach, which means Intel, as the chip maker, may have knowledge of the key.

A more modern approach involves generating the key internally within the TEE using an onboard true random number generator (TRNG). When the TEE is initialized for the first time, it uses this TRNG to generate a key that even the chip manufacturer cannot predict. As a result, not even the data center hosting the TEE can access its internal keys.

Most documentation on TEE tends to emphasize its security aspects, but often overlooks integrity — a critical component. The process of verifying the TEE’s signature on the program hash is known as Remote Attestation. This allows users to confirm that the program running inside the TEE matches the open-source code published on platforms like GitHub.

Therefore, for any TEE-based application, we can confidently say that:

1. Sensitive data will not be leaked.
2. The program is verifiably running as written in the source code.

However, TEE is not entirely trustless. Applications built on TEE must still trust the hardware manufacturer. Since TEEs are typically implemented by vendors like Intel, AMD, or ARM, users must rely on these companies to properly follow secure manufacturing processes and avoid inserting any backdoors.

To mitigate this, users can use Remote Attestation to ensure the host is not executing programs outside of the TEE, even if they do not fully trust the hosting environment.

Typical TEE Application Scenarios in Web3

TEE-Boost: Decentralizing the Block Construction Process

In the Ethereum ecosystem, Trusted Execution Environments (TEEs) have been introduced as a potential solution to the centralization challenges of MEV (Maximal Extractable Value). The majority of Ethereum nodes currently rely on an intermediary middleware called MEV-Boost, which in turn depends heavily on centralized Relay services. To better understand the role of TEEs here, let’s briefly walk through how MEV-Boost works:

1. Searchers: Within the Ethereum network, there are numerous Searchers who continuously scan the public mempool for unconfirmed transactions. They identify profitable MEV opportunities and construct ordered bundles of transactions — often inserting their own transactions strategically — before submitting these bundles to a Builder.
2. Builders: Multiple Searchers compete by submitting different transaction bundles. Builders select several non-conflicting bundles and aggregate them into a full block. They then declare how much of a tip they are willing to pay to the block proposer if the block is included on-chain.
3. Relays: Acting as intermediaries, Relays collect candidate blocks from multiple Builders. When a Validator/Proposer is ready to propose a block, it requests a block from the Relay. The Relay selects the block offering the highest tip and returns its block header — not the full block — to the proposer. This header contains summary data and the tip amount promised by the Builder.
4. Proposer Signing: The Validator/Proposer signs the block header and broadcasts it across the network, signaling acceptance of the block offered by the Relay. Once this signature is verified, the Relay transmits the full block to the Proposer, who finalizes and rebroadcasts it to the network.

Looking at the above workflow, it’s clear that Relay service providers play a critical role in the MEV-Boost system. A Relay must fulfill several key responsibilities:

1. Privacy: The Relay must ensure that the block contents are not visible to the proposer before commitment. If a proposer sees the transaction ordering in advance, they could replicate the Searcher’s strategy, insert their own MEV transactions, and capture the entire profit.
2. Block Validity: The Relay is responsible for verifying that the blocks submitted by Builders are valid and do not contain spam or malformed data.
3. Data Availability: The Relay must be able to deliver the full block to the proposer within a limited time window, ensuring the block can be proposed and broadcast on time.
4. Highest Bid Guarantee: The Relay must ensure that the block it submits to the Validator yields the highest tip possible, maximizing proposer revenue.

Despite the Relay’s pivotal role, MEV-Boost currently depends on a small, centralized group of Relay providers. As the chart below illustrates, a handful of Relays dominate the MEV market. For example, Ultra Sound Relay alone commands nearly 40% of the market share.

This centralization introduces significant risks — including the potential for censorship, manipulation, and collusion. Any single Relay or colluding group of Relays could abuse their position to favor certain Builders, withhold blocks, or leak private information, undermining the fairness and neutrality of Ethereum’s block production process.

One of the simplest yet most damaging attack scenarios is when a Relay provider violates the principle of privacy by leaking the contents of a Builder’s block to the proposer ahead of time. This enables the proposer to mimic the Builder and Searcher’s transaction ordering, insert their own MEV transactions, and siphon off the profit for themselves.

Other potential forms of malicious behavior by Relays include:

• Submitting invalid blocks
• Withholding block data
• Manipulating tip selection to favor certain Builders

To address these issues, TEE-Boost introduces a revolutionary approach: it leverages Trusted Execution Environments (TEE) to eliminate the need to trust centralized Relay providers, while preserving all the security guarantees of the MEV-Boost architecture.

In the TEE-Boost model:

• The Relay role is removed entirely.
• Builders run their block-construction logic inside TEEs, and use remote attestation to prove that the block was generated correctly and securely.
• Proposers interact directly with multiple Builders, selecting the block header with the highest tip and signing it.
• After receiving the signed header, the selected Builder then reveals the full block to the proposer for final broadcasting.

By removing the Relay as a centralized intermediary, TEE-Boost prevents early leakage of block contents, ensuring both privacy and fairness in MEV capture.

Rollup-Boost: Scaling Layer 2 with TEE

In addition to TEE-Boost, the Ethereum ecosystem also employs TEEs in another innovation known as Rollup-Boost. Developed through a collaboration between Flashbots, Uniswap Labs, and OP Labs, Rollup-Boost powers Unichain and represents a modular rollup architecture. It introduces two key scalability and fairness-enhancing modules:

1. Flashblocks with 250ms Finality:
   Transactions can be confirmed in just 250 milliseconds, significantly improving user experience. From a user’s perspective, this means near-instant transaction inclusion and confirmation.
2. Verifiable Priority Ordering:
   Transactions are strictly ordered based on the priority fee paid, and this ordering is enforced cryptographically — not subject to manipulation by block builders. Furthermore, it allows DeFi smart contracts to recapture a portion of MEV through built-in mechanisms.

For the Flashblocks module, the core mechanism involves packaging transactions within a TEE, which then generates block fragments and broadcasts them. Validators on Unichain collect these fragments and assemble them into a complete block.

The advantages of this approach are immediately clear. By allowing validators to continuously receive partial block data, rather than waiting through idle intervals before receiving a full block, bandwidth utilization is significantly improved, resulting in higher TPS (transactions per second) and faster transaction finality.

Moreover, since block fragments are generated within the TEE, they are guaranteed to be valid and free from junk data, as long as the code running inside the TEE is correct. This effectively eliminates the need for validators on Unichain to re-verify block data, reducing their computational overhead.

As for verifiable priority ordering, it leverages the trust guarantees of the TEE to produce a credible transaction ordering. Any third party can trust that the block-building logic within the TEE is free from manipulation. In contrast, if the same logic were executed outside of the TEE, transaction prioritization might be compromised — block producers could reorder transactions to maximize their own profits, undermining fairness.

DeepSafe: A Next-Generation Trustless Threshold Signature Scheme

To build a more decentralized and trustless message verification + threshold signature system, DeepSafe introduces TEE (Trusted Execution Environment) and ZK (Zero-Knowledge Proofs) to create an original, fully confidential committee selection and signing mechanism, called CRVA (Cryptographic Random Verification Agent).

To optimize both the speed and trust model of message verification and threshold signing, CRVA employs a lottery-based random selection algorithm. For example, every 30 minutes, a set of 10 nodes may be randomly selected to act as verifiers to confirm the validity of a given message (e.g., whether a cross-chain transaction is legitimate). Once verified, the selected nodes generate a threshold signature, which triggers the next on-chain action.

In CRVA, DeepSafe uses the privacy-preserving features of TEE and ZK to conceal the identities of the selected verifiers, thus protecting against internal collusion or external attacks. A simplified version of the process is as follows:

1. Each CRVA node runs its core module within a TEE and registers a permanent public key on the DeepSafe mainnet to establish its identity.
2. The node generates a temporary public key inside the TEE, and produces a ZK proof that this temporary key is linked to one of the registered permanent keys — without revealing which one. (Note: due to TEE protection, even the node itself cannot see the contents of its temporary key.)
3. The node then encrypts the temporary public key within the TEE, and sends the resulting ciphertext along with the ZK proof to an external Relayer, which aggregates inputs from all participating nodes. Inside its own TEE, the Relayer decrypts the ciphertexts to recover the set of temporary public keys — but without knowing which node submitted which key, again thanks to TEE isolation.
4. After assembling the full set of decrypted temporary keys, the Relayer submits the list on-chain, where a VRF (Verifiable Random Function) is used to randomly select a subset of nodes as verifiers, forming a fully anonymous committee.
5. When a message (e.g., a cross-chain request) needs to be verified, it is broadcast to the CRVA network. Each node uses its temporary public key inside the TEE to privately verify whether it has been selected as part of the committee. If selected, it then participates in threshold signing.
6. DeepSafe ensures the integrity of CRVA’s internal processes through remote attestation. All CRVA nodes generate remote attestation proofs from within their TEE, and these proofs are verified on-chain. DeepSafe has built its own dedicated blockchain specifically for receiving and verifying these proofs.

At the core of CRVA is the principle that almost all critical operations occur entirely within TEEs, making the process confidential and tamper-resistant. From the outside — including Relayers — all that is visible is a series of encrypted ciphertexts. No one knows who the selected verifiers are — not even the nodes themselves, as they cannot access their own temporary public keys. This architectural choice completely eliminates the possibility of collusion or targeted attacks.

In theory, compromising a CRVA committee would require attacking hundreds of nodes across the CRVA network, making it exceedingly difficult. This trustless threshold signature system, powered by TEE and privacy-preserving computation, is suitable for a wide range of applications — including multisig wallets, asset custody, cross-chain bridges, and oracles.

In previous articles, we’ve discussed how CRVA can enhance smart contract wallets by serving as a second layer of 2FA (two-factor authentication), further strengthening asset protection. Furthermore, since most cross-chain bridges and asset platforms rely on multisig or MPC custody mechanisms, CRVA is naturally suited for these environments.

A notable example is Bool Network, a leading cross-chain bridge in the Bitcoin ecosystem, which is built on CRVA. In 2024 alone, it processed over $350 million in cross-chain transactions, connecting to nearly 80% of Bitcoin Layer2 networks, and achieving substantial success.

Future Applications of TEEs

TEE Coprocessors: Bridging Web2 and Web3

TEE coprocessors are emerging as one of the most promising use cases for Trusted Execution Environments (TEEs). The concept is similar to Rollups: leveraging verifiable off-chain computation to replace expensive on-chain operations. In this model, complex algorithms, data processing, and computational logic are executed inside a TEE, while the blockchain only verifies the result using cryptographic proofs.

This approach enables cost-efficient and privacy-preserving computation for smart contracts in the EVM ecosystem. Take AMM contracts for example: they often rely on complex algorithms to optimize parameters for trading. Running such algorithms on-chain would consume excessive gas. By offloading the computation to a TEE, the AMM contract can simply send a request to the TEE and receive updated parameters, saving both gas and time.

Moreover, this architecture opens the door to entirely new types of applications. For instance, Teleport is a project that uses TEE coprocessors to allow smart contracts to control Twitter accounts. Users authorize their Twitter accounts via TEE, and on-chain transactions can trigger TEE-based agents to automatically post tweets — bridging on-chain logic with Web2 platforms in a secure, verifiable manner.

An even more fascinating direction is calling large language model (LLM) APIs inside the TEE for advanced conditional logic. DeepSafe is currently exploring this area with the development of a TEE-powered AI Oracle, where the core logic runs securely within a TEE. This Oracle can query external data using LLMs, make determinations about whether a specific real-world event has occurred, and send the validated results back on-chain. This enables more accurate and trustworthy resolution of prediction markets and other event-driven smart contracts.

Encrypted Mempool and Privacy-Preserving Transactions

Leveraging the confidentiality of TEE, it is possible to build fully privacy-preserving transaction processing workflows. Traditional mempools expose transaction details to the entire network, creating opportunities for various MEV attacks that harm user interests. The developers behind Rollup-Boost have been actively exploring this scenario.

TEE-based encrypted mempools ensure that transactions remain highly confidential throughout their lifecycle. For example, users submit encrypted transactions directly to a TEE-based sequencer, where decryption, ordering, and execution all occur inside the TEE, invisible to external parties. Ultimately, only the final updated state changes after transaction execution are published on-chain.

Multi-Prover TEE Systems

Beyond the previously mentioned scenarios, TEEs can serve as provers for rollups, complementing technologies such as ZK (Zero-Knowledge) proofs and OP (Optimistic) rollups. Notable rollup projects like Scroll and Taiko have adopted TEE-based provers. This approach offers greater efficiency and speed compared to ZK proofs and facilitates easier iteration.

Summary

TEE represents one of the most significant technological advancements in the blockchain domain, offering a practical solution to the longstanding tension between performance, privacy, and decentralization. By providing hardware-backed guarantees of isolation and integrity, TEEs enable new categories of applications while preserving the trust-minimization principles inherent to blockchain systems.

The applications discussed herein — from the decentralized block construction in MEV-Boost, through the performance enhancements in Rollup-Boost, to the advanced security mechanisms of DeepSafe — demonstrate the transformative potential of TEE technology. These implementations prove that TEEs can deliver immediate tangible benefits while laying the groundwork for more ambitious future use cases.

The future of blockchain infrastructure is likely to transcend any single technology, evolving instead into a complex ecosystem of complementary solutions — each optimized for specific use cases and security requirements. Within this multifaceted environment, TEEs will play a pivotal role, providing the performance and capabilities necessary to drive mainstream adoption of blockchain applications, while maintaining their distinctive decentralized and trustless characteristics.

Source: DeepSafe Research

On March 25, 2025, news of an oracle manipulation attack on Polymarket drew widespread attention. Previously, a prediction market on the platform — regarding whether Ukraine would sign a mineral agreement with Trump before April — had attracted around $7 million in bets. As of the evening of March 25, no such agreement had been signed. However, a whale manipulated UMA, the oracle Polymarket relied on, leading to a false contract resolution that claimed the mineral agreement had been signed. This caused significant losses for many participants. After public outcry, the incident was widely reported and sparked intense discussion.

In this typical case of oracle manipulation, the vulnerability stemmed from the UMA oracle’s design, which allows token holders to vote on the outcome of real-world events. If a majority of tokens are cast for “Yes,” the oracle will determine that the event has occurred. On March 25, a whale holding a massive amount of UMA tokens used multiple addresses to cast a total of approximately 5 million UMA tokens, forcibly pushing through a “Yes” outcome — essentially turning falsehood into truth.

It’s worth noting that this is not the first time Polymarket has experienced oracle manipulation. In previous cases, the platform incorrectly declared Edmundo González as the winner of Venezuela’s presidential election, and also wrongly concluded that an Ethereum ETF would be approved before May 31, 2024. Among these incidents, however, the Ukraine mineral agreement prediction market has had the most significant impact.

After the misjudgment in the mineral agreement case, although stakeholders expressed strong dissatisfaction, Polymarket’s official response on Discord stated that the incident was not caused by a technical failure in Polymarket’s system. Therefore, the platform would not compensate affected users, only promising to work with the UMA team to improve the mechanism design and strengthen risk controls. This response was widely seen as an act of inaction and further raised doubts about UMA’s reliability.

Unlike quantitative data-focused oracles such as Chainlink, UMA is primarily used to push outcomes of arbitrary off-chain events, many of which are qualitative and difficult to quantify — such as whether a mineral agreement was signed, as mentioned earlier. Determining such complex events requires not only reliable information sources but also an understanding of the content and the ability to reason about it — something traditional oracles clearly struggle with. UMA’s approach, which relies on human intervention to resolve complex events, may be simple and effective in practice, but it also creates significant room for malicious manipulation.

Currently, several major projects — such as Story Protocol, Polymarket, Across, Snapshot, and Sherlock — use the UMA oracle as a critical data source. If another governance attack were to occur, the resulting losses could be substantial. But if we are to address UMA’s vulnerabilities through technical means, what can be done?

Some have argued that UMA’s penalties for malicious voters are too lenient, and that increasing the severity of these punishments could deter bad actors. However, this approach effectively shifts power to so-called “punishers,” and the punishment process itself could end up being even more centralized than the original voting mechanism — essentially replacing one threat with another.

In this article, DeepSafe Research analyzes the contract code of the UMA oracle and identifies its issues based on relevant documentation. At the same time, we propose a solution that combines AI agents with DeepSafe’s existing technologies, attempting to leverage large language models to assess complex real-world events.

We believe that by combining the optimistic/challenge model with the powerful capabilities of AI agents, it is entirely possible to create a new generation of intelligent oracles. If such a facility capable of verifying and pushing arbitrary off-chain messages is successfully put into production, it could enable highly efficient interaction between smart contracts and the off-chain world, opening up unprecedented scenarios and vast market opportunities.

Workflow and Code Analysis of UMA’s Optimistic Oracle

To better understand the implementation approach of intelligent oracles, let us first conduct an in-depth exploration of the UMA oracle. UMA, which stands for Universal Market Access, provides data on arbitrary events to DApps through a service called the “Optimistic Oracle.” The basic principle is as follows:

If you want UMA to determine whether Trump was elected president, you can submit a question/request and offer a reward as payment. Then, an “assertor/proposer” and a “disputer” will contest the answer to the question.

UMA has a dispute resolution module called the DVM. After the assertor/proposer publishes an answer, a disputer can challenge it, triggering a voting process where UMA token holders decide who is right or wrong. If the vote determines that the assertor acted maliciously, the system penalizes them and rewards the disputer, and vice versa. Additionally, voters who vote correctly can also receive rewards.

In the above model, the oracle optimistically assumes that the assertor/proposer is honest, and punishes them only if they are dishonest; therefore, this model is called the “Optimistic Oracle.” The diagram above shows the workflow of the Optimistic Oracle V3, which is the version most commonly referenced in online materials.

Currently, Polymarket uses an earlier version called Optimistic Oracle (OO) V2. While OOV2 and OOV3 share the same basic principles, there are many differences in implementation details. Since Polymarket uses OOV2, we will focus on analyzing the implementation details of V2 below.

Requester Submits A Question

In OOV2, if you want the oracle to answer a question, you first call the requestPrice() function with the relevant parameters. After the question is submitted, a third-party proposer provides an answer, which then enters a challenge period. If no one disputes the answer during the challenge period, the proposer’s answer is considered correct by default.

In the V3 version, the person submitting the question also acts as the proposer, using a “self-ask, self-answer” approach to submit both the question and the answer simultaneously, which then directly enters the challenge period.

As mentioned earlier, in OOV2 users must first call the requestPrice() function to submit the question information, with key parameters including the identifier and ancillaryData (auxiliary information), among others.

The identifier is used to declare the type of question. A typical binary question can use “YES_OR_NO_QUERY” as the identifier, while quantitative data questions use other identifiers. The auxiliary information in ancillaryData describes the question content in natural language, such as “Was Trump elected President of the United States in 2024?”

In addition to the identifier and ancillary information, you must also specify parameters such as the timestamp when the question is submitted, the token offered as a reward, and the reward amount. These parameters are submitted together to the oracle contract.

After receiving the above data, the OOV2 contract calls the _getId() function, which calculates a hash value using four parameters — the requester’s address, the identifier, the ancillary data, and the timestamp — to serve as the unique ID of the question, which is then recorded on-chain.

Subsequently, the contract emits an event named RequestPrice, notifying off-chain listeners that a new question request has been posted. Currently, UMA also provides an official front-end UI to display these pending questions awaiting answers.

Proposer Submits An Answer

If a question has been posted but no answer has been provided, anyone can call the proposePriceFor() or proposePrice() function to submit an answer. The answer, linked to the corresponding question ID, is stored on-chain.

It is important to note that the proposer submitting the answer must stake a bond. Each question only accepts the first proposer’s answer, after which the question’s status immediately changes to Proposed. Any other proposers who try to submit an answer later will have their answers rejected.

Afterwards, the OOV2 contract emits an on-chain event called ProposePrice to notify the outside world that a proposer has submitted an answer to a question. UMA’s official UI categorizes the question under the “Verify” section, publicly displaying detailed information about the question and attracting community members to review the answer.

The difference is that OOV2 adopts a permissionless system where anyone can submit answers and anyone can challenge them, whereas the OOV3 version adds an Escalation Managers module that allows project teams to set up whitelists in advance, effectively switching to a permissioned system.

Disputer Challenges the Answer

Continuing the analysis of OOV2’s workflow: if someone disagrees with the answer to a question, they can call the disputePriceFor() function to initiate a challenge. The question will then switch to a disputed status. The disputer must stake a bond, and if a subsequent vote rules that the disputer was wrong, they will be penalized.

It is important to note that a question can only be disputed once, meaning only the first disputer’s challenge will succeed.

Afterwards, the contract transfers the disputed question to the DVM arbitration module by calling a function named requestPrice(), passing the question information to VotingV2, which is the main contract of the DVM module, thereby initiating the voting and judgment process.

DVM Arbitration Module and “Commit-Reveal” Private Voting

The VotingV2 contract inserts the question awaiting a vote decision into the PendingPriceRequestIds queue, then emits an event to notify the outside world that a new question requires voting. Afterwards, the UMA official UI publicly displays that the question’s answer has been disputed and needs to be decided by vote.

According to UMA’s official requirements, voters must first stake UMA tokens and then cast votes on the pending issues. UMA stakers can currently earn an APY of up to approximately 20%. UMA continuously issues new tokens to maintain this high APY, attracting users to stake tokens and participate in voting.

To prevent voter inactivity, stakers who fail to vote are penalized 0.1% of their staked tokens for each missed issue. Additionally, voting results that do not match the final outcome also incur a 0.1% penalty (previously 0.05%; the penalty rate was increased to 0.1% in the second half of 2024).

To prevent voters from deliberately influencing others’ voting tendencies, UMA employs a two-phase “Commit-Reveal” privacy voting system. In the Commit phase, voters submit a hash on-chain, which does not directly reveal their voting choice. After the Commit phase ends, voting is paused and the Reveal phase begins, during which voters decrypt their votes to prove that their revealed vote corresponds to the previously submitted hash.

In other words, voters cannot see others’ voting choices during the voting period; the votes only become visible after the voting window closes.

According to the UMA code, during the Commit phase, voters must upload a hash on-chain through the commitVote() function. This hash is generated off-chain using the keccak256 algorithm, with the input containing a parameter named price, which represents the answer you believe to be correct.

In binary qualitative scenarios, price can be either True or False, while in pricing or other numeric scenarios, price can be a number.

Additionally, the input used to generate the hash includes an off-chain random value called salt, which prevents others from reverse-engineering your input by observing the hash. As long as others cannot predict your input during the Commit phase, they will not know your price.

In the subsequent Reveal phase, voters need to call the revealVote() function and provide the inputs used to generate the hash, including the voting information price. The contract will verify whether your input matches the previously submitted hash. If the verification passes, the vote will be counted.

After the Reveal window closes, vote counting automatically ends, and theoretically the entire workflow is nearing completion. However, it’s important to note that smart contracts within the EVM cannot initiate actions on their own — they require external calls to trigger functions. Therefore, the finalization stage requires someone to call the settle() and settleAndGetPrice() functions, which change the status of the Requester’s question to “settled” and return the resolved answer to the caller.

Before settling, the smart contract determines the correct answer based on the on-chain voting results. As mentioned earlier, voters submit a custom price during the voting phase. The contract counts which price received the most votes and designates that as the valid answer.

When counting votes, the system sums the staked tokens of participating voters, where one UMA token equals one vote. A sufficient total number of votes must be collected (currently, the default requirement is more than 5 million total votes, with over 65% of staked UMA supporting the same answer).

Subsequently, the contract can reward or penalize the Proposer, Disputer, and Voters based on the voting outcome. This requires calling the updateTrackers() function, which is typically triggered by specialized Keeper nodes.

Furthermore, if no one disputes the Proposer’s answer, the voting process is not required. The OOV2 contract can independently handle the entire process from question submission to finalizing the answer without involving the VotingV2 contract. This design simplicity is one of UMA’s distinctive features.

What are the Problems/Issues with UMA?

1. UMA’s security model clearly does not align with its official claims.

In the UMA whitepaper and Medium articles, the UMA team has claimed that the security premise is that the cost of malicious behavior exceeds the profit from it. They gave an example:

Assuming the total profit from a voting attack is $100 million, to ensure security, the cost of obtaining 51% of the voting power must remain above $100 million in the long term. However, in reality, UMA tokens once reached over $40 but are currently priced around $1.3, a drop of more than 95%. The project team obviously has not implemented effective price support.

Secondly, because UMA’s penalty for incorrect voting is very low (currently only 0.1%), voters can always submit results inconsistent with the facts. If the attack succeeds, they can sell their tokens afterward, so the actual cost of malicious behavior does not follow the security model described above.

Theoretically, attackers could bribe or rent tokens from voters (similar to bribing or renting mining power to launch a 51% attack in Bitcoin) without directly buying tokens. The cost of obtaining over 50% of the staked tokens would thus be much lower than UMA’s official estimates.

Moreover, according to data from May 2025, UMA officially raised the voting threshold to 65%. With fewer than 24 million UMA tokens staked and eligible to vote, an attacker controlling about 15.6 million tokens could manipulate the oracle. At the current UMA price of $1.3, those tokens would be worth around $20 million.

Meanwhile, according to UMA’s own publicity, the total assets on multiple platforms connected to the UMA oracle exceed $1.4 billion. Clearly, the potential profit from malicious behavior far exceeds the cost.

2. UMA’s privacy voting has limited effectiveness.

UMA’s “Commit-Reveal two-stage privacy voting” method directly copies an idea from Austin Thomas Griffith on Gitcoin. In theory, this approach encrypts votes during the commit phase and decrypts them after voting ends, which can protect voter privacy. However, to prevent insufficient vote counts, UMA added a “Roll” (rolling) mechanism.

If the collected votes in the current round are insufficient, another voting round begins. At this point, new voters can see the revealed votes from previous rounds, which clearly opens the door for manipulation.

Consider this scenario: Suppose there are 20 million staked UMA tokens, and 10 million votes are required to finalize an answer (one staked UMA token equals one vote). The question is “Will Elon Musk be assassinated in 2025?”

After the first round of voting, 8 million votes say “yes,” 8 million say “no,” so no answer reaches the 10 million vote threshold. The system then automatically starts a second round. If the remaining 4 million votes are controlled by a whale, that whale can vote whichever way benefits them financially, without regard for the truth.

Clearly, the privacy voting mechanism only works effectively if enough votes are gathered in the first round. If not, privacy protection is effectively lost.

Furthermore, although votes aren’t visible on-chain during the commit phase, manipulators can still announce on social media that they will vote a certain way or collude privately with other large holders to influence community sentiment.

In the Ukrainian mining farm dispute case, although the media widely believed a whale named borntoolate decided the final answer by controlling 5 million UMA (about 25% of staked UMA), private collusion behind the scenes likely played a role. Therefore, UMA’s privacy voting is only a superficial fix and cannot efficiently prevent malicious behavior.

If the protocol relies on official intervention to punish malicious voters, it only sinks deeper into a self-perpetuating spiral. As noted at the beginning of this article, resorting to human intervention to address issues caused by human behavior is essentially trying to solve a governance problem with more governance — a cycle that inevitably leads to challenges around authority, power distribution, and trust. Ultimately, this approach may be less effective and more problematic than simply abandoning such manual intervention altogether.

Solution: Replacing Humans with AI Agents

Facing the above pain points, the industry has begun to explore introducing AI Agents to perform oracle adjudication, thereby reducing reliance on human voting governance. However, a major drawback of AI Agents is their tendency to produce hallucinations. According to Chainlink’s official test results, an AI oracle based on GPT-4o achieves about 84% accuracy when judging complex political events, which is still far from extremely high precision. Although this accuracy is expected to improve with iterations of large language models, errors may still occur.

In response, the DeepSafe team believes that decentralized verification can prevent errors from a single AI Agent. By leveraging DeepSafe’s existing decentralized verification network, CRVA, we can integrate each CRVA node with the deep search capabilities commonly used by large AI models.

For example, CRVA node 1 could integrate DeepSeek, CRVA node 2 could integrate ChatGPT, and CRVA node 3 could integrate Grok. This way, each CRVA node becomes an independent AI Agent, and we take a weighted average of the answers submitted by each AI Agent to produce a decentralized verification result.

Specifically, the CRVA network uses a cryptographic lottery algorithm to randomly select a group of proposer nodes. These proposers, when submitting their results, must provide sufficient reasoning steps, context, and intermediate evidence — collectively called a “verifiable reasoning path.” Other nodes within the CRVA network can use this information to independently audit the reasoning process by invoking their local AI models. Finally, all nodes can collectively sign off on the proposer’s answer, thereby achieving decentralized verification.

(Introduction to CRVA: Reflections on the Importance of Trustless Custody in Light of the $unibtc Freeze Incident)

Additionally, we can combine the previously discussed UMA oracle design by allowing humans to vote under normal circumstances without CRVA intervention. However, if someone suspects that the voting results have been manipulated, AI and CRVA can step in to audit the voting outcome and impose heavy penalties on those who voted incorrectly.

Fearing the AI’s judgment capability and the potential for substantial fines, voters should be deterred from casting votes for incorrect answers. Since the CRVA network is highly decentralized and inherently more neutral than human governance, it can significantly mitigate the risks of centralized manipulation.

In the next article, we will provide a more detailed discussion on the implementation approach of AI oracles and the specific issues involved. We invite everyone to stay tuned!

Source: DeepSafe Research

On April 23, 2025, a user by the name of Brain sought help on Twitter through a friend, reporting that over $100,000 worth of $unibtc — an asset issued by @Bedrock_DeFi become inaccessible during an arbitrage attempt on a Bitcoin layer 2 network. The user claimed that the official Bedrock team had blocked his ability to exit the position.

Technical Analysis: Centralized Gatekeeping in the $unibtc Incident

According to a firsthand account from the user, identified as W, the incident began on April 17. He observed an abnormal price deviation between $unibtc and $BTC on a specific Bitcoin layer 2 chain, with $unibtc temporarily depegged from Bitcoin. Believing this depeg to be short-lived and expecting a swift re-pegging, W identified a potential arbitrage opportunity. Acting on this assumption, he bridged a portion of his $BTC to the layer 2 network, exchanged it for $unibtc, and planned to sell once the asset re-aligned with $BTC.

Within just 24 hours of the depeg, $unibtc had already re-pegged to $BTC. However, when W attempted to liquidate his position, he discovered that the unibtc-BTC liquidity pool on that layer 2 network had been withdrawn — by none other than the Bedrock team. This pool had served as the sole secondary market exit route for $unibtc on the chain. With no option to sell his holdings on the current network, W attempted to bridge the $unibtc to another chain.

He soon located the only available cross-chain bridge supporting $unibtc on that network, named Free. However, the transaction interface returned a warning: “This transaction requires project owner signature authorization.” Upon contacting the Free bridge’s customer support, W was informed that the multisig keys for unibtc cross-chain transfers were fully controlled by Bedrock. Without Bedrock’s explicit authorization, users could not bridge their $unibtc off-chain.

Left with no alternatives, W reached out directly to Bedrock representatives. Their initial response was: “We can allow you to withdraw your principal, but whether or not you can withdraw any profits made from arbitrage will be subject to further review.”

At this point, W came to the unsettling realization that all exit paths for $unibtc on this layer 2 network had been effectively severed. His $unibtc holdings — valued at approximately $200,000 — were now “temporarily frozen”: he could neither sell them on-chain nor bridge them elsewhere. Feeling helpless, W shifted his focus solely to retrieving his initial principal.

However, communication from Bedrock representatives grew increasingly ambiguous. They refused to provide a clear timeline for the return of W’s principal and offered no written commitments. Instead, they cited vague justifications such as “risk assessments” and “technical investigations” to delay action.

After a prolonged period of stalling, Bedrock eventually attributed the $unibtc depegging to large-scale borrowing and subsequent dumping of $unibtc on the LayerBank platform. Bedrock representatives then deflected responsibility, suggesting that W should “hold LayerBank accountable.” However, W’s attempts to contact LayerBank went unanswered for an extended period.

Left with no other recourse, W turned to Twitter and sought help through friends. After more than two weeks of public exposure and pressure, both LayerBank and Bedrock finally responded and took action — ultimately enabling W to recover his assets.

W’s case is not an isolated incident. According to feedback from other affected users, Bedrock had previously employed similar tactics to cut off unibtc exit channels, effectively resulting in the “functional freezing” of user-held assets. While this report does not speculate on the motives behind such actions, it aims to highlight — strictly from a technical standpoint — the critical importance of eliminating centralized control in custody systems and preventing malicious gatekeeping in decentralized finance infrastructure.

The Elusive Pursuit of Trustless Custody

In reviewing the above case, it becomes evident that Bedrock — both the issuer of unibtc and the initial LP for the token’s trading pairs — holds inherent control over the exit routes in the secondary market. This centralized authority is difficult to neutralize purely through technical means and would require robust governance frameworks to be properly constrained.

However, the deeper technical flaw was exposed in the refusal by the Free cross-chain bridge to process the user’s withdrawal request, an action clearly taken in collaboration with Bedrock. This reveals a critical weakness in $unibtc’s lifecycle — from issuance, to single-chain circulation, to cross-chain utility: the bridge, Free, is evidently a highly centralized infrastructure component.

A truly trustless bridge should be designed in such a way that even the bridge operator cannot prevent a user from exiting. Yet in the $unibtc incident, both Bedrock and the Free bridge wielded absolute authority, lacking any censorship-resistant mechanism that would allow users to withdraw assets independently.

Importantly, $unibtc is not an isolated case. There is a well-documented pattern across the crypto space — particularly in exchanges and bridge ecosystems — of cutting off users’ exit paths through centralized controls. For instance, in June 2022, the Harmony Horizon Bridge halted withdrawals for 57 different assets following a security breach. While such actions may appear justified on the surface, they nonetheless raise deep concerns about the potential abuse of centralized privileges.

The 2021 StableMagnet incident stands as a stark warning: the project team exploited a deliberately embedded backdoor to steal over $24 million. It took significant law enforcement efforts across Hong Kong and the UK, combined with assistance from the crypto community, to recover 91% of the stolen funds. This and similar cases underscore a critical point — any custody solution that fails to provide truly trustless services is ultimately vulnerable to catastrophic abuse.

Yet achieving trustlessness is far from straightforward. From payment channels and Discreet Log Contracts (DLCs), to BitVM and ZK Rollups, the industry has explored numerous technical paths toward minimizing reliance on centralized actors. These mechanisms significantly improve user autonomy and create more secure exit routes, but each comes with inherent limitations.

Payment channels, for example, require users to actively monitor counterparties for malicious behavior. DLCs introduce dependencies on oracles. BitVM offers a powerful framework, but its implementation cost is high and introduces its own trust assumptions. ZK Rollup escape hatches — while theoretically robust — can only be triggered after prolonged time windows and often require halting the entire Rollup, making them costly and impractical in real-world scenarios.

At present, no solution offers a perfect balance of security, usability, and decentralization in asset custody and exit mechanisms. Innovation remains urgently needed.

In the following section, DeepSafe Research introduces a novel custody framework designed by the DeepSafe protocol. This hybrid approach combines TEE (Trusted Execution Environments), ZK (Zero-Knowledge Proofs), and MPC (Multi-Party Computation) to deliver a trustless message validation and asset control solution. By carefully balancing cost, security, and user experience, it offers a reliable infrastructure layer for exchanges, bridges, and any other application requiring robust decentralized custody.

CRVA: Cryptographic Random Verification Agent

Today, the most widely adopted digital asset custody solutions rely on multi-signature (multisig) schemes or MPC/TSS (Multi-Party Computation / Threshold Signature Schemes) to validate asset transfer requests. These systems offer practical advantages: they are easy to deploy, cost-efficient, and enable fast message verification. However, their shortcomings are well known — they often lack sufficient decentralization and expose users to security risks.

The 2023 Multichain scandal is a case in point. Despite involving 21 MPC nodes, all were reportedly controlled by a single individual — a textbook Sybil attack. This incident clearly demonstrates that a system’s node count alone is not a reliable indicator of its decentralization or trustworthiness.

To address these inherent flaws in traditional MPC/TSS models, DeepSafe has developed the CRVA with several key innovations.

First, CRVA imposes an economic entry barrier: validators must stake assets to participate. The network will only launch its mainnet once it reaches approximately 500 staked nodes. Based on current projections, the total amount locked by these nodes will remain in the tens of millions of dollars or more, providing a strong financial security foundation.

Second, to enhance the efficiency of MPC/TSS signing while minimizing coordination overhead, CRVA employs a randomized selection mechanism. Every 30 minutes, a subset of 10 nodes is randomly chosen to act as verifiers. These nodes are responsible for validating user requests and producing the required threshold signatures to authorize asset movements.

To further mitigate risks of internal collusion or external attacks, CRVA introduces a novel Ring VRF (Ring Verifiable Random Function) combined with zero-knowledge proofs. This mechanism ensures that the identities of selected nodes remain hidden from the outside world, effectively shielding the system from preemptive targeting or manipulation.

Of course, this level of security is still not enough. Although the external world does not know who has been selected, the selected node itself knows, leaving room for potential collusion. To further eliminate the possibility of collusion, all CRVA nodes are required to run their core code in a Trusted Execution Environment (TEE), essentially placing the core tasks inside a “black box.” This approach ensures that no one can determine whether they have been selected, unless they manage to compromise the TEE hardware. However, given the current state of technology, this is exceedingly difficult to achieve.

The above outlines the fundamental design of DeepSafe’s CRVA scheme. In actual operation, nodes within the CRVA network must engage in frequent broadcast communications and data exchange. The detailed process is as follows:

1. Staking and Registration: Before joining the CRVA network, all nodes are required to stake assets on-chain. During this process, each node registers a public key, referred to as the permanent public key, which serves as a persistent identifier within the network.
2. Temporary Key Generation and ZK Proofs: Every hour, the CRVA network randomly selects a small subset of nodes. However, prior to selection, all candidate nodes must locally generate a one-time temporary public key. Along with this, they must produce a Zero-Knowledge Proof showing that the temporary public key is cryptographically linked to their on-chain permanent public key. In other words, each participant proves they are a valid candidate without revealing their specific identity.
3. Privacy-Preserving Random Selection: The use of temporary public keys serves a critical privacy function. If selection were made directly from the set of permanent public keys, the identities of the chosen nodes would be immediately revealed. By only exposing temporary public keys and selecting from that set, each selected node can confirm its own participation, but cannot determine the identities of other selected nodes. This ensures that selection remains verifiable while preserving anonymity.
4. Blind Generation of Temporary Keys: To further mitigate the risk of identity leakage, the CRVA protocol is designed such that even node operators are unaware of their own temporary public keys. These keys are generated entirely within the node’s TEE. Since the TEE operates as a secure, isolated hardware enclave, the node operator has no visibility into the internal computations, including the generated key.
5. Obfuscation and Relayer Decryption: Once generated, the temporary public key is immediately encrypted into an unreadable ciphertext within the TEE. This encrypted output is then transmitted to the external network. Only designated Relayer nodes, operating within their own TEE, possess the capability to decrypt these ciphertexts. Even then, Relayers cannot link decrypted temporary keys back to specific participants, preserving anonymity across the system.
6. Random Selection via VRF and Threshold Signing: After decrypting and aggregating all temporary public keys, the Relayers compile them into a set and submit this set to an on-chain VRF, which randomly selects a subset of nodes as verifiers. These selected verifiers are then responsible for validating user-submitted transaction requests. Upon successful validation, they collaboratively generate a threshold signature, which is subsequently submitted to the blockchain to authorize the transaction. (It is important to note that Relayer identities themselves are concealed and subject to periodic random selection, ensuring their operations remain trust-minimized and tamper-resistant.)

A natural question arises: if each node is unaware of whether it has been selected, how can the assigned work be executed? The answer lies in the TEE-based design mentioned earlier. Each node generates its temporary public key within its local TEE environment. Once the random selection process is complete, the list of selected temporary public keys is publicly broadcast across the network.

Each node can then pass this broadcast list into its TEE environment, where an internal verification is conducted to determine whether the node’s temporary key is included among the selected ones. Since this matching process also takes place inside the TEE, it preserves the confidentiality of both the identity of the selected nodes and the temporary keys themselves.

The core strength of DeepSafe’s approach lies in its architecture, where nearly all critical operations are executed within TEE hardware. From outside the TEE, it is virtually impossible to observe or interfere with what is happening inside. As a result, no individual node can determine who the selected verifiers are, effectively eliminating the possibility of collusion and malicious coordination. At the same time, this design significantly increases the cost and complexity of any external attack.

To compromise a DeepSafe-based CRVA committee, an adversary would theoretically need to compromise the entire CRVA network. Moreover, since each participating node is protected by TEE, the level of difficulty required for such an attack is dramatically elevated.

Integration of CRVA with Self-Custody Asset Management Solutions

In the previous section, we outlined the fundamental principles behind CRVA and explained how it achieves decentralized and trustless verification. Now, we will explore CRVA’s application in asset custody by examining HelloBTU, a Bitcoin-based algorithmic stablecoin.

As widely known, Bitcoin’s base layer does not support Turing-complete smart contracts, making it impossible to implement complex DeFi functionalities directly on-chain. As a result, most BTCFi solutions involve bridging Bitcoin to other blockchain ecosystems where it can interact with smart contracts.

HelloBTU follows a similar approach, with its smart contract infrastructure deployed on Ethereum. Users deposit BTC into a designated HelloBTU address, after which an official bridge transfers the BTC to Ethereum, enabling interactions with HelloBTU’s algorithmic stablecoin contract.

Suppose a user wants to deposit 10 $BTC into the HelloBTU platform. The operational process would be as follows:

1. The user transfers 10 $BTC to a Taproot address on the Bitcoin network.
2. Unlocking the $BTC from this address requires a 2-of-2 multisignature scheme, where:

One signature is provided by the user.

The other signature is generated by CRVA.

Several scenarios arise under this setup:

• Standard Redemption: After a user deposits 10 $BTC into the designated taproot address and mints stablecoins against it, they may choose to redeem their $BTC at a later time. In this case, both the user and CRVA generate signatures to co-authorize the unlocking of the $BTC, which is then returned to the user’s address. If CRVA fails to respond for an extended period, the time-lock mechanism activates. Once the lock period expires, the user may unilaterally retrieve the $BTC without CRVA’s involvement. This process, referred to as User-Initiated Redemption, ensures user autonomy and protects against prolonged service downtime.
• Liquidation of Collateral: The user’s collateralized $BTC is liquidated due to under-collateralization. The $BTC should then be transferred to a Taproot address controlled solely by CRVA (i.e., a CRVA one-way channel). While the user is expected to cooperate in signing the release, they may refuse to do so. In such cases, the $BTC becomes temporarily frozen — neither party can access it. Once the shorter liquidation time-lock expires, CRVA is authorized to unilaterally transfer the $BTC to its custody address. It is worth noting that the liquidation time-lock is deliberately set shorter than the user redemption time-lock, ensuring that, in cases of dispute or inaction, liquidation takes precedence. This asymmetry serves as a deterrent against user misconduct and promotes orderly liquidation.
• Misbehavior by CRVA: Since CRVA is a decentralized, autonomous network of validator nodes operating within TEE environments, the possibility of malicious behavior is minimized. As long as the software executed at genesis contains no malicious logic, CRVA should not actively refuse user redemption. Therefore, the probability of CRVA misconduct is considered negligible.
• CRVA Downtime Due to Force Majeure: In the event of unforeseen disasters (e.g., large-scale power outages or natural disasters) that incapacitate a significant portion of the CRVA network, the user may still recover their assets via the user-initiated redemption pathway. This contingency reinforces the assumption that, provided CRVA is sufficiently decentralized (as previously discussed), it poses no centralization risk.
• Custody in the CRVA One-Way Channel: When BTC is transferred into the CRVA one-way channel (typically as a result of collateral liquidation), ownership is considered to have passed to the liquidator. The liquidator can initiate a withdrawal request. Upon CRVA’s approval, it will sign and release the corresponding BTC to the liquidator’s address. If CRVA fails to respond in a timely manner, a secondary safeguard activates: after the liquidation time-lock expires, the BTC is transferred to an address governed by a DAO. This multi-signature-controlled DAO comprises reputable ecosystem players, security firms, and investment institutions, and was established to ensure no single party can abuse control.

In summary, we have outlined DeepSafe’s self-custody solution for Bitcoin assets. The same principles apply to ERC-20 assets, and we will not repeat them here for brevity. Regarding the previously mentioned $unibtc freeze incident, if the unibtc cross-chain bridge had implemented the CRVA-based self-custody solution, it would have been nearly impossible for the asset issuer to exercise unilateral control over the assets.

Moving forward, DeepSafe will continue to iterate on its self-custody technology for both Bitcoin and ERC-20 assets. We encourage everyone to stay engaged and follow our ongoing progress!

Authors: DeepSafe Research Team & GodRealmX

The past two months have undoubtedly been a tumultuous period for the Crypto industry. Following Trump’s aggressive tariff impositions after taking office, the cryptocurrency market rapidly shifted from bullish to bearish, leaving countless investors with positions reduced by half. Unfortunately, this misfortune has befallen not only retail investors but also major institutions. The recent successive theft cases involving Bybit and Infini have shocked the entire industry, fully exposing the fragility and inadequacy of security infrastructure within the Web3 ecosystem, serving as a sobering wake-up call.

These two incidents resulted in staggering losses exceeding $1.5 billion, even subjecting the Safe wallet itself to FUD. While people grew skeptical about smart contract wallets and multi-signature solutions, they also recognized the dual dilemma facing Web3 in terms of asset security: sophisticated attacks from external hackers and internal embezzlement by trusted personnel — both seemingly impossible to fully guard against. Without a fundamental redesign of asset custody tools within the industry, incidents similar to the Bybit and Infini thefts will only become more frequent.

In response, the DeepSafe Research Team has analyzed the issues exposed in the Bybit theft case, attempting to reveal the pain points and potential risks of existing asset custody tools, as well as how DeepSafe’s Cryptographic Random Verification Agent (CRVA), built on MPC, ZKP, and TEE technologies, can create more comprehensive asset management tools.

Issues with Traditional Smart Contract Wallets like Safe in the Bybit Theft Case

According to post-incident analysis, in the Bybit theft case, North Korean hackers successfully bypassed multi-signature verification by exploiting “blind signature vulnerabilities” and “spoofed signature interfaces.” Bybit’s cold wallet employed Safe’s 3/4 multi-signature structure, involving multiple signers, including cold wallets and hardware wallets controlled by Bybit. Under normal circumstances, operators managing the assets would receive internal notifications, log into the signature interface to verify transaction details, and then sign transactions using hardware wallets.

However, according to analysis from SlowMist, attackers infiltrated the AWS infrastructure hosting Safe’s frontend code and injected malicious code specifically targeting Bybit’s multi-signature wallet.When multi-signature wallet operators initiated transactions through the Safe frontend, the displayed information appeared normal, but the actual transaction content had been tampered with, altering critical settings in the Safe wallet contract used by Bybit (such as replacing the contract address corresponding to delegateCall), giving hackers control over assets in the wallet.

To help everyone better understand the key aspects of this attack, we will briefly explain Safe wallet’s contract deployment model and the commonly used delegateCall in Solidity.

Let’s assume there are three contracts in the current system: Contract A, Contract B, and Contract C, where Contract B calls Contract C during execution. If Contract A uses DelegateCall to interact with Contract B, then Contract A can execute Contract B's code within A's environment. This means that the code logic in Contract B can modify data stored in Contract A.

If Contract B’s code includes a call to Contract C, then Contract A will also initiate a call to Contract C when running Contract B’s code. However, Contract C cannot directly modify the content stored in B and A; it can only perform calculations on the data actively passed to it by B and A and return results.

We can view DelegateCall as a pattern that borrows another contract's code to execute within the local environment.

Building on the foundation of DelegateCall, Ethereum developers invented the proxy deployment pattern. For example, when new users create an account with Safe wallet, they need to deploy specialized smart contracts on-chain to meet various complex requirements. However, the Safe wallet as a whole contains extensive logic code, and deploying all this code directly in a single contract would require substantial transaction fees.

To reduce costs, the Safe team deploys their own contracts containing this complex code, and new wallet users can use DelegateCall to execute the Safe contract code in their local environment. This way, users' newly created wallet contract accounts can be kept as minimal as possible.

From a developer’s perspective, we typically refer to the contract deployed by users as the proxy contract, while the contract deployed by Safe is called the logic contract. The most important variable in the proxy contract is the target address for DelegateCall, which should theoretically point to the logic contract address deployed by the Safe team.

In the Bybit attack incident, hackers tampered with the transaction content initiated by Bybit’s cold wallet operators through a malicious frontend, replacing the logic contract address called by DelegateCall with a malicious contract deployed by the hackers themselves. At this point, Bybit’s Safe wallet account effectively lost its multi-signature functionality, and the hackers then stole all ETH assets from Bybit’s Safe wallet through a sweepETH function in the malicious contract.

During the Safe wallet signing process, signers actually sign the transaction data hash (dataHash), without seeing the plaintext transaction content. Therefore, they cannot determine the specific content being signed and can only trust the information displayed by the Safe frontend. The attackers exploited this by using a counterfeit Safe frontend to trick Bybit's asset managers.

Beyond this Bybit theft case, there have been multiple supply chain and signature process attacks related to Safe wallets throughout history: the 2021 Habitat theft case, the 2024 Radiant Capital multi-signature wallet theft case, and the 2024 WazirX theft case were all related to this type of phishing attack and social engineering infiltration, where victims were tricked into signing malicious transactions. Even though the Safe smart contract itself may not have internal vulnerabilities, attackers shift their focus to malicious frontends, phishing websites, malicious browser extensions, trojan programs, and other methods to defraud signers.

Summarizing these incidents, we can identify the following issues:

1. All transactions in Safe wallets are signed using hashed results, which is not user-friendly for most ordinary users, making it difficult to determine the content being signed;
2. Safe wallets often require users to use specialized facilities to coordinate and aggregate multi-signatures before submitting them all at once. Generally, users choose the Safe frontend as the facility for aggregating signatures, but the Bybit hack occurred precisely because of problems with the Safe frontend;
3. For most users, Safe wallet accounts use proxy deployment during creation, a deployment model that carries certain risks — for instance, hackers induced Bybit operators to replace the logic contract address through a malicious transaction.

Among these issues, problem 2 is particularly severe. The essence of recent numerous Safe multi-signature theft incidents is due to problems with multi-signature coordination and aggregation platforms. Of course, users are also affected by problems 1 and 3. Although some professional tools can prevent these vulnerabilities, they cannot provide fundamental protection. The recent Infini theft case also revealed the dangers of internal embezzlement. To guard against such risks, institutional teams should adopt multi-factor authentication to increase operational thresholds and strengthen security protection for signing devices.

How, then, can we address the deficiencies in existing asset custody tools like Safe wallet? Or rather, how can we both resist external attacks and prevent internal theft? Based on this need, DeepSafe’s CRVA (Cryptographic Random Verification Agent) solution has emerged. CRVA, through a series of supporting facilities including decentralized signature systems, MPC, ZKP, TEE, and intelligent risk control, can fundamentally build more comprehensive multi-signature solutions and self-custody tools, providing protection for institutional users and whale investors.

Let’s analyze in detail how DeepSafe’s CRVA solution can enhance the security of multi-signature systems.

CRVA-based Multi-signature System: Adding a Dedicated Decentralized Verification Network to Ordinary Multi-signatures

First, DeepSafe has adjusted the verification threshold of traditional multi-signature wallets like Safe. It allows users to continue using well-known signature aggregation facilities like Safe, but adds an extra layer of verification on top of this. After you submit the aggregated multi-signature to the blockchain, the transaction content and the aggregated signatures are submitted to an on-chain Cosign contract. At this point, the off-chain CRVA network captures the transaction information and signatures submitted by users and verifies their validity.

The CRVA network contains numerous nodes, with the core components of node clients running within TEE devices, which verify the content submitted to the Cosign contract according to user-preset restrictions. For example, users might set a rule not allowing single transfers exceeding 100 ETH, so CRVA would first determine whether a transfer exceeds 100 ETH, and would not approve it if invalid.

If the majority of CRVA nodes consider the transaction valid, they trigger threshold signature, sign the verification result, and submit the signature to the Cosign contract. At this point, the Cosign contract already has both the cold wallet signature submitted by the user and the MPC signature submitted by CRVA, satisfying the requirements of 2FA (two-factor authentication). Only then will the Cosign contract aggregate these signatures and call the specialized code logic to execute the transaction. Of course, if the user frontend submits transaction information to Cosign that doesn’t comply with preset rules, CRVA will refuse to sign. If the Cosign contract doesn’t collect the threshold signature from CRVA, the transaction will ultimately be rejected even if users have submitted multi-signatures using cold wallets.

At this point, we can understand that DeepSafe essentially adds an extra layer of verification on top of traditional multi-signature verification solutions, meeting the requirements of two-factor authentication. The difference is that this additional verification is guaranteed by CRVA, a decentralized network composed of multiple technologies including TEE, ZKP, and MPC.

The key question now is whether CRVA itself is secure? Can it prevent node collusion or external hacker attacks?

DeepSafe’s approach is as follows: First, we build a decentralized validator network through asset staking; after the network reaches sufficient scale, for example, integrating several hundred or thousand devices, they regularly randomly select nodes from the network to serve as CRVA validators. DeepSafe uses a specially developed Ring-VRF algorithm combined with ZK to hide the selected validators’ identities among all candidates, simplified as follows:

1. Before entering the CRVA network, all nodes must first stake assets on-chain and leave a public key as registration information. This public key is also known as the “permanent public key.”
2. Every hour(the rotation time can be set), the CRVA network randomly selects several validators through a specific Ring-VRF algorithm to verify user transaction information mentioned above. But before this, each potential candidate must generate a one-time “temporary public key” locally, while generating a ZKP to prove that this “temporary public key” is associated with the “permanent public key” recorded on-chain; in other words, they prove through ZK that they exist within the candidate list, but without revealing which specific person they are;
3. What is the purpose of the “temporary public key”? It’s precisely for privacy protection. If selections were made directly from the “permanent public key” set and the results published, everyone would immediately know who was selected, significantly compromising security. If everyone temporarily submits one-time “temporary public keys,” and selectors are chosen from this set, at most you only know if you yourself were selected, because you don’t know which other selected temporary public keys correspond to whom.
4. This isn’t the end. The CRVA network intends to go further: directly prevent you from knowing what your own “temporary public key” is. How is this accomplished? Simply by encrypting the plaintext temporary public key within the TEE before sending it out as “scrambled code,” and then only specific Relayer nodes can decrypt these temporary public keys, though of course the decryption process also happens within the TEE, so even the Relayer itself doesn’t know which temporary public key corresponds to which candidate.
5. After the Relayer decrypts all “temporary public keys” generated locally in TEE by everyone, it aggregates them, submits them to the on-chain VRF function, which selects the winning validators who form the verification committee to verify transaction information published by users.

With this, the overall logic becomes clear: We regularly randomly select several validators from the temporary public key collection to serve as the current verification agent committee, a design named CRVA (Cryptographic Random Verification Agent). Since each node runs TEE, with all core computation processes hidden within the TEE environment, no one knows what their own temporary public key is, nor anyone else’s, no one knows exactly who comprises the current verification agent committee, fundamentally preventing internal collusion or external compromise.

Some might ask, if each node doesn’t know whether it belongs to the committee, how can the committee collaborate to generate threshold signatures? This is easily resolved: we simply broadcast to the entire CRVA network, sending the committee list to everyone. Each node’s temporary public key is encapsulated in its local TEE, which can verify internally against the committee list to determine if it has been selected.

The core of DeepSafe’s solution is that almost all important activities take place within the TEE, making it impossible to know what is happening from the outside. No node knows which validators have been selected, fundamentally preventing collusive attacks and significantly increasing the cost of external attacks. Theoretically, attacking a DeepSafe-based CRVA committee would require attacking the entire CRVA network.

In the CRVA architecture diagram shown earlier, we can see the existence of an Escape Hatch — what is this for? It’s actually similar to Ethereum ZK Rollup’s forced exit/escape pod. Since CRVA only executes actions based on transaction content submitted to the chain by user frontends and according to established rules, no individual or organization can collude with the CRVA system. However, in extreme circumstances, if many CRVA nodes go offline, there needs to be a fund escape exit to safely withdraw assets from the vault.

The Escape Hatch shown in the diagram can have its specifics customized by users, but by default includes a time lock. Users can trigger the escape pod functionality using dedicated keys or through professional institutions to request the transfer of funds from the vault. However, the time lock provides a delay window — for example, the forced exit of funds only becomes effective after 7 days. This prevents hackers who may have stolen the user’s escape hatch keys from immediately absconding with the funds. During the time lock restriction period, users typically have ample time to revoke their fund escape requests.

Social Media:

Website丨Twitter丨YouTube丨Channel丨Community丨Discord

Case Review: Lessons from the Bybit Incident

On February 21, 2025, the North Korean hacker group Lazarus Group infiltrated Safe{Wallet}’s front-end interface, tricking Bybit operators into signing malicious transactions, resulting in a $1.5 billion loss. This incident exposed two critical vulnerabilities in the industry:

1. Blind Signing Risks with Hardware Wallets: Operators cannot verify the actual content of transactions, forcing them into “blind signing.” Attackers can manipulate the front-end interface to display falsified transaction details on hardware wallets. Relying solely on front-end information allows malicious contracts to be “legitimately” authorized.
2. Single-Point Dependency in Multi-Sig Systems: The absence of last-line defenses such as address whitelisting and tiered approvals enables malicious transactions to execute directly. All signers share the same infrastructure (e.g., Safe{Wallet}), meaning a compromised front-end leads to total system collapse. High-risk operations (e.g., private key changes) lack real-time monitoring and cooling-off period mechanisms.

Traditional solutions that rely solely on hardware wallets combined with multi-signature mechanisms are no longer sufficient to counter targeted attacks on the human-machine interaction layer.

DeepSafe Solution:

Decentralized Signature System

1. Initialization：

● Configure a 3/4 multi-signature structure in Safe{Wallet}, where signers include the exchange’s cold wallets (Cold Wallet 1, Cold Wallet 2, Cold Wallet 3) and DeepSafe’s CRVA (Signer 4).

2. Withdrawal Request：

● When the exchange needs to transfer assets from a cold wallet to a hot wallet, the cold wallet holders (Signer 1 and Signer 2) first initiate the signing process (Step 1).

3. Decentralized Verification：

● Within DeepSafe’s CRVA, TEE nodes (TEE Node 1, 2, 3) independently retrieve the signed events from Signer 1 and Signer 2. Using MPC (Multi-Party Computation) protocols, they collaboratively generate a threshold signature, which is then submitted as Signer 4’s approval to the on-chain Safe{Wallet} (Steps 2, 3, and 4).

Technical Advantages

1. Security: The Final Line of Defense Against Targeted Attacks

● Self-Custody of Assets:：

DeepSafe holds only a single signature authority, ensuring clients retain ultimate control over their assets. This eliminates risks of asset control being compromised.

● Smart Risk Control Engine (Programmable Rules)：

Address Whitelisting: Transfers are restricted to pre-approved addresses (e.g., bound hot wallet addresses), blocking any funds sent to unknown destinations. For example, if an attacker attempts to withdraw to an unwhitelisted address like 0x8a3…d4f, the transaction is automatically rejected.

Tiered Approvals & Anomaly Monitoring: Multi-level approval rules based on transaction amounts and asset types (e.g., transactions exceeding 1,000 BTC require confirmation from risk control, finance, and executive teams).

Cooling-Off Period: High-risk operations (e.g., contract upgrades, permission changes) are subject to a mandatory 24–48 hour delay, creating a window for manual review..

● Decentralized Signing System：

• TEE nodes in the CRVA are dynamically rotating and anonymized, preventing hackers from establishing attack vectors or gaining node control through targeted exploits. MPC (Multi-Party Computation) distributes signing authority across multiple nodes. A valid signature requires consensus from at least two-thirds of nodes (configurable threshold), ensuring system-wide security even if a single node is compromised.

2. Flexibility

● DeepSafe does not replace existing hardware wallet + Safe{Wallet} multi-sig systems. Instead, it operates as an independent security enhancement layer, complementing current infrastructure.

● Exchange employees continue using familiar interfaces to initiate transactions and approvals. DeepSafe performs automated backend verification with zero user experience disruption, requiring no operational changes.

We are thrilled to unveil our evolution from Bool Network to DeepSafe, marking a significant leap forward in our mission to secure the digital future. Our journey, which began with safeguarding Bitcoin infrastructure, now pioneers the forefront of AI verification. DeepSafe embodies our expanded vision: serving as the core verification infrastructure for both blockchain and AI.

To Our Valued Verifiers: Your role has transformed. You are now the vanguards of Web3’s future, extending beyond Bitcoin’s cross-chain interactions to become integral in shaping the trustworthy evolution of AI agents. As AI reshapes the digital landscape, DeepSafe will serve as the bedrock for ensuring their integrity and reliability.

This isn’t merely an upgrade; it’s a Revolution in our approach to security and verification. Together, we are forging a safer digital world for everyone. Together, we are making history.

Let’s dive into what makes DeepSafe special:

1/7 At the heart of DeepSafe lies our groundbreaking Crypto Random Verification Agent (CRVA). This innovation creates a dynamic verification framework that leverages cryptographic randomness for secure AI agent operations, ensuring autonomous development while maintaining rigorous security and verifiable behavior through threshold signatures and secure key management.

2/7 DeepSafe integrates three cutting-edge technologies: Multi-Party Computation (MPC) for collaborative data privacy, Zero-Knowledge Proofs (ZKP) for transparent verification, and Trusted Execution Environment (TEE) for hardware-level isolation. This comprehensive security stack creates a secure and private foundation for AI agent operations.

3/7 Security Reimagined:
• Hardware-level TEE protection
• Threshold signature mechanisms
• Cryptographic randomness for enhanced security

4/7 Privacy First:
Our MPC and ZKP integration means your AI agents can operate and be verified without exposing sensitive data.

5/7 Efficiency Unleashed:
• Parallel processing capabilities
• Distributed task allocation
• Minimal verification costs
• Seamless blockchain integration

6/7 Seamless Token Migration:

• 1:1 token exchange guarantee
• $tBOL → $tDEF conversion
• $BOL → $DEF conversion
• Zero-loss token transition
• Secure asset preservation

7/7 DeepSafe is not just an upgrade; it’s a paradigm shift in how we approach AI agent security and privacy. We invite you to join us in building a future where digital trust and security are the foundation of progress.

Welcome to the era of DeepSafe — a Revolution in Verification Security!

The rapid evolution of artificial intelligence has brought us to a crucial crossroads in AI agent development. While AI agents are designed to serve human interests, the current paradigm of heavily restricted AI systems significantly limits their potential for autonomous learning and evolution. This creates a fundamental paradox: how can we enable AI agents to develop true autonomous capabilities while ensuring their actions remain aligned with human interests and safety parameters?

This paradox manifests in what we call the AI agent autonomy trilemma: the need for autonomous development capabilities, operational security, and reliable behavior verification. Traditional approaches typically sacrifice autonomy for security, or security for autonomy, creating systems that either lack the ability to evolve or pose potential risks to their operating environment.

The technical architecture of Bool Network represents a significant advancement in secure AI systems, integrating three fundamental technologies to create a secure and private environment for AI agent operations. Multi-Party Computation enables collaborative computation while protecting data privacy, allowing multiple nodes to complete verification tasks without exposing private information between parties. Zero-Knowledge Proofs provide transparent verification of AI agent behavior without revealing sensitive operational details, generating tamper-proof verification proofs that build trust among users and regulators. The Trusted Execution Environment offers hardware-level isolation, ensuring data and code confidentiality and integrity while preventing external tampering and attacks.

At the heart of Bool Network’s innovation lies its Cryptographic Random Verification Agent (CRVA) network, comprising thousands of permissionless TEE nodes. This network leverages cryptographic randomness mechanisms to dynamically assign verification tasks and ensure fair, unpredictable validation processes. The system’s architecture delivers comprehensive security through hardware-level TEE protection and cryptographic security measures, while maintaining privacy through MPC collaboration and ZKP verification. The implementation of cryptographic random node selection provides dynamic defense against potential threats.

The core verification process involves several key steps managed by the CRVA. The system handles on-chain data verification, consensus generation, and decision-making processes. Parallel to this, it manages message delivery and asset mapping, culminating in transaction execution. A separate verification path handles input and output verification, ensuring comprehensive coverage of all operational aspects.

A unique feature of the system is its private keyshare handover mechanism between epochs. When transitioning from one epoch to another (for example, from Epoch 1 with nodes A, B, C to Epoch 2 with nodes X, Y, Z), the system implements a secure handover protocol for private key shares. This rotation mechanism ensures continuous security while preventing any single group of nodes from maintaining prolonged control over verification processes.

The trading agent layer mirrors the CRVA’s structure with intelligent decision-making, task execution, result observation, and memory storage capabilities. This layer interacts with an on-chain/off-chain behavior large model to ensure consistent and reliable operation. The entire system is designed to support AI agents’ interaction with blockchain infrastructure, where agents can submit tasks and manage their keys through the CRVA network.

In practical implementation, when an AI agent needs to perform operations, it interacts with the system through two primary channels: key management and task execution. The CRVA network handles these requests by coordinating among its TEE nodes, with results being written to the blockchain through smart contracts. This architecture ensures that all operations are both secure and verifiable, with the TEE nodes providing hardware-level security guarantees while maintaining the system’s decentralized nature.

The strength of this implementation lies in its combination of distributed architecture, secure hardware (TEE), and cryptographic protocols. The CRVA network’s ability to dynamically select and rotate verification nodes, combined with secure key management and verification processes, creates a robust framework for AI agent operations. This design not only ensures security and privacy but also maintains the system’s scalability and reliability through its distributed nature and fault-tolerant architecture.

The system’s distributed architecture ensures robust fault tolerance through threshold signature mechanisms and dynamic node rotation, while its modular design enables flexible scaling to accommodate different operational requirements. Bool Network achieves high efficiency through distributed task allocation and parallel processing capabilities, with the combination of TEE and ZKP technologies minimizing verification costs. The integration with blockchain, smart contracts, and Web3 infrastructure ensures seamless compatibility with existing systems, while the trustless management approach significantly reduces operational overhead.

The implementation process follows a streamlined approach where AI Agents can customize their security parameters according to specific needs. When an AI Agent initiates the process, they first specify the desired number of nodes and threshold signature requirements. For instance, an Agent might select three TEE nodes with a threshold signature requirement of two. The system then employs the Ring-VRF algorithm to randomly select nodes from the network, forming a dedicated CRVA. Using MPC technology, the Agent’s private key is split into shares and securely stored within the TEE environment of each selected node. During operation, the threshold signature mechanism ensures that signatures require participation from the specified minimum number of nodes, maintaining security while enabling efficient processing.

This sophisticated integration of advanced cryptographic technologies and secure hardware creates a comprehensive framework that effectively addresses the key challenges in AI agent security and privacy. Bool Network ‘s innovative cryptographic random mechanism and distributed collaboration model solve critical issues in security, privacy, and verifiability, paving the way for decentralized AI applications. As the technology continues to evolve and application scenarios expand, this network is positioned to become a core infrastructure component in future AI ecosystems, promoting both the trusted development of AI technology and the construction of a more secure digital society.

Social Media:

Website丨Twitter丨YouTube丨Channel丨Community丨Discord丨GitBook

For Developer:

GitHub丨White Paper丨Yellow Paper

November has been a groundbreaking month for Bool Network, as we achieved several critical milestones that set the stage for our continued growth and innovation. This month marked the launch of our Beta Mainnet, an exciting step as we transition into the mainnet testing phase. We also conducted the highly anticipated airdrop snapshot for Testnet participants, rewarding our early supporters and contributors. Additionally, Bool Network made its presence felt on the global stage, with our CEO and CMO representing us at the W2140 World AI + WEB3 Conference in Bangkok, sharing insights on our role in shaping the future of blockchain and DeFi. Lastly, the Bool Network Ecosystem expanded significantly with the launch of the Bool Ecosystem Super Consumer Application, further showcasing the versatility and potential of the Bool chain.

1. Beta Mainnet Testing Phase Initiated

The Bool Network Foundation officially deployed 20 Validator nodes and 30 DHC nodes for early-stage testing of the Beta Mainnet. This critical testing phase will last approximately two weeks, with actual duration subject to progress and refinement. During this period, all earnings generated by the test nodes will be allocated toward future community-building initiatives. Once testing is successfully completed, the node networks will be opened to general node providers and the global community, enabling wider participation in Bool’s decentralized network.

2. Snapshot for Beta Testnet Airdrop Completed

On November 10th at 12 PM UTC, we conducted a snapshot for the first Beta Testnet airdrop, capturing user contributions during the Testnet phase. Following data parsing, eligible users will soon be able to verify their rewards. Additionally, the Beta Testnet remains operational, and active engagement in DHC nodes will continue to generate valid rewards throughout the Beta Mainnet testing period, ensuring an ongoing incentive for participation.

3. Beta Testnet Airdrop Round #2 Announced

Following the successful completion of the first Beta Testnet Airdrop snapshot on November 10th, Bool Network observed a surge in new user participation leading up to the snapshot. To further incentivize community engagement and provide more users the opportunity to benefit from the Beta Testnet, Bool Network officially launched Round #2 of the Beta Testnet Airdrop during the Beta Mainnet testing period. Rewards from the second airdrop round will be independent of the first, ensuring fair distribution across all contributors.

4. Bool Network Represents at W2140 World AI + WEB3 Conference

In mid-November, Bool Network proudly participated in the W2140 World AI + WEB3 Conference held in Bangkok, Thailand, marking another significant step in our journey toward global recognition.

On the first day of the conference, Victor Saylor, Bool Network’s CMO, represented the project, sharing our revolutionary vision and groundbreaking technological advancements with attendees.

On the second day, Raul Heraud, Bool Network’s CEO, delivered a keynote presentation highlighting the expansive Bool ecosystem and its role in unlocking Bitcoin’s untapped potential. His presentation was met with widespread interest and enthusiasm from Web3 professionals, further solidifying Bool Network’s position as a leader in driving innovation within the blockchain industry.

These engagements not only underscored Bool Network’s commitment to advancing decentralized technologies but also strengthened our global presence, opening doors to future partnerships and collaborative opportunities.

5. Launch of Bool Meme — The First Ecosystem Application on the Bool chain

On Nov 18th, Bool Meme was officially launched, marking it as the first application developed on the Boolchain. Positioned as a Super Consumer Ecosystem Application, Bool Meme serves as a dedicated Meme Token Launch Platform, combining the dynamic appeal of memecoins with the technological power of Bitcoin-based DeFi (BTCFi).

Bool Meme is designed to enable developers and creators to seamlessly launch and manage their memecoin projects, leveraging Boolchain’s robust infrastructure for scalability, security, and decentralization. This launch not only marks the beginning of a new chapter for Boolchain applications but also underscores Bool Network’s vision of bridging BTCFi and the vibrant memecoin market.

Developers are warmly invited to join the Bool Meme platform and contribute to co-building a thriving ecosystem of creativity and decentralized innovation.

Looking Ahead

The launch of the Beta Mainnet marks a critical milestone in Bool Network’s journey toward building a robust and complete ecosystem. During the testing phase, we have been rigorously validating the feasibility of the DHC mechanism and refining our technologies to ensure a secure, scalable, and decentralized infrastructure.

As we move forward, December will be a pivotal month for further development and expansion. We are committed to making continuous improvements to Bool Network’s technology and ecosystem while taking decisive steps toward the full mainnet launch. Each step brings us closer to realizing Bool’s vision of a decentralized, user-centric future. Stay tuned for more exciting updates as we shape the next chapter of Web3 innovation.

Social Media:

Website丨Twitter丨YouTube丨Channel丨Community丨Discord丨GitBook

For Developer:

GitHub丨White Paper丨Yellow Paper