> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tplus.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# TEEs

> What trusted execution environments are, how Tplus uses Intel TDX, remote attestation, and trustless replication with dstack.

A trusted execution environment (TEE) is an isolated compute environment whose code and runtime state can be measured and proven by hardware. Tplus runs its offchain services — the orderbook, order management, and the clearing-engine ledger — inside Intel TDX TEEs, while funds stay in onchain vaults that move only against a quorum-signed approval. The hardware lets the fast path run offchain without asking users to trust the operator hosting it.

Intel TDX deploys each service as a **trust domain** (TD): a virtual machine hardware-isolated from the hypervisor, the host OS, and the operator running the box. A TD gives Tplus two properties:

* **Confidentiality and integrity.** A TD's memory and CPU state are sealed from everything outside it, and its code is measured from firmware up. User data — orders, balances, matches — and deposit-vault credentials stay secret from the host, and the running code cannot be tampered with by the operator or the hypervisor.
* **Remote attestation.** A TD can prove to a remote party exactly what code it is running, anchored in the hardware manufacturer's trust root.

## Why TEEs

Trading systems need low latency, private order flow, and reliable accounting. Pure onchain execution gives strong public verifiability but is too slow and expensive for every orderbook event. A normal centralized server is fast, but users must trust the operator.

TEEs let Tplus put the fast path offchain while shrinking what the operator can do:

| Goal                   | How TEEs help                                                                                                      |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Fast matching          | The OMS and orderbooks run offchain instead of waiting for block production.                                       |
| Private execution      | User orders, balances, and checkpoint material stay inside attested services rather than being public chain state. |
| Verifiable deployment  | Peers accept connections only from services with valid hardware attestation and approved code measurements.        |
| Limited operator power | Operators host infrastructure, but cannot make vaults release funds without quorum-approved signatures.            |

## Remote attestation

Confidentiality and integrity are only useful if a counterparty can verify them. Remote attestation is how a relying party confirms it is talking to genuine TDX hardware running approved Tplus code:

1. The hardware manufacturer provisions an attestation key inside the chip, secured against software and physical extraction — this is the root of trust.
2. The TD produces a **quote**: a measurement of its firmware, configuration, and application code, signed with that attestation key.
3. The relying party verifies the signature against the manufacturer-provisioned key, then checks the measurements against the approved Tplus code. A valid signature over approved measurements proves the data came from hardware-protected, untampered Tplus code.

Tplus uses Intel DCAP, through the dstack framework, to produce and verify these quotes.

### Attested secure channels

For a user, knowing *what code* answers is as important as confidentiality, so attestation is bound to the connection itself. Tplus binds each quote to the TLS key used for the channel: the quote commits to the connection's public key, so a valid TLS certificate alone does not establish trust — that key must also appear in a verified quote. A peer that cannot produce a quote for an approved measurement is dropped before any confidential data is sent.

Internal connections are **mutually** attested and verified during the handshake: when an orderbook connects to the clearing engine, each side proves its TLS key belongs to an approved TD before protocol messages flow. The same channel secures user-facing entry points. A user still trusts their own client — browser, app, or Tplus client code — and the attested channel extends that trust to the backend it talks to.

## Hot and cold layers

Tplus separates offchain services into hot and cold TEE layers.

**Hot tier** — the OMS, orderbooks, and interest engine. They accept requests, match orders, and propose state changes, with the oracle and blockchain clients feeding prices and chain events alongside them. A hot service can be fast and lightly replicated because it is not the final authority over funds.

**Cold tier** — the clearing-engine quorum. It holds the authoritative ledger for balances, positions, fills, withdrawals, settlements, and interest. A proposed state change becomes final only when a threshold of clearing-engine nodes independently validates the transition and signs the resulting state.

So an orderbook match is immediate but provisional: the clearing engine still re-checks user signatures, cumulative fills, margin, protocol caps, oracle and mark prices, and chain finality before committing the fill. Of all these services, only the orderbook (hot) and the clearing engine (cold) hold durable state; the rest are stateless.

## Trustless replication with dstack

A single TD is a single point of failure: if its host goes down, the service goes with it. Tplus runs its components through **dstack**, a framework for deploying confidential VMs on TDX, so the protocol can operate redundant instances of each component and prove they run identical, approved code.

This is what makes the redundancy *trustless*. Because every instance must present a valid quote for the approved measurement before peers or users accept it (see [attested secure channels](#attested-secure-channels)), a backup can be run by a different operator without trusting that operator — the attestation, not the host, is the trust anchor. The same property is the path to permissionless operation: with no operator allowlist configured, any correctly attested instance is admitted, so new nodes can eventually be spun up without anyone's permission.

How a component is replicated depends on whether it holds state:

* **Stateless services** — the oracle, interest engine, blockchain clients, and the OMS (which only mirrors clearing-engine state) — keep nothing durable. Redundancy is just running more attested instances and routing around a failed one; there is no state to recover, so a hot-swap is seamless.
* **Stateful services** carry their state across instances:
  * The **orderbook** streams its log of state transitions to backup instances running the same attested code, and keeps an encrypted local snapshot. On restart it rebuilds from a backup or that snapshot; if a node is lost entirely, a backup is promoted to primary.
  * The **clearing engine** is replicated by its own quorum — peers re-apply every finalized slot — and periodically writes encrypted [checkpoints](/security/consensus#checkpoints) whose keys are split across a governance council. Leader failover and full-outage restart are covered in [Consensus & finality](/security/consensus#recovery).

## Quorum safety

The clearing engine does not rely on a single TEE. It combines hardware attestation with threshold signing.

For an action to finalize, a configurable threshold of the clearing-engine committee must agree on the same next state after applying the proposed action to the latest finalized state. Vault contracts then verify the resulting quorum signatures before accepting withdrawals or settlements.

TEE integrity alone is enough for the latency-sensitive hot services: a compromised orderbook or OMS can stall or misorder proposals, but cannot move funds, because the clearing engine re-validates everything. The clearing engine is different — it approves onchain movements — so it layers k-of-N threshold signing on top of TEE integrity. A single broken TD (for example, a leaked attestation key used to attest to a state the code never produced) cannot forge a withdrawal or settlement: it is one signature short of the threshold, and the vaults reject anything below it.

**Rotation.** As defense in depth, the protocol rotates which clearing-engine node may post checkpoints, the set of approved backups, and the hosts they run on. An attacker cannot easily learn which machine to target, and cannot count on prolonged physical access to any one box.

## Relationship to onchain contracts

The onchain contracts remain the custody root.

* Deposit vaults hold user funds.
* The credential manager registers operators, approved TEE measurements, and attested keys, and validates state checkpoints.
* Vaults verify quorum signatures, nonces, expiries, and registered credentials before releasing assets.

TEEs authorize offchain state transitions; they do not bypass onchain checks. If an approval is missing, expired, replayed, signed by the wrong keys, or below threshold, the vault rejects it.

## What TEEs do not solve

TEEs are a pragmatic security layer, not a cryptographic proof that every computation was correct.

| Limitation                           | Tplus mitigation                                                                                                                                          |
| ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Hardware or firmware vulnerabilities | Clearing-engine threshold signing, operator and host rotation, and measurement updates through governance.                                                |
| Bad code with a valid measurement    | Public audits, governance-controlled measurement changes, and clearing-engine revalidation of hot-TEE proposals.                                          |
| Full clearing-engine quorum outage   | Encrypted checkpoints and restart procedures; permanent failure falls back to the escape hatch.                                                           |
| Network censorship or unavailability | Users can use other attested OMS or orderbook instances where available; force-withdrawal paths are designed for severe failure modes.                    |
| Trust in TEE hardware                | Planned additions include stronger proof systems and broader economic security, but current production security still assumes TDX plus threshold signing. |

For the full hierarchy, failure modes, and escape hatch, see the [trust model](/security/trust-model).