> ## Documentation Index
> Fetch the complete documentation index at: https://developer.litprotocol.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> How Lit Chipotle's three composable layers — TEE enclave, on-chain permissions, and IPFS — work together to provide programmable key management.

Lit Chipotle is built on three composable layers that each handle a distinct concern. Understanding the separation makes it easier to reason about security, auditability, and where your own code fits in.

The throughline: **your keys' authority lives on-chain, and an attested TEE enforces it by reading the chain.** We call this [Chain Secured](/architecture/chain-secured) — on-chain authority, signing at the speed of an API call.

## The Three Layers

**TEE Enclave (Phala / dstack)**
The enclave holds the root key and performs all sensitive operations: key derivation, authorization checking, and sandboxed Lit Action execution. Nothing that touches key material ever leaves the enclave. The TEE also acts as a convenience relay — it can sign and submit on-chain management transactions on your behalf after verifying your API key scopes.

**On-Chain Permissions (Base)**
All authorization state lives on-chain in a set of smart contracts: an Account contract that registers the owner address, an API Key Registry mapping key addresses to scopes, a PKP Registry of wallet derivation path IDs, and Groups that bind PKPs to permitted action CIDs. The TEE reads these contracts to decide whether to execute a request. You can update them either through the TEE relay or by submitting transactions directly from an EOA or multisig.

**Lit Actions (IPFS)**
Lit Actions are immutable JavaScript programs stored on IPFS and referenced by content ID (CID). They are not owned by anyone — they are public, reusable, and content-addressed, similar to npm packages. The TEE fetches the action by CID at execution time and runs it inside a sandboxed JS environment that has access to the derived key material.

## API mode vs ChainSecured mode

Who owns the account is a configuration choice, not a fork in the code. In **API mode**, a Lit-managed credential owns the account and relays your admin writes — the fastest way to start. In **ChainSecured mode**, a wallet you control (an EOA or Safe) owns the account on-chain and signs every change itself — fully self-custodied, with an on-chain audit trail. Both run the same contracts and the same Lit Actions; only account ownership and how writes are signed differ.

See [API Mode vs ChainSecured Mode](/management/account_modes) for the side-by-side and the migration path.

## Further Reading

* [Chain Secured](/architecture/chain-secured) — why your keys' authority lives on-chain, and how an attested TEE enforces it by reading
* [Verify the TEE in 30 seconds](/architecture/verification/quick-verify) — one-click Phala Trust Center report for the live API
* [Auth Model & Permission Matrix](/architecture/authModel) — detailed entity boundaries, execution flow, and the full permission matrix
* [System Diagram](/architecture/diagram) — entity relationships, on-chain vs TEE boundaries, and management paths
* [Security & Verification](/architecture/verification/index) — Zero-Trust TLS, attestation verification, and the full chain of trust
* [On-Chain KMS](/architecture/verification/onchain-kms) — how Base smart contracts gate key release