Solana DEX Historical Data: Jupiter vs Raydium vs Meteora vs Orca vs PumpSwap

If you are looking for Solana DEX historical data, the first thing to understand is that there is no single, uniform kind of “Solana swap.”

A user may submit one swap through Jupiter. Jupiter can route it through one or more liquidity venues. Those venues might include a Raydium CPMM pool, a Meteora DLMM pool, an Orca Whirlpool or a PumpSwap pool. One wallet action can therefore appear in several valid records at different layers of the same transaction.

That is not duplicate data by itself. It becomes a data-quality problem only when you combine the layers without a clear definition of what you are counting.

This guide explains which historical Solana DEX data you need, how Jupiter, Raydium, Meteora, Orca and PumpSwap differ, and how to build reliable research and backtesting datasets without double counting routed swaps or mixing incompatible pool models.

#Quick answer: choose data by the question

The important distinction is this:

Aggregator data describes a user’s routing intent. Pool data describes execution on a specific venue.

Both are useful. They answer different questions.

#What is Solana DEX historical data?

Solana DEX historical data is a record of on-chain exchange activity and the state transitions behind it. Depending on the protocol and the analysis, it can include:

• swaps and routed swaps;
• pool creation and initialization;
• liquidity additions and removals;
• concentrated-liquidity positions;
• ticks, price ranges or liquidity bins;
• fee collection and rewards;
• pool reserve/account state;
• token mints and token-account transfers;
• transaction signatures, slots and instruction paths.

Trades are usually the first table researchers want. For many serious questions, they are not enough.

If you need to calculate historical DEX volume, trades may be sufficient once you choose a counting convention. If you need to estimate whether a hypothetical order could have executed at a quoted price, you need the historical liquidity distribution as well. If you need to understand why the route chose a venue, you need routing context and comparable pool state.

#The two layers of a Solana DEX swap

#Aggregator layer: Jupiter

Jupiter is routing infrastructure. Its current developer documentation describes a router path and a meta-aggregator path that can use multiple routing engines. A Jupiter swap record answers questions such as:

• Which wallet initiated the swap?
• What token did the user offer and receive?
• What was the final input and output amount?
• Which Jupiter instruction/version handled the route?
• When did the routed transaction execute?

This is normally the best layer for user-level flow: for example, “How much SOL did wallets swap into token X through Jupiter?”

It is not necessarily sufficient for venue-level market structure, because the economic execution may have crossed one or several underlying pools.

#Liquidity-venue layer: pools and swap legs

Raydium, Meteora, Orca and PumpSwap host or operate the liquidity mechanisms that a route can use. Their pool-level records answer questions such as:

• Which pool was touched?
• What were the input/output amounts in that pool?
• Which direction did the trade take?
• Which liquidity model determined the fill?
• What were the pool state and fees at the time?

This is the right layer for pool volume, liquidity, price impact and LP analysis.

#Why one user swap can produce several records

Imagine a wallet wants to exchange SOL for TOKEN.

Wallet → Jupiter route → Raydium pool leg → Meteora pool leg → TOKEN

The data may legitimately show:

1. one Jupiter-level user swap;
2. two pool-level swap legs;
3. several inner instructions and token transfers;
4. fee movements associated with the route and/or pools.

If you sum the notional value of the Jupiter row and both pool legs as if they are independent market trades, you overstate activity. If you use only the Jupiter row, you lose the venue allocation and may not have enough state to model pool-level execution.

There is no universally correct row count. There is only a correct definition for the metric you are computing.

#Jupiter historical data: best for routed user flow

Jupiter is often the answer to “How did the user swap?” rather than “Which AMM made the market?”

Jupiter’s official Swap API explains that its router can return raw swap instructions and that its meta-aggregator selects across routing engines. That architecture is why aggregator data is useful for user-level analysis and why a Jupiter transaction may touch multiple programs.

For a historical Jupiter swap dataset, look for:

• user wallet;
• input and output token mints;
• input and output amounts;
• signature, slot and deterministic instruction path;
• route or underlying venue information, if available;
• success/failure status;
• precise timestamp/event-order fields.

Use Jupiter data when you are studying:

• retail or bot token flow;
• aggregator adoption;
• user-level token demand;
• route selection;
• the final execution received by a wallet;
• strategy signals based on routed buy/sell behaviour.

Do not use Jupiter data alone to calculate the liquidity, volume or price impact of every underlying venue unless it is explicitly enriched with route-leg information.

#Raydium historical data: identify the program first

“Raydium data” is not one homogeneous dataset.

Raydium’s official documentation distinguishes multiple AMM programs, including AMM v4, CPMM and CLMM. It also notes that these AMM programs are peers: a direct swap on one pool touches one AMM program, while Raydium’s routing program can compose several pool types in one transaction.

That matters because each model has different state and different analytical requirements.

Raydium's current documentation says CPMM is the recommended default for most new permissionless pools and supports Token-2022, while AMM v4 remains for existing pools/positions. Do not rewrite old history to look like a single current protocol version.

For Raydium research, keep the program type in every normalized row. A unified dex_swaps view can be useful, but it should preserve the source protocol and its native pool state rather than discarding it.

#Meteora historical data: bins and dynamic liquidity

Meteora is also not a single pool model. Its DLMM is a concentrated-liquidity design built around bins, with dynamic liquidity and fee concepts. Historical swap data from a DLMM needs more context than a simple token-in/token-out row if you are studying execution or LP behaviour.

Useful fields may include:

• pool address and token mints;
• active bin/price information;
• bin step or price granularity;
• swap direction and amounts;
• liquidity across relevant bins;
• dynamic fee state;
• liquidity-position activity;
• fee/reward collection.

For a small retrospective volume chart, swaps may be enough. For slippage simulation, bin occupancy and ordering become central. A trade that crosses many bins can experience different effective pricing from one that remains within the active bin.

Meteora’s official developer documentation describes DLMM as its concentrated-liquidity product and points developers to the published IDL, TypeScript SDK, on-chain accounts and data API. Treat the bin state as first-class data rather than flattening it into an ordinary constant-product reserve ratio.

#Orca historical data: Whirlpools and tick-based liquidity

Orca Whirlpools is a concentrated-liquidity AMM (CLMM). Liquidity providers choose ranges, so liquidity can be dense around the current price and absent away from it.

For historical analysis, that means:

• a pool’s total liquidity is not the same as executable depth at every price;
• a swap can cross one or more ticks;
• a position may be in range at one time and out of range later;
• estimating slippage needs historical tick and liquidity information, not just candles.

Orca’s Whirlpools documentation identifies it as an open-source concentrated-liquidity AMM on Solana. If you are measuring volume or wallet flow, normalized swap data may be sufficient. If you are measuring LP performance, market depth or hypothetical execution, retain tick/range and liquidity-position data.

#PumpSwap historical data: the post-graduation venue

PumpSwap deserves its own category because it is also the continuation of a common token lifecycle.

Pump.fun tokens begin on a bonding curve. Once a curve reaches completion, liquidity is migrated to PumpSwap. Pump.fun states that this move is automatic and irreversible.

For a Pump.fun token, the accurate historical sequence is therefore:

Pump.fun creation
→ Pump.fun bonding-curve trading
→ curve completion
→ PumpSwap migration
→ PumpSwap AMM trading

If you want a complete price or wallet-activity study, you need a join between Pump.fun and PumpSwap datasets. The migration record should map the mint to the PumpSwap pool; do not guess the pool from token symbols or current listings.

The datastore.sh Pump.fun Swaps dataset provides decoded PumpSwap instructions and events as analytics-ready Parquet. Pair it with the Pump.fun historical dataset when analysing the full pre- and post-graduation lifecycle.

#Which Solana DEX is “best” for historical data?

The answer depends on the research unit—not which protocol is better.

It is often right to use more than one dataset. What matters is that every joined row has a stated role: user intent, route leg, pool state, liquidity action or token transfer.

#How to build a Solana DEX dataset without double counting

#1. Define the unit before you ingest

Write down what one row represents:

• one user swap;
• one routed transaction;
• one underlying pool leg;
• one pool state update;
• one liquidity action;
• one economic token movement.

Without this definition, a data warehouse can produce a plausible but wrong volume number.

#2. Retain native identifiers

Keep these fields even when you create a normalized view:

• transaction signature;
• slot/block time;
• transaction index, where available;
• instruction index/path;
• program ID and decoded instruction name;
• pool address;
• aggregator/route ID where available;
• source table/schema version.

The signature alone is often not a unique business key. One transaction can contain several meaningful swaps, route legs or events.

#3. Keep aggregator and pool records separate first

Create separate raw or staging models:

jupiter_user_swaps
raydium_pool_swaps
meteora_pool_swaps
orca_pool_swaps
pumpswap_pool_swaps

Only then build a purpose-specific mart such as user_swap_volume_daily or pool_leg_volume_daily.

#4. Make route-leg joins explicit

Join an aggregator swap to pool legs only when the available keys and execution structure support the association. Do not claim a perfect one-to-one match merely because rows share a timestamp or token mint.

For each joined route, record whether the attribution is:

• exact from transaction/instruction lineage;
• a deterministic inference from chain structure;
• unresolved.

#5. Preserve source-specific decimals and fees

Store raw integer amounts and token-decimal metadata alongside correctly scaled analytical columns. A final output amount may be net of fees while individual pool legs have their own fee model. Clearly choose gross or net quantities before aggregating volume.

#A practical normalized swap model

For cross-DEX analysis, a normalized table might look like this:

event_time
slot
signature
instruction_path
source_protocol
source_program
pool_address
swap_layer                 -- aggregator or pool_leg
wallet
input_mint
output_mint
input_amount_raw
output_amount_raw
input_amount_decimal
output_amount_decimal
fee_amount_raw
route_parent_signature     -- nullable
schema_version

This design allows you to keep protocols comparable without pretending they use the same execution model.

For a Raydium CLMM, Meteora DLMM or Orca Whirlpool, store associated state in companion tables instead of cramming bins, ticks and positions into one generic swap row.

#Example: daily user-facing volume versus pool-leg volume

The following DuckDB-style SQL intentionally produces two different metrics. Neither should be called simply “Solana DEX volume” without its definition.

-- User-facing volume: each Jupiter routed swap counted once.
SELECT
  DATE_TRUNC('day', event_time) AS day,
  SUM(input_amount_usd) AS routed_input_volume_usd
FROM jupiter_user_swaps
WHERE success = TRUE
GROUP BY 1
ORDER BY 1;

-- Venue activity: every underlying pool execution leg counted.
SELECT
  DATE_TRUNC('day', event_time) AS day,
  source_protocol,
  SUM(input_amount_usd) AS pool_leg_input_volume_usd
FROM normalized_pool_swaps
WHERE success = TRUE
GROUP BY 1, 2
ORDER BY 1, 2;

Do not add the two result sets together. They describe different layers of the same market activity.

#Solana DEX data for backtesting

Candles and completed swaps are a weak basis for execution-quality backtesting.

Suppose a strategy fires at 12:00:00 and wants to sell $50,000 of a token. A last-traded price says little about whether $50,000 could execute at that price. The answer depends on the liquidity mechanism:

• CPMM/constant-product pools: reserves, fees and the invariant drive price impact.
• CLMM/Whirlpools: liquidity at ticks near the price drives the fill.
• DLMM: active-bin and adjacent-bin liquidity drives the fill.
• Routed swaps: execution can be split across venues and route legs.

A causal historical backtest must:

1. build features only from data available at or before the decision event;
2. select a venue/route using only state available then;
3. model fees and conservative price impact;
4. order concurrent events deterministically;
5. avoid using later liquidity, later route results or future token labels;
6. state whether results assume immediate execution, latency or partial fills.

The final route observed on chain is useful for analysing what happened. It is not automatically a route your strategy could have known or reproduced before sending its own transaction.

#Common Solana DEX data mistakes

#Mistake 1: Calling Jupiter and Raydium competitors in the dataset

They are often different layers of one execution. Jupiter can route a user action through Raydium and other venues.

#Mistake 2: Counting a routed trade and its legs as independent volume

Choose either the user-facing swap or the pool-leg model for the metric. Keep the other as supporting detail.

#Mistake 3: Treating all Raydium pools as one protocol version

AMM v4, CPMM and CLMM have different mechanics and analytical state.

#Mistake 4: Simulating concentrated liquidity from closing prices

Tick/bin state and liquidity distribution matter for price impact.

#Mistake 5: Guessing a PumpSwap pool from current information

Use the historical Pump.fun migration record to establish the lifecycle mapping.

#Mistake 6: Joining only on timestamp or mint

Use transaction and instruction lineage wherever possible. Multiple actions can share the same timestamp and token.

#Mistake 7: Erasing raw units

Floating-point rounding and missing decimal metadata can corrupt financial aggregates. Preserve raw integer amounts and decimals.

#Where can you get Solana DEX historical data?

There are three broad approaches.

Build from raw Solana data if you need a custom universal indexer and are prepared to decode every relevant program, event and state transition.

Use APIs/RPC for current state, narrow queries or application requests.

Use prepared bulk datasets when you need to scan large historical ranges, train models, run repeated backtests or retain reproducible inputs in your own warehouse.

datastore.sh provides historical Solana data as typed, versioned Parquet files. Its catalog includes decoded datasets for Jupiter Swap, Raydium AMM v4, Raydium CPMM, Raydium CLMM, Meteora DLMM, Orca Whirlpool, Pump.fun and PumpSwap. Each protocol should still be assessed at the table and coverage-window level before it is used in analysis.

#Frequently asked questions

#Where can I get Solana DEX historical data?

You can decode it from raw Solana transactions, query a data API for limited use cases, or obtain protocol-decoded bulk datasets. The best route depends on whether you need a few recent records, a custom indexer or repeated large-scale analysis.

#Is Jupiter data the same as Raydium data?

No. Jupiter represents routing/user-swap activity, while Raydium represents pool-level execution and liquidity activity. A Jupiter route can include a Raydium pool leg.

#How do I calculate Solana DEX volume correctly?

First define whether you mean user-facing routed volume or venue-level pool-leg volume. Do not sum both layers together. Use deterministic keys and a documented deduplication/attribution policy.

#Can I backtest with Solana DEX swap data?

Yes, but trade records alone are rarely sufficient for execution-quality backtests. Add the historical pool state appropriate to the liquidity model, fees, event ordering and a realistic latency/slippage model.

#What is the difference between a CLMM and a DLMM?

Both concentrate liquidity around selected prices, but they expose it through different pool models and state structures. For historical research, that means their execution and liquidity data should remain protocol-native rather than forced into the same simplistic reserve model.

#How do I follow a Pump.fun token after graduation?

Join Pump.fun creation, curve-trade and migration records to the PumpSwap pool identified by the historical migration data. Then continue the study with PumpSwap trades and pool activity.

#The key takeaway

There is no single “best Solana DEX dataset.” There are several useful layers of data.

Use Jupiter to understand user-facing routed flow. Use Raydium, Meteora, Orca and PumpSwap records to understand what happened inside specific liquidity venues. Preserve their native state models. Then build a normalized view only after you have declared the unit your metric represents.

That is how you avoid turning valid on-chain records into misleading volumes, backtests or wallet labels.

Explore historical Solana datasets on datastore.sh to inspect the available protocol schemas and choose the records your analysis actually needs.