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.
In three numbers
Every figure below is quoted from the paper, which in turn cites standards, draft EIPs and published measurements.
2,420 bytes against 65 bytes of calldata. The comparison leaves out aggregation, public-key storage, contract execution and failure recovery (§5.2).
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).
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
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:
Mint and burn keys, treasury, pause and blacklist roles, proxy upgrades, governance, oracle administration, bridge attestation.
Host-chain accounts, validator and finality signatures, data availability, rollup proofs, sequencers, light clients, cross-chain verification.
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$.
| Source | Requirement | Migration consequence |
|---|---|---|
| MiCA Art. 34 | Governance, ICT controls, continuity | Key and contract migration must be inventoried, tested, and auditable. |
| MiCA Arts. 46–47, 49, 55 | Recovery, orderly redemption, par redeemability | Freezes, reissuance, and claim contracts must preserve timely and equitable redemption. |
| GENIUS Act §4 | Reserves, disclosed redemption, operational/IT risk | A PQ incident is an operational-risk and disclosure event, not only a protocol bug. |
| GENIUS Act §4(a)(6) and OCC proposals | Lawful orders, custody, audit, AML/sanctions | Migration must preserve required freeze, burn, screening, blocking, and reporting controls. |
Interactive 1 · Table 1
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
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.
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
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.
| Source | Target | Logical qubits | Toffoli gates |
|---|---|---|---|
| Babbush et al. | secp256k1 | at most about 1,200 | 90 million |
| Babbush et al. | secp256k1 | about 1,450 | 70 million |
| Luo et al. | 256-bit prime-field curve | 835 | — |
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
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.
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
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
| Pattern | Property broken | Stablecoin surface |
|---|---|---|
| A. At-rest extraction | EUF-CMA of signature | Mint / treasury / admin / oracle / bridge keys |
| B. On-spend race | EUF-CMA at key disclosure | User wallets and dormant balances |
| C. Retroactive disclosure | IND-CCA of past KEM/PKE; anonymity / hiding of privacy schemes (offline) | Custody / compliance / API traffic; shielded stablecoin history |
| D. Bridge forgery | Threshold / aggregate unforgeability | Wrapped supply and lockboxes |
| E. Oracle / governance | Report/vote unforgeability | Peg logic, liquidation, parameter updates |
| F. Commitment equivocation | Commitment binding | Confidential balances, proof-of-reserves |
| G. ZK soundness | Proof-system soundness | Rollups, shielded pools, compliance proofs |
| Operation | Frequency | Value concentration | Primary constraint |
|---|---|---|---|
| Treasury or recovery | Low | Very high | Long-term assurance, audit, recovery |
| Mint, burn, admin | Low–medium | Very high | Direct verification, control continuity |
| Bridge/oracle | High | High | Aggregation, bandwidth, latency |
| Retail transfer | Very high | Low per transfer | Fee, wallet size, batching |
| Private transfer | High | Variable | Proof size, proving time, disclosure policy |
The paper collects these from the cited sources; they are not the authors' own measurements.
| Mechanism | Key / signature | Verification / data cost | Evidence type |
|---|---|---|---|
| ECDSA/secp256k1 | 65-byte signature | 3,000 gas for ecrecover; about 1,040 calldata gas | Deployed precompile and calldata schedule |
| ML-DSA-44 calldata | 1,312-byte pk; 2,420-byte signature | About 38,720 calldata gas for non-zero signature bytes | Calculation from FIPS 204 and EIP-2028 |
| EIP-8051 | 20,512-byte expanded verifier key; 2,420-byte signature | 4,500 gas proposed | Draft specialized precompile |
| EIP-8164 | 1,312-byte key; 2,420-byte signature | 50,000 intrinsic gas proposed | Draft native account rule |
| poqeth W-OTS+ | Parameter-specific | 222,114 on-chain; 126,095 Naysayer gas | Measured EVM implementation |
| poqeth XMSS | Parameter-specific | 4,363,623 on-chain; 594,572 Naysayer gas | Measured EVM implementation |
| poqeth SPHINCS+ | Parameter-specific | 11,617,690 on-chain; 693,721 Naysayer gas | Measured EVM implementation |
| poqeth MAYO | Parameter-specific | 938,752,492 on-chain; 107,634,064 Naysayer gas | Measured EVM implementation |
| SLH-DSA | Kilobytes to tens of kilobytes | Workload and implementation dependent | NIST 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).
| Primitive | Stablecoin-relevant function | Post-quantum candidates / status |
|---|---|---|
| Hash functions | Identities, Merkle trees, PoW, commitments, transaction identifiers | Retain modern hashes with sufficient output length; 256-bit outputs for long-lived commitments and nullifiers |
| Digital signatures | Account authentication, admin actions, validator messages, contract calls | ML-DSA and SLH-DSA standardized; FN-DSA/Falcon and nine additional signature candidates in progress |
| Multisignatures | Custody, governance, bridge committees, issuer administration | Lattice multisignatures exist; compact aggregation, accountability, key rotation, wallet integration open |
| Threshold signatures | Distributed custody, consensus, bridge attestation, treasury approval | Lattice threshold signatures; production performance, identifiable abort, dynamic committees, custody integration open |
| Randomness / VRFs | Leader election, committee sampling, validator selection | Symmetric-key and lattice PQ VRFs; proof size and consensus integration limiting |
| Key exchange | Private channels, off-chain coordination, API confidentiality | ML-KEM standardized; HQC under standardization as backup; hybrid KEMs for staged migration |
| Zero-knowledge proofs | Privacy, rollup validity, compliance proofs, reserve proofs | STARKs; lattice SNARKs and ZK; verifier cost and wallet proving open |
| Commitments | Data binding, privacy, confidential balances, reserve proofs | Hash and lattice commitments; migrate together with the proof system |
| Encryption / AEAD | Note encryption, private memos, off-chain communications | ML-KEM or hybrid KEM plus 256-bit AEAD; archived traffic remains subject to SNDL |
| Exotic signatures | Privacy, payment channels, swaps, anonymous authorization | Lattice ring/blind/adaptor schemes; production readiness and aggregation open |
Cite
@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.