Skip to main content

TEEs in Blockchain: Use Cases and Projects

TEEs in blockchain power MEV protection, private smart contracts, verifiable AI, and bridge security. See how Flashbots, Phala, Secret, and Marlin use them.

Written by Robert Felt
Updated today


TEEs in blockchain refer to the use of hardware-based trusted execution environments (Intel SGX, Intel TDX, AMD SEV-SNP, ARM TrustZone, and AWS Nitro Enclaves) to run protocol logic that requires confidentiality, integrity, or remote attestation. A TEE gives a smart contract a way to trust offchain code without re-executing it: the enclave signs an attestation containing a measurement of the loaded binary, and an onchain verifier checks that signature against the chip vendor's public key infrastructure. The combination unlocks classes of applications that pure smart contracts cannot deliver: MEV-resistant block production, private smart contracts, verifiable AI agents, and cross-chain bridges with reduced operator trust.

Adoption has accelerated since 2023. Flashbots moved its block-builder infrastructure into SGX. Phala Network's worker mesh processed tens of thousands of contract calls per day in early 2025. Automata, Marlin, Secret Network, and Oasis each shipped TEE-based products into production. The Confidential Computing Consortium's 2023 outlook report projects the broader confidential computing market reaching roughly $54 billion by 2026, with cryptocurrency and Web3 listed as fast-growing segments.

This article walks through the major use cases for TEEs in blockchain and the production projects shipping each one. It includes the hardware each project uses, the integration pattern with onchain verification, and the known limitations of the approach.

Why Blockchains Use TEEs

Public blockchains are deliberately transparent and deterministic. Every node executes every transaction; every state change is visible to anyone running a full node. Transparency and determinism are exactly what makes consensus possible, and exactly what blocks several useful applications. A user submitting a private trade does not want the mempool to leak it. A protocol running an AI model does not want the weights public. A bridge does not want validators to forge messages.

A TEE lets specific workloads opt out of full transparency while still being verifiable. The smart contract verifies a remote attestation once, confirming that the offchain code matches an audited binary running on a current-firmware chip, and from that point on accepts the enclave's signed messages. The attestation links the offchain computation to onchain verification through cryptographic measurement and a chip-vendor signature chain. Costan and Devadas's "Intel SGX Explained" paper remains the most cited primary reference for how the measurement and attestation work.

Three properties account for almost every blockchain TEE use case:

  • Memory confidentiality: encrypted RAM keeps private state, model weights, or transaction contents hidden from the host operator.

  • Execution integrity: the loaded code is measured and verified before any secret is provisioned.

  • Remote attestation: a smart contract or another enclave can verify what code ran without trusting the operator.

The next sections walk through five categories of production deployment.

MEV Protection and Block Building

Maximum extractable value (MEV), the value a block producer can extract by reordering, including, or excluding transactions, has driven the most production-grade TEE deployment in crypto. Searchers want to submit profitable bundles without the builder front-running them; users want their swaps and intents executed without leakage; relays want to prove they did not censor.

Flashbots SUAVE. Flashbots moved its block-builder and orderflow-auction infrastructure into Intel SGX starting in 2023. The SUAVE TEE coprocessor design describes how user bundles are encrypted to a known SGX measurement; the enclave decrypts and orders them; and the resulting block is sealed before any operator sees the contents. The trust assumption shifts from "Flashbots will not front-run me" to "Intel's attestation chain is intact and the loaded code matches the audited measurement."

Manta Network's MEV Lite. Manta has shipped sequencer-side TEE integration for its rollup that aims to reduce per-block extractable value. The pattern mirrors Flashbots: orderflow encrypted to an enclave measurement, decrypted and sequenced inside, returning a sealed block.

Linea and other rollups. Several Layer-2 rollups are evaluating TEE-based sequencers for the same reason: provable fairness in transaction ordering without slowing down block production with ZK proofs.

The MEV use case sits in the TEE sweet spot. Latency budgets are millisecond-scale, ruling out per-block ZK proofs. Confidentiality is the core requirement. The threat model accepts trust in Intel's signing infrastructure as a step up from blind trust in the builder operator.

Private Smart Contracts

Private smart contracts run application code with encrypted state, encrypted inputs, and selective reveal of outputs. They are useful for any application where the data is sensitive but the computation must still be verifiable.

Secret Network. Secret has been the longest-running TEE-based smart-contract platform, live since 2020. Validators run full nodes inside Intel SGX enclaves; contract state is encrypted with keys held inside the enclaves; only callers authorized by the contract see plaintext outputs. Secret's developer documentation covers the encryption flow and the trust assumptions. Secret has had to manage SGX patch cycles aggressively. The chain coordinated multiple TCB-recovery upgrades after each disclosed SGX vulnerability.

Oasis Network's Sapphire. Oasis shipped Sapphire, an EVM-compatible confidential runtime, in 2023. Contracts run inside SGX, state is encrypted, and selectively revealed using opt-in view functions. Sapphire's documentation walks through the developer model, including how to handle the slower transaction throughput that comes with enclave overhead.

Phala Network. Phala runs a network of worker nodes, each an SGX-attested enclave, that execute Phat Contracts. According to Phala's public dashboards, the network processed roughly 30,000 contract calls per day in early 2025, with a peak of ~2,000 active workers. Phala registers worker measurements onchain so contracts can verify which TEE measurement processed any given call.

iExec. iExec uses Intel SGX for confidential offchain compute marketplaces, particularly for tasks like privacy-preserving genomic analysis and federated machine learning. The platform predates most blockchain SGX deployments — iExec began shipping SGX integrations in 2018.

The common pattern across these projects is registering a known SGX measurement onchain and treating any message signed by an enclave with that measurement as authoritative. The state never appears in plaintext outside the enclave.

Verifiable AI and Agent Compute

AI agents that interact with smart contracts (placing trades, managing treasuries, fulfilling intents) have a verifiability problem. The smart contract cannot run the model itself; it must trust that some offchain operator ran the right model on the right inputs. ZK proving an LLM is technically possible but currently 10,000–100,000× slower than native inference. A TEE can run the model natively while signing an attestation that links the output to the model weights and prompt.

Marlin Oyster. Marlin's Oyster is a TEE marketplace that lets developers deploy code into AWS Nitro Enclaves and Intel SGX with onchain attestation verification. Oyster's documentation covers AI inference, ZK proving, and oracle workloads. Several projects use Oyster to run LLM agents that produce attested outputs consumable by smart contracts.

Phala Agent Wars and Phat Contract AI. Phala has positioned its worker network as a host for AI agents that need attestable execution. The agent's prompt and model weights stay inside the SGX enclave; the output is signed by the worker's attestation key.

Automata Network. Automata shipped onchain DCAP attestation contracts that EVM smart contracts use to verify Intel SGX/TDX attestations directly. The DCAP repo includes a SNARK-compressed verifier path that reduces gas costs by an order of magnitude. Automata's verifiable AI service uses TEE-attested LLM inference for agent-controlled smart-contract interactions.

Atoma Network. Atoma is a more recent entrant building a confidential AI inference network using a mix of SGX, TDX, and Nvidia Confidential Computing GPU support. The pitch is verifiable AI compute that pays in stablecoins and produces onchain-verifiable inference receipts.

Verifiable AI is the area where TEE adoption has accelerated fastest in 2024–2025. Smart contracts that pay agents, accept agent decisions, or settle agent-driven trades benefit directly from a hardware-anchored attestation that links the output to the model.

Cross-Chain Bridge Security

Cross-chain bridges have historically lost more value to smart-contract bugs and operator compromises than any other class of crypto infrastructure — Chainalysis reported $2.8B+ stolen from bridges in 2022 alone. TEEs offer one of several primitives that reduce operator trust in a bridge's message validation.

Hyperlane Interchain Security Modules. Hyperlane's modular security framework lets each route define its own validator set and proof system. TEE-based ISMs, where a quorum of attested SGX enclaves validate cross-chain messages, are part of the available module catalog. The pattern is registering a set of enclave measurements as the valid signer set, then accepting any message signed by a quorum of those measurements.

Eigenlayer-Restaked TEE Operators. Several restaking-based AVS designs include TEE-attested operators where the enclave measurement is part of the slashing condition. If an operator runs unattested code, restaked ETH can be slashed.

Automata Multi-Prover. Automata's multi-prover AVS uses TEE attestations alongside ZK proofs as parallel security inputs for rollup state transitions. The combination lets the verifier accept either signal independently or require both.

The cross-chain use case typically combines TEEs with another primitive (restaking, ZK proofs, or economic security) rather than relying on the enclave alone. The combination matters because a successful side-channel attack on an SGX enclave should not be sufficient to compromise the whole bridge.

Custody, Wallets, and Signing Infrastructure

The longest-running production use of TEEs in crypto is custody. Hardware wallets, custodial signing infrastructure, and HSM-backed key vaults have used TEEs for years.

Fireblocks. Fireblocks's MPC signing infrastructure runs key-share operations inside Intel SGX enclaves. The signing keys never appear in plaintext in any host memory; even a compromised cloud operator cannot exfiltrate the shares. Fireblocks discloses the SGX integration in its platform security documentation.

Anchorage Digital. Anchorage's federally-chartered crypto bank uses HSMs alongside SGX-based signing services for the regulated custody product line. The combination satisfies banking-grade key-management requirements while supporting the operational flexibility of cloud deployment.

Hardware wallets. Ledger, Trezor, and other hardware wallets use ARM TrustZone or proprietary secure elements as TEE-class isolation for signing keys. The signing operation occurs inside the secure environment; the host computer only sees the resulting signature.

Custody is the most conservative TEE use case. The workload is small, the attack surface is well-understood, and the trust model fits established financial-services practice.

Limitations and Risks for Blockchain Deployments

Production blockchain TEE systems share five recurring operational concerns.

Side-channel attack history. SGX has been hit by Foreshadow (2018), SGAxe (2020), and ÆPIC Leak (2022). Each required microcode patches and TCB recovery. Blockchain networks like Secret had to coordinate chain-wide upgrades. New deployments should include a TCB-recovery plan and an attestation policy that rejects measurements from chips below a minimum patch level.

Vendor trust concentration. Almost all production TEE deployments depend on Intel's SGX/TDX or AWS's Nitro signing keys. A compromise of the vendor PKI is catastrophic. Multi-vendor designs — combining SGX with TDX or with AMD SEV-SNP — reduce this concentration but increase operational complexity.

Performance cost. Memory encryption adds 2–15% overhead for compute-heavy workloads. SGX's older small-EPC versions added 10–100× overhead per page swap; newer Ice Lake Xeons fix this. Block-building latency budgets, in particular, are tight enough that the overhead matters.

Open-source and reproducibility gaps. Deploying a known measurement requires reproducible builds. Many TEE projects ship Docker images that change measurement at every rebuild, which makes onchain measurement registration a moving target. Reproducible builds are improving but are not the default.

Censorship and liveness. A TEE can prove what code ran but cannot guarantee liveness. If the operator stops running the enclave or refuses to process certain inputs, the chain has no automatic recovery path. Multi-operator quorums and economic incentives (slashing) are how production systems handle this.

How Eco Considers TEE-Based Components

Eco's stablecoin orchestration network spans 15 chains and uses several primitives — solver execution, cross-chain messaging, and onchain settlement — that map naturally onto TEE design choices. Solver execution that handles user intents is a candidate for TEE-attested compute when confidentiality matters; cross-chain message verification often blends TEE attestations with other security signals. Teams building on Eco who need confidential compute or attested AI inference for agentic flows can integrate TEE-backed services through the same patterns described above. For more on the underlying primitives, see cross-chain messaging protocols and intent-based routing protocols.

FAQ

Which blockchain projects use TEEs in production?

Flashbots (SUAVE), Secret Network, Oasis Sapphire, Phala Network, iExec, Marlin Oyster, Automata, Atoma, and several Hyperlane ISMs ship TEE-based components in production. The hardware mix is mostly Intel SGX for older deployments and a growing share of AWS Nitro and Intel TDX for newer ones.

Why use a TEE instead of a ZK proof for blockchain?

TEEs offer cheap, low-latency, general-purpose execution with hardware-rooted trust. ZK proofs offer cryptographic trust at orders-of-magnitude higher proving cost. For workloads that need confidentiality, complex code, or millisecond latency — block building, AI inference, private contracts — TEEs are usually more practical. ZK is a better fit for state validity proofs and light-client verification where the verifier wants minimal trust assumptions.

Can a smart contract verify a TEE attestation onchain?

Yes. Automata's DCAP attestation contracts implement Intel's verification logic in Solidity, and a SNARK-compressed verifier path reduces gas costs to roughly 300k per attestation. Phala, Marlin, and Hyperlane ISM consumers use similar patterns. The smart contract typically verifies the attestation once and registers the enclave measurement, then accepts subsequent enclave-signed messages.

Are SGX vulnerabilities a problem for blockchain TEE projects?

They are a real operational concern but a manageable one. Foreshadow, SGAxe, and ÆPIC Leak each required Intel microcode updates and TCB recovery. Blockchain networks like Secret have coordinated chain-wide TCB-recovery upgrades after each disclosure. New deployments use attestation policies that reject below-minimum-patch chips and combine SGX with at least one other security primitive.

Do TEEs make a blockchain more decentralized?

Not directly. A TEE-based component still depends on the chip vendor's PKI as a trust root. What it does change is the threat model — a malicious operator alone is no longer sufficient to compromise the system. Combining TEEs with vendor diversity, ZK proofs, or economic security gets closer to the decentralization goals public chains care about.

Did this answer your question?