Notary

The log holds 5025 leaves from 12 sources. Each leaf is a 0x… sha256 and four fields of context — a sealed head, a certificate, a receipt — and nothing about who or how much. The head below is the RFC 6962 root over all of them, recomputed here; fetch the leaf stream and rebuild it yourself.

Growth

Measured from the leaves’ own seal-times — not asserted. A leaf counts in a week because the work it seals happened that week, so the figures below cannot move unless the estate’s real activity does.

Leaves sealed per week — the last 8 weeks, oldest to newest.

Who is in the log

Each property folds its own hashes in. A checkpoint/1 leaf is a property’s whole sealed record in one root; the finer kinds — certificate/1, receipt/1 — are one leaf per event.

Browse the log

Every leaf, newest first — the same stream served at /.well-known/notary-log.json, one screen at a time. Each row is a 0x… sha256 and four fields of context; there is nothing here about who or how much, because there is nothing like that in the log.

What the log proves, and what it does not

The head is reproducible: anyone can rebuild it from the leaf stream, and a consistency proof shows the log only ever grew. It is not yet tamper-evident — that needs a cosignature from a party that is not the estate, and until one exists the log says so rather than implying more. See the checkpoint for the per-property root and verify to hash a record in your own browser.

Served at /api/v1/public/notary (head + proofs) and /.well-known/notary-log.json (the full stream). This page is derived from that stream — the estate’s fan-in runs every six hours, and a fold that changes the log deploys this page with it, so a new hash appears here on its own without anyone pushing.