Network Overview

A comprehensive overview of the Quantum Network.
Version 0.9 May 2026.

Our Solutions at a Glance

Most blockchains rely on classical signatures (ECDSA/EdDSA) for transaction authorization and validator voting. Those signatures are vulnerable to sufficiently capable quantum computers (via Shor's algorithm).

Quantum's target end state is post-quantum by default: no legacy ECDSA authorization, and a protocol engineered around the scaling realities of PQ signatures—larger bytes-on-the-wire, larger bytes-on-disk, and larger consensus proof objects.

I.

On-chain verification — PQ on-chain verifier

How PQ signatures are enforced and verified on existing chains

  • Smart-contract-level PQ signature verification: ML-DSA-65 is the default verifier exposed at the smart-contract layer — used by the PQ smart wallets we deploy on pre-existing EVM chains and available to application contracts for governance, attestations, and cross-chain proofs. Falcon and a higher-entropy ML-DSA variant are pre-baked as contingencies, so the verifier behind the PQ smart wallet can be swapped if ML-DSA-65 needs to be replaced or strengthened.
  • Verifier-side crypto agility (cross-chain on-chain verifier): The PQ verifier contracts we deploy on pre-existing EVM chains support flexible signature schemes. If a given PQ scheme is found to be compromised or weakened, we can swap the verifier behind the PQ smart wallet to a fallback scheme without migrating user assets or addresses — the on-chain verifier remains PQ-safe by construction.
II.

PQ-sig creation — PQ Signer

How institutions and end users produce PQ-authorised transactions

  • Mithril (institutional custody): Native constant-time Rust implementation of threshold ML-DSA (ePrint 2026/013). T-of-N threshold signing (up to 6 parties) producing standard FIPS 204 signatures. Used for MPC and institutional custody workflows, not consensus (party limit incompatible with validator-scale threshold signing).
  • PQ Wallet Layer (cross-chain signer infrastructure):
    • Dual-mode wallet infrastructure.
    • PQ smart wallets on other EVM chains: assets held in a wallet that only accepts PQ signatures, with PQ verifier contracts deployed per supported chain.
    • Native Quantum wallet with MPC, TEE, and Mithril threshold ML-DSA for institutional custody.
    • Local PQ signing tool to sign transactions and broadcast via standard pipelines (Foundry/Hardhat), with planned upstream PRs where feasible.
    • Additional wallet integrations as the ecosystem matures.
III.

L1 Network technical details

Native AA, execution, consensus, bridge, and transport

  • Native Account Abstraction: Custom EIP-2718 composite transactions verified natively in the Reth client before EVM execution. Every transaction references a key from the sender's on-chain KeyVault. Each key has a mandatory primary signer (from the switchboard's approved-primary list — today ML-DSA-44) and an optional cosigner (P256 for passkeys, ECDSA for hardware wallets/custodians). KeyVault supports multiple keys per account with scoped permissions (FullAccess vs contract/method/allowance/expiry-restricted). Key management via native KeyVault precompile. 2D nonces (RIP-7712-style) for parallel mempool scaling. Native gas sponsorship via envelope-level fee payer. PQ security is enforced structurally at the key level, not delegated to application contracts or policy flags.
  • L1 crypto agility (on-chain switchboard): Multiple signature algorithms ship pre-baked in every Quantum node binary. An on-chain CryptoSwitchboard precompile controls which schemes are active for L1 consensus and userland authorization — runtime rotation among pre-baked algorithms requires no hard forks or restarts. Adding a net-new algorithm family requires a coordinated client update. This is the L1-protocol counterpart to the verifier-side agility described in Section I.
  • Node-level PQ signature verification (validator path): Falcon (compact, consensus critical path) + ML-DSA-44 (userland authorization). SLH-DSA (hash-based) is pre-baked as a fallback algorithm for lattice-break scenarios — usable as a cosigner on cold vault KeyEntries, verified in the node's native tx-auth path.
  • Execution: Reth-based EVM. Deploy any Solidity contract as-is — Foundry, Hardhat, and the full EVM toolchain work without modification. Only transaction signing routes through the Quantum PQ signing tool until upstream toolchains adopt the Quantum transaction type natively.
  • Consensus: Commonware Simplex for fast notarization/finality (2 hops to notarization, 3 hops to finalization). Falcon signatures chosen specifically for the smallest PQ signature size on the consensus critical path.
  • Threshold exploration (consensus): Active research into post-quantum threshold signatures with distributed key generation (DKG) to reduce consensus overhead and scale validator sets without compromising finality. Ringtail remains a candidate for compact PQ threshold certificates.1
  • Entanglement (Quantum ↔ EVM bridge): Canonical bridge architecture using LayerZero v2 transport + DVN security, with a PQ boundary invariant: inbound value only materializes on Quantum via pending credit → PQ claim() (and a required PQ-secured DVN as defense-in-depth).
  • P2P transport PQ-KEM (post-mainnet): We will evaluate ML-KEM (Kyber) for P2P key establishment after mainnet, once baseline performance and operational behavior are proven. No hybrid approach is planned at this stage; the goal is a clean, single-lane PQ KEM decision based on measured need and risk.
[ WHY NOW ]

Why post-quantum now

NIST's first finalized PQC standards (FIPS 203/204/205) were approved and published in August 2024.

Signature standards include ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). Falcon is selected by NIST and planned for standardization in a future document (FN-DSA / FIPS 206, in development).2 This means the "which algorithms?" question is converging, and it's worth doing systems engineering now instead of waiting.

[ ARCHITECTURE ]

What we are building

Quantum is an EVM-compatible blockchain designed for a world where post-quantum authorization is non-optional.

What makes it different from "PQ add-ons":
01

PQ-by-default authorization (target end state)

PQ signatures aren't a plugin; they become the default account authorization mechanism. Addresses derive from PQ keys. No ECDSA fallback. Quantum-resistant from block zero.
02

Consensus and networking engineered for PQ payload sizes

PQ signature and certificate bytes are treated as first-class protocol constraints. Falcon chosen at the consensus layer for minimum byte overhead.
03

Cryptographic agility and operational hedging

Multiple algorithms ship pre-baked in every node binary. An on-chain switchboard controls which are active. Runtime rotation among pre-baked algorithms requires no hard forks; adding new algorithm families requires a coordinated client update.
04

Native Account Abstraction with composite PQ transactions

Every account is a smart account. Composite transactions enforce a mandatory primary signer (from the switchboard's approved-primary list) with optional cosigner, verified natively in the Reth client before EVM execution. Scoped access keys enable granular delegation. Existing wallets and custody infrastructure plug in on day one. PQ security is structural — enforced by the shape of the key data, not by policy flags.
05

Minimalist architecture

We avoid adding complexity (e.g., DAG ordering) unless benchmarks prove it's required.
06

Bring PQ safety to the broader EVM ecosystem

Even before chains migrate at L1, we materially improve asset custody by enabling PQ-secured smart wallets on existing EVM chains, developer tooling that fits existing workflows, and institutional custody via Mithril threshold ML-DSA.
[ PRINCIPLES ]

Design goals
01

PQ authorization at L1 (target end state)

A primary signer from the switchboard's approved-primary list is required on every transaction. No classical-only authorization.

02

Fast finality, designed for PQ payloads

We target sub-second UX and treat bytes as the key constraint. Simplex + Falcon delivers this today on devnet.

03

Hedge against cryptographic surprises

Lattice dominates practical PQ, but we preserve a conservative hedge path with pre-baked fallback algorithms and an on-chain switchboard for runtime rotation.

04

Keep the protocol simple

Prefer straightforward consensus + execution unless measurements demand more.

05

Make PQ adoption practical

Ship wallet and developer tooling so PQ signing works in real workflows, not only prototypes. Support institutional on-ramps via composite transactions that let custodians augment existing ECDSA infrastructure with a PQ primary signer rather than replacing it.
[ APPLICATIONS ]

Use cases

Quantum is designed for assets and applications where "wait to migrate later" is not acceptable:

Long-lived assets

RWAs, treasuries, long-duration bonds, institutional custody.

High-value vaults

Cold vault KeyEntries with SLH-DSA cosigner for lattice-family diversification.

Exchange / bridge assurance

Externally referenced checkpoint anchors for conservative finality.

Governance with long horizons

Voting that remains valid under future quantum threat models.

Infrastructure primitives

PQ-native accounts for applications that must be future-proof by design.

Wallet-layer hardening on today's chains

Protect assets with a PQ-controlled smart wallet even on EVM chains that still use ECDSA at the base layer.

Institutional custody

Mithril threshold ML-DSA enables MPC and TEE-based custody workflows with standard FIPS 204 signature output.
[ SYSTEM DESIGN ]

System overview

Execution + consensus are intentionally conventional. The novelty is PQ authorization + PQ scaling, and how that boundary is enforced across bridges, wallets, and marketplaces.

Architecture at a glance

Layer / Domain What runs there What it does
Execution Reth-based EVM Full Ethereum execution ergonomics. Contracts deploy as-is.
Consensus Simplex (Commonware) + Falcon Sub-second finality. Falcon chosen for smallest PQ sig size. Threshold DKG under research.
Authorization KeyVault + composite tx + native precompiles + 2D nonces Per-account key registry with scoped permissions. Primary signer mandatory (from approved-primary list). Optional cosigner (P256/ECDSA). Pre-EVM verification in Reth.
Entanglement bridge LayerZero v2 + DVN stack + PQ boundary gate Cross-chain transfers with pending credit → PQ claim()
PQ Wallet Layer PQ smart wallets + native wallet + Mithril Dual-mode. PQ smart wallets on EVM chains. Native wallet with MPC, TEE, threshold ML-DSA for institutions.

Core chain transaction path

1 User signs a composite transaction. The key_id field references a KeyEntry in the sender's on-chain KeyVault.
2 Reth client intercepts the transaction before EVM execution.
3 Node looks up the sender's KeyVault in state. If no KeyVault exists (first outbound tx from a new account), the transaction must be an explicit bootstrapKey() call to the KeyVault precompile with init_primary_pubkey in the envelope and key_id == 0. Pre-EVM validation authenticates the bootstrap signature and writes transient context; bootstrapKey() then creates key_id: 0 as a FullAccess primary-only entry during EVM execution. Bootstrap is always primary-only — co-signer activation is a subsequent explicit updateKeyAuth lifecycle step. Subsequent transactions reference key_id: 0 without including the public key.
4 Node retrieves the KeyEntry by (sender, key_id). Authentication is account-lane + key-lane based: signature and key material must match the stored entry, without requiring signer-address derivation to equal sender. Reject if not found.
5 Node checks permissions: if the KeyEntry has Scoped permission, validates that the calls target only allowed contracts/methods and the native value is within allowance.
6 Node verifies the primary_signature against KeyEntry.primary. The primary scheme must be on the switchboard's approved-primary list.
7 If KeyEntry.cosigner is Some, node verifies cosigner_signature against it.
8 Node validates the 2D nonce: if nonce_key == 0, checks the standard account nonce; if nonce_key > 0, checks via the NonceManager precompile.
9 If fee_payer is present: node looks up the fee payer's KeyVault, verifies fee_payer_signature against the same tx_intent_hash (with QuantumFeePayer domain separator), and deducts gas from the fee payer's balance instead of the sender's.
10 If the transaction is a key-management lifecycle operation (addKey/removeKey/updateKeyAuth), pre-EVM validation writes transient lifecycle-intent context. The KeyVault precompile consumes this intent during execution and rejects mutations without matching intent (preventing contract-mediated lifecycle bypasses).
11 Node writes the validated auth context (key_id, permission) into transient storage on the KeyVault precompile. This is how the precompile learns whether the outer transaction was signed by a FullAccess or Scoped key during EVM execution.
12 Executes calls atomically in the EVM (checkpoint/revert — if any call fails, all state changes revert).
13 Increments nonce. Persists state updates.
14 Simplex provides notarization → finalization.
I.

On-chain verification

PQ on-chain verifier: how PQ signatures are enforced and verified on existing EVM chains via the PQ smart wallet stack.
[ PQ SMART WALLETS ]

PQ Smart Wallets on existing EVM chains

A drop-in post-quantum custody stack for the EVM ecosystem — ML-DSA on Arbitrum Stylus, plugged into Safe7579, fully ERC-4337 compatible.

Architecture

The PQ smart wallet is built as an ERC-7579 validator module attached to a Safe7579 account. Validation flows through a stable VerifierGateway that delegates to a chain-specific Stylus ML-DSA verifier, so the validator can stay at a deterministic CREATE2 address while each chain points to its own verifier.

CLI (pq-keygen / pq-sign) ──signed UserOp──▶ Bundler / handleOps
                                                 │
                                                 ▼
                                       EntryPoint v0.7
                                                 │
                                                 ▼
                                       Safe7579 account
                                                 │ validateUserOp
                                                 ▼
                                       MLDSAValidatorModule (ERC-7579)
                                                 │ IVerifierGateway.verify
                                                 ▼
                                       VerifierGateway
                                                 │ staticcall verify
                                                 ▼
                                       MLDSAVerifier (Stylus / Rust+WASM)

The gateway hides the chain-specific verifier address from the validator. If a PQ scheme needs to be rotated, only the gateway target changes — accounts, addresses, and assets stay put.

Wallet Profiles

Profile Install data Signature envelope Cosigner rotation
PQ-only abi.encode(uint8(0), pqPubKey) 0x00 || mldsaSig Deploy a new wallet
PQ + ECDSA abi.encode(uint8(1), pqPubKey, cosigner) 0x01 || mldsaSig || ecdsaSig rotateCosigner(newCosigner)
PQ + P256 abi.encode(uint8(2), pqPubKey, x, y) 0x02 || mldsaSig || p256Sig rotateCosigner(newX, newY)

The first envelope byte must match the account profile — this prevents a PQ-only signature being replayed against a hedged account. PQ+P256 uses the RIP-7212 precompile at 0x100 for cheap on-chain P256 verification.

Technology choices

Choice Rationale
ML-DSA-44 (FIPS 204) NIST-standardized PQ signature scheme. Level 2 (128-bit) security. Smallest FIPS 204 parameter set, minimizing calldata and L1 data-posting cost.
Arbitrum Stylus Native Rust/WASM execution — ML-DSA verification runs in hundreds of thousands of gas vs. millions in pure EVM. The only viable platform for on-chain lattice crypto today.
Safe7579 + ERC-7579 Plug-and-play with the Safe ecosystem. No custom account is required; the validator is a standard ERC-7579 module.
VerifierGateway Stable indirection between validator and chain-specific Stylus verifier. Enables crypto agility without account migration.
Stateless Stylus verifier Public keys are stored in Solidity and passed as calldata. Avoids cross-runtime storage bugs (Nitro #4114) and keeps the Stylus contract a pure function.
ERC-4337 + Alto bundler Standard account-abstraction pipeline. Works with hosted bundlers and Pimlico/Alchemy/Stackup-compatible infrastructure.

Gas benchmarks (Arbitrum Sepolia)

Scenario Profile Gas
First transferPQ-only508,428
First transferPQ+ECDSA517,998
Repeat transferPQ+ECDSA500,888
rotateCosignerPQ+ECDSA503,731
Account creationPQ-only1,365,023
Account creationPQ+ECDSA1,408,159

Data sizes

Property ECDSA ML-DSA-44 Ratio
Signature65 B2,420 B37×
Public key64 B1,312 B21×
WASM (gz)—7.8 KB24 KB cap

L1 data posting dominates cost on Arbitrum (~$2–8 per PQ transaction at current prices). This is an inherent trade-off of post-quantum signatures, not a tooling artifact.

Live deployment (Arbitrum Sepolia)

Contract Address
EntryPoint v0.70x0000000071727De22E5E9d8BAf0edAc6f37da032
VerifierGateway0xE5030c3a345A40086e68975669DE1c30A3F4cc25
MLDSAValidatorModule0x36758C8DBCcC03886f644657043818b7D6f6D0F4
Stylus ML-DSA verifier0x09b381b2b8fff7caddaa06d096df7d8d70ad9bf8
Safe75790x7579f2AD53b01c3D8779Fe17928e0D48885B0003
Safe7579Launchpad0x75798463024Bda64D83c94A64Bc7D7eaB41300eF

Status & production caveats

  • Proof of Concept, unaudited. Not for production use today. The ml-dsa crate is a release candidate; the Stylus SDK is pre-1.0 with known issues flagged by OpenZeppelin and Trail of Bits audits.
  • Operational: Stylus contracts auto-deactivate after 365 days or after ArbOS upgrades and must be reactivated. Gateway ownership is currently a single key; production should be a multisig with timelock.
  • Missing today: PQ key rotation (only the classical cosigner can rotate), sender allowlist, signature aggregation, paymaster support, and a client SDK. Hosted bundler compatibility is partially validated.
II.

PQ-sig creation

PQ Signer: how institutions and end users produce PQ-authorised transactions.
[ INSTITUTIONAL CUSTODY ]

Mithril: threshold ML-DSA

Native Rust implementation of the threshold ML-DSA protocol for institutional custody workflows.

Key properties

  • T-of-N threshold signing (2 ≤ T ≤ N ≤ 6)
  • Standard FIPS 204 output — signatures verifiable by any conforming ML-DSA implementation
  • 3-round signing protocol (commit → exchange → respond) + combine
  • Constant-time polynomial arithmetic; zeroize on all secret material

Performance (Apple M4, ML-DSA-44)

(T, N) KeyGen Sign+Combine Verify
(2, 2)~0.2ms~0.5ms~0.03ms
(3, 3)~0.4ms~0.7ms~0.03ms
(4, 6)~0.5ms~12ms~0.03ms

Institutional architecture

Hardware-enforced policy

Mithril shares are isolated inside hardware trusted execution environments (e.g., AWS Nitro/TDX). Enclaves refuse to participate unless the inbound transaction carries a valid cryptographic authorization token.

Stateful coordinator with transparent retries

An untrusted routing layer handles the global mathematical aborts inherent to lattice rejection sampling. Typical end-to-end signing completes within ~1.5 seconds including retries.

Scoped key delegation

The KeyVault's scoped permissions integrate directly with institutional custody. The vault's FullAccess key (3-of-5 quorum in TEEs) only comes online for high-value operations. Trading desks receive scoped keys with daily caps.
[ CROSS-CHAIN SECURITY ]

PQ Wallet Layer (Cross-chain)

Making other chains quantum-safer

Quantum's L1 target end state is PQ-by-default. But we can deliver meaningful benefits to users before the rest of the ecosystem migrates by improving wallet-layer custody on existing EVM chains.

Key idea

Even on chains where consensus and base accounts still use ECDSA, assets can be protected inside a smart wallet that only accepts PQ signatures.

This is not "full PQ security" of the chain, but it materially improves user safety: even if a user's ECDSA key is compromised, the attacker cannot move assets held in a PQ-only smart wallet.

What we are implementing first
1.

PQ smart wallets on other EVM chains

Assets held in a wallet that only accepts PQ signatures, with PQ verifier contracts deployed per supported chain.

2.

PQ verifier contract deployments

We deploy either a Falcon verifier or an ML-DSA verifier to every chain we support. The PQ smart wallet delegates verification to this verifier contract.

3.

Local PQ signing tool

A CLI tool to sign transactions with PQ keys and broadcast via standard pipelines (Foundry/Hardhat), with planned upstream PRs where feasible.

4.

Native Quantum wallet with institutional custody

Native wallet on Quantum with MPC, TEE, and Mithril threshold ML-DSA for institutional custody workflows. Standard FIPS 204 signature output.

5.

Additional wallet integrations

Expanded wallet integrations as the ecosystem matures.

PQ verification on other chains (verifier contracts)

Most EVM chains do not have native PQ verifier precompiles. To make PQ-secured smart wallets practical across the ecosystem, we deploy a canonical verifier per supported chain.

  • We deploy either a Falcon verifier or a Dilithium/ML-DSA verifier (depending on direction) to every chain we support.
  • The PQ smart wallet delegates verification to this verifier, rather than embedding full PQ verification logic in every wallet instance.
  • This improves auditability (one shared verifier surface per chain) and standardizes verification semantics across networks.

User journey (high level)

1 User goes to our frontend.
2 User sets up a PQ wallet (native Quantum wallet or supported PQ signer).
3 We deploy or configure a PQ smart wallet for the user on the target chain.
4 User transfers assets into that wallet.
5 From that point on, the wallet only accepts PQ signatures for sensitive actions.

How it works (high level)

1 User signs with a PQ key (via native wallet or supported signer).
2 User submits a transaction to the PQ smart wallet containing (callData, pqPubKey, pqSignature, …).
3 Smart wallet calls the chain's deployed verifier contract (Falcon or ML-DSA) to validate the signature.
4 Only if verification succeeds, the smart wallet executes the requested action.

Components (ecosystem PQ custody on existing EVM chains)

Component Where it runs What it does
Local PQ signing tool (CLI) User/dev machine Signs with PQ keys; broadcast via Foundry/Hardhat/RPC
PQ Smart Wallet (contract) Target EVM chain Holds assets; only authorizes actions with valid PQ signatures
PQ Verifier Contract Target EVM chain (one per supported chain) Canonical PQ signature verification (Falcon or ML-DSA)
Native Quantum wallet Quantum chain MPC, TEE, and Mithril threshold ML-DSA for institutional custody
Frontend / onboarding Web app Guides setup; wallet deploy; asset migration

Important limitations (explicit)

  • This improves custody safety, but does not convert the underlying chain into a PQ-by-default chain.
  • Guarantees depend on verifier correctness/audits, wallet upgrade policies, and secure key management.
III.

L1 Network technical details

Native AA, execution, consensus, bridge, and transport.
[ ACCOUNT ABSTRACTION ]

Native Account Abstraction

Account abstraction logic lives in the node client\'s transaction parsing layer, not in EVM opcodes or application-layer bundler infrastructure.

Why not existing approaches?

ERC-4337

Requires UserOperations, off-chain bundlers, and gas-heavy proxy smart contracts. Dead end for a new L1.

EIP-8141

Theoretical ideal but introduces unsolved mempool DoS vectors (arbitrary code execution in validation frame). Too risky for production.

EIP-7702

Still requires ECDSA (secp256k1) at the outermost authorization layer. Fundamentally incompatible with PQ-by-default.

Quantum\'s approach: pre-EVM composite transactions

We define a custom EIP-2718 transaction type (0x7A). The Reth node client intercepts and validates composite signatures before the transaction enters the EVM interpreter — all signature verification happens in native Rust, not in EVM gas.

Every transaction references a key_id from the sender\'s on-chain KeyVault. The primary signature is the lock. The cosigner is a convenience and compatibility layer — not a security dependency.

Account profiles

PROFILE A

Retail / Mobile

ML-DSA-44 primary + P256 cosigner via RIP-7212. Users authenticate with FaceID. No seed phrases, no browser extensions. The PQ layer is invisible.
PROFILE B

Institutions & Hardware Wallets

ML-DSA-44 primary + ECDSA cosigner. Custodians plug their existing ECDSA pipeline in as the cosigner and add an ML-DSA signer alongside it.
PROFILE C

PQ-only

ML-DSA-44 primary alone, no cosigner. Pure post-quantum authorization with no additional overhead.

Protocol-level primitives

Batched transactions

Multiple EVM calls in a single transaction, executed atomically via checkpoint/revert semantics. Enables patterns like "approve + swap + revoke" in one atomic transaction.

Native gas sponsorship

Gas sponsorship is a first-class envelope feature, not an EVM contract. The fee_payer field identifies a sponsor account; both sender and sponsor sign the same canonical tx_intent_hash with different domain separators.

Pre-EVM verification

Transaction-level composite signature verification (primary + cosigner) happens in native Rust before EVM execution — no EVM gas is charged for transaction authorization. This is distinct from verifier precompiles (ML-DSA-44, P256, Falcon-512), which are callable by smart contracts and charge standard precompile gas.

Zero proxy deployment fees

Account abstraction is pushed into the transaction envelope and key management is handled by native precompiles. Users do not need to deploy proxy smart contracts.

Parallel mempool scaling (2D nonces)

RIP-7712-style 2D nonces with (nonce_key, nonce) pairs. Allows institutional custodians and native paymasters to process thousands of transactions in parallel without mempool congestion.

Per-account key management (KeyVault)

Every account\'s on-chain KeyVault holds a mutable set of authorized keys, managed via a native precompile. Each key entry is structurally PQ-safe — the primary field is mandatory and must be a scheme on the protocol\'s approved-primary list.

KeyVault uses keccak-hashed slot addressing and stores each public key once in chunked EVM storage alongside a keccak256 integrity hash. Transactions reference key_id, and validators load the stored pubkey during detached verification instead of expecting it on every transaction.

FullAccess keys

Can sign any transaction, add or remove other keys, and modify the KeyVault itself.

Scoped keys

Restricted to specific contracts, methods, spending allowances, and expiry times. Perfect for trading desks and delegated operations.

Key rotation and crypto migration

Addresses derive from the initial ML-DSA pubkey hash at account creation, but the KeyVault decouples the address from current signing keys. The protocol validates transactions by looking up the account's KeyVault in state rather than re-deriving the address from the signer's pubkey, and detached verification loads the stored public key by key_id.

Key rotation via the precompile remains straightforward: AddKey(new_key) → verify → RemoveKey(old_key). The address, assets, token approvals, and all on-chain references stay the same. If a new signature scheme replaces ML-DSA-44 on the switchboard, users simply add a key with the new scheme and remove the old one. No address change, no asset migration, no broken contract ACLs.

This same detached-key model also cuts transaction wire size materially: the ~1.3 KB ML-DSA-44 public key is registered once on-chain instead of being transmitted with every signature, reducing userland wire overhead by roughly 35%.

Cold vault profile (lattice hedge)

COMPOSITE KEYENTRY

For high-value accounts wanting defense against a lattice-family break, the existing composite key model supports a cold vault profile: a KeyEntry with primary = ML-DSA-44 and cosigner = SLH-DSA (both required). No new policy machinery — this is a standard composite KeyEntry where the cosigner happens to be hash-based.

ML-DSA-44 primary + SLH-DSA cosigner (independent PQ assumption via hash functions)
Designed for rare, high-value operations — SLH-DSA sigs are 7,856 B, impractical for everyday tx

Native precompiles

All precompiles are implemented in native Rust inside the Reth EVM handler — no EVM bytecode interpretation, but standard precompile gas costs apply when called by smart contracts. Callable via standard ABI-encoded CALLs, composable with batched transactions, and compatible with existing EVM tooling.

Signature verifiers

Precompile Address Purpose
ecrecover 0x01 Standard Ethereum ECDSA (secp256k1) recovery. Retained for smart contract compatibility.
P256 Verifier (EIP-7951) 0x0100 secp256r1 signature verification for passkey cosigning. EIP-7951 compliant (canonical L1 address).
ML-DSA-44 Verifier 0x1003 FIPS 204 ML-DSA-44 signature verification. Enables on-chain PQ sig verification for smart contracts, governance, and cross-chain proofs.
Falcon-512 Verifier 0x1004 Falcon signature verification. Enables smart contracts to verify consensus certificates and validator attestations.

Protocol precompiles

Precompile Address Purpose
KeyVault 0x1000 Key management: bootstrapKey, addKey, removeKey, updateKeyAuth, getKeys. Enforces approved-primary invariant, lockout protection, and lifecycle intent binding.
NonceManager 0x1001 2D nonce tracking: ValidateAndIncrement(nonce_key, nonce). Per-account, per-queue sequential counters.
CryptoSwitchboard 0x1002 Read-only runtime algorithm governance: getApprovedPrimary(), getHedgingMode(), isApprovedPrimary(uint8). Genesis-initialized with [ML-DSA-44] as approved primary. Read by KeyVault precompile at addKey time and by the consensus multiplexer at each block.
ML-DSA-44 Verifier 0x1003 FIPS 204 ML-DSA-44 signature verification (also listed in signature verifiers above).
Falcon-512 Verifier 0x1004 Falcon signature verification (also listed in signature verifiers above).
[ AUTH MODEL ]

Permissions & Authorization Matrix

Authorization rules, permission capabilities, cosigner policies, and scheme placement constraints.

Key Operations Authorization

Operation Who Can Invoke Auth Level Required Additional Constraints
bootstrapKey() Any sender with no existing keys Primary signature only (from init fields) key_count == 0; key_id must be 0; creates FullAccess primary-only entry; cosigner init fields must be absent
addKey(...) FullAccess key holder FullAccess (perm byte 0) Lifecycle intent required; key_id must not exist; primary scheme must be on approved-primary list; max 256 keys
removeKey(uint32) FullAccess key holder FullAccess (perm byte 0) Lifecycle intent required; key must exist; cannot remove last FullAccess key (lockout protection)
updateKeyAuth(...) Key holder (any permission) Self-scoped: auth_key_id == target_key_id Lifecycle intent required; key must exist; primary scheme must be approved; cosigner downgrade requires cosigner auth
getKeys(address) Anyone None (read-only) No auth context needed; callable in STATICCALL

Permission Capabilities

Capability FullAccess (0) Scoped (1)
Sign arbitrary transactions ✅ ❌
Call any contract ✅ Only allowed contracts
Call any method ✅ Only allowed selectors
Transfer any native value ✅ Up to allowance per tx
Use after expiry ✅ (no expiry) ❌ (rejected after expiry timestamp)
Invoke addKey ✅ ❌
Invoke removeKey ✅ ❌
Invoke updateKeyAuth (self) ✅ ✅ (own key lane only)
Invoke updateKeyAuth (other) ❌ ❌

Cosigner Policy Matrix

Current State Desired State Requirements
No cosigner Add cosigner updateKeyAuth with cosigner tuple; requires self-scoped auth
Active cosigner Change cosigner updateKeyAuth with new cosigner tuple; requires self-scoped auth + current cosigner signature
Active cosigner Remove cosigner updateKeyAuth with cosigner_scheme=0, cosigner_pubkey=empty; requires self-scoped auth + current cosigner signature
No cosigner No change No action needed

Scheme Placement Rules

Scheme As Primary As Cosigner Notes
ML-DSA-44 (0x01) ✅ (if on approved list) ✅ Default approved primary; post-quantum
P256 (0x02) ❌ ✅ Classical; cosigner-only (passkeys/mobile)
ECDSA (0x03) ❌ ✅ Classical; cosigner-only (hardware wallets)
SLH-DSA (0x04) ✅ (if on approved list) ❌ Post-quantum; rejected as cosigner (verification stubbed)

Safety Invariants

  1. Lockout protection: The last FullAccess key cannot be removed.
  2. Bootstrap isolation: Bootstrap is primary-only. Cosigner activation requires a subsequent explicit updateKeyAuth.
  3. Lifecycle intent binding: Mutations are bound to the authenticating sender and target key_id via transient storage.
  4. Cross-key auth mutation forbidden: updateKeyAuth is self-scoped — you can only update your own key lane.
  5. Cosigner downgrade guard: Removing an active cosigner requires the current cosigner to have signed the transaction.
  6. Primary scheme governance: All primary schemes must appear on the CryptoSwitchboard's approved_primary list.
  7. Key count cap: Maximum 256 keys per account.
  8. Scoped item caps: Maximum 64 contracts and 64 methods per scoped key.
[ CRYPTOGRAPHIC FOUNDATIONS ]

Cryptography choices

We prefer widely analyzed families and published standards where possible.

Signature schemes and wire sizes

Public keys are stored on-chain in the sender's KeyVault as chunked EVM storage and are not carried on the wire. The transaction envelope includes only a 1-byte scheme discriminator followed by the raw signature bytes.

Scheme Scheme Byte Signature Pubkey (stored) Wire Size (scheme + sig) primary_capable Notes
ML-DSA-44 (0x01) 0x01 2,420 B 1,312 B 2,421 B ✅ Default approved primary (FIPS 204). Post-quantum.
P256 (0x02) 0x02 64 B 64 B 65 B ❌ Cosigner-only. Passkeys / mobile (secp256r1).
ECDSA (0x03) 0x03 64 B 33 B 65 B ❌ Cosigner-only. Hardware wallets / custodial (secp256k1).
SLH-DSA 128s (0x04) 0x04 7,856 B 32 B 7,857 B ✅ Post-quantum hash-based hedge. Conservative but byte-heavy.
Falcon-512 — ≤ 666 B — — — Consensus layer only. Practical max-size bound.3

Only post-quantum schemes (ML-DSA-44, SLH-DSA) are primary_capable — eligible for the CryptoSwitchboard's approved-primary list. Classical schemes (P256, ECDSA) are cosigner-only per the PQ-by-default model. Public keys are registered once at bootstrap or via key updates, then loaded from KeyVault storage during detached signature verification.

Algorithm placement

Layer Algorithm Role
Consensus (validator voting) Falcon-512 Smallest PQ signatures for consensus critical path
Userland (tx auth — primary) ML-DSA-44 Mandatory primary signer on every transaction (switchboard-governed)
Userland (cosigner — retail) P256 (secp256r1) Passkeys, mobile wallets, FaceID
Userland (cosigner — institutional) ECDSA (secp256k1) Ledger, Trezor, custodial MPC networks
Cold vault cosigner (lattice hedge) SLH-DSA Hash-based cosigner for high-value accounts hedging against lattice break. Verified in node tx-auth path; no EVM precompile in v1.
Institutional custody Mithril threshold ML-DSA T-of-N (≤6 parties), standard FIPS 204 output

What we're actively exploring

  • Falcon on consensus + ML-DSA-44 on userland as the baseline split (running on devnet today)
  • Post-quantum threshold signatures with DKG for consensus scaling (separate from Mithril, which is capped at 6 parties)
  • Ringtail as a candidate for compact PQ threshold certificates at validator scale1
  • On-chain cryptographic switchboard for runtime algorithm rotation

P2P transport: PQ-KEM (post-mainnet)

We will evaluate ML-KEM (Kyber) for P2P key establishment after mainnet, once baseline performance and operational behavior are proven. No hybrid approach is planned at this stage; the goal is a clean, single-lane PQ KEM decision based on measured need and risk.
[ RESILIENCE — L1 ]

L1 cryptographic agility and the on-chain switchboard

This is the L1-protocol switchboard governing which signature schemes Quantum nodes accept for consensus and userland authorization. (For the verifier-side switchboard used by our PQ smart wallets on pre-existing EVM chains, see the cross-chain on-chain verifier in Section I and the PQ Wallet Layer.)

Existing chains are locked to one cryptographic scheme. If that scheme breaks, there's no fallback — only a contentious hard fork. We take a different approach.

Pre-baked algorithms + state-driven routing

Multiple signature algorithms are compiled into every node binary at build time. An on-chain switchboard contract (deployed at genesis) controls which algorithms are currently active. Rotating among pre-baked algorithms is a governance transaction, not a code deployment.

Fat validator keychain

When validators register, they submit keys for every algorithm baked into the binary. The network is always pre-positioned for a switch.

On-chain switchboard

The CryptoSwitchboard precompile holds the active configuration and the approved-primary list for userland keys. The KeyVault precompile reads this list at AddKey time.

Consensus multiplexer

At each block, the consensus engine reads the switchboard state and routes signing/verification through the required algorithms.

Mempool routing

The Reth transaction validator monitors the switchboard. If an algorithm is deactivated, pending transactions using only that algorithm are invalidated after the grace period.

Staged deprecation (no instant lockouts)

PHASE A

Registration freeze

The algorithm is removed from the allowed_for_new_keys list. No new KeyEntry can use it as a primary. Existing accounts can still sign normally and have a long grace period (months) to rotate keys.

PHASE B

Signing deactivation

After the grace period, the algorithm is removed from the allowed_for_signing list. Accounts that have not rotated can no longer transact. In emergency scenarios, governance can skip the grace period.

Consensus hedging (exploratory, post-mainnet)

We are evaluating hash-based dual-signing at the consensus layer (e.g., validators SLH-sign periodic checkpoints) as a mechanism for producing long-horizon finality proofs that remain verifiable even if lattice confidence collapses. This is relevant for bridges, auditors, and cross-chain verification.

However, SLH-DSA signatures are 7,856 bytes per validator — a naive "every validator signs every epoch boundary" approach is operationally impractical at scale. Any practical design would need to be low-frequency, committee-based, or off-chain-published. This remains a research item and is not part of the v1 protocol.
[ SCALING CHALLENGES ]

The PQ scaling cliff

Post-quantum signatures can be CPU-manageable, but they are large, and that cascades into bandwidth, storage, and consensus proof scaling.

User layer: throughput becomes byte-limited

Each transaction carries a larger authorization payload. If blocks/propagation are tuned around ~65–72 byte classical signatures, PQ payloads can:

  • ▸ reduce transactions per block at the same byte budget
  • ▸ increase propagation latency and orphan risk
  • ▸ increase mempool bandwidth and storage pressure

Consensus layer: quorum proofs grow with validator count

In BFT-style consensus, finality requires a quorum (often 2f+1) of validator approvals. If a quorum proof contains the set of signatures, then:

quorum-proof signature-bytes ≥ (2f+1) × signature_size

(plus signer IDs/bitmap and framing overhead)

For Falcon-512 (≤666 B max):3

  • n = 100 ⇒ f = 33 ⇒ 2f+1 = 67 ⇒ ≥ 44,622 bytes (~44.6 KB)
  • n = 200 ⇒ f = 66 ⇒ 2f+1 = 133 ⇒ ≥ 88,578 bytes (~88.6 KB)

Where time goes (why bytes become latency)

In practice, PQ payloads show up first as:

  • network latency pressure — bigger votes/certs; more bandwidth on critical path
  • durability pressure — larger artifacts persisted; fsync/WAL sync points can become visible4
  • verification pressure — often secondary for consensus, primary for tx throughput
[ CONSENSUS ]

Consensus approach

We start with Simplex for a short critical path and operational clarity.5

Then we address PQ scaling with minimal levers:

OPTION A

Current (simple)

Quorum proofs ship individual Falcon signatures.
OPTION B

Research (benchmark-gated)

Post-quantum threshold signatures with DKG to compress quorum proofs into a single signature.

Caveat: Must not erase Simplex's fast-path advantages.
[ BRIDGE ]

Entanglement: Quantum ↔ EVM Bridge

Quantum needs a bridge that preserves a clear boundary:

Nothing mints/unlocks on Quantum unless there is post-quantum (PQ) authorization.

Entanglement uses LayerZero v2 as transport and a DVN-based verification stack, with defense-in-depth:

  • 1. PQ-DVN required for EVM → Quantum verification
  • 2. Quantum-side pending credit → PQ claim() gate

Message lifecycle

OUTBOUND

Quantum → EVM

  1. 1. PQ-auth on Quantum initiates send
  2. 2. LayerZero transports message
  3. 3. EVM mints after verification + delivery
INBOUND

EVM → Quantum (inbound boundary)

  1. 1. EVM burns/locks and sends
  2. 2. Quantum records pending credit keyed by guid
  3. 3. User/relayer finalizes via PQ-authenticated claim()
[ BENCHMARKS ]

Current Quantum Benchmarks

Production-grade post-quantum security with real throughput and sub-second finality — verified on a multi-region devnet, benchmarked against today's leading L1s, L2s, and sidechains.
[ DEVNET 2 — MEASURED ]

Performance and PQC, today

20 validators · 5 regions Reth + Commonware Simplex Falcon (consensus) · ML-DSA-44 (userland)
Chain Type Real TPS Block time Finality
Quantum L1 586 sustained / 2,263 burst ~357 ms ~470 ms
EthereumL1~2112 s12 m 48 s
BaseL2~932 s13 m 13 s
OptimismL2~262 s16 m 48 s
ArbitrumL2~370.25 s13 m 48 s
Polygon PoSSidechain~1082 s5 s
Avalanche C-ChainL1~341 s2 s
PolkadotL0~2.66 s~60 s
Sustained TPS
586
vs ~21 on Ethereum L1
Block time
~357 ms
single-slot cadence
Finality
~470 ms
PQ-signed — Falcon on consensus

Comparison data sourced from chainspect.app. Quantum figures are from Devnet 2 internal runs and will be reproduced under public load harnesses; numbers may shift as we tune the network and broaden the metric set.

[ SECURITY SCOPE ]

Threat model and scope

This documentation focuses on post-quantum safety for signatures (authorization + consensus voting), not "PQ everything."

In scope

  • Account safety under quantum threat models (primary signer from approved-primary list required on every transaction)
  • Consensus safety under standard BFT assumptions (Falcon signatures)
  • Operational hedge modes (on-chain switchboard + hedging framework)
  • Wallet-layer custody hardening on other EVM chains
  • Institutional custody via Mithril threshold ML-DSA

Out of scope

  • Full PQ guarantees for all primitives beyond signatures
  • "DoS-proof" guarantees
  • MEV elimination
  • Claiming cross-chain PQ smart wallets upgrade another chain to full PQ security
  • Post-quantum transport key establishment as a requirement (evaluated post-mainnet)
[ MILESTONES ]

Roadmap

This roadmap is organized as milestones (not a status board). Workstreams can run in parallel; sequencing may adjust based on benchmarks, audits, and ecosystem readiness.
DONE

Completed

Devnet 1 (Falcon consensus) ✓ · Devnet 2 (ML-DSA-44 userland + Falcon consensus on Reth EVM) ✓ · PQ Smart Wallet prototype (Arbitrum) ✓ · Mithril implementation (threshold ML-DSA) ✓ · pq-encoder + pq-oid libraries ✓ · Documentation published ✓ · RalphStarter.ai launched ✓

W1

PQ Wallet Layer (cross-chain)

Verifier contracts deployed per supported chain. PQ smart wallet library. Local PQ signing tool (CLI). Foundry/Hardhat enablement. Frontend onboarding. Native Quantum wallet with MPC, TEE, and Mithril. Expanded integrations.

D3

Devnet 3 — NonceManager, gas economics, epoch manager, Quantum CLI

NonceManager precompile for 2D nonce tracking. Native gas sponsorship via envelope-level fee payer. Block gas economics (fee market tuning, gas pricing for PQ precompiles). Epoch manager (validator set transitions, epoch-based state management). Quantum CLI (key management, transaction submission, node operations).

D4

Devnet 4 — Threshold certificates (benchmark-gated)

Optional consensus threshold certificates for scaling validator sets.

BR

Entanglement bridge

LayerZero v2 integration. PQ boundary enforcement: pending credit → PQ claim(). Required PQ-DVN in EVM → Quantum security stacks. End-to-end benchmarks + operational runbooks.

TN

Testnet

Full surface enabled (consensus + PQ userland + Native AA + supported wallet-layer components). Multiple independent audits (consensus/networking, PQ tx + precompiles, bridge + DVN, verifier + smart wallet, Mithril).

MN

Mainnet

Launch + bug bounty.

PM

Post-mainnet: P2P transport PQ-KEM

Evaluate ML-KEM (Kyber) for P2P key establishment based on measured operational need, performance impacts, and implementation maturity. No hybrid KEM planned; clean single-lane decision.

Disclaimer

This document is a working draft intended to describe a direction and an experimental plan. Architecture, parameters, and cryptographic choices may change based on benchmarks, audits, and ecosystem readiness.

Footnotes

1 Ringtail is a candidate threshold signature scheme with message-independent preprocessing and reported signature/communication sizes at large thresholds; it's explicitly exploratory and benchmark-gated for Quantum. Separate from Mithril, which is used for institutional custody (≤6 party limit).

2 NIST PQC standards & status: FIPS 203/204/205 (finalized Aug 2024). Falcon is selected by NIST and planned for standardization as FN-DSA (FIPS 206, in development).

3 We use ≤ 666 B as a practical Falcon-512 max-size bound consistent with common interface assumptions; implementations may vary by encoding choices.

4 Larger persisted artifacts can make durability sync points more visible in latency tails (design-dependent).

5 Simplex references: Commonware materials on architecture and fast-path finality.

Ready to start building?

Explore our developer documentation and join the community.

Explore GitHub View Roadmap