> ## 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.

# Consensus & finality

> How the clearing-engine quorum agrees on state: slots, single-slot finality, checkpoints, and recovery.

The clearing-engine quorum runs as a network of cold [TEEs](/security/tees) that agree on every state change without a blockchain. This page covers how that agreement is reached, made final, and recovered after failure.

## Proposals and slots

Hot TEEs (the OMS and orderbooks) only *propose* state changes; they cannot mutate the ledger. Agreement runs in a coordinator the protocol calls the **slot machine**:

1. Hot TEEs propose mutations — matched fills, deposits, withdrawals, settlements.
2. The leader clearing-engine node batches proposals into a **slot**, the unit of state change.
3. Peer nodes independently re-apply and validate the slot against the latest finalized state.
4. A threshold of nodes signs the result, and the slot is **final**.

There is no confirmation wait: a slot is final the moment the threshold signs it (single-slot finality). One node is the active leader; peers validate and replicate but do not produce competing slots.

## What finality means for you

A state change is visible before it is final. The stages a fill passes through are listed in the [trust model](/security/trust-model#slot-lifecycle): an order-book match is **pending** (instant, unvalidated), the quorum's signature makes it **finalized**, and a later **checkpoint** is the durable recovery point. Withdrawal and settlement approvals are signed at checkpoint boundaries.

A pending fill is provisional, but in practice it is a **soft finalization**: because orders are validated and margin-checked before they reach the book, the quorum confirms the vast majority of fills unchanged, so a match can be treated as confirmed for most purposes. At finalization the quorum re-checks every party's margin and rolls back any leg that no longer passes — per party, so a counterparty's rollback does not void your own valid fill (fill-or-kill orders are the exception: they clear all-or-nothing across the batch). A [settlement](/funds/settlement) is atomic on the same principle: either the incoming asset is credited or the lock expires and the outgoing funds are restored, never both.

Replication between the leader and its peers is asynchronous — chosen for latency over durability. An acknowledgment means the leader processed your request, not that it is durably replicated; a leader crash in that window can drop the unreplicated tail (see [Recovery](#recovery)).

## Checkpoints

The quorum runs entirely in encrypted memory, so it periodically snapshots critical state (balances, inventories) to a **checkpoint**: encrypted to key shares split across a governance council distinct from the operators, and endorsed by peers. No single council member can decrypt it. A checkpoint is the point the system restarts from after a total outage.

## Recovery

| Failure                      | Response                                                                                                                                                                                                                                                                                                                                              |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Leader fails                 | A view change elects a new leader; peers already hold state through the last finalized slot. Trading continues — orderbooks keep matching and the OMS keeps risk-checking; fills buffer as pending until the new leader validates them.                                                                                                               |
| Unvalidated tail on failover | The new leader recovers buffered proposals and finalizes what it can. Only the proposals it cannot recover are rolled back (fills reversed, orders restored); [auto-reduce](/trading/orders#auto-reduce) then corrects any margin violations.                                                                                                         |
| Full quorum outage           | The system restarts from the latest checkpoint. The council re-supplies key shares to a fresh attested node, encrypting each share to that node's attested key so members never see plaintext state. The onchain credential manager certifies the restart and rejects an ambiguous one (two candidates claiming the same epoch with different state). |
| TEEs permanently offline     | Users exit onchain without operators via the [escape hatch](/security/trust-model#escape-hatch).                                                                                                                                                                                                                                                      |

Automatic leader election, and witness-encrypted checkpoints that would remove the recovery council entirely, are planned; today recovery uses a committee-quorum restart.

### What a restart recovers

A checkpoint captures finalized balances and inventories plus the per-chain deposit, withdrawal, and settlement nonces, as of one finalized slot. A restart loads it and resumes from the next slot; the window between the checkpoint and the outage is rebuilt by source.

* **Onchain events** — deposits, withdrawals, and settlements are anchored on-chain, so they outlive the outage. They are re-ingested from the chain on top of the checkpoint, and its per-chain nonces apply each exactly once: anything already in the checkpoint is skipped as a duplicate, anything that landed after it is applied. Nothing is double-credited or missed.
* **Off-chain mutations** — orderbook fills and resting orders exist only in TEE memory and the replicated log, which is replayed forward from the checkpoint as far as it was durably captured. This is where the unreplicated-tail risk above applies: a fill or order acknowledged but not yet replicated when the outage hit can be absent after restart. Orderbooks rebuild from the recovered state, and clients re-submit open orders.

Confirmed balances are safe in the checkpoint; only the most recent, not-yet-replicated off-chain activity is at risk.

## How it compares

The slot machine trades cryptographic guarantees for performance and privacy relative to public chains and rollups.

|            | Blockchains                    | Rollups                                | Slot machine                               |
| ---------- | ------------------------------ | -------------------------------------- | ------------------------------------------ |
| State      | Public                         | Public (posted to L1)                  | Private (encrypted in memory)              |
| Finality   | One to many blocks             | Fraud-proof window or proof generation | Single slot                                |
| Compute    | Re-executed by every validator | Must fit a ZK circuit                  | Arbitrary; no re-execution or proof        |
| Trust      | Cryptographic / economic       | Inherited from L1 + sequencer          | TEE hardware integrity + threshold signing |
| Throughput | Consensus-bound                | Proof-overhead-bound                   | No re-execution on the hot path            |

The trust model is the explicit tradeoff: hardware integrity plus threshold signing is weaker than a validity proof, in exchange for arbitrary offchain compute — portfolio margining does not fit in a ZK circuit — at low latency. Asynchronous ZK proofs and economic security (operator staking/slashing) are planned additions on top, verifying execution after the fact, off the hot path. See [what TEEs do not solve](/security/tees#what-tees-do-not-solve).