Skip to main content

Overview

solana.dex_swaps is a Turbo-only curated dataset that emits one normalized row per DEX swap across the major Solana AMMs and bonding-curve programs. Each row is a fully decoded swap event with the bought/sold token, amounts (both raw and decimal-scaled), the underlying program, and the transaction context needed to trace the swap back on-chain.
This dataset is exclusive to Turbo and is not available in Mirror.
Use it when you want to:
  • Track swap volume, prices, or flows across multiple Solana DEXes without decoding each program’s instructions yourself.
  • Attribute swaps to routers/aggregators (for example, Jupiter) versus direct DEX interactions.
  • Join raw and decimal-scaled amounts alongside the on-chain transaction signature and slot.

Quick start

Scope the source to the DEXes you care about with filter.program_ids (program IDs) and options.dex (human-readable labels). Both accept a comma-separated string.
See Solana Sources for general Solana source configuration (start_block, block_ranges, filters, checkpoints).

Supported DEXes and program IDs

The dataset currently decodes swap events from the following programs. The project column is the human-readable label (use in options.dex); project_main_id carries the raw on-chain program ID (use in filter.program_ids).

Schema

All amounts describe a single side of the trade: the bought token is what the trader received, the sold token is what they gave up.

Field notes

  • token_bought_* vs token_sold_* — direction is from the trader’s perspective. A row always has both sides populated; token_bought_amount and token_sold_amount are the decimal-scaled versions of the _raw integer amounts.
  • trade_source — distinguishes direct DEX interactions from router-routed ones. When a swap is an inner instruction of an aggregator, this holds the parent (router) program ID rather than direct.
  • trader_id — the payer/owner account attached to the swap instruction itself. For router-routed swaps this is typically the router-owned account that signed the inner instruction, not necessarily the end user that submitted the transaction. Use tx_id plus the outer transaction’s fee payer if you need the originating wallet.
  • project vs project_main_id — use project for human-readable filters and grouping; use project_main_id when you need the exact on-chain program ID.

Guide: Stream swaps from selected DEXes to Postgres

This pipeline streams Raydium CLMM and Orca Whirlpool swaps. filter.program_ids narrows the source at scan time; options.dex tells the decoder which DEX projects to emit.

Guide: Filter to a single DEX

Narrow both the source filter and the decoder options to a single DEX — here, Raydium CLMM:

Guide: Separate direct swaps from router-routed swaps

Aggregators like Jupiter invoke DEX programs as inner instructions. Use trade_source to split direct swaps from aggregator flow:

Guide: Track swaps involving a specific token

Filter by mint on either side of the trade — for example, all Raydium CLMM and Orca Whirlpool swaps involving USDC:
Keep filter.program_ids and options.dex in sync — filter.program_ids scopes which slots are scanned during backfills (see Filtering by Account or Program), and options.dex controls which decoded DEX projects are emitted. Listing a DEX in one but not the other will either scan more slots than needed or drop rows you expected.