Why did PerpDex go down? A complete replay of Lighter's 4-hour downtime

On October 11th, the cryptocurrency market experienced its largest margin call in history, with a total liquidation amount of approximately $19 billion. Amid this extreme market test, several decentralized perpetual swap trading platforms (PerpDex) experienced outages, with Lighter experiencing the most severe outage. The resulting losses in its liquidity provider pool (LLP) sparked widespread market discussion about the PerpDex platform. As a Web3 security firm that has audited several PerpDex platforms, including Surf Protocol and Tifo.trade, Beosin will leverage years of experience in technical and on-chain data analysis to provide a deeper understanding of the causes of the Lighter outage. Lighter's Technical Framework: Lighter stands out amid the PerpDex craze with its zero transaction fees, attracting numerous users to trade on its platform. Lighter is built on zkLight, a specialized ZK Rollup L2, to improve trading performance and order book matching efficiency. Its core operating mechanism is shown in the figure below:

Sorter: As the first stop for user interaction, it is responsible for receiving transaction instructions, sorting transactions, and packaging them into batches (batch data packets of transactions).

Matching Engine: Receives batches from the sorter and strictly adheres to the "price-first, time-first" matching logic.

Every successful match prepares data for generating a zero-knowledge proof, ensuring that anyone can verify the fairness of the matching process afterwards and preventing the possibility of manipulation. Prover: Generates the matching engine's operations into a concise ZK-SNARK proof, which is used to subsequently verify the correctness of matching execution and state transitions. Mainnet Contract: Responsible for verifying the zero-knowledge proof submitted by the prover. Once verified, the state root is updated, and the transaction result is finally confirmed and finalized 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), which performs the triple functions of liquidity provision, quote generation, and risk assumption. LLP participants share in the platform's profits and the losses of their counterparties, while also shouldering some of the risk in the event of a user's margin call, collaborating with Lighter's liquidation system to form a risk buffer.

Lighter Downtime Review

On October 11, 2025, the crypto market saw record-breaking contract liquidations. During this extreme market, Lighter experienced a multi-hour service outage, preventing users from operating their positions and resulting in a LLP loss of approximately 5.35%.

Beosin found through on-chain data analysis during the main time period of this incident (00:17-05:08 Beijing time on October 11, 2025) that Lighter lost 3 batches starting from Batch#55661 and resumed batch production at 00:17 (00:23 Lighter issued an announcement stating that users' orders could not be processed or executed).

Before the outage, the Lighter platform normally processed about 4,005 transactions per minute. The transaction volume surged from 00:17. Batch#55665 contained 560 blocks and processed 196,913 transactions. On average, about 65,638 transactions were processed per minute, about 16 times the normal time 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:

Statistically produced by Beosin

At 04:56 on October 11, the number of transactions processed by Batch#55743 reached its maximum, completing 639,370 transactions in 2 minutes, which is 79.8 times the number of transactions processed per minute during normal times. By analyzing the data from the Lighter incident, we found that Lighter's batch can accommodate up to 1,600 blocks, each of which can accommodate up to 500 transactions. The theoretical number of transactions it can process is 800,000 per batch, while the highest measured number is 639,370. The above are transactions successfully processed by the Lighter platform. There are also many users whose data was not recorded on-chain due to failed transaction submissions and inability to adjust their positions (downtime). From a technical architecture perspective, this downtime and the resulting LLP losses are primarily due to two reasons: 1. 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 ZK Proof is used to verify the results, the centralization of the sorter creates a single point of failure risk. During periods of sharp price drops, the sequencer and database are unable to handle the sudden load, potentially leading to index corruption and transaction blockage in the database, directly disrupting the connection between the matching engine and the user end. 2. During periods of sudden increases in trading volume, the ZK-SNARK proof generation and submission process becomes a bottleneck due to the coordinated processing capabilities of the proof generation nodes and the database. Under extreme market conditions, a simultaneous surge in trade matching and clearing operations simultaneously initiates requests to the ZK proof generation node. The platform may not have implemented resource reservation mechanisms for high-priority operations like clearing, resulting in resource competition between regular trading and clearing proof generation requests, further exacerbating system response delays, preventing the clearing process from executing promptly, and exacerbating user losses. On an operational level, Lighter CEO Vladimir Novakovski responded, "Lighter had originally planned to upgrade its database over the weekend of the price drop to accommodate the continued surge in trading demand." This incident reveals that this "incorrect upgrade window selection" 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 in the extreme market conditions. This incident reveals a core challenge facing PerpDex: how to maintain normal platform operations during extreme market conditions. Regarding smart contract security, PerpDex project teams should conduct comprehensive and professional contract security audits. Beosin has previously provided security audit services for PerpDex projects such as Surf Protocol and Tifo.trade, covering aspects such as smart contract code security, business implementation logic correctness (margin trading, clearing, liquidity pool management, etc.), contract code gas optimization, potential vulnerability discovery and remediation, and successfully helping project teams resolve multiple medium- and high-risk vulnerabilities. Furthermore, the PerpDex project team must consider architectural redundancy and emergency response mechanisms. In the future, with the application of technologies such as multi-sequencers and dynamic resource scheduling, Perp Dex is expected to solve the current bottleneck, serve more users and become the core infrastructure of crypto finance.