> ## 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. # Trust model > Custody, attestation, signing, failure modes, and current limitations. Funds are custodied by onchain vault contracts. The offchain system can only release them by producing quorum-signed, nonce-bound, expiring approvals that the contracts verify. ## Trust hierarchy Four tiers, from most to least trusted: 1. **Onchain contracts**: deposit vaults, the registry, and the credential manager. The credential manager is the root of trust: it binds each operator to a dual key (operator identity key plus hardware-attested key, both required) and pins approved TEE code measurements. Its governance is timelocked: risk-parameter changes 48h, registry changes 72h, code-measurement and delay changes 7 days. 2. **Clearing engine**: the authoritative ledger, run as an MPC+TEE quorum across Intel TDX nodes. State changes require a k-of-N threshold. Its coordination protocol, the Slot Machine, batches proposals into slots that peers independently validate and threshold-sign. Slots are final once signed; there is no fraud-proof window. 3. **Hot TEE components**: OMS, orderbooks, interest engine. These can only propose mutations. The clearing engine re-verifies user signatures, bounds-checks rates, and requires chain finality on chain events, so a compromised hot component cannot move funds or forge fills. 4. **External parties**: user requests (signature-verified), settlers (registry-verified), RPC providers (majority agreement across multiple independent endpoints; no single provider is trusted). ## Attestation Internal connections are bound to hardware attestation: a peer's Intel TDX quote must attest to the TLS key it connects with. A valid certificate alone does not admit a peer. Attestation uses Intel DCAP, via dstack (a framework for running attested containers on TDX). ## Slot lifecycle A state change passes through three stages: | Stage | Meaning | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | | Pending | Orderbook match. Instant and unvalidated, but a soft finalization — valid in the vast majority of cases. Visible on trade-event streams. | | Finalized | The quorum validated and threshold-signed the slot. Trades stream as confirmed at this point. | | Checkpointed | State snapshotted into an encrypted, peer-endorsed recovery point. Withdrawal and settlement approvals are signed at checkpoint boundaries. | If the clearing engine is unavailable, orderbooks keep matching and the OMS keeps risk-checking; fills buffer as pending until a new leader validates them. ## Operator constraints | Operators cannot | Enforced by | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Move funds | Vaults verify quorum signatures, nonces, and expiries on every approval | | Sign alone | `withdrawalQuorum` distinct signatures for withdrawals; k-of-N threshold for state changes | | Reorder or tamper with state | Single-writer, deterministically ordered event loop; transactional operations roll back fully on validation failure | | Read checkpoints alone | Checkpoint keys split (Shamir k-of-N) across a governance council distinct from the operator set | | Liquidate an account above maintenance margin | Liquidation fills validated at clearing against maintenance margin at both oracle and mark price | ## Failure modes | Scenario | Impact | Mitigation | | ------------------------------- | -------------------------- | ----------------------------------------------------------------------------- | | Single TEE node fails | Service interruption | Replicas take over (dstack); users can switch to another attested instance | | Clearing-engine leader fails | Settlement paused | View change; quorum elects a new leader | | Clearing-engine majority fails | Clearing halted | Restart from encrypted checkpoint | | TEE network permanently offline | No trades or settlements | Escape hatch (below) | | TDX silicon vulnerability | Attestation weakened | Quorum rotation; MPC majority still required | | Oracle manipulation | Incorrect pricing | Dual-price checks; [circuit breakers](/trading/liquidations#circuit-breakers) | | Chain reorg | Events could be dropped | Confirmation queue holds events until finality | | Settler fails to execute | Assets locked until expiry | Locks expire; funds return to the user | ## Escape hatch Users can exit without operator participation. A user submits a bonded withdrawal request to an onchain inbox contract. During a timelock window, the clearing-engine quorum can reject invalid requests, slashing the bond. After the window expires unchallenged, the withdrawal executes with no operator involvement. Limitation: the escape hatch is reliable for plain balances only. Prices move during the timelock, so leveraged positions cannot be exited at a known value; close open borrows before relying on it. ## Signing and replay protection ### User signing Orders and requests are signed with the account's Ed25519 master key. Optional multisig adds secp256k1 / P-256 / WebAuthn co-signers with weight-based thresholds per action category; withdrawals, settlements, and transfers can require a higher threshold than trading. Signatures are validated before any state change, with low-s normalization against malleability. See [Multisig](/trading/multisig) for the configuration model, signer schemes, and action tiers. ### Protocol signing Withdrawal and settlement approvals use a custom typed keccak256 scheme with secp256k1 ECDSA. A domain hash binds vault address, chain, and schema version; a type tag identifies the approval schema; and fixed-width encoded fields are concatenated into `keccak256(bytes.concat(...))`. This is not standard EIP-712: there is no `\x19\x01` envelope and no EIP-712 struct hash. Vaults verify signatures against registered keys. ### Replay protection Nonces are independent per user, per chain, and per action type; settlement nonces are additionally per sub-account. Orders carry timestamps with a 30-day maximum TTL, order IDs are unique per user, and cumulative fill tracking prevents overfills. Every approval carries a `valid_until` expiry. ## Price integrity Oracle prices come from Chainlink, Pyth, and CEX feeds through threshold RPC consensus; the freshest source wins per asset, and updates with source timestamps more than 5 seconds from local time are rejected. The mark price is an EMA of worst-fill trade prices, which resists single-print manipulation. Trade admission must pass IM at both oracle and mark price; liquidation requires the account to be below maintenance margin under the dual-price rule. Stale prices trigger [circuit breakers](/trading/liquidations#circuit-breakers). The oracle feed-to-asset mapping can only be rotated by a council-signed operation. ## Current limitations * Clearing-engine operators are currently a known, permissioned committee. Permissionless access exists at the hot-TEE layer: anyone can run their own attested OMS or orderbook via dstack, and the credential manager admits any correctly attested instance. A federated, permissionless cold-TEE quorum is on the roadmap. * The trust root is TEE hardware plus threshold signing, a weaker guarantee than pure cryptography. Asynchronous ZK validity proofs and economic security (staking/slashing) are planned additions; witness-encrypted checkpoints, which would remove the recovery council, are research-stage. * Recovery from full-network failure requires the governance council to reconstruct checkpoint decryption keys into a fresh attested TEE.