Security-First Architecture
The directives in the documentation: what each rule means on the Pre-Final Chain today and on Final Chain, with the suite, the standard and the products they shape.
Last updated 2026-09-08 · maintained in the Final Wiki
The suite they call for is on Post-quantum cryptography; the standard they produce is on Final Certificates; the products they shape are Final Identity, Final Wallet and the Final Network Protocol.
#The directives
- Post-quantum everywhere, under two hardness assumptions. No surface rests on RSA or elliptic curves — the problems Shor's algorithm solves on a large quantum computer. Every signature, key encapsulation and hash comes from the NIST-standardised suite, and every purpose is covered by two independent families: lattice and hash-based for signatures, lattice and code-based for key encapsulation, two cipher families for content. Breaking one family buys nothing.
- Keys are made where they are used, and never moved. A holder's keys are generated on the holder's device; certificate issuance receives commitments, never key material, so no endpoint anywhere accepts a private key. Recovery keys are pre-committed successors fixed by the certificate that created the identity, so rotation takes no key input. On Final Chain, key generation for every network key is decentralised across nodes under our own secret-sharing construction (a Shamir variant): no complete secret exists in one place.
- Perfect forward secrecy, always. Session keys are ephemeral and rotate while the session runs; the keys that open a time slot are destroyed after the slot closes; the Final Network Protocol rotates sessions with zero downtime. Compromising a long-term key later reveals neither past traffic nor past intents.
- The chain is the only root. There is no root store, no self-signed anchor and no cross-signing. A certificate exists because the chain admitted its record; a verifier resolves everything from chain state; post-quantum verification runs in the state plane's precompiles, so every verdict is re-derivable from public data.
- Nothing long-lived can spend. No operator holds a spend key. Execution on the chains you use is signed by single-use accounts; every long-lived secret is split K-of-N across nodes and released only while the state plane says an intent is executable. Every bundle is signed by a fresh single-use account that exists only for that one signature and ends at zero; no persistent submission key exists. What a program may spend for a holder is a bounded allowance — one route, one budget, one expiry — never a key (agents).
- Fail closed. An unknown chain, an unknown wallet, a stale root, a quorum short of its threshold or a check that cannot be re-derived is a refusal, never a default. The rules are the same on the client, in the fleet and on chain, so no lane can be talked into a different answer.
- Disclose the minimum. An intent is encrypted on the holder's device and stays encrypted until execution is authorised. Outsiders see the target chain, the deadline and the schedule — never the wallet, the recipient or the content. At execution, the transaction carries no address history back to the holder: the submitting account exists for that one signature and never again. What you can rely on: Privacy.
- What will execute is readable before it executes. Intents and oracle marks are records on the state plane; execution has to match the admitted record, and the price it settles at is an attestation anyone can read. A party between you and the chain cannot substitute either. See Oracles.
- Constant-time code, secured memory, layered entropy. The cryptographic core runs in constant time, holds secrets in protected buffers that are overwritten in several passes before release, and draws randomness from five layered sources — the operating system's generator, hardware generators, high-resolution timers, network jitter and internal state — so a failed or compromised source does not weaken a key.
- Live state is extended, never replaced under users. Contracts that hold live state are adopted and re-pointed, never redeployed; a hold on a step covers the whole step. What changes host — the move from the Pre-Final Chain to Final Chain — keeps every interface, root and proof.
#Now and on Final Chain
| Directive | On the Pre-Final Chain today | On Final Chain |
|---|---|---|
| Two hardness families | Every certificate and quorum | Unchanged; the nodes add FN-DSA-1024, Classic McEliece-8192128 and FrodoKEM-1344 |
| Keys made where used | On-device generation; commitments at issuance | Plus decentralised key generation across nodes for every network key |
| Forward secrecy | Slot keys destroyed after their slot; rotating sessions | The node-facing tunnel module carries the same rotation into every node |
| The chain as root | Certificates chain-attested (schema v5), precompile-verified | Same roots and precompile addresses; issuer registration and the licence and code-signing profiles |
| Nothing long-lived spends | Single-use accounts; no operator spend key | Node modules hold split keys; no operator lane remains |
| Readable before execution | Intent log and oracle marks on the state plane | Zone and group proofs on the global attestation chain, readable the same way |
| Cross-chain trust | vAsset anchors and settlement roots are published by the operator's K-of-N quorums and verified on every chain against that published anchor. A settlement's destination is committed at the source and re-derived on arrival, so a compromised operator cannot redirect one; the interim gap is a worthless-but-tradeable counterfeit, never custody | Final Chain's validator set anchors them and the operator leaves the trust path |
Plainly: every directive already holds on the Pre-Final Chain, in the protocol's own hands; Final Chain keeps each one and moves the trust that remains — key generation, tunnel termination, anchoring — from the operator into the nodes.
#See also
Post-quantum cryptography · Final Certificates · Final Identity · Final Wallet: security and capabilities · Final Network Protocol · Oracles · Architecture overview