Knowledge Base

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, fixing where the observation sits in Truestamp’s own ledger; once that block is committed to a public blockchain, the observation is pinned to a public moment it must already have existed before. An observation also does a second job, outside its own page: a submission whose fingerprint names it as a witness is thereby proved to have been submitted after the moment that source published the value, which is the earlier edge of a submission window. 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.

The answer compared against may be one Truestamp retrieved earlier rather than a lookup made for this check. A published pulse, a closed ledger and a deep enough block never change, so Truestamp keeps the source’s answer and reuses it instead of asking the source again on every view. The result always says which source answered and when it was retrieved.

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, fixing its place in Truestamp’s ledger; once that block reaches a public blockchain, that same binding pins the observation to a public moment it must already have existed before. 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 is not yet bound into Truestamp’s ledger.
• 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 same two levels inside an item’s proof

The levels above describe checking a standalone entropy observation on its own page. The identical pair of questions is asked, under the identical two levels, when an observation appears inside another subject’s proof bundle as one of that item’s witnesses.

When you submit, your item’s own metadata records one hash per witness: the block then at the head of Truestamp’s ledger, plus the newest captured observation from each entropy source that had one. Hashing that metadata folds every one of them into the item’s fingerprint, so the choice is fixed at submission and cannot be revised afterwards. A proof bundle may carry each of those observations’ payloads in full, and a verifier then runs:

• The internal level, as a rehash. Re-canonicalize the carried payload, hash it under the same entropy byte prefix, and compare against the fingerprint your item committed to. A match proves the bundle carries exactly the observation your submission named, and that neither has been altered since. It needs no network access and no Truestamp server.
• The external level, as a re-fetch. Look the ledger, pulse, or block up at its own public source and compare the published fields, exactly as described above. The published time itself is read out of the carried payload, which the rehash has already bound to your item’s fingerprint; the re-fetch is what confirms that time against the source. The operative submitted-after edge is the latest published time among the witnesses confirmed in that run, and a run that confirmed none still reports the edge the fingerprint rests on, marked as unconfirmed.

Two differences from the standalone case are worth noting. The per-observation Ed25519 signature is not part of this path: the bundle’s own signature covers the item’s composite fingerprint, which already binds the witness fingerprints, so a separate observation signature would add nothing. And the Merkle step answers a different question here, because the inclusion proof in an item’s bundle walks that item into its block, not the observation into its own.

A witness your metadata commits to but the bundle does not carry is reported as skipped, not failed, the same way an uncommitted observation’s Merkle step is skipped. A compact bundle that carries no witness details still verifies; it simply establishes no submitted-after edge on its own and says which witnesses the fingerprint commits to.

The existence-not-freshness caveat carries over unchanged, and it is worth restating in this setting: confirming a witness proves the value really was published at that source, so your submission cannot have happened before that moment. It does not prove the value was fresh when captured. A frozen source yields a true but looser edge, never a false one. In the other direction, a carried witness whose published time falls after your item’s own submission time is an anomaly and is flagged with a warning.

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 observation’s binding into Truestamp’s ledger, is only available for observations that have been committed into a finalized block. Until then the summary treats that step as skipped, not failed.