Skip to main content
Lit’s core guarantee is simple to state: a key’s authority is on-chain state. What a key may sign, which code is allowed to use it, and who can change those rules all live in smart contracts on Base. Nothing off-chain — no server, no API key, no operator, not even Lit — can make a key sign outside the rules currently on the chain. We call this Chain Secured.

​
Video overview

This video explains how Chain Secured works in about four and a half minutes. It covers who can change your wallet’s rules and how the runtime checks them on every request.
A programmable wallet has two parts. There’s a private key, and there are rules that decide when the key can sign. Most of the work in this space goes into protecting the key. Providers keep it in secure hardware, or they split it into shares so that no single party holds all of it. Protecting the key is important. But the rules decide what the key signs, so whoever can change the rules has real control over the wallet.That’s why I think the most useful question to ask about a wallet system is who can change the rules. It breaks down into four smaller questions. Who can change the permissions? Who can approve the software that enforces them? Who can stop access? And who can restore access if something goes wrong? Let’s see how a typical hosted wallet answers these, and then how Lit’s Chain Secured mode answers them.In a typical hosted wallet service, the key is well protected, often in secure hardware. The rules live inside the provider’s system. You read them and change them through the provider’s API. The provider’s own operators decide which software is trusted to enforce those rules. Good providers run that process carefully, and some let you verify which software is running. But the approval still happens inside the provider, and you can only see the rules through its API. Splitting a key into shares doesn’t remove this question either. You still need to know who administers the policies and roles around the shares.Chain Secured mode puts the rules on a blockchain. Your account’s permissions are stored in smart contracts on Base, and a wallet you control owns the account. That can be a regular wallet or a multisig. Inside the account you create groups. A group lists some keys and the Lit Actions that are allowed to use them. Each Action is listed by the hash of its code, its IPFS CID. To change a group, the owner wallet sends a transaction on Base. API keys only get the scopes you grant them on-chain. An execute key can run your Actions, but it can’t add itself to a group or swap in new code.Here’s what happens on every request. The runtime receives the Action’s code and an API key. It hashes the code to get the CID. Then it reads Base and checks one thing. Does this API key have permission to execute in a group that contains both this CID and this key? If yes, the Action runs and can sign. If not, nothing gets signed. The runtime reads the current state on Base, so a change you make applies as soon as the transaction is on-chain.The rules also depend on the software that enforces them, so that software is under on-chain control too. The runtime runs in confidential hardware. Its code hash has to be approved in a contract on Base before the key management service will give it any keys. Deploying new code isn’t enough to reach the keys. Each approval is a public transaction, so anyone can see which releases were approved and when.This changes what you can check. You don’t need the provider’s API to read the rules. Anyone can read an account’s groups straight from Base, along with every change to them and the wallet that made it. And because each Action is identified by its hash and can’t be edited, you know exactly which code is allowed to sign. To change the logic, you approve a new version, and the key keeps its address.This is useful for agent wallets. An agent can only sign through code you’ve approved, and its limits are written into that code. It’s also useful for treasuries. If a multisig owns the account, every rule change needs approval from several signers, and each change is recorded on-chain.There are limits to keep in mind. The runtime operator can still pause signing. Your permissions stay on-chain, but signing needs the runtime and the key service, so you still need a recovery plan. The account contracts can also be upgraded under their own approval rules, so review those as well. Within those limits, here’s the difference. The rules that control your keys live on a public chain, and changing them takes a transaction from your wallet. The docs show how to set up a Chain Secured account. They’re at developer.litprotocol.com.

​
The chain holds the authority

Authorization isn’t a flag in someone’s database. It’s on-chain state that you own:
  • Account — an address on Base that owns everything: a wallet you control (an EOA or Safe) in ChainSecured mode, or a Lit-managed credential in API mode. See API mode vs ChainSecured mode.
  • API keys & scopes — each key is registered on-chain with explicit, per-group scopes (execute, group:addPkp, and so on).
  • PKPs & Groups — a Group is the authorization policy: it binds the keys (PKPs) to the immutable Lit Actions (IPFS CIDs) allowed to use them.
The contract is the authority. Every privileged operation comes down to one check:
Changing a rule is an on-chain transaction — public, auditable, and authorized by an owner you control. Put a Safe in the owner slot and it takes a multisig vote. See the Authentication Model for the full permission matrix.

​
An attested TEE enforces it — by reading

On-chain rules are only as strong as what enforces them. In Lit, that’s a sealed TEE that reads the contracts on every request:
  1. A request arrives: an API key, and “run action QmABC with pkp_001.”
  2. The TEE reads on-chain — does this key have execute scope on a group where both QmABC and pkp_001 are listed?
  3. If yes, it derives the key inside the enclave, runs the action, and signs. If no, it refuses.
This is the same path every request takes: Every request takes this path. A group answers “Can this action use this PKP?” A usage key’s scopes answer “Can this caller use this group?” A wildcard key (execute_in_groups: [0]) passes the first check for any code, but it still needs a group to use a PKP. The Overview follows one request through these checks step by step. Key material never leaves the enclave, and the enclave can only run code that on-chain governance has whitelisted — so the read is trustworthy, not just convenient. You can verify the exact enclave yourself: see Security & Verification and On-Chain KMS.

​
Why it scales: write the rules, read to enforce

The split between authority and enforcement is the point:
  • Setting or changing a rule is a write — one on-chain transaction, only when you configure or govern.
  • Using a rule is a read — the TEE reads current on-chain state and signs in the enclave. No per-operation transaction, no gas, no waiting on a block.
So you get the chain’s guarantees — public, owner-controlled, auditable authority — without paying the chain’s throughput cost on every signature. Use smart-contract rails where they create trust, and reads where you need speed. The result is authority on-chain, signing at the speed of an API call.

​
What Chain Secured locks down

Because authority lives on-chain and the TEE only ever enforces it:
  • A leaked execute-only key can invoke the actions it is already permitted to, and nothing else. It cannot add itself to new groups, swap in new code, or move funds outside policy.
  • Changing what the rules are requires an owner transaction on Base. Put the owner behind a Safe, and an evil admin holding an execute key can invoke existing actions but cannot change the rules.
  • The rules are visible to anyone, at any time, so you can read them on Base and check them yourself.

​
Limits

Chain Secured covers who can change the rules. Keep these limits in mind as well:
  • The operator can pause signing. Your rules stay on-chain while signing is paused, but signing needs the runtime and the key service, so plan for recovery.
  • The contracts can be upgraded. The Lit Safe that approves new releases (2 of 4 signers) also owns the AccountConfig contract, and an upgrade to that contract can change how rules are enforced. There is no timelock: an upgrade takes effect as soon as the Safe executes it. See Upgrade Governance for the Safe’s settings and how to check them.
  • Attestation shows which code is running. It doesn’t prove that the code is free of bugs, and it relies on Intel’s hardware being secure. See What Is Attestation?.

​
Further reading