OpenTimestamps Integration

TrackForge uses OpenTimestamps (OTS) to create independently verifiable timestamp evidence for methodology hashes and evidence roots.

What Is Submitted

TrackForge stores hashes as 64-character lowercase hexadecimal SHA-256 strings. For OTS submission, the implementation:

1. Validates that the value is a 64-character lowercase hex digest.
2. Decodes the hex string to 32 bytes with bytes.fromhex(hash_hex).
3. Computes SHA256(decoded_hash_bytes).
4. Submits that 32-byte commitment to OTS calendar servers.

This means the OTS commitment is a SHA-256 commitment of the decoded hash/root bytes. It is not the raw ASCII string of the Merkle root.

Submission Flow

The proof bundle should include both the original hash value and the .ots proof file, so an independent verifier can reproduce the commitment and validate the timestamp.

Proof States

State	Meaning
pending	Calendar proof exists or submission is awaiting confirmation.
confirmed	Proof contains confirmed blockchain attestation.
failed	Submission or upgrade failed.
not_submitted	No OTS submission was made.
local_only	Local witness only; not a public blockchain confirmation.

Certificate and verification pages must not blur pending, confirmed, failed, and local-only states.

Calendar Servers

TrackForge submits to configured OTS calendar servers. Calendar availability is external to TrackForge; if calendars are unreachable, the system can preserve a local witness state so certification work is not silently blocked. That state must be labelled as local-only rather than confirmed.

Verification Without TrackForge

To verify a confirmed proof:

1. Recompute the relevant evidence or methodology hash.
2. Decode the 64-character hash to bytes.
3. Compute the OTS commitment hash.
4. Verify the .ots file with a compliant OpenTimestamps verifier.
5. Confirm the verified commitment corresponds to the certificate's hash/root.

The certificate should provide enough information for this process without requiring access to TrackForge systems.