Perpetual contracts are the highest value and most frequently traded products in the on-chain financial ecosystem, while also exhibiting the most pronounced systemic risks.
In March 2025, Hyperliquid's HLP pool triggered significant losses due to a whale opening large leverage positions on the platform and repeatedly withdrawing collateral, exposing structural weaknesses in the 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 its risk model's ability to withstand extreme market conditions.
Whether it is losses incurred by market makers, cascading liquidation reactions, or systemic risks triggered by individual actions, all relate directly to the same core issue: how the protocol prices, allocates risk, and handles leverage and liquidation. Therefore, without understanding the risk control architecture, one cannot truly grasp the moat of Perp DEX.
This article will delve into the "risk model," systematically dismantling 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.
The Risk Model of Perp DEX: The Lifeline of the Protocol
The risk model is the dynamic risk control hub of the protocol, determining its survival in extreme market conditions. It is akin to the risk engine in traditional finance but is more complex, as on-chain systems cannot undergo temporary manual interventions.
A mature Perp DEX risk model consists of multiple core components, with its architecture and interconnections illustrated in the following diagram:

Figure 1: (This diagram shows how the risk model starts from 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 price models, margin rules, liquidation mechanisms, and insurance funds.)
These modules collectively form the "risk skeleton" of the protocol. Any weakness in one link may lead to structural failures during significant market movements:
- LPs or market makers encountering uncontrollable losses (common in AMM models)
- The protocol becoming insolvent overall, with the insurance fund rapidly depleted
- Delayed liquidations triggering cascading liquidations and socialized losses
- Manipulation of oracles leading to attacks by arbitrageurs
- Loss of control over combination risks under multiple assets and leverage, resulting in global liquidation
In other words, the risk model determines how much capital the protocol can bear, what types of traders it can serve, and whether it can "survive" in extreme market conditions. Therefore, the risk model ultimately sets the upper limits for all indicators such as trading experience, depth, capital efficiency, protocol revenue, and token value capture.
This is why, in the past two years, the competition among Perp DEXs has shifted towards underlying risk control architecture, rather than merely focusing on trading mining or fee wars.
Core Module Breakdown of Mainstream Perp Architectures and Risk Models
The evolution of Perp DEX architecture is essentially a path of "how risk is redistributed."
- Stage One (Off-chain Order Book): Risk is concentrated in the robustness of centralized matching nodes. Represented by dYdX, this design ensures trading efficiency but highly concentrates risk on the availability and security of off-chain matching.
- Stage Two (AMM): Risk shifts towards directional exposure in liquidity pools. For example, GMX, under the AMM model, places significant directional risk on LPs, making impermanent loss, extreme market shifts, and MEV unavoidable issues within this architecture.
- Stage Three (On-chain Order Book - CLOB): Risk transforms into dependence on the performance and certainty of the underlying public chain. Representative projects like Hyperliquid have seen 70-80% of perpetual trading volume concentrated in the order book model. This high-performance on-chain environment also means unprecedented reliance on TPS, memory pool stability, and contract execution security.
- Frontier Exploration (Hybrid Model): The risk lies in the logic and feedback loop of dynamically switching between order books and liquidity pools. For instance, Drift on Solana uses AMM as a deep backup mechanism and automatically fills quotes when the order book lacks liquidity, thus seeking a new balance between execution quality and capital efficiency.
The differences in various architectures ultimately manifest 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 trades, triggers for liquidation, and funding rates, serving as the underlying benchmark for perpetual contract systems. It faces challenges such as oracle delays, manipulation, and MEV. Mature systems employ multi-source aggregation, TWAP, and maximum deviation limits to enhance attack resistance. The AMM architecture also requires an internal pricing mechanism to simulate liquidity depth, which is a core variable of its risk exposure.
2.2. Liquidation Model: The Key Risk Buffer Layer
The liquidation mechanism determines the system's capacity to withstand price fluctuations and is the most critical risk buffer layer of perpetual protocols. Its safety boundaries consist of initial margin, maintenance margin, and liquidation buffer. 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 bidding manipulation.
2.3. Insurance Fund: The Last Line of Defense
The insurance fund is used to absorb liquidation losses, and its size and usage rules directly reflect the protocol's risk tolerance, serving as the "last line of defense" for the system in extreme market conditions. The design needs to balance safety and capital efficiency: an overly large scale affects returns, while a too-small scale may trigger automatic liquidation, damaging the protocol's reputation.
2.4. Position Management: The System's Global Risk Controller
Position management ensures that the system does not lose control due to excessive concentration of unilateral positions. Through mechanisms such as position limits, dynamic margins, and funding rates, it adjusts the market's long and short forces. For multi-asset and long-tail assets, it also needs to manage correlation risks and manipulation risks, presenting greater challenges.
Trade-off Analysis of Risk Models in Mainstream Cases
Current mainstream platforms are transitioning towards CLOB or CLOB-Centric hybrid solutions to pursue better matching accuracy and capital efficiency. The following table systematically compares the risk model characteristics and core trade-offs of four representative projects:

Table 2: (This table juxtaposes Hyperliquid, Aster, edgeX, and Lighter across six dimensions: core architecture, price model, liquidation mechanism, insurance fund, major risks, and core trade-offs, showcasing the risk preferences and compromises under different technical routes.)
Key points from the case analysis:
- Hyperliquid: Achieves efficiency and depth close to CEX, but its matching logic combines on-chain settlement and order book verification, increasing system complexity and reliance on risk control mechanisms, necessitating a large HLP capital pool and complex risk control mechanisms, transferring significant risk control pressure to liquidity providers and the protocol itself.
- Aster: The liquidation mechanism follows the principle of "layered risk reduction," enhancing capital efficiency and robustness during low volatility periods through a "risk pooling" strategy, but at the cost of a more complex risk transmission path and extreme sensitivity to parameter settings.
- edgeX: Ensures high transparency and verifiability through ZK-Rollup technology, reducing reliance on external insurance funds, but at the cost of performance being limited by L2 data availability and state submission delays. The system must rely on redundancy mechanisms, verifiable replay, and strong monitoring to mitigate the impact of these risks on overall stability.
- Lighter: Under the "verifiable off-chain order book" architecture, it prioritizes auditability and on-chain credibility, but at the cost of performance not reaching the limits of pure off-chain matching, making it more suitable for users who prefer transparency, verifiability, and lower systemic risks.
Conclusion: Safety Boundaries and Future Trends
By 2025, the safety boundaries of Perp DEX have transitioned from "smart contract security" to "system-level security." On-chain matching, oracle price sources, liquidation logic, risk parameters, LP capital pool exposure control, the robustness of market-making mechanisms, and the integrity of cross-chain messaging collectively form an interdependent security framework.
Three major trends for the future:
Semi-Automated Risk Control: On-chain mechanisms are insufficient to cope with complex attacks; future systems will combine off-chain real-time monitoring and dynamic parameter adjustments to form a "semi-automated governance" system.
Regulatory Integration: A hybrid form of "non-custodial but regulated" will become key to attracting institutional-level liquidity. Verifiable KYC and compliant liquidity pools will become new infrastructure.
Technology-Driven Expansion of Safety Boundaries: Technologies such as zero-knowledge proofs, high-performance L2, and modular design 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 future winners will not be determined by competition over fees or depth, but by the ability to integrate technological security, financial engineering, and regulatory frameworks.
免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。