Original Source: Beosin
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, multiple 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 in the market about PerpDex platforms.
As a Web3 security company that has audited several Perp Dex platforms such as Surf Protocol and Tifo.trade, Beosin will leverage years of accumulated technical and on-chain data analysis experience in this article to help everyone gain a deeper understanding of the reasons behind the Lighter outage.
Lighter Technical Framework
Lighter stands out in the PerpDex boom due to its zero trading 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 trades into Batches (data packets of trade processing).
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, used for subsequent verification of the correctness of matching execution and state transitions.
Mainnet Contract: Responsible for verifying the zero-knowledge proofs submitted by the prover. Once verified, it updates the state root, thus 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 gains 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 managing 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 event (Beijing time October 11, 2025, 00:17-05:08) found that Lighter began losing 3 Batches starting from Batch#55661, and started to recover Batch production 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, but starting from 00:17, the transaction volume surged. Batch#55665 contained 560 blocks, processing a total of 196,913 transactions, requiring an average of about 65,638 transactions to be processed per minute, which is about 16 times the usual period.
The following is a statistical chart of the number of transactions processed at each Batch submission time point from 00:17 to 05:08 on October 11:
Compiled by Beosin
At 04:56 on October 11, Batch#55743 reached its maximum transaction processing volume, completing 639,370 transactions in 2 minutes, which is 79.8 times the usual transaction processing volume per minute. By analyzing the data from this incident, we found that Lighter's Batch can accommodate a maximum of 1,600 blocks, with each block capable of holding up to 500 transactions, theoretically allowing for 800,000 transactions per Batch, while the actual maximum was 639,370.
The above represents the transactions successfully processed by the Lighter platform; 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 outage and the resulting LLP losses were primarily due to two reasons:
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 leads to a single point of failure risk. During the crash period, the sorter and database could not handle the sudden load, potentially causing index corruption and transaction blocking in the database, directly leading to a disconnection between the matching engine and the user end.
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 initiated requests to the ZK proof generation node. The platform may not have set up a resource reservation mechanism for high-priority operations like liquidation, leading to resource competition between ordinary transaction and liquidation proof generation requests, further exacerbating system response delays, preventing timely execution of the liquidation process and 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.” From this incident, it is evident that this "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 during 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 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.), gas optimization of contract code, and the discovery and remediation of potential vulnerabilities, successfully helping project teams fix multiple medium to high-risk vulnerabilities.
https://www.beosin.com/audits/Surf%20Protocol%20V2_202403281200.pdf
Additionally, Perp Dex project teams need to consider incorporating architectural redundancy and emergency mechanisms. In the future, with the application of technologies such as multi-sorters and dynamic resource scheduling, Perp Dex is expected to resolve the current bottleneck, serve more users, and become a core infrastructure of crypto finance.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
