Overview

Every captured entropy observation carries a stored data hash, a per-row signature, and (once committed) a Merkle inclusion proof. Verification answers two independent questions about that observation, and they form the two verification levels a user sees. Internal verification asks “is this record internally consistent and endorsed by Truestamp?” by recomputing hashes and checking a signature, using only the stored record and no network access. External verification asks “does this value actually match what the original public source published?” by re-fetching the value from that source and comparing fields. A combined verification summary merges both, plus the Merkle inclusion check, into one overall pass or fail. The Merkle check is the one that binds the observation into a finalized block, which is what places it in a submission window: the proof that any data committed into that block was submitted after this entropy event and before the block that includes it. Each level proves a different thing, so a user should read them together, not in isolation. For what the underlying sources are, see entropy sources.

Internal verification

Internal verification runs every check that needs nothing but the stored observation itself. It does not touch the network, so anyone holding the record can run it offline. It combines two independent checks and passes only if both pass.

• Data hash check. The observation’s raw entropy value is re-canonicalized with JSON Canonicalization Scheme (JCS) and re-hashed with SHA-256 under an entropy-specific byte prefix, then compared byte-for-byte against the stored data hash. See domain-separated hashing for why the prefix matters. A match proves the stored value has not been altered since capture. This is the “data integrity” guarantee for the raw entropy payload.
• Signature check. Each observation carries a per-row Ed25519 signature produced by Truestamp’s active signing key at capture time. Verification looks up that key’s public half and checks the signature over the observation’s composite hash (a single fingerprint that binds the observation’s id, its data hash, its metadata hash, and the id of the signing key that endorsed it). A valid signature proves Truestamp’s signing key endorsed this exact observation at capture, and it is verifiable against Truestamp’s public signing keys (published so anyone can check the signature) without waiting for the observation to be committed into a block. The check falls back to the currently configured key if the historical key id is not yet known locally.

What internal verification proves: the record is self-consistent (the stored hash really is the hash of the stored value) and authentic (Truestamp signed it). What it does not prove: that the value genuinely came from the external public source. That is what external verification adds.

External verification

External verification re-fetches the value from the original public source over the network and compares the published fields against what Truestamp stored. It is the level that ties an observation back to the real world outside Truestamp. The comparison is source-specific:

• Bitcoin observation. The block is looked up from public block explorers (with fallback providers) and the block height, hash, and timestamp are compared.
• NIST beacon observation. The pulse URL is reconstructed from the chain and pulse indices, and the chain index, pulse index, output value, and timestamp are compared.
• Stellar observation. The ledger is looked up by sequence number and the sequence, ledger hash, and close time are compared.

What external verification proves: the stored value is a faithful copy of what the named public source actually published, so anyone can independently confirm the same value from that source.

One caveat is worth stating plainly. External verification confirms that the value exists at the source, not that it was fresh at capture. If a source freezes and republishes an old value (for example, the NIST beacon repeating its last pulse during a US government shutdown), external verification still succeeds against that frozen value. It confirms existence, not freshness.

The verification summary

The verification summary is the combined result a user reads to judge an observation overall. It runs all layers and merges them into one report: the internal data hash check, the signature check, the Merkle inclusion proof, and the external source check. The overall status passes only when no individual check fails.

The Merkle inclusion check is what binds the observation into a finalized block and thereby into its submission window, the proof that any data committed into that block was submitted after this entropy event. It is only meaningful once the observation has been committed into a block, so before that point the summary marks the Merkle step as skipped rather than failed. A skipped step is not a failure: an observation that has been captured but not yet committed can still pass internal and external verification while its Merkle step is pending. Once committed, the Merkle step verifies the stored inclusion proof reaches the block’s Merkle root, using the observation’s composite hash (that same fingerprint binding its id, its data hash, its metadata hash, and its signing key id) as the leaf value.

Reading the levels together:

• Internal passes, external passes, Merkle skipped. The record is consistent and Truestamp-signed and matches its public source, but it is not yet committed into a block, so it has no submission-window binding yet.
• Internal passes, external passes, Merkle passes. Full confidence: consistent, signed, matches the source, and committed into a block whose inclusion proof checks out.
• Any check fails. The summary fails overall, and the failing level tells the user which guarantee did not hold.

The clock delta: source time versus capture time

Alongside the verification levels, every observation carries a derived timing signal: the clock delta, the difference in whole seconds between the moment the source itself claims for the value and the moment Truestamp captured it. The source-claimed moment is read out of the stored raw value, so it is part of what the data hash protects: the publication timestamp of a NIST beacon pulse, the timestamp in a Bitcoin block header, or the close time of a Stellar ledger. The delta is computed on demand from the stored record rather than stored itself.

Reading the sign:

• Near zero. The source published the value and Truestamp captured it almost simultaneously, the expected shape for live capture.
• Negative. Capture happened after the source’s claimed moment. Small negative values are normal network and processing delay.
• Positive. The source’s claimed moment is ahead of Truestamp’s capture clock. Bitcoin block header timestamps are set by miners and are routinely minutes ahead of wall-clock time, so modest positive deltas are expected for Bitcoin observations.

The product shows the delta as a warning next to an observation only when its magnitude exceeds five minutes. The delta never changes any verification outcome: it is not one of the internal or external checks and does not gate the summary. It is a transparency signal that complements the external level’s existence-not-freshness caveat. A small delta is supporting evidence that the observation was captured promptly after the source published the value, while a large one says to look closer at whether the source was frozen, the capture was delayed, or the source’s clock is simply loose.

Limitations

Each level is scoped to a distinct guarantee, so no single level is sufficient on its own.

• Internal verification alone cannot tell you the value came from the real public source; a self-consistent, Truestamp-signed record could in principle contain a value that the source never published. External verification closes that gap.
• External verification alone confirms the value exists at the source but not that it was captured promptly; a frozen or stale source value still matches. It also requires network access to the source at verification time.
• The Merkle inclusion check, and therefore the submission-window binding, is only available for observations that have been committed into a finalized block. Until then the summary treats that step as skipped, not failed.