On October 11, the cryptocurrency market experienced the largest liquidation event in history, with a total liquidation amount of approximately $19 billion. During this extreme market test, several decentralized perpetual contract trading platforms (Perp Dex) experienced outages, with Lighter suffering the most severe downtime, leading to losses in the liquidity provider fund pool (LLP) and sparking widespread discussion about PerpDex platforms in the market.
As a Web3 security company that has audited multiple Perp Dex platforms such as Surf Protocol and Tifo.trade, Beosin will help everyone gain a deeper understanding of the reasons behind the Lighter outage incident through years of accumulated technical and on-chain data analysis experience.
Lighter Technical Framework
Lighter stands out in the PerpDex craze with its zero transaction fee feature, attracting numerous users to trade on its platform. Lighter is built on zkLight, a specific ZK Rollup L2, to enhance trading performance and order book matching efficiency. Its core operational mechanism is illustrated in the diagram below:
Sorter: As the first point of user interaction, it is responsible for receiving trading instructions and sorting and packaging transactions into Batches (data packets of transaction batches).
Matching Engine: Receives Batches from the sorter and strictly follows the "price priority, time priority" matching logic. Each successful match prepares data for generating zero-knowledge proofs, ensuring that anyone can later verify the fairness of the matching process, thus avoiding the possibility of manipulation.
Prover: Generates a concise ZK-SNARK proof of the matching engine's operations for subsequent verification of the correctness of the matching execution and state transitions.
Mainnet Contract: Responsible for verifying the zero-knowledge proofs submitted by the prover. Once verified, the state root is updated, and the transaction result receives final confirmation on Ethereum.
In addition to the above design, Lighter provides users with a treasury function, allowing users to deposit funds into the Lighter Liquidity Pool (LLP), which undertakes the triple functions of liquidity provision, quote generation, and risk assumption. LLP participants can share platform profits and the earnings generated from counterparty losses, while also assuming part of the risk during user liquidations, forming a risk buffer mechanism in conjunction with Lighter's liquidation system.
Lighter Outage Review
On October 11, 2025, the scale of contract liquidations in the crypto market set a historical record. During this extreme market condition, Lighter experienced several hours of service interruption, preventing users from operating their positions, resulting in an LLP loss of approximately 5.35%.
Beosin's analysis of on-chain data during the main time period of this incident (Beijing time, October 11, 2025, 00:17-05:08) revealed that Lighter began losing 3 Batches starting from Batch #55661, and started recovering production of Batches at 00:17 (at 00:23, Lighter announced that user orders could not be processed or executed).
Before the outage, Lighter was processing approximately 4005 transactions per minute. Starting from 00:17, the transaction volume surged, with Batch #55665 containing 560 blocks and processing a total of 196,913 transactions, requiring an average of about 65,638 transactions per minute, approximately 16 times the usual period.
The following is a statistical chart of the number of transactions processed at each Batch submission time from 00:17 to 05:08 on October 11:
Compiled by Beosin
At 04:56 on October 11, the number of transactions processed by Batch #55743 reached its peak, completing 639,370 transactions in 2 minutes, which is 79.8 times the usual transaction processing rate per minute. By analyzing the data from this incident, we found that Lighter's Batches can accommodate a maximum of 1,600 blocks, with each block capable of holding up to 500 transactions, giving a theoretical maximum processing capacity of 800,000 transactions per Batch, while the actual maximum observed was 639,370.
The above represents the transactions successfully processed by the Lighter platform, while many users were unable to adjust their positions (due to the outage) because their transaction submissions failed and were not recorded on-chain. From a technical architecture perspective, the reasons for this outage and the resulting LLP losses can be attributed to two main factors:
In addition to issues with accessing the front-end page and submitting orders, Lighter's ZK Rollup relies on a single sorter for transaction sorting and packaging. Although results are verified through ZK Proof, the centralization of the sorter introduces a single point of failure risk. During the crash period, the sorter and database could not handle the sudden load, potentially leading to index corruption and transaction blocking in the database, directly causing a disconnection between the matching engine and the user side.
The proof generation and submission process of ZK-SNARK became a bottleneck during the surge in transaction volume. In extreme market conditions, the simultaneous surge in transaction matching and liquidation operations sent requests to the ZK proof generation nodes. The platform may not have set up resource reservation mechanisms for high-priority operations like liquidation, leading to resource competition between ordinary transaction and liquidation proof generation requests, further exacerbating system response delays and preventing timely execution of the liquidation process, amplifying user losses.
From an operational perspective, Lighter CEO Vladimir Novakovski responded, "Lighter originally planned to upgrade the database over the weekend when this crash occurred to accommodate the continuously growing trading demand." This incident highlights that the "wrong choice of upgrade window" was due to the team's insufficient preparation for market risks, failing to complete timely infrastructure upgrades during the platform's rapid expansion, ultimately leading to systemic failures of the platform under extreme market conditions.
This incident reveals a core challenge faced by PerpDex: how to maintain normal platform operations during extreme market conditions. In terms of smart contract security, project teams in the Perp Dex space should conduct comprehensive and professional contract security audits. Beosin has previously provided security audit services for Perp Dex platforms such as Surf Protocol and Tifo.trade, covering various aspects including the security of smart contract code, the correctness of business implementation logic (leverage trading, liquidation, liquidity pool management, etc.), contract code gas optimization, and the discovery and remediation of potential vulnerabilities, successfully helping project teams fix multiple medium to high-risk vulnerabilities.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
