What this does not yet prove

What a stranger can establish today

With no account, no key, no cooperation from us and no permission, anybody can do all of this:

1. Fetch the newest checkpoint statement from an unauthenticated endpoint.
2. Fetch the full set of keys that ever signed one, from an unauthenticated endpoint.
3. Verify the ES256 signature themselves, in a library of their choosing, with no code of ours involved.
4. Walk sequence, previousCombinedRoot, previousFingerprint and periodStart/periodEnd backwards to sequence 1 and confirm the published history has no gaps, no forks and no missing time.

That is genuinely more than most systems offer, and it is not nothing: a single altered event changes a leaf, which changes a stream root, which changes the combined root, which changes the fingerprint, which breaks the signature. The tamper-evidence within a published history is real.

What they cannot establish

The specific thing you cannot do today is establish that UnifyID did not, at some point, produce a different sequence of statements and publish those. Not because the cryptography is weak — because nobody outside UnifyID holds a copy to compare against, and a signature verifies equally well whichever history it was made over.

The integrity verifier's own documentation says it plainly: a checkpoint forged with a stolen or re-used key passes checks 1 to 8 and fails check 9. Check 9 is the chain, and until launch the chain is not there. What is left is checks 1 to 8, which is what this section documents and all it claims.

That is exactly the gap anchoring exists to close, and it is not running yet: it starts on Base mainnet at launch. See Anchoring, which is badged Not yet available for that reason.

The property that does exist, and how you get it

Independence does not have to come from a chain. It comes from somebody outside holding a copy. A chain is a convenient stranger who holds one for you and cannot be leaned on; you can be that stranger for yourself today, at the cost of a cron job.

1. 1

   Take the key set first

   GET /.well-known/unifyid-checkpoint-keys.json, stored the day you start. Every later comparison is against your copy, not against whatever the endpoint returns that day.

2. 2

   Poll for new statements

   GET /v1/public/transparency/checkpoints/latest on a schedule. Cheap, cacheable, and no credential.

3. 3

   Back-fill once

   Page backwards with before and nextBefore to sequence 1 and keep the lot. A sealed statement is immutable, so this is a one-time cost.

4. 4

   Verify on arrival, not on demand

   Run the signature check when you store it. A statement that fails on the way in is the signal; one that fails three months later tells you much less about when.

5. 5

   Compare, and keep the evidence

   Re-fetch a sequence you already hold from time to time and diff it against your copy. Keep both if they ever differ. The evidence is the pair, and neither half is any use alone.

The cost is a few kilobytes an hour. The property you buy is that UnifyID cannot rewrite a period you were watching without your copy and ours disagreeing in public.

How to describe this accurately

The right-hand column is not a list of future features to describe in the present tense. If you need one of those properties today, this is not the section that gives it to you, and saying otherwise in a document somebody relies on is the failure mode this page exists to prevent.