api.chipotle.litprotocol.com, your request terminates inside an Intel TDX Trusted Execution Environment (TEE) operated by Phala Cloud. The TEE generates a hardware-signed attestation quote on every boot, and the code it’s allowed to run is gated by smart contracts on Base — not by Lit Protocol or any Phala employee.
Start with the Phala Trust Center report for our production app. This page is a quick diagnostic guide, not a production attestation implementation. Viewing a report does not verify the connection your application uses to reach Chipotle.
View the Lit Chipotle Trust Center Report
Phala’s public Trust Center verifies the Intel TDX hardware quote, the Docker compose hash, the OS measurements, the TLS certificate, and the on-chain KMS configuration — all automatically, no install required.
app_id (3f91deaf16ff7c823ee65081d6bafa1ceea05ffc). This same value is returned by GET /info on the live API and is the address of the on-chain DstackApp contract that governs which code the enclave is allowed to run.
What you should expect to see
A passing Trust Center report confirms four independent properties:
If any of these fail, the report will show it.
Inspect API metadata and on-chain policy
These commands inspect what the API reports and whether its reported compose hash is whitelisted on Base. They are preliminary diagnostics, not a substitute for cryptographic verification.Production verification is integration-specific
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 attestation verification correctly in your integration. The implementation depends on your setup and where and how your client connects to the Chipotle server, including any proxies, gateways, and TLS termination points. Apply your approved workload and security policy, and bind verified evidence to the connection carrying your application traffic before sending secrets. Phala’s instructions do not select that application policy or enforce it in your client for you.TLS verification requires authenticated evidence
Comparing the live TLS certificate with a PEM fetched from the same server proves only that they match. A server with no attestation can serve a matching PEM. Before trusting a certificate binding, verify the evidence quote signature, validate its approved measurements and workload identity, and usereportData extracted from that verified quote. Then verify the checksum chain from reportData through sha256sum.txt to the certificate file and bind that certificate to the TLS connection you will actually use. Verifying the separate /attestation quote alone does not authenticate the TLS evidence quote.
Unauthenticated quote.json fields and matching hashes are not proof of attestation. See the Full Verification Guide for the verification layers and evidence format; its checksum comparisons are not a standalone substitute for quote signature and measurement validation.
On-chain governance you can audit
Smart contracts on Base together define what Lit Chipotle is allowed to do. Lit’s own governance contracts are administered by a Lit-controlled Safe multisig — no single party can change them. The Phala KMS contract is a shared Phala-operated contract governed by a separate Phala-controlled Safe.DstackApp
0x3F91…05FfC — whitelists the compose hashes (i.e. the docker-compose configurations) the Lit Chipotle CVM is allowed to boot.Phala KMS
0x2f83…Ba9C — whitelists allowed dstack OS images and KMS instance measurements. Gatekeeps key release to the CVM. This is a shared Phala-operated contract, governed by a separate Phala-controlled Safe (0x3926…a663), not the Lit Safe below.Safe Multisig
0xF688…1098 — Lit’s governance Safe. Owns the DstackApp contract above (and Lit’s AccountConfig). Any Lit deployment or config change requires multiple Lit signers.On-Chain KMS Deep Dive
What KmsAuth and DstackApp actually do, what “active” looks like on Basescan, and how key release is gated.
What’s next
- On-Chain KMS — how the KMS contracts gate key release and what to look for on Basescan
- Full Verification Guide — Chipotle-specific diagnostic examples and prerequisites; follow Phala’s instructions for production
- Chain of Trust Reference — what each layer checks and why
- Security & Verification Overview — Zero-Trust TLS and the trust model