Perpetual contracts are the most valuable and frequently traded products in the on-chain financial ecosystem, but they also pose the most significant systemic risks.

In March 2025, Hyperliquid's HLP pool suffered significant losses due to whales using excessive leverage and repeatedly withdrawing collateral on the platform, exposing structural weaknesses in its mark-price mechanism and liquidation process. Such events remind us that beyond superficial trading depth and user growth, the true stability of Perp DEX ultimately stems from the resilience of its risk model under extreme market conditions.

Whether it's market maker losses, liquidation cascades, or systemic risks triggered by individual actions, they are all directly related to the same core issue: how the protocol is priced, how risk is allocated, and how leverage and liquidation are handled. Therefore, without understanding the risk control architecture, one cannot truly understand Perp DEX's competitive advantage.

This article will start with the "risk model" and systematically break down the core architecture, sources of risk, differences in risk control, and future trends of Perp DEX, providing a professional and comprehensive analytical framework for funds, quantitative traders, and Web3 investors.

Perp DEX's Risk Model: The Protocol's Lifeline

The risk model is the protocol's dynamic risk control hub, determining its survival under extreme market conditions. It is similar to the risk engine in traditional finance, but more complex because on-chain systems cannot be subject to temporary manual intervention.

A mature Perp DEX risk model is a system composed of multiple core components, and its architecture and interrelationships are shown in the following diagram:

 Figure 1: (This figure illustrates how the risk model starts with price inputs, is processed through the core risk control layer, and ultimately outputs the overall stability and capital efficiency of the system through the risk buffer layer. It reveals the intrinsic connections between modules such as the price model, margin rules, liquidation mechanism, and insurance fund.)

These modules together form the protocol's "risk skeleton." A weakness in any one of these components could lead to structural failures during major market movements.

LPs or market makers may experience uncontrollable losses (common in AMM models).
The agreement was insolvent, and the insurance fund was quickly depleted.
Delayed liquidation triggered a chain reaction of margin calls and widespread losses.
Oracle was manipulated, triggering an arbitrage attack.
The uncontrolled risk of a multi-asset, multi-leverage portfolio led to a total margin call.

In other words, the risk model determines how much capital a protocol can support, what types of traders it can serve, and whether it can survive in extreme market conditions. Therefore, the risk model ultimately determines the upper limit of all indicators such as trading experience, market depth, capital efficiency, protocol revenue, and token value capture.

This is why, in the past two years, competition in Perp DEX has shifted to underlying risk control architecture, rather than just transaction mining or fee wars.

Breakdown of core modules of mainstream PERP architecture and risk model

The architectural evolution of Perp DEX is essentially a path of "how risk is redistributed".

Phase 1 (Off-chain Order Book): The risk lies in the robustness of the centralized matching nodes. Represented by dYdX, this design ensures transaction efficiency, but the risk is highly concentrated on the availability and security of off-chain matching.
Phase Two (AMM): Risk is transferred to the directional exposure of the liquidity pool. For example, in GMX, under the AMM model, LPs bear extremely strong directional risk, making permanent loss, extreme market deviations, and MEV (Mean Equity) unavoidable issues for this architecture.
The third stage (On-Chain Order Book - CLOB): Risk shifts to reliance on the performance and determinism of the underlying public blockchain. A representative project is Hyperliquid, where 70-80% of perpetual transaction volume is now concentrated in the order book model. This high-performance on-chain environment also means an unprecedented reliance on TPS, mempool stability, and contract execution security.
Frontier Exploration (Hybrid Mode): The risk lies in the logic and feedback loop of the dynamic switching between the order book and liquidity pool. Taking Drift on Solana as an example, it uses AMM as a deep backup mechanism and automatically replenishes quotes when the order book lacks liquidity, thereby finding a new balance between execution quality and capital efficiency.

The differences between the different architectures are ultimately reflected in the design of the following four core risk control modules:

2.1. Price Model: The System's Benchmark

The price model determines the fairness of transactions, liquidation triggers, and funding rates, serving as the underlying benchmark for perpetual contract systems. It faces challenges such as oracle latency, manipulation, and MEV (Mean Equity). Mature systems employ multi-source aggregation, TWAP (Transfer-Only-Pay), and maximum deviation limits to enhance resistance to attacks. AMM (Automated Market Maker) architectures also require internal pricing mechanisms to simulate liquidity depth, a core variable in their risk exposure.

2.2. Liquidation Model: A Key Risk Buffer

The liquidation mechanism determines the system's ability to withstand price fluctuations and is the most critical risk buffer layer of a perpetual protocol. Its security boundary consists of the initial margin, maintenance margin, and liquidation buffer. The execution logic (partial liquidation, full liquidation, auction) directly impacts user experience and system efficiency. Liquidation itself also faces attack surfaces such as on-chain congestion and bid manipulation.

2.3. Insurance Funds: The Last Line of Defense

The insurance fund is used to absorb losses from margin calls. Its size and usage rules directly reflect the agreement's risk tolerance and serve as the system's "last line of defense" in extreme market conditions. The design needs to balance security and capital efficiency: too large a size will affect returns, while too small a size will easily trigger automatic liquidation, damaging the agreement's reputation.

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

Position management ensures the system doesn't spiral out of control due to excessive concentration of one-sided positions. Mechanisms such as position limits, dynamic margin requirements, and funding rates are used to regulate market forces. For multi-asset and long-tail assets, managing correlation and manipulation risks presents even greater challenges.

Risk model trade-off analysis in mainstream cases

Current mainstream platforms are transitioning towards CLOB or CLOB-Centric hybrid solutions to achieve better matching accuracy and capital efficiency. The table below systematically compares the risk model characteristics and core trade-offs of four representative projects:

 Chart 2 (This chart compares Hyperliquid, Aster, edgeX, and Lighter side-by-side from six dimensions: core architecture, pricing model, liquidation mechanism, insurance fund, major risks, and core trade-offs, demonstrating the risk preferences and trade-offs under different technology routes.)

Key points of case analysis:

Hyperliquid achieves near-CEX efficiency and depth, but its matching logic combines on-chain settlement and order book verification, increasing system complexity and reliance on risk control mechanisms. It requires a large HLP liquidity pool and complex risk control mechanisms, transferring extremely high risk control pressure to liquidity providers and the protocol itself.
Aster: The liquidation mechanism is based on the principle of "reducing risk layer by layer". It improves capital efficiency and robustness during periods of low volatility through the "risk pooling" strategy, but at the cost of a more complex risk transmission path and extreme sensitivity to parameter settings.
edgeX uses ZK-Rollup technology to ensure extremely high transparency and verifiability, reducing reliance on external insurance funds. However, this comes at the cost of performance limitations imposed by L2 data availability and state commit latency. The system needs to rely on redundancy mechanisms, verifiable playback, and robust monitoring to mitigate the impact of these risks on overall stability.
Lighter: Under the "verifiable off-chain order book" architecture, auditability and on-chain trust are given priority, but at the cost of performance that cannot reach the upper limit of pure off-chain matching. Therefore, it is more suitable for users who prefer transparency, verifiability and lower systemic risk.

Conclusion: Security Boundaries and Future Trends

By 2025, Perp DEX's security boundary had transitioned from "smart contract security" to "system-level security." On-chain matching, oracle price sources, liquidation logic, risk parameters, LP liquidity pool exposure control, robustness of the market-making mechanism, and the integrity of cross-chain messages together constitute an interdependent security framework.

Three major trends for the future:

1. Semi-automated risk control: On-chain mechanisms are insufficient to cope with complex attacks. In the future, a "semi-automated governance" system will be formed by combining off-chain real-time monitoring and dynamic parameter adjustment.

2. Compliance Integration: The hybrid model of "no custody required but subject to regulation" will become key to attracting institutional-grade liquidity. Verifiable KYC and compliant liquidity pools will become the new infrastructure.

3. Technology-driven expansion of security boundaries: Technologies such as zero-knowledge proofs, high-performance L2, and modular design will enable complex real-time risk models to run on the blockchain, elevating risk control capabilities to the level of financial infrastructure.

The winners of the future will no longer be those who compete on transaction fees or depth, but rather those who can integrate technological security, financial engineering, and compliance frameworks.

ZachXBT: Beware of fake Hyperliquid apps on the Google Play Store.

Popular Articles