TEEs on Solana: confidential compute by trusting the chip

A Trusted Execution Environment (Intel SGX/TDX, AMD SEV-SNP, AWS Nitro) is a hardware-isolated region of a CPU that runs code and data encrypted from the host OS and hypervisor — and emits a remote attestation: a hardware-signed proof of exactly what code is running inside. It's the third way to do confidential compute on Solana, and quietly the most deployed.

TEE vs MPC vs ZK vs FHE

• MPC (Arcium) — splits secrets across nodes; trust = honest-majority, no hardware.
• FHE — computes directly on ciphertext; strongest guarantee, orders of magnitude slower.
• ZK — proves a computation was correct, but doesn't itself keep inputs confidential at runtime.
• TEE — fastest and most general-purpose (run any code at near-native speed), but you trust the silicon vendor's attestation root.

It's already on Solana

• Jito BAM (Block Assembly Marketplace) — transaction scheduling moved off the validator into AMD SEV-SNP enclaves ("BAM Nodes"). A TEE-encrypted mempool hides transactions until execution to limit harmful MEV — mainnet alpha from ~Sept 2025, with validators including Helius, SOL Strategies, and Triton One.
• MagicBlock — Private Ephemeral Rollups on Intel TDX; a Private Payments API for confidential transfers and sealed-bid auctions.
• Switchboard — oracle aggregation and signing keys run inside SEV-SNP/SGX enclaves; on-chain attestation proves each price update came from an unaltered enclave.
• Marlin Oyster — a TEE coprocessor network (AWS Nitro), used for persistent AI-agent wallet custody with an on-chain attestation-verifier pattern. (Multi-chain, not Solana-exclusive.)

The attestation flow

The clever part is getting an off-chain enclave's guarantee onto Solana cheaply. Verifying a full attestation on-chain is expensive, so the common pattern is a one-time verify plus a cheap recurring signature check:

1. App runs in enclave → enclave produces an attestation:
   sign( measurement(code) || enclave_pubkey )   // hardware root key

2. A verifier checks the full attestation ONCE off-chain
   (or in a one-time on-chain step), establishing trust in enclave_pubkey

3. On-chain program then does a cheap secp256k1 check on each enclave output
   → trusts results via the chain of trust, no per-call attestation cost

The threat model (read this)

You are trusting the chip vendor (Intel/AMD/AWS) and their attestation root — not a decentralized set. And TEEs have a real side-channel history: SGX's Foreshadow/L1TF (2018) and CacheOut/SGAxe (2020) extracted attestation keys, letting attackers forge "genuine" quotes. SEV-SNP and TDX are newer with their own evolving CVEs. Mitigations exist, but enclave security is an arms race, not a closed proof.

The honest read

TEEs are the pragmatist's privacy: fast, general-purpose, and cheap enough to put a whole mempool or oracle pipeline inside one — which is exactly why Jito, MagicBlock, and Switchboard reached for them. The cost is a centralized trust root (a chip vendor) plus proven side-channel risk, and operational centralization while node sets are small (BAM nodes were initially run by Jito Labs). For latency-sensitive confidentiality at scale they're unmatched today; for adversarial, maximum-assurance secrecy, MPC or ZK still make a stronger trust argument.

References

• Helius — Block Assembly Marketplace (BAM)
• MagicBlock docs (TEE / private rollups) · Marlin Oyster
• The Solana privacy landscape

MPC trusts a majority and ZK trusts math. TEEs trust a chip — and on Solana in 2026, that trade is already running in production.