PaperlayerView exact revision on arXiv

Source-linked AI summary

SoK: Stablecoins in the Quantum Era

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

arXiv:2610.02435v1cs.CR

TL;DR

Stablecoins rely on cryptographic controls across issuer, host-chain, bridge, and privacy systems, but their post-quantum dependencies and migration paths have not been systematized around stablecoin functions. This SoK maps those functions to threats and migration choices, finding that component upgrades alone do not resolve cross-organizational loss and continuity risks.

  • Problem

    Stablecoin systems combine many cryptographic control surfaces, but their post-quantum dependencies and migration paths remain under-systematized.

    Source: §1 · p. 1

  • Method

    The paper systematizes stablecoin threats, cryptographic dependencies, control surfaces, migration authorities, and deployment choices using research, standards, proposals, roadmaps, and issuer documentation.

    Source: §1 · pp. 1–2

  • Results

    Standardized signatures and key encapsulation provide necessary building blocks but do not cover full stablecoin functions, and migration authority often differs from the party bearing losses.

    Source: §5.1 · p. 10, §5.3 · p. 12

  • Takeaways & Limitations

    Migration should be assessed across stablecoin functions and layers, preserving authorization, redemption, supply integrity, finality, privacy, and required controls across the system.

    Source: §6 · p. 14

    The SoK aims for category-level rather than bibliographic completeness and is not a quantitative meta-analysis.

    Source: §1 · p. 2

Abstract

from arXiv · show

Stablecoins support payments, trading, collateral, and cross-chain settlement across the digital-asset ecosystem. They also concentrate value behind issuer, custody, upgrade, oracle, and bridge keys while inheriting the quantum vulnerabilities of host-chain accounts, consensus, rollups, and privacy systems. This paper presents a Systematization of Knowledge (SoK) on post-quantum stablecoins. We develop a stablecoin-specific threat model, map cryptographic dependencies to monetary control surfaces, and classify migration choices along three dimensions: who can authorize a change, where the change must occur, and whether it is hybrid, post-quantum native, or an encapsulation of a classical component. We emphasize an authority-liability gap: the party able to migrate a component is often different from the holders, exchanges, protocols, or issuers that bear the loss if it fails. We review the relevant cryptographic primitives, but distinguish general blockchain failures from their stablecoin-specific effects. We also examine recent blockchain and issuer-controlled interoperability proposals, and relate migration choices to redemption, continuity, and intervention requirements under current stablecoin regulation. Our findings identify open problems in aggregate and threshold authorization, operation-specific security levels and costs, dormant and wrapped supply, private and compliance-enabled transfers, and measurement of quantum-vulnerable stablecoin exposure.

1 Introduction

Stablecoins combine monetary control with host-chain, bridge, custody, and user-key dependencies, making quantum migration a multi-actor problem in which migration authority and loss bearing can diverge. This SoK maps those dependencies and migration choices, while distinguishing its stablecoin-specific focus from adjacent SoKs and blockchain migration proposals.

1 Introduction

  • Stablecoin quantum exposure reaches minting, redemption, liquidity, and long-lived issuer, custody, oracle, and bridge keys, while the actors able to migrate components may differ from those bearing losses.The paper frames stablecoins as a concrete instance of multi-actor cryptographic migration because monetary claims compose issuer privileges with host-chain authentication, finality, bridges, and user-held keys.Source: §1 · pp. 1–2
  • Migration is a multi-year coordination task, and a cryptographic inventory also serves as a financial-control inventory linking keys and primitives to supply, redemption, privacy, and governance.The paper reviews research, standards, guidance, proposals, roadmaps, and issuer documentation, organizing evidence by stablecoin functions and control surfaces.Source: §1 · pp. 1–2
  • The SoK maps quantum capabilities to stablecoin-specific threats, cryptographic dependencies, migration authority, deployment layers, and migration strategies.Its scope includes minting, reserve management, transfers, bridge-backed supply, privacy, finality, and redemption, rather than a new primitive or CRQC-date prediction.Source: §1 · p. 2
  • The SoK claims category-level rather than bibliographic completeness, targeting distinct control surfaces, attack classes, and migration authorities rather than every paper or implementation.New schemes may change candidate mechanisms without necessarily changing the threat and migration categories.Source: §1 · p. 2

1.1 Related Work

  • Adjacent stablecoin SoKs cover payments, composability, and tokenization, while blockchain and post-quantum surveys cover related systems and primitives; they do not systematize quantum migration across stablecoin control paths.The paper compares protocol and issuer-controlled proposals as complementary pieces, noting that none alone migrates the entire stablecoin stack.Source: §1.1 · p. 2, §1 · p. 2

2 Background

Stablecoin quantum risk spans three coupled layers: control, settlement, and claims, with migration authority often separated from financial liability. The background connects stablecoin designs and regulatory duties to the quantum vulnerabilities and post-quantum alternatives of their cryptographic components.

2.1 Stablecoin Designs and Control Surfaces

  • Fiat-backed, crypto-collateralized, algorithmic, and bridged stablecoins place quantum-sensitive authority in issuer roles, governance and oracle controls, or bridge attestations that can create unbacked wrapped supply.The specific dependencies vary: centralized issuer keys and contract roles; collateral, liquidation, and governance mechanisms; or bridge signers, finality, relayers, and destination contracts.Source: §2.1 · p. 3

2.2 Control, Settlement, and Claims

  • Stablecoins couple a control plane that governs supply, a settlement substrate that authenticates transactions, and a claim-and-distribution layer whose participants may bear losses without controlling the failed component.The control plane includes issuer, governance, oracle, and bridge privileges; settlement includes accounts, consensus, rollups, and cross-chain verification.Source: §2.2 · p. 3, Table 1 · p. 4
  • Migration authority and financial liability can fall to different organizations, so a technically available change may lack the incentive, legal authority, or coordination needed to protect the main loss bearer.Table 1 makes this authority–liability gap explicit.Source: §2.2 · p. 3, Table 1 · p. 4

2.3 Regulatory Constraints on Migration

  • Migration must preserve redemption, reserve control, audit evidence, continuity, and intervention capabilities; abandoning old accounts or removing issuer controls may conflict with regulatory duties.The cited regulatory provisions include redemption and continuity requirements and lawful-order capabilities to seize, freeze, burn, or prevent transfers.Source: §2.3 · pp. 3–4

2.4 Cryptographic Primitives, Quantum Vulnerabilities, and Post-Quantum Candidates

  • Shor’s algorithm threatens public-key signatures and related discrete-log or pairing constructions, while Grover-style search reduces symmetric and hash security margins; issuer and bridge keys are often long-lived and visible.NIST-standardized ML-DSA and SLH-DSA and ongoing FN-DSA standardization offer signature candidates, but none is a drop-in replacement for BLS-style non-interactive aggregation.Source: §2.4 · p. 4
  • Threshold ECDSA, Schnorr, and BLS remain vulnerable because recovering the aggregate secret does not require compromising every share, while post-quantum threshold deployment still needs accountability, rotation, recovery, and audit support.Lattice multisignatures and threshold schemes, including work on threshold ML-DSA, narrow the primitive gap but leave stablecoin deployment requirements.Source: §2.4 · p. 5
  • Issuer–custodian and other operational channels face store-now-decrypt-later exposure under Shor-vulnerable key exchange, while hybrid KEMs can be deployed before host-chain account formats change.ML-KEM is standardized, and the cited TLS 1.3 hybrid Internet-Draft provides a migration path while remaining work in progress.Source: §2.4 · p. 5

2.4.1 Privacy and Advanced Functionality.

  • Quantum-vulnerable proof and commitment systems can undermine private balances, reserve proofs, or rollup transitions, while post-quantum alternatives trade among proof size, recursion, and verifier cost.The paper identifies STARKs as relying primarily on hash commitments and FRI-style testing, and treats migration as a proof-and-commitment-stack problem.Source: §2.4.1 · p. 5

3 Threat Model and Quantum Attack Surface

The threat model combines classical and quantum adversary capabilities with a planning horizon, then traces how quantum attacks affect stablecoin controls across application, blockchain, and privacy layers. Key forgery, bridge and oracle manipulation, proof failure, and retroactive disclosure can produce distinct harms that propagate across those layers.

3.1 Adversary Model and Capabilities

  • The adversary model separates classical capabilities, quantum capabilities, and the time horizon over which they accumulate.It treats public-ledger observation, transaction submission, and network archival as realistic classical abilities; the quantum adversary additionally has CRQC access, while Simon-style attacks are mostly theoretical for stablecoins.Source: §3.1 · p. 6

3.2 Stablecoin Attack Patterns

  • At-rest Shor attacks target already exposed high-value keys, while on-spend attacks race to replace a transaction after its public key is revealed.Exposed issuer, bridge, oracle, custody, and validator keys concentrate control; on-spend extraction primarily threatens user holdings, with potentially total loss for an affected user.Source: §3.2 · pp. 6–7
  • Store-now-decrypt-later attacks can expose archived issuer communications and reconstruct historical private transfers, causing informational harms that reissuance or freezing cannot repair.Off-chain recording requires network visibility, whereas on-chain artifacts can be archived by any public-ledger observer; the affected privacy construction must be assessed directly.Source: §3.2 · p. 7
  • Forged bridge attestations can create unbacked wrapped supply or release native value without a corresponding burn, with losses potentially spreading through exchanges and DeFi.For issuer-backed interoperability such as Circle xReserve, reserve contracts, API attestations, and partner-chain mint/burn logic jointly determine issuance and redemption.Source: §3.2 · p. 7
  • Forged oracle or governance inputs can trigger liquidations or alter peg-maintenance modules, while commitment equivocation and proof soundness failures can falsify balances or state transitions.Discrete-log breaks can undermine solvency commitments and confidential balances; proof failures can affect rollups, shielded pools, and compliance or proof-of-reserves claims.Source: §3.2 · p. 7

3.3 Layered Composition of Threats

  • The layered view distinguishes concentrated application controls, inherited blockchain authentication and finality, and privacy or metadata risks in off-chain channels and private-payment systems.A stablecoin may remain exposed through host-chain signatures, bridge or rollup verification, or privacy mechanisms even when issuer controls are post-quantum secure.Source: §3.3 · pp. 7–8
  • Lower-layer quantum risk can propagate upward, while issuers can reduce some exposure by hardening custody, administration, bridges, oracles, and off-chain communications before base-layer migration.The actor able to migrate one layer may not control the layer that fails or bear the resulting loss.Source: §3.3 · p. 8

4 Taxonomy and Migration Strategies

The taxonomy classifies migration by who controls a change, where it occurs, and how post-quantum protection is introduced. Applying those dimensions to proposals and stablecoin designs exposes partial migrations, cross-layer dependencies, and gaps in operational cost evidence.

4 Taxonomy and Migration Strategies

  • The taxonomy classifies migration by control surface, deployment layer, and cryptographic strategy, exposing proposals that leave the responsible actor, lower-layer dependency, or legacy state unspecified.Strategies are hybrid, PQ-native, or encapsulation; encapsulation can be deployed without changing the original token but remains dependent on original administration, host-chain, bridge, or finality assumptions.Source: §4 · pp. 8–9

4.1 Current Proposals and Deployment Directions

  • The migration sequence inventories monetary-function dependencies and responsible actors, hardens issuer infrastructure, adds application and bridge safeguards, adopts host-chain agility, and defines rules for dormant and wrapped state.Dormant-state options include voluntary migration, redemption and reissuance, claim contracts, freezing after a deadline, or post-quantum recovery; rollups and wrapped supply need separate migration and sunset rules.Source: §4 · p. 9, §4.1 · pp. 9–10
  • Recent proposals address different parts of migration; Circle’s plan separates issuer, Arc-chain, and third-party responsibilities, explicitly deferring several HSM, wallet, immutable-contract, and host-chain tasks.Ethereum gas figures also depend on execution model: specialized-precompile and intrinsic protocol-cost proposals are not ordinary Solidity ML-DSA verification, while poqeth measures full EVM verification.Source: §4.1 · p. 9, Table 5 · p. 10

4.2 Representative Stablecoin Designs and Deployments

  • Representative stablecoin designs inherit lower-layer cryptography while concentrating stablecoin-specific risk in privileged keys, bridge attestations, oracles, custody, and upgrade paths.The table applies the taxonomy across designs rather than introducing a fourth dimension.Source: §4.2 · p. 10
  • Available measurements support some size and verifier-cost estimates, but do not evaluate complete stablecoin operations such as mint authorization, bridge redemption, private transfers, or rollup settlement.Native verification latency may be acceptable for low-frequency issuer and custody actions, while calldata, data availability, aggregation, and verifier support dominate several other costs.Source: §4.2 · p. 10

5 Research Insights, Gaps, and Open Problems

Post-quantum stablecoin security requires more than replacing signature schemes: the open problems span authorization, operation-specific costs, cross-layer migration, privacy, measurement, and regulatory continuity.

5.1 Standardized Primitives Do Not Cover Stablecoin Functions

  • Standardized signatures and key encapsulation support issuer, wallet, and encrypted-channel tasks, but stablecoin migration must cover whole functions rather than isolated primitives.Requirements differ across issuer and custody control, bridge and oracle committees, private or compliance-enabled transfers, and host-chain or rollup settlement.Source: §5.1 · p. 10
  • Production authorization suites remain incomplete across stablecoin workloads; implementation hardening and aggregation must address custody-hardware constraints and the amplified costs of independent signatures.Those costs include calldata, data availability, and verifier work across bridge messages, oracle updates, validator votes, and rollup settlement.Source: §5.1 · p. 11

5.2 Security Level and Cost Depend on the Stablecoin Operation

  • Security levels should reflect operation-specific value, lifetime, exposure, frequency, migration latency, and failure consequences rather than inherit unrelated conventions.A rare treasury recovery key, continuous oracle updates, retail transfers, and high-value bridge attestations present different workloads.Source: §5.2 · pp. 11–12
  • Primitive cost anchors do not optimize full operations: benchmarks must include aggregation, storage, execution, recovery, and deployment-specific verifier placement.Liquid’s opt-in verifier for issued assets avoids a consensus change, while the peg, Confidential Assets commitments, and block-signing consensus remain classical.Source: §5.2 · p. 12

5.3 The Authority–Liability Gap Creates Residual and Legacy Risk

  • Migration authority and loss-bearing cross layers, so one component’s upgrade leaves residual exposure and old wrapped claims require explicit route, redemption, and loss rules.Migration analysis should also specify authoritative checkpoints, user claims, deadlines, appeals, and recovery.Source: §5.3 · pp. 12–13
  • Dormant balances pose a governance trade-off: leaving them preserves ownership but retains quantum exposure, while freezes or recovery alter control and may affect redemption and due process.The paper calls for migration mechanisms to specify notice, ownership proof, deadlines, recovery routes, and effects on redemption.Source: §5.3 · p. 13

5.4 Privacy, Measurement, and Regulation Must Become Testable

  • Private stablecoins use distinct cryptographic stacks, and the planned TEE-based design retains a classical dependency on vendor-controlled enclave attestation and certificates.The described designs include FHE over encrypted balances, note-based commitments and proofs, and TEE execution with transaction and state encryption.Source: §5.4 · p. 13
  • Research should measure exposed value by dependency and representation, and test cryptographic readiness alongside redemption, reserve control, intervention, and historical evidence.The research agenda also calls for migration protocols for dormant and wrapped supply, efficient aggregate and threshold attestations, and PQ-friendly private transfers.Source: §5.4 · p. 13

6 Conclusion

Post-quantum stablecoin migration is a system-wide problem: control of vulnerable components is fragmented, and the party able to change a component may differ from those bearing its losses. Migration must preserve redemption, reserve control, audit evidence, and intervention while addressing unresolved technical and supply-management questions.

6 Conclusion

  • The authority–liability gap separates component-level migration authority from the holders, exchanges, protocols, or issuers that may bear losses.Stablecoins’ host-chain, rollup, and privacy dependencies mean no single actor can complete migration alone.Source: §6 · pp. 13–14
  • A practical transition combines a function-level cryptographic inventory with issuer, contract, bridge, oracle, and host-chain safeguards, plus explicit treatment of dormant and wrapped supply.Standardized KEMs and signatures are building blocks, not replacements for aggregate bridge attestations, threshold custody, private transfers, rollup proofs, or recovery governance.Source: §6 · p. 14
  • Regulatory requirements constrain migration to preserve redemption continuity, reserve control, audit evidence, and intervention capabilities.Source: §6 · p. 14
  • The research agenda calls for complete-operation benchmarks, models of layered risk and migration authority, efficient aggregate and threshold authorization, and post-quantum privacy and compliance mechanisms.It also identifies protocols for dormant balances and legacy wrapped routes, and empirical measurement of quantum-vulnerable stablecoin supply; progress is measured across authorization, redemption, supply integrity, finality, privacy, and required controls.Source: §6 · p. 14

A Supplementary Cryptographic Details

The supplementary material defines cryptographic primitives and summarizes their quantum vulnerabilities and post-quantum alternatives. It highlights implications for blockchain functions including randomness, signatures, custody, and encrypted communications.

Hash functions

  • Grover reduces hash preimage security quadratically, but 256-bit hashes retain approximately 128-bit post-quantum security and require no primitive change.BHT gives Θ(2^λ/3) collision complexity assuming quantum RAM, while the realistic parallel, low-memory model retains the classical 2^λ/2 collision bound.Source: A Supplementary Cryptographic Details · p. 17

Digital signatures

  • Shor breaks deployed DLP- and factoring-based blockchain signatures, including ECDSA, Schnorr, EdDSA, RSA-PSS, and BLS, and can undermine historical audit evidence.Issuer, treasury, bridge, and oracle keys are almost always in the at-rest regime described by the Google Quantum AI estimate [11].Source: A Supplementary Cryptographic Details · p. 17
  • ML-DSA (FIPS 204) is presented as the default for issuer administration and oracle workloads, while SLH-DSA (FIPS 205) suits cold-path treasury actions.Falcon is compact at approximately 666 B but has side-channel-sensitive Gaussian sampling; none of these candidates supports non-interactive aggregation comparable to BLS.Source: A Supplementary Cryptographic Details · p. 17

Multi-signatures and threshold signatures

  • Shor recovers the aggregate secret key of threshold ECDSA, Schnorr, or BLS directly from its public key, nullifying the threshold policy.Lattice-based multi- and threshold-signature constructions exist, but production gaps remain in dynamic committees, identifiable abort, HSM/MPC integration, and aggregate sizes within calldata budgets.Source: A Supplementary Cryptographic Details · p. 17

Key exchange and authenticated channels

  • Shor breaks classical DH/ECDH, ECIES, and RSA-OAEP, enabling store-now-decrypt-later exposure of archived issuer–custodian communications.Hybrid KEMs such as X25519+ML-KEM-768 in TLS 1.3 remain secure as long as either component does; ML-KEM is standardized in FIPS 203.Source: A Supplementary Cryptographic Details · p. 17

Randomness, VRFs, and leader election

  • Current EC-VRFs lose pseudorandomness under Shor because their security relies on discrete logarithms, while post-quantum VRFs are slower or larger and light-client committee-sampling integration remains unsolved.Symmetric-primitive VRFs have proofs of tens of KB; ring-signature-based PQ VRFs rely on lattice assumptions.Source: A Supplementary Cryptographic Details · pp. 17–18

A.0.1 Cryptography for Privacy and Advanced Functionality.

The appendix reviews quantum effects on proof, commitment, and symmetric-encryption systems used in privacy and advanced functionality. It contrasts constructions whose soundness or binding relies on discrete logarithms or pairings with hash-based and lattice-based alternatives.

Zero-knowledge proofs

  • Shor breaks the soundness of Groth16, PLONK with KZG, Bulletproofs, and Halo/Halo2, while STARK soundness is treated as post-quantum secure today.The cited failure can permit false rollup state transitions or shielded notes minted from nothing; quantum zero-knowledge generally survives with a uniform random tape, but Fiat–Shamir requires QROM re-analysis.Source: §A.0.1 · p. 18
  • STARKs and hash-based IOPs offer transparent setup and post-quantum soundness with larger proofs, while lattice ZK supports range and equality proofs for confidential stablecoin transfers.STARK proofs are approximately 50–200 KB and can be amortized via recursion; lattice-based SNARK constructions include publicly verifiable, preprocessing, and recursive proofs.Source: §A.0.1 · p. 18

Commitment schemes

  • Shor breaks the binding of Pedersen commitments, enabling equivocation, while their statistical hiding property survives.Hash-based commitments remain statistically binding in the random-oracle model, with binding degrading to approximately 2^λ/2 under Grover; lattice SIS commitments are homomorphic.Source: §A.0.1 · p. 18

Encryption and AEAD

  • Grover-style key search leaves AES-128 with approximately 64-bit quantum security and AES-256 with approximately 128-bit security.Under superposition queries to a keyed primitive—an unrealistic model for blockchain settings—Simon’s algorithm breaks several MAC and mode constructions, including CBC-MAC [64].Source: §A.0.1 · p. 18

B Cost Evidence and Benchmarking Details

The appendix cautions that post-quantum verification and data-cost figures depend on execution model. It proposes benchmarking complete stablecoin operations and reporting operational as well as cryptographic costs.

B Cost Evidence and Benchmarking Details

  • Table 9 separates deployed precompiles, calldata-only calculations, draft protocol costs, and measured ordinary-EVM verification, so its values are not directly comparable across execution models.The EIP figures are proposals, while poqeth gas values are measured for specific schemes and NIST-level-1 parameter choices.Source: B Cost Evidence and Benchmarking Details · p. 18, Table 9 · p. 19
  • Stablecoin benchmarks should cover complete operations, from mint or burn authorization and threshold withdrawals to bridge redemption, oracle retries, migration claims, private transfers, and rollup settlement.Source: B Cost Evidence and Benchmarking Details · p. 18
  • Each benchmark should report resource, performance, integration, and failure-behavior measures, including bytes, gas or verifier cost, data availability, throughput, latency, HSM/MPC support, wallet memory, audit evidence, and signer or relayer failures.Source: B Cost Evidence and Benchmarking Details · p. 18
Loading 2610.02435v1…