Analyzing the Underlying Game Theory of Perp DEXs Through the Hyperliquid Incident

Why is the competition between Perp DEXs essentially a competition of “risk models”?

Perpetual contracts are the most valuable and frequently traded products in the on-chain financial ecosystem, and also the ones with the most prominent systemic risks.

Perp DEX Risk Model: The Lifeline of the Protocol

The risk model is the core of a protocol’s dynamic risk control, determining whether it can survive extreme market conditions. It is similar to the risk engine in traditional finance, but even more complex, as on-chain systems cannot rely on temporary manual intervention.

A mature Perp DEX risk model is a system composed of multiple core components, with its architecture and interactions shown in the diagram below:

Figure 1: (This diagram illustrates how the risk model starts from price inputs, is processed by the core risk control layer, and ultimately outputs overall system stability and capital efficiency through the risk buffer layer. It reveals the internal connections among modules like the price model, margin rules, liquidation mechanism, and insurance fund.)

These modules together form the protocol’s “risk skeleton.” Weakness in any link may lead to structural failures during major market events:

• LPs or market makers experience uncontrollable losses (common in AMM models)
• The protocol as a whole becomes insolvent, and the insurance fund is rapidly depleted
• Liquidation delays trigger cascading liquidations and socialized losses
• Oracles are manipulated, leading to attacks by arbitrageurs
• Portfolio risk across multiple assets and leverage spirals out of control, resulting in systemic insolvency

In other words, the risk model determines how much capital the protocol can support, what types of traders it can serve, and whether it can “survive” extreme market conditions. Therefore, the risk model ultimately sets the upper limit for all metrics, including trading experience, depth, capital efficiency, protocol revenue, and token value capture.

This is why, in the past two years, competition among Perp DEXs has shifted towards underlying risk control architecture, rather than just trading mining or fee wars.

Core Module Breakdown of Mainstream Perp Architectures and Risk Models

The evolution of Perp DEX architectures is essentially a journey of “how risk is redistributed.”

• First stage (off-chain order book): Risk is concentrated on the robustness of the centralized matching node. Represented by dYdX, this design ensures trading efficiency but highly concentrates risk on the availability and security of off-chain matching.
• Second stage (AMM): Risk is transferred to the directional exposure of the liquidity pool. For example, in GMX, the AMM model puts strong directional risk on LPs, making impermanent loss, extreme market shifts, and MEV unavoidable issues for this architecture.
• Third stage (on-chain order book—CLOB): Risk shifts to reliance on the underlying public chain’s performance and finality. Projects like Hyperliquid exemplify this, with 70-80% of perpetual trading volume now centered on the order book model. This high-performance on-chain environment creates unprecedented reliance on TPS, mempool stability, and contract execution security.
• Frontier exploration (hybrid mode): Risk lies in the logic and feedback loops of dynamically switching between the order book and liquidity pool. Solana’s Drift, for example, uses the AMM as a deep backup mechanism and automatically fills quotes when the order book lacks liquidity, seeking a new balance between execution quality and capital efficiency.

The differences in architecture ultimately boil down to the design of these four core risk control modules:

2.1. Price Model: The System Benchmark

The price model determines trading fairness, liquidation triggers, and funding rates, serving as the foundation of the perpetual contract system. It faces challenges such as oracle latency, manipulation, and MEV. Mature systems use multi-source aggregation, TWAP, and max deviation limits to enhance resistance to attacks. AMM architectures also require internal pricing mechanisms to simulate liquidity depth, which is a key variable in their risk exposure.

2.2. Liquidation Model: The Key Risk Buffer Layer

The liquidation mechanism determines the system’s ability to withstand price volatility and is the most critical risk buffer for perpetual protocols. Its safety boundaries are set by initial margin, maintenance margin, and liquidation buffer. Execution logic (partial liquidation, full liquidation, auction) directly affects user experience and system efficiency. Liquidation itself also faces attack surfaces such as on-chain congestion and bidding manipulation.

2.3. Insurance Fund: The Last Line of Defense

The insurance fund absorbs bankruptcy losses. Its size and usage rules directly reflect the protocol’s risk tolerance and form the system’s “last line of defense” during extreme market conditions. The design must balance safety and capital efficiency: too large reduces returns, too small easily triggers auto-deleveraging, harming protocol reputation.

2.4. Position Management: The System’s Global Risk Controller

Position management ensures the system doesn’t spiral out of control from excessive concentration in one-sided positions. Mechanisms such as position caps, dynamic margin, and funding rates adjust the balance of long and short forces in the market. For multi-asset and long-tail assets, managing correlation and manipulation risks is even more challenging.

Trade-off Analysis of Risk Models in Leading Examples

Currently, mainstream platforms are shifting toward CLOB or CLOB-centric hybrid schemes to pursue better matching accuracy and capital efficiency. The table below systematically compares the risk model characteristics and key trade-offs of four representative projects:

Figure 2 (This table compares Hyperliquid, Aster, edgeX, and Lighter across six dimensions: core architecture, price model, liquidation mechanism, insurance fund, main risks, and core trade-offs, showing the risk preferences and choices of different technical routes.)

Key points from the case studies:

• Hyperliquid: Achieves efficiency and depth close to CEXs, but its matching logic combines on-chain settlement and order book verification, increasing system complexity and reliance on risk control mechanisms. It must be equipped with a large HLP fund pool and complex risk management, shifting considerable risk management pressure to liquidity providers and the protocol itself.
• Aster: The liquidation mechanism follows the principle of “layered risk reduction,” using a “risk pooling” strategy to enhance capital efficiency and stability during low-volatility periods, at the cost of a more complex risk transmission path and extreme sensitivity to parameter settings.
• edgeX: Utilizes ZK-Rollup technology to ensure high transparency and verifiability, reducing dependence on external insurance funds. The trade-off is that performance is limited by L2 data availability and state submission delays. The system relies on redundancy mechanisms, verifiable replay, and strong monitoring to mitigate these risks to overall stability.
• Lighter: Under the “verifiable off-chain order book” architecture, it prioritizes auditability and on-chain trustworthiness, but cannot achieve the performance ceiling of pure off-chain matching. Thus, it is better suited for users who value transparency, verifiability, and lower systemic risk.

Conclusion: Security Boundaries and Future Trends

By 2025, the security boundary for Perp DEXs has shifted from “smart contract security” to “system-level security.” On-chain matching, oracle price feeds, liquidation logic, risk parameters, LP pool exposure controls, market making mechanism robustness, and cross-chain message integrity now form an interdependent security framework.

Three major future trends:

1. Semi-automated risk control: On-chain mechanisms alone are insufficient against complex attacks. In the future, they will be combined with real-time off-chain monitoring and dynamic parameter adjustment to form a “semi-automated governance” system.

2. Compliance integration: “Non-custodial but regulated” hybrid models will be key to attracting institutional liquidity. Verifiable KYC and compliant liquidity pools will become new foundational infrastructure.

3. Technology-driven expansion of security boundaries: Zero-knowledge proofs, high-performance L2s, and modular designs will make it possible for complex real-time risk models to operate on-chain, elevating risk control capabilities to the level of financial infrastructure.

The winners of the future will no longer compete on fees or depth, but on their ability to integrate technical security, financial engineering, and compliance frameworks.