Trustless TEEs Open Hardware and ERC-733

Summary

Current TEEs (Intel TDX/SGX, AMD SEV) require trusting closed-source hardware from a single manufacturer. The Trustless TEE (TTEE) initiative, led by Quintus Kilbourn (Flashbots), aims to produce open, physically verifiable, and side-channel-resistant secure hardware within 3 years using Physical Unclonable Functions (PUFs), optical chip inspection (IRIS), and hardware masking for side-channel resistance. ERC-733 (Zhang + Miller, January 2026) is a draft standard for integrating any TEE — including future TTEEs — with the Ethereum EVM, providing a three-layer framework (Attestation, Replication, Interoperability) and a security staging model.

The Problem with Current TEEs

Trust Hierarchy

Standard remote attestation (Intel TDX, AMD SEV) requires trusting:

The hardware manufacturer (Intel/AMD): could issue fraudulent attestation keys; could have backdoors in microcode
The supply chain: hardware could be tampered between fab and deployment
Firmware/microcode: usually closed-source and unauditable

For MEV infrastructure (block builders, encrypted mempool keyholders, relays), this trust hierarchy is a meaningful attack surface. A compromised Intel root-of-trust could allow silently reading secrets from all TEE enclaves globally.

Side-Channel Attacks

Even genuine TEE attestation doesn’t prevent:

Cache timing attacks: execution time reveals memory access patterns (SPECTRE-class)
Power analysis: measuring power consumption while the enclave runs reveals secret operations
Memory bus snooping: observing DRAM bus traffic reveals access patterns
Acoustic/electromagnetic emissions: physically near hardware can capture side channels

Many high-value exploits against TEEs use side channels rather than breaking attestation directly.

Supply Chain Attacks

A chip modified between fabrication and deployment cannot be detected by software attestation. The attestation certifies what code runs but not whether the hardware is the original unmodified chip.

TTEE: Trustless TEE Initiative

Physical Unclonable Functions (PUFs)

PUFs exploit natural manufacturing variation in semiconductor circuits. Every chip has microscopic differences in transistor threshold voltages, oxide thickness, etc. that produce a unique “fingerprint.”

Operation:

Challenge-Response: send an electrical challenge to the chip; the response depends on its physical structure (which the manufacturer cannot predict in advance)
The PUF is used to derive a secret key unique to the chip
The key cannot be cloned: another chip with the same design produces a different response

Anti-tamper property: physical tampering (probing, reverse engineering) destroys the delicate manufacturing variation → the PUF response changes → the derived key changes → any existing attestation certificates are invalidated.

TTEE use: PUF-derived keys are stored nowhere (no key material to steal). The PUF is the “key” in a physical sense. Attestation certificates can be bound to PUF responses, making them physically tied to the specific chip.

IRIS: Optical Chip Inspection

IRIS (non-destructive optical inspection) allows verifying that a chip’s physical structure matches its design specification, without opening the package or destroying the chip.

Technique: infrared light passes through the chip substrate; interference patterns are compared against a golden reference (the original design). Deviations (extra circuits, modified routing) are detectable.

TTEE role: an independent inspection body (analogous to a certificate authority) physically inspects chips using IRIS, verifies they match the expected design, and issues a certificate. Remote users trust this certificate rather than trusting the manufacturer directly.

Supply chain assurance: IRIS inspection at multiple points in the supply chain (fab, shipping, data center installation) can detect tampering at any stage.

Masking: Hardware-Level Side-Channel Resistance

Masking is an MPC-on-chip technique that splits every sensitive computation into multiple shares:

Each share carries no information about the secret value
Only the combination of all shares reveals the output
Power consumption and timing of each share are independent of the secret

Key 2023 breakthrough: arbitrary composability of masked circuits was achieved. Previously, composing two masked circuits (e.g., masked AES followed by masked SHA-256) required re-randomization overhead between them. The 2023 result allows masked circuits to be composed without overhead, enabling automated secure circuit synthesis.

Raccoon: a post-quantum signature scheme (Dilithium-class) designed with masking compatibility. Standard Dilithium is not efficiently maskable; Raccoon was designed specifically to be. This enables leakage-resilient PQ signatures that don’t reveal secret keys even to physical side-channel attackers.

TTEE Timeline

3-year goal (from 2025): produce an open, physically verifiable, maskable TEE with:
- PUF-based key derivation (no manufactuer-held root of trust)
- IRIS-inspectable structure (independent supply chain verification)
- Fully masked cryptographic operations (side-channel resistance)
- Open-source hardware design (public RTL/GDSII)

Key reference papers (named in Kilbourn’s presentation):

Trusted Increment: non-equivocation-based consensus using TEE properties
Zipnet: liveness from TEE + anonymity from cryptography (complementary assurance)
Raccoon: maskable PQ signature scheme enabling leakage-resilient auth

ERC-733: TEE+EVM Co-Processing Standard

ERC-733 (Justin Zhang + Andrew Miller, draft v4, January 2026) standardizes how any TEE (current or future TTEE) interacts with Ethereum’s EVM. Three-layer architecture:

Layer 1: Attestation

Encumbered Keys:

A secp256k1 keypair is generated inside the enclave at startup
The private key never leaves the enclave (encumbered: cannot be extracted without breaking TEE security)
The public key is embedded in the attestation quote
The on-chain registry maps: enclave_id → (code_hash, public_key, attestation_quote)

On-Chain Registry (ERC-733 Registry Contract):

Any address can register an enclave by submitting its attestation quote
The registry verifies the quote (using on-chain attestation verification, e.g., via a SNARK verifier)
After registration, other contracts can check: “did this message come from an enclave running code_hash X?”

Code Integrity:

The attestation quote contains the SHA-256 hash of the code running in the enclave
Smart contracts can condition trust on specific code hashes
Upgrades require registering a new attestation with the new code hash

Layer 2: Replication

Enclave-held secrets must survive hardware failures, support load balancing across multiple enclaves, and enable upgrades.

Options:

MPC-based replication: secret is shared using threshold secret sharing (Shamir’s) across N enclaves. Each enclave holds one share. M-of-N enclaves must cooperate to reconstruct. If M enclaves fail, secret is lost.
KMS-based replication: a trusted Key Management Service holds the encryption key for the enclave’s secrets. On restart/migration, the KMS re-encrypts the secret for the new enclave’s public key.

MPC replication is more decentralized but requires N enclaves to be online. KMS is simpler but adds trust in the KMS operator.

Upgrade flow: new enclave registers a new attestation → old enclave verifies the new enclave’s code hash matches expected upgrade → MPC resharing protocol transfers shares to include the new enclave → old enclave is removed from the active set.

Layer 3: Interoperability

TLS Integration: enclaves often need to connect to external services (oracles, off-chain data, other protocols). ERC-733 standardizes attested TLS (aTLS) for these connections:

Enclave generates TLS certificate using its encumbered key
Certificate is bound to the attestation quote
External parties can verify they are connected to a specific code version

Web2 Integrations:

REST API calls from inside TEE (with aTLS)
WebSocket connections for real-time data
OAuth flows where the enclave acts as a trusted proxy

Security Stages

ERC-733 defines a progression of security maturity:

Stage	Description	Trust Assumption
0	Prototype	No formal security; development only
1	Deployed TEE	Trust hardware manufacturer (Intel/AMD)
2	Multi-operator TEE	Trust 1-of-N operators (BuilderNet model)
3	Trustless TEE	Trust TTEE hardware (PUF + IRIS + masking)

Stage 3 is the TTEE target: no trust in any software or organizational entity, only in verifiable physics.

Applications

Trustless Agents (ERC-8004): on-chain autonomous agents whose code is TEE-attested; can sign transactions and hold funds without a human custodian
Private DEX: order matching inside TEE; traders don’t reveal orders to each other or to the sequencer
Oracles: price feeds computed inside TEE, attested on-chain; manipulating the oracle requires compromising the TEE
Bridges: cross-chain message relay inside TEE; bridge compromise requires hardware attack
DAO Governance: vote tallying inside TEE; vote privacy + provably correct counting

Reference Implementations

Flashtestations (Flashbots): on-chain TDX attestation verification; used in BuilderNet
Dstack TEE (by ERC-733 contributors): reference implementation of the three-layer stack
Oasis ROFL (Runtime Off-chain Logic): framework for running off-chain computations with on-chain attestation

Integration: TTEE + ERC-733

The TTEE initiative provides the hardware; ERC-733 provides the software framework. When TTEE hardware becomes available:

Inspection body issues PUF-certified hardware certificates (IRIS-verified)
Enclaves running on TTEE hardware self-attest using PUF-derived keys
ERC-733 registry accepts TTEE attestations alongside Intel/AMD attestations
Smart contracts that today trust Intel root-of-trust can migrate to trusting TTEE certificates without changing their interface

Open Questions

❓ When will TTEE hardware be production-ready? The 3-year timeline from 2025 suggests 2028; MEV infrastructure timelines are shorter.

❓ How does IRIS inspection scale? Physically inspecting every deployed chip requires significant logistics.

❓ Can ERC-733’s on-chain attestation verifier be made gas-efficient enough for frequent use? (SNARK verifier for Intel attestation is expensive.)

❓ How does ERC-733’s security stage model interact with formal protocol security definitions?

Timeline

2023 — Arbitrary composability of masked circuits achieved (key milestone for masking)
2026-01 — ERC-733 Draft v4 published by Justin Zhang + Andrew Miller
2025-08-08 — TTEE initiative presented by Quintus Kilbourn (Flashbots) at MEV-SBC 2025