AI network token
Provenance Blockchain HASH
Provenance Blockchain (HASH) is a Cosmos SDK-based Layer-1 Proof-of-Stake blockchain purpose-built for financial services and real-world asset tokenization. As of the evaluation date, the project has no post-quantum or hybrid-PQC protection in production. All critical cryptographic layers—spend authorization (secp256k1 user keys), validator consensus authentication (Ed25519 via CometBFT), and state binding (BLS signatures)—rely entirely on quantum-vulnerable classical elliptic-curve cryptography. The project's whitepaper acknowledges quantum risk through a future research item ('Quantum-Resistant Protocol Evolution') but no public cryptographic inventory, quantum threat model, PQC testnet, migration mechanism, or production PQC code exists. Approximately $500M-$970M in market capitalization (~54B HASH circulating) is secured by quantum-vulnerable cryptography. The QRI Score of 3.25 reflects that quantum risk has been acknowledged at a roadmap level (Stage 1) but no meaningful production protection or migration infrastructure exists. The score is capped by the absence of a public cryptographic inventory with quantum threat model (Readiness & Risk Cap: 10) and is ultimately limited by the near-zero Factor Score across all categories.
Roadmap OnlyECC-DependentCosmos SDKIBC-ConnectedPoS
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
0.5 / 20
Migration Mechanism, Governance & Ecosystem Coordination
1.5 / 15
Migration Status & Value-at-Risk
0 / 25
Production Cryptographic Protection
0 / 35
Security Assessment & Evidence Preparedness
1.25 / 5
Critical Quantum Blockers
- Active production spend authorization remains entirely secp256k1/EdDSA-only; no PQC or hybrid-PQC transaction path exists on mainnet.
- Consensus-critical validator authentication uses quantum-vulnerable Ed25519 signatures via CometBFT.
- BLS signatures used for validator signature aggregation are quantum-vulnerable.
- No public cryptographic inventory with quantum threat model covering attack assumptions, affected assets, and affected layers.
- No migration mechanism, PQC testnet, or production PQC code exists; all ~$500M-$970M in market cap is quantum-exposed.
Key Risks
- QUANTUM-CRITICAL: All user transaction signatures use secp256k1 ECC, which Shor's algorithm can break on a sufficiently powerful quantum computer. Every on-chain transaction exposes the sender's public key, creating a permanent Harvest-Now-Decrypt-Later attack surface.
- QUANTUM-CRITICAL: Validator consensus signatures use Ed25519. A quantum adversary compromising validator keys could forge blocks, break consensus finality, execute double-sign attacks, and potentially halt or corrupt the network.
- QUANTUM-CRITICAL: BLS signature aggregation for validator votes is quantum-vulnerable. Compromise could enable validator impersonation and consensus manipulation.
- QUANTUM-CRITICAL: IBC light-client verification and cross-chain packet authentication rely on the same classical cryptographic assumptions. A quantum break of the host chain's validator signatures could compromise bridged asset security across all IBC-connected chains.
- Approximately $500M-$970M in market cap is fully exposed with no migration path, freeze mechanism, or PQC fallback.
- No public cryptographic inventory means the full quantum attack surface (all key types, all layers, all exposure windows) is not systematically documented or assessed.
- The project has no published quantum-specific incident-response process. While general emergency governance exists, there is no evidence of preparedness for a quantum-enabled consensus or signature-forgery event.
Assurance Notes
- No independent cryptographic audit or formal quantum risk assessment has been published by the Provenance Blockchain Foundation.
- The whitepaper lists cryptographic primitives (SHA-256, Ed25519, BLS signatures) but does not provide a quantum threat model, attack assumptions, affected assets mapping, or affected layers analysis.
- The 'Quantum-Resistant Protocol Evolution' roadmap mention in the whitepaper is a future research item without technical specifications, activation criteria, timelines, or public code artifacts.
- User-facing accounts use secp256k1 keys; validator consensus uses Ed25519 keys. Both are quantum-vulnerable. No hybrid-PQC or PQC transaction path exists on mainnet.
- The project uses IBC for cross-chain communication. IBC light-client verification and relayer authentication rely on the same classical cryptographic assumptions as the host chain.
- Market cap is approximately $500M-$970M (varies by source). All on-chain value is secured by quantum-vulnerable classical ECC.
- No formal quantum-specific incident-response playbook or disclosure process has been published. General emergency governance procedures are referenced in the whitepaper.
- No performance or resource-impact analysis for PQC signature/verification costs has been published.
Non-Scoring Caveats
- The whitepaper's 'Quantum-Resistant Protocol Evolution' roadmap mention is a future research item, not a committed development timeline. It does not provide production protection and should not be interpreted as evidence of imminent PQC deployment.
- A secondary industry analysis (source date 2026-04-23) references 'Quantum-Resistant Protocol Evolution' in late 2026/2027, but this is a secondary source with Medium confidence and does not constitute a primary project commitment.
- IBC bridge dependencies mean HASH tokens bridged to other Cosmos chains inherit the quantum security posture of those counterparty chains.
- Validator FAQ notes that 'no major cloud infrastructure providers have a compatible HSM solution that supports the required signing algorithm' (Ed25519), indicating HSM support for current classical keys is already challenging. PQC HSM support would be an additional hurdle.
- The project's Smart Accounts feature (passkey, biometric, FIDO2 authentication) is referenced as a future enhancement and does not address quantum security of the underlying cryptographic layer.
- No exchange or custody migration attestations exist, but this is expected given the absence of any PQC migration path.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: Provenance Blockchain whitepaper lists cryptographic primitives (SHA-256, Ed25519, BLS signatures) but does not provide a quantum threat model, attack assumptions, affected assets mapping, or affected layers analysis.
Coverage basis: Partial inventory of cryptographic primitives from official whitepaper and developer documentation; no quantum threat model component.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory with quantum threat model exists.
Assurance: The whitepaper lists algorithm names but does not map them to specific protocol layers, key types, exposure windows, or quantum attack assumptions.
The whitepaper's 'Cryptographic Primitives: SHA-256, Ed25519, BLS signatures' entry is a minimal algorithm list, not a structured cryptographic inventory.
Security Assessment & Evidence Preparedness
Public evidence record supporting quantum assessment
Claim: Project has open-source code, public documentation, and a whitepaper, but no quantum-specific evidence record (audits, transaction analytics, reproducibility reports for quantum assessment) exists.
Coverage basis: General open-source codebase and documentation; no quantum-focused evidence artifacts.
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: Code is publicly available and documentation is comprehensive for general development purposes, but no quantum-specific evidence artifacts have been published.
The open-source nature of the project supports reproducibility for classical security review but does not substitute for quantum-specific evidence preparation.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: User transaction signatures use secp256k1 ECDSA (standard Cosmos SDK accounts). No PQC or hybrid-PQC spend authorization exists on mainnet.
Coverage basis: All user-facing accounts use classical ECC for transaction signing, confirmed by developer documentation and on-chain account data.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Active production spend authorization remains entirely secp256k1/EdDSA-only.
Assurance: Confirmed from multiple primary sources: developer docs explicitly show `/cosmos.crypto.secp256k1.PubKey` for user accounts.
Every transaction broadcasts the sender's secp256k1 public key on-chain, creating a permanent Harvest-Now-Decrypt-Later surface.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: Standard Cosmos SDK HD wallet derivation (BIP32/BIP44, secp256k1 for users, ed25519 for validators). No PQ/hybrid key-derivation controls. Public keys are exposed on first transaction.
Coverage basis: Confirmed by developer documentation describing HD wallet paths, key types, and address derivation.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Documentation explicitly confirms secp256k1 for user addresses and ed25519 for validator consensus addresses.
Accounts that have never sent transactions (pub_key: null in auth queries) have not yet exposed their public key on-chain, offering some short-term protection.
Production Cryptographic Protection
Consensus-critical authentication (validator signatures, BLS, VRFs)
Claim: CometBFT consensus uses Ed25519 validator signatures. BLS signatures are used for validator vote aggregation. Both are quantum-vulnerable.
Coverage basis: Confirmed by CometBFT specification and Provenance Blockchain whitepaper listing cryptographic primitives.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Consensus-critical validator authentication uses quantum-vulnerable Ed25519 signatures via CometBFT. BLS signature aggregation is also quantum-vulnerable.
Assurance: CometBFT encoding specification explicitly documents ED25519 signatures for consensus messages.
Top 100-125 validators secure the network with a minimum 500,000 HASH stake. Compromise of validator consensus keys by a quantum adversary could enable forged blocks and network disruption.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: SHA-256 for hashing; BLS signatures for state binding/attestation. No KZG/pairing-based commitments identified in production use. SHA-256 is partially quantum-resistant but BLS-based state attestation is quantum-vulnerable.
Coverage basis: Whitepaper listing of cryptographic primitives; CometBFT and Cosmos SDK architecture.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: SHA-256 hashing provides partial quantum resistance (Grover's algorithm gives O(2^128) preimage search vs O(2^256) classical). However, BLS-based state attestation is fully quantum-vulnerable.
The whitepaper lists BLS signatures as a cryptographic primitive but does not specify all state-integrity contexts where BLS is used.
Production Cryptographic Protection
Privacy and proof layers (ZK, note encryption, shielded state)
Claim: Provenance Blockchain does not currently have production privacy or zero-knowledge proof layers. The whitepaper mentions zk-SNARK and zk-STARK research as future work.
Coverage basis: Whitepaper future research section; no evidence of production privacy features in current mainnet.
Implementation score: 1 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
If privacy features are deployed in the future, they would need separate quantum assessment.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: P2P networking uses libp2p with classical cryptographic authentication. No PQC or hybrid-PQC for node-to-node communication.
Coverage basis: Whitepaper listing of libp2p; standard Cosmos SDK/CometBFT P2P stack.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: P2P node identity is documented as using libp2p. While P2P compromise alone does not directly enable asset theft, it could facilitate network-level attacks that compound with other quantum vulnerabilities.
The validator FAQ describes a multi-tier network architecture (public sentry nodes, private sentry nodes, isolated validator nodes) which provides defense-in-depth against classical network attacks.
Production Cryptographic Protection
Critical wallet, custody, HSM, and hardware-wallet workflows
Claim: No evidence of PQ/hybrid wallet, custody, or HSM support. Validator documentation notes HSM compatibility challenges even for current Ed25519 signing.
Coverage basis: Validator FAQ and general documentation; no PQ wallet tooling referenced anywhere.
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Validator FAQ explicitly states: 'at present no major cloud infrastructure providers have a compatible HSM solution that supports the required signing algorithm' (Ed25519).
The Provenance mobile wallet exists but does not support any PQC signature schemes.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: 0% of value-at-risk is protected by PQC or hybrid-PQC. All ~$500M-$970M market cap (~54B HASH circulating) is secured by quantum-vulnerable classical ECC.
Coverage basis: Market data from CoinGecko, CoinMarketCap, and other aggregators; cryptographic vulnerability confirmed by project documentation.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All ~$500M-$970M in market cap is quantum-exposed with no PQC protection or migration path.
Assurance: Market cap varies by source (~$523M on CoinGecko, ~$648M on CoinMarketCap, ~$899M on The Defiant, ~$968M on MEXC) due to price volatility and different circulating supply calculations.
The Provenance Blockchain Foundation delegates nearly half of its HASH treasury ($2.41B in HASH tokens per Q1 2025 report) to validators. Foundation-controlled and treasury assets represent a concentrated quantum-vulnerable value pool.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to PQC or hybrid-PQC. All remain on quantum-vulnerable classical keys.
Coverage basis: Absence of any migration evidence across all reviewed sources.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Foundation treasury, validator stakes, exchange-held HASH, and all protocol-controlled value remain on quantum-vulnerable keys.
Assurance: The Foundation's Q1 2025 validator delegation program delegates nearly half its treasury ($2.41B HASH) to validators.
Critical infrastructure participants (exchanges listing HASH, IBC relayers, major validators) all operate on the same quantum-vulnerable classical key infrastructure as ordinary users.
Migration Status & Value-at-Risk
Legacy vulnerable pools identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No identification, measurement, deprecation, freeze, or migration of quantum-vulnerable pools has been conducted. All accounts and balances are on classical ECC with no distinction between vulnerable and protected pools.
Coverage basis: Absence of any pool identification or migration activity across all reviewed sources.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No evidence of any effort to identify, categorize, or measure quantum-vulnerable balances.
Accounts that have never sent transactions (pub_key: null) have not exposed their public keys and represent a smaller immediate quantum risk.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: The whitepaper mentions 'Quantum-Resistant Protocol Evolution' as a future research direction with 'Post-quantum cryptographic primitives, Quantum-safe signature schemes, Lattice-based cryptography integration.' This is a high-level roadmap mention without sequencing, activation criteria, or dependencies.
Coverage basis: Whitepaper future research section; secondary industry analysis.
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The roadmap mention is in a future research section of the whitepaper and lists generic PQC categories without specificity.
Roadmap mentions do not provide production protection and should not be interpreted as evidence of imminent PQC deployment.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, and migration prompts
Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education materials, or migration prompts exist.
Coverage basis: Absence of any such features across all reviewed documentation, code, and community resources.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Comprehensive absence of any PQ migration tooling across developer docs, GitHub repositories, wallet software, and community resources.
Users cannot create a PQ-protected account on Provenance Blockchain today.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms, exchange/custody/bridge/wallet coordination, unsafe-path blocking
Claim: No enforcement mechanisms, deprecation policies, freeze capabilities, disabled legacy signing, or exchange/custody/bridge coordination for quantum migration exist.
Coverage basis: Absence of any such mechanisms across all reviewed sources.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The project has governance mechanisms for protocol upgrades but none have been adapted or tested for quantum migration coordination.
IBC bridge dependencies add complexity: even if Provenance Blockchain were to deploy PQC, bridged assets flowing through IBC would remain vulnerable to quantum attacks on counterparty chains' validator sets.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: The whitepaper references general emergency governance procedures for critical security issues but no quantum-specific incident-response or disclosure process has been published.
Coverage basis: Whitepaper governance section describing emergency procedures.
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The whitepaper mentions 'emergency procedures for critical security issues' but these are generic security governance provisions.
General emergency governance provides a foundation for quantum-incident response but lacks the specificity needed for quantum-era threats.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: No PQC or hybrid-PQC algorithms are used in the production system. All cryptography is classical ECC (secp256k1, Ed25519, BLS).
Coverage basis: Confirmed by all project documentation and source code.
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No NIST-standardized PQC algorithms (ML-KEM/FIPS 203, ML-DSA/FIPS 204, SLH-DSA/FIPS 205) or any other PQC schemes are in use.
The whitepaper's future research mention of 'lattice-based cryptography integration' suggests awareness of NIST PQC standards, but this is purely aspirational with no implementation.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit for quantum-critical scope
Claim: No independent cryptographic audit covering quantum-critical implementation has been identified. General security audits are referenced but not publicly linked or quantum-specific.
Coverage basis: Absence of any quantum-specific audit across all reviewed sources.
Implementation score: 0 · Evidence confidence: None
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: The whitepaper references 'regular security audits and penetration testing' but no specific cryptographic audit report is publicly linked.
The absence of a published cryptographic audit does not, by itself, create a new quantum attack path—the quantum vulnerability is inherent in the algorithm choice.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: The Provenance Blockchain codebase is open source (Apache 2.0 license) and publicly available on GitHub. However, there is no PQC implementation to be open-source or reproducible.
Coverage basis: GitHub repository and open-source licensing.
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The classical codebase is open source and buildable. However, the subfactor evaluates the quantum-critical implementation, which does not exist.
The repository (provenance-io/provenance) has 110+ stars and is actively maintained. The codebase being open source means that if PQC were added, it would be publicly reviewable.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path documented
Claim: The project has a general governance-based upgrade mechanism (on-chain voting, time-locked execution). The whitepaper acknowledges the need for quantum-resistant protocol evolution but provides no PQC-specific parameter agility or upgrade path documentation.
Coverage basis: Whitepaper governance section and future research section.
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The general governance upgrade mechanism provides a procedural foundation for future PQC upgrades. However, no PQC-specific parameter agility is documented.
The acknowledgement of quantum-resistant evolution in the whitepaper is a positive signal of awareness but falls far short of a documented, actionable PQC upgrade path.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks
Claim: No PQC signatures are in use, so stateful-signature safety (e.g., XMSS/LMS anti-reuse controls) is not applicable. No side-channel or fault-injection analysis for PQC has been conducted.
Coverage basis: Absence of any PQC implementation.
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: This subfactor is applicable in principle but cannot be evaluated because no PQC implementation exists.
The current classical implementation faces existing HSM challenges (validator FAQ: 'no major cloud infrastructure providers have a compatible HSM solution').
Algorithm & Implementation Assurance
Performance and resource-impact analysis for PQC deployment
Claim: No performance or resource-impact analysis for PQC signature/verification costs has been published.
Coverage basis: Absence of any PQC performance analysis.
Implementation score: 0 · Evidence confidence: None
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: PQC signatures (e.g., ML-DSA-87 at ~4.6KB, SLH-DSA at ~8-30KB) are significantly larger than Ed25519 (64 bytes) and secp256k1 signatures (~70-72 bytes).
PQC signature sizes (2-30KB vs ~64 bytes for Ed25519) would significantly impact block space, storage requirements, and network bandwidth.
Report metadata