Most systems that call themselves audit logs are ordinary databases with an extra column for the time. An administrator with the right access can change a row, adjust a timestamp, or remove an entry, and in a well-run system that edit will look exactly like a legitimate one. The first article in this series showed how often provenance fails across supply chains, intellectual property, and documents. This article explains the mechanism that fixes it. The key distinction is not whether a record exists. It is whether the party holding the record could have altered it after the fact without anyone being able to tell. That property has a name, tamper-evidence, and it is built from two simple ingredients: a cryptographic hash and an independent timestamp anchor.
A Hash Is a Fingerprint for Data
A cryptographic hash function takes any input, a contract, an image, a dataset, a firmware build, and produces a short string of fixed length, often 64 hexadecimal characters. The same input always yields the same output, and changing a single byte of the input produces a completely different output that gives no hint of how small the change was. A modern hash like SHA-256 has two properties that make it useful here. It is practically impossible to find two different inputs that produce the same hash, and it is impossible to reverse the hash back into the original data. So a hash works as a fingerprint. Publishing the fingerprint reveals nothing about the file, but anyone who later holds the file can recompute its hash and confirm it matches. If even one character changed, the fingerprints will not match.
This already solves half of provenance. To prove a document has not been altered since some moment, you do not need to publish the document. You only need to have published its hash at that moment, and to keep the document so you can recompute the hash on demand. The remaining half is proving when the fingerprint was published, and that is where timestamping comes in.
The Trusted Timestamp Authority Model
The established standard for this is RFC 3161, which defines a Time-Stamping Authority, or TSA. You send the TSA a hash, and it returns a signed token binding that hash to a time, vouched for by the authority's cryptographic signature. This is genuinely useful and widely used in software signing and document workflows. It has two structural limits worth understanding.
The first is that a TSA is a single point of trust. The token is only as good as the authority behind it. If the authority is compromised, coerced, or simply mistaken, the timestamps it issued inherit the problem, and you are back to trusting one operator. The second limit is operational. A TSA token depends on the authority's public-key certificate chain, and those certificates typically expire after one to three years. To keep an old proof valid, you generally have to re-timestamp it before the certificate lapses. For a record meant to hold up for a decade, that is a recurring maintenance burden and another dependency on the authority's continued existence and good standing.
Anchoring to a Public Blockchain
A second approach removes the single authority. Instead of one signer vouching for the time, you commit the hash to a public blockchain, where it becomes part of a record that no single party controls and that is expensive to rewrite. OpenTimestamps, created by the Bitcoin contributor Peter Todd, is the best-known implementation. It collects many document hashes, combines them efficiently into a single fingerprint using a Merkle tree, and anchors that one fingerprint into the Bitcoin blockchain with a single transaction. Each document then gets a compact proof file, with the .ots extension, that links its hash through the tree to a specific Bitcoin block.
The difference from the TSA model is who you have to trust. To verify an OpenTimestamps proof, you do not trust an authority. You check the math against Bitcoin's public ledger, something anyone running a node can do independently, now or years from now. The time comes from the block, and altering it would mean rewriting Bitcoin's history, which the network's accumulated proof-of-work makes prohibitively costly. There is no certificate to renew and no company whose survival the proof depends on.
The Legal Layer
None of this is purely technical. Regulators have begun to recognize electronic timestamps as evidence. In the European Union, Article 41 of the eIDAS regulation states that an electronic timestamp may not be denied legal effect or admissibility as evidence in legal proceedings solely because it is in electronic form or does not meet the requirements of a qualified timestamp. A qualified electronic timestamp goes further and enjoys a legal presumption that its date and time are accurate and that the bound data has not changed, recognized across all member states. The direction of travel is clear: a verifiable timestamp is increasingly treated as real evidence, not a curiosity.
Why the Operator-Controlled Log Falls Short
Return to the audit log that an administrator can edit. It may record exactly the same hash and the same time as an anchored record. The difference is the trust assumption. With the internal log, you are trusting that the operator did not change the entry, and crucially you usually cannot prove they didn't, because the system that would record a tampering is the same system the operator controls. With an anchored record, the proof stands on its own. Anyone holding the file and the proof can confirm the file existed in that exact form at that time, without trusting the party who created it.
That is the whole point of tamper-evidence. It does not stop someone from trying to alter a record. It guarantees that if they do, the alteration becomes detectable, because the published fingerprint will no longer match. An operator-controlled log offers tamper-resistance at best, a lock that the operator holds the only key to. An anchored record offers tamper-evidence, a seal that anyone can inspect.
One honest caveat applies to both approaches. Anchoring proves that a specific file existed in a specific form at a specific time. It does not, by itself, prove that the contents were true or that the right person submitted them. Garbage anchored is still garbage, now durably timestamped. Provenance systems close that remaining gap with identity, signatures, and process around the anchor. The anchor's job is narrow and essential: it makes the record's existence and integrity checkable by anyone. The final article shows how Mintlayer's IP Notary applies this to any digital asset on a Bitcoin-anchored ledger, and why the chain underneath the proof is what makes it durable.
This article is for informational purposes only and does not constitute investment advice.
Mintlayer Web Services provides Bitcoin-native infrastructure for notarizing and settling assets so integrity is anchored to the base layer, not held in a log one party can edit. Learn more →
