Blockchain Anchoring
Methodology Version 1.0 — Effective February 2026
Once the Merkle tree has been constructed and a single root hash produced for the certification batch, that root hash is anchored to a public blockchain via the OpenTimestamps protocol. This creates a permanent, tamper-proof record that the hash existed at a specific point in time — a record that is independent of TrackForge and verifiable by anyone.
TrackForge currently uses the Bitcoin blockchain via the OpenTimestamps protocol. The properties described on this page — immutability, independence, transparency, cost efficiency — are properties of the blockchain verification approach. The technical pages reference Bitcoin specifically where the implementation details require it.
The OpenTimestamps protocol
OpenTimestamps is an open protocol for creating timestamps backed by a blockchain. The process works as follows:
Current implementation
-
Submission — The Merkle root hash is submitted to one or more OpenTimestamps calendar servers as a raw 32-byte SHA-256 digest.
-
Aggregation — Calendar servers aggregate multiple timestamp requests from different parties into their own Merkle tree. This aggregation means that many timestamps share a single Bitcoin transaction, making the process cost-efficient.
-
Bitcoin transaction — The calendar server's aggregated Merkle root is embedded in a Bitcoin transaction, which is broadcast to the Bitcoin network. Calendar servers typically commit once per Bitcoin block (approximately every 10 minutes).
-
Confirmation — Once the Bitcoin transaction is included in a confirmed block, the timestamp is permanent. The block number, transaction ID, and confirmation timestamp are recorded.
-
Proof upgrade — The initial proof returned by the calendar server is a "pending" proof. Once the Bitcoin transaction is confirmed (typically within 1-3 hours), the proof can be "upgraded" to include the full path from the submitted hash to the Bitcoin block header.
Why blockchain verification?
| Property | Significance for certification |
|---|---|
| Immutability | Once confirmed in a block, blockchain transactions cannot be altered, reversed, or deleted. The timestamp is permanent for as long as the blockchain network exists. |
| Independence | Verification does not require TrackForge to exist or to cooperate. Any party with access to a blockchain node or a public blockchain explorer can confirm the anchor. |
| Transparency | The blockchain is a public ledger. Anyone can inspect the transaction and verify that it contains the expected hash commitment. |
| Cost efficiency | Through the OpenTimestamps aggregation mechanism and TrackForge's own Merkle tree, a single blockchain transaction covers an entire catalogue batch — regardless of whether it contains 10 tracks or 100,000 tracks. |
| Decentralisation | No single entity controls the blockchain. The timestamp does not depend on the continued operation of any single company, government, or institution. |
TrackForge selected the Bitcoin blockchain for these properties due to its maturity, security track record, and the availability of the OpenTimestamps protocol.
What is recorded on the blockchain
The blockchain anchor contains only the Merkle root hash — a 64-character hexadecimal string derived from the Merkle tree. No personal data, no metadata content, no track titles, no writer names, no IPI numbers, and no commercially sensitive information is written to the blockchain.
The relationship between the Merkle root and the individual track data is established through the inclusion proofs stored in the certification database and proof bundles, not through the blockchain itself.
Proof data
Each blockchain anchor produces an OpenTimestamps proof file (.ots format). This binary file contains the cryptographic path from the submitted hash, through the calendar server's aggregation tree, to the block header. The proof file is:
- Included in the certification proof bundle delivered to the catalogue owner
- Stored in the certification database for future verification
- Self-contained: it can be verified using the
otscommand-line tool or any compatible verifier, without contacting TrackForge or the calendar server
Anchoring record
For each certification batch, TrackForge records:
| Field | Description |
|---|---|
| Chain | The blockchain used |
| Status | Pending, confirmed, or local-only |
| Submitted at | UTC timestamp of submission to calendar server |
| Calendar URL | Which OpenTimestamps calendar server accepted the submission |
| Transaction ID | The blockchain transaction ID (once confirmed) |
| Block number | The block number (once confirmed) |
| Block timestamp | The UTC timestamp of the confirming block |
| Proof data | The binary OpenTimestamps proof file |
Graceful degradation
If all OpenTimestamps calendar servers are unreachable at the time of certification (a rare but possible scenario, as calendar servers are volunteer-operated), the system degrades gracefully:
- The certification proceeds with a local-only status
- The Merkle root, canonical JSON, and all other certification data are stored normally
- The blockchain anchor is retried when calendar servers become available
- Local-only certifications are clearly marked and do not claim blockchain verification until the anchor is confirmed
This ensures that certification is never blocked by transient network issues, while maintaining transparency about the anchoring status.
Related methodology pages
- Merkle Tree Construction — How the root hash that gets anchored is produced
- Independent Verification — How third parties verify the blockchain anchor
- Hashing — The SHA-256 algorithm used throughout the pipeline