VERIFY · LIVE
Notary
One append-only log of hashes — never content — from across the estate. Every figure below is recomputed from the leaf stream a stranger can download; none is a number we typed.
The log holds 6464 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.
| Head size | 6464 |
|---|---|
| Head root | 0xa65a645969001d297f5aaa808a81fb023ffeb2880562ac45f0b75c1a4d50103f |
| Most recent leaf | 2026-09-13T15:21:55.110Z |
| Stream regenerated | 2026-09-13T16:24:59.193Z |
Per-event coverage
The fine-grained sources — one leaf per real event, not per commit or sealed head. A source is folding once the log holds a leaf of its own kind, and awaiting when its emitter is wired and correct but the property has not produced that event yet. Awaiting is the honest middle state, not a failure: a record only speaks when there is something true to seal.
| Source | Event | Status |
|---|---|---|
| academy | certificate/1 | ✓ folding |
| claimyourgold | receipt/1 | ✓ folding |
| flashynetwork | settlement/1 | ✓ folding |
| flashyid | verification/1 | ◇ awaiting first event |
| flashyos | countersignature/1 | ◇ awaiting first event |
| intentmesh | intent/1 | ◇ awaiting first event |
| magician | introduction/1 | ◇ awaiting first event |
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.
| This week | 1153 | -15% vs last week |
|---|---|---|
| This month | 5135 | +783.8% vs the month before |
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.
| Source | Leaves | Kinds |
|---|---|---|
| flashynetwork | 3739 | checkpoint/1, settlement/1 |
| claimyourgold | 911 | checkpoint/1, receipt/1, ship/1 |
| flashyos | 806 | checkpoint/1, ship/1 |
| gdagroup | 215 | checkpoint/1, ship/1 |
| flashygroup | 170 | checkpoint/1, ship/1 |
| academy | 156 | certificate/1, checkpoint/1, ship/1 |
| goldholdings | 142 | checkpoint/1, ship/1 |
| flashyid | 130 | checkpoint/1, ship/1 |
| flashygold | 94 | checkpoint/1, ship/1 |
| mlgblockchain | 79 | checkpoint/1, ship/1 |
| intentmesh | 16 | checkpoint/1, ship/1 |
| rites | 6 | checkpoint/1, ship/1 |
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.