Skip to main content
Schema: solana.core Table: ez_signers Type: View

View DBT Documentation

View the complete technical documentation and data lineage for this table

​
Description

This table contains one row per unique Solana signer (address that signs transactions), with activity metrics, first/last transaction dates, programs used, and fee totals. Each row represents a unique signer and their activity profile, supporting analytics on user and protocol adoption, signer activity, and fee contributions across the Solana blockchain.

​
Key Use Cases

  • Analyze signer activity and protocol adoption
  • Track user and protocol engagement over time
  • Study fee contributions and transaction patterns
  • Segment signers by activity, protocol, and time
  • Support analytics on user growth, retention, and protocol usage

​
Important Relationships

  • Closely related to core.fact_transactions (for transaction context), core.fact_events (for event context), and core.ez_transfers (for transfer events)
  • Use core.fact_transactions to analyze transaction-level activity
  • Use core.fact_events for event-level context and protocol interactions
  • Use core.ez_transfers for asset movement and transfer analytics
  • Joins with core.fact_blocks for block context

​
Commonly-used Fields

  • signer: For user and protocol identification
  • first_tx_date, last_tx_date: For activity period analysis
  • num_days_active, num_txs: For engagement and usage analytics
  • total_fees: For fee contribution analysis
  • programs_used: For protocol usage segmentation

​
Columns

Column NameData TypeDescription
SIGNERTEXTThe Solana address (public key, base58-encoded) that signed the transaction. Signers are responsible for authorizing transactions and may represent users, programs, or system accounts. In most cases, the first signer is the fee payer. This field enables analysis of user activity, protocol adoption, and transaction attribution. Example: ‘7Ggk7Q2…’.
FIRST_TX_DATEDATEThe date (UTC) of the first transaction signed by this address, formatted as YYYY-MM-DD. Useful for cohort analysis, user onboarding studies, and measuring protocol adoption over time.
FIRST_PROGRAM_IDTEXTThe program ID (base58-encoded address) of the first Solana program this signer interacted with, excluding chain admin programs. Indicates the initial protocol or application used by the signer. Example: ‘TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA’.
LAST_TX_DATEDATEThe date (UTC) of the most recent transaction signed by this address, formatted as YYYY-MM-DD. Useful for measuring user retention, reactivation, and protocol engagement over time.
LAST_PROGRAM_IDTEXTThe program ID (base58-encoded address) of the last Solana program this signer interacted with, excluding chain admin programs. Indicates the most recent protocol or application used by the signer. Example: ‘Vote111111111111111111111111111111111111111’.
NUM_DAYS_ACTIVENUMBERThe total number of unique days (UTC) on which this signer performed at least one transaction. Useful for measuring user activity, engagement, and protocol stickiness.
NUM_TXSNUMBERThe total number of distinct transactions signed by this address. Useful for analyzing user activity, protocol adoption, and transaction frequency.
TOTAL_FEESNUMBERThe total amount of transaction fees (in lamports) paid by this signer. Only the first signer in a transaction pays the fee. This field may be null for non-fee-payer signers. Useful for analyzing fee contributions, protocol costs, and user economics. 1 SOL = 1,000,000,000 lamports.
PROGRAMS_USEDARRAYAn array of program IDs (base58-encoded addresses) that this signer interacted with on a given day. Useful for protocol segmentation, user journey analysis, and ecosystem mapping. Example: [‘TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA’, ‘Vote111111111111111111111111111111111111111’].
EZ_SIGNERS_IDTEXTA 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_TIMESTAMPTIMESTAMP_NTZThe 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_TIMESTAMPTIMESTAMP_NTZThe 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.