Skip to main content

Threat model — Quantum L1

This page covers the L1's threat model. The product-level threat model — what the wallet protects, what the on-chain validator protects — lives in Introduction → Threat model, and the smart-account-specific boundaries live in PQ Smart Account → Security boundaries. Read those first if you haven't.

The L1 litepaper is explicit about what's in scope and what isn't. We carry that same explicitness here.

In scope​

  • Account safety under quantum threat models. A primary signer from the switchboard's approved-primary list is required on every transaction. Today that means ML-DSA-44; tomorrow it could be a new scheme via the CryptoSwitchboard.
  • Consensus safety under standard BFT assumptions. Falcon-512 validator signatures with Simplex notarization (≥ 2f+1) and finalization.
  • Operational hedge modes. The on-chain switchboard plus the crypto-agility hedging framework: pre-baked algorithms, staged deprecation, emergency mode, cold-vault profile for high-value custody.
  • QCN settlement integrity. On-chain escrow, commit-reveal, objective disputes, permissionless finalization. (Post-mainnet.)
  • Wallet-layer custody hardening on other EVM chains via the PQ Smart Account and the Quantum Wallet. Note that this is wallet-layer hardening, not L1-level PQ for those other chains.
  • Institutional custody via Mithril threshold ML-DSA. T-of-N with TEE-enforced policy.

Out of scope (v0.9)​

  • Full PQ guarantees for all primitives beyond signatures. This release is about authorization and consensus voting. Hash functions, symmetric encryption, transport encryption are not part of the v0.9 claim.
  • "DoS-proof" guarantees. The protocol is engineered for resilience, but no chain is DoS-proof; we don't claim it.
  • MEV elimination. We don't make MEV claims; ordering is bounded by Simplex leader behavior and the standard set of L1 MEV considerations.
  • On-chain adjudication of QPU correctness (default QCN mode). QCN settles disputes through commit-reveal and stake; it does not formally verify QPU output.
  • Claiming cross-chain PQ smart wallets upgrade another chain to full PQ security. They harden custody on the source chain. They do not change that chain's consensus or base accounts.
  • Post-quantum transport key establishment as a requirement. ML-KEM for P2P is evaluated post-mainnet, not committed v0.9.

What the switchboard does and does not protect against​

The CryptoSwitchboard is the runtime governance for algorithm activation. It does not improve any individual algorithm's cryptographic strength. What it does:

  • Allows rotation among pre-baked algorithms without a hard fork.
  • Enforces structural invariants (only primary_capable schemes can be on the approved-primary list).
  • Supports staged deprecation so cold-storage holders have time to rotate.
  • Supports an emergency mode for actively-broken algorithms.

What it does not do:

  • Add a new algorithm family without a coordinated client update.
  • Save users who haven't pre-positioned cold-vault keys in an emergency scenario where their primary scheme is broken. This is why the cold-vault profile (ML-DSA-44 primary + SLH-DSA cosigner) is encouraged for high-value custody — it's a covered escape hatch.

What the Entanglement bridge does and does not protect​

See Entanglement bridge for the full description.

  • The bridge preserves a PQ boundary on the Quantum side: nothing mints or unlocks without PQ authorization.
  • It does not retroactively make every chain on the other side of the bridge PQ-secure. Bridge destinations where the counterparty enforces ECDSA are still classical from that side.
  • The defense-in-depth invariants (PQ-DVN required + Quantum-side pending-credit → PQ claim()) reduce single-point-of-failure exposure, but bridges remain a high-value target and audit / monitoring are non-negotiable before any meaningful traffic.

Acknowledged risks​

For honest balance, the things that are not solved by ML-DSA or Falcon:

  • Off-chain key custody. If the user's PQ private key leaks, the chain has no way to know it. PQ-by-default does not change this fundamental constraint. The wallet, snap, and Mithril designs all exist to make this harder, but they do not make it impossible.
  • Application-layer bugs. A PQ-signed transaction authorizes the smart account to execute its calldata. If the target contract has a bug, the PQ signature does not help.
  • Validator collusion. Simplex assumes < f byzantine validators. A 2f+1 collusion can finalize anything they like, regardless of PQ.
  • TEE compromise. Mithril relies on TEEs to enforce policy at the shares. If the TEE platform is broken (or the attestation root is compromised), Mithril's policy guarantees degrade.
  • Implementation bugs. ML-DSA, Falcon, Simplex, KeyVault — every one of these is software. Audits help. Bug bounties help. Neither makes implementation bugs impossible.

We list these because pretending otherwise produces the "cryptographic security theater" that we are explicitly trying to avoid.