# Lighter — L2BEAT profile (read 2026-10-27)

Caveat: the page was read through a summarising fetch tool that capped quotes at 125 characters, so most values below are close paraphrases, not verbatim L2BEAT wording. Short quotes are marked with quotation marks. The final ~50k characters of the page (contract/permission detail) were read in a second pass; the middle sections were only partly visible. Source for everything unless stated: https://l2beat.com/scaling/projects/lighter

## Identity
- Display name: Lighter (https://l2beat.com/scaling/projects/lighter)
- Category: ZK Rollup, application-specific (appchain); purpose: Exchange (same URL)
- Host chain: Ethereum
- TVS: $1.05B on 2026-10-27, down 3.60% over 7 days. ETH & derivatives $22.16M (2.09%); stablecoins $578.69M (54.7%); other $456.32M (43.1%). The LIT token is 43.1% of TVS and carries a warning flag.
- Badges: Application-specific chain; Ethereum with blobs.

## 1. Stage
Source: https://l2beat.com/scaling/projects/lighter#stage
- Shown: **Stage 0**.
- Stage 0 requirements met (5): complete, functional proof system deployed; project calls itself a rollup; state roots posted to L1; state transition inputs posted to L1; source-available node that can recreate state from L1 data (L2BEAT has not verified the code).
- Stage 1 guidelines met (3): trusted setup meets minimum requirements; prover source published; verifier contracts regenerable from source.
- Stage 1 unmet (4): permissioned operators can censor user withdrawals; upgrades by actors with less control than a Security Council give under 7d to exit if the operator is down or censoring; the Security Council is not properly set up; indefinite blocking or invalid L2→L1 messages are not limited to Security Council compromise.
- Stage 2 unmet (2): upgrades unrelated to provable bugs give under 30d to exit; Security Council actions are not confined to onchain provable bugs.
- Banners/warnings: LIT token is 43.1% of TVS (warning). Pause guardian paused Lighter L2 for 2h on 2026-10-17, described as "in what looks like a test". Liveness: no ongoing anomaly, but the last 30 days show multiple gaps in proof, state-update and data submissions, longest 4h 38m. No "under review" banner was reported by the fetch.
- Config: the stage is computed by `getRollupStage(...)` with Stage 1/2 items set false (e.g. `usersHave7DaysToExit: false`, `usersCanExitWithoutCooperation: false`): https://raw.githubusercontent.com/l2beat/l2beat/main/packages/config/src/projects/lighter/lighter.ts
- L2BEAT's general stage checklist page was not separately fetched (see Not found).

## 2. Proof system
Source: https://l2beat.com/scaling/projects/lighter#state-validation
- State Validation: validity proofs (SNARKs), no execution delay, rated good. (Exact badge string, e.g. "Validity proofs (SN)", not captured verbatim.)
- Proofs are live (Stage 0 requirement "complete, functional proof system deployed" is met). Custom Plonky2 circuits for perp DEX and spot logic, wrapped in a Plonk proof using a trusted setup (Aztec Ignition).
- Permissioned: "Only the centralized operators can submit batches and verify them with a ZK proof" (config file above). Validators are EOA 1, EOA 4, EOA 5; the network governor (Lighter Multisig 2) adds/removes validators (https://l2beat.com/scaling/projects/lighter#permissions). Three EOAs can commit, verify, execute and revert uncommitted batches. Proving is not permissionless; no one can challenge (validity system).
- Proof finality/challenge period: no execution delay stated. Desert mode requires valid exit proofs verified on Ethereum.

## 3. Exit window and upgrades
Source: https://l2beat.com/scaling/projects/lighter#permissions and #upgrades-and-governance
- Exit Window: rated bad; the page says there is no exit window for an unwanted upgrade because contracts are "instantly upgradable" (config: `EXIT_WINDOW(0, priorityExpiration)`). The same page lists a 21d upgrade delay that the Security Council can skip, so the effective window is zero. Risk summary: malicious upgrade can steal funds, rated CRITICAL, "no delay on code upgrades".
- Who upgrades: Lighter, Governance and ZkLighterVerifier have admin UpgradeGatekeeper; upgrades are made by Lighter Multisig 2 with a 21d delay.
- Lighter Multisig 2 (0x97A9…03a2): 3/5, 5 participants; also networkGovernor; manages validators, insurance fund, treasury, markets, assets, and the Pause and Emergency Guardians.
- Lighter Multisig (0x92b1…2045): 4/7, 7 participants; is the UpgradeGatekeeper securityCouncilAddress; can reduce the 21d delay to zero. The page says every upgrade so far was fast-tracked this way.
- Other Safes listed: 0x3dD7…4daE 2/3 (3 participants); 0x9ccE…7310 3/5 (5 participants). Their roles were not captured.
- Guardians: EOA 2 (0x26Bb…dd16, emergencyGuardian) can pause commitment/verification/execution/withdrawals 24h–72h then 7d cooldown; EOA 3 (0x3896…A47a, pauseGuardian) 2h–24h then 24h cooldown; neither affects desert mode. Note: one fetched passage said both guardian addresses were zero after the 2026-10-02 update, another lists EOA 2/3; unresolved.
- Upgrade history: 91 upgrades; last ~7d 3h before snapshot; ZkLighterVerifier upgraded 2026-10-18 and 2026-10-20; Lighter and Governance 2026-09-30.

## 4. Data availability
Source: https://l2beat.com/scaling/projects/lighter#data-availability
- Onchain (state diffs) published as Ethereum blobs, rated good. Badge: Ethereum with blobs.
- Prover migration at block 23,711,820 left earlier blobs undecodable; Lighter published a full state snapshot at batch #166859; L2BEAT reproduced the root and rolled forward to chain head.
- DAC: none reported.

## 5. Sequencer and forced inclusion
Source: https://l2beat.com/scaling/projects/lighter#operator and #withdrawals
- Sequencer/operator: centralized operators only; risk: MEV by frontrunning.
- Sequencer Failure / Proposer Failure values verbatim: NOT CAPTURED. Config uses `RISK_VIEW.SEQUENCER_FORCE_VIA_L1(priorityExpiration)`.
- Forced inclusion: users can force deposits, withdrawals, order creation, order cancellation and pool-share burns via L1. Forced transactions must be processed within 14d (reduced from 18d on 2025-10-27, as read) or the system enters desert mode; users then exit by proving balances with a ZK proof (public exit circuit and snapshot).

## Stage history since 2026-04-27
- Milestones section lists only contract deployments/upgrades, no stage change. Config milestones: 2025-10-02 mainnet launch, 2025-10-10 4.5h downtime.
- Commit history for packages/config/src/projects/lighter (33 commits, 2026-05-25 to 2026-10-26): https://github.com/l2beat/l2beat/commits/main/packages/config/src/projects/lighter . Titles are dailies, ossification tooling, permissions storage, etc.; none says stage change. Diffs were not inspected, and commits between 2026-04-27 and 2026-05-25 were on the next, unread page.
- Stage is computed, not hard-coded, and the page still shows Stage 0 with Stage 1 blockers. Conclusion: no stage change evidenced; not verified at diff level.

## Not found
- Verbatim L2BEAT wording (summarising tool paraphrased); exact Sequencer Failure / Proposer Failure strings; the State Validation badge string.
- Stage checklist page https://l2beat.com/stage-checklist (not fetched). Possible "under review" banner not confirmed.
- Per-commit diffs of the config `stage` logic; commits from 2026-04-27 to 2026-05-24.
- Roles of the 2/3 and 3/5 Safes; resolution of guardian address conflict; middle of the page (about characters 100000 onward was read separately, but not the whole page in one pass).