Knowledge Base

Overview

A Truestamp beacon is a public, verifiable snapshot of the Truestamp blockchain: the hash of a finalized (or committed) block, published as a source of public randomness and as a “moment in time” marker. Each block hash is unpredictable before the block is finalized and immutable afterward, because it commits, through a Merkle tree, to every item and entropy observation captured in that block. The public entry point is the /beacons page at https://www.truestamp.com/beacons, which shows the current head beacon and gives every beacon a stable, shareable permalink at /beacons/<hash>. Anyone can view a beacon, derive fair random outcomes from it, and download a cryptographic proof of it without an account.

The public beacon page

The beacon page is genuinely public: /beacons and /beacons/<hash> are open to both signed-in and anonymous visitors, no API key or login required. /beacons resolves the current head of the chain and redirects to that block’s permalink at /beacons/<hash>, so a shared beacon link always points at one specific, addressable block hash. A beacon is also findable by pasting its block hash or ID into the search page.

A beacon page shows:

• The 64-character lowercase hex block hash (a SHA-256 digest).
• The finalization timestamp, labelled “Beacon Finalized”: when the underlying block was finalized. It is not the creation time of anything a user submitted; a beacon opens the submitted-after edge for whatever later references its hash.
• Previous and next links that walk the hash chain block by block.
• Explanatory content about what the beacon is and why it is verifiable.

The page updates in real time. When a new block is finalized or committed, the beacon you are viewing refreshes and its “next” link lights up, so watching /beacons behaves like a live heartbeat for the chain. A new block is produced roughly once a minute, so the current head beacon is a fast-moving value while any specific /beacons/<hash> permalink is stable forever.

Signed-in and anonymous visitors see the same beacon data and the same fairness tools; the only difference is that anonymous visitors also see a call to action inviting them to create an account.

What a beacon is and its fields

A beacon is a read-only virtual projection over a finalized or committed Truestamp block. The underlying block’s full detail page lives in the public block explorer; the beacon exposes only the fields that matter for treating a block hash as public randomness or a proof-of-life marker, and deliberately omits the block’s internal cryptographic machinery.

Every beacon exposes exactly four fields:

• id - the underlying block’s UUIDv7 identifier, used for follow-up lookups and proofs.
• hash - the beacon hash: a SHA-256 digest as 64 lowercase hex characters.
• timestamp - ISO 8601 UTC time identifying when the underlying block was finalized.
• previous_hash - the chain-link to the previous beacon’s hash, so a verifier can walk the chain.

Only finalized or committed blocks ever appear as beacons; blocks in earlier states are never surfaced. The Merkle root, the signing key, the signature, and other block internals are intentionally not part of the beacon shape. The previous_hash of the very first block in the chain is a fixed, well-known sentinel value (it is a real 64-character hex string, not all zeros); treat it like any other previous hash.

Because the hash cryptographically commits to everything finalized in that block, it inherits the unpredictability of the underlying entropy sources. To understand where that entropy comes from, see entropy sources; for why an unpredictable, publicly published value is a sound randomness beacon, see public randomness.

Deriving fair random outcomes

The beacon page turns a beacon hash into fair, reproducible random outcomes. These tools are available to everyone on the public page and require no account. Each tool is deterministic: the same beacon hash and the same parameters always produce the same result, so anyone can independently reproduce and check the outcome.

The available tools are:

• Coin toss (heads or tails).
• Dice roll (any number of sides, two or more).
• Random integer within a range you choose.
• Lottery draw (a set of unique numbers from a range). The number range runs from 1 up to at most 1,000, and the number of picks from 1 up to the range.
• Drawing from a list (pick one entry; the list is sorted first, so the result does not depend on the order you typed the entries). The list holds at most 1,000 entries.

Those limits are enforced by Truestamp, not only by the form. A lottery with a range or a number of picks outside them, or a drawing from a longer list, is refused with an error message and nothing is drawn.

Fairness comes from two properties working together. First, the beacon hash is unpredictable before the block is finalized, so no participant can know the outcome in advance. Second, each tool uses domain-separated SHA-256 (a distinct byte prefix per tool) so that, for example, a coin toss and a dice roll derived from the same beacon are independent. The result is verifiable public randomness: unbiasable by any single party, yet reproducible by everyone after the fact.

Beacon proofs

A beacon proof is a self-contained cryptographic artifact that lets a third party verify, offline and without trusting Truestamp, that a specific beacon hash existed and was committed to at least one public blockchain. The subject of the proof is the block itself: the block is both the subject and the top of its own Merkle tree, so the proof carries no separate subject payload and no intra-block inclusion proof; those fields are simply absent, and the subject hash is just the block hash.

Nothing in the file has to be taken on trust as an opaque hash. The bundle carries the block’s own values: its identifier, the previous block’s hash, its Merkle root, its block metadata, and the identifier of the key that signed it. The beacon hash itself is not one of the fields; a verifier recomputes it from those values and compares the result against what the signature covers. Alongside them the bundle carries the public blockchain commitments, each with the proof that walks the beacon hash up to the value actually written on that chain, and it can also carry the key event that introduced Truestamp’s signing key.

Two block-subject proof shapes exist for the same block, distinguished by the bundle’s top-level type key and by the matching t type code that is bound into the signed payload. The plain block proof is type block, code 10. A dedicated beacon proof is type beacon, code 11. The two are structurally identical (same fields, same block hash) but cryptographically distinct: a signature produced under one code does not verify under the other. Every beacon surface produces the beacon proof: both the download on the beacon page (see downloading a beacon proof below) and the public verify page’s beacon presentation of the block. The plain block proof of the same block comes from the block’s own page in the public block explorer and from the verify page’s block presentation. For the full wire format, see the proof bundle format.

Requiring an external commitment

Every downloadable proof, beacon proofs included, requires the underlying block to have been committed to at least one public blockchain first. This is a deliberate contract: a proof that could only be checked against Truestamp’s own signature chain would not meet the “offline-verifiable without trusting Truestamp” guarantee, so Truestamp does not ship one until an external commitment exists.

A freshly finalized beacon lives in a brief window before its block is committed. During that window the beacon page’s Verify and Download buttons stay enabled, but a proof download does not yet produce a file. Instead of downloading, the page surfaces an informational message explaining that the beacon has not yet been committed to a public blockchain and that a downloadable proof will be available after the next epoch commit. Once the block is committed, the same buttons produce a real proof.

Downloading a beacon proof

From any beacon page, the header offers the proof in two variants, complete and compact, each in JSON or CBOR. Both encodings carry the identical proof; JSON is human-readable and CBOR is compact. The download is a client-side action on the public page, so no account is needed once a commitment exists.

The complete variant is the one to take when the file has to stand alone: it carries the key event that introduced Truestamp’s signing key, so a reader can check where that key came from without asking Truestamp anything. It rides along only when that key event has itself been committed to a public blockchain, and is otherwise absent. The compact variant leaves the key event out for a smaller file, and its file name is marked compact so the two are easy to tell apart. Choosing a variant never changes a hash or the signed payload, so both verify under the same signature; the compact file simply leaves the key’s introduction uncheckable from the file alone.

If Truestamp cannot issue a committed beacon’s proof at that moment, for example because it cannot sign it just then, the page says the proof is temporarily unavailable and to try again later. Nothing is wrong with the beacon, and no incomplete proof is issued in its place.

The proof produced by this download is the beacon proof (type beacon, code 11) for the underlying block, saved under a beacon-flavored file name so it is easy to recognize. It is a self-contained, verifiable proof of the block whose hash is the beacon. The plain block proof (type block, code 10) of that same block is a separate artifact, downloaded from the block’s own page in the public block explorer rather than from here.

Verifying a beacon proof

You verify a beacon by recomputing its hash from the block values the proof carries, checking that Truestamp’s signature over that hash is valid, and checking that the hash reached a public blockchain through its commitment. When the file carries the signing key event, a verifier also checks that the key that produced the signature was introduced by a key event that is itself recorded on a public chain. There are two public ways to do this.

The public verify page verifies a live, on-server beacon. Open https://www.truestamp.com/verify/beacon/<hash_or_id> for the beacon presentation, or https://www.truestamp.com/verify/block/<block_id> for the plain block presentation of the same block. Because the 64-character hash is a beacon’s natural public identifier, the beacon route accepts either that hash or the underlying block’s id; the block route accepts the block id only. The URL always names an explicit type segment; there is no auto-detection from the identifier alone. Both pages are public and require no account.

Independent, offline verification of a downloaded bundle is also possible without any Truestamp service at all. The downloaded bundle is self-contained: a verifier can recompute the beacon hash and confirm the signature locally, and check the public-blockchain commitment directly against the relevant public blockchain. The external command-line client at github.com/truestamp/truestamp-cli verifies downloaded proof bundles from your terminal and works fully offline, so verifying one this way needs no Truestamp credentials. For the cross-implementation verification contract, see how to verify a proof.

Limitations

A beacon proves submission timing, not authorship or creation time. Referencing a beacon hash opens the submitted-after edge of the submission window at that block: it proves the data was submitted after that block was finalized, and says nothing about when the data was originally created or by whom.

The programmatic beacon surfaces are not public. Beacons are also exposed over a JSON:API and a GraphQL API for programmatic consumers, but those endpoints require an authenticated caller (an API key or an OAuth access token) and are therefore out of scope for anonymous use. The genuinely public surfaces are the /beacons page, its randomness tools and proof downloads, the printable beacon artifact at /beacons/<hash>/print, the /verify/beacon/<hash_or_id> and /verify/block/<block_id> pages, and offline verification of a downloaded bundle with an external client.