Skip to main content
Schema: ethereum.nft Table: fact_mev_arbitrage_events Type: View This table contains information about the NFTs involved in arbitrage transactions, documenting events from both the buy and sell sides

​
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. | | TX_HASH | TEXT | Unique 66-character identifier for the transaction. Format: 0x + 64 hexadecimal characters Usage:
  • Primary key for transaction lookups
  • Join key for traces, logs, and token transfers
  • Immutable once confirmed
Example: 0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060 | | TRADE_SIDE | TEXT | The side of the trade that this event represents. This can be either buy or sell. Buy would represent the events where nfts are bought while sell would present the events where the bought nfts are sold. Note that the number of events for buy and sell may not be the same for a given transaction. | | EVENT_INDEX | FLOAT | Zero-based sequential position of the event within a transaction’s execution. Key Facts:
  • Starts at 0 for first event
  • Increments across all contracts in transaction
  • Preserves execution order
  • Essential for deterministic event ordering
Usage Example: 
-- Trace event execution flow
SELECT
    event_index,
    contract_address,
    topic_0,
    SUBSTRING(data, 1, 10) AS data_preview
FROM <blockchain_name>.core.fact_event_logs
WHERE tx_hash = '0xabc...'
ORDER BY event_index;
``` |
| PLATFORM_NAME | TEXT | The marketplace or platform where the NFT sale occurred. Standardized to lowercase with no spaces.

Example: 'opensea' |
| PLATFORM_EXCHANGE_VERSION | TEXT | The version identifier of the marketplace contract. Tracks protocol versions and upgrades.

Example: 'seaport_1_5' |
| BUYER_ADDRESS | TEXT | The blockchain address that purchased the NFT.

Example: '0x1234567890123456789012345678901234567890' |
| SELLER_ADDRESS | TEXT | The blockchain address that sold the NFT.

Example: '0x1234567890123456789012345678901234567890' |
| CONTRACT_ADDRESS | TEXT | The smart contract address of the NFT collection. Supports ERC-721, ERC-1155, and custom implementations.

Example: '0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d' |
| TOKEN_ID | TEXT | The unique identifier of the specific NFT within its collection. Format is numeric string.

Example: '1234' |
| QUANTITY | TEXT |  |
| TOKEN_STANDARD | TEXT | The technical standard implemented by the NFT contract. Common values include 'erc721', 'erc1155', 'cryptopunks', and 'legacy'.

Example: 'erc721' |
| NAME | TEXT | The name of the NFT collection or project. May be NULL for unverified collections.

Example: 'Bored Ape Yacht Club' |
| EZ_MEV_ARBITRAGE_EVENTS_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**:
```sql
-- 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;
``` |