MIR / Memory Infrastructure Registry

Trust & Transparency

Don't trust the registry. Verify it.

MIR records what entities have actually done, and seals every event into an hourly, hash-chained checkpoint. The current tip is below, live. Anyone can fetch it and verify the chain on their own machine -- nothing depends on MIR staying online.

The current checkpoint

Checkpoint
…
loading current tip
connecting Next checkpoint … seals in --:--
Tip
fetching…
Prev tip
Merkle root
Range
Witnesses
announced to sebbi.pro as each tip seals; independently fetched from the published head by public-contract.github.io
Verify it yourself
curl https://mir.events/v1/transparency/tipcurl https://mir.events/v1/transparency/checkpoints?beforeSeq=…

How the chain works

Hourly seal, back to genesis

Every hour, a few minutes past the hour, the events in that window are sealed into one checkpoint. The chain covers every event MIR has ever recorded. Nothing is added retroactively without changing the tip.

Bitcoin anchoring covers checkpoints sealed from 12 September 2026 onward, when it was switched on. Earlier checkpoints are hash-chained and verifiable against the chain, but carry no Bitcoin attestation; their proof endpoint returns 404 by design rather than pretending otherwise.

Each tip binds the last sha256

A tip is the hash of the sequence, the time range, the event count, the Merkle root, and the previous tip. Alter any sealed event and every later tip stops matching.

Per-event Merkle root

The root is computed over a leaf per event, so a single event's inclusion can be proven without exposing any of the others.

Observed by two witnesses, two ways

Each sealed tip is announced, as it seals, to sebbi.pro. Only the commitment travels: the chain name, the tip hash, a public URL for the tip, and the seal time. No event data ever leaves the node.

A second witness, public-contract.github.io, works the other way round. Nothing is announced to it. It fetches our published head itself, records what we served against its own chain position at that moment, and seals that observation into its own checkpoint chain. The distinction matters: an observation a witness took is worth more than one we handed over, because we cannot choose the moment or the value. Reciprocally, we fetch its head hourly and publish what we hold at /v1/transparency/held/tips.

Per-checkpoint witness outcomes have been recorded since 14 September 2026. Tips sealed before that were announced, but the result was not retained, so they read unrecorded rather than claiming something we cannot show. That is also why the count climbs by one an hour rather than starting full.

Check it yourself: the witness answers an unauthenticated read at sebbi.pro/x/witness/attest?peer=mir&tip=<tip>, returning whether that exact tip was observed, when it was first seen, and where it sits in their own chain. Being straight about what that is and is not: it shows a second party holds a contemporaneous copy, recorded independently of us. It does not prove our identity to them, and their own response says so. The Bitcoin anchor above needs no one's permission and remains the claim to lean on.

Signed exports verify offline against a pinned key

Take a signed export of your record and it checks out on your own machine with no MIR code in the loop: the signature, the hash chain, and a Merkle inclusion proof per event. v4 bundles also carry a dated completeness claim, so a holder can show nothing was withheld as of a sealed checkpoint, not only that nothing was altered.

Pin the public key out of band and compare its fingerprint before you rely on a bundle. The key's SHA-256 fingerprint is 542adea8414d945b6dd3ace733385efb59a3a6a0f8fb1904e5d9690fc9e4b747. It is also published in two live places that derive it from the key in use — /v1/transparency/export/key and /.well-known/ai-integrity.json — so this page is a third surface to cross-check against, not a single point to trust. If the three ever disagree, trust the two live endpoints.

What this page will never do