Overview
Every record BlockDB delivers comes with a mathematical receipt you can independently verify. You can always ask: where did this come from, and was it computed correctly? Lineage is the answer — a traceable path from any derived row (a price, a pool snapshot, a transfer) back to the raw on-chain log that produced it, anchored by cryptographically stable coordinates and verifiable against the Merkle trie that secures the chain itself.
What Lineage Gives You
Stable row handles
_tracing_id repeats across API responses and warehouse exports for the same logical row — safe to store, join, and use in support tickets.Explicit on-chain coordinates
block_height, transaction_hash, log_index, and related fields anchor every row to chain execution, where the DDL defines them.Cross-dataset joins
Shared coordinates and dataset IDs let you join OHLC, reserves, transfers, and primitives in SQL or notebooks.
Tracing Fields
| Location | Field | What it provides |
|---|---|---|
APIs (/evm/*) | _tracing_id | Opaque per-tenant handle for the row when present in that dataset’s schema. |
| SQL exports | _tracing_id, _created_at, _updated_at | Mirror API fields for warehouses (where the table defines them). |
| Row payloads | block_height, transaction_hash, log_index, pool/token addresses | Direct anchors to chain state and protocol entities. |
Not every aggregate table includes
_tracing_id or tracking_ids_view[]. Use the data catalog for the exact column list per table.Lineage API
For programmatic provenance expansion, use the Historic API Lineage suite:Record
POST /evm/lineage/record — retrieve lineage metadata for a specific row.Parents
POST /evm/lineage/parents — walk the provenance graph up to parent records.