Trusted Execution Environments

With increasing calls for privacy in the web3 space and the addition of new cryptographic technologies like zero knowledge proofs and multi-party computation, interest in trusted execution environments (TEEs) has grown in popularity within the crypto ecosystem.

What is a TEE?

A TEE is a hardware‑backed isolated execution environment that protects code and data from the rest of the system, including the operating system and hypervisor. Hardware enforces which parts of memory can be accessed in plaintext, typically using memory encryption and strict access rules. The OS still manages resources, but it cannot inspect or tamper with the data and code running inside the TEE.

Enclaves

Enclaves are process‑level TEEs. An enclave is a protected region inside an application’s address space where sensitive code and data run in isolation from the operating system, the hypervisor, and even the rest of the application. Only well‑defined entry and exit points allow communication between enclave code and non‑enclave code. Enclaves were originally meant to segment and protect sensitive code from the rest of the system, but have been largely used to store the entire application state.

CVM

Confidential Virtual Machine (CVM) is a virtual machine deployment model where the entire VMs memory is isolated and protected using the TEE features of the underlying hardware. From the cloud operator’s point of view, the VM’s memory remains encrypted; only code running inside the VM can see it in plaintext.

Confidential Computing Environment

A confidential computing environment (CCE) is a computing environment that uses hardware‑based isolation to protect data in use, providing strong confidentiality and integrity guarantees for computations, even from the underlying cloud provider or operating system. This is achieved through three core principles: runtime memory encryption, remote attestation, and isolation. In practice, CCEs are built on top of TEEs such as enclaves or confidential VMs, together with attestation and key‑management infrastructure. The terms “TEE” and “confidential computing” are sometimes used interchangeably in industry, but in this article we’ll mostly use “TEE” for simplicity, except in this section where we discuss the broader confidential computing model.

Runtime Encryption

Runtime encryption in confidential computing typically refers to hardware‑level encryption of data in use in memory. When code inside an enclave or confidential VM reads or writes memory, the CPU and memory controller automatically decrypt data as it is loaded and encrypts it as it is written back to RAM. From the perspective of the operating system or hypervisor, the protected memory region appears only as encrypted bytes; they cannot see the plaintext. From the perspective of the code running inside the TEE, memory access looks normal.

Remote Attestation

Remote attestation is the process by which a remote party verifies that it is talking to a genuine CCE running specific code and configuration. Hardware manufacturers provide the root of trust, so an outside party can check that the attestation comes from real hardware and that the reported software configuration matches what they expect.

Isolation

Isolation is the process of separating the TEE from the host environment. Even privileged software can’t read the protected memory in plaintext, which means the OS cannot access the CCE environment directly. Meaning that the OS cannot access the CCE environment directly. If the operating system tries to read memory that belongs to the TEE, it doesn’t see the actual values being processed. Because of runtime encryption, all it can access is encrypted data, not the underlying plaintext.

Why use a TEE?

Advancements in zero knowledge proofs and other cryptographic protocols have allowed for the development of new applications that prove the validity of data without revealing the data itself. Naturally, this has increased the demand for privacy-preserving applications at the cost of overhead and technical complexity. Both of which increase costs and create their own problems. Compared to zero‑knowledge proofs and MPC, TEEs offer a more straightforward developer experience: you can often run existing code with minimal changes, without adopting new domain‑specific languages or specialized circuits. The trade‑off is that you must trust the hardware vendor and the attestation infrastructure, whereas ZK/MPC rely purely on cryptographic assumptions.

What are the risks?

TEEs provide local confidentiality and integrity for computations on a single machine, but they don’t replace the global integrity, availability, and Sybil resistance guarantees you get from consensus protocols like blockchains. Adept enough hacker with access to the physical hardware can theoretically circumvent the TEE and access the underlying data. TEEs depend on complex hardware, firmware, and microcode stacks. These components are often updatable, which is a double‑edged sword: it allows security patches, but also creates a risk that compromised signing keys or supply‑chain attacks could push malicious updates. At the same time, any non‑updatable components can accumulate unpatchable vulnerabilities over time. Both factors mean TEEs can’t be treated as infallible. Instead, a16z notes in their article: "Design for failure." The expectation that these components will fail at some point can be mitigated by building with privacy in mind rather than core system attributes like blockchain integrity. Rather than relying on them as a whole private and secure solution, development with TEEs should coincide with other strong security and privacy guarantees.

TEEs in the wild

In practice, TEEs tend to show up in two patterns: blockchains that use TEEs as one layer in a security stack, and infrastructure for confidential cloud/AI compute. Oasis and Phala are good examples of each. The ability to process encrypted data in a TEE is a key feature of these projects and a capability that will help bridge the web2 world with the web3 world. The more computation that can be moved offchain without sacrificing onchain guarantees, the better and the cheaper it will be to run arbitrary compute on a blockchain. Fast, inexpensive, and secure onchain compute will fuel global adoption of decentralized applications.

Oasis

Oasis blockchain uses a multiprong approach for managing risk on their platform. Oasis couples infrastructure TEEs with light client verification, multi-party computation, and decentralized node consensus to ensure the overall security of the network.

Phala

Phala specializes in providing a secure execution environment for AI cloud deployments. This means applications can launch AI models and computation in TEEs with verifiable compute results. Phala uses CVMs providing a cryptographic proof between the hardware, the operating system, and your application code.