Summary

Trusted Execution Environments (TEEs) allow code to run in hardware-protected enclaves that prevent even the server operator from observing or modifying execution. Attested TLS (aTLS) extends standard TLS with a TEE attestation proof, allowing remote parties to cryptographically verify that they are connected to a specific code version running in a genuine enclave. Both technologies are foundational to BuilderNet and other Phase 1 decentralized building infrastructure.

Trusted Execution Environments

What TEEs Provide

A TEE (Intel TDX/SGX, AMD SEV, ARM TrustZone) creates a hardware-isolated execution environment:

  • Confidentiality: memory is encrypted; the host OS, hypervisor, and cloud provider cannot read it
  • Integrity: the code executing inside cannot be modified at runtime
  • Attestation: the TEE can produce a signed certificate (quote) proving: (a) what code is running, (b) the code hasn’t been modified, (c) the hardware is genuine Intel/AMD/ARM

Attestation Flow

  1. Code inside the TEE measures itself (SHA hash of code + initial data)
  2. The TEE hardware signs this measurement with a key stored in hardware (not accessible by software)
  3. The signed quote is sent to a remote verifier
  4. The verifier checks the signature against Intel/AMD’s root certificate and verifies the measurement matches expected code

This enables remote attestation: a client can verify they are connecting to the exact code they expect, running in genuine isolated hardware — not a modified version on a compromised host.

Limitations

  • TEEs are not a silver bullet: side-channel attacks (cache timing, power analysis, memory bus snooping) can sometimes extract secrets even from genuine enclaves
  • The hardware manufacturer (Intel, AMD) is in the trust chain: a compromised manufacturer could issue fraudulent attestations
  • TEE bugs and vulnerabilities (e.g., Spectre, foreshadow) have been discovered historically
  • Flashtestations: Flashbots’ tool for on-chain TDX attestations, enabling blockchain-verifiable proof that BuilderNet nodes run specific code

Attested TLS (aTLS)

Standard TLS authenticates the server’s identity (via certificate) but not what code is running on the server. aTLS adds a TEE attestation proof to the TLS handshake.

Two Binding Approaches

1. Certificate-Public Key Binding

  • The TEE generates a TLS certificate whose public key is derived from the TEE’s identity
  • The attestation quote is embedded in or alongside the certificate
  • Verifier: check that the certificate’s public key matches the TEE’s attestation → proves you’re connected to the specific enclave

2. EKM (Exported Keying Material) Binding

  • During the TLS handshake, both parties derive shared keying material from the session
  • The TEE includes a hash of this keying material in its attestation quote
  • Verifier: check that the EKM in the attestation matches the actual session’s EKM → proves the attestation was produced by the same endpoint that established the TLS session

EKM binding is stronger against certain attack scenarios (attacker proxying a valid attestation from a different session).

Applications in the Wild (2026)

  • T+ (stock exchange): uses aTLS to allow institutional clients to verify they are connecting to genuine trading systems
  • Flashbots BuilderNet: uses aTLS for order flow submission; OFA providers can verify they are sending transactions to genuine BuilderNet enclaves
  • LUCID encrypted mempool: threshold decryption committee members use TEE-based key management with aTLS for coordination

BuilderNet TEE Architecture

BuilderNet (Phase 1 decentralized building) uses TDX (Intel Trust Domain Extensions):

  • Multiple operators (Flashbots, Beaver Builder, Nethermind) run the same code in TDX enclaves
  • Order flow providers can verify all operators run identical code (same measurement)
  • If one operator’s enclave is compromised or goes down, others continue unaffected
  • The TEE enforces that only valid operations (backruns, not frontrunning) are performed on shared transaction data
  • Flashtestations publish on-chain proofs of the code running in each TDX enclave

Signal-Boost (Flashbots Phase 2)

For Phase 2 decentralized building, Signal-Boost generalizes BuilderNet’s TEE architecture:

  • Untrusted parties can run code inside the builder’s TEE sandbox
  • The builder’s enclave attests that it executed the untrusted party’s code without modification
  • This enables co-building: multiple parties each build segments of a block; their code runs in isolated enclaves within the builder’s environment
  • Applications: DEX integrations with real-time state diffs, liquidation engines, cross-chain bridges, all operating at builder-time

DCEA (Data Center Execution Assurance)

Flashbots’ approach to extending TEE guarantees to physical hardware:

  • Standard TEE attestation proves what code runs but not where the hardware physically is
  • DCEA binds TEE attestation to specific physical deployments
  • “Proof of Cloud” variant: bind to a specific cloud provider region and configuration
  • Goal: prevent TEE attestations from being used from unauthorized/compromised hardware environments

Relationship to Other Privacy Technologies

TechnologyConfidentialityIntegrityPerformance
TEEYes (hardware)Yes (hardware)Near-native
MPCYes (cryptographic)Yes (cryptographic)High overhead
FHEYes (full computation)YesVery high overhead
ZK proofsPartial (outputs only)YesHigh overhead
aTLSConnection onlyConnection onlyNear-zero overhead

TEEs win on performance; MPC/FHE win on being hardware-agnostic and not trusting manufacturers.

Key Sources

  • Attested TLS in the Wild (2026) — cert-pubkey vs. EKM binding; T+ exchange and Flashbots applications
  • Decentralized Building: wat do? (Flashbots, Feb 2026) — Phase 0–3; Flashtestations; Signal-Boost; DCEA
  • What Emerged from the Blockspace Forum Workshop in Cannes (Apr 2026) — BuilderNet TEE presentation; value distribution; SUAVE reference