Knowledge Base

Overview

When you timestamp something with Truestamp, the item you submit is fingerprinted by two independent hashes that are then bound into one. The claims fingerprint (in code, claims_hash) covers exactly what you submitted and nothing else, so anyone holding a copy of the data can recompute and check it, with no trust in Truestamp required. The timing fingerprint (metadata_hash) covers a small system record naming the item’s witnesses, the public records that already existed at the moment you submitted; that record could only be assembled after those records were published, so it opens the submitted-after edge of your submission window without ever touching your data. Neither fingerprint is built from the other. The item’s composite fingerprint (item_hash) then binds both, together with the item’s identifier and the signing key’s ID, into one final fingerprint: the single value Truestamp signs and places as a leaf in its internal Merkle tree, inside a block that is later committed to a public blockchain. This document explains what each fingerprint covers, why the work is split this way, and why who authored an item is never part of any of them.

What each fingerprint covers

Truestamp computes an item’s fingerprints in order.

• Claims fingerprint (claims_hash). A SHA-256 hash over your submitted data (your “claims”) after that data is put into a single canonical byte-for-byte form. It covers only what you sent: a name, an optional external file hash and its algorithm, an optional description, URL, geographic location, your own timestamp, and any freeform fields. Nothing the system adds is mixed in here, so you can reproduce this hash from your own copy of the data at any time.
• Timing fingerprint (metadata_hash). A SHA-256 hash over a small system-generated record that captures the moment of submission: one hash per witness, naming the public records that already existed when you submitted. The record always names the block then at the head of Truestamp’s internal chain, and it names the newest observation captured from each public randomness source that had one, from the NIST Randomness Beacon, the Stellar ledger, and the Bitcoin blockchain. Hashing this record separately commits the submission-window timing without touching your data. The submission moment is an instant Truestamp records, not an instant it proves; what a proof establishes is the submission window, whose submitted-after edge this fingerprint opens.
• Composite fingerprint (item_hash). A SHA-256 hash that binds four inputs together into one value: the item’s identifier, the claims fingerprint, the timing fingerprint, and the signing key ID (a short 4-byte identifier of the key Truestamp uses to sign the item). The composite fingerprint is the value that becomes a leaf in Truestamp’s internal Merkle tree, and it is the value Truestamp signs. Because it is built from the two independent fingerprints, it commits to both your data and the submission timing at once, while also recording which key signed it.

Each fingerprint uses a distinct one-byte domain-separation prefix so that a hash computed for one purpose can never be mistaken for a hash computed for another: the claims fingerprint, the timing fingerprint, and the composite fingerprint each reserve their own prefix byte. The mechanics of that prefixing are covered in the hashing and domain separation concept, and the full list of reserved prefix bytes is in the byte-prefix registry. Entropy observations mirror this pattern exactly under their own prefixes, and blocks bind their Merkle root, previous-block link, and metadata hash into a composite of their own.

Kept apart, bound together

Splitting the work into two independent fingerprints and one binding keeps three concerns cleanly separated, which a single combined hash could not do.

• Your data stays pure and independently verifiable. Because the claims fingerprint is computed over exactly what you submitted and nothing else, you never have to trust Truestamp to reproduce it. You take your own copy of the claims, put it into the same canonical form, hash it, and compare it to the stored claims fingerprint to confirm nothing changed. Separately, if you submitted an external file’s hash as part of your claims, that same hash is stored inside your claims and is itself searchable: pasting it into the search page finds the public items whose claims carry it, plus, when you are signed in, the items in your own teams, answering “do I already have a timestamp for this data”. If the system had folded its own metadata into the claims fingerprint, you could not check it without also reconstructing everything the system added.
• The submission window is committed on its own. The timing fingerprint records which public records preceded your submission. Keeping it in a separate hash means the timing evidence is committed to cryptographically, but it lives in its own record instead of contaminating your data. It also means the evidence can travel: because the record is a small map of names to hashes rather than an opaque digest, a proof can carry the witnessed records themselves and let a verifier rehash each one. This is one half of the submission window described below.
• One value carries everything into the tree. The composite fingerprint binds the identifier, your claims fingerprint, the timing fingerprint, and the signing key ID into a single leaf value. That gives the Merkle tree, and any later proof, exactly one hash to work with while still being tied back to both the data and the timing. Building it from the two fingerprints means changing either your data or the recorded timing would change the composite fingerprint, and therefore the leaf, and therefore any inclusion proof over it. See inclusion proofs for how that leaf is later proven to belong to a block.

The submission window

The timing fingerprint is what lets a proof state a submission window rather than a single instant. It names the witnesses that already existed at the moment you submitted, which forms the submitted-after edge: your item was submitted after those records were published. Every witness carries a time, but not every time is worth the same. An entropy witness carries the publication time its own outside source set, and a verifier can go back to that source and re-fetch the record to confirm it, so the operative edge is the latest entropy witness confirmed that way. The head block carries the time Truestamp minted it, which is Truestamp’s own assertion rather than an outside publisher’s: it stands as the edge only when no outside source could be confirmed in that run, and its other job is fixing where your submission sits in the internal chain. Later, when your item is placed into a finalized block, that assigned block forms the submitted-before edge: your item was submitted before that block existed. Together these two edges prove a submission window, not a claimed creation time. Truestamp proves when data was submitted, never when it was originally created.

A familiar picture makes the mechanism concrete: stapling a photo to today’s newspapers proves the bundle was put together after those papers were printed, and says nothing about when the photo’s subject was born. The timing fingerprint is the stack of newspapers, the claims fingerprint is the photo, and the composite fingerprint is the staple that makes the bundle inseparable. Taking several papers rather than one is the point: if a single publisher went quiet, its edition would be stale, and the freshest of the others still dates the bundle.

Authorship is never hashed

None of these fingerprints include who authored the item. The claims fingerprint covers only your submitted data. The timing fingerprint covers only the submission-timing record. The composite fingerprint binds together the identifier, the claims fingerprint, the timing fingerprint, and the key identifier of the signing key, and nothing else. The account that ran the submission, the current owner of the item, and the team it lives in all sit outside every one of these hashes.

This is deliberate. It means an item’s composite fingerprint stays stable even as ownership is reassigned or the item is moved between teams, so an inclusion proof made before such a change is still valid afterward. It also means the fingerprint makes no claim about authorship at all: proving an item is included in a block proves the data existed and when it was submitted, not who originally created it. The separation between an item’s immutable, audit-only authorship and its transferable ownership is covered in ownership versus authorship.

The preimage is the stored map, exactly as stored

Each of the two leading fingerprints is a hash over a whole map, canonicalized with JCS and prefixed with its domain byte. No field list is involved and there is no selection step: every key present in the stored claims contributes to the claims fingerprint, and every key present in the stored metadata contributes to the timing fingerprint. That is what lets anyone holding the stored maps recompute both hashes and arrive at the same composite fingerprint the Merkle tree committed.

The invariant this places on the system is easy to state and easy to violate: whatever reads a stored map back has to hand over the whole map. A read that narrows the map to some schema’s current field list would make the fingerprint depend on that schema rather than on the data, and the asymmetry that follows is unforgiving. Adding a field stays safe, because an item that never carried it hashes identically either way. Removing or renaming one would retroactively change the recomputed hash of every item that did carry it, and those items were committed under the old name.

Truestamp therefore reads both maps back whole. Field-level validation still runs, but it runs on the way in, where a schema belongs: a map being written is checked and narrowed before it is hashed, so what is hashed and what is stored are the same bytes, and what is read back is those bytes again. The retrieval path holds no opinion about which keys the current schema happens to name.

The same rule covers every stored map a hash is computed over, not only an item’s two. An entropy observation’s captured payload and its metadata, and a block’s metadata, are each hashed the same way and read back the same way.

Should a stored map ever stop reproducing its committed hash regardless, Truestamp treats that as a reason to refuse to generate a proof for the item, never as licence to issue a proof over the map it can currently see. Such a proof would carry a subject hash absent from the block’s Merkle tree, so no verifier could confirm it. See the proof lifecycle.

Limitations

• The claims fingerprint proves the integrity of the data you submitted and that you can reproduce it; it does not prove that the underlying real-world facts in that data are true.
• The composite fingerprint proves the submission window, not an original creation time, and not who authored the data.
• A composite fingerprint alone does not prove inclusion in a block. That requires an inclusion proof over the Merkle tree, and public-blockchain evidence that the block existed. Those are separate steps documented in the verification and merkle concepts.