Skip to main content

Lit Protocol

Lit Protocol — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Lit Protocol — an Infra / Cryptography project (Lit Chain + a network of Lit Nodes), token (symbol: LITKEY).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a decentralized key/secret management network for signing and encryption (threshold cryptography), plus “serverless” JS functions (Lit Actions) for access rules and automations.
  • Who it’s for: application developers who need programmable signatures/decryption/access policies without storing a single private key on a server.
  • Why onchain/token: onchain is needed for accounting/coordination and payment for network services; the LITKEY token is used as Lit Chain gas, as payment for network operations, and also for operator staking and governance.

How it works (very briefly)

  1. The user does: the application calls Lit for signing/decryption or to run a Lit Action.
  2. The system does: Lit Nodes running in TEEs perform the operation via MPC/TSS: each node uses its own key share.
  3. The user gets: the result (signature/decryption/Lit Action execution) without revealing the private key to a single node/client.
  4. Where the blockchain is: Lit Chain stores states/contracts (including the ledger for prepayment and the network parameters).
  5. Token role: LITKEY — Lit Chain gas, payment for network services, operator staking/delegation and governance.

Quick links: AI thesis fit

Project passport

Field Value
Project name Lit Protocol
Also known as (aliases) Lit, Lit Network, Lit Nodes, Lit Actions, LITKEY
Logo (logo) ../assets/189_lit-protocol_logo.webp
Token symbol (ticker) LITKEY
Category Infra | Cryptography
Primary chain (chain) Lit Chain
Type EVM
Network status —
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x4D4eb0E8B160f6EbF63cC6d36060ffec09301B42 (Ethereum, master)
Token model (token_type) utility (work + payment + governance)
Max supply 1,000,000,000 LITKEY (fixed token supply; per the docs)
Issuance —
Tokenomics (tokenomics, brief) LITKEY is used as a work+payment+governance token; payment for services via the ledger contract on Lit Chain
Governance onchain governance + Lit Protocol Council at the start of v1 (per the docs)
Admins/keys —
Audit yes (there is a folder with audits; per the docs)
Bug bounty yes (per the docs)
Team (team) —
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) threshold signing, encryption/decryption, access control, automations
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 2 / 3 / 2
Last verified 2026-02-11

General project overview

Lit Protocol describes itself as a “decentralized programmable key management network” for signing and encryption. The key idea is that keys and secrets are managed in a distributed way: each node holds a key share, and signing/decryption operations are performed in a threshold manner with the participation of more than (2/3) of the network (per the documentation).

On top of the cryptographic operations, Lit offers Lit Actions — immutable JS functions that define key usage policies (access rules, spending policies, transaction automations, etc.) and are executed in a JS environment inside the nodes.

Features/modules

  • Threshold signing & encryption/decryption (MPC/TSS + DKG).
  • Lit Actions: “serverless” functions for access rules/data orchestration and automation.
  • TEEs: hardware isolation of computation and key share storage.
  • Lit Chain: the onchain layer for coordination, accounting and payment (ledger contract, gas, governance operations).

Typical scenarios

  • Scenario 1 (access to encrypted data): the application encrypts data and sets access conditions; users receive decryption only when the conditions are met.
  • Scenario 2 (signing automation): a Lit Action checks conditions (onchain/offchain) and authorizes the signing of a transaction or message.
  • Scenario 3 (spending policies): a Lit Action implements spending policies and controls when and what to sign.

Getting started (wallet/network)

  • What you need: an EVM wallet for interacting with Lit Chain and the LITKEY token; the project’s SDK.
  • Network/chain: Lit Chain (described in the documentation as an Arbitrum Orbit‑based L3) + bridges for LITKEY (Ethereum/Base/Arbitrum/Optimism, etc.).
  • Fees: Lit Chain gas and payment for network services in LITKEY via the prepaid ledger.

Architecture/tech (non‑AI)

  • Components: Lit Nodes (TEE + key shares + JS runtime), DKG, MPC/TSS, Lit Chain (ledger/price feed/governance), SDK/Payment Manager.
  • Participant roles: node operators (stake), developers/users (pay for operations), governance participants.
  • Where logic runs: cryptographic operations and Lit Actions — on the nodes in TEEs; accounting/payment/parameters — onchain on Lit Chain.
  • Dependencies: TEE technologies + threshold signing/encryption schemes.

Token/economics (expanded, no forecasts)

  • Token utility: LITKEY — a work token (operator stake), a payment token (payment for network operations), a governance token (governance).
  • Protocol necessity drivers: the docs describe that operators must stake LITKEY to participate in the network; users pay for network operations in LITKEY.
  • Who pays fees: users/applications consuming signatures/decryption/Lit Actions; separately — Lit Chain gas.
  • Where fees go: to pay for services and compensate operators; the distribution details are set out in the token paper (link in the docs).
  • Issuance/burn: a fixed token supply of 1B is described in the docs; distribution/vesting — in the Initial Allocation and Distribution section.

Governance

  • Who makes decisions: LITKEY holders + Lit Protocol Council at the start of v1 (per the docs).
  • How protocol parameters change: via the governance architecture (see the docs).

Security and incidents

  • Audits: the documentation provides a link to a folder with audit reports.
  • Bug bounty: a bug bounty program is claimed (per the docs).
  • Incidents: no public Tier‑1 postmortems/incidents were identified.
  • Threat model: the docs describe a combination of MPC/TSS and TEE to avoid a single point of failure and key share extraction.

Project status and timeline

  • Current status: the documentation and SDK are maintained; the economic model of payment and governance is described.
  • Key releases/milestones: see the changelog and GitHub.
  • Roadmap: see the link to the “cryptography roadmap”.

Ecosystem/integrations

  • Where it’s actually used: the use cases are oriented toward applications that need signing/decryption/access policies; specific integrations are not listed in this card.

AI component of the project

  • What is real AI here? Per Tier‑1 sources, this is cryptography/key management/automations; an AI model/inference is not claimed as a product component.
  • What is truly onchain? Lit Chain (the ledger for prepayment, gas, governance/coordination operations) + the token contract addresses.
  • Why is a token needed? LITKEY — payment for network services, operator staking, governance and Lit Chain gas.
  • Red flags (based on the information found): AI‑washing — high (the project is not about AI); what to double‑check: the max supply/issuance parameters from the token paper and/or onchain.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity medium 2
Token necessity high 3
Evidence Tier‑1 partially present 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): no intent/roadmap for AI as a separate module was found.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/how-it-works
  • Why sufficient / why not (one line): the documents describe cryptographic services, not an AI component.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): AI features are not described.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/how-it-works
  • Why sufficient / why not (one line): Lit Actions and threshold cryptography are not AI.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a demo of an AI component is absent.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/how-it-works
  • Why sufficient / why not (one line): the examples relate to cryptographic operations/access policies.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/how-it-works
  • Why sufficient / why not (one line): AI metrics are not applicable.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): there is a technical description, but it is not about an AI model/inference.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/security
  • Why sufficient / why not (one line): the security model describes MPC/TSS + TEEs, not AI.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum (master LITKEY) + Lit Chain (native gas token)
  • Addresses/identifiers: master LITKEY on Ethereum 0x4D4eb0E8B160f6EbF63cC6d36060ffec09301B42
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/governance/litkey/bridging-and-addresses
  • Why sufficient / why not (one line): the page with the official addresses records the token contract.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: the ledger contract on Lit Chain for prepayment and automatic charging for services; governance/key generation operations require transactions on Lit Chain.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/pricing/payment-model
  • Why sufficient / why not (one line): the docs describe onchain balance accounting and charging for operations.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the network could theoretically handle payments/accounting on a server; no strict Tier‑1 proof of “breaks down without the blockchain” in an operational form was found.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/pricing/payment-model
  • Why sufficient / why not (one line): the docs explain how it works on Lit Chain, but do not formulate “without the blockchain it loses its meaning” per the OC_3 standard.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, LITKEY.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/governance/litkey/overview
  • Why sufficient / why not (one line): the docs describe the functions of the token.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): all network services are priced and paid for in LITKEY via the ledger.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/learning-lit/pricing/payment-model
  • Why sufficient / why not (one line): the token deposit/ledger and charging for operations in LITKEY are described.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): node operators must stake LITKEY and receive rewards for operating the network.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/governance/litkey/overview
  • Why sufficient / why not (one line): the work‑token function is described explicitly.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): LITKEY is used for onchain governance.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/governance/litkey/overview
  • Why sufficient / why not (one line): the governance role of the token is described explicitly.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): LITKEY is described as the base work/payment/governance asset of the network and the gas of Lit Chain.
  • Evidence: Tier‑1 — https://naga.developer.litprotocol.com/governance/litkey/overview
  • Why sufficient / why not (one line): the token is embedded in the payment, staking and governance mechanics, i.e. it is a native instrument of the protocol.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://naga.developer.litprotocol.com/learning-lit/how-it-works description of the node network, key shares, Lit Actions and threshold execution
Tier‑1 https://naga.developer.litprotocol.com/learning-lit/security use of MPC/TSS and TEEs, as well as the presence of links to audits and the bug bounty
Tier‑1 https://naga.developer.litprotocol.com/learning-lit/pricing/payment-model the payment model in LITKEY via the ledger contract on Lit Chain
Tier‑1 https://naga.developer.litprotocol.com/governance/litkey/overview the role of LITKEY as a work/payment/governance token
Tier‑1 https://naga.developer.litprotocol.com/governance/litkey/initial-allocation-and-distribution fixed token supply of 1B and the distribution of LITKEY
Tier‑1 https://naga.developer.litprotocol.com/governance/litkey/bridging-and-addresses official addresses of the LITKEY contracts on different networks
Tier‑2 https://www.coingecko.com/en/coins/lit-protocol reference profile