Lesson 05 of 05
Suppose nobody trusts the service that issued the receipt
The live panels show the digest comparison. The labelled record shows what an example receipt contains; its chain values are illustrative and cannot be looked up.
The situation
On 3 March you sent a client a signed services agreement and recorded its fingerprint the same day. In August the client produces a version with a different payment term and says it is the one you sent. Both files open. Both look fine. The question the fingerprint can answer is narrower: which copy reproduces the recorded digest?
The example record
Illustrative Base record
Example values only — this is not a transaction you can look up.
A real receipt provides the values needed to inspect a real Base transaction.
- block
- 178,620,608
- Base block time
- 3 March 2026 · 14:02:11 UTC
- transaction
- 0x7a2f…e4c1
- batchIndex
- 0
- batchSize
- 1
- slot
- slot 0 — bytes 0–31
- transaction type
- eip1559
- from
- 0x4c1a…9fe2
- to
- 0x4c1a…9fe2
- value
- 0 ETH
zero-value relayer self-transfer · 32-byte digest slots concatenated in claim order
The comparison
Both panels are live. Edit either one and the fingerprint and result change. Try putting the second copy's payment term back to 30 days.
Your copy
services-agreement.txtRecomputed now
Computing fingerprint…Their disputed copy
services-agreement.txtRecomputed now
Computing fingerprint…What it supports
What a real check supports
- The retained file reproduces the receipt's digest under the same processing rule.
- The digest equals the 32 bytes in the real transaction slot named by batchIndex.
- The included Base transaction supports that the data existed in that form no later than the relevant chain record.
What it does not settle
- Who wrote the agreement, signed it, supplied it, or owns it.
- Whether the terms are true, fair, binding, or enforceable.
- What happened before or after anchoring, including whether a later revision was sent.
- Confidentiality, storage, a complete chain of custody, or a legal outcome.
Technical version — how the real check works
First compute SHA-256 from the exact retained bytes — for this text sample, a local tool could run shasum -a 256 services-agreement.txt. For a real record, use the real receipt to retrieve its Base transaction, then compare the digest with exactly 32 bytes beginning at batchIndex × 32 in the transaction input. Do not search for the digest at an arbitrary position.
This independent path needs no Quantum Notary account, API, or database. It still depends on the exact retained data, the receipt's transaction and slot details, and Base history through an RPC provider, explorer, or archival infrastructure. The example block and transaction on this page are illustrative, so they are not lookup instructions.
Use a real receipt and retained file when you need to perform the check.
Verify a file →