What Is Attestation?

Every other page in this section tells you how to verify Lit Chipotle. This page explains what you are actually verifying and why it is trustworthy — in plain language, before any commands. If you have never worked with a Trusted Execution Environment (TEE) before, start here.

​

The problem attestation solves

When you send data to an ordinary cloud server, you are trusting a lot of people you will never meet: the application operator (Lit), the cloud provider (Phala/Intel), the OS administrators, anyone with physical access to the machine. Any of them could, in principle, read your data, swap the code for a malicious version, or copy out a private key. You have no way to tell. “Trust us” is the only guarantee. Remote attestation removes that trust. It lets a remote machine produce hardware-signed, mathematical proof of exactly what code it is running. You can check the proof yourself, and no operator (including Lit) can forge it. You no longer have to trust the operator. You still trust Intel’s hardware and the math that checks its signature. Attestation tells you which code is running. It doesn’t tell you that the code is free of bugs, which is one reason the Lit Chipotle source is public. This is the idea behind the broader Proof of Cloud movement: cloud services that prove what they run rather than asking you to take their word for it.

​

What a TEE is

A Trusted Execution Environment is a hardware-isolated region of a CPU. Lit Chipotle runs inside Intel TDX (Trust Domain Extensions), a TEE built into recent Intel server chips. Inside the TEE:

• Memory is encrypted by the CPU. Even someone with root on the host, physical access to the RAM, or a hypervisor cannot read the plaintext.
• The boot chain is measured. As firmware, kernel, and application load, the CPU records a cryptographic hash of each stage into tamper-proof registers.
• Secrets generated inside (like the TLS private key) never leave. There is no API to extract them, by design.

Lit Chipotle runs as a confidential virtual machine, or CVM, inside TDX. These pages use “CVM” for that machine and “enclave” as another word for the TEE. A TEE is not magic — it rests on the assumption that Intel’s hardware root of trust is sound, and TEEs have known classes of side-channel research. But it replaces many fully-trusted humans with one well-studied hardware assumption you can reason about.

​

What an attestation quote is

When the TEE boots, it produces an attestation quote: a small binary document, signed by Intel’s hardware root of trust, that contains the measurements of everything that loaded. Think of it as a notarized receipt the silicon hands you, saying “here is exactly what I am running.” The measurements live in registers called MRTD and RTMR0–RTMR3: Two numbers carry most of the weight:

• The OS measurements (MRTD/RTMR0–2) prove which operating system image booted.
• The compose hash (in RTMR3) proves which application code booted — it is the SHA-256 of app-compose.json, which holds the exact, image-digest-pinned docker-compose that defines Lit Chipotle, plus its metadata. The explainer videos call it the release hash.

If even one byte of the OS or the application changes, these numbers change, and the quote no longer matches what is expected. For example, if a payment program that sends 1,000 were changed to send 1,001, its hash would come out completely different.

​

How a stranger turns a quote into trust

Receiving a quote is not enough — anyone can hand you a document. The value comes from four independent checks, each of which you can run yourself:

1. Is the quote real? Verify Intel’s signature on the quote against Intel’s published root certificates. This proves the quote came from genuine TDX hardware running with security patches up to date (not a simulator, not debug mode).
2. Is the OS one I trust? Check the OS measurements against a known-good dstack OS release — and confirm that release is whitelisted on-chain (see below).
3. Is the code one I trust? Recompute the compose hash from the public source and confirm it matches the quote — and that it is whitelisted on-chain.
4. Am I really talking to that TEE? The TLS certificate for api.chipotle.litprotocol.com was generated inside the TEE and bound into the quote. Once you have checked that binding and pinned the certificate, a successful HTTPS handshake proves your connection terminates in the attested enclave — no proxy in the middle. A handshake on its own, before those checks, does not prove this. (See Zero-Trust TLS.)

The crucial move is in steps 2 and 3: “a version I trust” is not decided by Lit. It is decided by a whitelist held in smart contracts on Base, governed by a Safe multisig. Lit cannot ship code to the production enclave without first getting that code’s compose hash approved on-chain, in public, by multiple signers. That is what the On-Chain KMS page covers, and the approval process itself is documented in Upgrade Governance.

​

Why this is stronger than “trust the operator”

Put the pieces together and the trust model inverts:

• The cloud provider cannot read your data — memory is CPU-encrypted.
• Lit cannot silently change the code — a new version cannot get keys until its compose hash is whitelisted on Base by a multisig, visible to everyone.
• No single Lit employee can change that whitelist — it takes a multisig quorum.
• You do not have to trust any of the above — you re-derive every measurement and read the on-chain whitelist yourself.

That is the whole point of attestation: you check the evidence yourself instead of taking anyone’s word for it.

​

The stronger check in the Lit SDK

verifyLitEndpoint() in @lit-protocol/keychain (2.3.0 and later) runs every check above with no configuration. It is opt-in: Keychain, Owner, the CLI and MCP keep running the original checks, unchanged, and nothing calls verifyLitEndpoint() unless your code does. It reads GET /attestation/v2?nonce=…, which adds two things the plain /attestation quote cannot provide:

• The OS image is tied to the hardware measurement. The event log that names the OS image is written by the guest itself, so on its own it proves nothing about what booted. dstack’s KMS, however, releases an app’s keys only to a CVM whose MRTD/RTMR0–2 match a whitelisted OS image and whose compose hash is governed. The endpoint returns a signer derived from those keys with the KMS signature chain, and the SDK checks that chain against the KMS root key published in the DstackKms contract, which must also match the root pinned in the SDK so a dishonest Base RPC cannot substitute its own. A machine that did not boot the approved image cannot produce it.
• Freshness. The signer signs a random nonce chosen by the SDK together with the hash of the quote it serves, so a response cannot be replayed or paired with another machine’s quote.

In Node it also binds the TLS certificate the origin serves to the enclave and returns it as tlsCertificateSha256. Requests are bound to the attested enclave only on connections that pin that certificate. The SDK’s own connections do not, so pin it in your HTTP client if you need that. Failures throw an AttestationError with a stable code (for example BOOT_BINDING_FAILED, KMS_MISMATCH, STALE_OR_REPLAYED, NOT_GOVERNED). verifyAttestation(), the original check the SDK’s connections use, is unchanged and performs neither check above. This relies on the governed KMS enforcing its OS-image whitelist when it releases keys (dstack’s default). It does not check Intel TCB status or PCK revocation. Browsers cannot read or pin TLS certificates: there the check proves that genuine Lit evidence was served at the origin, and the requests that follow rely on the browser’s own TLS validation.

​

Production verification is your integration’s responsibility

For full production verification, follow Phala’s official application verification instructions and complete chain-of-trust checklist, the authoritative references for Phala/dstack verification. You are responsible for implementing and enforcing these checks for your setup and the path your client uses to reach Chipotle, including any proxies and TLS termination points. A report or matching hashes alone cannot authenticate that connection; your client must enforce your approved workload and security policy against authenticated evidence.

​

What’s next

​

Further reading

• Proof of Cloud — the verifiable-cloud movement
• Intel TDX overview
• Phala: Attestation Overview
• Phala: Complete Chain of Trust