Skip to main content

How the pieces fit

The stack has four main pieces:

┌──────────────────────────────┐   ┌──────────────────────────────┐
│  Quantum Wallet              │   │  PQ Signer                   │
│  Self-custodial extension    │   │  Custodian co-signing service │
│  ML-DSA-44 signing           │   │  TEE + KMS — no hot key       │
│  Safe7579 smart accounts     │   │  Threshold ML-DSA via Mithril │
└───────────────┬──────────────┘   └───────────────┬──────────────┘
                │ uses                              │ uses
                └──────────────┬────────────────────┘
                               ▼
┌──────────────────────────────────────────────────────────────────┐
│  PQ Smart Account                                                │
│  ERC-7579 validator module + Arbitrum Stylus ML-DSA-65 verifier  │
│  Plug-and-play PQ authorization for ERC-4337 accounts            │
└───────────────────────────┬──────────────────────────────────────┘
                            │ uses
                            ▼
┌──────────────────────────────────────────────────────────────────┐
│  post-quantum-packages                                           │
│  NIST PQ packages (TS + Rust): OIDs, key encoding, JWS/JWE,     │
│  COSE/CMS, FIDO2, TLS, blockchain signers, WASM/Worker runtimes  │
└──────────────────────────────────────────────────────────────────┘

post-quantum-packages​

A monorepo of NIST PQ packages, all published to npm and crates.io with identical APIs and shared NIST ACVP test vectors. The catalog covers:

  • Core primitives — OIDs, algorithm identifiers, key encoding (DER/PEM/JWK/SPKI/PKCS#8), test vectors, key strength, size calculation, fingerprints, RNG, side-channel helpers.
  • Certificates — SPKI, PKCS#8, CSR, X.509 parse and verify.
  • Web standards — JWS, JWE, JWK, JWT verify, COSE, CMS, PKCS#7, XMLDSig, DKIM.
  • Encryption and key exchange — ECIES, HPKE, KEM combiner, Noise.
  • Authentication — FIDO2, WebAuthn, SSH agent, Kerberos.
  • Network protocols — TLS 1.3 client, DTLS, QUIC crypto.
  • Blockchain — Ethereum signer, Solana signer, Bitcoin Taproot.
  • Runtime — browser WASM build, Web Worker wrapper.

See Overview and package catalog for the full list and current implementation status.

PQ Smart Account​

A three-layer system that lets any ERC-7579-compatible smart account require ML-DSA-65 signatures for selected operations, without protocol changes or new chains:

  • Off-chain tools — Rust CLI (pq-keygen, pq-sign, pq-verify), a MetaMask Snap, and a WalletConnect dapp build UserOperations and sign their hashes with ML-DSA-65.
  • Solidity validator module (PQValidatorModule) — ERC-7579 compliant. Stores a 1,952-byte public key per account, exposes validateUserOp and isValidSignatureWithSender, and delegates verification to the Stylus contract.
  • Stylus verifier (MLDSAVerifier) — Rust/WASM running on Arbitrum Stylus. ML-DSA-65 verification at roughly 374K gas — 10–100× cheaper than the equivalent pure-EVM implementation.

Compatible with Kernel v3, Safe7579, and other ERC-7579 accounts. End-to-end validated locally on a Nitro devnode with the Alto bundler.

See Architecture overview for the request flow.

PQ Signer​

A custodian co-signing service for institutions and teams that cannot accept a single hot key. PQ Signer uses hardware Trusted Execution Environments (AWS Nitro Enclaves) and KMS-backed key material to enforce a policy boundary: a signature is only produced when the transaction passes a configurable authorization check, regardless of whether the application host is compromised.

Key properties:

  • No hot key — signing key material never exists outside the enclave or KMS; there is no file or environment variable to steal.
  • Policy enforcement inside hardware — the enclave verifies authorization before participating in the signing protocol, not afterward.
  • Threshold signing via Mithril — supports T-of-N ML-DSA signing (up to 6 parties), producing standard FIPS 204 output accepted by any ML-DSA verifier.
  • Drop-in for custodians — PQ Signer slots into any ERC-4337 workflow as a co-signer; it does not replace the wallet, it augments it.

See PQ Signer architecture for the full trust model and end-to-end flow.

Quantum Wallet​

A self-custodial Chrome extension and Vite web app:

  • Crypto — ML-DSA-44 signing via wdk-signing-pq, BIP-39 mnemonic, AES-256-GCM encrypted vault, ephemeral master key in session storage.
  • Accounts — Safe7579 smart accounts with the PQValidatorModule. Custom viem code path for ERC-4337 UserOp construction (no Safe SDK).
  • Chains — Arbitrum (USDT today, more ERC-20s queued), native Quantum L1 (QBIT), with an Arbitrum USDT ↔ Quantum qUSDT bridge UI.
  • UX — works as a standalone extension or as a "dApp" connected to the extension via EIP-6963, and ships a faucet app for testnet onboarding.

How they share code​

  • The wallet imports pq-key-encoder, pq-oid, and pq-algorithm-id from npm (transitively, via wdk-signing-pq) to handle JWK / SPKI / fingerprint serialization for backup and recovery.
  • The smart-account validator stack uses the Rust ML-DSA implementation directly in the Stylus contract; the Solidity module is independent of pq-* packages because all encoding happens off-chain.
  • Quantum L1 uses pq-* packages for transaction signing, key encoding, verifier-contract tooling, and the PQ wallet layer that extends to other EVM chains.

The same packages can be (and are) used outside this stack. They are MIT-licensed.

Where the lines are​

A common confusion: the algorithm the wallet uses (ML-DSA-44) is not the same as the algorithm the smart-account validator on Arbitrum uses (ML-DSA-65). This is intentional. ML-DSA-44 is faster to sign and produces smaller signatures, which is what an extension needs for responsive UX on a constrained device. ML-DSA-65 gives a wider security margin (NIST Level 3 vs Level 2) for on-chain verification, where signature size is paid in L1 calldata and verification gas is the dominant cost. The validator can be configured for either; current production uses ML-DSA-65.