What is Phoenix DEX?

Order BookSolana DEX

Last verified: May 2026

This page documents what Phoenix DEX is and how it works — based on official Phoenix documentation. Nothing here is financial advice. Always do your own research.

👋 New to this? Just start reading at the top — it begins in plain English and gets more detailed as you scroll. Jump to any level:

🟢 Start simple 🟡 A bit more detail 🟣 Full technical

🟢 The simple version

Plain English — no jargon. Start here.

One sentence that captures it

Phoenix is a fully on-chain central limit order book (CLOB) on Solana — unlike AMMs where prices are set by mathematical formulas, Phoenix allows market makers to post precise bid and ask prices at specific quantities, creating a professional-grade order book that is entirely on-chain and permissionlessly accessible.

AMM vs order book — the fundamental difference

Most Solana DEXes use AMMs (automated market makers) like Raydium and Orca — prices are set algorithmically based on the ratio of assets in a pool. AMMs are simple and always available but inefficient for professional market making: a market maker in an AMM provides liquidity at all prices from zero to infinity rather than precisely where they want to trade.

A central limit order book (CLOB) works like a traditional stock exchange: market makers post specific bids (prices they will buy at) and asks (prices they will sell at). A buy order is matched against the cheapest available ask. A sell order is matched against the highest available bid. This is how professional markets work — and how Binance, Coinbase, and NYSE operate.

Phoenix brings this model fully on-chain. Every order placement, cancellation, and fill is a Solana transaction. The order book state lives in Solana accounts. There is no off-chain matching engine, no custodial risk, and no centralised server that could go down.

Why a CLOB on Solana was not possible before

A fully on-chain CLOB requires: very fast block times (slow confirmations = stale orders), very low transaction fees (market makers cancel and replace orders constantly), and high throughput (many orders per second). Ethereum cannot support this — an on-chain CLOB on Ethereum would cost hundreds of dollars in gas per order. Solana's 400ms block times, sub-cent fees, and 65,000 TPS made Phoenix possible.

Is there a Phoenix token?

Phoenix launched as a public good protocol without a native governance token — it operates as open infrastructure. As of May 2026, there is no PHX token. Market makers and takers pay no protocol fees beyond Solana network fees.

Is it legal in India?

Yes. Trading on Phoenix using SOL/USDC is standard crypto trading — standard VDA tax rules apply. See India tax guide.

🟡 A bit more detail

For when you want to go a little deeper.

Phoenix's order book architecture

Phoenix uses a "page table" data structure to store order book state efficiently in Solana accounts. Each market (e.g., SOL/USDC) has a dedicated programme account storing all open orders. Orders are stored in a sorted structure (red-black tree for efficient insertion and lookup). When a new order arrives: if it matches an existing order (buy price ≥ best ask, or sell price ≤ best bid), it executes immediately (a "taker" trade). If it doesn't match, it rests on the book (a "maker" order) until cancelled or filled by a future taker.

What it's used for in real life

Phoenix serves professional market makers on Solana — trading firms that use Phoenix's precise order control to provide tighter spreads than AMMs. Jupiter aggregates Phoenix order book liquidity alongside AMM pools — when a Jupiter user swaps SOL for USDC, Jupiter's router checks if Phoenix has a better price than Raydium or Orca before routing. Phoenix's no-fee model (no protocol fees beyond Solana network fees) makes it cost-effective for high-frequency market makers who place and cancel thousands of orders per day. Several algorithmic trading firms have deployed market-making bots on Phoenix, improving price efficiency across Solana DeFi.

Cranking — the order execution model
Phoenix uses a "cranking" model for order settlement. When a taker order matches a maker order, the trade is recorded but not immediately settled — the tokens are not immediately transferred. Instead, "crankers" (anyone running a crank bot) periodically call the crank instruction, which processes pending trade settlements and transfers tokens to the correct accounts. This design amortises the settlement cost — multiple trades can be settled in one crank transaction. Crankers are incentivised by the Solana compute savings relative to settling each trade individually.

How people evaluate this
Key Phoenix metrics: daily volume, number of active market makers, bid-ask spread width (tight spreads = good liquidity), and orders per second (capacity utilisation). Phoenix competes with OpenBook (formerly Serum) as the on-chain order book layer for Solana. The key question: can a fully on-chain CLOB match the efficiency of off-chain order books in professional market making? Phoenix's adoption by serious market makers is evidence that the answer is increasingly yes. Live data: Phoenix.trade · Phoenix GitHub.

🟣 The full technical picture

For the technically curious.

Phoenix's seat system — permissioned market making

Phoenix uses a "seat" system for market makers. A seat is an on-chain account that gives its holder the right to post maker orders on Phoenix. Seats can be acquired freely (permissionless) by paying a small SOL deposit. The seat deposit is refundable — a market maker closing their seat recovers their deposit. This seat deposit serves as an anti-spam measure: it requires real capital commitment to participate as a market maker, preventing bots from spamming the order book with zero-cost fake orders. Takers (those executing against maker orders) do not need seats — anyone can take liquidity permissionlessly.

Source: Phoenix documentation. ellipsis-labs.gitbook.io/phoenix-dex · Phoenix GitHub: github.com/Ellipsis-Labs/phoenix-v1

Order types and self-trade prevention

Phoenix supports: limit orders (post at specific price, may rest on book), immediate-or-cancel orders (execute immediately or cancel remainder, never rest), fill-or-kill orders (must fill entirely immediately, else cancel entirely), and post-only orders (execute only as maker — cancel if it would immediately match). Self-trade prevention: Phoenix checks if the incoming order would match against an existing order from the same trader. If so, the matching is skipped and the order rests — preventing traders from accidentally executing against themselves (which would incur two-sided fees and no net position change).

Technical detail

Phoenix's page table uses a free list allocator for memory management within the order book account. The order book account has a fixed maximum size (set at market creation). New orders are allocated from the free list; cancelled or filled orders return their memory to the free list. This design gives O(1) order insertion and deletion — important for a high-frequency on-chain order book where thousands of orders may be processed per second. The red-black tree (sorted by price, then by time for equal prices — price-time priority) ensures O(log n) matching against the best available price. The combination of O(1) allocation and O(log n) matching makes Phoenix competitive with off-chain order books despite the on-chain overhead.

Key facts

Type: Fully on-chain CLOB (central limit order book)
Token: None (public good protocol, no protocol fees)
Market makers: Seat-based (refundable SOL deposit)
Settlement: Crank model (batched settlement)
Integration: Jupiter aggregates Phoenix liquidity
Developer: Ellipsis Labs
Order types: Limit, IOC, FOK, post-only

Explore related