Final Certificates

Endpoint certificates: upcoming, month 1–2.

This page describes the standard at the level a holder or integrator needs; byte layouts are in the developer schema and are not needed to use it.

#Why a standard of our own

Public-key infrastructure as deployed today rests on a root store of self-signed certificates and on signature schemes a large quantum computer breaks. Final Certificates replace both premises: every key in a certificate is post-quantum, and the chain is the only root — there is no root store to install into, no self-signed anchor, no cross-signing. A certificate is issued the moment the chain admits its record, and a verifier resolves everything it needs from chain state.

#What a certificate holds

• A certificate set per wallet: a live pair and an armed recovery pair. A Final Identity has a live stage and a recovery stage; each is issued as a public .fcert and a private .fcert, with the rest of the set beside them. The public half is the distributable artifact — what a verifier needs, what the chain attests, what the certificate's identity is computed over. The private half never leaves the holder.
• Four keys per stage: a transaction key (ML-DSA-87), an access key (SLH-DSA-SHAKE-256s) and two key-encapsulation keys (ML-KEM-1024 and HQC-5). Two independent hardness assumptions cover every purpose; breaking one buys nothing.
• A stage, not a key, is the unit that is issued, rotated and revoked. A holder presents a whole stage or nothing. The recovery stage is the pre-committed successor the live stage rotates into: every key the identity can ever hold was fixed by the certificate that created it, so rotation takes no key input and cannot be handed a key nobody vouched for.
• The address is derived from the certificate's attestation. A Final Wallet's address on every chain follows from its certificate, which is why the same identity has the same address everywhere and why an attacker cannot predict a wallet's address on a chain where it does not exist yet.
• Type is structural. A wallet identity, a service identity, an issuer, a licence or a code-signing certificate differ by what they carry, not by a declared type. Purposes and extensions are registered; algorithms are identified by registry id, never by position — and the registry is open: which algorithms a certificate carries is configurable per certificate, and many more post-quantum algorithms become registrable soon. Custom extensions — caller- defined, registered ids — carry application data of your own.

#Who issues, and how

• Chain-native issuance. Final Identities — wallets, services, co-signers, guardians, registered issuers — are issued by admission: the registrar quorum approves, the registry stores the keys, the ledger leaf projects in the same transaction, and the anchored identity root is the chain's signature over everything it contains. Proof of possession is verified by the chain's precompiles inside the admission transaction. Nothing self-signs, ever.
• Issuer-signed certificates under the chain. A company or institution registers on chain as an issuer, with its depth, its delegation limit and its name constraints, and then signs certificates off-chain with its registered keys — licences, capabilities, person or device certificates, code signing. Those are issuer-signed, never self-signed, and a verifier resolves the issuer's keys and liveness from chain state. Offline and air-gapped issuance stays possible.
• Delegation by depth, not by flag. Every certificate carries its depth and the deepest level its key may issue to; it may sign a child only while its depth is below that limit. Two integers with no contradictory states replace the CA flag and path length of older standards.
• Registered issuers carry their jurisdiction; the chain's own root is jurisdiction-silent, because the issuer is the network.

#Verification

A verifier checks, from chain state: that the record is live and unrevoked, that the attestation is anchored under an accepted root, that the validity window holds, and — for issuer-signed certificates — every link upward: the issuer is registered, live and unrevoked, the depths agree, the subject sits inside the issuer's name constraints, and the required signatures verify over the certificate's bytes against the issuer's registered keys, never keys carried in the presented chain. The chain terminates the path by identity; there is no root file to trust.

#Lifecycle

• Expiry carries the volume. Licence, machine and service-class certificates carry a real expiry; renewal is re-issue under the same keys. Wallet identities do not expire: their lifecycle is the account's (freeze, rotation).
• One revocation lane, keyed on the certificate's identity, writable by the issuing identity and by the root plane independently. Revoking an issuer cascades to its whole subtree in one write. Revocation is one-way.
• Freshness is a proof, not a list. A fresh inclusion proof of the record is the statement that it is unrevoked; there is no revocation list to fetch and no responder to trust.

#Use cases: the profiles

Type is structural, so a profile is a settled combination of what a certificate carries. Five are settled today:

Plainly: five kinds of certificate share one format. The chain issues wallet identities and the protocol's service identities, which never expire — a wallet's stage is superseded by rotation, a service's can be revoked by the root plane — and registers institutions as issuers with a real expiry; a registered issuer then grants licences and capabilities and signs code, each with a required expiry, revocable by the issuer and the root plane.

Natural-person, government-authority and equipment profiles are reserved; their attribute sets are written when the first such profile lands. Because type is structural, a new class of certificate is a new registered extension and no format change.

Uses that follow from the profiles: a wallet that is the same identity on every chain; services that authenticate to each other over the Final Network Protocol with pinned identities; an institution that issues licences under the chain without touching it for each one; software whose signature a verifier checks against chain state rather than a vendor's root; and, on Final Chain, node operators whose keys are made by the network itself. On Final Chain a certificate is also the mandatory identity of a publication on compatible platform modules, carrying the platform's trust scores, and the credential a person presents — attribute by attribute, at their own choice — wherever KYC is asked for; see Final Identity.

#Final Identities: the wallet profile

A Final Identity is a Final Certificate set of the wallet profile — the special set of certificates that carry the four wallet key purposes. Everything above applies to it, with two properties of its own: it never expires, because the account's lifecycle governs it, and it is issued at account creation by the chain itself, from commitments the holder's device produced. Its private halves are the holder's seed phrase.

#Recovery certificates

The recovery stage is issued as its own pair of certificates, recovery.pub.fcert and recovery.key.fcert, carrying the same four key purposes in their recovery form. They are pre-committed successors: fixed by the certificate that created the identity, so rotating into them takes no key input and cannot be handed a key nobody vouched for. They authorise one thing — rotating the wallet's own credentials after a delay — and nothing else; acting as a guardian for another wallet, an ordinary action, uses the live access key. Until promoted they sign nothing and decrypt nothing, which is why they can and should be kept cold and apart from the live pair. Guardians can cancel a queued rotation; they never rotate. Details: Recovery and guardians.

#The schema

A certificate is TBSCertificate ‖ SignatureBlock: the signed bytes, then the signatures over exactly those bytes. Every field is length-prefixed and order-fixed, all integers big-endian, so a parser never looks ahead and two encoders of the same certificate produce the same bytes — which is what makes the certificate's identity (its hash) reproducible and minable before signing.

TBSCertificate

Plainly: the first block is everything a certificate says about itself — who issued it, whom it names, how long it is valid, which keys it carries and what they are for. Its hash is the certificate's identity, and because the layout is fixed, everyone computes the same hash.

SignatureBlock: one or more signatures, each (algorithm id, bytes) over the whole TBSCertificate, sorted by algorithm id. A verifier requiring N-of-M checks N distinct ids.

Registries — one id space for signatures and KEMs, the id being the NIST standard's number where one exists:

Plainly: a number names each algorithm, and the number is the NIST standard's own where there is one — so a key or a signature is never mistaken for a different kind.

The set of algorithms a certificate carries is a floor, not a cap: there is no upper limit on how many a certificate carries or on its size, the registry is extendable and the set is configurable per certificate; the rule is at least two signature algorithms, ideally from two different hardness families. Many more post-quantum algorithms become registrable soon. And the format is not reserved for us: anyone can generate certificates purely for their own use — a set only they issue and only they verify — under the same schema.

Plainly: every key says what it is for. A wallet's keys carry the wallet purposes; a node's key carries network authentication; an issuer's key carries certificate signing. A certificate with the wallet purposes is a wallet identity.

Plainly: extensions are what make a certificate a person, a device, a licence or a wallet — and, with the Program extension, what let a certificate carry its own rules. A verifier that does not understand a critical extension refuses the certificate instead of guessing.

Byte layouts, worked sizes and the issuance procedure are in the repository's developer schema; this is the shape a holder or integrator needs.

#What it means for a holder

• Your certificate is your identity: the private halves are the seed phrase of this world. Offline copies, never uploaded, never pasted. Nobody at Final will ask for them.
• One identity, one address, every chain. Creating your wallet on another chain is one action; the identity is already yours.
• Recovery and guardians act through the stages described above; see Recovery and guardians.

#Now and the end state

Today certificates are chain-attested (schema v5, ruled and implemented) on the Pre-Final Chain, and the wallet and service profiles are live. The end state on Final Chain keeps every root and proof and adds the rest of the standard: third-party issuer registration with delegation by depth, the licence and code-signing profiles, programmable certificates — the optional Program extension (0x0008) carries a program in a Turing-complete language, so the certificate itself states the policy a verifier evaluates: a licence that rate-limits or caps its own use is one example among many — and, for every key the network itself holds, key generation decentralised across nodes, so no complete secret exists in one place. The directives behind all of it hold on both chains.

#See also

Post-quantum cryptography · User guide · Recovery and guardians · Final Identity · Security-first architecture · Final Network Protocol · Glossary