Technical reference

Methodologies

Formal models and quantitative methods underlying the quantum exposure analysis, risk quantification, and network cascade simulations on this site.

Section I

Quantum Threat Model

A Cryptographically Relevant Quantum Computer (CRQC) is a fault-tolerant quantum device capable of running Shor's algorithm at the scale required to break elliptic curve cryptography. Recent resource estimates from Google Quantum AI (Babbush et al., March 2026) place the requirement at approximately 4,000 logical qubits for attacking ECDSA secp256k1 within operationally relevant time windows, with consensus timelines spanning 2030 to 2040.

We model three distinct attack modes, each with different adversary constraints and time budgets:

  • At-rest (key-exposed): The public key is permanently on-chain. The attacker has no time pressure and can run the quantum computation offline with unlimited attempts.
  • On-spend (mempool interception): The attacker intercepts a transaction in the mempool, extracts the public key from the signature, and must derive the private key before the transaction is confirmed (seconds to minutes).
  • On-setup (key generation): Compromise during key generation or derivation. Requires the attacker to be present at wallet creation time.

The primary vulnerability is ECDSA over secp256k1: Shor's algorithm solves the Elliptic Curve Discrete Logarithm Problem (ECDLP) in polynomial time, deriving the private key from any exposed public key. A secondary vulnerability affects BLS12-381 signatures used in Ethereum's Proof of Stake consensus and KZG polynomial commitments for EIP-4844 blob transactions, exposing validator signing keys and data availability proofs to the same class of quantum attack.

Section II

FAIR Risk Quantification

We apply the Factor Analysis of Information Risk (FAIR) framework to translate quantum threat probabilities into dollar-denominated loss estimates. The core quantity is Annual Loss Expectancy, computed as the product of three components: the probability that a CRQC becomes operational in a given year, the conditional probability that an attacker successfully exploits it against a specific target, and the magnitude of loss if the attack succeeds.

ALE(e, T) = P(CRQC by T) · P(attack | CRQC) · L_magnitude(e) · [1 − P(migration(e) by T)]

Tail risk is captured through Monte Carlo simulation (10,000 trials per assessment) with Bayesian updates to CRQC arrival probability as new research milestones emerge. From the resulting loss distribution we extract two measures:

  • VaR 99.9%: Value at Risk at the 99.9th percentile — the worst-case loss exceeded only 0.1% of the time.
  • ES 99.9%: Expected Shortfall (Conditional VaR) — the average of all losses exceeding the VaR threshold, capturing the shape of the tail beyond the quantile.
VaR_q(L) = inf{ ℓ ∈ ℝ : F_L(ℓ) ≥ q } ES_q(L) = 1/(1−q) · ∫_q^1 VaR_u(L) du

Loss Exceedance Curves plot the probability of exceeding various loss thresholds across the full distribution, giving a continuous view of risk rather than a single point estimate. The FAIR decomposition follows Freund and Jones (2014), with simulation calibration methods drawn from Hubbard and Seiersen (2016).

Section III

Network Cascade Model

Protocol dependencies in DeFi create contagion channels analogous to interbank payment networks. We adapt the Eisenberg-Noe (2001) clearing vector framework, originally developed for interbank obligations, to model how a quantum compromise of one protocol's admin keys propagates losses through the dependency graph. The clearing vector is found by fixed-point iteration:

d* = ([a_NIB + Π'·d*] ∨ 0) ∧ d̄
  • a_i^NIB — exogenous (non-DeFi) asset value of protocol i
  • Π' — proportionality matrix: share of obligations owed to each counterparty (Eisenberg-Noe 2001)
  • d̄ — vector of total nominal obligations per node
  • ∨ — componentwise maximum (limited liability: payments ≥ 0)
  • ∧ — componentwise minimum (pays at most what is promised)

System-wide fragility is measured via the Gai-Kapadia (2010) resilience indicator, which determines whether a local shock remains contained or triggers a global cascade. The indicator undergoes a sharp phase transition at zero:

R = 1 − (1/z) · Σ_{j,k} j·k·v_j·p_jk
  • j — in-degree: number of incoming dependency edges
  • k — out-degree: number of outgoing dependency edges
  • v_j — vulnerability probability: P(K_i / A_i^IB < 1/j), i.e., node with in-degree j cannot absorb one counterparty failure
  • p_jk — joint degree distribution (fraction of nodes with in-degree j and out-degree k)
  • z — average degree: Σ_{j,k} j·p_jk
  • R > 0: resilient — shock stays local; R ≤ 0: phase transition — system-wide cascade

Beyond the clearing vector, we apply the Cont-Moussa iterative capital cascade to track cascade depth -- the number of successive rounds of defaults triggered by the initial shock. Fire-sale amplification is incorporated via the Brunnermeier and Pedersen (2009) liquidity spiral multiplier, which models the feedback loop between declining asset prices and tightening funding constraints. The combined framework follows Fouque and Langsam, Handbook on Systemic Risk, Chapters 11-13.

Section IV

Blast Radius Estimation

Blast radius quantifies the total economic damage from a quantum key compromise, from the directly affected protocol through all downstream contagion. We compute a three-point estimate to bound the uncertainty:

B_low(e) = Σ_{(e,t)∈E} ℓ_et · p_et B_central(e) = B_low(e) + Σ_t B_low(t) · p_{e→t} B_high(e) = DI(e,c,E) = Σ_{j∈V} [c_0(j) − c_{n−1}(j)]
  • ℓ_et — direct exposure (TVL at risk) on edge e → t
  • p_et — cascade probability on edge e → t; empirical rate of contagion given upstream default
  • B_low — lower bound: model-free, depends only on observable TVL and direct edges
  • B_central — central estimate: first- plus second-order contagion; requires full dependency graph
  • B_high = DI(e) — upper bound: structural Default Impact via Cont-Moussa capital cascade (Fouque Eq. 13.5)
  • c_0(j) — capital buffer of node j before cascade; c_{n−1}(j) — buffer after convergence

The Monte Carlo simulation yields a full percentile distribution of blast radius (5th, 25th, 50th, 75th, 95th), reflecting uncertainty in both the initial loss magnitude and the network propagation dynamics. The Contagion Index, adapted from Fouque Eq. 13.8, measures stress-conditioned Default Impact: the expected cascade depth under simultaneous macro shocks (liquidity withdrawal, correlated depegs, oracle failure).

B_low is model-free and depends only on observable TVL. B_central requires the full dependency graph and Eisenberg-Noe iteration. B_high applies the full Cont-Moussa capital cascade and diverges as R → 0, where the 1/R term signals the onset of systemic collapse.

Section V

Data Sources

All exposure assessments, risk quantification, and cascade simulations are built on publicly available on-chain and off-chain data. Primary sources include:

  • On-chain transaction data: Google BigQuery public datasets (crypto_bitcoin, crypto_ethereum) for full transaction history and public key extraction.
  • DeFi TVL and protocol data: DeFiLlama API for total value locked, protocol dependencies, and treasury compositions.
  • Layer 2 data: L2BEAT for rollup TVL, bridge contracts, and security model classification.
  • Multisig governance: Safe Transaction Service API for multisig signer sets, threshold configurations, and admin key identification.
  • Contract classification: Etherscan V2 API for contract source verification, proxy pattern detection, and deployer attribution.
  • Validator data: beaconcha.in and rated.network for Ethereum PoS validator set composition, BLS key exposure, and staking distribution.
  • Bitcoin quantum exposure: Project Eleven Bitcoin Risq List for addresses with exposed public keys and associated balances.
Section VI

Exposure Derivation

  • ETH staked (beacon chain): 37.0M ETH — Fig 12, p.28, Claims C52-C54. BLS12-381 signatures also vulnerable to Shor's algorithm.
  • ETH in L2 / bridge TVS: 15.0M ETH — Fig 11, p.27, Claim C51. Subsumes 2.5M in admin-vulnerable contracts.
  • ETH in EOAs + contracts: 48.0M ETH — derived. 120.2M - 37M - 15M = 68.2M. 70% conservative exposure = 48M.
  • Total ETH exposed: 100M ETH (83% of ~120.2M supply).
  • BTC exposed: 6.9M BTC — Fig 5, p.14.
  • Stablecoin / RWA admin-key exposure: ~$200B — Fig 10, pp.25-26, Claim C48.

Non-overlap proof: The three ETH exposure categories are provably disjoint. EOAs and contracts are distinct account types in the EVM specification. The beacon deposit contract is immutable and excluded from the upgradeable-proxy set in Fig 9. L2/bridge TVS resides in bridge contracts, disjoint from EOA current-balance measurements.

Migration path — Account Abstraction: ERC-4337 and EIP-7702 offer a migration to quantum-resistant signature schemes (e.g., CRYSTALS-Dilithium, SPHINCS+) without requiring an Ethereum hard fork. Users could transition to smart contract wallets with post-quantum signatures before a cryptographically relevant quantum computer exists.

Section VII

Limitations & Caveats

  • The 70% exposure estimate for ETH in EOAs + contracts is a conservative lower-bound assumption, not a direct census measurement; true exposure could be higher.
  • USD-denominated totals rely on CoinGecko pricing, which introduces a ~1hr staleness window between market moves and displayed exposure figures.
  • The address and entity database is a sample, not a census of every exposed wallet, admin key, protocol, or dependency on-chain.
  • Monte Carlo scoring outputs should be read with confidence intervals and uncertainty bands; ALE, VaR, and ES are estimates, not exact forecasts.
  • Protocol classifications are based on public documentation, deployed contracts, and observed admin configurations, and may lag newly shipped or undisclosed changes.
  • Cascade and blast-radius figures depend on model assumptions about dependency edges, liquidity transmission, recovery behavior, and failure ordering; real-world contagion may be weaker or stronger.
Section VIII

Bitcoin Address-Type Taxonomy

Bitcoin's quantum exposure depends on address type. Not all BTC is equally at risk — approximately 65.2% of circulating supply (~12.9M BTC) has never exposed its public key and remains quantum-safe until spent.

  • P2PK (Pay-to-Public-Key): ~1.7M BTC. The public key IS the scriptPubKey — always exposed regardless of spend history. Predominantly early Bitcoin coinbase rewards (2009–2012). Attack vector: at-rest.
  • P2PKH (Pay-to-Public-Key-Hash): Most common legacy format. Public key hidden behind RIPEMD-160(SHA-256(pubkey)) until first spend. Once spent, pubkey is published in the scriptSig. Unspent P2PKH addresses are quantum-safe.
  • P2SH (Pay-to-Script-Hash): Multisig and wrapped formats. Public keys exposed upon spending via the redeemScript. P2SH-wrapped multisig (P2MS) exposes all signer public keys.
  • P2WPKH / P2WSH (Native SegWit): Same exposure model as P2PKH — public key exposed on first spend via the witness field.
  • P2TR (Taproot): Key-path spends expose the internal public key. Script-path spends may not expose the key-path public key, but any key used in the executed script branch is revealed. Address-level classification requires on-chain spend analysis.

Composition: 1.7M P2PK (always exposed) + reused P2PKH/P2SH/P2TR + P2MS = 6.9M BTC total (34.8% of ~19.8M circulating supply). Source: Fig 5, p.14 — full-chain BigQuery UTXO analysis (census, not sample).

References

Bibliography

  1. Babbush, R. et al. (2026). Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities. Google Quantum AI.
  2. Brunnermeier, M. & Pedersen, L. (2009). Market Liquidity and Funding Liquidity. Review of Financial Studies, 22(6), 2201-2238.
  3. Eisenberg, L. & Noe, T. (2001). Systemic Risk in Financial Systems. Management Science, 47(2), 236-249.
  4. Fouque, J.-P. & Langsam, J. (Eds.) (2013). Handbook on Systemic Risk. Cambridge University Press.
  5. Freund, J. & Jones, J. (2014). Measuring and Managing Information Risk: A FAIR Approach. Butterworth-Heinemann.
  6. Gai, P. & Kapadia, S. (2010). Contagion in Financial Networks. Bank of England Working Paper No. 383.
  7. Hubbard, D. & Seiersen, R. (2016). How to Measure Anything in Cybersecurity Risk. Wiley.
  8. McNeil, A., Frey, R. & Embrechts, P. (2005). Quantitative Risk Management: Concepts, Techniques and Tools. Princeton University Press.