Architecture Overview

This page describes surfaces and guarantees; internal designs that are not public are named but not described.

#The three planes

Plainly: Final Chain decides, the execution chains hold and move the assets, and the fleet only carries — nothing it does can authorize anything on its own.

The rule that ties them together: authority is proved on the execution plane per use, from state that lives on the state plane. A wallet's owner is not a storage slot on Ethereum; it is a leaf in tree 1 on the state plane, presented with its inclusion proof inside every bundle and verified against a root the chain already holds.

#Final Wallet on an execution chain

• Wallet proxy at a stable address, derived from the certificate that created it. Identity is the certificate's key commitments, never an EOA.
• Sub-accounts are wallet-owned custody routes, isolated per purpose, optionally bound to a controller contract for protocol-specific policy.
• Final Gateway is the single bundle entrypoint. One bundle carries many intents, of pre-PQ wallets (signature-authorized) and PQ wallets (anchor-authorized) alike; the anchor covers the PQ subset.
• Chain-global contracts: the wallet factory (deployment, implementation pointers, recognition), the recovery authority and module, the chance vault for dormant funds, the settlement contract, and the root authority that holds the four signer sets (cold, hot, settlement, account).
• Deterministic addresses everywhere, from one deployer singleton and pre-mined salts, so every chain-global contract has the same address on every chain.

#Now: the Pre-Final Chain

The state plane in service today is the Pre-Final Chain: a temporary, fully working build for the protocol's own data, 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, and a block is final the moment it is produced. When Final Chain is released, all data moves to it. It holds:

• Seven state trees, tree 1 being the account ledger: one leaf per wallet with owner, key commitments, PQ flag, freeze, deployed chains and version. The tree is read by proof, never rebuilt off chain.
• Identity registry with the root CA as its first record; certificates (schema v5) are chain-attested and verified against it.
• Intent log: the record of submitted intents, approvals, cancels and executions, with deadlines and schedules, mirrored as a status index in tree 7.
• Bundle log: the append-only MMR of admitted bundle roots that gateways verify against. Admission is a post-quantum K-of-N quorum.
• Settlement log and registries: the canonical cross-chain operation record; the chain set and asset set as published roots.
• PHI supply and Launch Sale ledger.

Post-quantum verification runs in precompiles (SHA3-256, ML-DSA-87, SLH-DSA-SHAKE-256s), so every verdict is re-derivable from public state.

Fully EVM-compatible, now and later. The Pre-Final Chain is an EVM chain with post-quantum precompiles, and Final Chain keeps full EVM compatibility alongside its UTXO-like model — so a project or protocol can move to it, adapt to it, or simply interface with it using the tools and contracts it already has. Only the strictly sequential parts of some protocols behave differently under the asynchronous model, and a dedicated lane lets them persist their ordering.

#Next: Final Chain, the Quantum Tesselated Protocol

Final Chain is still in development, and its architecture has diverged from today's build. The Quantum Tesselated Protocol is asynchronous by design: participation is per module and per zone, in a UTXO-like model that runs alongside the EVM — full EVM compatibility is kept, so contracts and tooling carry over — and a global attestation chain attests the whole. Its internals are not published; what is fixed is the contract it honours — the same ledgers and logs, the same proofs, the same precompile addresses, the same certificate roots — so the move from the Pre-Final Chain changes the host, not the interfaces described here.

• How it is built. 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 empty blocks anywhere, a block exists because something happened. All time is denominated in nanoseconds, for the parallel, globally asynchronous admission of DAG vertices and for the quantum internet. The global attestation chain carries only the reconciliations and the zero-knowledge proofs of the active zones and groups within a global block ticker; its blocks are not hash-joined but chained by the public keys of two post-quantum algorithms, with the verifications chained in turn.
• Keys made by the network. Key generation decentralised across nodes for every key, under our own secret-sharing construction (a Shamir variant), so no complete secret exists in one place. For Final Chain, not the Pre-Final Chain.
• Your own zone. Participation is per zone, and a zone can be yours: a company, a government or any institution can host a zone with access, privacy and permission rules tuned to its needs — its own rules for its own users — secure and private, and always integrated with Final Chain rather than apart from it. A module's scope is the whole chain, one zone or one group, and identities join and leave modules as they please.
• Services become node modules. The fleet's functions move into the node: indexing, co-signing and slot keys, the shard log, the fee ledger, settlement, the encrypted node tunnel, routing and protection, the HTML interface. Several node types carry different sets of modules.
• Nodes upgrade independently, and modules earn by use. Module incentives are user-based: demand for a module — or for a new one, or an upgrade — grows with the users who want it, and operators who adapt faster earn more. No network-wide upgrade gate.
• PHI is Final Chain's execution asset. It pays for execution there, and every fee goes to the holders and the node operators; nothing is burned and nothing is retained by the protocol. See PHI.
• Chains as modules — the end state. Other chains join as modules, wrapped in post-quantum security together with their assets; see the whitepaper.

Roadmap points: Next: Final Chain and After.

#Execution transport

1. A wallet client submits an encrypted intent to the protocol.
2. The solver opens what it is authorized to open, runs preflight against the execution chain, and asks the co-signer quorum to admit the bundle into the bundle log on Final Chain.
3. The gateway's anchor is advanced inside the bundle itself, so an idle chain needs no separate keeper transaction.
4. The relayer wraps the bundle into one transaction signed by a virgin EOA (single use, funded a block ahead from the gateway's float, swept back afterwards).
5. The gateway verifies the anchor, dispatches each row to its wallet, collects fees, and emits one event per row and one per bundle.
6. The settlement keeper reads the final receipt, settles fees, saves what the execution did not use to the payer's deposit at that gateway, and writes the user-facing receipt.

Which road a chain takes is a record on Final Chain, not a setting in a service: the chain registry tree carries, per chain, the transport mode, whether the EIP-7702 wrapper may run there, whether a leg with no private lane falls back to the staged envelope, the staging bounty, and the name of the builder set the chain uses. The services read those rows when they adopt the chain set; a chain whose row says no EIP-7702 gets no staged plan. The builders' own entries — endpoint and capabilities — are rows on the same tree, and a service refuses any endpoint the chain's rows do not attest.

No fleet component holds a key that can spend user assets.

#Settlement and vAssets

The settlement contract locks real assets on their origin chain and issues vAssets — verifiable representations of them — elsewhere. Lock on origin → observed at finality → admitted into the settlement log by the settlement quorum, with a post-quantum (LaBRADOR-based) zero-knowledge proof of the lock → anchored on the target, where the proof's hash is published → settled (minted, or released back on the origin). A vAsset is the key to the locked asset, not a receipt for it, and anyone can verify the proof. Operations that will never settle are returned on the chain they started from. Chain and asset registries are published from Final Chain and copied to every chain by proof.

#Fleet services

Solvers, relayers and the API, replicated for availability; three independent five-member co-signer quorums (bundle admission, the account plane, settlement); oracle and fee publishers; account registry and intake; settlement sync; treasury; conservation and recovery services. All PQ identities are Final Wallets issued by the same tooling; there is no EOA signing key in the fleet.

#See also

Whitepaper · Post-quantum cryptography · Intents · Developer API · Operations and environments · Glossary