Verify your receipt · holder's guide

Verify your receipt — without trusting NoData and without disclosing anything sensitive.

Your receipt already contains everything required for verification — the SHA-256 event_hash, the Ed25519 signature, the Merkle inclusion proof, and the epoch reference. The math runs in your browser, on your laptop, or against the Bitcoin blockchain. NoData is never in the verification path.

You never upload your payload. You never reveal your business context. You decide whether to share even the receipt itself · the steps below cover the cases where you keep it private and the cases where you delegate verification to an auditor.

Three paths · pick the trust level you need

From a one-paste browser check to a Bitcoin-rooted offline proof.

01

Web UI · one paste, one click

~10 seconds

Trust assumption · Trusts the browser-side verifier we ship.

You need

Your proof_ref handle (e.g. ND-2026-X8K2M) — given to you in the receipt envelope at issue time.

Steps

Open https://nodatacapsule.com/verify/ref/<your-proof_ref>
The page renders 5 checks · event_hash integrity, HMAC chain link, Ed25519 signature, chain continuity, and Merkle inclusion · all run client-side.
Each check has its own ✓ / ✗ with the technical reason inline. No NoData credential, no account, no payload upload.

02

Offline CLI · open-source verifier

~5 minutes

Trust assumption · Trusts only the public verifier source code + the GitHub witness feed + math.

You need

Your receipt JSON (saved locally when the event occurred).
Internet access to clone the public witness-feed repo · or a previously-cached copy of the relevant epoch JSON.

Steps

git clone https://github.com/proofbydefault/witness-feed && cd witness-feed
Save your receipt JSON to receipt.json (the file we hand you contains event_hash + inclusion_proof + epoch_seal_id).
node verify.mjs --receipt receipt.json --epoch epochs/YYYY-MM/YYYY-MM-DD-HH.json
Output: "✓ Merkle root matches witness feed · event_hash included at position N · Ed25519 signature valid". Returns exit code 0 on success.
For deeper review, read verify.mjs — it is ~200 lines of Web Crypto API code, zero npm dependencies.

03

Bitcoin-deep · OpenTimestamps verification

~30 minutes including Bitcoin node sync

Trust assumption · Trusts only the Bitcoin blockchain. Maximum paranoia mode.

You need

Your receipt JSON (event_hash + inclusion_proof).
The matching .ots.b64 sidecar from the witness-feed repo.
The standalone `ots` CLI (https://opentimestamps.org/).
A Bitcoin node OR a trusted block-height lookup service.

Steps

First confirm Merkle inclusion locally (path 02 above) → you now trust the merkle_root.
Download epochs/YYYY-MM/YYYY-MM-DD-HH.ots.b64 from witness-feed and base64-decode to obtain proof.ots.
ots verify --hash <merkle_root_hex> proof.ots
Output reports the Bitcoin block height and block time at which the root was anchored. Verifiable against any Bitcoin block explorer (independent of NoData and independent of GitHub).
You now have a chain · receipt → Merkle root → Bitcoin block. NoData is not in the verification path at any step.

What you keep private · what's already public

Verification never requires disclosure.

The whole architecture is built so the holder can verify without ever exposing the contents of a transaction · not to NoData, not to the public, not even to an auditor unless the holder chooses to invite one.

Must I upload my payload to verify?

No.

NoData never had your payload. Only its SHA-256 hash entered the chain. Verification operates on the hash · the original bytes stay with you.

Must I share my proof_ref with a third party?

Only if you choose to.

Sharing the proof_ref lets the other party verify YOUR receipt. It reveals nothing about content or business context. Many holders share it only with their auditor or counterparty.

Can a third party verify my receipt without me sharing anything?

Not directly — and that is by design.

The proof_ref is the access handle. Without it, no one can enumerate your receipts or correlate them to your tenant. Public observers only see aggregate counts and Merkle roots.

Will the public Merkle root or Bitcoin anchor leak my activity?

No.

Merkle leaves are lexicographically sorted before hashing · arrival order is erased. Two hours with the same set of receipts produce the same root. No timing inference, no enumeration vector, no tenant identification.

What about NoData being compelled to hand over data?

A compelled disclosure would expose receipts NoData holds — never the verification path.

Verification uses the public witness feed + Bitcoin. Even if NoData were forced to release internal records, the integrity chain is verifiable without them and against them.

What if NoData ceases to operate?

Verification still works.

The Ed25519 public key is mirrored at /api/chain/pubkey AND in the witness-feed repo. The Merkle roots live in GitHub. The Bitcoin anchors live in the Bitcoin blockchain. Verification has zero NoData dependency.

What's already public · safe to inspect, link, or archive

Ed25519 public key · at /api/chain/pubkey · mirrored in the witness repo · used to verify every signed Merkle root.
Witness feed (Merkle roots) · proofbydefault/witness-feed/epochs · one JSON commitment per UTC hour · append-only · no payloads, no IDs.
OpenTimestamps proofs · alongside each Merkle root as *.ots.b64 sidecars · upgradable to Bitcoin-confirmed attestations within ~24h.
Open-source verifier · witness-feed/verify.mjs · Web Crypto API · zero npm dependencies · ~200 lines · reviewable in one sitting.
Aggregate transparency stats · at /transparency · counts and roll-up roots only · no per-event detail, no timing signal.

Verify your receipt — without trusting NoData and without disclosing anything sensitive.