The private CLOB

Layrs runs a central limit order book (CLOB) whose order matching, balances, and user identities live entirely inside an attested secure enclave (a trusted execution environment, or TEE). The host machine that operates the enclave — the parent process — moves ciphertext in and out but never sees the plaintext book, never learns who is trading, and cannot act on its own. This page describes exactly what lives inside that boundary, what stays outside, and the controls that make the boundary hold.

Inside vs. outside

The enclave is the trust boundary. Everything that could reveal a user's identity, position, or intent stays inside it. Everything that must talk to the outside world — the chain, the oracle, authentication — stays outside and only ever handles ciphertext or already-public aggregates.

Inside the enclave (private)	Outside the enclave (host / public)
Opaque private-user identities and signed sessions	Authentication and compliance eligibility
available, held, collateral, fee, and position balances	Chain and Pyth connectivity
Deterministic price-time matching with self-trade prevention	VSOCK ciphertext transport (host never sees plaintext)
Complete-set mint/burn and one-to-one market collateral	Encrypted journal and snapshot storage
Fee accounting (0 bps maker / 20 bps taker, 5% winning-profit fee)	Aggregate depth and public receipt publication
Signed Pyth resolution	—
Encrypted hash-chained journal, deterministic receipts, AEAD-encrypted snapshots	—

The key asymmetry: the host stores the encrypted journal and snapshots, transports sealed orders, and publishes aggregate depth and receipts — but the per-user order book, the identities behind it, and the matching logic never leave the enclave in the clear.

What lives inside the enclave

Identities and sessions

User identities inside the enclave are opaque — they are not the wallet address or the login the outside world sees. Trading happens against a registered, signed session rather than a raw account, so the matching engine operates without ever handling an externally identifying key.

Balances

The enclave is the sole authority for the ledger. It tracks five balance categories per user:

• available — funds free to trade or withdraw
• held — funds reserved against open orders
• collateral — funds locked backing positions
• fee — fee accounting
• position — the user's outcome holdings

Because these balances live inside the enclave, no host container, database, or log ever holds a per-user balance in plaintext.

Matching and self-trade prevention

Matching is deterministic price-time: orders are prioritized by price, then by time. Determinism matters because the same inputs must always produce the same fills — that is what lets the encrypted journal be replayed and verified. The engine also enforces self-trade prevention, so a single user's resting and incoming orders cannot cross against each other.

Complete-set mint/burn and collateral

Layrs markets are binary (UP / DOWN / PUSH on a price boundary). The enclave manages complete-set mint and burn with one-to-one market collateral — each market's outstanding positions are fully backed by collateral held inside the enclave, so the ledger stays solvent by construction rather than by trust.

Fees

Fees are computed and accounted inside the enclave:

• 0 bps maker — resting liquidity pays no fee
• 20 bps taker — orders that remove liquidity pay 20 basis points
• 5% positive winning-profit fee — charged on realized winning profit, computed against a per-position cost basis

The winning-profit fee only applies to positive profit and is measured per position against its own cost basis, so it is a fee on gains rather than on volume or on principal.

Journal, receipts, and snapshots

Every state transition is written to an encrypted hash-chained journal — each entry commits to the prior one, so any tampering with history is detectable. The engine emits deterministic receipts for actions, and it exports state only as AEAD-encrypted snapshots (authenticated encryption). A snapshot carries the journal sequence/head and the state root, and nothing about it is legible outside the enclave.

What lives outside the enclave

The host process is deliberately kept ignorant. Its jobs are the ones that require talking to the outside world:

• Authentication and compliance eligibility — checking that a would-be trader is allowed to trade, before anything is sealed to the enclave.
• Chain and Pyth connectivity — reaching the settlement chain and the price oracle.
• VSOCK ciphertext transport — the local channel between host and enclave. The host relays sealed bytes across VSOCK; it never sees plaintext orders.
• Encrypted journal / snapshot storage — the host persists the enclave's encrypted journal and snapshots, but cannot read them.
• Aggregate depth and public receipts — the host publishes book depth as aggregates and publishes receipts, never the per-user order book.

This is why market data over the public API exposes hiddenBook: true and an aggregateBucketMs bucket size (for example, 1000) instead of a raw book: the only depth that ever leaves the enclave is bucketed and aggregated.

The controls that hold the boundary

The privacy guarantees rest on two hard requirements — one on the operator side, one on the user side.

The parent cannot act alone

The parent/host process cannot submit an administrative operation without the Ed25519 operator key that is compiled into the EIF (the enclave image). Because the key lives inside the measured enclave image rather than on the host, operating the machine is not the same as controlling the ledger. A compromised host still cannot forge an admin op.

Users need four things, every time

A user cannot execute an action unless all four of the following hold:

1. a registered enclave session,
2. a valid signature,
3. an unexpired request, and
4. a strictly increasing sequence number.

The unexpired-request rule bounds how long any sealed message is valid, and the strictly-increasing sequence rule prevents replay and reordering — an old or duplicated request is rejected because its sequence number is not strictly greater than the last one accepted.

How an order reaches the book

Because the host is untrusted, the client verifies the enclave before it trusts it with anything.

1. The client fetches an attestation from GET /v1/attestation — which requires a nonce query parameter (without it the API returns ATTESTATION_NONCE_REQUIRED). The nonce guarantees freshness and prevents replay of an old attestation.
2. The client verifies the attestation. The enclave measurement is PCR0 (SHA-384); verification checks the expected pcr0 and requires the document to be unexpired (allowExpired: false). The attestation document carries the requestNonce and a transportPublicKey. Each market also advertises the attestedPcr0Sha384 measurement bound to it.
3. Only after verifying does the client seal a signed order to the enclave's transportPublicKey and submit it through POST /v1/private/relay, a ciphertext-only relay. Plaintext never reaches an API container, database, or log. Private sessions are established at POST /v1/private/sessions.

So the trust order is: verify the enclave, then encrypt to it, then submit. The host is never in a position to be trusted with a plaintext order.

Settlement leaves the enclave netted

What ultimately reaches the chain is not a stream of per-user orders. The enclave signs a batch and it settles on-chain via batchSettle on the MatchSettlement contract, under the EIP-712 domain { name: 'LayrsMatchSettlement', version: '1', chainId: 26514 }. A batch is a list of fills — (marketId, buyer, seller, quantity, price, fee, nonce) plus a deadline — signed by the enclave. Because only the netted batch is published, the on-chain footprint reveals settlement outcomes without exposing each user's individual orders.

Recovery, without weakening the guarantees

Recovery is designed so that restoring state can never be a way around the enclave's invariants. The enclave exports only AEAD-encrypted snapshots (journal sequence/head plus state root). On restore, the enclave rejects corruption and rejects any snapshot older than an independently anchored minimum sequence — this is the defense against a rollback attack, where a stale-but-valid snapshot might otherwise be replayed to undo settled activity. Receipts and journal records are archived to Object Lock storage, and checkpoints are anchored to a public audit rail.

The behavior is exercised by tests covering atomic ledger failure, price-time ordering, self-trade prevention, FOK behavior, journal tamper detection, collateralized trading, resolution fees, snapshot restore, and rollback rejection.

Why the split matters

The design goal is that privacy does not depend on trusting the operator. Identities, balances, matching, and fees live where the host cannot see them; the host handles only ciphertext, aggregates, and public receipts. The operator key sits inside the measured image, so running the host is not the same as controlling the ledger; and every user action must carry a session, a signature, an unexpired request, and a strictly increasing sequence before the enclave will act on it. Attestation lets any client confirm — against PCR0 — that it is talking to exactly that enclave before it entrusts it with an order.