Quantum Readiness Score (QRS) — methodology v0.4 (2026-10-20)

QRS rates chains against a cryptographically relevant quantum computer (CRQC): one large enough to break today's elliptic-curve cryptography (ECC). Post-quantum (PQ) mechanisms resist that threat. Every rating needs public evidence or a repeatable on-chain measurement. score.py implements these rules.

Design rules

1. Stage comes first. Every requirement must pass; high scores or good documentation cannot offset failures.
2. Plans earn at most planned. Only usable mainnet code earns live-*; full credit needs production support and non-experimental code (see live-experimental).
3. Live U requires no ECC key that can move funds, re-key or upgrade the account (hold). Contract/program PQ accounts and vaults must be immutable or upgradeable only by their own PQ key or another PQ-controlled authority. ECC-controlled timelocks only delay forged upgrades; they do not qualify.
4. The weakest required slice limits the stage. For L2s, this includes proofs and upgrade keys controlling funds.
5. Every state above unknown needs a URL. So does every stage gate and every n/a, except P on L1s. Missing evidence means unknown or an unmet gate.
6. Exposure probes are published with a pinned block and hash. They affect scores only once they cover the full chain state.

Rosette — 6 slices

The rosette shows six areas of risk. L1s are base chains; L2s settle on another chain.

Why these weights

Weights affect only the secondary 0–100 score, never stages.

• U 25: users need a safe place to hold and spend before any other fix can help them. Stealing from a user also takes just one key, with no protocol failure.
• C 20 covers catastrophic validator-signature forgery: double spends, rewritten finality and censorship. Attacks need a large stake share and are public, leaving time to react.
• B 15 covers canonical bridges, historically the most attacked component, pooling value behind few keys or a verifier.
• A 15 covers few but powerful keys that can replace any contract. Stages reward timelocks and exit windows that neutralize them.
• M 15: on most chains, most value already sits under revealed ECC keys. Migration decides whether that value can be rescued.
• P 10 mainly applies to L2s; more weight mostly reorders them. Most L1s have no proof system (n/a, excluded).

scripts/sensitivity.py tests each weight at 50%, 75%, 125% and 150%, rescaling others to total 100, plus equal weights. Spearman's rank correlation measures agreement with the published ranking, for capped and raw scores; ties use average ranks. The methodology page publishes data/sensitivity.json, regenerated by the site build. A test rejects stale committed results. Weights cannot change stages.

U — hold and state

U rates holding and spending separately. hold rates the best option a user has on mainnet today. The note says when the default account is weaker.

• pq means no ECC key can move funds, re-key or upgrade the account. Hybrid accounts that need both a PQ and an ECC signature qualify. Threshold/multisig accounts qualify only if ECC keys alone cannot form a quorum. All value-sending ECC keys must be removable and removed, including limited/function-call keys that send value through contracts.
• hidden-until-spend means a hash hides the ECC public key until the first spend, when it becomes exposed. Examples: Bitcoin P2WPKH and an Ethereum externally owned account (EOA) that has never sent a transaction. Safe at rest only.
• exposed means the controlling ECC public key is on-chain from the start, as the address or in account state/a key registry.
• unknown.

state rates spending with an approved PQ mechanism. Signature-less methods count: transaction-bound hash commitment/reveal or hash-based STARK proofs of secret knowledge.

hold and state rate the same account type. On L2s, hold looks at the account only. System upgrade keys (security councils, core contract admins) belong to slice A.

U counts as live only with a live state, an approved mechanism and hold of pq. Otherwise a live state earns at most 6 points and fails stage gates. A revoked or vulnerable U mechanism makes a pq hold that relies on it exposed.

Scope definitions

Live migration (M) must let existing accounts, contracts and stored state move to PQ protection. New PQ accounts alone count under U. Live M needs covers: {accounts, contracts, state}, all true; false or missing fields cap M at 6 points and fail gates. Below live, M is rated on the best published artifact (roadmap, spec or code). M is n/a only with evidence of no past ECC user keys, hence no legacy state.

A canonical bridge is core-team/foundation-operated or endorsed, or holds most of the chain's bridged value. B excludes third-party bridges.

Proof-of-work (Bitcoin, QRL, Abelian) has no block signatures to forge, so C is n/a with evidence. Grover-style mining speed-ups are out of scope.

L2 consensus (C) covers sequencer/proposer signatures. P (proofs), B (bridge) and A (upgrade keys) cover fund safety and gate L2 stages. An L2 cannot rate P as n/a; it is treated as unknown.

States and points

Hybrid earns PQ-only credit because requiring both signatures is at least as strong as the PQ part. ECC OR PQ is not hybrid: the ECC path means the slice is rated as ECC-only.

Mechanism registry

Every live slice names a mechanism id and its deployed parameter_set where the registry defines sets. If the registry defines sets and the file names none, the slice is non-standard. List all other verification mechanisms in components, including SNARK wrappers and KZG commitments. The weakest component decides. Every component must be an approved registry mechanism; otherwise the slice is non-standard.

For proofs, include every commitment the verifier reads: data-availability commitments and state-trie hashes (e.g. Pedersen). This includes KZG blob proofs checked through Ethereum's point-evaluation precompile. Mentioning KZG, pairings, Groth16, PLONK, Pedersen, BN254 or BLS12-381 in a proof-system description/note without declaring it makes the slice non-standard. Declare the component or reword the description.

The methodology page shows the versioned registry, data/algorithms.json, used to check mechanisms and components. Entries list kind, allowed slices, parameter sets with NIST security levels, and status:

• approved counts for live states and gates. Signatures include ML-DSA (FIPS 204), SLH-DSA (FIPS 205), XMSS / LMS (SP 800-208) and WOTS+. RFC 8391-only XMSS sets are accepted and marked; standalone WOTS+ has no NIST approval. Signature-less methods include hash commitments and STARK proofs of knowledge. P and proof-secured bridges accept STARK/FRI and Merkle-based fault proofs.
• candidate is under standardization; non-standard until approved. Falcon / FN-DSA was selected by NIST in 2022; FIPS 206 is not final. Deployed variants differ, including Algorand's deterministic profile and alternative hash-to-point functions. Approval waits for FIPS 206 publication. MAYO is also a candidate.
• revoked means broken or withdrawn: Rainbow in 2022; HAWK in July 2026 after an attack roughly halved its key strength. A dependent slice scores 0 and becomes exposed.
• vulnerable means Shor's algorithm breaks it: KZG and pairing SNARKs such as Groth16, including SNARK proofs of knowledge. Treated as exposed.

Unlisted mechanisms or approved ones outside their allowed slices are non-standard: at most 8 points, no stage gates. A status change re-rates every chain using that mechanism on the next build. The registry keeps a dated changelog.

Parameter sets and caveats are published, not scored in v0.3. Live slices show their deployed set's NIST category (e.g. ML-DSA-44: category 2; ML-DSA-87: category 5). NIST considers category 1 adequate; no penalty applies. XMSS/LMS in SP 800-208, standalone WOTS+ and hash commitments lack standard-assigned categories. The registry labels estimates and explains their basis.

Caveats appear with each mechanism. Falcon / FN-DSA signing needs floating-point arithmetic, complicating side-channel-safe hardware wallets; on-chain verification is unaffected. XMSS/LMS are stateful: each one-time key may sign once, so wallets must track which keys they have used.

Score 0–100 (secondary progress index)

score = Σ W·points / Σ W over in-scope slices (n/a excluded), × 10, then caps:

• ≤ 40 unless U is live, meaning users can hold and spend under a production PQ mechanism on mainnet.
• ≤ 60 unless C is testnet, n/a, or live-* with an approved mechanism.

in_scope_weight shows how much of the rosette applies. research_coverage shows the weight of non-unknown slices out of 100. Both flag scores based on limited scope or research.

Stage gates

Each record in the chain file's gates needs ≥ 1 URL:

• audit is an independent audit of the deployed PQ signing code with no open high/critical findings. It must be ≤ 3 years old or re-attested within 3 years, measured at as_of.
• migration_dated requires a ratified migration plan with an activation date.
• pq_by_default requires new accounts to be PQ/hybrid by protocol or reference-wallet default.
• ecc_sunset requires no ECC-only path to move material value; PQ-only since genesis qualifies.
• admin_timelock records the upgrade delay in days and whether a PQ key can override or veto (pq_override). It counts only with at least 30 days and a PQ override.
• exit_window records the days users have to exit before an L2 upgrade takes effect. It counts only with at least 7 days.

"Live" below means live-hybrid or live-pq with an approved mechanism; U also needs hold: pq.

Stages run from 0 to 7. Each stage requires every lower one. Stages 0–4 track how far PQ user accounts have got, read from the U slice alone. From Stage 5 users are actually protected, and every requirement must pass.

Getting ready (U n/a passes all four):

• Stage 0 — Not started: Stage 1 requirements not met (U exposed, unknown or discussed).
• Stage 1 — Committed: U at least planned (official roadmap or accepted spec).
• Stage 2 — Code merged: U at least in-dev.
• Stage 3 — Testnet: U testnet or any live-* state.
• Stage 4 — Live option: U live-* on mainnet and hold: pq. The mechanism may still be a candidate or non-standard and unaudited; Stage 5 closes those gaps.

Protected:

• Stage 5 — Escape hatch: U live; valid audit; C at least in-dev (or n/a). L2s also need P not exposed/unknown, and A live or exit_window met.
• Stage 6 — Hybrid protected: Stage 5; C and B live (or n/a); A live (or n/a) or admin_timelock met. L2s need P live. Migration needs M ≥ planned with migration_dated, or ecc_sunset, or M n/a. Also requires pq_by_default or ecc_sunset.
• Stage 7 — Quantum-safe: Stage 6; M live (or n/a because no legacy ECC state ever existed); ecc_sunset.

An L2 names its settlement L1 in settles_on. From Stage 5 up, its stage cannot exceed that L1's stage: forgeable settlement-layer consensus or keys also threaten L2 withdrawals. Stages 0–4 are not capped, because an L2 can ship PQ accounts on its own.

v0.4 (2026-10-20) split the old Stage 0 into Stages 0–4 and renumbered Stages 1–3 as 5–7, with unchanged rules.

Measured exposure and adoption (published, not scored in v0.3)

pct_value_key_revealed is the share of sampled EOA value whose public key is already on-chain. The v0.1 probe samples recently active addresses, making account-chain results close to 100% by construction. Scoring waits for a full-state snapshot or indexer. Each result records chain, block number, block hash, RPC and sampling method.

adoption tracks value (pct_value_pq) and accounts (pct_accounts_pq) held in PQ accounts. Each dated point needs a method, evidence and at least one percentage. Shipping PQ accounts does not prove migration works. Trends matter as much as levels; a few percent after months signals trouble. Trends are published; scoring waits for cross-chain comparability. These measurements are intended for a future Stage 7 adoption threshold.

Process

Chain inputs live in chains/<chain>.json, and verbatim evidence quotes in docs/research/evidence/<chain>.md. scripts/check_evidence.py and scripts/check_quotes.py check URLs and quoted text against cited pages. score.py is deterministic: identical inputs, including as_of, produce identical stages and scores.

Review uses public PRs, a dispute window and per-chain changelogs. Re-run probes weekly; every slice change needs new evidence.

Prior art

qrindex.org (QRI), LayerQu, Hardy Index, Tectonic Quantum Tracker, Verdict, LatticeScan, and ZKNOX's PQbeat (Ethereum ecosystem). Most rate documents and roadmaps. QRS adds on-chain exposure measurements, proof/bridge/admin-key analysis and an open, deterministic scorer.

Mechanism registry 2026-10-13

Source: data/algorithms.json. cat. = standard-assigned NIST security category. est. = our estimate when no standard assigns one; notes explain the basis.

Registry changelog

• 2026-10-13 Registry introduced (methodology v0.3): signature-less authentication, parameter sets with NIST categories (estimates marked as such), candidate/revoked/vulnerable entries.
• 2026-10-13 Review added vulnerable Pedersen and estimated categories for Falcon variants (deterministic, alternative hash-to-point). Clarified WOTS+, hash-commitment, STARK-PoK and proof-system caveats.
• 2026-10-13 XMSS: RFC 8391 SHAKE128 sets (XMSS-SHAKE_h_256) accepted with estimated category 1 and marked as not approved in SP 800-208.
• 2026-10-13 FN-DSA / Falcon moved from approved to candidate until FIPS 206 is final.
• 2026-10-13 HAWK moved from candidate to revoked: withdrawn in July 2026 after an attack that roughly halved its key strength.

Weight sensitivity

Each weight tested at 50%, 75%, 125% and 150%; others rescaled to total 100. Equal weights tested too, across 21 chains. Lowest ranking agreement with published weights: ρ = 0.927 (before caps: 0.949). Stage changes: none. Reproduce: python3 scripts/sensitivity.py.