Skip to main content
Lit is a programmable runtime that reads data from any source, runs your JavaScript inside a chain-secured TEE, and signs on any chain or API. Keys never leave the enclave, and the code that’s allowed to use them is governed on-chain. You get the speed and expressiveness of a single trusted runtime, with the auditability of a smart contract. This version of Lit is Lit Protocol v3, also called Chipotle. You’ll see the name in the API and Dashboard addresses, such as api.chipotle.litprotocol.com.

Start here: Quick Start

Create an account, fund it, and run your first Lit Action in a few minutes — via the Dashboard or the REST API.
If you want to run code first, take the Quick Start and then read the Lit Actions overview. If you want to understand the trust model first, read Chain Secured and then What Is Attestation?. If you’re setting up an account for a team, read Account Modes and then API Keys. The Glossary defines each term in one place.

​
Build

The fastest paths to a running integration.

Dashboard

Web GUI for accounts, API keys, wallets (PKPs), IPFS actions, and groups.

REST API

Drive the same workflows from cURL, the lightweight JS SDK, or your own client built from the OpenAPI spec.

Lit Actions

JavaScript that runs inside the network’s TEE. One file can read data, decide what to do, and sign the result.

Lit Agent Keychain

Owner-approved, locally encrypted credentials for AI agents. Approve an agent’s public key, and Lit’s enclaves check your signature on every request. SDK, CLI and MCP server included.

​
Use cases

Patterns you can build on one programmable runtime.

Cross-chain actions

Read state on one chain, sign on another — bridges, mirrors, and replays without a multisig in the middle.

Custom oracles

Aggregate any HTTP or RPC feed inside the TEE, sign the result with a PKP, deliver it anywhere a signature is trusted.

Conditional signing

Sign only when on- or off-chain conditions hold — sanctions screens, price thresholds, KYC checks, dispute windows.

Encrypted secrets

Encrypt API keys, credentials, or user data under a PKP or to a single immutable action — decryptable only by code you’ve authorized.

​
Design patterns

The two structural patterns production apps on Chipotle are built from. Both work with no PKP and no trusted backend.

Derived Actions

One audited template plus a stamped-in constant yields a new immutable action, with its own TEE-held key, per user, secret, or tenant.

Signed Data in Untrusted Storage

Have an action sign the records you store and verify them at runtime. Your database can still fail or roll back. It can’t forge a permission, because the action only accepts records it signed.

​
Concepts

How the runtime works and how trust is established.

Chain Secured

Your keys’ authority lives on-chain; an attested TEE enforces it by reading the chain.

Architecture

The three layers: chain-secured TEE, on-chain permissions, and actions addressed by IPFS CID.

Auth Model

How API keys, scopes, and account ownership combine to authorize requests.

Groups

Bind Programmable Key Pairs to permitted action CIDs. Usage keys reach a group through their scopes.

Verification

Attest that the enclave is running the code it claims to be running.

​
Operate

Account ownership, billing, and key management.

Account Modes

API mode vs. ChainSecured mode — picking an ownership model and migrating between them. Both modes keep the rules on-chain; they differ in who owns the account.

API Keys

Account keys vs. usage keys, and how to scope them.

Pricing

Credit-based billing, how requests are metered, and how to add funds.

Self-Hosting

Open-source repos, deployment ownership, and the tradeoffs of operating your own Lit stack.

​
Reference

Lit Actions SDK

Functions available inside an action: signing, encryption, HTTP, response.

OpenAPI / Swagger

Full REST API schema — generate clients in any language.

Glossary

One definition for each term: account key, usage key, PKP, group, CID, TEE, compose hash.