1 · Your proof
The file you notarized (optional — hashed locally to prove it matches the certificate)
The proof certificate (JSON)
Base RPC to read from (optional — defaults to a public one; paste your own if you prefer)
Verify locally
2 · Verify it yourself, by hand
You never have to trust this page. Reproduce every step with your own tools:
Hash your file. On any machine:
sha256sum yourfile # or: shasum -a 256 yourfile
The result (prefixed with 0x) must equal the certificate’s hash.
Read the Base anchor. Call notarizedAt(hash) on the contract with any RPC:
cast call <contract> "notarizedAt(bytes32)(uint256)" <hash> --rpc-url https://mainnet.base.org
A non-zero result is the proof-of-existence timestamp (unix seconds) — and it must equal the certificate’s timestamp. Or open the txHash in a Base block explorer and read the Notarized event. Pin the issuer: the certificate’s chainId/contract are self-declared — confirm the contract is the real notaros deployment before you trust a check mark.
(If present) verify the Bitcoin proof. Save the certificate’s ots.otsBase64 (base64-decoded) as proof.ots next to your file, then:
pip install opentimestamps-client
ots verify proof.ots # checks the file's sha256 was committed to a Bitcoin block
A pending proof is still upgrading — run ots upgrade proof.ots later.
The certificate is self-contained: {hash, algorithm, chainId, contract, txHash, blockNumber, logIndex, timestamp} (+ optional ots). Anyone, anywhere, forever, without us.
3 · Verify entirely on your own — with tools that aren’t ours
notaros could disappear tomorrow and your proof would still stand. Here is how to confirm it using nothing of ours — because a notaros proof rests on three open standards, none of which is notaros:
Compute the fingerprint yourself — SHA-256. Any operating system already ships a tool:
sha256sum yourfile # coreutils (Linux)
openssl dgst -sha256 yourfile # anywhere OpenSSL is installed
certutil -hashfile yourfile SHA256 # Windows
The result must equal the certificate’s hash. SHA-256 is the algorithm defined by NIST FIPS 180-4 ↗ — it is in every OS and security tool, and always will be.
Reproduce the Merkle construction — RFC 6962. When a proof is part of a Merkle batch, the proof file names the exact construction it uses — the Certificate Transparency Merkle tree of IETF RFC 6962 ↗ , the same construction that underpins web-PKI Certificate Transparency. Because the proof is self-describing, anyone can recompute the root with any of the many independent open-source verifiers.
Confirm permanence on Bitcoin — OpenTimestamps. This is the durable guarantee. Verify the certificate’s .ots file against the Bitcoin blockchain with the open client from opentimestamps.org ↗ (source and install: opentimestamps-client on GitHub ↗ ):
ots verify proof.ots
Then inspect the anchoring Bitcoin block yourself on mempool.space ↗ or blockstream.info ↗ . A self-contained .ots proof plus Bitcoin verifies existence forever, trusting no company.
(Convenience) Read the Base anchor. The Base anchor is only the fast, cheap convenience anchor — Bitcoin/OpenTimestamps is the permanent one. Open the certificate’s txHash in the public explorer basescan.org ↗ and read the Notarized event for the on-chain timestamp.
Our own downloadable offline verifier is one option among these — not a requirement. Every tool above is external, authoritative, and outside our control. That is the point: your proof depends on open standards, never on notaros.