QRI reports use scripts/qri.md as the scoring authority. Each report must include the numeric score, numeric stage, stage label, readiness tags, confidence level, assurance and review notes, critical quantum blockers, evidence notes, user urgency status, and review status.

For generated reports, evidence ingestion models use scripts/evidence_sys.md and OpenRouter web search to assemble a timestamped source dossier before scoring. Maintainers can add project-specific curated evidence and human notes in data/evidence/{project_id}.json; those notes are treated as high-priority leads that the models must verify, apply, qualify, or reject with an explicit human_note_treatment trace. Evaluator models then analyze the project against the QRI specification using scripts/eval_sys.md, the evidence dossier, and web search for missing primary-source support. A final synthesis model uses scripts/synth_sys.md to reconcile disagreements, normalize evidence, fact-check claims against supplied materials, separate score-reducing quantum issues from assurance-only caveats, and produce one structured report. Public pages show the exact model IDs used when a report has been generated.

Generated reports are treated as evidence-assisted drafts unless a maintainer marks them reviewed or published.

Quantum Readiness Index (QRI) draft (v3.1)

1. Executive Summary

The Quantum Readiness Index (QRI) is an evaluation tool to provide verifiable data to separate marketing claims from reality.

It’s designed to serve as:

1. An authoritative source for exchanges, institutions, developers and regulators assessing quantum vulnerabilities across the blockchain space.
2. An open platform that can be added to and adjusted by both users and the development teams of various projects.

This index is something that will be integrated into qday/qmarketcap but can act as a basis for other exchanges and entities as well.

2. Problem Statement

2.1 The Threat

• The Threat: Quantum computers threaten to break the elliptic curve cryptography (ECC) underlying most blockchain transactions and wallet signatures.
• The Confusion: Projects conflate “quantum-resistant state/history” with “quantum-secure active transactions”. Roadmaps are treated as live features.
• The Gap: There is no objective, granular, community-driven registry that separates production reality from roadmap promises, leaving institutions (like Coinbase/CoinMarketCap/CoinGecko) leaving institutions unable to accurately assess risk, adjust custody controls, review listings, manage deposits and withdrawals, or plan migrations.

3. Target Audience

1. Exchanges & Custodians (Coinbase, etc.): Need to know if a chain’s active transaction, consensus and P2P layer is vulnerable to decide on listing/delisting or restricting withdrawals/deposits.
2. Developers & Researchers: Need accurate data on PQC signature support, testnets, and migration tooling.
3. Regulators & Auditors: Need an objective source of truth for institutional risk reporting.
4. Crypto Community: Needs a place to contribute, verify, and debate claims.

4. QRI Goals

QRI is designed to:

1. Grade current quantum-security readiness across critical blockchain layers.
2. Align general cryptographic migration principles with blockchain-specific realities.
3. Prevent high scores based on roadmap claims alone.
4. Reward serious risk assessment without mistaking assessment for protection.
5. Account for different architectures, including PoW chains, PoS chains, privacy chains, smart-contract platforms, rollups, and tokens.
6. Measure value-at-risk rather than address count alone.
7. Distinguish quantum resistance, hybrid protection, quantum recoverability, and roadmap-only claims.
8. Separate quantum-attack readiness from general security assurance, audit freshness, and operational maturity.
9. Treat caveats as score-reducing only when they create, preserve, or make unverifiable a plausible quantum-enabled path to theft, forgery, inflation, consensus/finality compromise, bridge compromise, or critical privacy failure.

A project should only be considered fully quantum-ready when standardized, standards-track, or well-reviewed PQC or hybrid-PQC protection is default or mandatory across all critical applicable layers, migration coverage is complete or complete by design, and the claim is sufficiently evidenced for the evaluated production scope.

QRI is not designed to:

1. Score general usability, fee efficiency, validator economics, throughput, decentralization tradeoffs, or implementation convenience.
2. Convert audit age, general incident-response maturity, performance benchmarking, exchange-support gaps, or future roadmap uncertainty into QRI-score deductions unless those issues affect current quantum-attack readiness in the evaluated scope.

5. QRI Outputs

A QRI evaluation should produce seven outputs:

1. Numeric QRI Score: 0–100. This measures current quantum-attack readiness for the evaluated production scope.
2. Stage: Numeric readiness stage plus its public-facing stage label. Store the numeric stage for reporting/grouping, and display the canonical label from the Four Stages of Quantum Readiness.
3. Readiness Tags: Technical descriptors such as PQ-Native, PQ-Resistant, Hybrid-PQ, Partial Protection, PQ-Recoverable, Roadmap Only, or Not Assessed.
4. Confidence Level: Evidence quality and evaluation reliability. Confidence is reported separately from the QRI Score and is not a hidden score multiplier.
5. Assurance & Review Notes: Audit freshness, audit scope fit, reproducibility, formal review status, operational-readiness gaps, and other assurance caveats.
6. Critical Quantum Blockers: Any unresolved quantum-critical issues that cap the final score.
7. User Urgency Status: A simple, human-readable tag telling the user what to do. Example tags: [Monitor for Updates], [Migration Required], [No Action Needed].

The numeric score should never be published without the stage label, tags, confidence level, assurance notes, evidence notes, and blocker analysis.

5.1 Four Stages of Quantum Readiness

Stage 0 is reserved for unassessed projects or projects with no usable evidence. The four public readiness stages are:

6. QRI Formula

6.1 Final Score

QRI Score = min(Stage Cap, Readiness & Risk Cap, Factor Score)

Where:

Factor Score = sum of all Category Scores

Each category is scored using normalized applicable-layer scoring:

Category Score = Category Weight × (Earned Applicable Subfactor Points / Total Applicable Subfactor Points)

Where:

Earned Applicable Subfactor Points = Σ(Subfactor Weight × Implementation Score)

Total Applicable Subfactor Points = Σ(Subfactor Weight for all non-N/A subfactors in that category)

Evidence Confidence is calculated and reported separately under Section 6.3. It does not multiply every subfactor by default.

A claim must still be sufficiently evidenced to receive the claimed Implementation Score. If public evidence is insufficient to verify an implementation status, evaluators must lower the Implementation Score to the highest status supported by the evidence. If the uncertainty concerns a quantum-critical property that cannot be verified from public code, mainnet/testnet behavior, reproducible data, independent review, or protocol design, a Readiness & Risk Cap may also apply.

Conversely, once a quantum-security property is verifiable for the evaluated production scope, stale audit coverage, missing formal benchmarks, lack of exchange attestations, or incomplete operational documentation should normally affect Confidence, Assurance & Review Notes, or User Urgency Status rather than the QRI Score.

6.2 Implementation Score

Implementation score is applied per subfactor. A project may be fully implemented for one layer and only proposed or in testnet in another.

6.3 Evidence Confidence

Evidence Confidence is reported separately from the QRI Score. It describes how reliable the evidence is for the evaluated claim; it is not the degree of quantum protection and is not a default score multiplier.

Evidence can affect the QRI Score in two ways only:

1. Verification of implementation status: If the evidence does not support the claimed implementation status, lower the Implementation Score to the evidenced level.
2. Quantum-critical uncertainty: If the missing or weak evidence prevents verification of a quantum-critical property, apply the relevant Readiness & Risk Cap.

Evidence should not reduce the QRI Score merely because an otherwise verifiable quantum-secure design lacks a recent audit, formal incident-response document, formal performance benchmark, exchange attestation, or finalized future-upgrade plan.

6.4 Confidence, Audit Freshness, and Assurance Overlay

Evaluators should publish a separate confidence and assurance overlay alongside the QRI Score.

Audit freshness and scope should be recorded explicitly:

Operational preparedness, including security contacts, disclosure process, emergency governance, exchange coordination, custody attestations, and user education, should be reported as assurance context unless it directly affects current quantum-exposed value-at-risk or preserves a vulnerable fallback path.

6.5 Issue Classification

Every negative finding should be classified before it affects the score.

7. Applicability Rules

Every subfactor must be marked with one of three statuses:

• Applicable: The protocol has this layer or function and it must be scored.
• N/A: The protocol genuinely lacks this architectural layer. A subfactor may not be marked N/A merely because the project has not secured, implemented, documented, measured, audited, or migrated it. A written justification is required.
• Satisfied by Design: The protocol design eliminates the vulnerable path entirely. The subfactor receives an Implementation Score of 1.00 when the design claim is sufficiently evidenced. Evidence Confidence is reported separately. A written justification is required.

Examples:

7.1 PQ-Native Rule

If a chain is PQ-native and has no classical ownership namespace for the native asset, then ECC-to-PQC migration for the native asset is complete by design. A protocol qualifies only if: (1) the native asset launched with mandatory PQ or hybrid-PQ spend authorization, (2) no native address, account, script, contract, or wallet path allows ECC/BLS/Schnorr/EdDSA-only ownership of the native asset, (3) no legacy vulnerable native balances exist that require migration, and (4) no active pathway to legacy systems (such as an unrestricted bridge to a BSC/ETH contract) exists for the evaluated native asset scope.

When these conditions are met, the relevant native-asset subfactors must be scored as Implementation Score 1.00 unless public evidence identifies an actual quantum-vulnerable path or the PQ-native claim itself cannot be verified. This is a binding scoring rule. Critical native wallets, including exchanges and custodians, should not be penalized for lacking ECC-to-PQC migration attestations when their on-chain control path is PQ-safe by construction.

A PQ-native project should not be penalized in Section 9.1 merely because it did not publish an ECC-to-PQC migration plan for a legacy native ownership space that never existed. Protocol documentation, genesis/address-format documentation, algorithm specifications, source code, mainnet transaction evidence, or independent review may satisfy the preparedness subfactors when they demonstrate that classical native ownership cannot exist.

Future protocol upgrades from one PQ-secure production design to another PQ-secure design are not ECC-to-PQC migrations for the current production scope. They should be recorded as roadmap or operational notes unless the current production system depends on the future upgrade to avoid a quantum-enabled attack.

Audit age, missing exchange attestations, lack of migration prompts, and lack of a formal quantum-specific incident-response playbook should not reduce the QRI Score for a PQ-native native asset unless they make a quantum-critical property unverifiable or expose a current quantum-vulnerable fallback path. They may still reduce Confidence or appear in Assurance & Review Notes.

7.2 Token Inheritance

If an asset is a standard smart-contract token lacking custom cryptographic or cross-chain dependencies (e.g., a standard ERC-20), it inherently shares the base-layer (L1/L2) QRI score. Evaluators can mark the evaluation as Inherits L1 Score [Chain Name] and only need to evaluate token-specific admin/governance keys.

7.3 Attack-Window Classification

When evaluating public-key exposure, value-at-risk, and production cryptographic protection, evaluators should classify quantum-vulnerable surfaces by attack window:

• Long-exposure (at-rest): The public key is already visible on-chain or publicly derivable (e.g., P2PK outputs, reused P2PKH/P2WPKH addresses, P2TR key-path outputs, Ethereum EOAs that have sent transactions, exposed xpubs/descriptors, validator keys, bridge signer keys). These can be attacked offline with no time constraint.
• Short-exposure (on-spend): The public key is revealed only at transaction broadcast and must be attacked before confirmation/finality. Risk depends on block time, mempool policy, and finality latency.
• Structural (on-setup): Vulnerable public parameters, pairings, trusted-setup outputs, commitment schemes, or reusable protocol assumptions that are embedded in the protocol design and cannot be mitigated per-transaction.

Long-exposure surfaces represent the most immediate quantum risk and should be weighted accordingly in value-at-risk assessment. A protocol that protects only short-exposure paths while leaving material long-exposure value unaddressed should not receive full migration or protection credit.

7.4 Note-Only Caveat Rule

A caveat must be treated as note-only unless it creates, preserves, or makes unverifiable a plausible current production path for a quantum adversary to compromise asset ownership, supply integrity, consensus/finality, bridge settlement, critical state binding, or privacy.

Examples of note-only caveats include:

• An old but still relevant audit where the quantum-critical design remains verifiable from public code, mainnet evidence, standards, or historical review.
• A future upgrade or migration from one PQ-secure production system to another PQ-secure system.
• Lack of migration prompts where no unsafe classical path can be created.
• Lack of exchange or custody migration attestations where the native protocol makes classical custody impossible.
• Lack of a formal performance benchmark unless resource constraints prevent safe use of the PQ/hybrid path.
• Lack of a formal quantum-specific incident-response playbook unless the absence of a process leaves a current quantum-vulnerable path unresolved.

8. QRI Caps

Caps prevent inflated scores. A project’s final score is the minimum of its raw Factor Score and all applicable caps. Caps apply to cryptographic readiness only; they must not penalize or reward general adoption, market traction, or operational viability.

8.1 Stage Cap

8.2 Readiness & Risk Cap

This table merges readiness conditions and critical quantum blockers into a single cap lookup. The most restrictive applicable quantum-critical condition determines the cap.

Readiness & Risk Caps apply only to cryptographic readiness. They must not penalize or reward general adoption, market traction, operational maturity, audit recency, or roadmap completeness unless those issues affect current quantum-attack readiness in the evaluated production scope.

The following conditions do not create a Readiness & Risk Cap by themselves:

• No recent independent audit for an otherwise verifiable PQ-native or PQ-secure production system.
• A stale but relevant audit where the quantum-critical design and implementation remain verifiable from other evidence.
• No formal quantum-specific incident-response playbook.
• No formal performance/resource benchmark.
• Missing exchange or custody migration attestations where the native protocol makes classical ownership impossible.
• Future upgrade uncertainty where the current evaluated production system is already PQ-secure.

These conditions should be reflected in Confidence Level, Audit Freshness, Assurance & Review Notes, or User Urgency Status as appropriate.

9. Scoring Categories

QRI uses five categories totaling 100 points.

9.1 Security Assessment & Evidence Preparedness: 5 pts

This category rewards projects that have done serious public work to identify quantum risk. It is intentionally limited to 5 points so that risk assessment does not get confused with deployed protection or migration status. It should be evaluated as evidence preparedness, not as organizational maturity or adoption.

This is only applicable to designs that started out as vulnerable to quantum computers. A PQ-native or PQ-by-design asset should receive full credit here per Section 7.1.

9.2 Production Cryptographic Protection: 35 pts

This category measures whether production users and critical network functions are protected today.

Production protection must be evaluated by attack surface, not by signature algorithm alone. A chain can have a quantum-safe proof system but still be quantum-vulnerable if spend authorization, state binding, validator authentication, bridge verification, or critical ownership paths remain vulnerable.

9.3 Migration Status & Value-at-Risk: 25 pts

This category measures how much real economic value is protected, migrated, or already PQ-native by design.

Address count is not enough. A chain with 99% of addresses migrated but the largest treasury, exchange, bridge, foundation, or protocol-controlled wallets still vulnerable is not quantum-ready.

However, if the native asset is PQ-native and has no classical ownership space, then exchanges, custodians, and large holders must be treated as protected for native on-chain control. A separate ERC-20, BNB Smart Chain, wrapped, or bridged representation should be evaluated under token inheritance, bridge, or wrapper rules rather than treated as a legacy vulnerable native balance.

For privacy-preserving systems, evaluators should use value-pool data, protocol-level migration states, opt-in attestations, aggregate telemetry, and conservative confidence bands rather than requiring address-level deanonymization.

9.3.1 Coverage Thresholds

9.3.2 Dormant and Unmigratable Assets

Evaluators should account for value held in addresses or accounts that cannot practically migrate, including lost coins, abandoned contracts, unresponsive treasuries, frozen bridges, and long-dormant holdings with exposed public keys. Where a protocol lacks a policy mechanism to deprecate, freeze, burn, or otherwise address unmigratable quantum-vulnerable value, that value should be counted as unprotected in coverage calculations.

A protocol that has adopted a credible salvage, freeze, deprecation, or burn policy for unmigratable vulnerable value — with governance approval, public timeline, and enforcement mechanism — may receive partial migration credit for that value when the policy and enforcement path are sufficiently evidenced. Evidence Confidence is reported separately.

9.4 Migration Mechanism, Governance & Ecosystem Coordination: 15 pts

This category measures whether migration is practically achievable, enforceable, and coordinated for users and institutions. It does not score general ecosystem coordination, business development, listing coverage, or user adoption except where those activities directly reduce quantum-exposed value-at-risk.

For PQ-native systems with no classical native ownership space, migration mechanisms can be scored as satisfied by design for the native asset where the protocol prevents creation, import, or use of vulnerable ownership paths. In that case, the absence of user migration prompts, exchange migration attestations, or legacy-address analytics is not a deduction for native-asset migration mechanics.

For PQ-native production systems, a future protocol upgrade or transition from one PQ-secure network version to another should not be treated as an incomplete quantum migration for the current scope. Score the current production scope as it exists on the evaluation date. Record future transition uncertainty as a roadmap, operational, or assurance note unless current production quantum safety depends on that transition.

9.5 Algorithm & Implementation Assurance: 20 pts

This category measures quantum-critical algorithm and implementation assurance. It should not become a general software-quality score. Audit age, audit scope gaps, operational-process gaps, or missing formal benchmarks should reduce the QRI Score only when they affect safe use of the PQ/hybrid controls or make a quantum-critical property unverifiable. Otherwise, record them in Confidence Level and Assurance & Review Notes.

A bespoke algorithm may receive points only if it has serious public cryptographic review. A project should not receive high scores for opaque, proprietary, or weakly reviewed security claims.

Hybrid construction should not be required when the system is genuinely PQ-native and has no vulnerable classical fallback. Conversely, a migration design that leaves classical signatures as an active security dependency should be assessed on whether the combined construction is secure under both classical and quantum threat models.

10. Readiness Tags

Tags should accompany the numeric score. They clarify what type of readiness is being claimed.

10.1 Recoverability Rule

Quantum recoverability is valuable, but it is not the same as quantum resistance.

A recoverability design may earn points in preparedness, migration mechanism, state-integrity planning, or migration coverage if implemented and evidenced. It should not earn full production-protection credit unless it actually prevents quantum-enabled theft, forgery, inflation, consensus compromise, or critical privacy failure in the current production system.

A project should not be publicly labeled “Quantum-Ready” based only on recoverability.

11. Architecture-Specific Guidance

QRI is architecture-aware but should remain comparable across systems.

11.1 PoW / UTXO Chains

Common applicable layers include transaction signatures, address/public-key exposure, script conditions, P2P identity, wallet support, mining pool operational dependencies, and migration of exposed or reused keys.

Validator-specific subfactors may be N/A if the chain has no validator signatures, validator set, VRF consensus, or finality signatures.

11.2 PoS Chains

Common applicable layers include transaction signatures, validator signatures, BLS or threshold signatures, VRFs, randomness beacons, slashing authorization, governance keys, bridge light-client verification, node identity, staking custody, and validator operational keys.

Consensus-authentication subfactors are generally applicable.

11.3 Smart-Contract Platforms

Evaluators should assess base-layer accounts, contract-controlled assets, admin keys, multisigs, bridges, rollup escrows, token contracts, oracle keys, governance keys, and account-abstraction paths.

Migration coverage should include both native assets and major token/application value-at-risk where practical.

A smart-contract platform cannot be considered fully quantum-ready if most value is controlled by classical multisigs, governance keys, bridges, or token-admin paths, even if the base protocol supports PQ accounts.

11.4 Privacy and Shielded Systems

Evaluators should separately assess spend authorization, shielded note commitments, nullifiers, proof systems, note encryption, viewing keys, transparent pools, shielded pools, and recoverability mechanisms.

Private balances should not be deanonymized for QRI. Instead, use pool-level metrics, protocol state, wallet support, opt-in attestations, and conservative confidence bands.

A shielded system may have strong privacy properties while still having quantum-vulnerable spend authorization or state-binding assumptions. These should be scored separately.

11.5 Rollups and L2s

Evaluators should assess sequencer keys, validator/prover keys, bridge contracts, L1 escrow risk, fraud-proof or validity-proof assumptions, governance/admin keys, forced exits, and withdrawal paths.

An L2 cannot be fully quantum-ready if its L1 bridge, escrow, settlement dependency, or governance path remains quantum-vulnerable in a way that threatens user funds.

11.6 Bridges and Wrapped Assets

Bridges should be evaluated as critical infrastructure. Relevant layers include signer sets, threshold signatures, light-client verification, relayer authentication, governance/admin keys, emergency pause controls, and both source/destination chain dependencies.

A bridge that permits unrestricted two-way flow between PQ-secure and non-PQ-secure systems may cap the QRI of dependent assets.

11.7 Tokens and Application Assets

Tokens inherit risk from their host chain and may also have independent risks from admin keys, governance contracts, bridges, treasuries, upgrade authorities, and custody patterns.

Token-level QRI should identify inherited host-chain risk separately from token-specific risk.

12. Evaluation Workflow

A QRI evaluation should follow this process:

1. Identify the asset, protocol version, network, and evaluation date.
2. Inventory all critical cryptographic mechanisms.
3. Identify applicable, N/A, and satisfied-by-design subfactors with written justification.
4. Determine whether the asset is PQ-native, migrated, partially migrated, recoverable, roadmapped, or unprotected.
5. Classify every negative finding as a quantum-critical vulnerability, quantum-critical uncertainty, assurance-only caveat, or operational/product caveat.
6. Score each applicable subfactor using Implementation Score, lowering the score only to the level supported by evidence.
7. Calculate category scores using normalized applicable-layer scoring.
8. Apply Stage Cap and Readiness & Risk Cap only for quantum-critical blockers or unverifiable quantum-critical claims.
9. Assign Confidence Level, Audit Freshness, Assurance & Review Notes, and readiness tags.
10. Publish evidence notes, unresolved risks, N/A justifications, satisfied-by-design justifications, critical quantum blockers, non-scoring caveats, and user urgency status.
11. Allow community, project-team, and expert review.
12. Update the score when production evidence or the evaluated production scope changes.

QRI scores should be versioned. A score is only valid for the protocol version, network, scope, and evidence set evaluated.

13. Evidence Record Template

Each evaluation should maintain an evidence table.

14. Score Interpretation

Scores should be interpreted with the Confidence Level and Assurance & Review Notes. A high QRI Score with Medium confidence means no current quantum-critical attack path has been identified in the evaluated production scope, but review freshness, scope fit, reproducibility, or operational documentation could still be improved.

A score should not be reduced merely because an audit is old, a formal benchmark is missing, a future PQ-to-PQ upgrade is not finalized, or a formal quantum-specific incident-response playbook is absent. These items should reduce the QRI Score only when they create, preserve, or make unverifiable a current quantum-enabled path to theft, forgery, inflation, consensus/finality compromise, bridge compromise, critical state-binding failure, or privacy failure.

Scores should be interpreted conservatively. A high score should require production evidence or complete-by-design coverage for the evaluated scope, not theoretical security or roadmap claims alone.