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 window is bounded by two blocks in Truestamp’s internal ledger. A block is created roughly every minute whenever there is at least one thing to include, so the interval between the two bounding blocks is typically about a minute. Both edges are folded into cryptographic hashes that ride along inside the item’s proof, so neither can be altered after the fact without breaking the proof. The two edges are not equally self-contained, though: a third party can re-derive the submitted-before edge from the proof bundle alone, while re-deriving the submitted-after edge takes one extra out-of-band lookup. The next section says exactly why.

How the window is bounded

Every item carries a submission window with two ends, each tied to a specific ledger block.

• Submitted after (the earlier edge). At the moment you submit an item, Truestamp records the fingerprint of the current head block, the most recent block on the ledger. That value is folded into the item’s cryptographic hashes at submission time, so it cannot be changed later without breaking the proof. The head block may already be committed to a public blockchain, or it may still be awaiting commitment; either way it existed before your submission, so it proves your data was submitted after that block.
• 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 bounding blocks 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. As a result the window is usually on the order of a minute and never wider than the gap between the two blocks.

Both blocks are later committed to public blockchains (Stellar and Bitcoin), so the edges of your submission window are bound to timestamps that Truestamp does not control and cannot 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 is self-contained for the submitted-before edge and only partly self-contained for the submitted-after edge. The difference is worth stating plainly, because it is the one place a careful reader could be misled.

• The submitted-before edge is established by the bundle. 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 the on-chain transaction is the external grounding.
• The submitted-after edge is committed but not carried. The head-block reference captured at submission is folded into the item’s metadata hash, so it is fixed and tamper-evident. Only the metadata hash itself travels in the bundle; the metadata map holding the previous block’s id and hash does not. A verifier working from the bundle alone therefore cannot recompute that edge and should report it as not established from the bundle rather than assert it. Fetching the referenced block from Truestamp’s public block endpoint resolves it, which is an optional extension rather than a step every verifier runs.

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.

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 block X and block Y”
• “Data was submitted after block X”
• “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.