As the on-chain derivatives market becomes increasingly professional, more traders are paying attention to protocol stability during extreme market conditions. For on-chain perpetual futures protocols, the risk system affects not only the safety of user positions, but also whether the protocol can maintain solvency and market liquidity.
Perpetual futures allow users to use leverage to increase market exposure, but leverage also magnifies the risk of losses. When market prices move sharply, a user’s account equity can fall quickly. If the protocol cannot control risk in time, bad debt may occur.
Unlike traditional spot trading, the value of positions in perpetual futures markets changes continuously, so the protocol must monitor account risk levels in real time. Phoenix’s risk system needs to achieve several goals, including:
Checking whether user margin is sufficient
Limiting excessive leverage risk
Controlling bad debt during extreme market conditions
Maintaining stable market operation
Because Phoenix uses a Fully On-Chain model, these risk checks run on-chain rather than being manually controlled by a centralized platform.
Margin is one of the core risk control tools in perpetual futures trading.
When a user opens a position on Phoenix, they need to provide a certain percentage of initial margin. This capital is used to cover potential losses and determines the amount of leverage the user can access.
For example, if a user wants to open a position with 10x leverage, they only need to provide a portion of the position value as margin.
As market prices change, account equity also changes in real time. Phoenix continuously calculates:
Account equity
Unrealized profit and loss
Available margin
Leverage ratio
If account equity falls below the maintenance margin requirement, the system may trigger the liquidation process.
Compared with centralized exchanges, Phoenix’s margin status is fully public, and all risk data can be verified on-chain.
Phoenix’s Risk Engine is responsible for monitoring market and account status in real time.
When a user submits an order, the risk engine first checks whether the account meets the requirements for opening a position. These checks include current position size, leverage level, margin balance, and market risk parameters. Only orders that meet the risk requirements are allowed to enter the order book.
After an order is filled, the risk engine continues monitoring account status. When market volatility increases risk, the system may restrict the user from adding more to the position or even trigger forced liquidation.
Because on-chain derivatives markets can move quickly, the risk engine needs to stay synchronized with the order book, Oracle, and settlement system in real time.
Phoenix uses a funding rate mechanism to keep perpetual futures prices balanced with the spot market.
Because perpetual futures have no expiry date, their prices may remain disconnected from spot prices for extended periods. The funding rate mechanism encourages the market to return to balance through periodic payments between long and short traders.
In general:
When the perpetual futures price is higher than the spot price, longs pay funding to shorts
When the perpetual futures price is lower than the spot price, shorts pay funding to longs
Funding rates affect not only trading costs, but also the direction of market leverage.
For Phoenix, the funding rate mechanism can reduce the risk of long term market imbalance and lessen the impact of price divergence on protocol stability.
Although Phoenix uses an order book trading model, its risk system still relies on Oracle data to provide market reference prices.
Oracle data is mainly used to:
Calculate the mark price
Assess account risk levels
Trigger liquidation logic
Avoid market manipulation
If the system relied only on order book execution prices, short term abnormal volatility could appear in low liquidity environments. Phoenix therefore combines Oracle data to maintain the stability of its risk system.
In on-chain derivatives protocols, Oracle systems are usually one of the key infrastructure components. If Oracle prices become abnormal, they may cause incorrect liquidations or amplify market risk.
Therefore, Phoenix’s overall security depends not only on its order book structure, but also closely on the quality of Oracle data.
When account equity falls below the maintenance margin requirement, Phoenix triggers the forced liquidation mechanism.
The goal of the liquidation system is to prevent account losses from expanding and protect the protocol’s overall solvency.
After liquidation is triggered, the system will:
Check the account’s risk level
Close part or all of the position
Recover unpaid risk exposure
Update market status
Because perpetual futures involve leverage, liquidations may happen quickly during sharp market moves.
Phoenix’s liquidation logic runs on-chain, which means all liquidation records can be publicly verified rather than handled internally by a centralized platform.
However, on-chain liquidation systems are also affected by network performance. For this reason, Solana’s high throughput and low latency are important for the stable operation of Phoenix’s risk system.
Extreme market conditions are an important source of risk in the on-chain derivatives market.
When the market rises or falls rapidly, large scale liquidations, insufficient liquidity, severe price divergence, and liquidation delays may occur. Phoenix’s risk system therefore uses several methods to reduce the impact of extreme market conditions, including dynamic margin parameters, risk limits, and funding rate adjustments.
At the same time, the order book model itself can also help improve price discovery efficiency. Compared with the AMM model, an order book can provide more precise price management during highly volatile markets.
Even so, the on-chain perpetual futures market still carries systemic risk. Risk control mechanisms can reduce risk, but they cannot fully eliminate potential losses caused by market volatility.
Phoenix and centralized exchanges differ clearly in how they manage risk.
Centralized platforms typically rely on internal servers to maintain orders, liquidations, and risk systems, while Phoenix’s risk logic runs in on-chain programs.
The core differences include:
| Comparison Dimension | Phoenix | Centralized Exchanges |
|---|---|---|
| Risk system | Runs on-chain | Platform servers |
| Data transparency | Publicly verifiable | Internal to the platform |
| Asset custody | User self-custody | Platform custody |
| Liquidation records | Public on-chain | Usually not visible |
| Market control | Executed by protocol rules | Centrally managed by the platform |
Phoenix places greater emphasis on transparency and decentralization, but it also depends more heavily on underlying network performance and smart contract security.
Phoenix manages risk in on-chain perpetual futures through a margin model, risk engine, funding rates, Oracle system, and forced liquidation mechanism. Because perpetual futures involve leverage and continuous volatility, the risk control system is essential to the protocol’s stable operation.
Compared with traditional centralized exchanges, Phoenix’s risk logic runs on-chain, and market states, position data, and liquidation records can all be publicly verified. This design improves transparency, but it also depends more heavily on the performance of the underlying blockchain and the stability of Oracle data.
The system may trigger liquidation when account equity falls below the maintenance margin requirement.
Yes. Phoenix’s risk checks, position updates, and liquidation logic all run on-chain.
Yes. Funding rates affect the holding costs of long and short positions and are used to help maintain market price balance.
Oracle provides market reference prices for risk assessment and liquidation decisions.
No. Risk control mechanisms can reduce risk, but they cannot fully eliminate losses caused by extreme market conditions.
Phoenix places greater emphasis on on-chain transparency and automatic rule execution, while centralized exchanges usually manage risk systems internally.





