Knowledge Base

Overview

Entropy is unpredictable, public randomness that nobody can know in advance. Truestamp captures it on a best-effort basis from three independent public sources: the NIST Randomness Beacon, the Stellar ledger, and the Bitcoin blockchain. Each captured value becomes an entropy observation, and each observation is used twice: it is folded directly into the Merkle tree of an internal Truestamp block, sitting alongside the timestamped items in that same block, and the newest observation per source is separately committed as a witness inside each item’s own fingerprint at the moment of submission. The first makes the block itself evidence that it could not have been produced before that entropy existed; the second binds your specific item to entropy that had already been published when you submitted, so its proof stands on that evidence without needing the block’s contents. Because these values could not have been guessed before those public events happened, both are verifiable submission-timing evidence rather than claims you simply have to trust.

Why unpredictable public entropy matters

The timing guarantee Truestamp offers is a submission window: proof that a piece of data was submitted after a known moment and before the next block. Public entropy is what makes the “after” side of that window trustworthy and hard to fake.

The key property of a good entropy source is unpredictability. You cannot know tomorrow’s Bitcoin block hash or NIST beacon value today, and once a value is published it is part of a permanent, widely replicated public record that anyone can look up. So if a Truestamp block contains a Bitcoin block hash that only came into existence at a certain time, that block cannot have been produced any earlier: it could not have been precomputed, because the entropy it depends on did not yet exist. Your own data gets a sharper claim from the same sources, because the entropy your item commits to is fixed when you submit rather than when the block is built.

This is deliberately a proof of submission, not of creation or authorship. Capturing a fresh entropy value alongside your data proves you submitted the data after the entropy was published. It does not prove who created the data or when it was originally written. For more on that distinction, see the submission window.

Public sources are chosen precisely because they are hard to corrupt or forge:

• No single publisher you have to trust: these beacons and blockchains are widely replicated.
• Values are cryptographically chained or signed at the source.
• Anyone in the world can independently look up the same value.
• Guessing a future value in advance is computationally infeasible.

The three sources

Truestamp captures entropy from three independent public sources. Each one has its own capture mechanism and can be turned on or off independently, so a problem at one source never blocks the others.

NIST Randomness Beacon

The NIST Randomness Beacon is a public service run by the US National Institute of Standards and Technology that publishes a fresh, cryptographically signed random value roughly once a minute, each one linked to the previous in a tamper-evident chain. Truestamp captures each new pulse by polling the beacon over HTTP and storing only the essential fields (the random output value, the chain and pulse identifiers, and the pulse timestamp), which keeps storage small while preserving enough to look the value back up in NIST’s public records.

Stellar ledger

The Stellar network closes a new ledger every few seconds, and each closed ledger carries a cryptographic hash agreed by distributed consensus. Truestamp subscribes to a live stream of these ledger events and captures the ledger sequence number, its consensus hash, and the time it closed. The ledger hash is a consensus output that no single party controls, which makes it a good unpredictable public value.

Bitcoin blockchain

Bitcoin produces a new block roughly every ten minutes, and each block hash is the output of an enormous amount of proof-of-work that cannot be predicted ahead of time. Truestamp captures new Bitcoin blocks and stores the block hash, its height, and its timestamp. Because a Bitcoin block hash is expensive to produce and impossible to know in advance, it is one of the strongest publicly verifiable “this moment has passed” signals available.

How a captured value joins a block

Every captured value becomes an entropy observation. An observation records the captured fields exactly as the source published them, together with a reproducible cryptographic fingerprint of that data. The fingerprint is computed deterministically: the raw values are canonicalized into a single, unambiguous form and then hashed, so any independent verifier who fetches the same public value can recompute the exact same fingerprint and confirm it matches.

An entropy observation is not wrapped in any intermediate record. Its composite hash becomes a leaf in the Merkle tree of a Truestamp block, directly alongside the fingerprints of the timestamped items in that same block. One combined Merkle tree covers both the items and the entropy for that block. As a result, a single block simultaneously carries your data and the public entropy that pins down when the block existed, and the block’s public record lists both the item fingerprints and the entropy observations captured in the same window.

Each observation moves through a simple lifecycle as it is folded in: it is first captured, then assigned to a block, and finally committed once its place in the block’s Merkle tree is fixed. Because entropy is public data, entropy observations are readable by anyone; there is no private or tenant-scoped entropy. Every observation is browsable on the public entropy pages.

How a captured value also enters your own fingerprint

Joining the block’s Merkle tree is one of two independent routes entropy takes into a proof, and the second one binds to your submission rather than to the block around it.

At the moment you submit, Truestamp reads the newest captured observation from each source and commits its fingerprint into your item’s own system-generated metadata, as one of that item’s witnesses. Hashing that metadata folds every witness into your item’s composite fingerprint, so the choice is fixed at submission and cannot be revised afterwards.

The difference between the two routes is what a verifier can do with them.

• As a Merkle leaf, an observation says the block could not have been precomputed. Establishing that requires walking the block’s tree, and it says nothing about which of the block’s contents came first.
• As a witness, an observation says your item specifically was submitted after that published value. A proof bundle can carry the captured payload in full, so a verifier rehashes it, compares it to the fingerprint your item committed to, and then fetches the ledger, pulse, or block from its public source to read the published time. That path needs Truestamp for nothing beyond the bundle you already hold.

A source that had captured nothing at the moment you submitted simply contributes no witness. Naming fewer sources only makes the claim more conservative, so entropy availability never blocks or delays a submission.

Which witnesses ride in a given bundle is a choice made when the proof is generated: a downloaded file carries them all so that it stands alone, while a compact variant omits the detail and keeps only the fingerprint that commits to it.

Why this strengthens the guarantee

A proof cannot have been precomputed before the entropy it contains existed. That single fact is what public entropy adds to a Truestamp proof.

Without entropy, a block only establishes an internal ordering. With entropy folded in, the block is bound to concrete, externally verifiable public events, and each item is separately bound to the entropy that already existed when it was submitted. Anyone verifying a proof can independently fetch the referenced NIST pulse, Stellar ledger, or Bitcoin block from its public source, confirm the captured value is real, and conclude that the data was submitted after those events. Capturing from three independent sources means the guarantee does not rest on any one operator or network staying honest and available: the operative submitted-after edge is the latest of the sources a verifier can confirm, so one frozen or unreachable source costs precision rather than the edge itself.

The three sources are not interchangeable at both edges, and a proof page says so. All three serve as witnesses at the submitted-after edge, since each publishes a value that could not have been known earlier. Only Stellar and Bitcoin close the submitted-before edge, because that edge needs an outside record that a Truestamp block already existed, and it is to Stellar and Bitcoin that Truestamp writes its commitment transactions. A commitment is not a witness: it is recorded after your submission rather than published before it. Nothing is ever written to the NIST Beacon, so NIST speaks only to the earlier edge and forms no window of its own.

The degree of independent confirmation available for a given observation, from recomputing its fingerprint offline to re-fetching the original value from its public source, is covered in entropy verification levels.

Limitations

Public entropy proves submission timing, not creation or authorship. It shows that data was submitted after a captured value existed; it says nothing about when the data was originally created or who wrote it.

The guarantee is also only as fresh as the source. If a public source temporarily stops publishing new values, for example the NIST beacon repeating its last pulse during a US government shutdown, an independent verifier can still confirm that the captured value genuinely exists in the source’s records, but that value no longer pins the moment down as tightly. Existence remains verifiable; freshness may not, until the source resumes.