Verify a payment on Bitcoin Cash Chipnet

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 Chipnet without JavaScript, hidden APIs, or guesswork.

Search this network Open recent confirmed activity 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 proofMove from the rendered transaction or block page to raw hex, feeds, sitemap, and status routes without losing the canonical path.

Verify live height 302,409 Verify best block hash Open freshest confirmed window Inspect 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.

What you can prove right now

Verification pulse

chip

Best height302,409Use it as a live block-height verification example

Sampled txWindow pageOpen the bounded confirmed window

Median time2026-04-29 01:55:16 UTCChain time context

Next halving117,591 blocks25.00000000 BCH subsidy now

Open tx feed Open network sitemap

Choose your proof 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·Recent confirmed

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.

Tx feed·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 recent confirmed activityUse the bounded freshest window when you need a live example first.
3
Open the tx feedFinish on a machine-readable surface for monitoring.

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.

Researcher / AI

The route contract is explicit

Machine consumers should not need to reverse-engineer the explorer from rendered fragments.

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

Open the freshest confirmed window

When no sampled transaction is available yet, the explorer still gives an honest bounded newest-first window and a machine-readable feed.

Recent confirmed Transaction feed

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

Agents, mirrors, and automation can begin from explicit discovery endpoints instead of brittle scraping assumptions.

Network sitemap Transaction feed

Support-safe evidence bundle

Routes to save, cite, or automate

Need	Best route	Why it matters
Verify a transaction	Recent confirmed activity	The bounded window is the honest fastest route when you need a live confirmed example now.
Machine-readable transaction proof	Transaction feed	The feed is stable for polling and monitoring.
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.