Overview

Truestamp turns a piece of data into a small, self-contained proof that makes three affirmative claims, all of them checkable by anyone with no trust in Truestamp: the exact bytes of the data existed in that exact form (data integrity), those bytes were submitted to Truestamp inside a provable time window bracketed by transactions on public blockchains (submission window), and every one of these facts can be re-derived offline from the proof itself without contacting a Truestamp server. A proof is a downloadable artifact (JSON or a compact binary form) that carries all the cryptographic material a verifier needs, so it keeps working even if Truestamp is offline or shuts down.

This concept covers what a proof does establish. What a proof deliberately does not establish (original creation time, authorship, or anything about the meaning of the data) is covered in what a proof does not prove.

Data existence and integrity

The strongest and simplest guarantee is integrity: a valid proof shows that a specific sequence of bytes existed, and that not a single byte has changed since.

The mechanism is a hash. Truestamp reduces your data to a 64-character SHA-256 fingerprint. Change one byte of the data and the fingerprint changes completely, so a verifier who re-hashes the same data and gets the same fingerprint knows the data is byte-for-byte identical to what was timestamped. There are two equally valid ways to submit the data behind that fingerprint:

• Hash of an existing file. You compute the fingerprint of a file on your own device and submit only the fingerprint plus a short label. The proof later attests that those exact bytes existed within the submission window. You keep the original file; the proof plus the file together demonstrate integrity.
• The data itself. When the thing you want to attest is the content you are submitting (a written statement, a disclosure, a structured record), you submit that content directly. Truestamp canonicalizes it to a single deterministic byte representation, fingerprints that, and folds it into the proof. No separate file is needed; the proof alone reconstitutes the timestamped data.

Both modes produce the same shape of proof and are verified the same way.

From your fingerprint to a single block fingerprint

Your item’s fingerprint does not sit alone. It is combined into a Merkle tree, a structure that folds many fingerprints into one root fingerprint by hashing them together in pairs, level by level, until a single value remains. Each Truestamp block (a roughly one-minute page of the ledger) has one such root that binds every item submitted in that window.

A proof includes an inclusion proof: the short list of sibling fingerprints along the path from your leaf up to the root. A verifier starts from your item’s fingerprint, walks that path hashing pair by pair, and must arrive at exactly the block’s recorded root. If your data were altered, or your fingerprint swapped for another, the walk would produce a different root and the check would fail. The tree uses distinct prefix bytes for leaves and internal nodes (RFC 6962 domain separation), which prevents an attacker from passing an internal node off as a leaf, and comparisons run in constant time so they leak no information through timing.

The end result of this layer: the proof binds your exact bytes to one block’s root fingerprint, and any tampering anywhere in the chain breaks the match.

What a proof can attest

Most proofs attest a piece of your data, but a proof is not limited to that. The same proof format and the same verification steps also attest the pieces of Truestamp’s own public ledger. A proof can attest a block (one roughly one-minute page of the ledger), a beacon (a public heartbeat value the ledger publishes), or an entropy observation (an outside public randomness value, from sources such as NIST, Stellar, or Bitcoin, that Truestamp records into a block). Each of these is verified against the public blockchains in exactly the same way as a data proof, so anyone can confirm them offline without trusting Truestamp.

These subject types are not interchangeable. Every proof carries a small type marker that names what it attests (data item, block, beacon, or which entropy source), and that marker is folded into the value that Truestamp signs. Because the marker is part of the signature, a proof for one kind of subject cannot be passed off as a proof for another: the signature would not check out. The rest of this concept describes the data-item case, but the same guarantees of integrity, submission window, and independent offline verification hold for every subject type a proof can attest.

Submission within a proven time window

A proof does not just say the data existed; it says when it was submitted, expressed as a window rather than a single instant. The block that includes your data is one page in a chain, and each block links to the one before it, so the block your data lands in has neighbors before and after it in time. Your data was submitted after the prior block and before the block that contains it, which pins its submission to that window.

The verifier confirms this ordering directly from the proof: it checks that the subject’s own identifier places its submission at or before the block that committed it, and it re-derives the block’s fingerprint from the block fields in the proof. Because Truestamp proves when data was submitted to Truestamp, not when it was originally created, the guarantee is always phrased as a submission window. The fuller mechanics and vocabulary of that window are covered in the submission window.

Independent, offline verification against public blockchains

The window only carries weight because its boundaries are committed to public blockchains that Truestamp does not control. A block’s fingerprint is written onto Stellar and Bitcoin in a public transaction (in a Stellar transaction memo and in a Bitcoin OP_RETURN output). Once it is there, the public chain independently attests that the Truestamp block existed no later than that transaction, and no one, including Truestamp, can quietly rewrite it.

Every downloadable proof is required to carry at least one such public-chain commitment. A proof with no external commitment would rest solely on Truestamp’s own signature, which would mean trusting Truestamp, so the system refuses to emit one: proof generation returns an error until the block has been committed to a public chain. To keep fees bounded, many blocks are committed together in one transaction and the transaction carries the root of a Merkle tree over those blocks. The proof therefore includes a second inclusion proof (an epoch proof) that links your specific block’s fingerprint into the exact root value that reached the public chain.

Verification re-derives all of this from the proof alone:

• It re-hashes your data and walks the inclusion proof to the block root.
• It re-derives the block fingerprint and walks the epoch proof to the committed root.
• Optionally, it confirms that committed root really appears in the named Stellar and Bitcoin transactions by reading the public chains.

That last step is the only one that touches a network, and it touches the public blockchains, never Truestamp. A verifier that is offline, or that simply does not want to depend on any live service, can skip the external reads (the verifier exposes an offline option for exactly this) and still confirm the entire internal cryptographic chain from data to committed root. The public verification page at www.truestamp.com/verify renders this full report, and the standalone command-line tool runs the identical checks against a local proof bundle:

# Verify a downloaded proof bundle, including offline verification.
truestamp verify

Because a proof carries its own signature, its public key, its Merkle proofs, and its public-chain transaction references, anyone can rebuild the whole chain of evidence independently. A step-by-step walkthrough lives in verify a proof.

Citations

1. RFC 6962: Certificate Transparency. Defines the leaf (0x00) and internal-node (0x01) hash domain separation used by the Merkle inclusion proofs that back the data-integrity guarantee.