blockchain network
Avalanche AVAX
Avalanche is evaluated at Stage 1 (Quantum Risk Assessed) with a QRI Score of 6/100. The project's founder has publicly acknowledged the quantum threat and discussed lattice cryptography as a future direction, but no formal PQC roadmap, cryptographic inventory, prototype, testnet, or mainnet deployment exists as of the evaluation date. All critical cryptographic layers remain entirely classical: ECDSA secp256k1 for spend authorization across all three chains, BLS12-381 for consensus and cross-chain messaging, and Intel SGX + classical cryptography for the Avalanche Bridge. C-Chain EVM accounts permanently expose public keys on first use. The hashed-public-key design on X/P chains provides partial at-rest protection for unspent addresses only. No migration mechanism, tooling, enforcement, or ecosystem coordination for quantum readiness has been published. The claimed lattice cryptography pull request from late 2024 has not been evidenced in any public repository as of June 2026.
Roadmap OnlyECC-DependentBLS-DependentBridge-Vulnerable
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
0.83 / 20
Migration Mechanism, Governance & Ecosystem Coordination
1.25 / 15
Migration Status & Value-at-Risk
0.52 / 25
Production Cryptographic Protection
3.94 / 35
Security Assessment & Evidence Preparedness
2.5 / 5
Critical Quantum Blockers
- All spend authorization across C-Chain, P-Chain, and X-Chain uses ECDSA secp256k1, which is breakable by Shor's algorithm. No hybrid or PQC signature path exists in production, testnet, or prototype.
- Consensus authentication and Avalanche Warp Messaging (AWM) rely on BLS12-381 pairing-based signatures, which are quantum-vulnerable. Compromise of validator BLS keys enables cross-chain message forgery and probabilistic consensus influence.
- The Avalanche Bridge uses Intel SGX enclaves and classical cryptography (ECDSA/TLS) secured by a 6-of-8 Warden set. Quantum compromise of bridge keys would enable theft of all bridged assets (BTC.b, WETH, etc.).
- C-Chain (EVM) accounts permanently expose their secp256k1 public keys on first transaction, creating an indefinite at-rest attack window with no migration, recovery, or deprecation path.
- No formal post-quantum migration roadmap, Avalanche Community Proposal (ACP), prototype, testnet deployment, or mainnet deployment exists. The lattice cryptography pull request mentioned by the founder in December 2024 has not been verified in any public repository as of the evaluation date.
Key Risks
- All AVAX and token value on C-Chain, P-Chain, and X-Chain is spendable by a quantum adversary capable of running Shor's algorithm against secp256k1. There is no fallback, migration, or recovery mechanism.
- Compromised validator BLS keys enable forgery of Avalanche Warp Messaging (AWM) signatures, potentially allowing theft of cross-chain assets, fraudulent subnet communication, and disruption of validator coordination.
- The Avalanche Bridge's 6-of-8 Warden model secured by Intel SGX and classical cryptography is quantum-vulnerable. Compromise of bridge keys would allow unilateral extraction of all bridged assets from both sides.
- P-Chain staking keys are secp256k1-based. A quantum attacker could extract validator private keys and steal staked AVAX, potentially gaining enough stake to influence consensus outcomes via Avalanche's probabilistic sampling mechanism.
- C-Chain EOAs that have sent even a single transaction have permanently exposed public keys with no rotation mechanism. This creates a growing pool of quantum-vulnerable long-exposure value that cannot be retroactively protected.
- No published migration timeline means users, exchanges, custodians, and institutional holders have no guidance on when or how to transition to quantum-safe custody on Avalanche.
- If a cryptographically relevant quantum computer emerges before Avalanche deploys PQC, there is no circuit-breaker, emergency freeze, or coordinated response mechanism to prevent mass asset extraction.
Assurance Notes
- Classical security audits exist (Halborn, Least Authority, OpenZeppelin) covering bridge, wallet, and smart-contract scope, but none address post-quantum readiness. The most recent audits date to 2024 or earlier and are stale for the 2026 evaluation date.
- avalanchego is fully open-source and the classical cryptographic implementation is reproducible and well-documented, but no PQC code, test vectors, or hybrid signature paths exist in the repository.
- No formal quantum-specific incident-response playbook, emergency disclosure process, or quantum governance procedure has been published by Ava Labs or the Avalanche Foundation.
- No formal performance or resource-impact analysis for PQC deployment has been published by the project. Third-party research notes that lattice-based signatures are roughly 10x larger than current ECC signatures, which could strain network bandwidth and throughput.
- The founder publicly acknowledged quantum risk in December 2024 and mentioned a lattice cryptography pull request being prepared, but no such PR, ACP, testnet deployment, or formal specification has been verified in public repositories as of the evaluation date.
- Avalanche's subnet architecture theoretically allows individual subnets to experiment with custom cryptography including PQC, but the primary network (C-Chain, P-Chain, X-Chain) and validator set remain classical-only.
Non-Scoring Caveats
- Hashed public keys (SHA-256 + RIPEMD-160) on X-Chain and P-Chain provide partial at-rest protection for addresses that have never spent funds, similar to Bitcoin P2PKH. This does not protect C-Chain EOAs, staking keys, or any address after its first outgoing transaction.
- Avalanche's ~2-second finality significantly reduces the on-spend attack window compared to slower chains. However, recent research on fast-clock superconducting quantum computers suggests that on-spend attacks could become plausible even against fast-finality chains.
- The subnet model provides architectural flexibility for future PQC experimentation at the subnet level, but primary network validators and core chains would remain vulnerable even if individual subnets adopted PQC.
- ACP-20 proposes Ed25519 for P2P node identity, which improves operational security but does not address quantum vulnerability — Ed25519 remains ECC-based and breakable by Shor's algorithm.
- No formal quantum-specific security contact or vulnerability disclosure program has been published.
Evidence record
Claims and Caveats
spend_authorization
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: Avalanche uses ECDSA secp256k1 exclusively for transaction signing across all three chains (C-Chain, P-Chain, X-Chain). No PQC or hybrid signature path exists.
Coverage basis: ECDSA secp256k1 only; no PQC or hybrid alternative
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: ECDSA secp256k1 spend authorization across all chains is breakable by Shor's algorithm. No hybrid or PQC path exists in any form.
Assurance: Confirmed by official cryptographic primitives documentation, source code inspection of avalanchego, and independent academic survey (arXiv 2512.13333). No contrary evidence found.
account_address_exposure
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths or supports PQ/hybrid controls
Claim: X-Chain and P-Chain use SHA-256 + RIPEMD-160 hashed public keys providing at-rest protection for unspent addresses. C-Chain EVM accounts expose secp256k1 public keys permanently on first transaction. No PQ/hybrid controls exist.
Coverage basis: Partial hashed-key protection on X/P chains; no protection on C-Chain
Implementation score: 0.15 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: C-Chain EVM accounts permanently expose public keys on first transaction with no rotation, migration, or recovery mechanism. X/P chain hashed-key protection does not extend to spent addresses or staking keys.
Assurance: The founder's claim that hashed public keys provide meaningful quantum protection is partially valid for X/P chain unspent outputs but does not address C-Chain EOAs, staking keys, or any address after spending.
C-Chain represents the majority of Avalanche's DeFi activity and value. All C-Chain accounts that have ever sent a transaction have permanently exposed public keys, creating a large and growing pool of long-exposure quantum-vulnerable value.
consensus_authentication
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: Avalanche validators use BLS12-381 signatures for consensus-related functions including Avalanche Warp Messaging (AWM), peer handshakes, and cross-chain signature aggregation. No PQC alternative exists.
Coverage basis: BLS12-381 only; quantum-vulnerable pairing-based cryptography
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: BLS12-381 validator signatures are breakable by Shor's algorithm. Compromise enables AWM message forgery, cross-chain asset theft, and probabilistic consensus influence.
Assurance: BLS is deeply embedded in Avalanche's architecture: validator handshakes, AWM cross-chain messaging, Simplex consensus components, and ICM contracts BLS verifier. Migration would require coordinated replacement across all these systems.
state_integrity
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: Avalanche uses SHA-256 and RIPEMD-160 for hashing (quantum-safe for collision resistance), but AWM uses BLS for cross-chain state binding and the bridge uses ECDSA. Core hash-based state integrity is quantum-safe; cross-chain verification layers are not.
Coverage basis: Hash-based core state is quantum-safe; BLS/ECDSA cross-chain binding is not
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: BLS-based AWM state binding and ECDSA-based bridge verification are quantum-vulnerable. Forgery of cross-chain state proofs could lead to theft of bridged or cross-subnet assets.
Assurance: SHA-256/RIPEMD-160 hashing is not broken by Shor's algorithm. However, the AWM and bridge layers that bind state across chains rely on quantum-vulnerable signatures.
Avalanche's consensus model does not rely on quantum-vulnerable polynomial commitments like Ethereum's KZG. Core on-chain state integrity is hash-based and quantum-safe for collision resistance.
privacy
Privacy and proof layers are quantum-safe where applicable
Claim: Avalanche does not have a native privacy layer or shielded transaction pool.
Coverage basis: No privacy layer exists
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
p2p
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: Avalanche nodes use TLS with RSA/ECDSA certificates for P2P communication. ACP-20 proposes migration to Ed25519 for node identity but this remains ECC-based and quantum-vulnerable. P2P identity compromise does not directly enable asset theft.
Coverage basis: RSA/ECDSA TLS certificates; Ed25519 proposed; P2P not spend-critical
Implementation score: 1 · Evidence confidence: High
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: ACP-20 proposes Ed25519 which remains quantum-vulnerable. The coupling between P2P node identity and validator BLS keys (via handshake verification) is captured under the consensus_authentication subfactor.
wallet_custody
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path or are protected by native satisfied-by-design controls
Claim: No wallet, custody, or HSM workflow supports PQC on Avalanche. The Core wallet and all major Avalanche wallets (MetaMask, Rabby, etc.) use ECDSA secp256k1 exclusively.
Coverage basis: ECDSA secp256k1 only; no PQC wallet or custody support
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No PQC wallet path exists. Even if the protocol were upgraded to support PQC signatures, wallet and custody infrastructure would require separate migration.
bridge
Bridge verification and cross-chain dependencies — quantum-vulnerable signer set
Claim: The Avalanche Bridge relies on Intel SGX enclaves and a 6-of-8 Warden set using classical cryptography (ECDSA/TLS). Quantum compromise of bridge keys enables theft of all bridged assets.
Coverage basis: Intel SGX + classical ECDSA/TLS; quantum-vulnerable
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: The Avalanche Bridge uses Intel SGX + classical cryptography. Quantum compromise of bridge Warden keys enables theft of all bridged assets (BTC.b, WETH, etc.).
Assurance: Bridge code is audited by Halborn (classical scope only). SGX provides hardware isolation but does not protect against quantum attacks on the underlying ECDSA/TLS key material.
The bridge creates a two-way flow between Avalanche and quantum-vulnerable chains (Ethereum, Bitcoin). This triggers the 'Two-way bridge or wrapper allows value to flow back into a non-PQ-secure system without restrictions' Readiness & Risk Cap at 50, though the Stage 1 cap of 20 is more restrictive.
security_assessment
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: Avalanche's founder has publicly acknowledged the quantum threat and discussed specific vulnerabilities, but no formal public cryptographic inventory or quantum threat model has been published by Ava Labs or the Avalanche Foundation.
Coverage basis: Founder statements and informal discussion only
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: Third-party surveys (arXiv 2512.13333, BMIC, LayerQu) provide external cryptographic inventories but these are not project-authored. The founder's statements constitute acknowledgment but fall short of a formal inventory.
evidence_preparedness
Public evidence record supporting the assessment
Claim: No formal public evidence record supporting a quantum risk assessment has been published by the project. Third-party research and the open-source codebase provide indirect evidence.
Coverage basis: Third-party sources and open-source code only
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: score-reducing
Assurance: The open-source codebase and third-party analyses provide indirect evidence but Avalanche has not published its own evidence record with code references, specs, audits, or reproducible analytics for quantum risk.
migration_coverage
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: 0% of value-at-risk is protected by PQC or hybrid signatures. All native AVAX, staked AVAX, bridged assets, and DeFi TVL remain entirely quantum-vulnerable.
Coverage basis: 0% — no PQC protection exists
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No value-at-risk is protected. All on-chain assets are quantum-vulnerable with no migration, recovery, or protection mechanism.
Coverage <25% corresponds to implementation score 0.05 (1 point out of 20). C-Chain represents the majority of Avalanche's DeFi activity and value. All C-Chain accounts that have ever sent a transaction have permanently exposed public keys.
critical_wallets
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) on Avalanche have been migrated to or protected by PQC.
Coverage basis: 0% — no critical wallet migration
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No evidence of any exchange, custodian, foundation, or protocol migrating to PQC custody on Avalanche. No tooling exists to support such migration.
legacy_pools
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No systematic identification, measurement, deprecation, or migration of quantum-vulnerable accounts, UTXOs, or contracts has been performed.
Coverage basis: No legacy management exists
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No mechanism exists to identify, flag, deprecate, freeze, or migrate quantum-vulnerable legacy accounts. C-Chain's account model makes this particularly challenging since exposed public keys cannot be un-exposed.
migration_roadmap
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: No formal migration roadmap has been published. The founder mentioned lattice cryptography exploration in December 2024 but no ACP, specification, timeline, or activation criteria exist.
Coverage basis: Informal founder statements only
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: The founder's statements from December 2024 reference a lattice cryptography pull request that has not been verified in any public repository. No ACP, testnet, or formal proposal exists. Evidence confidence is Low.
Scored at 0.25 for informal public acknowledgment. No formal roadmap or ACP has been published.
migration_accessibility
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, and migration prompts
Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user warnings, education, or migration prompts exist in the Avalanche ecosystem.
Coverage basis: No migration tooling exists
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
migration_enforcement
Migration enforcement and coordination: enforcement mechanisms exist and exchange, custody, bridge, wallet, and infrastructure coordination prevents unsafe fallback into vulnerable systems
Claim: No migration enforcement mechanisms exist. There are no deprecation schedules, freeze capabilities, disabled legacy signing, or mandatory migration deadlines.
Coverage basis: No enforcement mechanisms
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
emergency_process
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No quantum-specific emergency disclosure, incident-response, or governance process has been published by Ava Labs or the Avalanche Foundation.
Coverage basis: No quantum-specific process
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Avalanche has general security contacts and governance processes but none specific to quantum threats. This is an assurance-only caveat per the Note-Only Caveat Rule — it does not create a current quantum-vulnerable path.
algorithm_selection
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: Avalanche uses no PQC algorithms in production. No NIST-standardized (FIPS 203/204/205) or standards-track PQC algorithms have been selected, specified, prototyped, or deployed.
Coverage basis: No PQC algorithm selection
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The founder mentioned lattice cryptography as a future direction. This could imply Dilithium (ML-DSA/FIPS 204) or Falcon (FN-DSA), but no formal algorithm selection has been made or published.
independent_audit
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: Classical audits exist (Halborn, Least Authority, OpenZeppelin) covering bridge, wallet, and smart-contract scope, but none address post-quantum readiness or PQC implementations.
Coverage basis: Classical audits only; no PQC audit
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Classical audits are stale (2024 and earlier) but relevant to the classical design. No PQC implementation exists to audit. Per QRI v3.1, a stale but relevant audit where the quantum-critical design remains verifiable from other evidence does not create a Readiness & Risk Cap by itself.
open_source
Open-source, reproducible implementation
Claim: avalanchego and related repositories are fully open-source (BSD-3-Clause). The classical cryptographic implementation is reproducible, well-documented, and actively maintained. No PQC implementation exists to evaluate.
Coverage basis: Open-source classical code; no PQC code
Implementation score: 0.25 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The open-source nature of the classical codebase is valuable for auditing existing quantum vulnerabilities. Scored at 0.25 for demonstrating strong open-source practices while acknowledging no PQC implementation exists to reproduce or verify.
parameter_agility
Parameter agility and future upgrade path are documented
Claim: No PQC parameter agility or future upgrade path has been documented. The subnet architecture provides theoretical flexibility but no concrete PQC upgrade path exists.
Coverage basis: No documented PQC upgrade path
Implementation score: 0 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: Avalanche's upgrade mechanism (network-wide mandatory upgrades via hard forks like Etna/Avalanche9000) demonstrates the technical capability for protocol-level changes, but no PQC-specific upgrade path has been documented.
stateful_signature_safety
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks for XMSS/LMS-style schemes
Claim: No stateful PQC signature schemes (XMSS/LMS) are deployed or planned on Avalanche. This subfactor is not applicable to the current production scope.
Coverage basis: No stateful signatures deployed
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
performance_analysis
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: No PQC performance or resource-impact analysis has been published by Ava Labs. Third-party research notes that lattice-based signatures are roughly 10x larger than ECC signatures, which could strain Avalanche's network bandwidth and throughput.
Coverage basis: Third-party analysis only
Implementation score: 0 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: note-only
Assurance: Third-party analysis from the arXiv survey notes Ava Labs' concern about lattice-based signature sizes potentially affecting performance and scalability. No formal performance analysis has been published by the project.
Per Note-Only Caveat Rule: the absence of a formal performance benchmark does not independently create a quantum-vulnerable path. However, it is relevant context for migration planning.
Report metadata