Why did PerpDex "shut down"? A complete review of the Lighter outage lasting 4 hours.

On October 11th, the crypto assets 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 futures trading platforms (Perp Dex) experienced outages, among which Lighter had the most severe outage, leading to losses in the liquidity provider fund pool (LLP), which sparked widespread discussion in the market about the PerpDex platform.

As a Web3 security company that has audited multiple Perp Dex such as Surf Protocol and Tifo.trade, Beosin will help everyone gain an in-depth understanding of the reasons behind the recent Lighter downtime incident through years of accumulated technology and on-chain data analysis experience.

Lighter Technical Framework

Lighter stands out in the PerpDex craze with its feature of zero trading fees, 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 shown 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 a Batch (batch processing data packets for transactions).

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 subsequently verify the fairness of the matching process, thereby avoiding the possibility of manipulation.

Prover: Generates a concise ZK-SNARK proof of the operation of the matching engine for subsequent verification of the correctness of matching execution and state transitions.

Mainnet Contract: Responsible for verifying the zero-knowledge proofs submitted by validators. Once the verification is successful, the state root will be updated, and at this point, the transaction result will achieve finality on Ethereum.

In addition to the above design, Lighter provides users with a vault function, allowing users to deposit funds into the Lighter Liquidity Pool (LLP). This liquidity pool undertakes the triple functions of providing liquidity, generating quotes, and assuming risks. LLP participants can share in the platform's profits and the profits generated from counterparties' losses, while also assuming part of the risk when users Get Liquidated, working with Lighter's liquidation system to form a risk buffer mechanism.

Lighter Outage Review

On October 11, 2025, the contract liquidation scale in the crypto market set a historical record. During this extreme market condition, Lighter experienced multiple hours of service interruption, preventing users from managing their positions, resulting in an LLP loss of approximately 5.35%.

Beosin analyzed the on-chain data during the main time period of this event (Beijing time, October 11, 2025, 00:17-05:08) and found that Lighter lost 3 Batches starting from Batch#55661, and began to recover the output of Batches at 00:17 (at 00:23, Lighter announced that users' orders could not be processed or executed).

The Lighter platform processed approximately 4005 transactions per minute before the downtime. Starting from 00:17, the transaction volume surged, with Batch#55665 containing 560 blocks. The number of transactions processed was 196913, requiring an average of about 65638 transactions per minute, which is roughly 16 times the normal 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

On October 11 at 04:56, Batch#55743 processed the maximum number of transactions, completing 639,370 transactions within 2 minutes, which is 79.8 times the usual transaction processing rate per minute. By analyzing the data from this event for Lighter, we found that Lighter's Batch can accommodate a maximum of 1,600 blocks, with each block capable of holding up to 500 transactions, resulting in a theoretical processing capacity of 800,000 transactions per Batch, while the highest measured was 639,370.

The above are the transactions successfully processed by the Lighter platform, and there are many users who were unable to adjust their positions due to failed transaction submissions (downtime) and thus did not have their data recorded on the chain. From a technical architecture perspective, this downtime and the resulting LLP losses are mainly due to two reasons:

1. Besides issues with accessing the frontend and submitting orders, Lighter's ZK Rollup relies on a single sorter for transaction sorting and packaging. Although ZK Proof is used for result verification, the centralization of the sorter leads to a single point of failure risk. During periods of sharp decline, the sorter and database cannot handle the sudden load, which may result in index corruption and transaction blocking in the database, directly causing a disconnection between the matching engine and the user end. 2. The proof generation and submission process of ZK-SNARK becomes a bottleneck when transaction volume surges. In extreme market conditions, the simultaneous spike in transaction matching and clearing operations sends requests to the ZK proof generation nodes. The platform may not have set resource reservation mechanisms for high-priority operations like clearing, leading to resource competition between proof generation requests for ordinary transactions and clearing, further exacerbating system response delays, making it impossible for the clearing process to execute timely, and amplifying user losses. From an operational perspective, according to Lighter CEO Vladimir Novakovski, “Lighter originally planned to upgrade the database over the weekend when this sharp decline occurred to accommodate the continuously growing transaction demands.” This incident reveals that this “upgrade window selection error” was due to the team's inadequate preparation for market risks. During the platform's rapid expansion, they failed to complete timely infrastructure upgrades, ultimately leading to systemic failures of the platform under extreme market conditions. This incident highlights a core challenge faced by PerpDex: how to maintain normal operations of the platform during extreme market conditions. Regarding smart contract security, the project teams in the Perp Dex track should conduct comprehensive and professional contract security audits. Beosin has previously provided security audit services for Perp Dex projects like Surf Protocol and Tifo.trade, covering various aspects such as the security of smart contract code, correctness of business implementation logic (leveraged trading, clearing, liquidity pool management, etc.), optimization of contract code gas, and discovery and remediation of potential vulnerabilities, successfully helping project teams fix several medium-to-high risk vulnerabilities.

In addition, the Perp Dex project team needs to consider architectural redundancy and emergency mechanisms. In the future, with the application of technologies such as multi-sorting and dynamic resource scheduling, Perp Dex is expected to overcome the current bottleneck, serve more users, and become the core infrastructure of crypto finance.