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 timestamp identifying when the underlying block was finalized.
• 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).
• 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).

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.

Two block-subject proof shapes exist for the same block, distinguished by a top-level type code that is bound into the signed payload. The plain block proof uses type code 10. A dedicated beacon proof uses type code 11. The two are structurally identical (same fields, same block hash) but cryptographically distinct: a signature produced under one type code does not verify under the other. The file you download from the beacon page is the type-code-10 block proof (see downloading a beacon proof below); the type-code-11 beacon proof is what the public verify page produces for its beacon presentation of the block. 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 a proof download in either JSON or CBOR format. 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 proof produced by this download is the plain block proof (type code 10) for the underlying block, saved under a beacon-flavored file name so it is easy to recognize. It is a complete, verifiable proof of the block whose hash is the beacon; the type-code-11 beacon proof is a separate artifact obtained through the public verify page rather than this download.

Verifying a beacon proof

You verify a beacon by checking that its hash chains correctly, that Truestamp’s signature over the block is valid, and that the block hash is recorded on a public blockchain. There are two public ways to do this.

The public verify page verifies a live, on-server beacon by id. Open https://www.truestamp.com/verify/beacon/<block_id> for the beacon presentation, or https://www.truestamp.com/verify/block/<block_id> for the plain block presentation of the same block. The URL always names an explicit type segment; there is no auto-detection from the id 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 confirm the signature and the hash chain locally, and check the public-blockchain commitment directly against the relevant public blockchain. The external command-line client at github.com/truestamp/truestamp-cli ships full verification support and runs against a local bundle, so verifying it 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 proves that data was submitted after that block was finalized (its submission window opened after that point); it 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 /verify/beacon/<block_id> and /verify/block/<block_id> pages, and offline verification of a downloaded bundle with an external client.