On the night of the 19 billion liquidation, why did Lighter "shut down"?

On October 11th, the cryptocurrency market experienced its largest margin call in history, with a total liquidation of approximately $19 billion. During this extreme market test, multiple decentralized perpetual swap trading platforms (PerpDex) experienced outages, with Lighter being the most severely affected. The resulting losses in the liquidity provider pool (LLP) sparked widespread market discussion about the PerpDex platform.

As a Web3 security company that has audited multiple Perp Dex platforms, including Surf Protocol and Tifo.trade, Beosin will use years of accumulated technology and on-chain data analysis experience to help everyone gain a deeper understanding of the cause of the Lighter outage in this article.

Lighter Technology Framework

Lighter stood 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 transaction performance and order book matching efficiency. Its core operating mechanism is illustrated 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).

The matching engine receives batches from the sequencer and strictly adheres to the "price-first, time-first" matching logic. Each successful match prepares data for generating a zero-knowledge proof, ensuring that anyone can verify the fairness of the matching process afterward, preventing manipulation.

Prover: Generates the matching engine's operations into a concise ZK-SNARK proof for subsequent verification of 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 on Ethereum.

In addition to the above features, Lighter provides users with a vault feature, allowing them to deposit funds into the Lighter Liquidity Pool (LLP). This liquidity pool serves as a liquidity provider, price generator, and risk management platform. LLP participants share in platform profits and counterparty losses, while also assuming some of the risk in the event of a user's margin call, forming a risk buffer mechanism in conjunction with Lighter's liquidation system.

Lighter downtime review

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

Beosin analyzed on-chain data during the main time period of this incident (00:17-05:08 Beijing time on October 11, 2025) and found 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 approximately 4,005 transactions per minute. Starting at 00:17, the transaction volume surged. Batch #55665 contained 560 blocks and processed 196,913 transactions. On average, approximately 65,638 transactions were processed per minute, which is about 16 times the normal volume.

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:

 Produced by Beosin Statistics

At 04:56 on October 11th, Batch #55743 reached its maximum transaction count, completing 639,370 transactions in 2 minutes, 79.8 times the average per-minute transaction rate. By analyzing Lighter's data from this 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 maximum number of transactions per batch is 800,000, but the actual maximum number of transactions processed was 639,370.

The above are transactions successfully processed by the Lighter platform. However, many users failed to adjust their positions due to transaction submission failures (downtime), resulting in data not being recorded on the chain. 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 sequencer for transaction sorting and packaging. Although ZK Proof is used for result verification, the centralization of the sequencer creates a single point of failure risk. During periods of price drops, the sequencer and database are unable to handle the sudden load, resulting in database index corruption and transaction blockage, directly leading to disconnection between the matching engine and the client.

2. When transaction volume surges, the coordinated processing capabilities of the proof generation nodes and the database become a bottleneck in the ZK-SNARK proof generation and submission process. In extreme market conditions, a simultaneous surge in trade matching and clearing operations simultaneously initiates requests to the ZK proof generation nodes. The platform may not have implemented resource reservation mechanisms for high-priority operations like clearing. This creates resource competition between regular transactions and clearing proof generation requests, further exacerbating system response delays and preventing the clearing process from executing promptly, 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 recent crash to accommodate increased trading demand." This incident suggests this "incorrect upgrade window" stems from 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 during 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. These audits cover the security of smart contract code, the correctness of business implementation logic (such as leveraged trading, liquidation, and liquidity pool management), contract code gas optimization, and the discovery and remediation of potential vulnerabilities. Beosin has successfully helped project teams resolve multiple medium- and high-risk vulnerabilities.