Skip to main content

Litepaper summary

This is the condensed version of the Quantum Litepaper v0.9. This page is the one-screen briefing for partners and integrators.

Status: v0.9 working draft (March 2026). Architecture and parameters are subject to change based on benchmarks, audits, and ecosystem readiness.

The thesis​

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.

The "which algorithms?" question is converging. NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024, with Falcon (FN-DSA / FIPS 206) following. It is time for systems engineering, not standards-waiting.

What we are building​

  • Execution. EVM-compatible execution. Deploy any Solidity contract as-is — Foundry, Hardhat, and the full EVM toolchain work without modification. Only transaction signing routes through Quantum's PQ signing tool until upstream toolchains adopt the Quantum transaction type natively.
  • Consensus. Commonware Simplex for fast notarization and finality (2 hops to notarization, 3 hops to finalization). Falcon signatures chosen for the smallest PQ signature size on the consensus critical path.
  • PQ signatures. Falcon at consensus, ML-DSA-44 at userland, with SLH-DSA pre-baked as a hash-based fallback for lattice-break scenarios.
  • Native Account Abstraction. Custom EIP-2718 composite transactions verified at the protocol level before EVM execution. Every account is a smart account. PQ security is structural, not policy.
  • Crypto agility. Multiple signature algorithms ship pre-baked in every node binary; an on-chain switchboard controls which are active. Runtime rotation needs no hard forks.
  • Mithril. Constant-time implementation of threshold ML-DSA (ePrint 2026/013, USENIX Security 2026) for institutional custody.
  • Entanglement bridge. LayerZero v2 transport with a hard PQ boundary invariant: nothing mints or unlocks on Quantum without post-quantum authorization.
  • PQ Wallet Layer. PQ smart wallets on other EVM chains, plus a native Quantum wallet with MPC, TEE, and Mithril threshold ML-DSA.
  • QCN (Quantum Circuit Network). A post-mainnet settlement-layer marketplace for distributed quantum jobs on real QPUs.

Why this isn't "PQ as a plugin"​

Existing chains adding PQ tend to do it as an opt-in or a hybrid scheme on top of an ECDSA-mandatory base. Quantum inverts the default:

  • PQ-by-default authorization. Addresses derive from PQ keys. There is no ECDSA fallback. Every transaction requires a primary signer from the switchboard's approved-primary list.
  • Consensus and networking sized for PQ. Bytes are first-class protocol constraints, not afterthoughts.
  • Operational hedging baked in. Pre-baked algorithms plus on-chain switchboard means runtime rotation is a governance transaction, not a code deployment.
  • Composite transactions with cosigner UX. The primary is the lock (PQ). Cosigners (P256 passkeys, ECDSA hardware wallets) are convenience and compatibility, not security dependencies.

The litepaper carries the full footnotes, citations, and parameter discussion. Everything in this section is derived from it; if there is ever a discrepancy, the litepaper wins.