Key transparency

The keys that sign every check.

Every compliance result is an Ed25519-signed attestation. A signature is only as trustworthy as the key behind it — so this page publishes that key openly: its fingerprint, how the fingerprint is derived, where to fetch it, and how rotation works. The current key is fetched live from the published endpoint below, so this page and the API can never silently disagree.

Current signing key

Active attestation key

Ed25519 · signing

Status

Fetching from live endpoint…

Key ID

—

Algorithm

—

SHA-256 fingerprint (of the SPKI DER public key)

—

Public key (PEM)

—

Fetch raw key JSON →

How the fingerprint is derived

The key ID isn't arbitrary — it's derived deterministically from the public key itself, so it can't be forged or reassigned to a different key. Anyone can reproduce it from the published PEM and confirm it matches:

Export the public key as SPKI DER

The raw binary form of the Ed25519 public key — the same bytes inside the PEM shown above.

SHA-256 the DER bytes

A standard hash over the key material. The full hex/base64url digest is the fingerprint field above.

Prefix and truncate for the key ID

The key ID is ed25519- followed by the first 16 characters of the base64url digest. Short enough to reference, unique per key.

Reproduce it yourself from the PEM with one command:

openssl pkey -pubin -in key.pem -outform DER | openssl dgst -sha256 -binary | basenc --base64url | cut -c1-16 # prepend "ed25519-" to get the key ID

Verifying an attestation against this key

Version 2 signatures use RFC 8785 canonical JSON over the data, timestamp, key ID, issuer, purpose, and schema version. Legacy attestations retain their original JSON.stringify verification path. The verifier resolves the exact key ID rather than assuming the current key.

import { OnchainDiligence } from '@onchaindiligence/sdk' const od = new OnchainDiligence({ account }) const r = await od.screen('vitalik.eth') const result = await verifyAttestationOffline(r, trustedRegistry) // result.state: VALID | INVALID | UNVERIFIABLE

Rotation policy

Keys can be rotated normally or marked compromised/revoked in an emergency. Retired public records remain available for historical verification only within their declared validity intervals. Compromised or revoked keys fail closed even when their signature bytes match.

Each key ID appears here with its activation date and, once retired, its retirement date.
Retired public keys stay published so historical attestations verify indefinitely.
On suspected exposure, rotation is immediate and the old key is explicitly marked compromised or revoked.
The key_id travels inside every attestation, so a verifier always knows which published key to check against.

Key history

Loading key history…

Maintaining this log. This history is loaded from the public key registry. Retired keys remain available for historical verification; revoked and compromised keys remain cryptographically checkable but are visibly distrusted. Registry changes require an explicit source-controlled deployment.

System status → API documentation →