As the DeFi market gradually expands from simple asset swaps into high frequency trading and professional derivatives, on-chain matching systems are becoming increasingly important. Phoenix’s on-chain matching process affects not only order execution efficiency, but also market liquidity, risk control, and trading costs.
Against the backdrop of the rapidly growing high frequency trading ecosystem on Solana, the on-chain order book model represented by Phoenix is once again becoming a key focus of the market.
Phoenix uses a Central Limit Order Book, or CLOB, model to complete trade matching. Buy and sell orders submitted by users enter the on-chain order book and are matched according to price priority and time priority.
Unlike the AMM model, Phoenix does not rely on liquidity pools for automatic pricing. Instead, market prices are formed through real limit orders. This means prices come from supply and demand between buyers and sellers, rather than from an algorithmic formula.
On Phoenix, order book data, order status, and trade records are all stored on-chain. Users can publicly view market depth, limit order prices, and trade history. This design improves market transparency and verifiability.
Because order book trading requires more frequent data updates and state synchronization, Phoenix places high demands on the performance of the underlying network. Solana’s high throughput and low latency allow it to support an on-chain real time matching system.
When a user submits an order on Phoenix, the system goes through several steps.
First, the user needs to sign the transaction request through their wallet. The order information includes the trade direction, price, quantity, leverage ratio, order type, and other details.
Next, Phoenix’s risk engine checks the account status, including:
Current margin balance
Position risk level
Leverage limits
Available margin ratio
Only when the account meets the risk requirements is the order allowed to enter the order book.
If the user submits a limit order, the order is placed on the order book and waits to be matched. If the user submits a market order, the system immediately attempts to execute it against existing orders in the market.
The entire order submission process takes place on-chain, so every order status can be publicly verified.
Phoenix’s matching logic follows the principles of price priority and time priority.
When a new buy order enters the market, the system looks for the lowest priced sell order to match against. Conversely, when a sell order enters the market, it is matched first with the highest priced buy order.
If multiple orders have the same price, the order that entered the order book earlier is executed first. This mechanism is basically the same as the order book logic used in traditional financial markets.
For example:
User A places a BTC long order
User B submits a BTC short order
When the two prices match, the system completes the trade
Both parties’ position status is then updated
Phoenix’s matching process does not rely on a centralized server. Instead, an on-chain program updates order states and confirms trades. This is one of the defining features of the Fully On-Chain model.
Perpetual futures trading involves leverage, so margin management is a key part of the matching process.
After an order is filled, Phoenix updates the user’s account information, including:
Position size
Entry price
Unrealized profit and loss
Margin used
Leverage ratio
The system continuously monitors the account’s risk level. When market price movements cause the account’s equity to decline, the maintenance margin ratio also changes.
If the account’s risk exceeds the safety threshold, Phoenix’s risk engine may trigger liquidation to help prevent bad debt risk for the protocol.
Because all position states are recorded on-chain, users can view account risk changes in real time.
Although Phoenix uses order book pricing, it still relies on oracles to provide market reference prices.
Oracle prices are mainly used to:
Calculate the mark price
Assess account risk
Determine liquidation conditions
Prevent abnormal price manipulation
If the system relied only on order book prices, the market could experience short term abnormal volatility when liquidity is insufficient. For this reason, Phoenix combines oracle data to maintain the stability of its risk system.
In the on-chain derivatives market, oracle systems are usually an important part of risk control. Oracle failures may affect funding rates, liquidation logic, and market stability, so Phoenix needs to rely on dependable data sources.
After an order is matched, the system writes the trade result into the on-chain state and updates the user’s position data.
On-chain settlement includes:
Updating account balances
Adjusting margin status
Recording trade information
Updating market open interest data
Because Phoenix uses a non-custodial structure, user assets are always controlled by on-chain accounts rather than held by a centralized platform.
This model improves transparency, but it also means all trading activity depends on blockchain network confirmation. As a result, the performance of the underlying network directly affects the trading experience.
Solana’s fast confirmation capability is one of the important reasons Phoenix can run an on-chain order book.
The biggest difference between Phoenix and traditional AMM protocols lies in how trades are executed.
The AMM model relies on liquidity pools and algorithmic pricing, meaning users effectively trade against a pool of funds. Phoenix’s order book model, by contrast, matches orders directly between users.
The two models differ clearly in trading process:
| Comparison Dimension | Phoenix | AMM Model |
|---|---|---|
| Trading structure | Order book matching | Liquidity pool |
| Price formation | Buy and sell limit orders | Algorithmic pricing |
| Slippage control | Relatively low | More noticeable for large trades |
| Market making method | Professional market makers | LPs provide liquidity |
| High frequency trading support | Stronger | Relatively limited |
| Order types | Limit orders, market orders | Usually fewer |
The order book model is generally better suited to professional trading and quantitative strategies, while AMMs are more suitable for basic asset swaps and open liquidity provision.
As high performance networks such as Solana continue to develop, more on-chain derivatives protocols are once again exploring order book architecture.
Phoenix’s on-chain matching process is not only about order execution efficiency. It also reflects a broader shift in DeFi market structure.
Early DeFi protocols placed more emphasis on open participation and permissionless liquidity. A new generation of on-chain derivatives protocols is now starting to focus on:
Lower latency
Higher capital efficiency
More professional trading experience
More precise order control
Phoenix’s Fully On-Chain Order Book model is, in effect, an attempt to bring the order book structure of traditional financial markets into a blockchain environment.
The development of such protocols also suggests that DeFi is gradually evolving from simple asset exchange tools into more complex on-chain financial infrastructure.
Phoenix uses a Fully On-Chain Order Book architecture to execute on-chain perpetual futures trades. Its matching process includes multiple stages, such as order submission, risk checks, order matching, position updates, and on-chain settlement.
Compared with the traditional AMM model, Phoenix places greater emphasis on order depth, price discovery efficiency, and high frequency trading capability. Built on Solana’s high performance network, Phoenix can run a matching system on-chain that is closer to those used by traditional exchanges.
As the DeFi market gradually expands into professional trading use cases, the on-chain order book model is once again attracting attention. Phoenix’s matching process not only reflects the development direction of on-chain derivatives protocols, but also shows how DeFi infrastructure is moving toward more complex financial market structures.
Yes. Phoenix uses a Fully On-Chain Order Book architecture, with both the order book and matching logic running on-chain.
Phoenix places greater emphasis on order depth, low slippage, and a professional trading experience, so it uses an order book model instead of a liquidity pool model.
Phoenix typically matches orders according to price priority and time priority.
No. Phoenix is a non-custodial protocol, and users manage their assets directly through their wallets.
Oracles are mainly used to provide reference prices, helping the system handle risk control and liquidation decisions.
Phoenix runs on Solana’s high performance network, which can provide lower latency and faster order confirmation.





