Verifier independence

How verification works

Every TrustNotch proof is self-contained. Verification runs entirely on your machine — no API call, no account, no TrustNotch server. Here is exactly what the verifier checks and why each step matters.

Proof structure

What a proof bundle contains

Once an entry's batch is anchored, TrustNotch can produce a proof bundle: a single document with everything needed to verify the entry offline.

Receipt

An Ed25519 signature over the entry's RFC 6962 leaf hash, issued at submission time. Proves the exact content that was accepted.

Merkle path

The sibling hashes needed to recompute every node from this leaf up to the batch's Merkle root, per RFC 6962.

Bitcoin anchor

An OpenTimestamps proof: a chain of hash operations from the batch root to a value it claims sits in a specific Bitcoin block. Once that value is matched against the real block, it shows the batch existed before the block was mined.

Step by step

Three checks, all local

  1. Verify the receipt

    The verifier computes the RFC 6962 leaf hash of the submitted content — SHA-256(0x00 || entry) — and checks the Ed25519 signature in the receipt against TrustNotch's public key. If the entry's content was changed after submission, the signature check fails.

    The verifier ships with TrustNotch's published public keys built in, so this check needs no network at all. The same keys are published at /v1/keys for comparison, and you can point the verifier at your own copy with --keys. The MCP server's verify tools fetch the keys from /v1/keys, or read a pinned file set in TRUSTNOTCH_PUBKEYS_PATH.

  2. Verify Merkle inclusion

    Using the sibling hashes in the Merkle path, the verifier recomputes each interior node up to the batch root, following the RFC 6962 construction: interior nodes are SHA-256(0x01 || left || right). The computed root must match the root the OpenTimestamps proof commits to. The receipt does not carry the root: it was signed at submission, before the batch existed, and it covers the leaf.

    This step proves the entry is in the specific batch, not merely that the batch root is anchored somewhere. An entry that was not included cannot produce a valid Merkle path to the committed root.

  3. Verify the Bitcoin anchor

    The verifier parses the OpenTimestamps proof and checks that it starts from your batch root and arrives at a committed value for a named Bitcoin block. This check is structural and runs fully offline: it confirms the proof is well formed and belongs to your batch. One comparison is left to you on purpose. The committed value must equal the Merkle root of the named block, which any Bitcoin node or block explorer can show you, so this step needs no trust in TrustNotch either. Once it matches, the batch is proven to have existed before that block was mined.

    Bitcoin anchoring is asynchronous: the signed receipt is returned at submission time, and the Bitcoin anchor accrues over the following hours as the OpenTimestamps calendars aggregate and a block is mined. The receipt alone proves the exact content; the Bitcoin anchor bounds it in time.

Why it matters

The guarantee that holds without us

All three checks run locally. The math does not involve TrustNotch — once a proof is in your hands, it is yours. A proof that verifies today keeps verifying, even if TrustNotch has shut down. It depends only on the bundle you hold, open-source code, and the strength of SHA-256 and Ed25519.

This is deliberately different from "trust our immutability claims." A signed receipt from a vendor that controls its own database is an assertion; a proof you can recompute yourself, and match against Bitcoin's public chain, is evidence anyone can check. The distinction matters in a compliance audit or legal proceeding where "we say it's immutable" is not acceptable.

Because the verifier is open source, anyone can read what it does. There is no black box — the verification logic is the same whether you run the trustnotch CLI, the verify_proof MCP tool, or implement the three checks yourself from the RFC 6962 and OpenTimestamps specs.

Try it yourself

Install the standalone verifier

The trustnotch verifier is open source, published to PyPI with provenance attestation, and has no runtime dependency on TrustNotch. 

# Install
pip install trustnotch

# Verify a proof bundle offline
trustnotch verify proof.json

Source mirror: github.com/trustnotch/trustnotch.  PyPI: pypi.org/project/trustnotch.

Related
MCP Server → Use TrustNotch from Claude Desktop and other MCP clients, including the verify_proof tool. Why it matters → The regulatory case: EU AI Act Article 12 and why "trust us" logging is not enough. FAQ → Common questions about trust, GDPR erasure, Bitcoin anchoring, and access.