The key, and how to check you got the right one.

Last updated 2026-08-03

The anchor

Machine-readable: /.well-known/synthera-kernel-keys.json — a map keyed by thumbprint, so rotation adds an entry and never changes the format. Look a key up by the thumbprint you are checking, not by “the current key”: a document minted last year needs the key that was current then.

The thumbprint inside a document is not an anchor

VAID v3 documents carry a kernel_key_thumbprint field. On its own it anchors nothing. It is self-asserted: an attacker mints their own document, signs it with their own key, and stamps their own key's thumbprint into it. Every internal check passes. The document is perfectly self-consistent and entirely unauthorized.

That field becomes an anchor only when compared against an independently published copy — one obtained through a channel the document's author does not control, such as this page. That comparison is the entire trust decision.

A verifier that checks a document's thumbprint against that same document's key has verified that a number equals itself.

This origin is untrusted by design

The JSON above is a static file on an ordinary web server. Do not trust it because it arrived over HTTPS from a domain you recognise. That is not a caveat about our hosting — it is the design.

Publishing a key would require an authenticated channel, because a substituted key is undetectable. Publishing a commitment to a key does not, because a substituted key fails the hash comparison. The hash is what makes the fetch safe. The transport is not.

So this file may be mirrored, cached, vendored into your build or emailed to you, and it is exactly as safe. Vendoring it is encouraged. What matters is that the thumbprint you compare against came from somewhere else.

Cross-check it

The same thumbprint is published in three independent channels, two of them on infrastructure we do not run:

• this page and /.well-known/synthera-kernel-keys.json — our origin
• docs/trust-anchor.md — GitHub
• release notes — GitHub

If they disagree, stop. That disagreement is the signal this design exists to produce.

What a verifier should do

1. Pin the thumbprint at build time from a channel you trust — not from the JSON.
2. Fetch, or read a vendored copy of, the key JSON.
3. Recompute the RFC 7638 thumbprint of the key and check it equals both the map key it was filed under and your pinned constant.
4. Fail closed on mismatch. Do not fall back to a cached key, do not proceed unverified, do not warn and continue. A key that fails this check is not a degraded key — it is somebody else's key.
5. Only then verify the signature.

Step 4 is the one that gets softened under delivery pressure. Full procedure: docs/trust-anchor.md.

Scope

This makes a substrate-signed document's signature verifiable by a third party. It does not make substrate documents verifiable by the open standard's verifiers: per ADR-0034 the substrate's document carries an additional external_identity field and versions its sig_version independently, so the two are deliberately not interchangeable. The identity fields converged; the documents did not.

Those are two different claims. This page establishes the first one only.