> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockdb.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Verification

> Verification processes that guarantee integrity across BlockDB's public datasets.

## Overview

BlockDB's indexers do far more than persist raw blockchain payloads. Every dataset export passes through a **multi-layer cryptographic verification pipeline** — running in sequence for every block, every transaction, and every log:

<Steps>
  <Step title="Log RLP Reconstruction">
    Each log's **contract address**, **topics**, and **data** are re-encoded from scratch using RLP encoding. This ensures every byte of every event is accounted for — no truncation, no reordering, no partial processing.
  </Step>

  <Step title="Log Bloom Validation">
    Each transaction's **2048-bit bloom filter** is recomputed by hashing the emitting contract address and every indexed topic. The result is compared bit-for-bit against the on-chain value. A single differing bit fails validation — catching subtle corruption that receipt checks alone would miss.
  </Step>

  <Step title="Receipts Root Recomputation">
    The reconstructed receipts are assembled into a **Merkle Patricia Trie**. A Keccak-256 hash of the rebuilt root is compared against the chain-supplied `receiptsRoot`. Any mismatch triggers an immediate blocking incident.
  </Step>

  <Step title="Block Continuity Check">
    Block numbers are verified to increment without gaps, and every `parent_block_hash` is matched against the previous block. This guarantees a complete, unbroken chain of evidence across the entire indexed range.
  </Step>
</Steps>

These checks ensure that all exported data is *provably identical* to what was produced on-chain — not just at ingest time, but at every stage of archival and replication.

***

## Stored Evidence

Each successfully verified block writes two immutable breadcrumbs to [`blockdb_evm.b0101_blocks_v1`](/data-catalog/evm/primitives/blocks):

| Column                            | Description                                                      |
| --------------------------------- | ---------------------------------------------------------------- |
| `_computed_receipt_root`          | The receipts root recomputed from verified transaction receipts. |
| `_computed_receipt_timestamp_utc` | UTC timestamp when the recomputation occurred.                   |

These fields allow consumers and auditors to independently confirm that BlockDB's recomputation matched the chain-provided root at the time of export.

***

## Archive Re-validation

In addition to live verification, BlockDB runs **offline re-validation** of data already exported to the persistence layer — replaying all verification logic using only stored data, without depending on live node responses:

* Long-term consistency across cold storage and replicas is preserved
* Block continuity and parent hash linkage remain intact after archival compaction
* Historical reproducibility is maintained, proving that what left the exporter stays self-consistent at rest

Because this process operates solely on exported data, it confirms integrity *post-ingestion* — and can safely run on lagged replicas or analytical nodes without affecting live indexing performance.

***

## Integrity Guarantees

The combination of **Log RLP reconstruction**, **bloom validation**, **receipts-root recomputation**, and **block continuity checks** makes BlockDB's verification pipeline uniquely resistant to silent corruption:

| Safeguard                                                   | Ensures                                                                    | Prevents                                                      |
| ----------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------- |
| `LogsRlp` rebuilt from each log's address, topics, and data | Log-level completeness and byte-accurate reproduction of on-chain payloads | Missing or truncated logs                                     |
| Receipts root recomputed from all transactions              | Transaction-level integrity and Merkle proof consistency                   | Missing transactions                                          |
| Block continuity validation                                 | Continuous block sequence and parent hash linkage                          | Missing or orphaned blocks                                    |
| Archive re-validation using exported database data          | Long-term consistency and reproducibility independent of live nodes        | Data drift, replica inconsistency, or corruption after export |

These layers form a **cryptographically auditable chain of evidence**, far stronger than checksum-based or row-count validation methods.

***

## De-duplication & Reorg Safety

BlockDB enforces **stable, domain-correct primary keys** to prevent duplicates across ingestion — mirroring how identity is defined on-chain and guaranteeing deterministic joins and idempotent re-ingestion:

* **`blockdb_evm.b0101_blocks_v1`** — primary key: `block_number`
* **`blockdb_evm.b0102_transactions_v1`** — primary key: `tx_hash`
* **`blockdb_evm.b0103_logs_v1`** — composite key: `(block_number, tx_index, log_index)`

Archive indexing operates with a **bounded backoff from the chain tip** (typically 3-100 blocks, chain-dependent). This buffer ensures short-range reorgs don't leak transient data into exports, and that final datasets reflect **post-reorg canonical history**.

***

## Auditing & API

BlockDB exposes dedicated verification endpoints so clients can independently validate exported data on their side:

<CardGroup cols={2}>
  <Card title="Verify Receipt Root" icon="shield-check" href="/api-reference/evm/verification/verify-receipt-root">
    Recompute and compare canonical receipt trie roots against the chain-supplied value.
  </Card>

  <Card title="Verify Logs Bloom" icon="shield-halved" href="/api-reference/evm/verification/verify-logs-bloom">
    Regenerate logs bloom filters for targeted block or transaction reconciliations.
  </Card>
</CardGroup>

<Note>
  For organizations that require deeper insight into the end-to-end verification pipeline or custom validation tooling, contact us at [support@blockdb.io](mailto:support@blockdb.io).
</Note>