Use this as a verification layer. Explorers are useful for checking samples of a transaction export, but they are not the whole data stack for complex wallets.
The goal is to catch obvious mismatches: missing hashes, wrong chains, token transfers that did not make it into the CSV, or labels that should not be treated as tax facts.
Use this when
- You already have an export and want to test whether it is plausible.
- You need a beginner-friendly verification step.
- You want to cite transaction hashes in a client memo.
What the workflow should produce
- A sample list of transaction hashes to check.
- Manual notes from explorer pages.
- Token transfer samples that may need deeper review.
- A short warning list: labels are clues, not tax classification.
Minimum setup
- Use the Etherscan V2 chainlist to confirm the explorer/API route for the chain being checked.
- Keep a sampled list of transaction hashes from the export rather than checking only the obvious rows.
- Ask Codex to generate a verification checklist, not a tax conclusion.
Skill to package next
tx-hash-verification: input a CSV, sample hashes, open or query explorer evidence, and produce verification-notes.md with unresolved labels.
Etherscan now documents a Streamable HTTP MCP server using bearer-token authentication. This article should eventually show both a manual explorer workflow and an MCP-assisted verification workflow.
Check before trusting it
Verify current explorer API names, coverage, and limits before turning this into a technical walkthrough. Never present explorer labels as final tax treatment.
