Post-Quantum Cryptography in Final DeFi
The algorithm suite, certificates, encrypted intents and key custody rules behind Final DeFi, under a large-scale quantum threat model.
Last updated 2026-09-08 · maintained in the Final Wiki
The threat model assumes large-scale quantum capability. Nothing here relies on nonces, probabilistic uniqueness or obfuscation.
#Algorithm suite
| Purpose | Algorithm | Standard | Where verified |
|---|---|---|---|
| Transaction authorization (wallet intents, fleet transactions on Final Chain) | ML-DSA-87 | FIPS 204 | the state plane's precompile 0x0204 (Pre-Final Chain today, kept on Final Chain); off-chain by co-signers |
| Access decisions (account ledger actions: freeze, rotate, transfer, enable PQ) | SLH-DSA-SHAKE-256s | FIPS 205 | the state plane's precompile 0x0205 |
| Key encapsulation (encrypted intents) | ML-KEM-1024 and HQC-5, hybrid | FIPS 203; HQC-5 — NIST selection 2025 | Client and executor libraries |
| Hashing | SHA3-256 / keccak-256 | FIPS 202 | Precompile 0x0202; EVM keccak |
| Content encryption | AES-256-GCM inside XChaCha20-Poly1305 | — | Client and executor libraries |
| Key derivation | HKDF-SHA256 | RFC 5869 | Everywhere a key is derived |
| One-time quorum signatures (root authority actions on execution chains) | LMS (hash-based) | SP 800-208 / RFC 8554 | Execution-chain root authority |
| vAsset proofs (that a lock exists on the origin chain: block, address, amount) | LaBRADOR-based zero-knowledge proof (lattice) | — | Off-chain by the settlement quorum; the target chain checks the published hash against the anchored record |
Plainly: one algorithm signs what you do (ML-DSA-87), another signs changes to your account (SLH-DSA-SHAKE-256s), two wrap the keys that encrypt your intents (ML-KEM-1024 and HQC-5), one hashes everything (SHA3-256), one signs the root authority's rare actions (LMS), and one proves a vAsset's lock exists (LaBRADOR). Each job is covered by two unrelated kinds of mathematics.
Two independent assumptions protect every surface: a lattice family and a code-based family for encapsulation, lattice and hash-based for signatures, two cipher families for content. Breaking one buys nothing. vAsset proofs are the one lattice-only surface; what a target chain relies on is the anchored record, which the quorum signs under both families.
The wider suite in the nodes (with the release, spoken by the Final Network Protocol):
| Purpose | Algorithm | Standard | Notes | |
|---|---|---|---|---|
| Node signatures, beside ML-DSA-87 | FN-DSA-1024 | FIPS 206 | registered algorithm id, reserved until the standard is final | |
| Cold custodian keys | Classic McEliece-8192128 | NIST round 4; ISO/IEC standardisation | code-based; large public keys are acceptable for keys that rarely move | |
| Executor keys | FrodoKEM-1344 | ISO/IEC standardisation | unstructured lattice; a third KEM assumption | |
| Content | four nested authenticated layers | — | AES-256-GCM innermost, then ARIA-256-GCM, then Camellia-256-GCM, XChaCha20-Poly1305 outermost, each layer sealing the last under its own 256-bit key (the intent envelope's AES-inside-XChaCha encapsulation taken to four layers), so a joint key search stays at 2^512 under Grover — see [[network-protocol | Final Network Protocol]] |
Plainly: with the release the nodes add a second lattice signature, two more ways to agree on keys (one code-based, one on an unstructured lattice) and two more ciphers — so a break in any single scheme still leaves the rest standing.
Four key-encapsulation families in total — ML-KEM-1024, HQC-5, Classic McEliece-8192128, FrodoKEM-1344 — two lattice signature schemes beside the hash-based SLH-DSA and LMS. Key generation is decentralised across nodes for every key on Final Chain, under our own secret-sharing construction; the nodes run post-quantum Byzantine fault-tolerant consensus.
#Certificates
A Final Identity is a certificate set (.fcert files): two stages (live and recovery), each a public and a private half, four post-quantum keys per stage, attested by the chain — the only root there is — and verified in the precompiles. Wallet addresses derive from the certificate's attestation. Fleet services are Final Wallets with their own certificates; there is no EOA signing key anywhere in the fleet. The standard has its own page: Final Certificates.
#Encrypted intents
An intent is encrypted on the holder's device before it leaves it and stays encrypted until execution is authorized. Two properties hold by construction:
- Only the holder and, once authorized, the executing service can read it. Both key-encapsulation families protect the same content key; breaking one buys nothing. The executing service's key is delivered only when execution is authorized (at posting for auto-approved intents, at the holder's approval for gated ones), so an unapproved intent is ciphertext nobody can act on.
- What is public is minimal. Timing, target chain and a bond for rate limiting; never the wallet, the target or the content. A pending revision makes postings from one wallet unlinkable to each other.
The wire construction itself is not a public interface: intents are submitted through Final Wallet clients, and third parties never build them.
#Key custody in the fleet
- No long-lived spend keys. Execution-chain transactions are signed by single-use accounts.
- Epochs. The transport's encapsulation key rotates on a fixed epoch; an epoch's secret is retired once every deadline that could reference it has passed.
- Sharing. Every long-lived secret is split K-of-N across nodes with our own secret-sharing construction; the shares are the durable record, wrapped to custodian keys and anchored for audit. The end state is key-part generation across nodes for every algorithm, so no full secret ever exists in one place.
- Release against chain state. A member releases its share of a decryption only while Final Chain says the intent is executable; after execution or cancellation the read is refused and the refusal is auditable.
- Time-locked privacy. For private intents, the key that lets the protocol read the intent is held under per-slot member keys and released only when the slot opens, so even the operator cannot read the intent early.
#What this does not claim
- Assets on an execution chain are protected by that chain's cryptography until the chain itself upgrades. Final DeFi removes the long-lived key from the user's path and bounds the exposure of every transport key; it cannot change Ethereum's signature scheme.