A transfer table keyed only by transaction hash can lose valid rows while every RPC call succeeds.

Here is a small, real fixture that catches that mistake: eight ERC-20 Transfer logs across four Base transactions. The per-transaction counts are 1, 1, 2 and 4. Put those logs into a dictionary keyed only by transaction hash and only four rows survive.

Run the check without an RPC key

Download cadd-raw-logs.jsonl from the fixed sample revision. Save the following as verify-sample.py in the same directory and run it with Python 3:

import json from collections import Counter from pathlib import Path logs = [json.loads(line) for line in Path("cadd-raw-logs.jsonl").read_text().splitlines() if line.strip()] by_transaction = {log["transactionHash"].lower(): log for log in logs} event_keys = [(log["transactionHash"].lower(), int(log["logIndex"], 16)) for log in logs] assert len(logs) == 8 assert len(by_transaction) == 4 assert len(set(event_keys)) == 8 assert sorted(Counter(key[0] for key in event_keys).values()) == [1, 1, 2, 4] print("8 logs; 4 transactions; 8 distinct event keys")

The code intentionally constructs the lossy transaction-keyed dictionary, then checks the event-level keys separately. No package installation, wallet, key or network request is needed once the sample is downloaded.

For this single-chain fixture, use transaction hash and log index to distinguish events. A dataset spanning chains should also carry chain identity. Keep block identity and removed/reorg handling as separate concerns: a distinct row key does not prove that an event is still canonical.

What the sample actually contains

BlockVectra's keyed Base endpoint returned these eight logs on November 8, 2026 at 04:25 UTC, for CADD at:

0x16f93ebc5320c89efc8701577efe49d14a276a06

The request filtered the ERC-20 Transfer topic over the inclusive range 53,758,000–53,758,999. The sample includes the raw result entries and expected rows from the unchanged decoder in this pinned upstream loader.

Only one event was independently compared with BaseScan: block 53,758,011, log index 6, contract/from/to, and raw amount 57370140000000000000000. The other seven are provider-returned samples. This does not establish that the window contains every event.

Keep raw amounts as integers or decimal strings. The fixture does not use floating-point conversion to normalize token amounts.

Timestamp and receipt checks are separate

At 05:02 UTC, two additional calls returned:

  • decimals() at latest: 18, agreeing with the project seed.
  • A one-element JSON-RPC batch for block 53,758,011: timestamp 1793941977, or 2026-11-06T05:12:57Z, matching the independently saved BaseScan time.

Those request/response bodies are in loader-method-requests-responses.json in the same sample. The header hash agrees with the earlier log response, which is a same-provider cross-check rather than independent canonical verification. One batch item does not establish compatibility for the loader's usual 50-item batches.

The earlier lookup of that transaction's receipt returned null. That result remains tracked separately; the upstream log loader does not directly call receipts. Safe-head selection, timestamps for the other sample blocks, February-onward history and the full database backfill have not been validated here.

This fixture is useful for a narrow regression: preserving multiple transfers in one transaction. It is not a backfill benchmark, a complete ingestion test or evidence of customer adoption.