Introduction

What Layrs is

Layrs is a protocol for private prediction markets. You trade binary outcomes on where an asset's price will be at the end of a fixed time window, and the matching engine that runs your orders lives inside an attested secure enclave (TEE) — a trusted execution environment whose exact code you can verify before you ever send it an order. The privacy is not a policy promise; it is a property you can check cryptographically.

Every market on Layrs is a binary question resolved to one of three outcomes: UP, DOWN, or PUSH. A market asks whether an asset's price at the close of a window is above, below, or exactly equal to a reference price captured at the open.

Today, the production live path is ZEN-only. There are 6 open markets on Horizen across the window durations 15m, 1h, 4h, 1d, 1w, and 1mo. Everything in these docs describes that live generation-v2 system.

The core promise: verifiable privacy

Most "private" systems ask you to trust an operator. Layrs asks you to trust math and then gives you the tools to check it.

The production ZEN path runs a matching core (private_core) and the layrs-enclave binary inside an attested secure enclave (TEE). Inside that enclave, the sensitive parts of the exchange are sealed off from the operator, the host machine, and anyone observing the network:

• Opaque private-user identities and signed sessions
• Your available, held, collateral, fee, and position balances
• Deterministic price-time matching with self-trade prevention
• Complete-set mint/burn and one-to-one market collateral
• Signed Pyth price resolution
• An encrypted, hash-chained journal, deterministic receipts, and AEAD-encrypted snapshots

Outside the enclave, on the untrusted host, sit only the things that do not need to see your plaintext:

• Authentication and compliance eligibility
• Chain and Pyth connectivity
• VSOCK ciphertext transport — the host relays sealed bytes and never sees plaintext
• Encrypted journal and snapshot storage
• Aggregate depth and public receipt publication — never the per-user order book

The order book itself is hidden. Per market, the public API reports hiddenBook: true, an aggregateBucketMs bucketing interval (for example 1000), and an attestedPcr0Sha384 measurement bound to that market.

Why you can trust the enclave

Two facts make the boundary meaningful rather than decorative:

• The parent/host process cannot submit an admin operation without the Ed25519 operator key compiled into the EIF (the enclave image).
• A user cannot execute an operation without a registered enclave session, a valid signature, an unexpired request, and a strictly increasing sequence number.

Attestation: how you verify before you trust

Before sending an order, a client verifies the enclave's attestation. The enclave's identity is a measurement of its code — PCR0, a SHA-384 hash. Verification checks the attestation document's PCR0 against the expected value and requires that the document is not expired (allowExpired: false).

To prevent replay, attestation is bound to freshness. The public endpoint GET /v1/attestation requires a nonce query parameter; call it without one and it returns ATTESTATION_NONCE_REQUIRED. The returned document carries back the requestNonce you supplied plus a transportPublicKey — the key the client uses to seal its order to the enclave.

GET /v1/attestation?nonce=<fresh-random-nonce>
  -> attestation document { PCR0 (SHA-384), requestNonce, transportPublicKey }
  -> client checks PCR0 == expected AND document not expired

How an order flows

The order path is designed so plaintext never touches an API container, database, or log:

1. The client verifies attestation first.
2. Only if verification succeeds does it seal a signed order to the enclave's transportPublicKey.
3. It submits the sealed ciphertext via POST /v1/private/relay — a ciphertext-only relay.
4. Private sessions are established via POST /v1/private/sessions.

Inside the enclave the order is matched by deterministic price-time priority with self-trade prevention. Fees are 0 bps maker, 20 bps taker, plus a 5% fee on positive winning profit computed against per-position cost basis.

How markets resolve

Resolution uses a signed Pyth Pro feed and a strict, deterministic procedure at each boundary (open and close):

• Collect exactly 25 authenticated samples at 200 ms spacing over the 5 seconds ending at the boundary — the interval (T-5s, T].
• Each sample must report at least 3 publishers and retains its signed EVM payload.
• Take the 13th sorted E8 price — the median of the 25 samples — at each boundary.

The outcome rule is simply the comparison of the two medians:

Condition	Outcome
closing median > opening median	UP
closing median < opening median	DOWN
exact equality	PUSH

There is deliberately no recovery deadline and no alternate source. If a valid Pyth window is missing, resolution pauses indefinitely rather than falling back. Binance is intentionally not a launch fallback.

Settlement on-chain

Matching is private, but final settlement lands on-chain. The enclave signs a netted batch and settles 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. What reaches the chain is the netted batch, not your individual orders.

Two chains and one asset path

Layrs spans two chains:

• Horizen Mainnet, chainId 26514 (explorer horizen.calderaexplorer.xyz) — where the live ZEN market path runs.
• Base, chainId 8453 (explorer basescan.org).

ZEN is native on Base and an OFT (LayerZero Omnichain Fungible Token) on Horizen. Movement between the two happens over Stargate / LayerZero. The supported assets are USDC (Base, 6 decimals) and ZEN (Base 18 decimals / Horizen OFT 18 decimals).

Funding is structured so credit follows finality, not mere arrival:

• Deposits go to a generated one-time deposit address; the backend sweeps into the LayrsPool, and your private ledger is credited only after pool-side finality.
• Withdrawals move from your credited balance through an enclave-signed withdrawal authorization and coordinator screening to a pool payout, with destinations envelope-encrypted (KMS) as destination_ciphertext.

The public API

All read models and the private relay are served from a single public base: https://api.layrs.xyz, described in its OpenAPI spec as "Public read models and ciphertext-only private relay for Layrs generation-v2." Endpoints you will meet throughout these docs include:

GET  /healthz
GET  /v1/attestation                 (requires nonce)
GET  /v1/markets
GET  /v1/markets/{marketId}
GET  /v1/resolutions/{marketId}
POST /v1/private/sessions
POST /v1/private/relay
POST /v1/funding/deposits
POST /v1/funding/withdrawals

What to read next

This page set the frame; the rest of the docs go deeper into each piece:

• Attestation — verifying PCR0, nonce freshness, and binding a market to its measurement.
• Order flow — sealing, sessions, and the ciphertext relay in detail.
• Resolution — the Pyth sampling procedure and the UP/DOWN/PUSH rule.
• Settlement — batchSettle, the EIP-712 domain, and netted batches.
• Funding — deposits, withdrawals, and cross-chain ZEN.

Wherever a claim here mattered — the enclave boundary, the resolution rule, the fee schedule, the chains and assets — the deeper pages hold the exact detail. Start with Attestation, because on Layrs verification comes before trust.