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 Truestamp’s newest internal block at the moment you submitted; that record could only be assembled after the block existed, 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: the identifier and hash of Truestamp’s newest internal block when you submitted. 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 every item whose claims carry it, answering “do I already have a timestamp for this data”. If the system had folded its own metadata into the claims fingerprint, you could no longer check it without also reconstructing everything the system added.
• The submission window is committed on its own. The timing fingerprint records which internal block 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. 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 records the identifier and hash of Truestamp’s newest internal block at the moment you submitted, which forms the submitted-after edge: your item was submitted after that block existed. 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 newspaper proves the bundle was put together after that paper was printed, and says nothing about when the photo’s subject was born. The timing fingerprint is the newspaper, the claims fingerprint is the photo, and the composite fingerprint is the staple that makes the bundle inseparable.

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.

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.