Overview

A Truestamp proof is deliberately narrow. It proves that a specific piece of data existed in a specific form and was submitted to Truestamp inside a time window bounded by two public-blockchain transactions. It does not prove when the data was originally made, who made it, whether anything it says is true, or that it existed before the moment it was submitted. These are not gaps to be fixed later. They are the honest boundary of what cryptography and a public timestamp can establish on their own, and stating them plainly is part of how the proof earns trust. The affirmative guarantees are covered separately in what Truestamp proves; this concept is only about the limits.

It does not prove creation time

Truestamp proves submission timing, never creation timing. The proof pins the data to a submission window: it was submitted after one finalized block and before the block that includes it. It says nothing about how long the data existed before that window. If someone holds a document for a year and then submits it, the proof shows only that the document existed by the time it was submitted, not that it existed a year earlier. Cryptography alone cannot look backward in time. A hash proves the data existed at submission because you cannot produce a matching hash without the data, but it cannot prove the data did not already exist for seconds, years, or centuries beforehand.

This is why the guarantee is always described as a submission window and never as a creation time. Claiming creation time would be a stronger statement than the underlying cryptography can support. Investigators practicing chronolocation, establishing when a piece of digital evidence existed, get exactly this bound from a proof: the evidence existed no later than the window’s submitted-before edge, and nothing more.

It does not prove authorship or ownership of the content

Truestamp records who submitted an item, but a submitter is not the same as an author. Anyone who possesses a piece of data can submit it, so the act of submission is not evidence that the submitter created the underlying content.

This limit is reflected in the cryptography itself. The hash that goes into the Merkle tree and reaches the public blockchain is a composite of the item’s identifier, the hash of the submitted data, and the hash of the temporal metadata. The identity of the submitter is not one of those inputs. It is kept as an immutable audit-trail record alongside the item, but it is deliberately excluded from every cryptographic hash. Because authorship is not hashed and not committed, a valid proof carries no cryptographic claim about who wrote the data.

Ownership is likewise an internal, transferable relationship used to decide who may read or manage an item. It can change over time and it is not part of the committed proof. The proof attests to the data and its submission window, not to any assertion about who owns or created that data.

It does not prove the content is true or authentic

Truestamp hashes the submitted data but never inspects, interprets, or vouches for it. A proof commits to the exact bytes that were submitted and to when they were submitted. It makes no claim about any property of those bytes beyond their integrity: not their truthfulness, not their accuracy, not their legal status, not their relevance, not their authenticity as a genuine record of anything.

A proof that a false statement was submitted at a certain time is still a perfectly valid proof. It faithfully attests that those exact bytes existed and were submitted within the window. It does not, and cannot, attest that the statement is correct. Verifying a proof tells you what was submitted and when, and leaves the meaning and truth of the content entirely to the reader.

It does not prove data existed before submission

The submission window has a submitted-after edge and a submitted-before edge, and both are about submission, not about earlier existence. The submitted-after edge proves the data was submitted after a particular block was finalized. It does not prove the data came into existence at that moment, and it cannot prove the data did not exist earlier. Data may have existed long before it was ever shown to Truestamp.

The same reasoning rules out proving uniqueness. Identical data can be submitted many times by many parties, each producing its own valid proof. A proof for a given piece of data does not establish that it was the first submission of that data or that no earlier copy existed. It establishes only that this submission happened inside this window.

Why stating the limits builds trust

Being explicit about these boundaries is a feature, not a disclaimer. A verifier who understands exactly what a proof does and does not assert can rely on it with confidence and will not be misled into treating it as a claim it was never meant to make. Overstating a timestamp, for example by calling a submission time a creation time, invites disputes the moment the stronger claim is tested. By proving a small, precise, independently checkable set of facts and refusing to imply anything beyond them, Truestamp keeps every proof defensible. The honest limits are what make the affirmative guarantees worth trusting.