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:- Hot TEEs propose mutations — matched fills, deposits, withdrawals, settlements.
- The leader clearing-engine node batches proposals into a slot, the unit of state change.
- Peer nodes independently re-apply and validate the slot against the latest finalized state.
- A threshold of nodes signs the result, and the slot is final.
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: 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 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).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
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.
How it compares
The slot machine trades cryptographic guarantees for performance and privacy relative to public chains and rollups.
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.