Every fill and market state change on Phoenix V1, Solana's on-chain central limit order book, decoded and USD-priced at block time.
Coverage
Full historyto Sep 23, 2026 · yesterday
Tables
2Parquet, one prefix each
Columns
146across 2 tables
Coverage ends yesterday, UTC
Overview
Complete historical record of the Phoenix V1 program (PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY) on Solana: every fill and every market state change, at slot resolution.
Phoenix is a central limit order book, not an automated market maker. Rows in the trades table are matched orders rather than swaps against a bonding curve, and rows in the market table record the state of a market after an event rather than constant-product reserves. The schema is the same one used across every Solana DEX dataset here, so Phoenix joins directly against the others on mint address, market address, slot or signature.
Use cases
Order-book microstructure research on an established Solana CLOB
Execution quality and spread analysis against AMM venues
Market-maker behaviour and fill attribution
Cross-venue routing research where an aggregator settles into Phoenix
2 tables
146 columns · free sample for each table
phoenix_trades
82 columns
One row per fill matched on a Phoenix market, with buy and sell sides, token metadata and USD pricing.
datashare/solana/phoenix/dex_trades<start_slot>_<end_slot>.parquet100 slots per file
phoenix_pools64 columnsOne row per Phoenix market state change, with the change amount and the resulting balance for both sides, USD-valued at block time.
ColumnTypeDescription
Block3
Block_DateDateUTC date of the block
Block_SlotUInt64Solana slot
Block_TimeDateTimeBlock timestamp, UTC
Instruction7
Instruction_CallPathArrayNested call path of the instruction
Instruction_ExternalSeqNumberUInt64Sequence number of the outer instruction
Instruction_IndexUInt64Position of the instruction within the transaction
Instruction_InternalSeqNumberUInt64Sequence number of the inner instruction
Instruction_Program_AddressStringProgram that executed the instruction
Instruction_Program_MethodStringDecoded program method
Instruction_Program_NameStringDecoded program name
Pool_BaseCurrency6
Pool_BaseCurrency_ChangeAmountDecimalBase-token amount added to or removed from the market by this event, decimal adjusted
Pool_BaseCurrency_ChangeAmountInUSDFloat64Base-token change valued in USD at block time
Pool_BaseCurrency_PostAmountDecimalBase-token market balance after the event, decimal adjusted
Pool_BaseCurrency_PostAmountInUSDFloat64Base-token balance after the event, valued in USD at block time
Pool_BaseCurrency_PriceFloat64Base-token price in quote-token units after the event
Pool_BaseCurrency_PriceInUSDFloat64Base-token price in USD at block time
Pool_Dex3
Pool_Dex_ProgramAddressStringPhoenix V1 program address (PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY)
Send this dataset’s full schema to an assistant and ask it anything. It reads the plain-text brief ↗ first, so the answer comes from the real column list rather than a guess.
Two Parquet tables: phoenix_trades and phoenix_pools, with 146 documented columns. Full history to yesterday, refreshed daily.
Phoenix is an order book. Why is the second table called pools?
For schema consistency. Every Solana DEX dataset here uses the same two-table shape, so the second table keeps the pools name and the Pool_ column prefixes. On Phoenix those columns describe market state after an event — base and quote balances and prices — rather than AMM reserves. Read them as market state, not as a constant-product curve.
Why are there more market events than fills?
Because an order book changes state without trading. Placing, modifying and cancelling orders all move a market's recorded state, while only a match produces a fill. In a quiet 100-slot window we measured 2 fills against 17 market events; in a busy one, 39 fills against 41. Neither is missing data — it is the ratio of quoting activity to actual trading, and it is itself a useful signal.
How do fills differ from AMM swaps?
A fill is a match between two resting or incoming orders at a price the book determined, not a price a curve determined. That makes Phoenix useful for spread, depth and execution-quality work that AMM data cannot answer, and it is why price columns here should be compared with AMM venues carefully rather than pooled together.
How does this compare to the Manifest dataset?
Both are Solana central limit order books with the same schema. Holding both lets you compare quoting behaviour, spreads and fill rates across the two books over the same tokens and time windows.
How is the data delivered?
As flat Parquet files under a stable S3 layout, one prefix per table, with a JSON manifest listing every file and its sha256. Signed HTTPS links are emailed to you once the files are prepared.
How current is the data?
Refreshed daily with T+1 latency. A purchase made today includes everything up to yesterday.
Can I try before I buy?
Yes. Every table links to a public sample file with real records, and the sample bucket holds full Parquet files you can load directly. No email address required.