Anchor a file. Standard or Sealed.
Two browser-form flows over the same chain. Pick the mode below, drop a file in, get a tamper-evident proof that an outside auditor can verify without us — its anchor is a public Bitcoin SV transaction anyone can confirm on a block explorer, in any browser.
Standard Proof or Sealed Proof.
Same chain, same verifier. They differ in what someone watching the public chain can learn about your file.
One question decides it: if a stranger noticed your on-chain transaction, would it matter that anyone holding the same file could confirm a proof exists for it?
Same flow · one step differs
Standard vs Sealed
Both anchor to the public chain and verify the same way. The only difference is what gets anchored, and when the data is shown.
Standard
For: proving a file, run, or manifest hasn’t changed — when the data can be shared now.
-
1
Your data
file / run / manifest
-
2
The difference
Anchor the fingerprint of the data
sha256 — payload stays with you
-
3
Public-chain anchor
broadcast to the chain · one tx
-
4
Verify anywhere
re-hash data · check anchor
Sealed
For: bids, votes, evals — when the data must stay private until a later reveal.
-
1
Your data
bid / vote / eval
-
2
The difference
Anchor a private commitment
salted — data revealed later
-
3
Public-chain anchor
broadcast to the chain · one tx
-
4
Reveal, then verify
disclose data + salt · check anchor
Step 2 is the whole difference: Standard anchors the fingerprint of the data so anyone can re-hash it now; Sealed anchors a private commitment — the file is fingerprinted together with a salt, a random secret value your browser generates, so observers can’t test candidate files without it — and the data is revealed later. Everything else — the public-chain anchor and the offline check — is identical.
One flow·One step differs·Verified the same way
Standard Proof
Use when the file is public now, or will be revealed later: released artifacts, public policy snapshots, signed contracts, code releases, revealed bids.
Create a Standard Proof →Sealed Proof
Use when even confirming a matching file would be sensitive: unrevealed bids, internal policy snapshots, private evidence manifests, legal exhibits, pre-release materials.
On the form, Sealed has one sub-choice: Mirror (default — we hold a salt-bearing server copy) or Blind (the salt never leaves your browser). Compared in the table below.
Create a Sealed Proof →The whole choice, in one table. Standard vs Sealed is the real decision; inside Sealed, Mirror vs Blind is a sub-choice that decides where the salt lives.
| Mode | Who can confirm a match | Where the salt lives | What reaches our server |
|---|---|---|---|
| Standard | Anyone holding the file (or its SHA-256) can confirm a proof exists | No salt — the fingerprint is anchored directly | The file’s fingerprints and size, computed in your browser; we keep the bundle until you delete it |
| Sealed · Mirror (default) | Only a holder of the salt can test a file against the anchor | In your bundle, and in a server copy until you delete the proof or its auto-delete window ends | Salted commitments, the salt, and the file’s fingerprint (sent so the proof is findable from the file later; stored only as a keyed hash); we hold the salt-bearing bundle for that period |
| Sealed · Blind | Only a holder of the salt can test a file against the anchor | In your downloaded bundle only — it never leaves your browser | Salted commitments only; no salt, and no bundle is stored on our server |
What goes where
What stays private, and what reaches the public chain.
Neither mode uploads your file. Here is exactly where each piece lives.
-
Stays with you
- Your original file — never leaves your device
- The Sealed salt — in your bundle; under the default Mirror option a copy is also held on our server until you delete the proof (or its auto-delete window ends). Choose Blind if the salt must not reach us — it then never leaves your browser
Verification later re-hashes this. Keep it.
-
In your bundle (.mbnt)
- Your proof — the verifiable claim you keep and share for later verification
- The Sealed salt, if Sealed — not the file bytes
Portable. A verifier re-checks the proof from this.
-
On the public chain
- A short commitment and the transaction timestamp
- An anchor — a timestamped commitment recorded on-chain
Permanent and public. No file content, ever.
-
On Satsignal
- Proof metadata, kept retention-dependent
- Under Sealed Mirror (the default): the salt-bearing bundle, salt included — Blind leaves no server copy
- Never your file’s bytes
You verify without us — the bundle is enough.
Keep these two together
Verification later needs both: the original item and the bundle. Either mode commits to your file’s fingerprint, not its bytes.
Sealed mode keeps its salt in the bundle. Under Blind your download is the only copy — lose it and the sealed proof can no longer be re-checked. Under Mirror a server copy also exists until you delete it (or its auto-delete window ends).
Format-aware fingerprints.
Fingerprints are content-aware: a re-saved PDF or re-exported CSV still verifies. Per-section breakdown enables selective disclosure of one page or row. Per-format detail in the bundle spec →
| File | Content fingerprint | Section breakdown |
|---|---|---|
| extracted text, normalized | per page | |
| JSON | RFC 8785 canonical | per top-level key |
| CSV | RFC 4180 normalized | per data row |
| Source / text | NFC-normalized, line-ending stable | per line |
| ZIP / DOCX / XLSX | entry manifest | per contained file |
| Image (JPG/PNG/WebP) | raw pixel data, metadata stripped | per tile |
| Anything else | byte-exact hash only | n/a |
Why this matters. A re-saved PDF, a re-compressed JPEG with metadata stripped, or a CSV re-exported with different line endings still verify against the content hash — even though the byte-exact hash changes.
Real proofs — one per format.
Each card opens the live proof page for a sample file we anchored. Bundles are public; the verifier has a one-click demo for both the Standard and Sealed flows. Click through to see the shape of the proof you’ll get when you anchor your own.