The Next Web3 Infrastructure May Be Confidential Computing

Consider an AI trading agent deployed on a public blockchain. The agent receives a user’s private strategy, reasons over it, and submits a transaction. Every validator, then, confirms the output is correct, and all of them also see the inputs.

This is in no way an implementation failure. It is the execution model working as designed. Public blockchains achieve trust through universal re-execution that allows any node to verify any transaction by running the same code on the same inputs. This mechanism is also the source of the privacy problem. One cannot simultaneously require every participant to see all inputs and expect any input to remain private.

Here is where confidential computing comes in. It addresses the dilemma by introducing hardware-enforced execution environments. In these environments, computation runs on private data, sealed from the host system, the cloud operator, and the network.

Whether it becomes foundational Web3 infrastructure depends on questions the industry has not yet answered.

Public Consensus Requires Public State

Input visibility on public blockchains is not a missing feature, but a USP that makes the system trustless. Removing universal re-execution simultaneously removes verifiability. That trade-off is acceptable when all data is meant to be public, but it fails wherever the data is not.

DeFi protocols that need sealed-bid auctions cannot implement them without leaking bids to validators and MEV bots. AI agents’ reasoning over private user instructions or model logic exposes that reasoning to the full network. Cross-chain data pipelines that consume sensitive real-world data, like credit scores, KYC status, and medical records, expose that information to every verifying node.

Most validators and sequencers run on centralized cloud providers, with AWS, Google Cloud, and Azure being notable examples. Moving sensitive computation off-chain to a cloud server does not resolve the trust problem, but only relocates it to the cloud operator, where it becomes invisible rather than absent.

Why Existing Privacy Tools Do Not Close the Gap

Encryption at rest and in transit, zero-knowledge proofs (ZKPs), multi-party computation (MPC), and homomorphic encryption exist to address versions of the privacy issues posed by decentralized consensus. However, the execution environment remains exposed.

Standard encryption protects data before and after computation, leaving the window in between wide open. Data must be decrypted to be processed, and once that happens, the operating system and hypervisor can read it.

ZKPs allow a prover to demonstrate that a computation was performed correctly on private inputs without revealing them. While this is useful for rollup validity proofs and identity claims, it is insufficient for AI inference. Computation must be reformulated as arithmetic circuits, proving time for transformer-scale models is prohibitive. The prover holds plaintext regardless. ZKPs verify what happened, but do not protect where it happened.

MPC distributes input across nodes so no single party sees the full data. This works for threshold key management. It fails for real-time agent execution, where multi-round coordination between nodes introduces latency that scales with the number of participants.

Fully homomorphic encryption computes on encrypted ciphertext without decrypting it. Although theoretically the strongest guarantee, it is practically 1,000–10,000x slower than plaintext computation. LLM inference at that overhead remains undeployable today.

Evidently, none of these protects the execution environment itself. The missing piece is a general-purpose environment where arbitrary code runs on private data in a way that the host system and operator cannot observe it.

A Different Category of Protection

Confidential computing fills the gap, protecting data in use during active computation. The CPU or GPU creates an isolated memory region, encrypted at the hardware level, which the host operating system, the hypervisor, and the cloud operator cannot read or modify. Code runs inside it, and data also stays within, allowing only the result to exit.

That isolation is a hardware contract, not a cryptographic protocol. What matters for Web3 is generality: any code can run inside a confidential execution environment without being reformulated into arithmetic circuits or distributed protocols, which are the exact constraints imposed by ZKPs and MPC.

How the Architecture Works

To understand confidential computing more deeply, it is imperative to know where the infrastructure is plugged in. Trusted Execution Environments (TEEs) are where that happens. Also referred to as enclaves, TEEs are the hardware mechanisms that implement confidential computing, and are isolated, encrypted regions of processors where code and data are protected from everything outside them.

TEEs exist at different levels of the hardware stack, each with a different scope of protection. Process-level TEEs isolate a specific memory region within a single application. They are suited for narrow operations like key signing, but constrained in the size of the workload they can handle. Virtual machine (VM)-level TEEs encrypt entire VMs, making them suitable for general cloud deployments with minimal performance overhead. GPU TEEs extend the same boundary to the accelerator, keeping model weights encrypted in memory and inaccessible to the cloud provider, which is what makes confidential AI inference viable at scale.

TEEs are connected to decentralized systems through remote attestation. When an enclave starts, the hardware generates a cryptographic quote, a measurement of the enclave’s code, configuration, and initial state, signed by the manufacturer’s key. An on-chain attestation verifier contract checks this quote and confirms a specific piece of unmodified code ran on genuine hardware, without seeing any of the data it processed. This is what makes TEE security composable with on-chain protocols.

But enclaves lose their contents when they shut down. So, sealed storage is harnessed to solve this by ensuring TEEs encrypt their own state to their code identity before exiting. If the enclave is modified, the sealed state becomes unreadable. Private keys, model weights, and agent memory persist, but only as long as the code running the TEE remains exactly what it was.

Sealed Execution Is Already in Production

Confidential computing is already being tested in the decentralized space, with four live deployments depicting how builders have approached the same hardware primitive differently. Each is a distinct answer to the question of where TEE execution fits in a decentralized stack.

Phala Cloud runs confidential VMs and AI agent contracts. In early 2025, Phala demonstrated DeepSeek R1, a 70-billion parameter model, running inside a GPU TEE with inputs and model weights sealed from the host infrastructure. Marlin’s Oyster is a decentralized marketplace for TEE coprocessors. Node operators list available hardware, and builders rent verified execution on serverless or persistent terms.

Secret Network runs privacy-preserving smart contracts, with all contract input, output, and state encrypted by default. Oasis Sapphire extends the same approach to an EVM-compatible runtime for Ethereum builders.

Ritual’s Infernet combines TEE attestations, ZKPs, and MPC within a single AI inference network, allowing smart contracts on participating chains to call AI models with verifiable results. The multi-proof design is deliberate, and no single privacy primitive covers the full inference trust model. Ritual’s partnership with Nillion, whose MPC-based blind computation handles specific parts of the trust model, reflects the direction the broader ecosystem is moving.

What Builders Can Actually Build

Confidential execution does not improve existing Web3 applications, but can make certain categories of product structurally achievable that were not before.

Provably private AI inference APIs: A model deployed within a GPU TEE creates an inference endpoint that the provider cannot inspect for query content or model weights. The privacy guarantee is attestation-verifiable and introduces cryptographic claims instead of policy ones.

Non-custodial AI agents with sealed state: Autonomous agents managing funds or executing strategies need to hold private instructions without exposing them to network observers. Attestation provides users with proof that the agent is running exactly the code they authorized, which is a prerequisite for trustless agent deployment.

MEV-resistant DeFi mechanisms: Sealed-bid auctions and private order books processed inside an enclave, with only settlement results published on-chain, make front-running structurally infeasible for TEE-settled operations.

Privacy-preserving data oracles: Sensitive real-world data processed inside a TEE with only the verified result published on-chain. Raw data never reaches the chain or the validator set, enabling regulated use cases that on-chain data exposure currently forecloses.

The Trust That Is Not Eliminated

As advancements emerge from this field, risks also emerge at different layers. Deploying computation inside a TEE relocates trust without eliminating it. The assumption moves from cloud operators and blockchain validators to hardware manufacturers.  While that is a narrower surface, it is not trustless. A government could compel a firmware backdoor, or a supply chain compromise could affect TEE integrity before the hardware ships.

The attack history matters for those advancing confidential computing across the decentralized realm. Foreshadow (2018) read Intel SGX enclave memory via speculative execution of faulting memory accesses, Plundervolt (2019) corrupted SGX computation via voltage manipulation, and LVI (2020) exploited speculative execution to inject attacker-controlled values into enclave code.

Intel addressed these in microcode. Newer TDX and AMD SEV-SNP were designed with these attack classes in mind. TEE security is not static, builders inherit a dependency on manufacturer responsiveness and disclosure timelines.

Intel’s deprecation of SGX on consumer-class processors, now concentrated on Xeon server chips, creates a structural consequence for decentralized networks. SGX-based nodes trend toward cloud data centers rather than distributed hardware. A protocol that claims decentralization at the protocol layer may depend on centralized cloud infrastructure at the hardware layer.

Remote attestation also introduces hurdles, such as operational complexity that most Web3 tooling was not designed for. Certificate chains expire, revocation lists must be validated, and an on-chain verifier accepting stale attestation collateral allows quotes from potentially compromised hardware to get through. Developer tooling does not yet match EVM ergonomics. Enclave development requires SDK-level knowledge, and debugging is constrained by the same isolation that makes enclaves useful.

What Remains Unproven

Blockchains produce verifiable computation, and TEEs produce sealed computation. Together, they create something neither achieves alone, which is execution that is simultaneously verifiable by a smart contract and opaque to every party that processed it.

The conditions for this to function as a default Web3 infrastructure are yet to be met. On-chain attestation verification is deployed piecemeal and is currently not standardized across chains. Multi-vendor TEE setups that reduce hardware concentration risk are uncommon, and formal audits that account for both cryptographic and hardware attack surfaces remain rare.

If these gaps close, confidential computing can become the execution layer for Web3 applications that cannot afford to expose their data. And if hardware trust remains unaddressed, it becomes a useful dependency that quietly constrains the decentralization claims built on top of it. This tension is the design problem that makes building here consequential.