Skip to main content

Threat model: what we protect

This page is the most important one in the documentation. If you are evaluating, integrating, or describing this stack to anyone else, read it before you do.

What "quantum-safe" actually means here​

A post-quantum signature scheme like ML-DSA replaces ECDSA in the signing step. It does not — and cannot — retroactively secure anything that was already signed with a classical scheme. The boundary is sharp and worth stating in plain language.

What this stack protects​

  • Future transactions from a PQ-protected smart wallet are signed with ML-DSA and are secure against quantum attacks using Shor's algorithm.
  • Assets held inside a PQ Safe7579 wallet require a valid ML-DSA signature to move.
  • Address derivation from the ML-DSA public key — the PQ smart wallet address itself has no exposed ECDSA public key on-chain.

What this stack does not protect​

  • Existing ECDSA addresses. An Ethereum address is the hash of an ECDSA public key. Changing the signing algorithm means changing the address. There is no protocol-level way to retroactively "upgrade" an EOA to PQ while keeping the address — this is a mathematical fact, not a roadmap item.
  • Historical transactions. They are already signed and settled on-chain with ECDSA. They cannot be un-signed or re-signed.
  • Assets sitting in ECDSA EOAs after a cryptographically relevant quantum computer (CRQC) exists. Any EOA that has ever signed on-chain has had its public key exposed (it is recoverable from any signature) — those addresses are subject to "harvest now, decrypt later".
  • Bridge destinations where the bridge enforces ECDSA on its side. The PQ signature protects the wallet side; it does not change what the bridge or counterparty contract requires.
  • Application-layer authorizations. A PQ-signed UserOp authorizes the smart account to execute calldata. If the target contract has a bug, an ECDSA admin key, or a centralized signer, the PQ signature does not help.

Three paths to a "quantum-safe UX"​

There is a difference between making a transaction PQ-secure and making a user's existing address PQ-secure. These are three separate paths, with very different feasibility:

LevelMechanismSame address?Status
1 — Asset migrationUser transfers assets from an ECDSA EOA into a PQ Safe7579 walletNo, new addressWorks today (current wallet MVP)
2 — EIP-7702 delegationEOA signs a one-time authorization delegating execution to a PQ smart contractYes, same addressAvailable once Pectra ships on Arbitrum
3 — Retroactive same-address upgrade"Make my existing EOA PQ-safe" with no migrationN/ACryptographically impossible. Never promise this.

Language guide​

For product, marketing, and integrations — mark this list and quote it back to anyone writing copy.

Use​

  • "Shield your assets with post-quantum signatures in one click."
  • "Future transactions are PQ-signed and unbreakable by quantum computers."
  • "Your assets move into a PQ-protected smart wallet."
  • "Same UX as MetaMask, quantum-safe execution under the hood." (EIP-7702 vision; only honest once it ships.)

Avoid​

  • "Make your existing address quantum-safe." (False.)
  • "Retroactively protect your address." (Impossible.)
  • "Your MetaMask becomes quantum-safe." (The Snap/extension creates a new PQ wallet; the MetaMask EOA is unchanged.)
  • "Hybrid ECDSA + PQ security." (Misleading — we sign PQ-only.)

A note on hybrid schemes​

There is a category of designs that combine an ECDSA signature with an ML-DSA signature and verify both. These exist for transition periods and have real use cases, especially in TLS handshakes for backward compatibility with classical-only counterparties. This stack does not deploy that on-chain: it doubles signature size and gas for a marginal security gain in our threat model, where the attacker is either capable of breaking ECDSA (in which case the ECDSA half is useless) or is not (in which case the PQ half is sufficient).

Where the smart-account boundary sits​

The on-chain validator stack — Solidity PQValidatorModule + Stylus MLDSAVerifier — is described in detail in Security boundaries. It covers what the ML-DSA signature authorizes (the UserOp calldata as digested into the UserOp hash), what it does not (mempool inclusion, paymaster behavior, target-contract logic), and the operational risks (Stylus reactivation, RC-stage crate dependency, immutable verifier address).

Summary: We sign new transactions with NIST-standardized PQ signatures — that is real and verifiable. We do not change the cryptographic past; no one can. If your asset is in an ECDSA EOA today and you want PQ protection, you move it. We are building a one-click migration to make that easy, and EIP-7702 will let us do it without changing the user-visible address when Pectra ships on Arbitrum.