Knowledge Base

Overview

A Truestamp proof is often described as something a stranger can check with no help from Truestamp. That is true of most of what the proof claims, and the parts where it is not true depend on what the verifier can reach at the moment of checking: the bundle itself, the original file, the public blockchains, the public entropy sources, a copy of Truestamp’s keyring pinned earlier, or Truestamp’s own ledger. This reference lays the claims out one at a time, says which inputs each one needs, and then walks through what a careful verifier should print, and what a holder can honestly say, under every combination of data and service availability that matters in practice.

Two of the rows below depend on something other than an outage: what the bundle was asked to carry. Witness details and the signing key event are optional at generation time. A complete bundle, which is what a download hands you by default, carries every witness the fingerprint commits to and, when the key-event block has been committed, the key event too. A compact bundle carries neither. Both verify under the same signature, because neither choice touches a hash. Where a row differs, it names the complete case first.

This reference describes item proofs. An entropy proof shares every row except the submitted-after edge: an observation’s metadata is the empty map, so it commits to no witness, and a verifier says the edge is not established from the bundle rather than naming one. A block or beacon proof carries no subject fingerprint at all, so it has no submitted-after edge either; its submitted-before edge still rests on the commitments.

The eight claims

A proof can be read as making eight distinct claims. Keeping them separate is what makes the matrix possible, because they fail and survive independently.

1. The exact bytes existed. A digest matching the file in hand cannot be produced without the file, so a matching digest establishes the bytes existed in that form. In hash mode the verifier needs the original file to make this claim; in content mode the data rides in the bundle and the claim needs nothing else.
2. Unchanged since. The same digest comparison establishes that not one byte has changed between submission and the copy in hand.
3. Submitted before a public moment (the submitted-before edge). The block that holds the item was committed, by way of an epoch root, to a transaction on a public blockchain. The public moment is the close time of the Stellar ledger that carries the transaction, or the header time of the Bitcoin block that mines it, or both. The earlier confirmed one is the tightest edge and the other corroborates it.
4. Submitted after a public moment (the submitted-after edge). At submission the item’s fingerprint bound one hash per witness: the block then at the head of Truestamp’s ledger, and the newest captured observation from each entropy source that had one. What turns a witness into a public moment is the time the source itself attaches to that value: a NIST pulse timestamp, a Stellar ledger close time, or a Bitcoin block header time. The latest confirmed one is the tightest edge. Because Stellar closes a ledger every few seconds and NIST publishes about once a minute, that edge is usually much tighter than the head block, whose own contribution is a Truestamp-minted identifier rather than a public moment.
5. A key endorsed this composite fingerprint. The bundle carries an Ed25519 signature over a payload that includes the item’s composite fingerprint, and the public key that verifies it.
6. That key is Truestamp’s. Binding the key inside the bundle to Truestamp’s identity is a separate claim from the signature verifying. It rests on the published keyring, or on the did:web document that projects the same keys, both of which live on Truestamp’s domain, or on a carried signing key event, which rests on the public chains instead.
7. The ledger position. The bundle names the containing block’s identifier and its previous-block hash, and those fields are bound into the block hash that reaches the public chain. A complete bundle also carries the head block itself, and a block path when the head block is not the direct predecessor, so the stretch of chain between the two is checkable from the file. Where the containing block sits relative to its wider neighborhood remains a property of the ledger.
8. Entropy freshness versus mere existence. For the after edge and for entropy proofs, a source re-fetch can confirm that a captured value exists in the source’s records. Nothing can confirm that the value was fresh when Truestamp captured it; a frozen source republishing an old value passes the same check.

Five grades of established

Each cell of the matrix uses one of these grades. They are ordered by how much the verifier has to reach for.

• bundle: established from the bundle alone (plus the original file, in hash mode). Survives every outage, including Truestamp disappearing.
• chain: established once the verifier reaches public chain data: a Stellar Horizon endpoint, a Bitcoin node or block explorer, or an operator-pinned set of Bitcoin headers. Survives Truestamp disappearing; needs the chains.
• source: established by re-fetching a witnessed record from the party that published it: the NIST beacon, a Stellar Horizon instance, or a Bitcoin node or explorer. For Stellar and Bitcoin this is the same public data the “chain” grade names; NIST is the one source that is neither a chain nor Truestamp.
• pinned: established only against a copy of Truestamp’s keyring (or DID document) that the verifier obtained and pinned while Truestamp was reachable. Survives Truestamp disappearing only for verifiers who pinned in time.
• ledger: established only by fetching records from Truestamp’s public ledger and checking them against hashes in the bundle. Needs Truestamp to be reachable and to still hold the record. This is an availability dependence, not a trust dependence: a fetched record that did not hash to the bundle’s value would be rejected.
• not established: no input makes it checkable. A careful verifier says so rather than staying silent, because a reader cannot tell an edge the verifier found unestablished from one it never considered.

The matrix

The first table gives each claim’s grade under the best case, with everything reachable. The second table shows how the scenarios move those grades. Cells that a scenario does not move are left as in the first table.

Claims under full availability

Claim	Grade	Input that closes it	Notes
1. Bytes existed	bundle	the original file (hash mode) or nothing (content mode)	The digest, the inclusion proof up to the block root, and the block hash all recompute offline.
2. Unchanged since	bundle	same as claim 1	A single changed byte changes the digest and breaks the inclusion walk.
3. Submitted-before edge	chain	one confirmed commitment transaction	The bundle names the candidate (the commitment’s timestamp) and carries the epoch proof; only the chain lookup establishes it. Stellar closes within seconds of the transaction; Bitcoin is settled once buried, conventionally six confirmations.
4. Submitted-after edge	chain and source, else ledger	the carried witness payloads, then a re-fetch of each from its own source	A complete bundle carries the payloads; each rehashes to the value the metadata commits to, and re-fetching it from NIST, Horizon, or a Bitcoin explorer pins the published time. From a compact bundle the metadata still names every witness by hash, so the records are recoverable from Truestamp’s public ledger first, at ledger grade.
5. A key endorsed the fingerprint	bundle	nothing	The signature verifies against the public key inside the bundle.
6. The key is Truestamp’s	chain given a known commitment account, else pinned	a carried signing key event, or a keyring pinned while Truestamp was reachable	The key event’s block hash and epoch proofs recompute from the file, and its commitments confirm on chain. A commitment entry names no sender, and the chain lookup compares only the memo or OP_RETURN payload, so tying that transaction to Truestamp rather than to any sender needs a verifier who already knows Truestamp’s own Stellar account and Bitcoin address. Without a key event, the pinned keyring is the only path, and even a match says only that Truestamp published the key: the keyring carries no validity interval and no revocation flag.
7. Ledger position	bundle, then chain	the carried head block and block path, plus one confirmed commitment	The head block hash, the path linking it to the containing block, and the containing block’s own fields all recompute offline; the confirmed commitment is what binds that block to a public root. Its wider neighborhood and height are ledger-grade.
8. Entropy freshness	not established	none	Existence at the source is checkable (chain-grade for Stellar and Bitcoin values, source-grade for NIST); freshness at capture never is. The capture-time clock delta is a signal, not a check.

How the scenarios move the grades

Scenario dimensions that leave every cell unchanged are named once here rather than given a row: hash mode versus content mode changes only whether claim 1 needs the original file; a redacted item changes nothing for a bundle already downloaded; and a bundle carrying both chains versus Stellar only changes only which public moment closes claim 3.

Scenario	Claims 1, 2, 5	Claim 3 (before)	Claim 4 (after)	Claim 6 (key binding)	Claim 7 (position)	Claim 8 (freshness)
Everything reachable	bundle	chain (both moments)	chain and source; ledger from a compact bundle	chain from a carried key event, for a verifier who already knows Truestamp’s commitment account, else pinned	bundle, then chain	not established
Truestamp temporarily offline	bundle	chain	chain and source, unchanged; a compact bundle waits for Truestamp	chain from a carried key event, for a verifier who already knows Truestamp’s commitment account; nothing new can be pinned	unchanged	not established
Truestamp permanently gone (domain and did:web gone)	bundle	chain	chain and source, unchanged; a compact bundle loses it, for every bundle already issued	chain from a carried key event, for a verifier who already knows Truestamp’s commitment account; otherwise pinned only, and no new verifier can ever bind the key	unchanged	not established
Stellar reachable, Bitcoin not	bundle	chain, Stellar close time only; Bitcoin entry reports internal consistency, not confirmation	the Bitcoin witness cannot be confirmed; NIST and Stellar witnesses carry the edge	unchanged	chain (Stellar)	unchanged
Bitcoin reachable, Stellar not	bundle	chain, Bitcoin header time only, once one external confirmation point is available	the Stellar witness cannot be confirmed; NIST and Bitcoin witnesses carry the edge	unchanged	chain (Bitcoin)	unchanged
Neither chain nor source reachable (fully offline)	bundle	named, not established	named and bound to the fingerprint, not confirmed	the key event recomputes; its on-chain confirmation is skipped	bundle (the path recomputes; the commitment is not confirmed)	not established
NIST frozen, republishing an old pulse	unchanged	unchanged	the NIST witness is loose (the last live pulse); the Stellar and Bitcoin witnesses stay tight	unchanged	unchanged	not established, and this is the case the grade exists for
NIST gone	unchanged	unchanged	the NIST witness cannot be re-fetched; other sources carry the edge	unchanged	unchanged	not established
Stellar or Bitcoin gone as an entropy source	unchanged	that chain’s commitment also unconfirmable	that source’s witness cannot be re-fetched	unchanged	unchanged	not established
Item redacted	bundle (an earlier bundle still carries the claims)	chain	unchanged; a compact bundle stays ledger-grade, since redaction leaves the ledger records alone	unchanged	unchanged	unchanged
Item expired on the free plan and swept	bundle	chain	unchanged for a complete bundle; ledger for a compact one, because the witnessed records are ledger objects that outlive the item row	unchanged	unchanged	unchanged
Bitcoin under six confirmations	bundle	chain, Stellar; Bitcoin confirmed but shallow, reorganization-exposed	unchanged	unchanged	unchanged	unchanged
Reorganization after the commit	bundle	chain, Stellar; the Bitcoin entry’s height and header may be stale, or its transaction gone	unchanged	unchanged	unchanged	unchanged
Stellar-only bundle downloaded early	bundle	chain, Stellar close time; no Bitcoin corroboration in this file	unchanged	unchanged	chain (Stellar)	unchanged

Two readings of the table are worth stating in words. First, claims 1, 2, and 5 are grade “bundle” in every row: no outage anywhere touches them. Second, a holder who downloaded the complete file, which is the default, loses no claim to Truestamp’s disappearance, provided that file carries a signing key event for claim 6 and that the holder does not need claim 7’s wider ledger neighborhood. Every remaining “ledger” in the table belongs to a compact bundle, so the fix is a one-time download rather than a property of the format.

Worked example A: everything reachable

The verifier holds a complete item bundle and the original file, and has network access. This is the sequence that establishes every claim the matrix allows, including the after edge, without fetching anything from Truestamp.

1. Run the offline core: hash comparison against the file, the subject metadata hash derived from the carried map, the subject and block hash derivations, the inclusion walk to the block root, the epoch walks to each committed root, the signature check. All pass.
2. Confirm the before edge on chain. Fetch the Stellar transaction from a Horizon endpoint and match its memo to the epoch root: the ledger close time is the submitted-before edge. Look up the Bitcoin transaction by id at the recorded height with a node or explorer, confirm the OP_RETURN payload equals the epoch root, and note the header time and confirmation depth as corroboration.
3. Rehash each carried witness. The head block map rehashes to a block hash; each entropy payload is canonicalized and hashed under the entropy prefix. Every one must equal the value the item’s metadata commits to. This step is what makes everything after it evidence rather than testimony: any other record would not hash to a value the bundle already carries, and the composite fingerprint under the signature commits to those values.
4. Check the ledger position. If the head block’s hash equals the containing block’s previous-block hash, the head block is its direct predecessor. If not, walk the carried block path oldest first, confirming each link, and confirm the last entry hashes to the containing block’s previous-block hash.
5. Re-fetch each entropy witness from its own source. The NIST pulse by chain index and pulse index (compare the output value and the pulse timestamp), the Stellar ledger by sequence (compare the hash and the close time), the Bitcoin block by hash (compare the height and the header time). A match establishes the value exists in the source’s records.
6. The submitted-after edge is the latest published time among the confirmed witnesses. Read a Bitcoin-derived edge conservatively: a header time may run up to two hours ahead of real time under Bitcoin’s rules, so either subtract that tolerance or let a NIST or Stellar witness carry the edge.
7. Bind the key. If the bundle carries a signing key event, recompute its block hash and walk its epoch proofs to their roots, then confirm those transactions on chain. Cross- check the key against a pinned keyring as well if one is in hand.

What the report should print, beyond the passing core:

• Stellar Commitment: pass naming the ledger and its close time; Bitcoin Commitment: pass naming the height, header time, and depth.
• Witnesses: pass for each carried witness, plus a pass on the ledger position naming the head block or the length of the block path.
• Signing Key Event: pass naming the event type and sequence, and Key Binding: pass when a keyring was pinned, with the note that the keyring carries no validity interval.
• Submitted before: <Stellar close time> (tightest) with the Bitcoin header time as corroboration.
• Submitted after: <source published time> naming the source, the witness, and that it was confirmed against that source in this run.

What the holder can honestly say: these exact bytes existed unchanged; they were submitted after the named public value was published and before the named public transaction; a key introduced by a publicly committed key event signed the proof. What the holder still cannot say: when the content was created, who wrote it, or anything about what it means.

Worked example B: Truestamp gone, both chains reachable

The domain, the ledger, the keyring endpoint, and the did:web document no longer resolve. The chains and the NIST beacon are fine. The holder has the complete bundle.

• Claims 1, 2, and 5 pass exactly as before; nothing in them ever touched Truestamp.
• The before edge is established on both chains. The Stellar transaction is still in the ledger history any full-history Horizon serves; the Bitcoin transaction is permanent.
• The after edge is established too, and this is the change that matters. The witness payloads are inside the file, they rehash to the values the fingerprint committed to, and NIST, Horizon, and a Bitcoin explorer all still answer. Every party in that chain is one Truestamp does not run.
• Ledger position holds for the stretch the bundle carries: the head block, the block path if present, and the containing block all recompute, and the containing block’s hash is under a root on both chains.
• Key binding holds from the carried signing key event, whose block hash recomputes and whose commitments still confirm on chain; that is reported under Signing Key Event, and the keyring cross-check stays a separate row. Without a key event the claim rests on that cross-check alone, which is pass only for a verifier who pinned the keyring while it existed and skip for everyone else, forever.

What the report should print: the passing core; both commitment groups pass; every witness pass and confirmed; Submitted before: <close time> and Submitted after: <source published time> both established; Signing Key Event: pass.

Now the same scenario with a compact bundle. Claims 1, 2, 3, and 5 are identical. The after edge is not established: the metadata still names each witness by hash, so the report can say precisely which records would close it, but the records themselves lived on a ledger that no longer answers. Key binding falls back to a pinned keyring. What the holder can say shrinks to one edge of the window rather than an interval, which is the whole argument for keeping the complete file.

Worked example C: fully offline

No network at all: the verifier has the complete bundle, perhaps the file, perhaps a pinned keyring.

• Every offline step runs and passes: the hash comparison, the metadata hash derivations, the subject and block hashes, the inclusion walk, the epoch walks, the signature, every witness rehash, the block path walk, and the key event’s own block hash and epoch walks.
• Stellar Commitment: skip. Bitcoin Commitment: skip, preceded by info rows when the entry carries the raw transaction and the txoutproof: the OP_RETURN payload equals the epoch root, the transaction id recomputes, the partial Merkle tree reaches the header’s root. Those rows are internal consistency, never confirmation. A fabricated low-difficulty header over a one-transaction tree carrying any 32-byte OP_RETURN would pass all of them, which is why they are info and not pass, and why binding the commitment to Bitcoin needs one external confirmation point.
• Submission Window: pass on the ordering of the item id’s time against the block id’s time, labelled as asserted by Truestamp and not externally verified.
• Submitted before: named (the earliest commitment timestamp), not established. Submitted after: named, with one row per witness giving the time its payload carries, and a closing row saying no witness was confirmed against its source in this run. That is stronger than the before edge offline: the times are read from payloads the fingerprint commits to, so they cannot have been edited after the fact. What is missing is confirmation that those payloads really are the records NIST, Stellar, and Bitcoin published.
• Key Binding: skip without a pinned keyring, and Signing Key Event reports the recomputations that passed with its chain confirmations skipped. Offline and unpinned, the whole bundle is something anyone with a keypair could have produced; the internal chain proves only that it is self-consistent.

What the holder can honestly say: the file in hand matches the proof, and the proof is internally consistent, including the records it says it was submitted after. Nothing is tied to the outside world until a chain or a source is consulted.

Worked example D: a redacted item

Redaction nulls the stored claims and keeps every hash, the metadata, the signature, and the commitment record, so the block’s Merkle root is unchanged and every bundle already issued keeps verifying. Truestamp will not issue a new bundle for a redacted item.

• A bundle downloaded before redaction still carries the claims. In content mode that means the content itself is inside every copy already downloaded; redaction withholds it from Truestamp’s surfaces and cannot recall it from anyone’s files. In hash mode the bundle carries the digest and the label only.
• The after edge is unaffected in either direction: a complete bundle carries its witnesses, and redaction leaves both the item’s metadata map and the ledger records those witnesses name in place.
• The public verification page for the item shows its claims step as skipped and its status as redacted; the bundle-based report is unchanged.

What the holder can honestly say: everything they could say the day before redaction. What they cannot do: obtain a fresh bundle, so a Stellar-only bundle downloaded early stays Stellar-only unless they also download the containing block’s own proof (see example H).

Worked example E: an expired free-plan item

Free-plan items are retained for 90 days, then scheduled for deletion with a 7-day grace period during which the owner can cancel by returning to a paid plan. After the grace period a sweep permanently removes the item row and its commitment record. Blocks and entropy observations are never removed.

• Every bundle already downloaded keeps verifying, offline and on chain: claims 1, 2, 3, and 5 are untouched, and the block’s Merkle root still contains the leaf.
• The item’s verification page and its raw contents return not found. No new bundle can be generated, so whatever variant the holder downloaded is the one they keep forever.
• For a complete bundle the after edge is untouched, because everything it rests on is inside the file: the witness payloads and the hashes they must reproduce. Nothing is fetched from Truestamp to establish it.
• For a compact bundle the after edge is still recoverable while Truestamp is reachable, at ledger grade. The metadata map travels in every bundle, so the committed witness hashes are in hand; pasting one into the public search finds the head block or the entropy observation it names, and rehashing that record’s raw contents confirms it is the record the fingerprint committed to. This works after the sweep because the witnessed records are ledger objects rather than item data: the item row is gone, and the block and the observations it pointed at are not.

What the holder can honestly say, from a complete bundle: everything example A allows, indefinitely. From a compact bundle: the same claims, but the after edge needs Truestamp to still be answering, and it is lost if Truestamp goes away.

Worked example F: NIST frozen during a shutdown

During a US budget lapse the NIST beacon serves its last pulse indefinitely. Truestamp deduplicates observations on the value’s hash, so a frozen pulse is captured once and then skipped; items submitted during the freeze keep committing to that same stale pulse as their NIST witness, while their Stellar and Bitcoin witnesses keep moving.

• For an item submitted during the freeze, the NIST-derived after edge is the last live pulse, earlier than the truth. It is still sound: the item was indeed submitted after that pulse. It is loose, not wrong.
• The Stellar and Bitcoin witnesses carry the tight edge, and a verifier taking the latest confirmed published time across witnesses lands on one of them.
• For an entropy proof of the frozen pulse itself, the source re-fetch passes: the value exists in NIST’s records. The report must say existence, never freshness.

What the report should print for the after edge: each witness’s time separately, the latest confirmed one as the operative edge, and for NIST the note that a re-fetch confirms the value exists and says nothing about when it was fresh.

Worked example G: a reorganization before six confirmations

Truestamp marks a block committed on Bitcoin at first inclusion and re-verifies recorded commitments against the live chain on a schedule; a block whose commitment stops being true returns to finalized and is recommitted in the next epoch.

• If the transaction is reorganized out and mined again in a later block, the transaction id in the bundle is unchanged, but the recorded height, header time, txoutproof, and block Merkle root are stale. A verifier looking up the transaction by id finds it at a different height. The honest report is a Bitcoin pass earned by that live lookup finding the transaction with the expected OP_RETURN, with a warn that the recorded height and header no longer match the chain, and the new header time as the before edge for that chain. The offline rows over the carried bytes stay info, since they never confirm anything against Bitcoin.
• If the transaction is dropped entirely, the bundle’s Bitcoin entry is permanently unconfirmable: a definitive not-found is a fail for that group, and a verifier that cannot look it up reports skip. The Stellar entry is unaffected, and the before edge rests on it. A holder who can still reach Truestamp downloads a fresh bundle carrying the recommitted Bitcoin entry.
• Nothing here touches the after edge. A commitment closes the later edge only; the witnesses that open the earlier one are unrelated records.
• Stellar ledgers do not reorganize once closed, so no Stellar scenario has this shape.

What the holder can honestly say: the before edge on Stellar, in every case. On Bitcoin, only what the live chain confirms.

Worked example H: a Stellar-only bundle downloaded early

Stellar epochs are committed about every five minutes and Bitcoin epochs about every fifteen, then wait for confirmation, so a bundle downloaded in the first minutes after Stellar lands carries one commitment entry.

• The bundle is complete and permanent: the Stellar close time is a final public moment within seconds of the transaction, and nothing in the file ever becomes wrong.
• It carries no Bitcoin corroboration for the before edge. Re-downloading later yields a bundle with both entries, for an item that is still committed and neither redacted nor expired.
• The after edge is unaffected: witnesses are captured at submission, so an early download carries exactly the same witness set as a later one. A Bitcoin witness and a Bitcoin commitment are different things, and only the second one arrives late.
• For a redacted or swept item, no new item bundle exists, but the containing block’s own proof at /blocks/<block_id> carries both chains’ entries and the same block fields. The item bundle proves the item is in the block; the block bundle proves the block is in a Bitcoin epoch; together they give the holder the Bitcoin edge without a fresh item bundle.

What the holder can honestly say: bytes existed unchanged no later than the Stellar close time. Adding “and no later than the Bitcoin block” needs the second bundle.

Why the two edges still differ

Both edges are now reachable from a complete bundle, but they are not symmetric, and the asymmetry is worth naming.

The before edge is closed by a record created after the submission, so the bundle can only carry a pointer to it: the commitment’s transaction hash and timestamp are a candidate until a chain lookup confirms them. Nothing offline can settle it, because the evidence lives on a chain by construction.

The after edge is opened by records that existed before the submission, so the bundle can carry the records themselves. Offline, a verifier already establishes that the fingerprint committed to those exact payloads and reads the times they carry; the network step only confirms that the payloads really are what NIST, Stellar, and Bitcoin published. That is why the after edge survives Truestamp’s disappearance from a complete bundle, where a compact bundle has to go and fetch the same records from Truestamp first.

The remaining dependence is a choice, not a property of the format: carry the witnesses, and the edge is yours permanently; carry none, and you keep a pointer that only Truestamp can currently dereference. Downloads default to the complete file for that reason.

Limitations

• This reference is about what is establishable, not about what is true. A claim graded “not established” in a scenario is not a claim that has become false; it is one the verifier can no longer check.
• Every grade assumes the verifier reaches an honest copy of the public record. A Horizon endpoint, a block explorer, or a beacon mirror that lies is outside the matrix; the defense is to use more than one, or your own node.
• A Bitcoin header time is set by the miner within consensus rules and may run up to two hours ahead of real time. It is a fine before edge (the block existed no earlier than it was mined, and confirmation depth settles it) and a loose after edge unless read conservatively.
• The witnesses are chosen by Truestamp at submission. A dishonest choice of older records widens the window and never narrows it, so the after edge can be loose but not falsely tight; the ordering of Truestamp-minted identifiers is likewise a consistency check on Truestamp’s own record, not outside evidence. The head block witness is the one entry whose own time is Truestamp-minted, which is why it is reported as a Truestamp-asserted basis and never as a public moment.
• A confirmed signing key event establishes that the key was introduced by a block committed to a public chain, which is a fact about those chains rather than about Truestamp’s web server. It is not a substitute for knowing which published identity you are dealing with; that is what the keyring and the did:web document are for.
• Nothing in any row establishes creation time, authorship, uniqueness, or the truth of the content. See what Truestamp does not prove.

Citations

1. NIST Randomness Beacon 2.0 API. The pulse endpoint family a verifier re-fetches by chain index and pulse index; the pulse timeStamp is the source-published time used for a NIST-derived after edge.
2. Stellar Horizon: retrieve a ledger. The ledger endpoint a verifier re-fetches by sequence; its closed_at is the close time used for both Stellar edges.
3. Bitcoin block header reference. The header time field and the consensus rule that it may not exceed network-adjusted time by more than two hours, which is why a Bitcoin-derived after edge is read conservatively.