Fact Swaps Jupiter Summary

​

Description

​

Key Use Cases

• Analyze the intended swap activity (initial in and final out amount)
• Information on user-initiated swaps on Jupiter
• Compare swap activity between DEXes at the start and end of the route

​

Important Relationships

• Use with defi.fact_swaps_jupiter_inner for full route details
• Use with defi.fact_swaps and defi.ez_dex_swaps for comparison with direct swaps
• Example queries: number of buy and sell swaps for a token on Jupiter, compare routed vs. direct swap volume

​

Commonly-used Fields

• block_timestamp, swapper, swap_from_mint, swap_to_mint, swap_from_amount, swap_to_amount, is_dca_swap, is_limit_swap

​

Sample Queries

​

User-initiated buy/sell analysis for Jupiter swaps

-- Number of buy and sell swaps for JTO token on Jupiter
WITH sells AS (
    SELECT
        block_timestamp::date AS dt,
        SUM(swap_from_amount) AS sum_sells,
        COUNT(DISTINCT swapper) AS unique_sellers
    FROM solana.defi.fact_swaps_jupiter_summary
    WHERE swap_from_mint = 'jtojtomepa8beP8AuQc6eXt5FriJwfFMwQx2v2f9mCL'
        AND block_timestamp::date BETWEEN '2025-01-01' AND '2025-01-07'
    GROUP BY 1
),
buys AS (
    SELECT
        block_timestamp::date AS dt,
        SUM(swap_to_amount) AS sum_buys,
        COUNT(DISTINCT swapper) AS unique_buyers
    FROM solana.defi.fact_swaps_jupiter_summary
    WHERE swap_to_mint = 'jtojtomepa8beP8AuQc6eXt5FriJwfFMwQx2v2f9mCL'
        AND block_timestamp::date BETWEEN '2025-01-01' AND '2025-01-07'
    GROUP BY 1
)
SELECT
    COALESCE(s.dt, b.dt) AS dt,
    COALESCE(s.sum_sells, 0) AS sell_volume,
    COALESCE(s.unique_sellers, 0) AS unique_sellers,
    COALESCE(b.sum_buys, 0) AS buy_volume,
    COALESCE(b.unique_buyers, 0) AS unique_buyers
FROM sells s
FULL OUTER JOIN buys b ON s.dt = b.dt
ORDER BY dt;

​

Jupiter DCA and limit order analysis

-- Analyze special Jupiter features usage
SELECT
    block_timestamp::date AS dt,
    COUNT(*) AS total_jupiter_swaps,
    COUNT(CASE WHEN is_dca_swap THEN 1 END) AS dca_swaps,
    COUNT(CASE WHEN is_limit_swap THEN 1 END) AS limit_swaps,
    COUNT(CASE WHEN NOT is_dca_swap AND NOT is_limit_swap THEN 1 END) AS regular_swaps,
    COUNT(CASE WHEN is_dca_swap THEN 1 END) * 100.0 / COUNT(*) AS dca_percentage,
    COUNT(CASE WHEN is_limit_swap THEN 1 END) * 100.0 / COUNT(*) AS limit_percentage
FROM solana.defi.fact_swaps_jupiter_summary
WHERE block_timestamp >= CURRENT_DATE - 30
GROUP BY 1
ORDER BY dt;

​

Jupiter user behavior and intent analysis

-- Analyze intended swap activity and user patterns on Jupiter
SELECT
    COUNT(DISTINCT swapper) AS unique_users,
    COUNT(*) AS total_swaps,
    AVG(swap_from_amount) AS avg_input_amount,
    AVG(swap_to_amount) AS avg_output_amount,
    COUNT(*) / COUNT(DISTINCT swapper) AS avg_swaps_per_user,
    COUNT(DISTINCT swap_from_mint) AS unique_input_tokens,
    COUNT(DISTINCT swap_to_mint) AS unique_output_tokens
FROM solana.defi.fact_swaps_jupiter_summary
WHERE block_timestamp >= CURRENT_DATE - 7
    AND succeeded = true;

​

Compare Jupiter vs all DEX activity

-- Compare Jupiter summary volume vs total DEX volume
WITH jupiter_volume AS (
    SELECT
        block_timestamp::date AS dt,
        SUM(swap_from_amount) AS jupiter_volume,
        COUNT(*) AS jupiter_swaps,
        COUNT(DISTINCT swapper) AS jupiter_users
    FROM solana.defi.fact_swaps_jupiter_summary
    WHERE block_timestamp::date BETWEEN '2025-01-01' AND '2025-01-07'
    GROUP BY 1
),
total_dex_volume AS (
    SELECT
        block_timestamp::date AS dt,
        SUM(swap_from_amount) AS total_dex_volume,
        COUNT(*) AS total_swaps,
        COUNT(DISTINCT swapper) AS total_users
    FROM solana.defi.fact_swaps
    WHERE block_timestamp::date BETWEEN '2025-01-01' AND '2025-01-07'
    GROUP BY 1
)
SELECT
    j.dt,
    j.jupiter_volume,
    t.total_dex_volume,
    j.jupiter_volume * 100.0 / t.total_dex_volume AS jupiter_market_share_pct,
    j.jupiter_swaps,
    t.total_swaps,
    j.jupiter_users,
    t.total_users
FROM jupiter_volume j
JOIN total_dex_volume t ON j.dt = t.dt
ORDER BY j.dt;

​

Columns

• 123456789

• Supports block-level analytics, such as block production rate and transaction throughput.
• Useful for tracing transaction inclusion and block explorer integrations.

• All transactions with the same ‘block_id’ share the same ‘block_timestamp’. | | TX_ID | TEXT | The unique transaction signature (hash) for each transaction on the Solana blockchain. This field is a base58-encoded string, typically 88 characters in length, and serves as the primary identifier for transactions across all Solana data models. Used to join transaction data with related tables (blocks, events, transfers, logs, decoded instructions) and to trace the full lifecycle and effects of a transaction. Essential for transaction-level analytics, debugging, and cross-referencing with block explorers or Solana APIs.

• 5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw

• Enables precise tracking, auditing, and attribution of on-chain activity
• Used for linking transactions to events, logs, and protocol actions
• Critical for compliance, monitoring, and analytics workflows | | INDEX | NUMBER | The position of the event (instruction) within the list of instructions for a given Solana transaction. Used to order and reference events within a transaction. Indexing starts at 0 for the first event.

• 0
• 3

• Enables precise identification and ordering of events within a transaction, which is critical for reconstructing transaction flows and analyzing protocol behavior.
• Used to join or filter event-level data, especially when multiple events occur in a single transaction. | | INNER_INDEX | NUMBER | The position of the inner instruction or event within the list of inner instructions for a given Solana transaction. Used to order and reference nested (CPI) instructions. Indexing starts at 0 for the first inner instruction.

• 0
• 2

• Enables precise identification and ordering of nested program calls (Cross-Program Invocations) within a transaction.
• Critical for analyzing composability, protocol integrations, and the full execution path of complex transactions. | | SWAP_INDEX | NUMBER | The order in which the intermediate swap was executed within a routed transaction (e.g., Jupiter aggregator route). Used to reconstruct the full path of multi-hop swaps.
• Data type: INTEGER (0-based index)
• Business context: Enables step-by-step analysis of routed swaps, DEX path optimization, and route efficiency studies.
• Analytics use cases: Route reconstruction, DEX path analysis, and aggregator performance benchmarking.
• Example: In a 3-hop Jupiter route, swaps will have indices 0, 1, and 2. | | SUCCEEDED | BOOLEAN | Boolean flag indicating whether the transaction was successfully executed and confirmed on the Solana blockchain. A value of TRUE means the transaction was processed without errors; FALSE indicates failure due to program errors, insufficient funds, or other issues.

• true
• false

• Used to filter for successful transactions in analytics and reporting.
• Important for error analysis, user experience, and program debugging. | | SWAPPER | TEXT | The Solana address (base58-encoded string) that initiated the swap transaction. This field identifies the user or contract responsible for the swap, enabling wallet-level analytics, behavioral segmentation, and user journey analysis.
• Data type: STRING (base58 Solana address, e.g., 4Nd1mYw4r...)
• Business context: Used to group swaps by user, analyze trading patterns, and track protocol adoption.
• Analytics use cases: User segmentation, whale tracking, protocol adoption analysis, and cross-table joins with other user-activity models.
• Example: 4Nd1mYw4r... | | SWAP_FROM_MINT | TEXT | The mint address of the token being sent or swapped from in the transaction. This is a unique identifier for the SPL token or SOL.
• Data type: STRING (base58 Solana mint address)
• Business context: Used to identify the source asset in the swap, filter by token, and analyze token-specific activity.
• Analytics use cases: Token flow analysis, asset popularity studies, and cross-token comparisons.
• Example: SOL: So11111111111111111111111111111111111111112, USDC: Es9vMFrzaCER... | | SWAP_FROM_AMOUNT | FLOAT | The total amount of the token sent in to initiate the swap, as recorded on-chain. This value is already decimal adjusted according to the token’s standard decimals, and represents the human-readable amount.
• Data type: NUMBER (float or integer, depending on token)
• Business context: Used to calculate swap volume, analyze liquidity flows, and measure user activity.
• Analytics use cases: Volume analysis, liquidity tracking, slippage calculations, and DEX protocol comparisons.
• Example: For SOL, a value of 2.5 means 2.5 SOL. For USDC, a value of 100.5 means 100.5 USDC. | | SWAP_TO_MINT | TEXT | The mint address of the token being received or swapped to in the transaction. This is a unique identifier for the SPL token or SOL.
• Data type: STRING (base58 Solana mint address)
• Business context: Used to identify the destination asset in the swap, filter by token, and analyze token-specific inflows.
• Analytics use cases: Token inflow analysis, asset demand studies, and DEX routing analytics.
• Example: SOL: So11111111111111111111111111111111111111112, USDT: BQvQ8... | | SWAP_TO_AMOUNT | FLOAT | The total amount of the token received from the swap, as recorded on-chain. This value is already decimal adjusted according to the token’s standard decimals, and represents the human-readable amount.
• Data type: NUMBER (float or integer, depending on token)
• Business context: Used to measure swap output, analyze price impact, and track liquidity received.
• Analytics use cases: Output volume analysis, slippage and price impact studies, and DEX performance comparisons.
• Example: For USDC, a value of 1.0 means 1 USDC. For SOL, a value of 0.25 means 0.25 SOL. | | PROGRAM_ID | TEXT | The unique public key (base58-encoded address) of a Solana program. This field identifies the on-chain program (smart contract) responsible for processing instructions, emitting events, or managing accounts. Used throughout Solana analytics models—including events, transactions, IDLs, and program activity tables—to join, filter, and analyze program-level data.

• “4Nd1mY…”
• “TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA”

• Used as a join key for program activity, deployments, events, and interface changes.
• Supports segmentation of activity by protocol, DEX, NFT marketplace, or other on-chain application. | | IS_DCA_SWAP | BOOLEAN | A boolean flag indicating whether the swap was initiated by a Jupiter DCA (Dollar Cost Averaging) order. This field enables analysis of DCA feature usage and user behavior patterns.
• Data type: BOOLEAN (TRUE/FALSE, NULL if not a DCA swap)
• Business context: Used to identify DCA swaps and analyze Jupiter’s DCA feature adoption and usage patterns.
• Analytics use cases: DCA feature adoption analysis, user behavior studies, and Jupiter product analytics.
• Example: TRUE | | DCA_REQUESTER | TEXT | The original address that requested the DCA (Dollar Cost Averaging) swap. This field identifies the user who initiated the DCA order, enabling user-level DCA analytics.
• Data type: STRING (base58 Solana address, NULL if not a DCA swap)
• Business context: Used to track DCA users, analyze DCA user behavior, and measure DCA feature adoption at the user level.
• Analytics use cases: DCA user segmentation, user behavior analysis, and Jupiter product adoption studies.
• Example: ‘4Nd1mYw4r…’ | | IS_LIMIT_SWAP | BOOLEAN | A boolean flag indicating whether the swap was initiated by a Jupiter limit order. This field enables analysis of limit order feature usage and user behavior patterns.
• Data type: BOOLEAN (TRUE/FALSE, NULL if not a limit order swap)
• Business context: Used to identify limit order swaps and analyze Jupiter’s limit order feature adoption and usage patterns.
• Analytics use cases: Limit order feature adoption analysis, user behavior studies, and Jupiter product analytics.
• Example: TRUE | | LIMIT_REQUESTER | TEXT | The original address that requested the limit order swap. This field identifies the user who initiated the limit order, enabling user-level limit order analytics.
• Data type: STRING (base58 Solana address, NULL if not a limit order swap)
• Business context: Used to track limit order users, analyze limit order user behavior, and measure limit order feature adoption at the user level.
• Analytics use cases: Limit order user segmentation, user behavior analysis, and Jupiter product adoption studies.
• Example: ‘4Nd1mYw4r…’ | | FACT_SWAPS_JUPITER_SUMMARY_ID | TEXT | A unique, stable identifier for each record in this table. The primary key (PK) ensures that every row is uniquely identifiable and supports efficient joins, lookups, and data integrity across models. The PK may be a natural key (such as a blockchain transaction hash) or a surrogate key generated from one or more fields, depending on the table’s structure and requirements. | | INSERTED_TIMESTAMP | TIMESTAMP_NTZ | The timestamp when this transaction record was first inserted into the analytics database. Used for data freshness tracking and incremental model logic. Format: YYYY-MM-DD HH:MI:SS. Not derived from the blockchain, but from the ETL process. | | MODIFIED_TIMESTAMP | TIMESTAMP_NTZ | The timestamp when this transaction record was last updated in the analytics database. Used for tracking updates and supporting incremental model logic. Format: YYYY-MM-DD HH:MI:SS. Not derived from the blockchain, but from the ETL process. |