Final DeFi Whitepaper (2026 edition)

Replaces the original whitepaper. This edition describes the system as it runs on the test environment today and as it is being brought to mainnet, including the temporary Pre-Final Chain and the path beyond it. Proprietary internals are deliberately left out; what is described here is the approach, its guarantees, and its boundaries.

#1. The problem we solve

Everything of value on public blockchains is protected by elliptic-curve signatures. A sufficiently large quantum computer breaks those signatures, and the assets behind them, in a single step: recover the private key from the public key that every transaction reveals. The chains themselves will migrate eventually. Users cannot wait for that, and the migration itself is the risk window: keys that are safe today are harvested today and broken later.

Final DeFi is the transition layer. It secures assets on the chains people use now, with post-quantum cryptography end to end, without asking those chains to change. When the chains upgrade, nothing has to be undone.

#2. Principles

• Authority is proved per use, never stored on an execution chain. A Final Wallet's public state lives on Final Chain and is projected to every other chain by proof. Nothing on an execution chain can be overwritten into authority.
• The holder's credential is the only execution authority. Relayers, solvers and co-signers carry intents; they cannot produce the signature that authorizes one.
• No long-lived hot keys in the fleet. Bundles are carried by single-use accounts funded a block ahead from the protocol's own float. There is no operator key that can move user funds.
• Privacy by construction. Intents travel as sealed envelopes. The operator reads what it executes, once execution is authorized, and nothing before.
• Verifiable on chain. Post-quantum signature verification happens in precompiles on Final Chain, so a verdict is re-derivable from public state, not a claim by whichever process ran a library.
• Adopt, never replace. Live contracts are extended and re-pointed; what is on chain is not redeployed under users.

#3. The stack

#3.1 Final Wallet

A smart-contract wallet with a stable address on every supported chain. Each wallet is created from a certificate, a post-quantum identity carrying four keys in two stages: a transaction key (ML-DSA-87), an access key (SLH-DSA-SHAKE-256s), and two key-encapsulation keys (ML-KEM-1024 and HQC-5). The address is derived from the certificate's attestation, so an attacker cannot predict a wallet's address on a chain where it does not exist yet.

The wallet enforces intents through one gateway rail. Sub-accounts give isolated custody per purpose, each with its own budget and able to pay its own fees; a protocol may be bound to one as a controller under rules the holder accepts and can leave, and a program acting for the holder — a bot or an AI agent — may hold a bounded allowance that never reaches the holder's keys or authority (sub-accounts, controllers and agents). Recovery runs through a chain-global authority with guardian and attestor options. Post-quantum mode is a one-way, per-wallet decision with no chain-wide switch; PQ-native wallets are created directly.

#3.2 The state plane: the Pre-Final Chain now, Final Chain next

Now — the Pre-Final Chain. The state plane in service today holds the account ledger (tree 1 of seven state trees), the intent log, the bundle log that anchors post-quantum execution, the settlement log, the asset and chain registries, and the PHI supply ledger. Every quorum on it is post-quantum and certificate-based, and its precompiles verify ML-DSA-87 and SLH-DSA on chain. It is a temporary build, not open to external execution: nothing but the protocol writes to it, and PHI on it is a ledger without external submission. It mints one-second blocks with millisecond timestamps, final the moment they are produced. It is the correct state plane for launch and it is how the system has been proven end to end. When Final Chain is released, all data moves to it.

Next — Final Chain, the Quantum Tesselated Protocol. Final Chain is still in development and its architecture has diverged from today's build: it is asynchronous by design, with participation per module and per zone in a UTXO-like model alongside the EVM — fully EVM-compatible now and later, so projects move, adapt or interface with the tools they have; only strictly sequential parts behave differently under the asynchronous model, and a dedicated lane lets them persist their ordering — and a global attestation chain over the whole, under post-quantum Byzantine fault-tolerant consensus. Blocks are not on a fixed cadence: block intervals are ranges set by priority, down to one millisecond, with finality in 50 milliseconds, and no block is ever empty; all time is nanosecond-denominated, for the parallel, globally asynchronous admission of DAG vertices and for the quantum internet. The attestation chain carries only reconciliations and the zero-knowledge proofs of the active zones and groups within a global block ticker; its blocks are chained by the public keys of two post-quantum algorithms and the chained verifications, not by hash-joining. Key generation is decentralised across nodes for every key under our own secret-sharing construction. Beyond that the design is not disclosed here. What is fixed is the contract it must honour: the same ledgers and logs, the same proof semantics, the same precompile addresses, the same certificate roots. The move is from services around a chain to modules inside the node — nodes upgrade independently, and modules earn by the use they get — and the interfaces described in this paper do not change. PHI becomes the chain's execution asset there (§3.6). The end state is §7.

#3.3 The execution transport

Intents execute on the user's chosen chain through the Final Gateway, in bundles. A bundle is carried by a virgin EOA, a fresh account that exists only to sign one wrapper transaction, funded a block ahead from the gateway's float and swept back afterwards. Nothing in the fleet ever holds a key that can spend user assets, and an idle chain needs no operator to wake up.

For holders who have not yet enabled post-quantum mode, a temporary owner transport lane lets the classical owner key dispatch ordinary wallet calls directly; it can never touch ownership, recovery, post-quantum keys or module administration, it switches itself off the moment the wallet enables post-quantum mode, and it can be retired network-wide, permanently, once the pre-quantum cohort has migrated.

#3.4 Intents

An intent is a signed instruction to a wallet. On the post-quantum lane it is encrypted on the holder's device under both key-encapsulation families and stays encrypted until execution is authorized; only the holder and, once authorized, the executing service can open it. What is public is the target chain, the deadline, the schedule and a bond, nothing that names the wallet. Three execution gates exist:

• Immediate, authorized at posting.
• Gated, requiring the holder's second look: an approval on Final Chain with a per-intent key, which also delivers the executor's key to the content.
• Scheduled, executed not before a chosen time, enforced by the chain rule rather than by operator behaviour.

Execution is admitted by a K-of-N quorum of post-quantum co-signers and anchored in the bundle log; the gateway verifies the anchor before any row runs. A consumed bundle can never run twice.

#3.5 Settlement and vAssets

Real assets are locked on their origin chain by the settlement contract and represented elsewhere as vAssets — verifiable assets. A lock on the origin is observed at finality, admitted into the settlement log by the settlement quorum together with a post-quantum zero-knowledge proof of the lock (a LaBRADOR-based scheme), anchored on the target with the proof's hash published there, and settled; the return path undoes an operation that will never settle. A vAsset is the key to the locked asset, not a receipt for one, and the proof is public for anyone to check. The chain set and the asset set are chain-global registries published from Final Chain, so no two chains can disagree about either.

#3.6 PHI

PHI is the protocol's asset: a fixed amount of 100,000,000, kept as a ledger on the state plane, native on every supported chain, moved by lock and spawn. The amount never changes: nothing is minted beyond it and nothing is ever burned. PHI pays for the network's services with tiered discounts from the particle ladder, and on Final Chain it is the execution asset: PHI pays for execution there, and every fee goes to the holders and the node operators — staking on its nodes, including delegation that never moves PHI out of a wallet, is the form of that (PHI). The same fixed amount stands behind an ecosystem that grows as chains join as modules and assets arrive as vAssets, which is how each token comes to hold more value over time.

The amount is allocated once: 5 % to the Launch Sale at a fixed USD 1.00, 50 % to a six-month ICO whose price grows every hour, 10 % to the staking reserve, 5 % to network bootstrap and the incentives governance votes for, 15 % to the team and at least 15 % to the project reserve, into which anything unsold flows. On Final Chain the fees split three ways — holders, node operators and the treasury that funds the incentives — and the split moves toward the operators as the incentive pools are spent. The figures: PHI Tokenomics.

#4. Security model

• Suite. ML-KEM-1024 (FIPS 203) with HQC-5 as a hybrid for key encapsulation, ML-DSA-87 (FIPS 204) for transactions, SLH-DSA-SHAKE-256s (FIPS 205) for access decisions, SHA3-256 (FIPS 202) for hashing, LMS (SP 800-208) one-time signatures for the root authority on execution chains, AES-256-GCM inside XChaCha20-Poly1305 for content. Two independent assumptions on every surface; breaking one buys nothing. With the release the suite widens in the nodes: FN-DSA-1024 (FIPS 206) beside ML-DSA-87 for signatures, Classic McEliece-8192128 and FrodoKEM-1344 beside ML-KEM-1024 and HQC-5 — four key-encapsulation families in total — and a four-cipher content cascade of nested authenticated layers.
• Quorums. Every fleet decision that touches authority is K of N, verified on chain in precompiles, with members resolved through the identity registry from stored keys, never from arguments.
• Custody. Long-lived fleet secrets are short-lived by policy: rotated in epochs, split across nodes with our own secret-sharing scheme, released against chain state, and kept only in encrypted shards for audit. The end state is key-part generation across nodes for every algorithm, so no full secret ever exists in one place.
• Assumed adversary. Large-scale quantum capability. No reliance on nonces, probabilistic uniqueness or obfuscation.

#5. Economics in one page

Fees are floors in USD converted at oracle time-weighted prices, percentages where value is moved, and tier discounts from the particle ladder for PHI holders. Every Final Chain write carries a small fixed floor. Scheduled and private intents carry explicit, published surcharges. Paying in PHI debits locked PHI on Final Chain and the protocol sponsors the native gas on the execution chains, so a PHI payer never touches an execution-chain token for fees. The lock itself sits on whichever execution chain the payer holds PHI on; the coins do not move, Final Chain records the lock and debits against it. Details: Fees and PHI.

#6. Where we are

The post-quantum execution lane runs end to end on both test networks with no operator step: wallet creation, sub-accounts, Launch Sale purchases, cross-chain locks, gated and scheduled intents. Mainnet is armed on five chains; the Launch Sale opens in month 4, after the Malta license (around month 3). Final Wallet is live on the five supported EVM chains. The release also promotes what the test environment has proven since: receipts carrying the real transaction hash, state-plane reads by lookup, settlement-class calls that execute on idle chains, the settlement roots advanced on every mainnet. Scheduled execution that lands at the chosen time and the salted envelope header are in place on test; the locks at scheduling, the sealed private option and the PHI fee lane follow. The next platform step is the move from fleet services to node modules on Final Chain, with the interfaces above held constant.

#7. The end state: chains as modules

Final Chain's end state is not one chain among many. Other chains join it as modules: a chain that joins becomes part of the tesselated network, wrapped in post-quantum security together with its assets, and its assets become vAssets of the whole — verifiable, usable everywhere, backed on the chain they came from. Users keep the wallets and addresses they have; what changes is that one post-quantum identity, one state plane and one fixed amount of PHI stand behind all of it. The order in which chains join and the module boundary they join through are part of the undisclosed design; the interfaces in this paper are what every module honours.

#8. Related pages

Architecture overview · Post-quantum cryptography · Intents: immediate, gated, scheduled, private · Fees and PHI · User manual · Developer API · Glossary