Verify a payment on Bitcoin Cash Testnet4

Fast Bitcoin Cash lookup for wallets, support, and research

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.

Search this network Open sampled transaction Open latest block Check node health Transaction feed

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 proofOpen transaction or block details, raw hex, feeds, sitemap, and status from one canonical path.

Verify live height 309,060 Verify best block hash Verify sampled tx Open freshest confirmed window Inspect live status

For urgent support work, start with the txid or address, then open raw endpoints and node-health pages only when you need deeper checks.

What you can prove right now

Verification pulse

test4

Best height309,060Use it as a live block-height verification example

Sampled tx37fd7b0156fa…Canonical tx path is ready

Median time2026-06-06 19:52:35 UTCChain time context

Next halving110,940 blocks25.00000000 BCH subsidy now

Open raw transaction Open network sitemap

Choose your lookup path

What do you already have?

Txid in hand

Verify a payment

Paste the txid and let the explorer redirect you to the canonical detail page immediately.

Search txid·Live tx example

Address only

Confirm receipt

Open the address route to inspect recent outputs, confirmation depth, and normalized locking-script evidence.

Search address·Recent confirmed

Block reference

Prove inclusion

Use a height or block hash when someone shared a block reference instead of a txid.

Latest block·Latest blocks

Machine workflow

Collect raw evidence

Start from feeds, sitemap, and raw routes when you need a script-friendly proof trail.

Raw tx·llms.txt

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.

Wallet user

I found the payment fast

The shortest happy path should begin with one paste and end on a page you can share with confidence.

1
Paste the txid or addressThe query redirects to a canonical transaction or address route when recognized.
2
Open the transaction pageInspect confirmations, fee, inputs, outputs, and token detail.
3
Open raw transactionFinish on raw hex that corresponds to the current transaction detail.

Support desk

I can produce a citation-safe trail

Support and operations people need links that survive screenshots, emails, tickets, and shared docs.

1
Open the referenced blockUse a canonical block route when the payment conversation includes height or hash context.
2
Check network statusVerify node health before making freshness-sensitive statements.
3
Open the sitemapGather stable public routes for follow-up citations or automation.

Data user

Public routes are listed

Public route guides make feeds, search, and detail pages easy to find.

1
Read llms.txtStart from the declared route guide.
2
Open OpenSearchReuse the documented search template for this chain.
3
Open the transaction feedContinue with a bounded machine-readable confirmed-transaction surface.

Live examples

Proof paths using current network data

Transaction trail

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.

Canonical tx page Raw tx

Block trail

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.

Latest block Raw block

Operational trail

Verify backend freshness before citing

The explorer exposes serving-node detail, failover state, and transaction pressure so the evidence trail includes backend health context.

Network status Mempool

Discovery trail

Start from declared public surfaces

Use sitemap, feeds, OpenSearch, and llms.txt to find public data endpoints.

Network sitemap Transaction feed

Support-safe evidence bundle

Routes to save, cite, or automate

Need	Best route	Why it matters
Verify a transaction	Canonical sampled tx page	Canonical explorer pages are the easiest details 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	Scripts can start from published route lists and canonical endpoints.

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 routes are stable entry points 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.