Skip to main content
Schema: solana.defi Table: fact_token_burn_actions Type: Base Table

​
Description

This table contains information on all token burn events on the Solana blockchain. It tracks the destruction of tokens across various token standards (SPL, Metaplex, etc.), capturing burn authority actions, token account sources, and burn amounts. Each row represents a single token burn event, supporting analytics on token destruction, supply reduction, and token standard usage.

​
Key Use Cases

  • Analyze token destruction patterns and supply reduction
  • Track burn authority activity and token destruction
  • Study token standard adoption (SPL, Metaplex, etc.)
  • Monitor token supply management and deflationary mechanisms
  • Support analytics on token economics and supply dynamics

​
Important Relationships

  • Closely related to defi.fact_token_mint_actions (for mint events), core.ez_transfers (for token movements), and core.fact_token_balances (for balance changes)
  • Use defi.fact_token_mint_actions to analyze token creation and supply increase
  • Use core.ez_transfers to track token movements before burning
  • Use core.fact_token_balances to analyze balance changes from burning
  • Joins with core.fact_blocks for block context and core.fact_transactions for transaction context

​
Commonly-used Fields

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

​
Sample Queries

​
Daily token burn activity

SELECT
    DATE_TRUNC('day', block_timestamp) AS date,
    COUNT(*) AS burn_count,
    COUNT(DISTINCT burn_authority) AS unique_burners,
    COUNT(DISTINCT mint) AS unique_tokens_burned,
    SUM(burn_amount / POW(10, COALESCE(decimal, 0))) AS total_tokens_burned
FROM solana.defi.fact_token_burn_actions
WHERE block_timestamp >= CURRENT_DATE - 30
    AND succeeded = TRUE
GROUP BY 1
ORDER BY 1 DESC;

​
Top tokens by burn volume

SELECT
    mint,
    COUNT(*) AS burn_events,
    SUM(burn_amount / POW(10, COALESCE(decimal, 0))) AS total_burned_tokens,
    COUNT(DISTINCT burn_authority) AS unique_burners,
    COUNT(DISTINCT DATE(block_timestamp)) AS active_days,
    MAX(burn_amount / POW(10, COALESCE(decimal, 0))) AS largest_burn_tokens,
    AVG(burn_amount / POW(10, COALESCE(decimal, 0))) AS avg_burn_size_tokens
FROM solana.defi.fact_token_burn_actions
WHERE block_timestamp >= CURRENT_DATE - 7
    AND succeeded = TRUE
GROUP BY mint
HAVING burn_events > 5
ORDER BY total_burned_tokens DESC
LIMIT 50;

​
Burn patterns by hour of day

SELECT
    EXTRACT(HOUR FROM block_timestamp) AS hour_of_day,
    COUNT(*) AS burn_count,
    SUM(burn_amount / POW(10, COALESCE(decimal, 0))) AS total_burned_tokens,
    AVG(burn_amount / POW(10, COALESCE(decimal, 0))) AS avg_burn_tokens,
    COUNT(DISTINCT burn_authority) AS unique_burners
FROM solana.defi.fact_token_burn_actions
WHERE block_timestamp >= CURRENT_DATE - 7
    AND succeeded = TRUE
GROUP BY 1
ORDER BY 1;

​
Large token burns (whale activity)

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

​
Token burn velocity (rate of burns over time)

WITH daily_burns AS (
    SELECT
        DATE_TRUNC('day', block_timestamp) AS date,
        mint,
        SUM(burn_amount / POW(10, COALESCE(decimal, 0))) AS daily_burned_tokens,
        COUNT(*) AS burn_events
    FROM solana.defi.fact_token_burn_actions
    WHERE block_timestamp >= CURRENT_DATE - 30
        AND succeeded = TRUE
    GROUP BY 1, 2
),
burn_velocity AS (
    SELECT
        mint,
        AVG(daily_burned_tokens) AS avg_daily_burn_tokens,
        STDDEV(daily_burned_tokens) AS stddev_daily_burn_tokens,
        MAX(daily_burned_tokens) AS max_daily_burn_tokens,
        COUNT(DISTINCT date) AS active_days
    FROM daily_burns
    GROUP BY 1
)
SELECT
    mint,
    avg_daily_burn_tokens,
    stddev_daily_burn_tokens,
    max_daily_burn_tokens,
    active_days,
    stddev_daily_burn_tokens / NULLIF(avg_daily_burn_tokens, 0) AS burn_volatility
FROM burn_velocity
WHERE avg_daily_burn_tokens > 100
ORDER BY avg_daily_burn_tokens DESC;

​
Columns

Column NameData TypeDescription
BLOCK_IDNUMBERA unique identifier for the block in which this transaction was included on the Solana blockchain. Typically a sequential integer or hash, depending on the data source. Used to group transactions by block and analyze block-level activity.
Example:
  • 123456789
Business Context:
  • Supports block-level analytics, such as block production rate and transaction throughput.
  • Useful for tracing transaction inclusion and block explorer integrations.
Relationships:
  • 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.
Example:
  • 5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw
Business Context:
  • 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.
Example:
  • true
  • false
Business Context:
  • 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.
Example:
  • 0
  • 3
Business Context:
  • 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.
Example:
  • 0
  • 2
Business Context:
  • 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.
Example:
  • ‘transfer’
  • ‘mint’
  • ‘burn’
Business Context:
  • Enables segmentation and filtering of on-chain activity for analytics and dashboards.
  • Used to group and analyze protocol-specific actions and user behaviors.
Relationships:
  • May be derived from decoded instruction data or protocol-specific logic. | | MINT | TEXT | Unique address representing a specific token | | BURN_AMOUNT | NUMBER | The amount of tokens being burned 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 burn tracking.
  • Data type: NUMBER (integer, token’s smallest unit)
  • Business context: Used to track token burns, analyze token supply changes, and measure deflationary pressure.
  • Analytics use cases: Token supply analysis, burn rate tracking, and deflationary token studies.
  • Example: For SOL, 1 SOL = 1,000,000,000 lamports; a value of 1000000000 means 1 SOL burned. | | BURN_AUTHORITY | TEXT | The account address that has authority to confirm the burn event. This field identifies the entity responsible for authorizing the token burn.
  • Data type: STRING (base58 Solana address)
  • Business context: Used to track burn authorities, analyze burn patterns, and identify centralized burn controls.
  • Analytics use cases: Burn authority analysis, centralized vs decentralized burn 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.
Data type: ARRAY (list of Solana addresses) Business context: Used to track transaction signers, analyze multi-signature patterns, and identify transaction authorities. Analytics use cases: Multi-signature analysis, transaction authority tracking, and signer pattern studies. Example: [‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’, ‘AnotherAddress…’] | | DECIMAL | NUMBER | Number of decimals in the token value, need to divide amount by 10^decimal | | MINT_STANDARD_TYPE | TEXT | The type of mint following Metaplex mint standards | | FACT_TOKEN_BURN_ACTIONS_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. |