Skip to main content
Schema: ethereum.beacon_chain Table: fact_validators Type: View This table contains information about the validators. For more info, please visit The Ethereum Organization

​
Columns

Column NameData TypeDescription
BLOCK_NUMBERNUMBERDeprecating soon! The name of this column will be replaced with slot_number. The values remain the same and are currently accurate, representative of the Beacon Chain Slot Number. Please migrate queries to the new column by 11/13/23.
SLOT_NUMBERNUMBERThe Beacon Chain slot this block represents.
STATE_IDTEXTThe hash-tree-root of the BeaconState.
INDEXNUMBEREach Validator receives their own unique index.
BALANCEFLOATBalance of Validator
VALIDATOR_STATUSTEXTStatus of Validator (ie. are they Active)
ACTIVATION_ELIGIBILITY_EPOCHNUMBERRefers to pending validators. The deposit has been recognized by the ETH2 chain at the timestamp of “Eligible for activation”. If there is a queue of pending validators, an estimated timestamp for activation is calculated
ACTIVATION_EPOCHNUMBERA period of 32 slots, each slot being 12 seconds, totaling 6.4 minutes.
EFFECTIVE_BALANCEFLOATThe effective Balance represents a value calculated by the current balance. It is used to determine the size of a reward or penalty a validator receives. The effective balance can **never be higher than 32 ETH.
EXIT_EPOCHNUMBERA period of 32 slots, each slot being 12 seconds, totaling 6.4 minutes.
PUBKEYTEXTValidator public key.
SLASHEDBOOLEANIn Phase 0, a validator can be slashed (a more severe penalty) if they violate the Casper FFG rules or if they create two beacon blocks in one epoch.
WITHDRAWABLE_EPOCHNUMBERWhen Validator can withdraw funds
WITHDRAWAL_CREDENTIALSTEXTCommitment to pubkey for withdrawals
VALIDATOR_DETAILSVARIANTInformation about the validator
FACT_VALIDATORS_IDTEXTPrimary key - unique identifier for each row ensuring data integrity.
Format: Usually VARCHAR containing composite key generated using MD5 hash of the relevant columns. Example: MD5(block_number, tx_hash, trace_index) Usage:
  • Deduplication in incremental loads
  • Join operations for data quality checks
  • Troubleshooting specific records
Important: Implementation varies by table - check table-specific documentation. | | INSERTED_TIMESTAMP | TIMESTAMP_NTZ | UTC timestamp when the record was first added to the Flipside database. Format: TIMESTAMP_NTZ Use Cases:
  • Data freshness monitoring
  • Incremental processing markers
  • Debugging data pipeline issues
  • SLA tracking
Query Example: 
-- Check data latency
SELECT
    DATE_TRUNC('hour', block_timestamp) as block_hour,
    DATE_TRUNC('hour', inserted_timestamp) as insert_hour,
    AVG(TIMESTAMPDIFF('minute', block_timestamp, inserted_timestamp)) as avg_latency_minutes
FROM <blockchain_name>.core.fact_transactions
WHERE block_timestamp >= CURRENT_DATE - 1
GROUP BY 1, 2;
``` |
| MODIFIED_TIMESTAMP | TIMESTAMP_NTZ | UTC timestamp of the most recent update to this record.

**Format**: TIMESTAMP_NTZ

**Triggers for Updates**:
- Data corrections
- Enrichment additions
- Reprocessing for accuracy
- Schema migrations

**Monitoring Usage**:
```sql
-- Recently modified records
SELECT *
FROM <blockchain_name>.core.fact_transactions
WHERE modified_timestamp > inserted_timestamp
AND modified_timestamp >= CURRENT_DATE - 1;

-- Data quality tracking
SELECT
    DATE(modified_timestamp) as mod_date,
    COUNT(*) as records_updated,
    COUNT(DISTINCT block_number) as blocks_affected
FROM <blockchain_name>.core.fact_transactions
WHERE modified_timestamp > inserted_timestamp
GROUP BY 1
ORDER BY 1 DESC;
``` |