Skip to main content
Schema: ethereum.beacon_chain Table: fact_attestations Type: View Validators are expected to create, sign, and broadcast an attestation during every epoch. Data in this table contains details around these attestations. For more info, please visit The Ethereum Organization

​
Columns

Column NameData TypeDescription
SLOT_NUMBERNUMBERThe Beacon Chain slot this block represents.
SLOT_TIMESTAMPTIMESTAMP_NTZTimestamp of Beacon Chain slot.
EPOCH_NUMBERNUMBERA period of 32 slots, each slot being 12 seconds, totaling 6.4 minutes.
ATTESTATION_SLOTNUMBERThe slot number in which the validator is attesting on
ATTESTATION_INDEXNUMBERA number that identifies which committee the validator belongs to in a given slot
AGGREGATION_BITSTEXT
BEACON_BLOCK_ROOTTEXTRoot hash of the block the validator sees at the head of the chain (the result of applying the fork-choice algorithm)
SOURCE_EPOCHNUMBERPart of the finality vote indicating what the validators see as the most recent justified block
SOURCE_ROOTTEXTPart of the finality vote indicating what the validators see as the most recent justified block
TARGET_EPOCHNUMBERPart of the finality vote indicating what the validators see as the first block in the current epoch
TARGET_ROOTTEXTPart of the finality vote indicating what the validators see as the first block in the current epoch
ATTESTATION_SIGNATURETEXTA BLS signature that aggregates the signatures of individual validators
FACT_ATTESTATIONS_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;
``` |