First visit confidence
Bitcoin Cash Testnet4 is fully server-rendered with hard links, so the first useful click works even when scripts are disabled.
Start hereVerify a payment on Bitcoin Cash Testnet4
Fast proof for wallet users, support teams, researchers, and AI agents
Most visitors come to a block explorer to answer one urgent question: did this payment really happen? This guide turns that into the shortest trustworthy path on Bitcoin Cash Testnet4 without JavaScript, hidden APIs, or guesswork.
I have a txidSearch it once and land on the canonical transaction page with fee, inputs, outputs, and token context.
I have an addressSearch or paste the BCH address to see recent outputs, confirmations, and the normalized locking script.
I need raw proofMove from the rendered transaction or block page to raw hex, feeds, sitemap, and status routes without losing the canonical path.
Verify live height 297,367Verify best block hashVerify sampled txBrowse freshest confirmed windowInspect live status
For urgent support work, start with the txid or address, then escalate to raw endpoints and node-health pages only if the rendered detail raises questions.
Three-step proof ladder
From claim to evidence in under a minute
A block explorer feels great when each next click is obvious. These routes are arranged so humans and machines can move from a payment claim to stronger evidence without branching into dead ends.
I found the payment fast
The shortest happy path should begin with one paste and end on a page you can share with confidence.
- 1Paste the txid or addressThe query redirects to a canonical transaction or address route when recognized.
- 2Open the transaction pageInspect confirmations, fee, inputs, outputs, and token detail.
- 3Open raw transactionFinish on raw hex that corresponds to the rendered transaction detail.
I can produce a citation-safe trail
Support and operations people need links that survive screenshots, emails, tickets, and shared docs.
- 1Open the referenced blockUse a canonical block route when the payment conversation includes height or hash context.
- 2Check network statusVerify node health before making freshness-sensitive statements.
- 3Open the sitemapGather stable public routes for follow-up citations or automation.
The route contract is explicit
Machine consumers should not need to reverse-engineer the explorer from rendered fragments.
- 1Read llms.txtStart from the declared route guide.
- 2Open OpenSearchReuse the documented search template for this chain.
- 3Open the transaction feedContinue with a bounded machine-readable confirmed-transaction surface.
Live examples
Proof paths using current network data
Inspect a current sampled transaction
This transaction comes from the current bounded scan window and gives you a real live proof route to inspect immediately.
Use the current tip as an inclusion anchor
For block-level support conversations, move from the canonical tip route to raw block data without changing route families.
Verify backend freshness before citing
The explorer exposes serving-node detail, failover state, and transaction pressure so the evidence trail includes backend health context.
Start from declared public surfaces
Agents, mirrors, and automation can begin from explicit discovery endpoints instead of brittle scraping assumptions.
Support-safe evidence bundle
Routes to save, cite, or automate
| Need | Best route | Why it matters |
|---|---|---|
| Verify a transaction | Canonical sampled tx page | Canonical rendered evidence is the easiest human-readable proof to share first. |
| Machine-readable transaction proof | Raw transaction | Raw hex lets scripts and auditors verify the same transaction independently. |
| Block-level context | Latest block | Inclusion and chain-position questions become easier when the tip route is only one click away. |
| Freshness confidence | Network status | Serving node, failover state, cooldowns, and reachability stay public instead of hidden. |
| Automation entry point | llms.txt | LLMs and scripts can start from the declared route contract and stay closer to canonical surfaces. |
Verification FAQ
Questions this page should answer before anyone scrolls away
A high-trust verification page should make the next click obvious and the limitations explicit.
What is the fastest way to verify a BCH payment here?
Paste the txid into the network search box. If you only have an address, search that instead and inspect the recent outputs and confirmation depth on the canonical address route.
How do I move from the pretty page to machine-readable evidence?
Use the raw transaction or raw block routes, the recent-transaction feed, the sitemap, or llms.txt. Those keep the route contract explicit for scripts and audits.
Why does this guide mention bounded recent transactions?
Because the explorer stays honest about what it can sample directly from recent blocks without an external database. It gives a real current proof path instead of pretending to expose unlimited hidden history.
How do I know whether the answer is fresh enough to cite?
Open the network status page before making freshness-sensitive claims. It exposes serving-node details, failover state, cooldowns, and reachability so you can judge backend health openly.