TEE Coordinator Network

The Problem

A single TEE coordinator is a single point of failure. If it crashes after advancing durable nonces, users' pre-signed refunds are invalid and funds are stuck until recovery.

Sealed storage (bound to MRENCLAVE + CPU) is insufficient: if the CPU dies, sealed data is lost permanently.

Solution: Mutual Attestation + State Replication

Deploy a network of 2-3 TEE coordinators that replicate state through mutually attested channels:

TEE_1 (SGX/Nitro)  ◄── mutual attestation ──►  TEE_2 (SGX/Nitro)
   |                    (same MRENCLAVE/PCR)          |
   |                                                  |
   |              encrypted state replication          |
   |              (shares, policies, swap state)       |
   |                                                  |
   └──────────────►  TEE_3 (standby)  ◄──────────────┘

How It Works

1. Mutual Attestation at Boot

TEE_1 verifies TEE_2's attestation quote (same MRENCLAVE/PCR = same code). TEE_2 does the same. Only identical approved binaries can join the network.

2. Encrypted State Sharing

Once attested, TEEs share delegated shares and swap state over an encrypted channel. The host machine cannot read data in transit.

3. Automatic Failover

If TEE_1 goes down, TEE_2 already has all state and continues executing scheduled payouts. Users are routed to any available TEE.

4. User Perspective

Alice and LPs verify the attestation of whichever TEE they connect to. Same MRENCLAVE/PCR across all coordinators = identical verification.

Coordinator Network vs. TEE Quorum

Both can be combined for availability + security.

Precedents

• Signal Private Contact Discovery — SGX enclaves with mutual attestation
• Oasis Network — TEE node committee with state replication
• Secret Network — SGX enclaves with recoverable encrypted state