Usual USD USD0

Claim: No public cryptographic inventory or quantum threat model exists for USD0 or the Usual Protocol.

Coverage basis: Absence of any quantum-specific documentation across official docs (docs.usual.money, tech.usual.money), blog posts, governance proposals, and audit reports.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No public cryptographic inventory or quantum threat model published

Assurance: Comprehensive review of all official documentation, technical docs, governance proposals (UIPs), and blog posts confirms zero mentions of quantum computing, post-quantum cryptography, or cryptographic inventory. The absence is unambiguous.

USD0 is not a PQ-native asset. It was launched as a standard ERC-20 token on ECDSA-only chains. The PQ-native rule (Section 7.1) does not apply. A full cryptographic inventory and quantum threat model are required.

• https://docs.usual.money/
• https://tech.usual.money/
• https://usual.money/blog

Claim: No quantum-specific evidence record exists. Classical audits and documentation are publicly available but do not address quantum threat models.

Coverage basis: 20+ classical audits, verified smart contracts, and public documentation exist but contain zero quantum-specific content.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No quantum-specific evidence record exists

Assurance: Classical evidence record is strong: 20+ audits, verified contracts on Etherscan/Arbiscan, public documentation. However, none of this evidence addresses quantum threat models, PQC algorithms, or migration planning. All evidence is scope-mismatched for QRI purposes.

The project has an excellent classical security evidence record but it is entirely irrelevant to quantum readiness. Quantum-specific code references, specs, audits, transaction examples, or reproducible analytics are completely absent.

• https://tech.usual.money/security-and-audits/audits
• https://etherscan.io/token/0x73a15fed60bf67631dc6cd7bc5b6e8da8190acf5
• https://docs.usual.money/resources-and-ecosystem/fact-sheets/usual-products/usd0

Claim: USD0 is a standard ERC-20 token. Spend authorization relies on host-chain ECDSA (Ethereum secp256k1). No PQC or hybrid-PQC signatures are supported at token or host-chain level.

Coverage basis: Token inherits host-chain signature scheme. Ethereum, Arbitrum, Base, and BNB Chain all use ECDSA for transaction authorization as of June 2026.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All spend authorization is ECDSA-only, inherited from non-quantum-ready host chains

Assurance: Ethereum Foundation's PQ roadmap (pq.ethereum.org) targets ~2029 for core PQ infrastructure with EIP-8141 providing account abstraction for PQ signature migration. This is a roadmap, not current production protection. Arbitrum, Base, and BNB Chain have no published PQ migration timelines as of June 2026.

Per Section 7.2 (Token Inheritance), USD0 inherently shares the base-layer QRI score of its host chains. All host chains are ECDSA-only. The Ethereum Foundation has a structured PQ program but it remains in development/testnet phase as of June 2026.

• https://etherscan.io/token/0x73a15fed60bf67631dc6cd7bc5b6e8da8190acf5
• https://docs.usual.money/usual-products/usd0-stablecoin
• https://pq.ethereum.org/

Claim: Standard EVM account model. All EOAs that interact with USD0 expose their public keys via ECDSA signatures. No PQ/hybrid address schemes or key-derivation protections exist at token level.

Coverage basis: Token inherits host-chain account model. Ethereum EOAs derive addresses from public keys (keccak256 hash). Public keys are exposed on first transaction and remain permanently visible.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Long-exposure public keys for all transacted EOAs — permanently visible on-chain with no rotation mechanism

Assurance: Per Ethereum Foundation analysis (pq.ethereum.org, February 2026), any EOA that has sent a transaction has an exposed public key. Accounts that have only received tokens have not exposed their public key (only the address hash is visible), providing some additional protection. EIP-8141 (Frame Transactions) proposes native account abstraction to enable PQ signature migration without address changes, but is not yet deployed.

This is a long-exposure (at-rest) attack surface per Section 7.3. All USD0 holders who have transferred tokens have exposed public keys. The ~$562M circulating supply is fully exposed.

• https://ethereum.org/roadmap/future-proofing/quantum-resistance/
• https://pq.ethereum.org/

Claim: USD0 is a token, not a consensus layer. Consensus authentication is inherited from host chains, none of which are quantum-ready.

Coverage basis: Token has no independent consensus mechanism. Host-chain consensus (Ethereum Gasper with BLS signatures, Arbitrum sequencer, Base OP Stack, BNB Chain Parlia) all rely on classical cryptography.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Host-chain consensus layers are all quantum-vulnerable

Assurance: Ethereum's Lean Consensus roadmap includes leanXMSS (hash-based validator signatures) and leanVM (SNARK-based aggregation). This is active research with weekly interop devnets involving 10+ client teams as of April 2026. Target for core PQ infrastructure: ~2029. Not production-ready.

While consensus compromise is less directly impactful for a stablecoin token than spend-authorization compromise, it could affect finality guarantees for USD0 transactions and bridge settlement.

• https://pq.ethereum.org/
• https://ethereum.org/roadmap/future-proofing/quantum-resistance/

Claim: USD0 supply integrity depends on admin-controlled mint/burn roles (5/9 ECDSA multisig) and Chainlink oracle data. Bridge verification (CCIP, LayerZero) for cross-chain supply reconciliation uses classical cryptography.

Coverage basis: Token supply is controlled by DEFAULT_ADMIN_ROLE (Usual Multisig) which authorizes USD0_MINT and USD0_BURN roles. Collateralization verification depends on Chainlink Price Feeds and Proof of Reserve — all classical cryptography.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Admin multisig (5/9 ECDSA) controls all supply-critical functions. Bridge and oracle dependencies are all classical.

Assurance: LlamaRisk (December 2024, referenced in DeepSeek evaluator's March 2026 update) confirmed the 5/9 multisig lacks timelock. The protocol intends to add timelocks 'when the associated functions and roles are significant.' Chainlink CCIP uses defense-in-depth security with multiple DONs and a Risk Management Network, but all rely on classical ECDSA/BLS node operator signatures. The Hashnote USYC oracle confirmed to use MPC rather than single EOA, which provides partial protection.

This is a structural attack surface per Section 7.3. The mint/burn roles, pause/unpause controls, blacklist management, collateral parameter settings, and fee configuration are all controlled by ECDSA keys. A quantum compromise of the admin multisig gives an attacker effectively unlimited control over USD0 supply and the protocol's economic parameters.

• https://tech.usual.money/overview/architecture/role-management
• https://tech.usual.money/smart-contracts/token-contracts/usd0
• https://usual.money/blog/usual-adopts-the-chainlink-standard
• https://llamarisk.com/research/pegkeeper-onboarding-usd0

Claim: USD0 has no privacy layer. All transactions are publicly visible on standard EVM chains.

Coverage basis: USD0 is a transparent ERC-20 token with no shielded transactions, zero-knowledge proofs, or privacy features.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://etherscan.io/token/0x73a15fed60bf67631dc6cd7bc5b6e8da8190acf5

Claim: USD0 is a token, not a network node. No independent P2P layer exists.

Coverage basis: Token has no P2P networking layer. P2P is handled entirely by host-chain infrastructure.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: The 5/9 admin multisig controlling all privileged functions is standard ECDSA. No PQ/hybrid wallet, HSM, or custody workflows exist for token administration.

Coverage basis: All protocol admin keys (DEFAULT_ADMIN_ROLE, PAUSING_CONTRACTS_ROLE, BLACKLIST_ROLE, etc.) are standard Ethereum EOA keys using ECDSA. Hashnote USYC oracle uses MPC (better than single EOA but still classical).

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Admin multisig is 5/9 ECDSA with no timelock — no PQ/hybrid wallet or custody workflows exist

Assurance: The Hashnote USYC oracle uses MPC rather than a single EOA (confirmed by LlamaRisk via direct communication with Hashnote team). This distributes trust but remains within classical cryptographic assumptions. The Usual Multisig (5/9) has no timelock. The protocol has stated intent to add timelocks but this has not been implemented as of June 2026.

The admin multisig controls all critical functions: minting USD0, burning USD0, pausing transfers, blacklisting addresses, upgrading implementation contracts, setting fees, activating Counter Bank Run Mechanism, managing collateral parameters, and configuring oracle/price feed settings. A quantum compromise would be catastrophic for USD0 integrity.

• https://tech.usual.money/overview/architecture/role-management
• https://llamarisk.com/research/pegkeeper-onboarding-usd0
• https://docs.usual.money/usual-products/usual-governance-token/usual-governance

Claim: 0% of USD0's ~$562M market cap is protected from quantum key-recovery attacks. All value is held in standard ERC-20 tokens on ECDSA-only chains with ECDSA-only admin controls.

Coverage basis: Circulating supply of ~562-564M USD0 (CoinMarketCap/CoinGecko/DeFiLlama, June 2026). No portion is protected by PQC or hybrid-PQC mechanisms.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: 0% of ~$562M value-at-risk is protected — <25% coverage, well below minimum migration thresholds

Assurance: Coverage is unambiguously 0%. No PQC, hybrid-PQC, or migration mechanism exists at any layer. All 123K+ holders, all admin keys, all bridge signers, and all RWA collateral tokens are on classical cryptography. The coverage thresholds in Section 9.3.1 place this in the <25% (negligible protection) band.

USD0 is not PQ-native (launched as standard ERC-20 on ECDSA chains). The PQ-native complete-by-design coverage rule (Section 9.3.1) does not apply. Value-at-risk includes not just the token supply but also the protocol-controlled collateral, treasury (~$30.75M as of September 2025), and insurance fund.

• https://coinmarketcap.com/currencies/usual-usd/
• https://www.coingecko.com/en/coins/usual-usd
• https://defillama.com/stablecoin/usual-usd

Claim: No critical wallets (treasuries, admin multisig, bridge operators, foundation) are migrated to PQC or hybrid-PQC. All use standard ECDSA.

Coverage basis: Usual Multisig (5/9 ECDSA), DAO treasury, bridge operator keys, and collateral provider admin keys are all on classical cryptography.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No critical wallets migrated — admin multisig, treasury, bridge operators all ECDSA-only

Assurance: The Hashnote USYC oracle's MPC implementation provides some operational distribution of trust but remains within classical cryptography and does not constitute PQC migration. The 5/9 multisig threshold provides classical Byzantine fault tolerance but no quantum protection.

Critical wallets include: (1) Usual Multisig (5/9) controlling all admin functions, (2) DAO treasury (~$30.75M), (3) Chainlink CCIP and LayerZero bridge operator/signer keys, (4) RWA collateral provider admin keys (Hashnote, M0, BlackRock, Ondo, Circle, Spiko). None are quantum-protected.

• https://tech.usual.money/overview/architecture/role-management
• https://llamarisk.com/research/pegkeeper-onboarding-usd0

Claim: No identification, measurement, deprecation, migration, freeze, or burn plan exists for quantum-vulnerable accounts, admin keys, or bridge dependencies.

Coverage basis: No quantum-specific inventory or management plan exists in any public documentation.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No legacy vulnerable pool identification or management plan exists

Assurance: The protocol does have blacklist functionality (BLACKLIST_ROLE) which could theoretically be used to freeze quantum-vulnerable addresses in an emergency, but no quantum-specific policy, criteria, or governance process for this use case exists.

Per Section 9.3.2, protocols lacking a policy mechanism to deprecate, freeze, burn, or address unmigratable quantum-vulnerable value should count that value as unprotected. USD0 has no such quantum-specific policy.

• https://docs.usual.money/
• https://tech.usual.money/

Claim: No quantum migration or protection roadmap exists for USD0 or the Usual Protocol.

Coverage basis: Zero mentions of quantum computing, PQC, or cryptographic migration in all official documentation, governance proposals, blog posts, and technical documentation.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No quantum migration roadmap exists — zero public acknowledgment of quantum risk

Assurance: The proxy upgrade architecture technically enables future migration but no plan, specification, sequencing, activation criteria, or dependencies have been published. The absence is confirmed by comprehensive review of all official channels.

Per Section 7.1, a PQ-native project that never had classical native ownership would not need a migration roadmap for native assets. USD0 is not PQ-native — it launched as a standard ERC-20 on ECDSA chains. A migration roadmap is required.

• https://docs.usual.money/
• https://usual.money/blog
• https://tech.usual.money/

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist.

Coverage basis: All user interaction with USD0 uses standard EVM wallets (MetaMask, etc.) with ECDSA-only signing. No quantum-aware tooling exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQ migration accessibility — no PQ account creation, wallet tooling, or user guidance

Assurance: USD0 is accessible through standard EVM wallets. Users interact with USD0 exactly as they would with any ERC-20 token. No quantum-specific warnings, education, or migration prompts are provided by the Usual Protocol. Wallet-level PQ migration would depend on Ethereum's EIP-8141 account abstraction, which is not yet deployed.

Per Section 7.2 (Token Inheritance), migration accessibility for spend authorization is primarily a host-chain concern. However, token-specific admin key migration and bridge dependency migration are token-level concerns that are entirely unaddressed.

Claim: No enforcement mechanisms, deprecation policies, disabled legacy signing, or exchange/custody/bridge coordination exist for quantum migration.

Coverage basis: No quantum-specific enforcement or coordination documented. The protocol has general pause/blacklist capabilities but no quantum-specific policies.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No quantum migration enforcement or ecosystem coordination exists

Assurance: The protocol has functional pause and blacklist capabilities via PAUSING_CONTRACTS_ROLE and BLACKLIST_ROLE, which could theoretically be repurposed for quantum emergency response. However, no quantum-specific criteria, thresholds, or governance process for invoking these powers exists. Coordination with exchanges, custodians, and bridge operators for quantum migration is entirely absent.

The two-way bridge dependency (CCIP, LayerZero) is particularly concerning per Section 8.2: 'Two-way bridge or wrapper allows value to flow back into a non-PQ-secure system without restrictions' → Max QRI 50. Even if USD0 somehow migrated to PQC, the bridges back to classical chains would re-expose value.

• https://tech.usual.money/overview/architecture/role-management

Claim: No quantum-specific emergency disclosure process, incident-response playbook, or governance procedure exists.

Coverage basis: The protocol has general security contact ([email protected]) and bug bounty, but no quantum-specific IR process.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No quantum-specific incident response or emergency governance process exists

Assurance: The protocol has general emergency mechanisms: Counter Bank Run Mechanism (CBR), pause/unpause controls, and blacklist functionality. These could provide a rudimentary emergency response, but no quantum-specific trigger criteria, response procedures, communication templates, or governance processes are documented. The absence of timelock on admin functions is a double-edged sword: it enables rapid emergency response but also enables instant malicious actions by a quantum-compromised admin.

Per Section 7.4 (Note-Only Caveat Rule), the absence of a formal quantum-specific IR playbook does not by itself reduce the QRI Score unless it leaves a current quantum-vulnerable path unresolved. Here, the absence is indicative of a broader lack of quantum risk acknowledgment, which compounds other quantum-critical vulnerabilities.

• https://docs.usual.money/start-here/faq
• https://docs.usual.money/usual-products/usual-governance-token/usual-governance

Claim: No PQC or hybrid-PQC algorithms are used anywhere in the USD0 protocol, admin infrastructure, or bridge dependencies.

Coverage basis: All cryptography is classical: ECDSA (secp256k1) for transaction signing and admin keys, BLS for Ethereum consensus, standard hash functions. No NIST PQC standards (FIPS 203/204/205) are implemented.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No NIST-standardized PQC algorithms used at any layer

Assurance: NIST finalized three PQC standards in August 2024: ML-KEM (FIPS 203), ML-DSA/Dilithium (FIPS 204), and SLH-DSA/SPHINCS+ (FIPS 205). None are used in USD0 or its dependencies. Ethereum's PQ roadmap targets ML-DSA and hash-based schemes (leanXMSS) for future implementation, but these are not in production.

This is a foundational blocker. Without PQC algorithms implemented, all other assurance subfactors are moot. The project has zero PQC usage at any layer.

• https://tech.usual.money/overview/architecture
• https://etherscan.io/token/0x73a15fed60bf67631dc6cd7bc5b6e8da8190acf5

Claim: No quantum-specific audit exists. The 20+ classical audits cover smart contract security only, with no PQC or quantum threat model scope.

Coverage basis: All audits (Cantina, Sherlock, Spearbit, Halborn, Hexens, Paladin, Blackthorne, OAK Security) are classical security audits covering smart contract correctness, access control, and economic model assessment. Zero audits address quantum resistance.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No quantum-specific audit exists for any protocol component

Assurance: The classical audit coverage is extensive and current (May 2024–November 2025), with multiple top-tier firms. However, all audits are scope-mismatched for QRI purposes — they verify classical smart contract correctness, not quantum resistance. A quantum-specific audit would need to assess admin key exposure, bridge signer schemes, oracle signature verification, and PQC algorithm implementation.

Per the spec, a stale but relevant audit where the quantum-critical design remains verifiable from other evidence does not reduce the QRI Score by itself. Here, there is no quantum-critical design to audit — the issue is deeper than audit freshness.

• https://tech.usual.money/security-and-audits/audits
• https://docs.usual.money/resources-and-ecosystem/fact-sheets/usual-products/usd0

Claim: No PQC implementation exists to be open-source. Classical contracts are verified on block explorers but contain no quantum-critical code.

Coverage basis: All smart contracts are verified on Etherscan and other explorers. However, there is no PQC code, library, or module to evaluate for openness or reproducibility.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: Classical contracts are verified and source code is available. However, the subfactor evaluates the quantum-critical implementation — which does not exist. Score is 0 because there is no PQC implementation to be open-source, not because existing code is closed.

The project's classical contracts are open-source and verified. This is positive for classical security but irrelevant to quantum readiness scoring.

• https://etherscan.io/token/0x73a15fed60bf67631dc6cd7bc5b6e8da8190acf5
• https://tech.usual.money/smart-contracts/token-contracts/usd0

Claim: No PQC parameter agility or quantum-specific upgrade path is documented. The proxy architecture enables upgrades but no quantum migration plan exists.

Coverage basis: The TransparentUpgradeableProxy pattern allows contract upgrades, but no PQC algorithm selection, parameter migration, or cryptographic agility documentation exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQC parameter agility or upgrade path documented

Assurance: The proxy upgrade pattern technically enables replacing the implementation contract. However, this architectural capability is not the same as a documented PQC upgrade path with algorithm selection, parameter sizing, migration sequencing, and backward compatibility planning. No such documentation exists.

The proxy architecture is a necessary but insufficient condition for quantum migration readiness. Without documented PQC algorithm choices, parameter sizing, signature format migration, and compatibility planning, the upgrade path is purely theoretical.

• https://tech.usual.money/overview/architecture

Claim: No PQC signatures (stateful or stateless) are used. Subfactor is not applicable.

Coverage basis: No XMSS, LMS, or other stateful hash-based signature schemes are deployed. No PQC signatures of any type exist in the protocol.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No PQC deployment exists to analyze. No performance or resource-impact analysis for quantum migration has been published.

Coverage basis: No PQC signature/verification cost analysis, gas/fee impact assessment, or node hardware requirement analysis exists for USD0.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: This is technically an assurance-only caveat (no performance analysis for undeployed PQC) but since there is no PQC implementation at all, the implementation score is 0.00. If PQC were deployed without performance analysis, this would be a confidence-only issue rather than score-reducing.

Per Section 7.4, lack of a formal performance benchmark should not reduce the QRI Score unless resource constraints prevent safe use of the PQ/hybrid path. Here, the score is 0 because no PQC path exists at all, not because of missing benchmarks.