Fact Swaps Jupiter Inner

​

Description

​

Key Use Cases

• Analyze the full path and DEX usage for Jupiter-routed swaps
• Calculate routed swap volume and compare with direct swaps
• Understand Jupiter’s routing logic and total impact on DEX activity

​

Important Relationships

• Use with defi.fact_swaps_jupiter_summary for user-level intent and summarized swaps
• Use with defi.fact_swaps to compare routed and direct swaps
• Example queries: buy/sell volume for a token routed on Jupiter, compare volume of Jupiter-routed swaps vs. direct DEX swaps

​

Commonly-used Fields

• block_timestamp, swap_index, swap_from_mint, swap_to_mint, swap_from_amount, swap_to_amount, swap_program_id, aggregator_program_id

​

Sample Queries

​

Analyze Jupiter routing for a specific token

-- Get number of swaps that routed through Jupiter for PYTH token
SELECT
    block_timestamp::date AS dt,
    SUM(swap_from_amount) AS daily_pyth_swapped_from,
    COUNT(*) AS num_intermediate_swaps,
    COUNT(DISTINCT tx_id) AS num_jupiter_transactions,
    COUNT(DISTINCT swap_program_id) AS unique_dexes_used
FROM solana.defi.fact_swaps_jupiter_inner
WHERE swap_from_mint = 'HZ1JovNiVvGrGNiiYvEozEVgZ58xaU3RKwX8eACQBCt3'
    AND block_timestamp::date BETWEEN '2025-01-01' AND '2025-01-07'
GROUP BY 1
ORDER BY dt;

​

Jupiter DEX usage and routing analysis

-- Analyze which DEXes Jupiter routes through most frequently
SELECT
    l.address_name AS dex_program,
    COUNT(*) AS total_route_steps,
    COUNT(DISTINCT tx_id) AS unique_transactions,
    SUM(swap_from_amount) AS total_volume_routed,
    AVG(swap_from_amount) AS avg_swap_size
FROM solana.defi.fact_swaps_jupiter_inner j
LEFT JOIN solana.core.dim_labels l ON j.swap_program_id = l.address
WHERE block_timestamp >= CURRENT_DATE - 7
GROUP BY 1
ORDER BY total_route_steps DESC;

​

Jupiter routing complexity analysis

-- Analyze the complexity of Jupiter routes (number of steps per transaction)
SELECT
    COUNT(DISTINCT swap_index) AS route_steps,
    COUNT(*) AS num_transactions,
    AVG(swap_from_amount) AS avg_initial_amount,
    COUNT(*) * 100.0 / SUM(COUNT(*)) OVER () AS pct_of_transactions
FROM solana.defi.fact_swaps_jupiter_inner
WHERE block_timestamp >= CURRENT_DATE - 7
GROUP BY tx_id, 1
ORDER BY route_steps;

​

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. | | SWAP_PROGRAM_ID | TEXT | The program ID of the AMM (Automated Market Maker) performing the swap within a Jupiter route. This field identifies the specific DEX protocol executing the swap step.
• Data type: STRING (base58 Solana program address)
• Business context: Used to identify the DEX protocol for each swap step in a routed transaction.
• Analytics use cases: DEX usage analysis within routes, protocol performance comparison, and route optimization studies.
• Example: ‘675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8’ | | AGGREGATOR_PROGRAM_ID | TEXT | The program ID of the aggregator (e.g., Jupiter) that orchestrated the multi-hop swap route. This field identifies the aggregator responsible for routing the swap across multiple DEXes.
• Data type: STRING (base58 Solana program address)
• Business context: Used to identify the aggregator protocol that coordinated the swap route.
• Analytics use cases: Aggregator usage analysis, route optimization studies, and protocol adoption tracking.
• Example: ‘JUP4Fb2cqiRUcaTHdrPC8h2gNsA2ETXiPDD33WcGuJB’ | | FACT_SWAPS_JUPITER_INNER_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. |