Skip to main content
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: 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

​
Failure modes

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