Lit Protocol is a key management and compute network that lets developers sign transactions, encrypt data and run code under rules they set onchain. Its current docs describe it as "a programmable runtime" that runs JavaScript inside a chain-secured trusted execution environment (TEE) and signs on any chain or API, with keys that never leave the enclave, per the Lit developer docs. Its token post calls it "a decentralized and programmable key management network," per the LITKEY announcement.
​

This page covers how Lit holds keys, what Programmable Key Pairs (PKPs) and Lit Actions are, what the LITKEY token does, common use cases, and how Lit differs from MPC wallets and TEE-only wallets. All sources were fetched October 21, 2026.
​

Lit stores the authority over each key as smart contract state on Base, and an attested TEE enforces that authority by reading the contracts on every request. The enclave derives the key, runs only approved code, and signs. Lit's earlier Naga network used threshold signing across a set of node operators instead.
​

Lit's current runtime, called Chipotle, has three layers, per its architecture overview. A TEE enclave built on Phala and dstack holds the root key and performs key derivation, authorization checks and sandboxed code execution. Contracts on Base hold all permission state: an Account contract, an API Key Registry, a PKP Registry and Groups. Lit Actions, the code that may use the keys, live on IPFS.
​

Lit calls this model Chain Secured. When a request arrives, the TEE checks onchain whether the API key has execute scope on a group that lists both the requested action and the requested PKP. If so, it derives the key inside the enclave, runs the action and signs; if not, it refuses, per the Chain Secured docs. Changing a rule is an onchain transaction, while using a rule is only a read, so signing needs no per-operation transaction or gas, per the same page.
​

Accounts come in two modes. In API mode, a Lit-managed credential owns the account and relays admin writes. In ChainSecured mode, a wallet the developer controls, such as an EOA or a Safe multisig, owns the account and signs every change, per the architecture overview.
​

The threshold model belongs to Lit's earlier network. The 2025 LITKEY post describes Naga features such as EdDSA PKPs "enabling native threshold signing support for Solana, Sui, Penumbra," and Realms, in which distinct sets of Lit nodes manage the same root key. Lit's comparison page now refers to this as "Lit's legacy MPC network."
​

A Programmable Key Pair is a wallet key minted and managed inside Lit, whose use is governed by a group of permitted code. A PKP keeps its address when the code changes: a team ships a new action version, adds its content ID to the group, and the same wallet keeps working.
​

Each action can reach two kinds of key, per the Lit Actions overview. A PKP key is bound to a wallet in a group and can be used by any action whose content ID is in that group. An action identity key is bound to the action's own code, so a new version of the code gets a new key. Lit's docs suggest PKPs for long-lived accounts such as treasuries, user wallets and shared vaults, and identity keys for anything that only one piece of code should operate.
​

Lit Actions are immutable JavaScript programs, addressed by IPFS content ID, that run inside Lit's TEE. They can sign with a PKP or their own key, encrypt and decrypt data, call HTTP APIs and blockchains, and return a value. Because the code cannot change, a signed output shows which code produced it.
​

The content ID works as both the action's address and a commitment to its code, so changing one byte makes a different action, per the Lit Actions overview. When an action fetches outside data, such as a price or another chain's state, and signs the result, a smart contract can verify that signature with ecrecover. That lets a contract act on data it could not fetch itself. The same page caps key operations at ten per execution and outbound fetch calls at fifty.
​

LITKEY is Lit Protocol's native token, with a total supply of one billion. Lit describes three roles: node operators stake it to take part in the network and earn rewards, users pay it for signing, encryption and compute, and holders use it in onchain governance, including selecting network operators.
​

Per the LITKEY announcement, the token launched before Lit's v1 mainnet, Naga, because it was required to select node operators. LITKEY is also needed for onchain transactions such as generating key pairs or staking. Investor and team allocations vest linearly over four years with a one-year lock after the token generation event, per the same post. Lit's current developer docs describe credit-based billing for the Chipotle runtime, per the docs home.
​

Teams use Lit for programmable wallets for AI agents and apps, signing that only happens when set conditions hold, cross-chain actions that read one chain and sign on another, custom oracles, and encrypting secrets so that only approved code can decrypt them.

An MPC wallet splits signing across parties so no one holds the full key. Lit's current runtime instead derives keys inside an attested TEE and makes the signing rules onchain contract state. A TEE-only wallet also signs in hardware, but its policy usually sits with the operator rather than onchain.
​

In a multi-party computation wallet, key shares are held by separate parties who jointly produce a signature. Lit's legacy Naga network worked in a similar threshold style across node operators, per the LITKEY post. Chipotle moved the root key into a TEE and the authority into Base contracts.

Lit's own comparison page frames the difference around release authority: its key management system checks attested measurements against contract rules before releasing runtime keys, so "an operator cannot authorize new code simply by deploying it." Lit publishes those comparisons itself and calls them architectural assessments, not security audits.
​

Lit's model still depends on TEE hardware, correct software, chain state on Base and Lit's own key infrastructure. Its account contracts can be upgraded, API mode places a Lit-managed credential in the owner role, and the network has changed architecture, so older guides may describe a system that no longer runs.
​

Lit's comparison page states that all deployments keep dependencies on software correctness, hardware trust roots and availability, and that Lit also depends on chain state and key infrastructure. It adds that Chipotle's account contracts support upgrades, so a review should cover both the permission checks and how those checks can change. Teams moving from Naga need Lit's migration guidance, since some Naga actions are deprecated. Per-execution limits on key operations and fetch calls also cap how much one action can do.
​

Every claim about Lit comes from Lit's own website, developer docs and blog, fetched October 21, 2026 with Firecrawl. The LITKEY post dates from 2025 and describes the Naga network; current architecture details come from the Chipotle developer docs. No price or market data is included.