Methodology
This page states how the forecast is produced, in enough detail to disagree with it. Every figure below is either read live from the running model's configuration or cited to a named source at the bottom of the page.
Event definitions
The forecast is defined against a Cryptanalytically Relevant Quantum Computer (CRQC): a quantum system able to break a cryptosystem that is secure against classical computers. “Q-Day” is the public name for the same event, not a separate concept.
Primary event (ECC-256): the earliest date on which a fault-tolerant quantum system can recover a private key from a specified, practically deployed 256-bit elliptic-curve target within a declared attack-runtime scenario and success probability. The published headline covers ECC-256 only. NIST P-256 and secp256k1 are treated independently and are not combined until a resource model proves the comparison valid — and a target is only forecast once a resource estimate is registered for it at the published attack window, which the home page states per target rather than leaving an unevaluated target looking like an unresolved one.
Secondary event (RSA-2048): the earliest date on which a fault-tolerant quantum system can factor a specified RSA-2048 modulus under the same conditions.
There is no “general-purpose computer” requirement: a specialised machine built for exactly this attack would still count, and requiring generality would exclude it.
Attack-runtime scenarios
Runtime is a declared scenario, never a vague “operationally meaningful” window. The published headline uses the operational scenario.
| Scenario | Window |
|---|---|
| transaction_window | 600 seconds |
| rapid | 3600 seconds |
| operational | 86400 seconds |
| extended | 604800 seconds |
| strategic | 2592000 seconds |
Model architecture
Four layers, deliberately not collapsed into one curve.
- Layer A — architecture-specific structural models
- Superconducting, trapped ion, neutral atom, photonic, topological and emerging, and modular or networked pathways are modelled separately and never aggregated into a single “qubit growth” line. A logical qubit from one experiment is never treated as equivalent to a logical qubit from another code or architecture without normalisation.
- Layer B — target-specific resource models
- One record per target and runtime scenario, each carrying its own paper, logical qubit count, gate counts, depth, assumed error rate, overheads and omitted engineering factors. Assumptions from different papers are never mixed into a single “best” estimate.
- Layer C — scenario and Monte Carlo engine
- Samples correlated future trajectories against a frozen evidence snapshot and evaluates threshold crossing per target and scenario. Correlated variables are never sampled independently.
- Layer D — expert priors
- Version 1 is a scenario-based probabilistic forecast built on explicit, versioned distributions. It is deliberately not described as a complete Bayesian model, because likelihoods and posterior updates are not formally implemented.
Evidence scoring
Every piece of evidence is reviewed by a human before it can affect the model, and scored on 5 dimensions:
- source_reliability
- verification_strength
- model_relevance
- recency
- extraction_quality
The dimensions combine into a single confidence value by equation E1, using weights that live in a versioned scoring configuration rather than in code — changing them is a new version with a stated reason, listed in the change log, not a silent edit.
Evidence is also graded A to E, from primary technical evidence with independent validation (A) down to unsupported or disputed claims (E). A grade describes the strength of the evidence, not whether the underlying claim is true.
Structural thresholds
An attack is possible only when all 7 of these conditions hold at once (equation E2). This is a conjunction, not a score: a machine that satisfies six of seven conditions cannot run the attack.
- logical_capacity
- logical_error_budget
- non_clifford_resource_supply
- operation_depth
- decoder_throughput
- runtime
- engineering_availability
A condition whose inputs are missing evaluates to undefined, never to false — absent data is never counted as a passed or a failed test.
Engineering availability requires a sustained uptime fraction of at least 0.5: hardware available less than half the time is not judged capable of a real attack regardless of its other properties.
In this version only two of the conditions vary over time — logical capacity and logical error budget. The other five stay fixed at their currently recorded values; see limitations.
Monte Carlo method
Each run samples many independent future scenarios. Within one scenario the model picks an architecture pathway per simulated competitor, samples correlated growth trajectories, roadmap delivery reliability, algorithmic-resource improvements and engineering delays, then asks in which year — if ever — all seven conditions hold.
The results are reported as percentile dates (equation E4) and as a cumulative probability by year-end (equation E3). Scenarios that never cross within the modelled horizon are censored: counted and stated as a percentage, never dropped and never extrapolated into a date.
Every published run records its evidence snapshot, configuration version, code commit, container image digest, scenario count and random seed, so any published number can be reproduced exactly.
Hidden capability
No classified capability is claimed as known. These scenarios show how undisclosed progress could change the public-evidence baseline.
Undisclosed progress is modelled as 3 named sensitivity bands (low, moderate, severe), each compared against the public-evidence baseline and never blended into it. The published headline is always the public-evidence baseline.
A sensitivity configuration takes two people: one proposes a version, a different person approves it. An unapproved version cannot be used by a run and does not appear in the change log below.
Validation
Before anything is published, a run must pass an automated validation report: schema validation, evidence-snapshot and configuration checksums, Monte Carlo convergence (re-running at half the scenario count and comparing), scenario validity rate, comparison against the previous version, movement-outlier detection, presence of a sensitivity report, no negative time, percentile ordering, and probability monotonicity. If validation fails, the run is not published.
A check can also come back undecided. Convergence compares the percentile the run actually publishes; when every percentile is censored there is nothing to compare, so the check reports no verdict rather than a pass, and the model-history page names it as untested instead of counting it among the checks that ran. An undecided check does not fail a run — nothing was published from what it could not compare — but it is never presented as a check that passed.
This checks integrity, not correctness. It verifies that the number was produced consistently and reproducibly from the recorded inputs. It cannot tell you whether the forecast is right. Evaluating that — hindcasting, comparison against independent expert surveys, external scientific review — is a separate programme described in the citations below, and it has not yet been carried out.
Limitations
These are the known weaknesses of the current version, stated specifically.
- No named scientific reviewer
- Part XII item 9 is unresolved: no external reviewer or expert panel has been named. Nothing on this site has passed independent scientific review.
- Two of seven gates vary over time
- Only logical capacity and logical error budget are projected forward. The other five conditions stay fixed at their currently recorded values, because growing every hardware field with an invented rate would be a larger and less defensible assumption than not.
- One expert survey, with a shrinking panel
- The Global Risk Institute report is the only recurring expert elicitation in this field. There is no independent second survey to cross-check it.
- No hardware logical-qubit result from IBM
- IBM's flagship fault-tolerance result is a code-design paper that was not executed on hardware, and its logical-qubit roadmap targets are not demonstrations. This is a confirmed gap in the evidence, not an oversight in collection.
- Algorithmic improvement is the least grounded input
- The algorithmic-resource improvement rate is a documented engineering placeholder, deliberately conservative rather than fitted to the observed 2019→2025 jump in RSA factoring estimates. It is the single most consequential unvalidated parameter.
- Patent and EU funding sources are not collected
- Two registered sources (EPO OPS, CORDIS) require credentialed API access that this project does not hold, so patent and EU-funding evidence is absent rather than sparse.
- Documents are read as metadata, not full text
- Standards and policy sources are collected as listing metadata; no PDF is downloaded or parsed. A claim made only inside a PDF body is not currently visible to the model.
- Validation checks integrity, not scientific accuracy
- The pre-publication validation report checks reproducibility, convergence and internal consistency. It cannot and does not check whether the forecast is correct. A check that has nothing to compare -- convergence on a run whose percentiles are all censored -- reports no verdict and is named as untested on the model-history page, rather than counted as a pass.
Change log
Every configuration that affects a published number is versioned and append-only, with a stated reason. This is that history.
| Date | What | Version | Reason |
|---|---|---|---|
| 2026-08-09 | Evidence scoring | v1 | Launch RC: no numerical evidence-scoring parameters have been approved; keep all scoring dimensions unconfigured. |
| 2026-08-09 | Simulation parameters | v1 | Seeded from forecast.distributions.DEFAULT_DISTRIBUTION_PARAMETERS by migration 0013 (issue #129). Every value is a v1 engineering placeholder, not a founder-approved figure traceable to a citation -- see docs/model-methodology.md's 'v1 Layer C engineering placeholders' section, which tabulates each parameter and flags the algorithmic-improvement rate as the most consequential and least grounded of them. Changing any of these is a new configuration version, which is a new migration. |
Downloadable snapshot
Download the methodology snapshot
(Markdown) — the full reviewed source documents
(event-definition.md, model-methodology.md, evidence-taxonomy.md, hidden-capability-model.md),
unedited. This is the citable form of this page.
Equations
E1 · Evidence confidence
confidence_total = Σ(wᵢ · sᵢ) / Σ(wᵢ) over the dimensions i that are present
Weights wᵢ come from the active scoring configuration, not from this page. A dimension with no score is excluded from both sums rather than treated as zero, so a record is never penalised for a dimension nobody could assess.
E2 · Threshold crossing
logical_capacity AND logical_error_budget AND non_clifford_resource_supply AND operation_depth AND decoder_throughput AND runtime AND engineering_availability
A conjunction, not a score: every condition must hold simultaneously for an attack to be possible. Any gate whose inputs are missing evaluates to undefined rather than to false, so absent data never silently counts as a passed or failed condition.
E3 · Cumulative crossing probability
P(year Y) = (number of simulated scenarios crossing on or before 31 Dec Y) / N
A right-continuous step function: the value holds flat through a year and rises only at that year's end. Reading it as rising on 1 January, or interpolating between years, overstates the probability by up to a full year.
E4 · Censored percentiles
Pk is undefined when fewer than k% of scenarios cross within the horizon
Reported as undefined rather than clamped to the horizon's last day. A clamped percentile would look like a forecast where the model has none.
E5 · Published movement
movement_days = P50(this published version) − P50(previous published version)
Measured against the previous *published* version, not the previous run, so the number on the site is the change a reader of the site would have seen.
Glossary
- P10 / P50 / P90
- The dates by which 10%, 50% and 90% of simulated scenarios have crossed.
- N
- Scenario count for a run — the number of Monte Carlo trajectories simulated.
- wᵢ, sᵢ
- The weight and the score of one confidence dimension (E1).
- Logical qubit
- An error-corrected qubit. Never compared across codes or architectures without normalisation — a logical qubit in one code is not equivalent to one in another.
- Λ (Lambda)
- Error suppression factor per two units of code distance.
- Toffoli / T gate
- Non-Clifford gates; their supply is one of the seven crossing gates.
- Censoring
- A scenario that never crosses within the modelled horizon. Censored scenarios are counted and reported, never dropped or extrapolated.
- Evidence snapshot
- The frozen, immutable set of approved evidence a run used. A published forecast is reproducible from its snapshot, configuration, code commit and random seed.
- CRQC
- Cryptanalytically Relevant Quantum Computer — a quantum system able to break a cryptosystem that is secure against classical computers. 'Q-Day' is the public name for the same event.
Citations
The sources the model's baselines come from. Where a source carries a caveat that affects how its numbers should be read, the caveat is printed with it rather than kept in an internal document.
RSA-2048 resource baseline — 1,409 logical qubits (peak), under 1,000,000 physical qubits, 6.5×10⁹ Toffoli gates, under one week runtime.
Generic 256-bit curve logical-qubit baseline — 2,330 logical qubits (the paper's own abstract and Table 2), 1.26e11 Toffoli gates.
Caveat: A purely logical estimate: the paper states no code distance, cycle time or runtime, so this project's logical-error-budget condition reports `undefined` for it rather than importing a physical layer its authors never specified.
Gate-optimised alternative configuration for the same ECC target.
Caveat: Never combined with the Roetteler qubit count into a single 'best of both' estimate: the two describe different resource trade-offs for the same attack.
First secp256k1-specific resource estimate — low-qubit variant under 1,200 logical qubits, low-gate variant under 1,450 logical qubits.
Caveat: This result was disclosed via a zero-knowledge proof (SP1 zkVM + Groth16 SNARK) rather than by publishing the attack circuits. That is a responsible-disclosure choice, and it means the estimate is not independently verifiable in the same way an openly published circuit would be.
Expert-elicitation benchmark. 2025 edition: 28–49% at a 10-year horizon, 51–70% at 15 years. 2024 edition: 19–34% at 10 years. The two editions are separate model inputs and are never blended into one number.
Caveat: The surveyed panel is shrinking — 37 experts in 2023, 32 in 2024, 26 in 2025 — which is itself a possible response-rate or selection effect. No independent survey of comparable rigour exists to cross-check it against; that absence is recorded as a model limitation rather than left unsaid.
The rolling-origin hindcast design this project's validation programme adapts.
Caveat: Adapted, not adopted: no quantum-computing-specific hindcasting standard exists. This is a novel methodology decision built on a borrowed, peer-reviewed design pattern, and is described that way deliberately.
Hardware baseline — distance-7 surface code, 0.143% logical error per cycle.
Hardware baseline — 94 logical qubits (iceberg QED codes) or 48 (concatenated QEC codes) on 98 physical qubits.
Caveat: Preprint, not yet peer reviewed.
This is a probabilistic model of CRQC capability based on public evidence. Its primary result is a forecast interval built from the percentiles the evidence can resolve. A percentile that does not cross within the model’s horizon is reported as undefined, never estimated, together with the share of scenarios that do not cross. The model is recalculated weekly and does not claim day-level or second-level certainty.