Knowledge Base

Overview

The submission window is Truestamp’s core time guarantee: a proof that a specific piece of data was submitted to Truestamp inside a narrow, cryptographically bounded interval. It is deliberately a claim about submission timing, not creation timing. Truestamp can prove that your data was submitted after one point in time and before another, but it cannot prove when the data was first created or how long it existed before you submitted it. That honesty is why the product always uses the words “submitted” and “submission window” and never “created” or “creation time” for this guarantee.

The later edge of the window is a block in Truestamp’s internal ledger, and the earlier edge is a set of public records that already existed when you submitted. Each edge is fixed by a hash: the earlier records are folded into the item’s own fingerprint at submission, and that fingerprint is in turn folded into the block’s Merkle root. Neither edge can be altered after the fact without breaking the proof, and a downloaded proof carries the evidence for both. The next section says exactly how each one is fixed.

How the window is bounded

Every item carries a submission window with two ends.

• Submitted after (the earlier edge). At the moment you submit an item, Truestamp records a hash for each of its witnesses: the block then at the head of the ledger, and the newest observation captured from each public entropy source that had one, from the NIST Randomness Beacon, from the Stellar ledger, and from the Bitcoin blockchain. Those hashes are folded into the item’s cryptographic hashes at submission time, so which records your submission was made against is fixed and cannot be changed later without breaking the proof. Each entropy record carries a publication time set by its own source, and the latest of those is the edge: your data was submitted after that public moment.
• Submitted before (the later edge). Shortly after submission, the item is assigned to a block whose contents are aggregated into a single Merkle tree root. That block is the submitted-before edge. Because the item is one of the leaves of that block’s tree, the block could not have been finalized until the item was already in hand, which proves your data was submitted before that block was finalized.

Together the two edges pin the submission to the interval between them. A block-creation run is scheduled at every minute boundary, and a block is created then whenever there is at least one leaf to include, whether an item or an entropy observation; empty blocks are never created. Extra blocks are also produced on demand during high-volume bursts, so the later edge is usually less than a minute after submission. The earlier edge is usually closer still: Stellar closes a ledger every few seconds and NIST publishes about once a minute, so the newest captured observation is normally seconds old when you submit, which makes the window tighter than the gap between two blocks would be on its own.

The head block is a witness too, but a different kind. It is minted by Truestamp rather than published by an outside party, so it fixes where your submission sits in Truestamp’s own chain, and a verifier never counts its time as an externally confirmed public moment.

The containing block is later committed to public blockchains (Stellar and Bitcoin), and the entropy records were published by parties Truestamp does not control, so both edges of your submission window are bound to timestamps Truestamp can neither set nor backdate. The mechanics of proving that an item is a leaf of its block’s Merkle tree ride inside the item’s proof.

What a proof bundle establishes on its own

A proof bundle carries evidence for both edges, but the two are not established the same way, and the difference is worth stating plainly.

• The submitted-before edge is a pointer the chain confirms. The bundle carries the inclusion proof up to the block’s Merkle root, the block fields, and at least one public-chain commitment of that block. A verifier walks all of it with no help from anyone, and then looks the transaction up on the public chain, which is the external grounding. It cannot be settled offline, because the record that closes it is written after your submission and lives on a chain by construction.
• The submitted-after edge is a set of records the bundle can carry outright. The witness hashes always travel inside the item’s metadata, and by default a downloaded proof also carries the records themselves: the head block’s fields and each entropy source’s captured payload. A verifier rehashes each one and confirms it reproduces the value the fingerprint committed to, offline, and then re-fetches the same record from NIST, Stellar, or Bitcoin to confirm the payload really is what that source published. Only that second step needs a network, and none of it needs Truestamp. The edge such a verifier reports is the publication time of the latest source it confirmed.

Which witness records ride along is chosen when the proof is generated: all of them, a named subset, or none. The compact download is the none case. It verifies under the identical signature and its metadata still names every witness by hash, but establishing the earlier edge from it means fetching those records back from Truestamp first, which is a dependence on Truestamp being reachable rather than on Truestamp being believed: a fetched record that did not hash to the value already in the bundle would be rejected.

A verifier can also read the millisecond timestamps embedded in the subject id and the block id and confirm the subject was submitted at or before the block. Those ids are minted by Truestamp, so that ordering is a Truestamp assertion, not an externally verified fact, and it should never be presented as one.

What each edge survives when Truestamp is offline or gone, when a chain or an entropy source is unreachable, or when the item has been redacted or has expired is worked through scenario by scenario in proof claims by availability.

Why the window is honest

The submission window is a conservative claim on purpose. Truestamp only asserts what a hash and a public ledger can actually support.

• Submitting a hash proves the data exists. You cannot produce a matching hash without possessing the data, so a proof establishes that the data existed in exactly that form (data integrity and existence).
• The window proves when it was submitted, not when it was created. The data may have existed for seconds, years, or centuries before you submitted it. Submitting a passage of Shakespeare proves the text exists and that you submitted it inside the window, but says nothing about when it was written.
• There is no lower bound on creation. Truestamp cannot prove that data was not created earlier. If you hold a document for a year and then submit it, the proof shows only that it existed by the time you submitted, not a year ago.
• The submitted-before edge is a genuine “existed by” guarantee. Because the data was submitted before the submitted-before block was finalized, and that block is committed to a public blockchain, the data provably existed no later than that public commitment.

Truestamp deliberately declines to make the stronger claims that some timestamping services imply. Without a trusted-time oracle, cryptography alone cannot prove creation time, so asserting it would overstate what the proof supports.

Why we say “submitted”, not “created”

The vocabulary is load-bearing. “Submitted” and “submission window” describe exactly what the cryptography proves; “created” and “creation time” describe a stronger claim that the cryptography cannot back.

Correct phrasings:

• “Proof that data was submitted between public value X and block Y”
• “Data was submitted after public value X was published”
• “Data was submitted before block Y”
• “Proof that the data existed by the time of the submitted-before block”
• “Temporal proof of submission” / “proof of submission window”

Phrasings to avoid, because they overstate the guarantee:

• “Proof that data was created at time X”
• “Proof of when the data was created”
• “The data could not have existed before this block”

For the wider set of things Truestamp does and does not prove, see what Truestamp proves.

Limitations

• Truestamp cannot prove when data was first created, only that it existed by the time of the submitted-before block.
• Truestamp cannot prove how long the data existed before submission, or that it was not created much earlier.
• Truestamp does not prove original authorship. It records who submitted an item, which is not the same as who authored the underlying data. Anyone in possession of data can submit it.
• Truestamp does not attest to any property of the data beyond the bytes themselves, such as truthfulness, relevance, or legal status.