Verifying a notarization proof
Every note is SHA-256 hashed — an append-only note as each entry arrives, an editable note as a once-a-day snapshot of what changed — and each day's hashes are committed to the Bitcoin blockchain via OpenTimestamps. A proof lets anyone confirm that a note's content existed by a certain time and has not changed since — without trusting Fresh Jots.
confirmed);
in the hours before that it rests on the OpenTimestamps calendar servers.
Two ways to check a note
The fast way — on your Provenance dashboard, click Verify next to any note: it runs the whole proof in your browser and shows the result, with nothing to install. The trustless way — download the proof and check it yourself, trusting no one, with the copy-paste walkthrough for your note type:
- Verify an append-only note — a log or stream you only append to (an AI-session log, a cron feed). You check every entry, in order.
- Verify an editable note — a note you edit, rich or plain. You check its dated daily snapshots.
- Verify an encrypted note — a note you encrypted yourself. Same checks on the ciphertext, plus one step to decrypt and confirm it's your content.
Not sure which you have? The checks are identical — only what the entries mean differs — so any walkthrough works; an encrypted note just adds the decrypt step. The section below is the reference behind all three.
The proof bundle
Fetch it from GET /api/v1/notes/:id/proof with your API token.
It is a JSON document: a note_token, a
recipe_version, the
anchors it references, and an
entries list — one entry per hashed event (a plain note's
creation, each append to a log, and each daily snapshot of an editable note). Everything below can be
checked offline, with the app stopped.
Verify it yourself
-
Content integrity. For each entry, base64-decode
contentand SHA-256 it — the result must equalcontent_hash. These are your exact bytes. -
Leaf value (recipe 1). Compute
SHA-256(0x00 ‖ note_token ‖ prev_hash ‖ content_hash)—note_tokenas its UTF-8 bytes, the two hashes as their raw 32 bytes. Foldingnote_tokenandprev_hashin is what makes the stream's identity and order part of the Bitcoin commitment, not just something we assert. -
Merkle branch. Fold the leaf value up through the entry's
branch: at each step computeSHA-256(0x01 ‖ left ‖ right), placing the sibling hash on the givenside. The result must equal the entry's anchorroot_hash. The0x00/0x01prefixes are load-bearing: they make it impossible for a tree node to be passed off as a leaf. -
Order. For an append-only note, each entry's
prev_hashmust equal the previous entry'scontent_hash. That chain is what proves the entries are in the order they were written. (A caveat, in the interest of honesty: the chain can prove nothing was inserted, reordered, or dropped from the middle, but not that nothing was withheld after the last entry you hold.) -
Bitcoin. Each anchor ships its OpenTimestamps proof
(
ots, base64) — a commitment to the anchor'sroot_hash. Save it and runots info proof.ots: it prints one or moreBitcoinBlockHeaderAttestation(<height>)lines plus each block's Merkle root. Look the earliest block up on any public block explorer — its timestamp is when your content provably existed, and its Merkle root must match the one shown. (ots verify proof.otsautomates this but needs access to a Bitcoin node — a localbitcoindor an explorer backend — so theots info+ explorer path above is the no-setup option.) Nothing in this step involves Fresh Jots.
Or timestamp it yourself, first
For a proof that never touches our servers at all, timestamp your file before you upload it, with the same OpenTimestamps client:
ots stamp mynote.txt # creates mynote.txt.ots
# ...upload mynote.txt to Fresh Jots; keep the .ots file...
ots info mynote.txt.ots # read the Bitcoin block, check it on any explorer
# (or `ots verify mynote.txt.ots` if you run a Bitcoin node)
Your .ots file, plus your own copy of the note, is a complete
independent proof — one we are not part of and cannot alter.