Attestation

The root of trust

Layrs runs its production ZEN markets inside an attested secure enclave (a TEE). The order book, balances, and matching logic all live inside that enclave; the host process that surrounds it never sees plaintext. But secrecy alone is not enough. You need a way to prove, before you ever send an order, that the code running inside the enclave is the code Layrs published — and not a tampered build that has quietly disabled privacy or is siphoning your order flow.

Attestation is that proof. It is the cryptographic root of trust for the entire private trading path. Every private action — opening a session, sealing an order, submitting to the relay — depends on the client having first verified a fresh attestation document against a known-good measurement. If that verification fails, the client refuses to trade. This is a deliberate fail-closed design: no attestation, no orders.

What PCR0 is

When the enclave boots, the platform measures exactly what was loaded — the enclave image — and records that measurement as a Platform Configuration Register. Layrs pins the enclave to PCR0, computed as a SHA-384 digest.

PCR0 is a fingerprint of the enclave image. If a single byte of the image changes — a different binary, a patched dependency, an added debug hook — the resulting PCR0 is different. There is no way to alter the running code without changing the measurement, and no way to forge a measurement that matches a different image.

The expected value is configured for the verifier as the environment variable LAYRSV2_ENCLAVE_PCR0_SHA384. This is the published, known-good measurement: the value the client insists the live enclave must match.

The attestation document

The enclave can produce a signed attestation document on demand. That document is signed by the attested-enclave platform's hardware root of trust — not by the enclave operator — and it carries, among other fields:

• the enclave's measured PCR values, including PCR0;
• a requestNonce — the caller's freshness challenge, echoed back inside the signed document;
• a transportPublicKey — the enclave's public key that clients use to seal orders.

Because the document is signed by the platform's hardware root of trust and not by the enclave operator, the operator cannot mint a document claiming a PCR0 it does not actually run.

How the client verifies

The client verifies attestation first, before any private order flow. Verification checks the live attestation document against the published measurement using an expected-PCR set and an explicit freshness policy:

expectedPcrs: { pcr0 }        // pcr0 = LAYRSV2_ENCLAVE_PCR0_SHA384
allowExpired: false           // reject any expired attestation document

Two things are worth calling out precisely:

• expectedPcrs: { pcr0 } — the document's PCR0 must equal the published LAYRSV2_ENCLAVE_PCR0_SHA384. A mismatch means the enclave is not running the code Layrs published, and verification fails.
• allowExpired: false — the document must not be expired. A stale document is rejected outright, even if its PCR0 matches. This closes the door on replaying an old, otherwise-valid attestation.

Only if verification succeeds does the client proceed: it seals a signed order to the enclave's transportPublicKey and submits it. The transport key comes from the same document that was just verified, which is what binds the encryption target to the attested measurement — you are provably encrypting to the enclave you just proved is genuine, not to a key an intermediary substituted.

The nonce requirement

Freshness is not optional. A verification that only checks PCR0 could be satisfied by a captured document from an earlier boot. To prevent that replay, the client supplies a nonce with every attestation request, and the enclave echoes it back inside the signed document as requestNonce. The client then confirms the nonce it sent is the nonce it got back.

The public endpoint enforces this at the protocol boundary:

• GET /v1/attestation requires a nonce query parameter.
• Called without one, it returns ATTESTATION_NONCE_REQUIRED.

So there is no way to obtain an unbound attestation document from the public API. Every document is tied to a challenge the caller chose, and freshness prevents replay.

:::tip Try it live Call the real attestation endpoint from your browser. A fresh nonce is generated per request, exactly as a client would.

:::

Transport public key binding

The transportPublicKey in the attestation document is the destination for all sealed orders. Because that key travels inside the signed, PCR0-verified, nonce-bound document, the client never has to trust a key it fetched separately or that the host handed it out of band. The chain of trust is unbroken:

1. The client challenges the enclave with a fresh nonce.
2. The enclave returns a signed document containing PCR0, the echoed nonce, and the transport key.
3. The client verifies PCR0 against LAYRSV2_ENCLAVE_PCR0_SHA384, confirms the document is not expired, and confirms the nonce matches.
4. Only then does it seal a signed order to the transport key from that document and submit it via POST /v1/private/relay.

The relay is ciphertext-only: plaintext never reaches an API container, database, or log. Attestation is what makes that guarantee meaningful — it proves the ciphertext is readable only by the specific attested enclave you verified.

Fail-closed on mismatch

The single most important property of this design is what happens when verification fails. If PCR0 does not match, if the document is expired, or if the nonce does not come back as sent, the client does not fall back, retry against an unverified endpoint, or trade anyway. It refuses to trade.

This is fail-closed behavior. The safe state is not trading. A compromised, out-of-date, or spoofed enclave cannot coax the client into leaking a plaintext order, because the client will not produce one until attestation has passed. There is no degraded mode in which privacy is quietly disabled.

Per-market attestation fields

Attestation is also surfaced per market, so the binding is visible in ordinary market data — not just at session setup. For each market, the public API returns privacy fields including:

Field	Meaning
hiddenBook: true	The per-user order book is not public; only aggregate depth is published.
attestedPcr0Sha384	The PCR0 (SHA-384) measurement bound to that market.
aggregateBucketMs	The bucket size for aggregate depth (for example, 1000).

The attestedPcr0Sha384 field ties each market to a specific attested enclave measurement, so a client can cross-check that the market it is trading and the enclave it verified are the same one. hiddenBook: true is the market-level statement of the privacy model that attestation ultimately backs: the host publishes aggregate depth and public receipts, never the per-user book.

Why this matters

Most "private" systems ask you to trust an operator's promise. Layrs replaces the promise with a measurement. Before a single order leaves your client, you have cryptographic evidence that:

• the enclave is running exactly the published image (PCR0 matches LAYRSV2_ENCLAVE_PCR0_SHA384);
• the evidence is fresh, not a replay (allowExpired: false, nonce echoed);
• your order will be sealed to that specific enclave's transport key and nothing else.

And if any of that fails, nothing is sent. That is the root of trust the rest of the privacy design stands on.