Fact Token Mint Actions

​

Description

​

Key Use Cases

• Analyze token creation patterns and supply dynamics
• Track mint authority activity and token issuance
• Study token standard adoption (SPL, Metaplex, etc.)
• Monitor new token launches and initial distributions
• Support analytics on token economics and supply management

​

Important Relationships

• Closely related to defi.fact_token_burn_actions (for burn events), core.ez_transfers (for token movements), and core.fact_token_balances (for balance changes)
• Use defi.fact_token_burn_actions to analyze token destruction and supply reduction
• Use core.ez_transfers to track token movements after minting
• Use core.fact_token_balances to analyze balance changes from minting
• Joins with core.fact_blocks for block context and core.fact_transactions for transaction context

​

Commonly-used Fields

• block_timestamp: For time-series and mint activity analysis
• mint, mint_authority, token_account: For token and authority identification
• mint_amount: For supply and value analytics
• mint_standard_type: For token standard analysis
• succeeded: For transaction success analysis

​

Sample Queries

​

Daily token minting activity

SELECT
    DATE_TRUNC('day', block_timestamp) AS date,
    COUNT(*) AS mint_count,
    COUNT(DISTINCT mint_authority) AS unique_minters,
    COUNT(DISTINCT mint) AS unique_tokens_minted,
    SUM(mint_amount / POW(10, COALESCE(decimal, 0))) AS total_tokens_minted
FROM solana.defi.fact_token_mint_actions
WHERE block_timestamp >= CURRENT_DATE - 30
    AND succeeded = TRUE
GROUP BY 1
ORDER BY 1 DESC;

​

Top minting authorities by volume

SELECT
    mint_authority,
    COUNT(DISTINCT mint) AS unique_tokens,
    COUNT(*) AS mint_events,
    SUM(mint_amount / POW(10, COALESCE(decimal, 0))) AS total_minted_tokens,
    AVG(mint_amount / POW(10, COALESCE(decimal, 0))) AS avg_mint_size_tokens,
    MAX(mint_amount / POW(10, COALESCE(decimal, 0))) AS largest_mint_tokens,
    COUNT(DISTINCT DATE(block_timestamp)) AS active_days
FROM solana.defi.fact_token_mint_actions
WHERE block_timestamp >= CURRENT_DATE - 7
    AND succeeded = TRUE
GROUP BY mint_authority
HAVING mint_events > 10
ORDER BY total_minted_tokens DESC
LIMIT 50;

​

Token supply expansion analysis

WITH mint_burn_comparison AS (
    SELECT
        m.mint,
        COALESCE(SUM(m.mint_amount / POW(10, COALESCE(m.decimal, 0))), 0) AS total_minted,
        COALESCE(b.total_burned, 0) AS total_burned
    FROM solana.defi.fact_token_mint_actions m
    LEFT JOIN (
        SELECT
            mint,
            SUM(burn_amount / POW(10, COALESCE(decimal, 0))) AS total_burned
        FROM solana.defi.fact_token_burn_actions
        WHERE block_timestamp >= CURRENT_DATE - 7
            AND succeeded = TRUE
        GROUP BY 1
    ) b ON m.mint = b.mint
    WHERE m.block_timestamp >= CURRENT_DATE - 7
        AND m.succeeded = TRUE
    GROUP BY 1, b.total_burned
)
SELECT
    mint,
    total_minted,
    total_burned,
    total_minted - total_burned AS net_supply_change,
    CASE
        WHEN total_burned = 0 THEN 'Pure Inflation'
        WHEN total_minted > total_burned THEN 'Net Inflation'
        WHEN total_minted < total_burned THEN 'Net Deflation'
        ELSE 'Balanced'
    END AS supply_dynamics
FROM mint_burn_comparison
WHERE total_minted > 0 OR total_burned > 0
ORDER BY ABS(total_minted - total_burned) DESC
LIMIT 100;

​

Minting velocity and patterns

WITH hourly_mints AS (
    SELECT
        DATE_TRUNC('hour', block_timestamp) AS hour,
        mint,
        COUNT(*) AS mint_events,
        SUM(mint_amount / POW(10, COALESCE(decimal, 0))) AS hourly_minted_tokens
    FROM solana.defi.fact_token_mint_actions
    WHERE block_timestamp >= CURRENT_TIMESTAMP - INTERVAL '24 hours'
        AND succeeded = TRUE
    GROUP BY 1, 2
)
SELECT
    hour,
    COUNT(DISTINCT mint) AS active_tokens,
    SUM(mint_events) AS total_mint_events,
    SUM(hourly_minted_tokens) AS total_minted_tokens,
    AVG(hourly_minted_tokens) AS avg_token_mint_amount,
    MAX(hourly_minted_tokens) AS max_token_mint_amount
FROM hourly_mints
GROUP BY 1
ORDER BY 1 DESC;

​

Large minting events (potential inflation events)

SELECT
    block_timestamp,
    tx_id,
    mint_authority,
    mint,
    mint_amount,
    mint_amount / POW(10, COALESCE(decimal, 0)) AS mint_amount_normalized,
    event_type,
    succeeded
FROM solana.defi.fact_token_mint_actions
WHERE block_timestamp >= CURRENT_DATE - 1
    AND mint_amount > 1000000  -- Large raw amounts
    AND succeeded = TRUE
ORDER BY mint_amount DESC
LIMIT 100;

​

Token creation and initial mints

WITH first_mints AS (
    SELECT
        mint,
        MIN(block_timestamp) AS first_mint_time,
        FIRST_VALUE(mint_authority) OVER (
            PARTITION BY mint
            ORDER BY block_timestamp
        ) AS initial_minter,
        FIRST_VALUE(mint_amount / POW(10, COALESCE(decimal, 0))) OVER (
            PARTITION BY mint
            ORDER BY block_timestamp
        ) AS initial_supply_normalized
    FROM solana.defi.fact_token_mint_actions
    WHERE block_timestamp >= CURRENT_DATE - 7
        AND succeeded = TRUE
)
SELECT DISTINCT
    DATE_TRUNC('day', first_mint_time) AS launch_date,
    mint,
    initial_minter,
    initial_supply_normalized,
    first_mint_time
FROM first_mints
ORDER BY first_mint_time DESC
LIMIT 100;

​

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’. | | BLOCK_TIMESTAMP | TIMESTAMP_NTZ | The timestamp (UTC) at which the block was produced on the Solana blockchain. This field is recorded as a TIMESTAMP data type and represents the precise moment the block was finalized and added to the chain. It is essential for time-series analysis, block production monitoring, and aligning transaction and event data to specific points in time. Used extensively for analytics involving block intervals, network activity trends, and historical lookups. Format: YYYY-MM-DD HH:MI:SS (UTC). | | 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 | | 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. | | 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. | | EVENT_TYPE | TEXT | A string categorizing the type of event or instruction, such as ‘transfer’, ‘mint’, ‘burn’, or protocol-specific actions.

• ‘transfer’
• ‘mint’
• ‘burn’

• Enables segmentation and filtering of on-chain activity for analytics and dashboards.
• Used to group and analyze protocol-specific actions and user behaviors.

• May be derived from decoded instruction data or protocol-specific logic. | | MINT | TEXT | Unique address representing a specific token | | MINT_AMOUNT | NUMBER | The amount of tokens being minted in the transaction, denominated in the token’s smallest unit (e.g., lamports for SOL, or the base unit for SPL tokens). This field enables token supply analysis and mint tracking.
• Data type: NUMBER (integer, token’s smallest unit)
• Business context: Used to track token mints, analyze token supply changes, and measure inflationary pressure.
• Analytics use cases: Token supply analysis, mint rate tracking, and inflationary token studies.
• Example: For SOL, 1 SOL = 1,000,000,000 lamports; a value of 1000000000 means 1 SOL minted. | | MINT_AUTHORITY | TEXT | The address of the account that has authority to authorize the mint operation. This field identifies the entity responsible for authorizing the token mint.
• Data type: STRING (base58 Solana address)
• Business context: Used to track mint authorities, analyze mint patterns, and identify centralized mint controls.
• Analytics use cases: Mint authority analysis, centralized vs decentralized mint studies, and token governance tracking.
• Example: ‘4Nd1mYw4r…’ | | TOKEN_ACCOUNT | TEXT | The account address where tokens are stored and from which they are burned or to which they are minted. This field identifies the specific token account involved in the action.
• Data type: STRING (base58 Solana address)
• Business context: Used to track token account activity, analyze token flows, and identify token holders.
• Analytics use cases: Token account analysis, holder tracking, and token flow studies.
• Example: ‘4Nd1mYw4r…’ | | SIGNERS | TEXT | List of accounts that signed the transaction. This field captures all wallet addresses that provided signatures for the transaction, enabling multi-signature analysis and transaction authority tracking.