Skip to main content
Schema: solana.nft Table: fact_nft_mints Type: Base Table

​
Description

This table tracks all NFT minting events on Solana, including both standard NFTs and compressed NFTs (cNFTs). It captures the initial creation of NFTs, including mint prices, purchasers, and program information. The data is sourced from various minting programs and provides a comprehensive view of NFT creation activity across the Solana ecosystem, supporting analysis of minting trends and creator economics.

​
Key Use Cases

  • Track NFT creation trends and identify popular minting periods
  • Analyze which minting programs are most active and successful
  • Study mint prices and their correlation with subsequent market performance
  • Monitor revenue generated from initial NFT sales
  • Understand the rate of new NFT creation and its impact on market dynamics
  • Track the adoption and usage of compressed NFTs vs standard NFTs

​
Important Relationships

  • Links to nft.dim_nft_metadata via mint address to provide metadata context
  • Connects to nft.ez_nft_sales through mint address to track post-mint trading activity
  • References core.fact_blocks and core.fact_transactions for blockchain context
  • program_id identifies the specific minting program used for creation

​
Commonly-used Fields

  • block_timestamp: Timestamp when the mint transaction was processed on Solana
  • tx_id: Unique transaction identifier for the mint event
  • purchaser: Address of the account that purchased the NFT during minting
  • mint: The unique mint address of the newly created NFT
  • mint_price: Price paid to mint the NFT in the specified currency
  • mint_currency: Address of the token used to pay for the mint
  • program_id: Address of the minting program that created the NFT
  • is_compressed: Boolean indicating if the minted NFT is a compressed NFT (cNFT)

​
Columns

Column NameData TypeDescription
BLOCK_TIMESTAMPTIMESTAMP_NTZThe 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).
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’. | | 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. | | 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.
Example:
  • “4Nd1mY…”
  • “TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA”
Business Context:
  • 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. | | PURCHASER | TEXT | The wallet address that purchased the NFT | | MINT_PRICE | FLOAT | The price paid to mint the NFT in the specified currency. This field captures the initial cost of creating the NFT and is essential for understanding creator revenue and NFT valuation from creation.
  • Data type: FLOAT (raw token amount, not decimal adjusted)
  • Business context: Used to analyze mint pricing strategies, creator earnings, and market entry costs for NFTs.
  • Analytics use cases: Mint price trend analysis, revenue forecasting, and price-to-market performance studies.
  • Example: 1.5 | | MINT_CURRENCY | TEXT | The address of the token used to pay for the NFT mint. This field identifies which cryptocurrency or token was used as payment during the initial NFT creation process.
  • Data type: STRING (Solana address, e.g., ‘So11111111111111111111111111111111111111112’ for SOL)
  • Business context: Used to analyze mint payment trends, creator revenue, and token adoption for NFT launches.
  • Analytics use cases: Mint payment token analysis, creator revenue breakdown, and minting trend studies.
  • Example: ‘So11111111111111111111111111111111111111112’ | | MINT | TEXT | Unique address representing a specific token | | IS_COMPRESSED | BOOLEAN | A boolean flag indicating whether the NFT is a compressed NFT (cNFT). Compressed NFTs use Merkle trees to reduce storage costs and enable more efficient NFT creation and management.
  • Data type: BOOLEAN (TRUE for compressed NFTs, FALSE for standard NFTs)
  • Business context: Used to distinguish between standard and compressed NFTs for analytics, cost analysis, and protocol adoption tracking.
  • Analytics use cases: cNFT adoption analysis, storage cost studies, and segmentation of NFT activity by type.
  • Example: TRUE | | FACT_NFT_MINTS_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. |