How the notary works

A walkthrough of the sealing process

The notary tool is used by one person — me — to seal documents under my own key. This page shows what happens when a document is sealed, step by step, so that anyone can inspect the process and verify the results independently.

The interface below is a mock. It shows a real example, sealed on 3 October 2026, with the description and fingerprint that were actually published. The buttons are disabled because the tool is not public — sealing is done from a private page with a wallet signature. Everything else below is what the tool does.

The interface

The example above records the same file that appears on the notary page. Its attestation is live on Celo, and anyone can look it up on celo.easscan.org.

What happens when a document is sealed

What the record shows

An attestation is public. Anyone can find it on Celo by querying the schema UID. What they will see:

• The fingerprint — the 32-byte hash of the file.
• The description — the short title written at sealing time.
• The status — "sealed", "revealed", or "provable".
• The date — the block timestamp, on record permanently.
• The signer — the wallet address that submitted the attestation.

What they will not see: the document, its content, or its filename. None of these are on-chain, and none can be inferred from the fingerprint.

How verification works

Given a copy of the original file, anyone can verify that it matches the record:

1. 1 · Fingerprint Compute the SHA-256 of the copy.
2. 2 · Look up Query Celo for the attestation matching that fingerprint.
3. 3 · Compare If the fingerprint matches and the record is signed by the expected address, the file is the one that was sealed.
4. 4 · Date The block timestamp of the attestation is the date on which that fingerprint entered the record.

The verification requires no cooperation from me, from any platform, or from any institution. It requires the file and access to the blockchain. A public verification tool performs the check in the browser.

The schema

The record is defined by a single schema, registered once on Celo. Its fields are:

Every field is deliberate. contentHash is typed as bytes32 because SHA-256 produces exactly 32 bytes. title and uri are strings because their lengths vary — an IPFS CID alone exceeds the 32-byte limit. status is a string rather than an enumeration so that a reader looking at the raw attestation sees "sealed" rather than a number.

Why on-chain

A record that lives in a database can be changed by whoever controls the database. A record on a public blockchain is written by a transaction, confirmed by consensus, and cannot be altered without invalidating every subsequent block. That is the property the notary relies on: the date is not a claim, it is a fact about the chain.

Any public chain would do. Celo is used because the collective's register already runs on it, and because attestations on Celo cost a fraction of a penny, which makes the practice of sealing routinely affordable. The Ethereum Attestation Service (EAS) provides the schema mechanism, so the fields are standard and readable by any EAS-compatible tool.

What is not recorded

Three things the notary deliberately does not do.

It does not host documents. The register holds no files. If a document is lost, the record survives, but its contents cannot be recovered from the chain. Preservation of the file is the sealer's responsibility.

It does not assert authorship. The record shows that a fingerprint existed at a date, signed by a key. Whether the sealer wrote the document, or merely held it, is not something the chain can determine. A verified record is a starting point in any dispute, not a conclusion.

It does not prevent copying. Nothing prevents a sealed document from being copied and published elsewhere. What the record does is establish that the sealed version existed, in the sealer's possession, before the copy appeared. The date is the whole contribution.