HashAnchor Guide

Verifying receipts

Offline inclusion is not on-chain verification, and neither one says the data is true. Being precise about this is what makes a receipt worth relying on.

Three checks#

If you need assurance that does not depend on TLAY, read the anchor transaction yourself — it is the only check that trusts no one.

Check the proof, offline#

verifyReceiptProof(receipt) hashes from hash through each proof step and compares the result with merkleRoot. It never touches a network, so it cannot tell you the root was really anchored.

Ask the service#

client.verify(hash) — or GET /v1/verify/:hash — checks the Merkle proof and the anchor transaction, and returns { verified, status, anchor }. No API key needed. It trusts the HashAnchor service.

Read the anchor yourself#

Open anchor.txHash on the explorer for anchor.chainId, and confirm the transaction committed the same root as the receipt's merkleRoot. This trusts only the public chain.

What a valid receipt proves#

These exact bytes hash to a leaf under this Merkle root.
With the anchor, the root — and so the record — existed no later than that block.
The record has not changed since: one altered byte and the path no longer arrives at the root.

What it does not prove#

That the data is true. A sensor that lies produces a perfectly anchored lie. Anchoring proves existence and integrity, never correctness.
Who produced it. Authorship comes from a signature over the record — what BoAT MER gives a device — not from anchoring.
That it existed before it was submitted. The timestamp you can prove is an upper bound only.

Tip

Have the device sign the record with BoAT MER, then anchor it. The signature says which machine produced it; the receipt says it has not changed since.