How to Verify Independently

A TrackForge certification is designed to be verifiable by anyone, at any time, without needing to contact or trust TrackForge. This page describes three methods, from simplest to most thorough.

Method 1: Online verification

The quickest way to verify a certificate.

1. Go to trackforge.studio/verify.
2. Paste the canonical_json field from your certificate into the input box.
3. The page computes the SHA-256 hash in your browser and checks it against the certification records.

Your data stays private

The hash is computed entirely in your browser using the Web Crypto API. The canonical JSON is never transmitted to TrackForge's servers — only the resulting hash is checked. You can verify this by inspecting the network traffic in your browser's developer tools.

Limitations: This method relies on TrackForge's verification service being available. For verification that works regardless of TrackForge's operational status, use Method 2 or 3.

Method 2: From the Proof Bundle

The Proof Bundle is a self-contained ZIP archive that includes everything needed for independent verification. This method requires no internet connection and no reliance on TrackForge.

What you need

• The Proof Bundle ZIP file
• A SHA-256 tool (built into macOS, Linux, and Windows; also available online)
• An OpenTimestamps verifier (optional, for blockchain confirmation)

Step-by-step

Step 1 — Extract the bundle

Unzip the Proof Bundle. You will see files including catalog_report.json, chain_of_title.json, a tracks/ directory, merkle_tree.json, and a proofs/ directory.

Step 2 — Open the track data

Open the track's JSON file from the tracks/ directory (named by ISRC, e.g. tracks/GBAYE0100538.json), or open chain_of_title.json to see all tracks.

Step 3 — Extract the canonical JSON

Find the canonical_json field. This is the exact string that was hashed during certification.

Step 4 — Compute the SHA-256 hash

Hash the canonical JSON string using any SHA-256 tool:

# macOS / Linux
echo -n '<paste canonical_json here>' | shasum -a 256

# Windows PowerShell
$bytes = [System.Text.Encoding]::UTF8.GetBytes('<paste canonical_json here>')
$hash = [System.Security.Cryptography.SHA256]::Create().ComputeHash($bytes)
[System.BitConverter]::ToString($hash).Replace('-','').ToLower()

Mind the exact string

The canonical JSON must be hashed exactly as it appears in the file — including all whitespace, key ordering, and escaping. Do not reformat or pretty-print it before hashing.

Step 5 — Verify the hash matches

Compare your computed hash with the record_hash field in the track's JSON. They should be identical.

If they match, you have confirmed that the certified data has not been altered.

Step 6 — Verify the Merkle proof

The track's JSON includes a merkle_proof with proof_hashes and proof_directions. Starting from the track's record_hash, combine it with each proof hash in sequence (left or right, as indicated by the direction), hashing at each step. The final result should match the merkle_root in catalog_report.json.

This confirms that the track was included in the certified batch.

Step 7 — Verify the blockchain anchor

Open the corresponding .ots file from the proofs/ directory. Use an OpenTimestamps verifier to confirm that the Merkle root is anchored in the blockchain:

# Using the ots command-line tool
ots verify proofs/batch_<batch_id>.ots

# Or use the online verifier at opentimestamps.org

This confirms that the Merkle root (and therefore every track hash in the tree) existed at or before the time recorded in the blockchain block.¹

Method 3: From scratch

This method uses no TrackForge tools or files at all. It is the most independent form of verification, suitable for adversarial contexts such as legal disputes.

What you need

• The canonical_json for the track (from any source — your certificate, the proof bundle, or a counterparty)
• The claimed record_hash
• The claimed merkle_root and the transaction ID
• Any SHA-256 implementation
• Access to a blockchain explorer (e.g. blockstream.info, mempool.space)

Step-by-step

1. Hash the canonical JSON using any SHA-256 implementation in any programming language. Verify it matches the claimed record_hash.

2. If you have the Merkle proof, walk the proof tree from leaf to root and verify the result matches the claimed merkle_root.

3. Look up the blockchain transaction using the transaction ID on any blockchain explorer. The transaction's OP_RETURN data (via the OpenTimestamps protocol) commits to the Merkle root.

4. Verify the timestamp. The blockchain block timestamp proves the data existed at or before that time. Blockchain blocks cannot be backdated.

Why this matters

This method demonstrates that the certification is not dependent on TrackForge in any way. The cryptographic proofs are based on open standards (SHA-256, Merkle trees, public blockchains, OpenTimestamps). Any competent technical expert can verify them using publicly available tools and a public blockchain — a public ledger that no single party controls.

Summary of verification methods

Method	Requires TrackForge?	Requires internet?	Technical skill needed	Best for
Online	Yes (verification page)	Yes	None	Quick checks
From Proof Bundle	No	No (except blockchain step)	Basic command line	Due diligence, archival
From scratch	No	Yes (blockchain explorer)	Moderate	Legal disputes, adversarial verification

All three methods verify the same underlying cryptographic proof. The difference is in convenience versus independence.

What's next

• The Proof Bundle — Detailed guide to the self-contained verification archive.
• Re-Certification — What happens when certified metadata changes.

Footnotes

1. TrackForge currently uses the Bitcoin blockchain via the OpenTimestamps protocol. See Blockchain Anchoring for implementation details. ↩