As the on-chain derivatives market continues to expand, more traders are looking for DeFi trading protocols that can balance execution efficiency with self-custody of assets. Phoenix emerged in this context as a high performance on-chain trading infrastructure.
Compared with traditional derivatives protocols that rely on automated market makers, or AMMs, Phoenix places greater emphasis on low slippage, high frequency trading, and order depth management. Its architecture is closer to the matching systems used by centralized exchanges in traditional financial markets. As demand grows for on-chain quantitative trading, professional market making, and high frequency strategies, the on-chain order book model represented by Phoenix is gradually regaining market attention.
Early decentralized trading markets were mainly dominated by the AMM model. AMMs use liquidity pools to complete asset swaps, lowering the barrier to on-chain market making, but they also bring issues such as slippage, lower capital efficiency, and limited price discovery. As DeFi expanded into perpetual futures and more professional trading use cases, the traditional AMM model gradually became less able to meet the needs of high frequency trading and complex order management.
At the same time, centralized exchanges have long dominated the perpetual futures market. Their core advantage comes from high performance order books and real time matching. However, centralized platforms usually require users to custody assets with the platform and rely on the platform itself to maintain order and liquidation systems.
Phoenix aims to rebuild the order book trading experience in an on-chain environment. With the high throughput and low transaction costs of Solana, Phoenix deploys order matching, risk checks, and market state maintenance on-chain, aiming to achieve execution efficiency closer to that of centralized exchanges while preserving transparency and verifiability.
Phoenix is an on-chain perpetual futures trading protocol built on Solana. It uses a Fully On-Chain Central Limit Order Book architecture. Users can connect to the protocol directly through their wallets and trade without handing custody of their assets to a centralized platform.
Phoenix’s core features include on-chain order book matching, non-custodial asset management, high frequency trading support, and an order experience closer to that of traditional exchanges. Compared with traditional AMM based perpetual futures protocols, Phoenix places more emphasis on order depth and price discovery efficiency.
Phoenix’s trading process mainly includes order submission, risk checks, matching execution, and on-chain settlement.
After a user submits an order, the protocol first checks the account’s margin and risk parameters to confirm whether the account meets the requirements for opening a position. The order then enters the on-chain order book and is matched against other buy and sell orders based on price.
When the prices of the buyer and seller match, the system executes the trade and updates both parties’ position status. The entire process is recorded on-chain, and all trading states can be publicly verified.
Phoenix uses a central limit order book, or CLOB, model, so traders can use order types closer to those on traditional exchanges, such as limit orders and market orders, rather than relying only on automatic pricing from liquidity pools.
In the perpetual futures market, the funding rate mechanism is also important. When the perpetual futures price is higher than the spot price, longs usually pay funding to shorts; when the opposite happens, shorts typically pay longs. This mechanism is used to help keep market prices balanced.
Phoenix’s technical structure is built on Solana’s high performance network. Its core components include:
Phoenix uses a Fully On-Chain Order Book model to store market order states. All limit orders, cancellations, and trade information are recorded on-chain rather than maintained by a centralized server.
This design improves transparency, but it also places higher demands on the underlying blockchain’s performance. Solana’s low latency and high throughput allow Phoenix to run an order book trading system in an on-chain environment.
The matching engine is responsible for matching buy and sell orders and updating market states. Unlike traditional centralized exchanges, Phoenix’s matching logic runs within an on-chain program.
The risk engine is responsible for checking account margin, maintenance margin ratios, and position risk levels. When an account’s risk exceeds the limit, the system may trigger forced liquidation.
Phoenix relies on external oracles to provide market reference prices, helping prevent market manipulation and abnormal price movements from affecting liquidation logic.
The biggest difference between Phoenix and traditional AMM based perpetual futures protocols lies in market structure.
AMM protocols mainly rely on liquidity pools to execute trades, with prices calculated automatically by algorithms. When large orders enter the market, they often create noticeable slippage.
Phoenix uses an order book model instead. Trading prices are formed by buy and sell limit orders, which is closer to the price discovery mechanism used in traditional financial markets.
The two models also create clearly different trading experiences:
| Comparison Dimension | Phoenix | AMM Based Perpetual Futures Protocols |
|---|---|---|
| Market structure | On-chain order book | Liquidity pool |
| Price formation | Matching buy and sell orders | Algorithmic pricing |
| Slippage control | Relatively low | More noticeable for large trades |
| High frequency trading support | Stronger | Relatively limited |
| Market making method | Professional market makers | LPs provide liquidity |
| Order types | Limit orders, market orders, and others | Usually fewer |
Both Phoenix and Drift are built on Solana’s high performance network. Solana’s high throughput and low fee structure allow it to support complex on-chain trading systems.
By comparison, Phoenix and Drift use different market structures and liquidity models.
In addition, Phoenix and Hyperliquid are both important protocols in the on-chain perpetual futures trading sector, but they follow different technical paths and market structures.
On-chain perpetual futures trading involves leverage, so risk control is a key part of Phoenix’s architecture.
Users need to provide initial margin when opening a position. If market volatility causes the account’s equity to fall below the maintenance margin requirement, the system may trigger liquidation. Phoenix will automatically close part or all of the position to help prevent bad debt risk for the protocol.
In addition, Phoenix’s risk system relies on oracles for market price data, so oracle stability also affects the protocol’s overall operational security. Because perpetual futures are inherently highly leveraged instruments, significant market risk can still occur during extreme conditions. Traders should fully understand liquidation rules and leverage mechanisms before participating in on-chain derivatives trading.
Phoenix’s main use cases include professional on-chain trading, high frequency market making, and DeFi trading infrastructure.
For regular traders, Phoenix provides a way to participate in the perpetual futures market without giving up custody of their assets. Users can trade directly through their wallets while retaining control over their funds.
For market makers and quantitative teams, Phoenix’s order book structure is better suited to high frequency strategy deployment. Compared with AMMs, order books can provide more precise price control and liquidity management.
At the same time, Phoenix can also serve as an infrastructure component within the Solana DeFi ecosystem, combining with aggregators, strategy protocols, and other financial applications. This composability is also one of the important features of DeFi protocols.
Phoenix’s main advantages come from its on-chain order book architecture and Solana’s network performance. Compared with traditional AMM based protocols, its trading experience is closer to that of centralized exchanges, while offering lower slippage and higher order precision.
At the same time, Phoenix still preserves the core features of DeFi, including non-custodial asset management, on-chain transparency, and open financial composability. This allows it to serve regular traders while also supporting professional quantitative teams and market makers.
However, Phoenix also has certain limitations. Order book markets require continuous liquidity support, while high frequency trading ecosystems place high demands on network stability. In addition, the on-chain derivatives market itself still faces systemic risk, oracle risk, and volatility pressure during extreme market conditions.
As an on-chain perpetual futures trading protocol in the Solana ecosystem, Phoenix uses a Fully On-Chain Order Book architecture to provide users with a non-custodial leveraged trading experience. Compared with traditional AMM based derivatives protocols, Phoenix places greater emphasis on order book depth, price discovery efficiency, and high frequency trading capability.
Still, the on-chain derivatives market remains a high risk area. Before participating in leveraged trading, users need to fully understand margin mechanisms, funding rates, and liquidation risks.
No. Phoenix is a decentralized perpetual futures trading protocol. Users connect to the protocol directly through their wallets, and their assets do not need to be custodied by a centralized platform.
Phoenix mainly uses an on-chain order book, or CLOB, model rather than a traditional AMM liquidity pool structure.
Solana offers high throughput, low latency, and low transaction costs, making it better suited to running on-chain order books and high frequency matching systems.
Phoenix supports perpetual futures, leveraged trading, limit orders, market orders, margin trading, and other related features.
The funding rate is used to help maintain balance between perpetual futures prices and spot market prices.
Yes. Because perpetual futures involve leverage, the system may trigger forced liquidation when an account does not have enough margin.
Phoenix places more emphasis on order book matching and professional trading structures, while most traditional DEXs use AMM liquidity pool models.





