Independent Verification
Methodology Version 2.0 — Effective February 2026
A TrackForge certification is designed to be verifiable by any party, at any time, without requiring access to TrackForge systems. This is the distinguishing property of the certification: the proof does not depend on the certifier's continued existence, cooperation, or honesty.
Three-step verification process
Verification follows three steps. Each step uses standard cryptographic tools available in every major programming language and operating system.
Step 1: Re-compute the hash
Take the canonical JSON string (included in the certification proof bundle) and compute its SHA-256 hash using any standard implementation:
SHA-256( canonical_json_bytes ) → 64-character hex digest
Compare the computed digest with the record_hash stated in the certificate. If they match, the canonical JSON has not been altered since certification. If they do not match, the metadata has been modified.
This step requires only the canonical JSON string and any SHA-256 implementation. No TrackForge software or network access is needed.
Step 2: Verify the Merkle inclusion proof
The certificate includes a Merkle inclusion proof: a compact set of sibling hashes and directions (left or right) from the track's leaf hash to the Merkle root.
To verify:
- Start with the track's hash (confirmed in Step 1)
- For each sibling hash in the proof, concatenate it with the current hash in the specified direction and compute SHA-256
- After processing all proof elements, compare the result with the stated Merkle root
If the computed root matches the stated root, the track is confirmed as part of the certified batch. If it does not match, either the proof is invalid or the track was not part of the original batch.
Step 3: Verify the blockchain anchor
Confirm that the Merkle root hash is recorded in the referenced blockchain transaction. This can be done using:
- Any public blockchain explorer (e.g., blockstream.info, mempool.space)
- A local blockchain node (for maximum independence)
- The OpenTimestamps verifier (
ots verifycommand-line tool)
The OpenTimestamps proof file (.ots format, included in the proof bundle) contains the complete cryptographic path from the Merkle root to the block header. Verification confirms that the hash was committed to the blockchain1 at the stated time.
No data transmission required
The verification process is designed to be performed entirely locally. At no point is it necessary to send the canonical JSON, the track metadata, or any commercially sensitive information to TrackForge or any other third party.
The public verification page at trackforge.studio/verify provides a browser-based verification tool that performs Step 1 entirely client-side using the Web Crypto API. The canonical JSON is hashed in the browser; no data is transmitted to TrackForge servers. Steps 2 and 3 are performed server-side using only the hash (not the underlying data).
Proof bundle contents
Each certification produces a proof bundle that contains everything needed for independent verification:
| Component | Purpose |
|---|---|
| Canonical JSON (per track) | The exact data that was hashed; input to Step 1 |
| Record hash (per track) | The SHA-256 digest to verify against |
| Merkle inclusion proof (per track) | Sibling hashes and directions for Step 2 |
| Merkle root | The batch-level commitment anchored to the blockchain |
OpenTimestamps proof file (.ots) | Complete cryptographic path to the block header |
| Blockchain transaction ID | Reference for blockchain explorer verification |
| Block number and timestamp | When the anchor was confirmed |
| Operator audit trail | Record of human review actions (B2B engagements) |
| Methodology version | Which version of this methodology governed the certification |
| Methodology hash | SHA-256 of the complete rating ruleset; proves the exact criteria in effect |
Methodology criteria (methodology.json) | Machine-readable serialisation of all rating thresholds; input to the methodology hash |
Methodology OTS proof (methodology_standard.ots) | OpenTimestamps proof anchoring the methodology hash to Bitcoin; proves rules predated certification |
The proof bundle is self-contained. If TrackForge ceased to exist, a verifier with only the proof bundle and access to the blockchain could independently confirm every certification.
What verification proves
A successful three-step verification confirms:
- Data integrity — The metadata has not been altered since certification (Step 1)
- Batch inclusion — The track was part of the specific certified batch (Step 2)
- Temporal proof — The certification existed at the stated time, as recorded on the blockchain (Step 3)
- Methodology integrity — The rating was governed by a specific, published set of criteria, as confirmed by the methodology hash (Step 4 of rating verification)
Verification does not prove that the metadata is legally correct or that no competing claims exist. It proves that the metadata was in the certified state at the certified time, and that it has not been altered since. See the overview of certification scope for the precise boundaries of what certification asserts.
Verifying a rating (not just a certification hash)
The three steps above verify that the certified data has not been altered and was anchored at the stated time. TrackForge's Rating Oracle adds a further layer of verifiability: because the rating is produced by a deterministic pure function applied to published criteria, an independent party can also verify the rating itself.
To verify a rating:
- Obtain the catalogue data snapshot — The same data the Rating Oracle evaluated. This is included in the proof bundle's canonical JSON records.
- Apply the published methodology — The rating criteria are published as the Rating Methodology, with exact thresholds for each of the six completeness levels and three assurance levels. The decision trees are deterministic: identical inputs always produce identical outputs.
- Compare evidence hashes — Each track rating includes a SHA-256 evidence hash computed from the canonical JSON. Recompute the hash from the canonical data and confirm it matches.
- Verify the methodology hash — Each rating includes a
methodology_hashfield: a SHA-256 digest of the complete rating ruleset. Recompute the hash from the published criteria (available inmethodology.jsonin the proof bundle) and confirm it matches. This proves the exact thresholds and criteria that governed the rating. - Verify the standard version — Every rating output records the global standard version (e.g.,
GLOBAL_STANDARD_v1.0). Confirm that the published methodology for that version matches the criteria applied.
5. Verify the methodology anchor
The proof bundle includes a methodology_standard.ots file — an OpenTimestamps proof that anchors the methodology hash to the Bitcoin blockchain independently of the certification anchor. To verify:
- Extract the
methodology_hashfrom the certification record. - Use the OpenTimestamps verifier (
ots verify methodology_standard.ots) to confirm that this hash was committed to a Bitcoin block. - Confirm that the Bitcoin block timestamp for the methodology anchor predates the certification timestamp.
This proves that the rating rules were locked in before the certification was issued. TrackForge cannot have adjusted methodology thresholds after the fact to produce a more favourable result, because the methodology hash was committed to an immutable public ledger before the certification process began.
The methodology anchor can also be verified programmatically via the /verify/methodology endpoint, which returns the methodology hash, the anchoring transaction, and the block timestamp.
If the independently computed rating matches the published rating, this confirms that the rating was produced by faithful application of the stated methodology to the stated data — not influenced by the enrichment engagement.
For the technical architecture ensuring rating independence (Chinese Wall), see Rating Independence.
Related methodology pages
- Hashing — The SHA-256 algorithm used in Step 1
- Merkle Tree Construction — The tree structure and inclusion proofs used in Step 2
- Blockchain Anchoring — The OpenTimestamps protocol verified in Step 3
- Re-Certification — How verification applies to tracks with multiple certification versions