The Chipotle Network

Chipotle’s core guarantee is short: a key’s authority is on-chain state.^[10] What a key may sign, which code may use it, and who can change those rules live in smart contracts on Base. Nothing off-chain — no server, API key, or operator, Lit included — can make a key sign outside the rules currently on the chain. Lit calls this property Chain Secured. The on-chain parties that approve the software and contracts enforcing those rules are covered in §4. Six design principles follow.

• ◆Authority lives on-chain. Accounts, API-key scopes, wallets, and groups are contract state, not rows in an operator’s database. Changing a rule is a public transaction authorized by the account owner.^[10]
• ◆Enforcement is a read. Setting or changing a rule is a write, made only when someone configures or governs. Using a rule is a read: the enclave checks current on-chain state and signs, with no per-operation transaction, gas, or block confirmation. Authority stays on-chain while signing runs at the speed of an API call.^[10]
• ◆Code is content-addressed. A Lit Action is identified by the IPFS CID of its source. Change one byte and it is a different action with different permissions.^[11]
• ◆Keys stay in hardware. Key material is derived and used inside the TEE and never leaves the enclave through the service. Only code an owner has permitted can use a key.^[12][11]
• ◆Releases are approved in public. New enclave software cannot obtain keys until a multisig whitelists its measurement on Base, so no single party can push code to the production enclave on its own.^[13]
• ◆Anyone can verify. Attestation quotes, release whitelists, and permissions can all be checked by a third party with public tools, and the whole stack can be self-hosted and governed by its users.^[14][15]

Chipotle is built from three composable layers, each with a distinct job: a TEE enclave that holds keys and runs code, smart contracts on Base that hold authorization state, and Lit Actions that define what code may do.^[12]

3.1Confidential execution

The hosted network runs as a confidential virtual machine (CVM) on Intel TDX, deployed with dstack on Phala Cloud.^[12][16] Inside the CVM, memory is encrypted by the CPU, so even someone with root on the host, physical access to the RAM, or control of the hypervisor cannot read the plaintext. The boot chain is measured: the firmware, the kernel, and the application’s digest-pinned Docker Compose configuration are hashed into hardware registers (MRTD and RTMR0–3) that appear in a hardware-signed attestation quote.^[16][17]

The enclave holds the root key and performs every sensitive operation: key derivation, authorization checks, and sandboxed Lit Action execution.^[12] HTTPS terminates inside the enclave. Its TLS private key is generated there and bound to the attestation quote, so a client can confirm that its connection ends in the attested software and not at a proxy in front of it.^[5][16]

3.2On-chain permissions

All authorization state lives in contracts on Base: an account record that registers the owner, a registry that maps API-key addresses to scopes, a registry of wallet (PKP) derivation identifiers, and groups that bind wallets to the action CIDs permitted to use them.^[12] Every privileged operation reduces to one check: the caller is the account owner, or holds an API key with the required scope for the group in question.^[10]

require(
  msg.sender == accountOwner ||
  isAPIKeyWithScope(msg.sender, requiredScope, groupId)
);

The enclave reads these contracts on every request. Owners update them either through the API, which relays the transaction, or by submitting transactions directly from an externally owned account (EOA) or a multisig.^[12]

3.3Lit Actions

A Lit Action is an immutable JavaScript program identified by its IPFS CID; the CID is both the action’s address and a commitment to its code. Developers submit source and the server derives the CID, so no IPFS upload is required, and publishing the source lets anyone check it against the CID.^[11][6] Inside the enclave an action can sign, encrypt and decrypt, make HTTP requests to APIs and blockchains, and return a value.^[11]

An action can reach two kinds of key. A PKP is a wallet the account mints and adds to a group. Any action whose CID is in the same group can use it, and it keeps its address as new versions of the code are approved. An action identity key is bound to the action’s own CID. Only that code can use it, and a new version of the code gets a new key.^[11] Because the code is immutable and the key stays in the TEE, a signed output is evidence that this exact code produced this exact result. The converse also holds: a permitted action can read and use a key inside the sandbox, so the code an owner permits is part of that key’s security boundary.

Actions run in a hardened Deno-based sandbox, a V8 isolate without Node.js built-ins such as the filesystem, in which native code cannot execute.^[5][18] They can import pinned ES modules from npm through jsDelivr. Each module is checked against a SHA-384 integrity hash before it runs, and redirects are refused.^[18] Default limits keep the shared runtime predictable: 15 minutes of execution, 64 MB of memory, 50 outbound HTTP requests, a 1 MB response, and 10 key or signature requests per execution.^[19]

3.4The life of a request

Authorization is checked twice: once against the chain before any code runs, and again inside the sandbox each time the code asks for a key or a decryption (Figure 1).^[10][11]

3.5Key release and the on-chain KMS

In most cloud key-management services, the provider decides which machines receive keys. Chipotle instead uses dstack’s on-chain KMS, which releases application keys only to CVMs whose attestation matches what smart contracts on Base allow.^[20][21]

On every boot, the CVM presents a TDX attestation quote. The KMS verifies the quote against Intel’s root certificates and then reads four whitelists on Base: the OS image and the KMS’s own measurement must be approved in Phala’s KMS contract, and the application’s compose hash and the hardware device must be approved in Lit’s DstackApp contract. Only if all four checks pass does the KMS release keys.^[20] A deployment that skips governance boots, but it cannot obtain keys, so it cannot serve traffic. The KMS that holds the root secret runs in a TEE of its own, and the CVM’s measurements record which KMS it is bound to, so a substituted KMS would fail verification.^[17]

The KMS derives application keys deterministically from its root secret, so a CVM that passes these checks obtains the same keys whichever approved machine it is scheduled on.^[22][23] Table 2 lists the contracts involved and who controls each.

3.6Accounts, keys, and groups

Who owns an account is a configuration choice, not a fork in the code. In API mode, a Lit-managed credential owns the account and relays administrative writes, which is the fastest way to start. In ChainSecured mode, a wallet the customer controls, either an EOA or a Safe, owns the account on-chain and signs every change itself, leaving an on-chain audit trail. Both modes execute Lit Actions through the same API; they differ in who owns the account and how administrative writes reach the chain.^[26][12]

API keys carry scopes granted by the owner. There are seven, and four of them — execute, manage a group’s actions, add wallets to a group, and remove wallets from a group — apply per group, so a key can be confined to exactly the groups it needs. Adding or revoking keys, changing scopes, and transferring ownership are reserved to the owner.^[27] A group answers the question “can this action use this key?”, and a key’s scopes answer “can this caller use this group?”^[27][28]

The result is least privilege enforced by the chain. A leaked execute-only key can invoke the actions it was already permitted to run, and nothing else: it cannot add itself to new groups, swap in new code, or move funds outside policy. Changing the rules takes an owner transaction, and with a Safe as owner, a multisig vote.^[10]

3.7Event-driven execution

Lit Triggers runs an action when something happens: an inbound webhook, a cron schedule, or an EVM log that matches a chain, contract, and event signature.^[29] A trigger turns a Lit Action into an autonomous, event-driven agent that can fetch data, sign, and transact with a key no human holds.^[29]

3.8Confidential AI workloads

The environment that authorizes and signs transactions also runs AI training, fine-tuning, and inference. Each deployment is hardware-attested against release hashes recorded on Base, and runtime keys are released only to deployments that match. Permitted data sources, outputs, and outbound requests are set at deployment and enforced during execution, rather than promised by an operator. AI deployments are onboarded with the Lit team, starting with a workload assessment.^[3]

4.1Defense in depth

The MPC network layered three defenses: threshold cryptography, TEEs, and cryptoeconomic security from staked, slashable operators.^[4] Chipotle replaces the threshold and staking layers with mechanisms that a third party can check directly. The layers below fail independently, so an attacker has to defeat several at once.

• 01Hardware isolation. Memory inside the TEE is encrypted by the CPU, and secrets generated there, such as the TLS private key, have no API through which they can be extracted.^[16]
• 02Remote attestation. A hardware-signed quote records the firmware, operating system, and application that booted. Anyone can recompute the expected values from public source.^[16][17]
• 03On-chain key release. The KMS releases keys only to software whose measurements are whitelisted in contracts on Base. No whitelist, no keys.^[20]
• 04Multisig release governance. Whitelisting a release takes a 2-of-4 Safe transaction, and deploying it is a separate step. Neither alone changes what runs.^[13]
• 05On-chain authorization. Permissions are contract state that only the account owner, or a key the owner has scoped, can change, and the enclave enforces them on every request.^[10][27]
• 06Supply-chain provenance. Images are pinned by digest and signed with Sigstore cosign in GitHub Actions, with signatures in the public Rekor transparency log. Imported modules are pinned by SHA-384.^[17][18]
• 07Zero-trust TLS. The TLS key is generated inside the enclave and bound to its attestation evidence, and CAA DNS records restrict certificate issuance to the enclave-controlled ACME account.^[17]

4.2Verifying the network

Attestation lets a remote machine prove what it is running, so the guarantee becomes “trust the silicon and the math” instead of “trust the operator.”^[16] Verification for Chipotle spans four layers (Table 3). A one-click report for the live API is published through the Phala Trust Center, and the full procedure — replaying the RTMR3 event log, checking image signatures, and reading the on-chain whitelists — is documented step by step.^[30][31]

Production verification belongs in the integrating client. The documentation and Phala’s chain-of-trust checklist describe the checks, but each application has to run and enforce them on its own connection path, including any proxies in front of the enclave.^[16]

4.3Release governance

Attestation proves what an enclave runs; release governance decides what it is allowed to run. Because the KMS releases keys only to whitelisted compose hashes, shipping a new version takes two independent actions: a governance transaction that adds the release’s compose hash to the DstackApp whitelist, and a deployment that builds the image and restarts the CVM. A deployment without the whitelist entry boots but cannot get keys. A whitelist entry without a deployment changes nothing.^[13]

Before approving, each signer confirms provenance (the image was built by GitHub Actions from a reviewed commit on LIT-Protocol/chipotle, as recorded in Rekor), reproducibility (the compose hash recomputes locally from the digest-pinned configuration), and the diff against the currently whitelisted release.^[13] Rolling back means redeploying a release that is still whitelisted. Forbidding a vulnerable release takes another 2-of-4 transaction that removes its hash. There is currently no timelock on top of the multisig, so an approved change takes effect as soon as the quorum executes it.

4.4Trust assumptions and limits

No system eliminates trust. Chipotle moves it to assumptions that can be stated and checked, listed in Table 4.

Chipotle prices usage in US dollars through prepaid credits, with no subscriptions, no per-seat fees, and no charge for read-only operations. Credits are drawn down as metered calls run. When a balance is exhausted, the API returns 402 Payment Required until the account is topped up.^[8]

Credits can be bought by card through Stripe, with ETH, USDC, SOL, and other tokens through Stripe’s crypto integration, or with LITKEY directly on Base at a 25% discount to the card price. Enterprise terms are available for higher volumes.^[8] Billing also follows the account mode. In ChainSecured mode, administrative writes are signed by the owner’s wallet and paid for in Base gas, so they never reach the metered endpoint, while Lit Action execution is metered the same way in both modes.^[8]

In the MPC network’s design, signing, encryption, and compute were paid for in LITKEY.^[4] Chipotle prices usage in dollars, and LITKEY remains the native payment token for Lit services.^[9]

5.1How LITKEY payments settle

LITKEY payments go through LitkeyPaymentGateway, a deliberately minimal contract on Base. It holds no state and no funds, and it is intentionally immutable: changing its behavior means deploying a new contract.^[25] Settlement takes three steps (Figure 3).

The payer and the credited account are separate fields, so a user can pay from any wallet. Every payment, and the treasury that receives it, is visible on Basescan.

LITKEY is the network token of Lit Protocol. It launched on Aerodrome on Base on October 30, 2025, with a fixed supply of one billion tokens.^[34][35]

In the MPC network, LITKEY had three jobs: a work token that node operators staked and could lose to slashing, a payment and gas token for the Lit Chain and its services, and a governance token.^[4] Chipotle’s architecture changes the first two.

• Payment. LITKEY is the native payment token for Lit services. Paying in LITKEY buys credits at a 25% discount to card pricing, settled on Base with no card or fiat conversion.^[9]
• No staked operator set. Chipotle does not coordinate a threshold of independent nodes, so it has no operator staking, slashing, or node rewards. Attestation-gated key release and public release governance (§4.3) take the place of the security that staking provided. When Naga was sunset, timelocks were removed so delegated stakers could withdraw, and node operators could unstake.^[5][7]
• All on Base. With the Lit Chain shut down, LITKEY no longer serves as a gas token. Chipotle’s contracts and LITKEY payments are on Base, and on-chain writes pay Base gas in ETH.^[12][8]
• Governance. The Lit Association stewards protocol governance in collaboration with the core development company, node operators, integration partners, and token holders. Anyone can take part through the public governance forum and the Lit Improvement Proposal (LIP) process (§7).^[36]

Authority over Chipotle is split into separate domains with separate rules, and verifying a deployment means checking how each one can change.^[32] There are three.

• Account governance: your rules. The account owner decides which keys, wallets, and actions exist and how they combine. In ChainSecured mode the owner is the customer’s own EOA or Safe, and every change is an on-chain transaction it signs.^[10][26]
• Release governance: which software may hold keys. Lit’s 2-of-4 Safe approves Chipotle releases through the DstackApp whitelist, using the propose, approve, and execute workflow in §4.3. Phala’s 2-of-3 Safe governs the OS-image and KMS whitelists.^[13][20]
• Protocol governance: policy and direction. The Lit Association, a Swiss non-profit association, stewards protocol upgrades, policy, and resource allocation. As set out at its launch in October 2025, proposed upgrades are posted in the public governance forum for review and, in the initial phase, ratified by the Association through a multisig. Governance is being rolled out in phases, and changes to governance itself are proposed through the LIP process.^[36]

Self-hosting moves release governance to the operator. A self-hosted deployment has its own DstackApp contract, owned by its own Safe, wallet, timelock, or DAO, so a new Lit release takes effect there only when that owner whitelists it — on its own timeline, and with whatever quorum or review delay its compliance posture requires.^[15][13]

Chipotle is open source. The API server, Lit Actions runtime, dashboard, contracts, examples, and local development tooling are public in the LIT-Protocol/chipotle repository.^[37][15] It runs anywhere dstack runs. Because dstack is native to Docker Compose, the images and compose files the hosted service uses deploy unchanged on bare-metal Intel TDX, bare-metal AMD SEV-SNP, Phala Cloud, GCP Confidential VMs, and AWS Nitro Enclaves, and dstack also supports NVIDIA confidential-computing GPUs.^[15][38]

The hosted service is the fastest path for most teams, because Lit operates the TEE infrastructure, deployment pipeline, monitoring, billing integration, and upgrades. Self-hosting suits teams that need infrastructure ownership, private deployment controls, custom compliance boundaries, or a deployment their users can verify independently. The operator then owns upgrades, monitoring, incident response, and the verification evidence it publishes to its users.^[15]

The initial Chipotle release delivered Lit Actions, signing and decryption gating, the REST API and dashboard, Phala TEE execution, on-chain KMS integration, and LITKEY payments.^[5] Since launch, the network has added module imports for Lit Actions, event-driven execution through Lit Triggers, and confidential AI deployments.^[18][29][3]

Announced areas of future work are additional programmable-cryptography primitives, multi-region scaling, expanded payment options, and more advanced policy frameworks.^[5] These are forward-looking: scope and timing may change, and this paper will be revised as they ship.

1. [1]Lit Protocol developer documentation — overview: one programmable runtime that reads data from any source, runs JavaScript inside a chain-secured TEE, and signs on any chain or API. link
2. [2]Lit Protocol, “Lit V3 Is Live: Confidential Compute and Key Management in One API” (Apr. 1, 2026). link
3. [3]Lit Protocol, “Lit Protocol now supports confidential, verifiable AI deployments” (Sept. 16, 2026) — training, fine-tuning, and inference in the Chipotle runtime; states that the network secures over $50B in transactions. link
4. [4]Lit Protocol, “$LITKEY Whitepaper” — the threshold-MPC network: distributed key generation and threshold signing across TEE nodes, the Lit Chain (an Arbitrum Orbit rollup), staking and slashing, and the original token design. link
5. [5]Lit Protocol, “Introducing Lit Protocol v3 — Chipotle” (Feb. 26, 2026) — execution decoupled from the KMS, on-chain key orchestration, the move from threshold cryptography to verifiable TEE execution, and the initial roadmap. link
6. [6]Lit Protocol, “Lit Protocol Launches Chipotle: Programmable Key Management and Verifiable Compute in a Single API Call” (Mar. 31, 2026). link
7. [7]Lit Protocol, “Naga Network Sunset & Lit v3 Transition” (Mar. 5, 2026) — the network stops on Mar. 25 and Naga fully sunsets on Apr. 1, 2026; timelocks removed for delegated stakers. link
8. [8]Lit developer documentation — Pricing: credit-based billing, metered operations, credit packages, payment rails, and billing in ChainSecured mode. link
9. [9]Lit developer documentation — LITKEY: buying credits on Base at a 25% discount, the canonical Base token address, and bridging via Hyperlane Nexus. link
10. [10]Lit developer documentation — Chain Secured: a key’s authority is on-chain state on Base, enforced by an attested TEE that reads the chain. link
11. [11]Lit developer documentation — Lit Actions overview: immutable programs identified by CID, PKP and action identity keys, and in-sandbox permission checks. link
12. [12]Lit developer documentation — Architecture overview: the TEE enclave, on-chain permissions on Base, and Lit Actions; API mode and ChainSecured mode. link
13. [13]Lit developer documentation — Upgrade Governance: two independent actions per release, the 2-of-4 Safe, what signers verify, rollback, and self-hosted governance. link
14. [14]Lit developer documentation — Security & Verification: zero-trust TLS, attestation verification, and the chain of trust. link
15. [15]Lit developer documentation — Self-Hosting: open-source repositories, supported dstack platforms, tradeoffs, and governing upgrades yourself. link
16. [16]Lit developer documentation — What Is Attestation?: Intel TDX, measured-boot registers, attestation quotes, and the checks a client performs. link
17. [17]Lit developer documentation — Chain of Trust Reference: application, platform, network, and governance checks. link
18. [18]Lit developer documentation — Module Imports: pinned jsDelivr ES modules verified by SHA-384 before execution inside the Deno/V8 sandbox. link
19. [19]Lit developer documentation — Limits: default payload, execution-time, memory, network, and key-request limits for Lit Actions. link
20. [20]Lit developer documentation — On-Chain KMS: the DstackApp and Phala KMS contracts on Base, the four key-release checks, and how to confirm each with cast. link
21. [21]Phala Network documentation — Understanding On-Chain KMS. link
22. [22]LIT-Protocol/chipotle — “Key Issuance from DeRoT (Onchain KMS)”: the boot-time key-issuance sequence and deterministic key derivation. link
23. [23]Phala Network documentation — dstack design: Decentralized Root of Trust; applications obtain the same derived keys regardless of the TEE hardware they run on. link
24. [24]EIP-2535, “Diamonds, Multi-Facet Proxy” — the upgradeable contract pattern used by the Chipotle permissions contract. link
25. [25]LIT-Protocol/chipotle — LitkeyPaymentGateway.sol: an immutable, stateless contract that forwards LITKEY to the treasury and emits a Payment event. link
26. [26]Lit developer documentation — API Mode vs ChainSecured Mode: account ownership models and migration between them. link
27. [27]Lit developer documentation — Authentication Model: entities, the seven API-key scopes, and the permission matrix. link
28. [28]Lit developer documentation — Groups: binding wallets, permitted action CIDs, and usage keys. link
29. [29]Lit developer documentation — Lit Triggers: running actions on webhooks, schedules, and EVM chain events. link
30. [30]Lit developer documentation — Verify in 30 Seconds: the Phala Trust Center report for the live API. link
31. [31]Lit developer documentation — Full Verification Guide: replaying the RTMR3 event log and checking every layer. link
32. [32]Lit Protocol, “Security & verification” — software identity, wallet authority, runtime governance, and the limits of attestation. link
33. [33]LIT-Protocol/chipotle — lit-payments: the LITKEY quote, payment page, and receipt-verified, idempotent crediting. link
34. [34]Lit Protocol, “$LITKEY Tokenomics” (Oct. 23, 2025) — token parameters at launch. link
35. [35]Lit Protocol, “$LITKEY is Live” (Oct. 30, 2025) — launch on Aerodrome on Base, airdrop claiming and staking, and the staking contest to select the genesis validator set. link
36. [36]Lit Protocol, “Introducing the Lit Association and Onchain Governance” (Oct. 21, 2025) — the Lit Association, a Swiss non-profit association; the governance domains; and the Lit Improvement Proposal (LIP) process. link
37. [37]LIT-Protocol/chipotle — source for the API server, Lit Actions runtime, dashboard, contracts, examples, and local development tooling. link
38. [38]Dstack-TEE/dstack — the open-source TEE stack Chipotle deploys on, and its supported platforms. link

This whitepaper is a technical description of Lit Protocol V3 (Chipotle) as of October 2026. It is not the LITKEY crypto-asset white paper prepared under the EU Markets in Crypto-Assets Regulation (MiCA), which is published separately. On-chain parameters such as owners, thresholds, and whitelists were read from Base in October 2026 and can change through the governance processes described here; verify them on-chain. Some functions described for the network and for LITKEY are forward-looking and may change, be delayed, or never be released. LITKEY is intended to provide access to and coordination within the network; it does not represent equity, ownership, or a right to revenue, assets, dividends, or profits. Nothing here is an offer or solicitation to buy or sell any token or other instrument, or investment, legal, or tax advice.