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)
- The user does: the application calls Lit for signing/decryption or to run a Lit Action.
- The system does: Lit Nodes running in TEEs perform the operation via MPC/TSS: each node uses its own key share.
- The user gets: the result (signature/decryption/Lit Action execution) without revealing the private key to a single node/client.
- Where the blockchain is: Lit Chain stores states/contracts (including the ledger for prepayment and the network parameters).
- 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 |
Links (links_*)
| Type | Link |
|---|---|
| Website | https://litprotocol.com/ |
| Docs | https://naga.developer.litprotocol.com/learning-lit/how-it-works |
| GitHub | https://github.com/LIT-Protocol |
| Releases / Changelog | https://naga.developer.litprotocol.com/changelog |
| Whitepaper | https://github.com/LIT-Protocol/whitepaper/blob/main/Lit%20Protocol%20Whitepaper%20(2024).pdf |
| Roadmap | https://spark.litprotocol.com/2025-cryptography-roadmap/ |
| Security advisories | https://github.com/LIT-Protocol/js-sdk/security/advisories |
| Explorer | https://etherscan.io/token/0x4D4eb0E8B160f6EbF63cC6d36060ffec09301B42 |
| X | https://twitter.com/LitProtocol |
| Discord | https://discord.com/invite/zBw5hDZve8 |
| Telegram | https://t.me/+6ckQP9u442RiNzk5 |
| Medium | — |
| Audit report(s) | https://drive.google.com/drive/folders/1Rrht88iUkzpofwl1CvP9gEjqY60BKyFn |
| Bug bounty | https://developer.litprotocol.com/security/bug-bounty |
| CoinGecko (profile, reference) | https://www.coingecko.com/en/coins/lit-protocol |
| CoinMarketCap (profile, reference) | https://coinmarketcap.com/currencies/lit-protocol/ |
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 |
No comments to display
No comments to display