Cryptography choices
We prefer widely-analyzed families and published standards. The choices below are deliberate and each one is justified by the constraints of its layer.
Scope note (v0.9). This page covers post-quantum signatures for authorization and consensus. Post-quantum key establishment (KEMs) for transport encryption is not a v0.9 requirement; ML-KEM (Kyber) for P2P key establishment will be evaluated after mainnet.
Algorithm placement
| Layer | Algorithm | Role |
|---|---|---|
| Consensus (validator voting) | Falcon-512 | Smallest PQ signatures for the consensus critical path |
| Userland — primary | ML-DSA-44 | Mandatory primary signer on every transaction (switchboard-governed) |
| Userland — cosigner (retail) | P256 (secp256r1) via RIP-7212 | Passkeys, mobile wallets, FaceID / Android |
| Userland — cosigner (institutional) | ECDSA (secp256k1) | Ledger, Trezor, custodial MPC networks |
| Cold vault cosigner (lattice hedge) | SLH-DSA | Hash-based cosigner for high-value accounts hedging against a lattice break. Verified in node tx-auth path; no EVM precompile in v1. |
| Institutional custody | Mithril threshold ML-DSA | T-of-N (≤6 parties), standard FIPS 204 output |
Wire sizes
Public keys are stored on-chain in the sender's KeyVault (chunked EVM storage) and are not carried on the wire. The wire envelope contains only a 1-byte scheme discriminator followed by the raw signature bytes — the detached-key model reduces ML-DSA-44 wire size by roughly 35%.
| Scheme | Scheme byte | Signature | Pubkey (stored) | Wire size (scheme + sig) | primary_capable | Notes |
|---|---|---|---|---|---|---|
| ML-DSA-44 | 0x01 | 2,420 B | 1,312 B | 2,421 B | ✅ | Default approved primary (FIPS 204). Post-quantum. |
| P256 | 0x02 | 64 B | 64 B | 65 B | ❌ | Cosigner-only. Passkeys / mobile (secp256r1). |
| ECDSA | 0x03 | 64 B | 33 B | 65 B | ❌ | Cosigner-only. Hardware wallets / custodial (secp256k1). |
| SLH-DSA 128s | 0x04 | 7,856 B | 32 B | 7,857 B | ✅ | Post-quantum hash-based hedge. Conservative but byte-heavy. |
| Falcon-512 | — | ≤ 666 B | — | — | — | Consensus layer only. Practical max-size bound. |
Only post-quantum schemes (ML-DSA-44, SLH-DSA) are primary_capable and eligible for the CryptoSwitchboard's approved-primary list. Classical schemes (P256, ECDSA) are cosigner-only by design — that's the PQ-by-default invariant.
Why each choice
Falcon-512 at consensus
Consensus is the byte-hungriest layer in a chain: every validator signs every quorum, and the quorum proofs ship over the network. Falcon has the smallest signature size among standardized PQ candidates (≤ 666 B). At 100 validators with 2f+1 = 67, a Falcon-512 quorum proof is roughly 44.6 KB; the equivalent in ML-DSA-44 would be roughly 162 KB.
The trade-off is that Falcon signing is more complex than ML-DSA (rejection-sampling-based and harder to make constant-time). For the consensus role — server-side validators with controlled environments — this is acceptable. For userland — heterogeneous devices, hostile environments — ML-DSA is the better fit.
ML-DSA-44 at userland
Three constraints govern userland: (1) signature size that fits in a transaction with reasonable mempool behavior, (2) signing that is fast and side-channel-resistant on commodity hardware, (3) NIST-standardized so we can interoperate.
ML-DSA-44 hits the balance: 2,420-byte signatures (3,733 B total wire including the pubkey, though we use detached keys so only the signature ships), faster verification than ML-DSA-65/87, and FIPS 204 conformance. We don't use ML-DSA-65 in userland because the marginal security gain at Level 3 is paid in nearly 1 KB extra per transaction, which compounds across L1 calldata.
ML-DSA-65 is used in the PQ Smart Account on Arbitrum verifier — there, on-chain verification gas dominates and signature size is paid in L2 calldata, so the Level 3 margin is worth it.
P256 cosigner for retail
P256 (secp256r1) is the curve behind Apple and Android Passkeys. It is available natively on every modern smartphone via the Secure Enclave / StrongBox / TEE. Pairing ML-DSA-44 (the lock) with P256 (the convenience layer) means a user signs with FaceID and gets PQ security underneath — no seed phrases, no browser extension.
P256 verification on Quantum uses the RIP-7212 precompile (canonical L1 address 0x0100), EIP-7951 compliant.
ECDSA cosigner for institutions
Institutional custody is built on ECDSA secp256k1: Ledger, Trezor, Fireblocks, Coinbase Prime, Copper, Anchorage. These pipelines exist, are audited, and are insured. Telling these custodians to rip them out is a non-starter. Quantum lets them plug their existing ECDSA infrastructure in as the cosigner and add an ML-DSA signer alongside. The result: ML-DSA is the lock, ECDSA is the operational interface. Integration drops from an estimated 18 months to a quarter.
SLH-DSA as a hedge, not a default
ML-DSA and Falcon are both lattice-based. If lattice math breaks, both userland auth and consensus signatures become suspect at the same time. The P256 / ECDSA cosigner doesn't help — it's classically secure but quantum-vulnerable. SLH-DSA is hash-based: its security rests on the collision resistance of a hash function, an entirely independent assumption.
SLH-DSA-128s signatures are 7,856 bytes — impractical for everyday transactions. So we treat it as a cold vault profile: a KeyEntry with primary = ML-DSA-44 and cosigner = SLH-DSA (both required). Designed for rare high-value operations (treasury movements, key rotation) where the bandwidth cost is acceptable. SLH-DSA verification ships in the node's native tx-auth path; an EVM verifier precompile is deferred until a concrete smart-contract use case appears.
Mithril for institutional custody
Mithril is a constant-time Rust implementation of threshold ML-DSA (ePrint 2026/013) for T-of-N signing across up to 6 parties. It produces standard FIPS 204 signatures, verifiable by any conforming ML-DSA verifier. See Mithril (threshold ML-DSA) for the full design.
Research directions
The following are research directions, not v1 commitments.
- Post-quantum threshold signatures with DKG for consensus scaling. Separate from Mithril, which is capped at 6 parties.
- Ringtail as a candidate for compact PQ threshold certificates at validator scale.
- Hash-based checkpoint hedging at consensus — low-frequency, committee-based. Research item, not v1.
- ML-KEM for P2P transport encryption (post-mainnet evaluation).