Skip to main content
Schema: ethereum.beacon_chain Table: ez_withdrawals Type: View This convenience table contains information about the withdrawals made from the beacon chain, alongside address labels for analysis purposes. Withdrawal activity in this table is derived directly from the withdrawals object in the eth_getBlockByNumber Ethereum JSON-RPC Method, where block_number represents the block on Ethereum Mainnet and slot_number corresponds to the Beacon Chain slot that the withdrawal was executed in. For more info, please visit The Ethereum Organization.

​
Columns

Column NameData TypeDescription
BLOCK_NUMBERNUMBERSequential counter representing the position of a block in the blockchain since genesis (block 0).
Key Facts:
  • Immutable once finalized
  • Primary ordering mechanism for blockchain data
  • Increments by 1 for each new block
  • Used as a proxy for time in many analyses
Usage in Queries: 
-- Recent data
WHERE block_number >= (SELECT MAX(block_number) - 1000 FROM fact_blocks)

-- Historical analysis
WHERE block_number BETWEEN 15000000 AND 16000000

-- Join across tables
JOIN <blockchain_name>.core.fact_event_logs USING (block_number)
Important: Block numbers are chain-specific. Block 15000000 on Ethereum ≠ block 15000000 on Polygon. | | BLOCK_TIMESTAMP | TIMESTAMP_NTZ | UTC timestamp when the block was produced by validators/miners. Format: TIMESTAMP_NTZ (no timezone) Precision: Second-level accuracy Reliability:
  • Set by block producer
  • Can have minor variations (±15 seconds)
  • Always increasing (newer blocks = later timestamps)
Best Practices: 
-- Time-based filtering (most efficient)
WHERE block_timestamp >= DATEADD('day', -7, CURRENT_TIMESTAMP)

-- Hourly aggregations
DATE_TRUNC('hour', block_timestamp) AS hour

-- UTC date extraction
DATE(block_timestamp) AS block_date
Note: Use for time-series analysis, but be aware that block production rates vary by chain. | | BLOCK_HASH | TEXT | The unique 32-byte Keccak-256 hash of the block header, prefixed with ‘0x’. Example: ‘0x4e3a3754410177e6937ef1f84bba68ea139e8d1a2258c5f85db9f1cd715a1bdd’ | | WITHDRAWAL_AMOUNT | FLOAT | The amount of the withdrawal. | | WITHDRAWAL_ADDRESS | TEXT | The address that received the withdrawal. | | WITHDRAWAL_ADDRESS_NAME | TEXT | The label or name associated with the withdrawal address. | | WITHDRAWAL_ADDRESS_CATEGORY | TEXT | The category or type of the withdrawal address. | | WITHDRAWAL_ADDRESS_TYPE | TEXT | The subtype or further classification of the withdrawal address. | | WITHDRAWALS_ROOT | TEXT | The root hash of the withdrawal data structure. | | WITHDRAWAL_INDEX | NUMBER | The index of the withdrawal. | | VALIDATOR_INDEX | NUMBER | The index of the validator associated with the withdrawal. | | SLOT_NUMBER | NUMBER | The Beacon Chain slot this block represents. | | EPOCH_NUMBER | NUMBER | A period of 32 slots, each slot being 12 seconds, totaling 6.4 minutes. | | EZ_WITHDRAWALS_ID | TEXT | Primary 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;
``` |