Every fill and market state change on Manifest, 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 Manifest program (MNFSTqtC93rEfYHB6hF82sKdZpUDFWkViLByLd1k1Ms) on Solana: every fill and every market state change, at slot resolution.
Manifest 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 Manifest joins directly against the others on mint address, market address, slot or signature.
Use cases
Order-book microstructure research on a native 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 Manifest
2 tables
146 columns · free sample for each table
manifest_trades
82 columns
One row per fill matched on a Manifest market, with buy and sell sides, token metadata and USD pricing.
datashare/solana/manifest/dex_trades<start_slot>_<end_slot>.parquet100 slots per file
manifest_pools64 columnsOne row per Manifest 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_ProgramAddressStringManifest program address (MNFSTqtC93rEfYHB6hF82sKdZpUDFWkViLByLd1k1Ms)
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: manifest_trades and manifest_pools, with 146 documented columns. Full history to yesterday, refreshed daily.
Manifest 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 Manifest 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.
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 Manifest 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.
Why do the two tables track each other so closely?
Every fill changes the market's balances, so trades and market events arrive one for one over a given slot range. Join the two tables on slot and signature to read the fill price alongside the market state it produced.
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.