← Duc V. Le
ACM PQQS 2026

SoK: Stablecoins in the Quantum Era

Stablecoin value sits behind a small set of issuer, custody, oracle, bridge and upgrade keys, on top of host-chain cryptography that a quantum computer breaks. This SoK maps each stablecoin function to its cryptographic assumption, the party able to migrate it, and the party that pays if it fails.

Panagiotis Chatzigiannis, Navid Alamati, Suvradip Chakraborty, Duc V. Le

In three numbers

Why this is not a drop-in swap

Every figure below is quoted from the paper, which in turn cites standards, draft EIPs and published measurements.

ML-DSA-44 vs ECDSA signature
≈37×

2,420 bytes against 65 bytes of calldata. The comparison leaves out aggregation, public-key storage, contract execution and failure recovery (§5.2).

Logical qubits, 256-bit ECDLP
835

Luo et al.'s construction for a 256-bit prime-field curve. Babbush et al. give about 1,200 or 1,450 for secp256k1. These are logical counts; physical counts are substantially larger (§3.1).

Same ML-DSA-44 signature, two drafts
4,500 vs 50,000 gas

EIP-8051's specialized precompile against EIP-8164's intrinsic account cost. Neither is the cost of verifying ML-DSA in ordinary Solidity (§4.1).

The problem

A stablecoin is not a single contract

Shor's algorithm breaks ECDSA, Schnorr, EdDSA and BLS. For an ordinary wallet that means one theft. For a stablecoin, one extracted mint, bridge or oracle key can change supply, redemption or liquidity for every holder. The paper models a stablecoin as three coupled layers:

Control plane

Changes supply or its rules

Mint and burn keys, treasury, pause and blacklist roles, proxy upgrades, governance, oracle administration, bridge attestation.

Settlement substrate

Authenticates and orders

Host-chain accounts, validator and finality signatures, data availability, rollup proofs, sequencers, light clients, cross-chain verification.

Claim & distribution

Holds the value

Holders, custodians, exchanges, DeFi protocols, payment apps, redemption channels, wrapped representations.

The authority–liability gap. The party able to migrate a component is often not the party that bears the loss when it fails. A migration that is technically available can still stall because the actor who could deploy it lacks the incentive, legal authority or coordination channel to protect the loss bearer.

Timing follows Mosca's inequality: a system is insecure if $X + Y > Z$, where $X$ is how long the data must stay protected, $Y$ is migration time and $Z$ is time until a CRQC. For stablecoins, $X$ is years to decades and $Y$ is large because every layer migrates through its own governance process. The paper does not estimate $Z$.

Regulation constrains how migration may happen (Table 2)
SourceRequirementMigration consequence
MiCA Art. 34Governance, ICT controls, continuityKey and contract migration must be inventoried, tested, and auditable.
MiCA Arts. 46–47, 49, 55Recovery, orderly redemption, par redeemabilityFreezes, reissuance, and claim contracts must preserve timely and equitable redemption.
GENIUS Act §4Reserves, disclosed redemption, operational/IT riskA PQ incident is an operational-risk and disclosure event, not only a protocol bug.
GENIUS Act §4(a)(6) and OCC proposalsLawful orders, custody, audit, AML/sanctionsMigration must preserve required freeze, burn, screening, blocking, and reporting controls.

Interactive 1 · Table 1

Who can fix it, and who pays

Choose a control surface. The left box names the actor able to migrate it and the right box names the principal loss bearer. Where they differ, a working post-quantum primitive is not enough.

    Interactive 2 · §3.3 and Table 3

    Upgrade one layer; watch what stays exposed

    Mark components as post-quantum secure. The outcomes on the right follow the paper's cross-layer rules. Securing the issuer's keys does not protect users on a vulnerable host chain, and a PQ bridge committee does not protect wrapped supply if source-chain finality can still be rewritten.

    Preset
    7of 7 stablecoin functions exposed
    Attack patterns still open

      Component-to-attack mapping from Table 3 and §3.3; control surfaces from §4, Dimension 1, and Table 1. Store-now-decrypt-later: upgrading the KEM protects future traffic only, because traffic already archived stays exposed.

      Interactive 3 · Remark in §3.1

      Quantum compromise is not all-or-nothing

      The paper separates three regimes of quantum attack. Stablecoins are exposed in the first: issuer, bridge and oracle keys sit at static on-chain addresses with public keys already revealed.

      Schematic; not to scale. The only time values shown are the paper's 12–15 s Ethereum window.

      Resource estimates cited in §3.1
      SourceTargetLogical qubitsToffoli gates
      Babbush et al.secp256k1at most about 1,20090 million
      Babbush et al.secp256k1about 1,45070 million
      Luo et al.256-bit prime-field curve835—

      Logical counts only. The paper gives no physical-qubit or runtime figure; these depend on error correction, physical error rate and target runtime.

      Interactive 4 · Tables 7 and 9

      Gas figures only mean something with their execution model

      Every cost figure in the paper on one log axis, coloured by what kind of evidence it is. Calldata figures only price moving the signature bytes. Draft EIPs are proposed prices. poqeth figures are measured full-EVM verification. The spread covers six orders of magnitude, and the paper warns these values are not directly comparable.

      Show poqeth
      • Calculated (bytes × 16 gas)
      • Deployed precompile
      • Draft EIP (proposed)
      • Measured (poqeth)
      Table view

      Calldata uses 16 gas per non-zero byte and excludes verification, public-key storage, aggregation and transaction overhead. Values are shown as the paper prints them; "≈" marks figures the paper gives as "about". SLH-DSA is not plotted: the paper gives only a bound ("an 8-KB signature alone costs over 100k calldata gas"). poqeth values use NIST-level-1 parameters. EIP-8051 assumes a 20,512-byte expanded verifier key.

      Interactive 5 · Table 5

      Each proposal fixes one part of the stack

      The taxonomy classifies migrations by control surface (who can authorize the change: issuer, host chain or ecosystem), layer (infrastructure, application overlay, bridge/rollup, base layer) and strategy (hybrid, PQ-native or encapsulation). Choose a proposal to see what it addresses and what it leaves open for a stablecoin. Most are drafts or roadmaps, not deployed guarantees.

        Properties & evidence

        What breaks, what each operation needs, what it costs

        Quantum-enabled attack patterns (Table 3)

        PatternProperty brokenStablecoin surface
        A. At-rest extractionEUF-CMA of signatureMint / treasury / admin / oracle / bridge keys
        B. On-spend raceEUF-CMA at key disclosureUser wallets and dormant balances
        C. Retroactive disclosureIND-CCA of past KEM/PKE; anonymity / hiding of privacy schemes (offline)Custody / compliance / API traffic; shielded stablecoin history
        D. Bridge forgeryThreshold / aggregate unforgeabilityWrapped supply and lockboxes
        E. Oracle / governanceReport/vote unforgeabilityPeg logic, liquidation, parameter updates
        F. Commitment equivocationCommitment bindingConfidential balances, proof-of-reserves
        G. ZK soundnessProof-system soundnessRollups, shielded pools, compliance proofs

        Requirements differ by operation (Table 8)

        OperationFrequencyValue concentrationPrimary constraint
        Treasury or recoveryLowVery highLong-term assurance, audit, recovery
        Mint, burn, adminLow–mediumVery highDirect verification, control continuity
        Bridge/oracleHighHighAggregation, bandwidth, latency
        Retail transferVery highLow per transferFee, wallet size, batching
        Private transferHighVariableProof size, proving time, disclosure policy

        Verification and data costs (Table 9, Appendix B)

        The paper collects these from the cited sources; they are not the authors' own measurements.

        MechanismKey / signatureVerification / data costEvidence type
        ECDSA/secp256k165-byte signature3,000 gas for ecrecover; about 1,040 calldata gasDeployed precompile and calldata schedule
        ML-DSA-44 calldata1,312-byte pk; 2,420-byte signatureAbout 38,720 calldata gas for non-zero signature bytesCalculation from FIPS 204 and EIP-2028
        EIP-805120,512-byte expanded verifier key; 2,420-byte signature4,500 gas proposedDraft specialized precompile
        EIP-81641,312-byte key; 2,420-byte signature50,000 intrinsic gas proposedDraft native account rule
        poqeth W-OTS+Parameter-specific222,114 on-chain; 126,095 Naysayer gasMeasured EVM implementation
        poqeth XMSSParameter-specific4,363,623 on-chain; 594,572 Naysayer gasMeasured EVM implementation
        poqeth SPHINCS+Parameter-specific11,617,690 on-chain; 693,721 Naysayer gasMeasured EVM implementation
        poqeth MAYOParameter-specific938,752,492 on-chain; 107,634,064 Naysayer gasMeasured EVM implementation
        SLH-DSAKilobytes to tens of kilobytesWorkload and implementation dependentNIST standard

        Table 7 also lists ML-DSA-65 (pk 1,952 B; sig 3,309 B; about 52.9k calldata gas) and Falcon-512 (pk 897 B; sig about 666 B; about 10.7k calldata gas).

        Cryptographic primitives and post-quantum status (Table 4)
        PrimitiveStablecoin-relevant functionPost-quantum candidates / status
        Hash functionsIdentities, Merkle trees, PoW, commitments, transaction identifiersRetain modern hashes with sufficient output length; 256-bit outputs for long-lived commitments and nullifiers
        Digital signaturesAccount authentication, admin actions, validator messages, contract callsML-DSA and SLH-DSA standardized; FN-DSA/Falcon and nine additional signature candidates in progress
        MultisignaturesCustody, governance, bridge committees, issuer administrationLattice multisignatures exist; compact aggregation, accountability, key rotation, wallet integration open
        Threshold signaturesDistributed custody, consensus, bridge attestation, treasury approvalLattice threshold signatures; production performance, identifiable abort, dynamic committees, custody integration open
        Randomness / VRFsLeader election, committee sampling, validator selectionSymmetric-key and lattice PQ VRFs; proof size and consensus integration limiting
        Key exchangePrivate channels, off-chain coordination, API confidentialityML-KEM standardized; HQC under standardization as backup; hybrid KEMs for staged migration
        Zero-knowledge proofsPrivacy, rollup validity, compliance proofs, reserve proofsSTARKs; lattice SNARKs and ZK; verifier cost and wallet proving open
        CommitmentsData binding, privacy, confidential balances, reserve proofsHash and lattice commitments; migrate together with the proof system
        Encryption / AEADNote encryption, private memos, off-chain communicationsML-KEM or hybrid KEM plus 256-bit AEAD; archived traffic remains subject to SNDL
        Exotic signaturesPrivacy, payment channels, swaps, anonymous authorizationLattice ring/blind/adaptor schemes; production readiness and aggregation open

        Cite

        BibTeX

        @inproceedings{chatzigiannis2026sokstablecoins,
          title     = {SoK: Stablecoins in the Quantum Era},
          author    = {Chatzigiannis, Panagiotis and Alamati, Navid and
                       Chakraborty, Suvradip and Le, Duc V.},
          booktitle = {ACM Conference on Post-Quantum and Quantum-based
                       Security (PQQS)},
          year      = {2026}
        }

        Code and data. This is a systematization paper and ships no code or dataset. Every number on this page is quoted from the paper, which cites standards, draft EIPs and BIPs, and published measurements.