[ Litepaper ]

Protocol Overview

A comprehensive overview of the Quantum protocol in one place.

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 (Ethereum execution ergonomics).
  • Consensus: Commonware Simplex for fast notarization/finality (2 hops to notarization, 3 hops to finalization).
  • PQ signatures: Falcon (compact) + ML-DSA/Dilithium (conservative), with a hash-based hedge path using SLH-DSA for break-glass security.
  • Threshold exploration: Ringtail as a candidate for compact PQ threshold certificates (to avoid shipping 2f+1 signatures per certificate).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).
  • PQ Wallet Layer (cross-chain):
    • MetaMask Snap enabling PQ key management + PQ signing (Falcon or ML-DSA lane).
    • Local PQ signing tool to sign transactions and broadcast via standard pipelines (Foundry/Hardhat), with planned upstream PRs where feasible.
    • PQ verifier contract deployed per supported chain (Falcon or ML-DSA/Dilithium), used by smart wallets for on-chain verification.
    • PQ-secured smart wallets on other EVM chains: assets held in a wallet that only accepts PQ signatures.
    • More wallet integrations and a native Quantum wallet.
  • 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 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.
02

Consensus and networking engineered for PQ payload sizes

PQ signature and certificate bytes are treated as a first-class protocol constraint.
03

Cryptographic agility and operational hedging

We plan for algorithm surprises with clear "normal → hedged → emergency" modes.
04

Minimalist architecture

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

Bring PQ safety to the broader EVM ecosystem

Even before chains migrate at L1, we can materially improve asset custody by enabling PQ-secured smart wallets and mainstream wallet + developer tooling that can produce PQ signatures.
[ PRINCIPLES ]

Design goals
01

PQ authorization at L1 (target end state)

Classical ECDSA is not a valid authorization mechanism for accounts.

02

Fast finality, designed for PQ payloads

We target sub-second UX and treat bytes as the key constraint.

03

Hedge against cryptographic surprises

Lattice dominates practical PQ, but we preserve a conservative hedge path.

04

Keep the protocol simple

Prefer straightforward consensus + execution unless measurements demand more.

05

Make PQ adoption practical

Ship wallet and dev tooling so PQ signing works in real workflows (not just research demos).
[ 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

Accounts that demand "break-glass" safety guarantees (dual-sign policies).

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.
[ 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 EVM compatibility and execution ergonomics
Consensus Simplex (Commonware) Fast notarization/finality with short critical path
Authorization PQ tx type + verifier precompiles PQ signatures as default authorization (target end state)
Entanglement bridge LayerZero v2 + DVN stack + PQ boundary gate Cross-chain transfers with pending credit → PQ claim()
PQ Wallet Layer Snap + verifier contracts + smart wallets PQ signing + PQ custody on other EVM chains
QCN On-chain escrow + off-chain execution Quantum job marketplace settled on Quantum

Core chain transaction path

1 User signs a PQ transaction (target end state).
2 Nodes perform transaction validity checks.
3 Signature verification runs via PQ verifier precompiles.
4 Optional future optimization: resolve keys/policy via AuthDescriptor.
5 Execute in Reth EVM.
6 Persist state updates.
7 Simplex provides notarization → finalization.
[ CRYPTOGRAPHIC FOUNDATIONS ]

Cryptography choices

We prefer widely analyzed families and published standards where possible.

Signature sizes (intuition)

Scheme Signature size Notes
Falcon-512 ≤ 666 B (max) Practical max-size bound used in common integration patterns.3
ML-DSA-44 (Dilithium family) 2,420 B Standardized family (FIPS 204).
SLH-DSA 128s 7,856 B Hash-based hedge is conservative but byte-heavy.

What we're actively exploring

  • Falcon everywhere (userland + consensus) for minimum bytes
  • Falcon userland + threshold certificates for consensus scaling (Ringtail candidate)1
  • Falcon vs ML-DSA/Dilithium lanes (benchmark + audit driven), depending on maturity and operational performance

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.
[ 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

Simple

Quorum proofs ship many signatures
OPTION B

Benchmark-gated

Threshold certificates / threshold proofs (ship one signature)

Caveat: threshold signing adds interaction. It must not erase Simplex's fast-path advantages.
[ RESILIENCE ]

Hedging and cryptographic agility

We want a contingency if a major lattice break happens.

Hedging modes
NORMAL

Normal

Lattice-only signatures.
CHECKPOINT

Checkpoint-hedged

Hash-based signatures only on checkpoints (epoch boundary / cadence).
EMERGENCY

Emergency

Dual-sign per message (lattice + hash-based) for sustained active attack scenarios.

Scope clarity: checkpoint hedging strengthens external anchoring without taxing the fast path. If lattice signatures become fully forgeable, Emergency is the break-glass posture for continued operation under pressure.
[ AUTHORIZATION ]

User layer: PQ-native authorization and key policy
CURRENT

Bring-up posture

1
Devnet 1

PQ consensus only (userland remains classical temporarily)

2
Devnet 2

PQ userland authorization + verifier precompiles; simplest tx format (pubkey included in every tx)
TARGET

End state

Disable ECDSA as L1 authorization entirely
Add a PQ transaction type
PQ-native EOAs (sender derived from PQ pubkey hash → 20-byte address)
PQ verify precompiles (Falcon/ML-DSA lane depending on direction)
AA wallet templates as default UX (not the only way to transact)
Phase 1 SHIP FIRST

Include pubkey every tx

Tx carries pubkey + signature each time. Avoid key registry complexity early.

No registry required
Phase 2 OPTIMIZE

Optional key registry (AuthDescriptor)

If bandwidth becomes painful, introduce native state: address → AuthDescriptor(keys, scheme_id, policy, metadata) and allow short-form tx referencing a key-id.

Bandwidth-gated upgrade

Hedge accounts

VAULT POLICY: 2-of-2

For users wanting a stronger safety margin:

One lattice key (Falcon / ML-DSA) + one hash-based key (SLH-DSA)
2-of-2 required to spend and rotate keys
[ 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.

MetaMask Snap for PQ key management + signing

A MetaMask plugin enabling users to generate and manage PQ keys, and produce PQ signatures (Falcon or ML-DSA lane).

2.

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.

3.

PQ verifier contract deployments

Falcon or ML-DSA/Dilithium verifier contract deployed per supported chain, used by smart wallets for canonical on-chain PQ signature verification.

4.

PQ-secured smart wallets

Smart wallets on other EVM chains where assets are held in a wallet that only accepts PQ signatures, delegating verification to the chain's verifier contract.

5.

More wallet integrations + native Quantum wallet

Additional wallet integrations and a native Quantum wallet 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 installs the MetaMask Snap (or uses another 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 Snap or another 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 Dilithium/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
MetaMask Snap (PQ signer) User device (inside MetaMask) Generates/holds PQ keys and produces PQ signatures
Local PQ signing tool (CLI) User/dev machine Signs with PQ keys; broadcast via Foundry/Hardhat/RPC/relayers
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/Dilithium)
Frontend / onboarding Web app Guides setup; Snap install; wallet deploy; asset migration
Relayer (optional) Off-chain service Improves UX (batching/sponsored gas) without weakening PQ auth

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 UX (Snap / wallet / local signer).
[ 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()
[ COMPUTE NETWORK ]

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

1. Submit → 2. Accept (bond locks) → 3. Commit → 4. Reveal → 5. Finalize (permissionless)
[ BENCHMARKS ]

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 registry)
  • ▸ precompile verification throughput
  • ▸ block propagation vs tx size
  • ▸ hedge policy overhead vs standard policy

Crypto metrics

  • ▸ sign/verify microbench across CPU targets
  • ▸ implementation variance and tail latency

PQ Wallet Layer metrics

  • ▸ Snap signing latency + reliability in real dApp flows
  • ▸ verifier gas costs and smart wallet overhead
  • ▸ end-to-end UX latency: sign → submit → finalize
  • ▸ tooling friction for Foundry/Hardhat and common stacks

QCN metrics

  • ▸ job submission calldata + gas
  • ▸ commit/reveal overhead
  • ▸ finalize contention and keeper tip sizing
  • ▸ dispute rates and slashing effectiveness
  • ▸ artifact availability during challenge windows
[ SECURITY SCOPE ]

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 (no ECDSA auth in target end state)
  • Consensus safety under standard BFT assumptions
  • Operational hedge modes
  • QCN settlement integrity
  • Wallet-layer custody hardening on other EVM chains

Out of scope

  • Full PQ guarantees for all primitives beyond signatures
  • MEV elimination
  • On-chain adjudication of QPU correctness (default QCN mode)
  • Claiming cross-chain PQ smart wallets upgrade another chain to full PQ security
[ 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.
M1

PQ Wallet Layer (Cross-chain) MVP

Deploy a wallet-layer custody primitive across multiple EVM chains (not cross-chain signing).

  • ▸ PQ verifier contract deployed once per supported chain (Falcon or ML-DSA/Dilithium lane)
  • ▸ PQ smart wallet that delegates signature verification to the verifier contract
  • ▸ MetaMask Snap for PQ key management + signing
  • ▸ Frontend onboarding + migration flow: Snap install → wallet deploy → deposit/migrate assets → PQ-only usage
  • ▸ Local PQ signing tool (CLI) to sign and broadcast via standard pipelines
  • ▸ Foundry/Hardhat enablement, with upstream PRs where feasible
  • ▸ Security review/audit scope for verifier + wallet + onboarding flows
M2

Quantum L1 Devnet 1 (PQ consensus baseline)

Simplex with PQ validator signatures. Benchmarks: vote/certificate bytes, WAL/durability impact, notarization/finality distributions.

M3

Quantum L1 Devnet 2 (PQ userland authorization)

PQ transaction type + verifier precompiles. Phase 1 tx format: pubkey included in every tx.

M4

Hedging modes (checkpoint + emergency)

Checkpoint hedging (hash-based signatures only on checkpoints). Emergency mode (dual-sign every consensus message when activated).

M5

AuthDescriptor optimization (optional key registry)

Short-form tx option referencing on-chain key metadata. Benchmarks: state growth vs bandwidth savings.

M6

Threshold certificates (optional, benchmark-gated)

Prototype behind a feature flag. Go/no-go based on interaction cost vs bytes saved and tail-latency impact.

M7

Entanglement MVP (Quantum ↔ EVM bridge)

LayerZero v2 adapters + bridge cores. PQ boundary enforcement: pending credit → PQ claim().

  • ▸ Required PQ-secured DVN in EVM → Quantum security stacks
  • ▸ End-to-end benchmarks + operational runbooks
M8

Public Testnet + audits

Full surface enabled (consensus + PQ userland + Entanglement + supported wallet-layer components). Multiple independent audits.

M9

Mainnet launch + bug bounty + QCN kickoff

Mainnet launch + bug bounty program. QCN begins as a post-launch track (phased, benchmark-gated).

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.

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