Quantum Notary
Start free →Sign in

◈ Security

What is sent, what is stored,and where the claim stops.

The claim

Your file never leaves your device.

SHA-256 is computed in your browser. We receive only the fingerprint and optional metadata (file name, size, file type). Both flows, no exception.

◇ The limits

A digest is not a secret.

Hashing is not encryption and not automatic anonymization. Anyone who can guess the contents can hash their guess and compare it with the published digest, so short, predictable or low-entropy files are the ones this matters for.

Metadata leaves if you turn it on

Filename, byte size and content type are off by default. Switch them on and they reach us with the request and sit off-chain beside the record, where we can read them.

Guest checkout involves Stripe

Paying without an account sends your payment details to Stripe, and a recovery email if you give one. That exchange is between you and them, under their terms.

Some request facts always cross

Your IP address reaches us on every request, in both flows, and hCaptcha sees browser and challenge data on the guest path. Neither is optional; both exist to control abuse.

No outside review

No third-party audit has been done: no SOC 2, ISO 27001, or PCI report has been produced for this service, and none is claimed. What you can check instead is the anchor — recompute the digest and read the transaction from Base yourself.

◇ The evidence

Four things that would have to be false.

SHA-256 runs in your browser, before anything is sent.
The Web Crypto API hashes the file you picked. You can watch it happen — open the network tab and the request that goes out is a few hundred bytes, no matter the size of the file you dropped in.
We receive the 32-byte SHA-256 fingerprint.
A digest, and nothing that can be turned back into the file. There is no copy of the body on our servers to leak, to subpoena, or to lose — not because we delete it, but because it was never sent.
What gets published is those same 32 bytes.
Written into the input data of a Base L2 transaction, at a 32-byte-aligned slot your receipt names, with the date it was included. A transaction often carries several digests at once, which discloses that those records were submitted in the same short window and nothing else about them. Nothing else goes on-chain — not the filename, not the size, not who anchored it.
Checking it later does not need to run through us.
Recompute the hash, open the transaction on any public Base explorer, compare. We do offer a free verification tool anyone can use, and a records dashboard if you have an account — but neither is required, and that comparison uses no API of ours and no record of ours.

◉ The two ways in

What each one actually sends.

Signed in

Anchoring from your account

  • DeviceThe file body, hashed here and never transmitted
  • SentA 32-byte SHA-256 digest
  • SentYour IP address, for rate limiting and abuse control
  • Opt-inFilename, byte size, content type — off by default

Nothing about the record reaches us that is not on that list. The digest is also written on-chain; the rest is not.

Guest checkout

Anchoring without an account

  • DeviceThe file body, hashed here and never transmitted
  • SentA 32-byte SHA-256 digest
  • To StripePayment details, and a recovery email if you give one
  • SenthCaptcha challenge data, for abuse control

The receipt URL is an unguessable secret — not indexed, not placed in navigation, and it stops working after one year. That is an access policy, not a deletion promise.

In transit and at restTLS on every connection. Credentials hashed at rest.
Tenant isolationEvery record, key and ledger entry scoped to your tenant, at the database layer.
Relayer permissionsAnchoring transactions only. No read, no modify, no delete.
IrreversibilityDigest bytes inside an included Base transaction cannot be removed by us.

◇ The escape hatch

Three comparisons, and a public explorer is enough for all of them.

Recompute the fingerprint
SHA-256 the file you kept. Any tool, offline, on a machine we have never touched.
Open the transaction your receipt names
On any public Base explorer or RPC provider serving historical data. There are several.
Read the 32 bytes at the position given
Same bytes, or not. That is the whole check, and no part of it asks us anything.

“Independent” here means the checking path does not run through our API or our records. It does not mean the check floats free of everything — the full list of what it does depend on is beside this, and it is short enough to print.

What the check depends on
You keep
The exact file

Unaltered, byte for byte. A re-exported PDF or a re-compressed image produces a different fingerprint and will not match — that is the mechanism working, not failing.

You keep
The receipt

It names the Base transaction and the position your fingerprint sits at inside it. Without the position, a reader has to search the transaction rather than look it up.

The world keeps
Base history, through somebody

Any public explorer or RPC provider serving historical Base data will do. This is the one dependency that is nobody’s promise — ours included.

▸ Threat model

What holds, and what it does not do.

Quantum Notary is compromised

What holds

A retained file and its receipt can still be checked through suitable Base infrastructure, without our API or our database.

What it does not do

You need the file and the receipt in your own hands. Nothing in that scenario is recoverable from us.

The file has been tampered with

What holds

A single bit-flip changes the SHA-256 digest, and it no longer matches what was anchored.

What it does not do

It does not say who altered it, or which copy was the original if you kept none.

Insider risk

What holds

Login, credential-change and administrative events are written to the audit log. Tenant data is isolated at the database layer, not just the application.

What it does not do

An audit log is a record of what happened, not a control that prevents it.

Chain history changes

What holds

Every finalized record carries Base transaction and block references you can resolve yourself.

What it does not do

Verification reports what the selected RPC or explorer returns. Higher-stakes checks should compare independent infrastructure.

Relayer compromise

What holds

Relayer accounts hold permission to submit anchoring transactions and nothing else — they cannot read, modify or delete records.

What it does not do

It does not stop a compromised relayer submitting anchors nobody asked for. It could not alter or withdraw an anchor that already exists.

A guest receipt link leaks

What holds

The URL is unguessable, is not indexed and is not placed in navigation, and stops working after one year.

What it does not do

Anyone holding the link can open it inside that window — that is what the link is for. Keep it out of public messages.

▸ Subprocessors

8 companies touch this, each named with what it gets.

The current list — every vendor, what it receives, and where it operates — lives on the subprocessors document, which is the page of record. Thirty days’ notice before it changes.

The sentence is testable in ten minutes.

Anchor a file you don’t mind being public, then check it on the official, or any third party, Base network explorer.

Check a file — freeRead the procedure