Skip to main content
Version: v2.0

Hashing

Methodology Version

Methodology Version 1.0 — Effective February 2026

Once a Golden Record has been transformed into its canonical form, the next step is to compute a cryptographic hash — a fixed-length digest that uniquely represents the metadata state. This hash is the foundation upon which Merkle tree construction and blockchain anchoring are built.

Algorithm: SHA-256​

TrackForge uses SHA-256 (Secure Hash Algorithm 256-bit), as specified in FIPS 180-4 (National Institute of Standards and Technology). SHA-256 was selected for the following properties:

PropertyDescription
DeterministicIdentical input always produces identical output. The same canonical JSON will always produce the same hash, regardless of when or where the computation is performed.
Collision-resistantIt is computationally infeasible to find two different inputs that produce the same hash. No two distinct metadata states will share a hash.
IrreversibleThe hash cannot be reversed to recover the original data. The metadata content cannot be derived from the hash alone.
Widely standardisedSHA-256 is supported by every major cryptographic library, every major programming language, and every major operating system. Independent verification requires no specialised software.

Process​

The hashing step takes the canonical JSON string and produces a 64-character hexadecimal digest:

  1. The canonical JSON string (produced by deterministic serialisation) is encoded as UTF-8 bytes
  2. The SHA-256 hash function is applied to the byte sequence
  3. The resulting 256-bit digest is represented as a 64-character lowercase hexadecimal string
Input:  UTF-8 encoded canonical JSON string
Output: 64-character hexadecimal SHA-256 digest

Example​

Given a canonical JSON string for a track, the hash computation produces a digest such as:

Canonical JSON (truncated):
{"artist":"Iron Maiden","certification_version":"1.0","duration_ms":437000,"isrc":"GBAYE9200143",...}

SHA-256 hash:
a3c1f7e2b9d4056831ca9e7f2b8a1d3c5e4f6a7b8c9d0e1f2a3b4c5d6e7f8a9b

Any change to the underlying data — even a single character — produces a completely different hash. For example, correcting a writer's share from 50.00% to 50.01% would produce an entirely unrelated 64-character digest. There is no relationship between the magnitude of the change and the magnitude of the hash difference.

Why hashing matters for certification​

The hash serves three purposes in the certification pipeline:

  1. Integrity verification — Anyone with the canonical JSON can recompute the hash and confirm it matches the certified value. If even one byte of the metadata has been altered, the hash will not match.

  2. Compact commitment — A 64-character string represents an arbitrarily large metadata record. This compact representation is what gets assembled into the Merkle tree and ultimately anchored to the blockchain.

  3. Version chain linkage — When metadata is re-certified, the new certification version references the hash of the previous version, forming a cryptographic linked list. This chain cannot be tampered with: modifying any historical version would change its hash, breaking the chain.

Methodology hash​

TrackForge certifications involve two independent hashes serving different purposes:

HashProvesInput
Record hash (record_hash)Data integrity — the rights-critical metadata has not changedCanonical JSON of the track's metadata
Methodology hash (methodology_hash)Rule integrity — the exact evaluation criteria that governed the ratingAll completeness thresholds, assurance thresholds, and disclosure text

The methodology hash is computed once from the complete set of rating constants: the standard version string, all completeness criteria (thresholds for each of the six levels), all assurance criteria (thresholds for each of the three levels), and the conflict-of-interest disclosure text. This payload is serialised as canonical JSON (sorted keys, no whitespace) and hashed with SHA-256.

If any threshold, criterion, or disclosure text is modified — even by a single character — the methodology hash changes. This allows any verifier to confirm that a given rating was produced by a specific, published set of rules.

The methodology hash is included in:

  • Every track rating produced by the Rating Oracle
  • Every certification batch record
  • The methodology.json file in the proof bundle

Importantly, the methodology hash is separate from the record hash. Changing the rating methodology does not change record hashes for unchanged data, and vice versa. They serve independent verification purposes.

Methodology anchoring​

The methodology hash is not only embedded in certifications — it is independently timestamped on the Bitcoin blockchain via OpenTimestamps, separately from any individual certification anchor. This creates a verifiable proof that a specific set of rating rules existed at a specific point in time.

The proof bundle for each certification includes a methodology_standard.ots file: an OpenTimestamps proof that anchors the methodology hash to a Bitcoin block. Any verifier can use this file to confirm, via the blockchain, that the methodology predated the certification it governed.

This closes the zero-trust loop. A verifier does not need to trust TrackForge's claim that "these were the rules in effect." They can independently confirm:

  1. The methodology hash matches the published criteria (by recomputing SHA-256 from methodology.json)
  2. The methodology hash was anchored to Bitcoin before the certification was issued (by verifying methodology_standard.ots)
  3. The certification references this exact methodology hash (by inspecting the certification record)

If any of these checks fail, the certification's methodology provenance is broken. If all three pass, retroactive modification of the rating rules is mathematically excluded.

Independent reproducibility​

SHA-256 is available in every major programming environment:

  • Python: hashlib.sha256(data.encode('utf-8')).hexdigest()
  • JavaScript: crypto.subtle.digest('SHA-256', data) (Web Crypto API)
  • Command line: echo -n 'data' | sha256sum
  • Go: sha256.Sum256([]byte(data))
  • Java: MessageDigest.getInstance("SHA-256")

No TrackForge software is required to verify a hash. Any party with the canonical JSON (included in the proof bundle) can independently compute the SHA-256 digest and confirm it matches the certified hash.

Last updated on