[ Litepaper ]
Protocol Overview
A comprehensive overview of the Quantum protocol in one place. Version 0.9 — March 2026.
TL;DR
EXECUTIVE SUMMARY
Most blockchains rely on classical signatures (ECDSA/EdDSA/Schnorr) 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.
Current direction:
- 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.
- PQ signatures: Falcon (compact, consensus) + 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.
- 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.
- Crypto agility: Multiple signature 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 or restarts. Adding a net-new algorithm family requires a coordinated client update.
- 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
- 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).
- 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).
- PQ Wallet Layer (cross-chain):
- 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.
- 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.
- QCN (Quantum Circuit Network): A settlement-layer marketplace for distributed quantum jobs on real QPUs (off-chain discovery + on-chain escrow, commit→reveal, objective disputes, permissionless finalization). Planned post-mainnet once the base chain + Entanglement are hardened.
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.
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":
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.
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.
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.
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.
Minimalist architecture
We avoid adding complexity (e.g., DAG ordering) unless benchmarks prove it's required.
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.
Design goals
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.
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.
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.
Keep the protocol simple
Prefer straightforward consensus + execution unless measurements demand more.
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.
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.
Compute settlement
QPU job results and receipts anchored under PQ authorization (QCN).
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 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. |
| QCN | On-chain escrow + off-chain execution | Quantum job marketplace settled on Quantum |
Core chain transaction path
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.
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 approach
We start with Simplex for a short critical path and operational clarity.5
Then we address PQ scaling with minimal levers:
Current (simple)
Quorum proofs ship individual Falcon signatures.
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.
Cryptographic agility and the on-chain switchboard
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)
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.
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.
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?
Requires UserOperations, off-chain bundlers, and gas-heavy proxy smart contracts. Dead end for a new L1.
Theoretical ideal but introduces unsolved mempool DoS vectors (arbitrary code execution in validation frame). Too risky for production.
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
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.
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.
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 KEYENTRYFor 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.
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). |
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
- Lockout protection: The last FullAccess key cannot be removed.
- Bootstrap isolation: Bootstrap is primary-only. Cosigner activation requires a subsequent explicit updateKeyAuth.
- Lifecycle intent binding: Mutations are bound to the authenticating sender and target key_id via transient storage.
- Cross-key auth mutation forbidden: updateKeyAuth is self-scoped — you can only update your own key lane.
- Cosigner downgrade guard: Removing an active cosigner requires the current cosigner to have signed the transaction.
- Primary scheme governance: All primary schemes must appear on the CryptoSwitchboard's approved_primary list.
- Key count cap: Maximum 256 keys per account.
- Scoped item caps: Maximum 64 contracts and 64 methods per scoped key.
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.
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
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.
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.
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.
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.
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)
How it works (high level)
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.
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
Quantum → EVM
- 1. PQ-auth on Quantum initiates send
- 2. LayerZero transports message
- 3. EVM mints after verification + delivery
EVM → Quantum (inbound boundary)
- 1. EVM burns/locks and sends
- 2. Quantum records pending credit keyed by guid
- 3. User/relayer finalizes via PQ-authenticated claim()
Quantum Circuit Network (QCN)
QCN is a protocol and marketplace for running structured quantum circuit jobs on real QPUs, with off-chain execution and on-chain settlement on Quantum.
Off-chain discovery + on-chain commitments + rule-based settlement.
What QCN is
- A compute market (workers compete on price + SLA + reliability)
- A settlement layer (escrow + bonds + objective slashing)
- Composable with EVM contracts (async job requests and result consumption)
What QCN is not (by default)
- An on-chain correctness verifier for quantum outputs
- A redundant rerun system
- A speed race ("first to claim wins")
Job lifecycle
What we will benchmark
We treat PQ readiness as measurable bottlenecks: bytes, sync points, and latency distributions.
Consensus metrics
- ▸ time-to-notarization / time-to-finality (p50/p95/p99)
- ▸ end-to-end bytes per view
- ▸ bytes broadcast per validator per view
- ▸ durability sync points (WAL/fsync) impact on latency tails
- ▸ sign-time tails under load
- ▸ certificate size vs validator count (with/without thresholding)
User layer metrics
- ▸ tx byte size (pk-in-every-tx vs KeyVault key-id reference)
- ▸ composite signature verification throughput (primary + cosigner)
- ▸ precompile verification throughput (KeyVault, NonceManager, CryptoSwitchboard)
- ▸ block propagation vs tx size
- ▸ cold vault (SLH-DSA cosigner) tx overhead vs standard composite tx
Crypto metrics
- ▸ sign/verify microbench across CPU targets
- ▸ implementation variance and tail latency
- ▸ Mithril threshold signing latency under realistic custody workflows
PQ Wallet Layer metrics
- ▸ PQ smart wallet gas costs and overhead
- ▸ verifier contract gas costs per supported chain
- ▸ end-to-end UX latency: sign → submit → finalize
- ▸ tooling friction for Foundry/Hardhat and common stacks
P2P transport evaluation (post-mainnet)
- ▸ handshake size and fragmentation behavior
- ▸ handshake CPU costs and tail latency
- ▸ connection churn impacts (reconnect storms, NATs, mobile links)
- ▸ operational debugging complexity and failure modes
- ▸ compatibility with existing network stacks and observability
Threat model and scope
This litepaper 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)
- QCN settlement integrity
- 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
- On-chain adjudication of QPU correctness (default QCN mode)
- Claiming cross-chain PQ smart wallets upgrade another chain to full PQ security
- Post-quantum transport key establishment as a requirement (evaluated post-mainnet)
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.
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 ✓ · Litepaper published ✓ · RalphStarter.ai launched ✓
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.
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).
Devnet 4 — Threshold certificates (benchmark-gated)
Optional consensus threshold certificates for scaling validator sets.
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.
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).
Mainnet
Launch + bug bounty. QCN begins as a post-launch track (phased, benchmark-gated).
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.