DeFi protocol token
Aave AAVE
Aave is a production DeFi lending protocol with approximately $10B+ in TVL across 19+ networks and no quantum readiness whatsoever. The protocol inherits Ethereum's ECDSA-based security model for all user operations and relies on ECDSA multisigs for all governance, emergency, and risk-management functions. Aave has published no quantum risk assessment, no cryptographic inventory, no PQC migration roadmap, and deploys no post-quantum or hybrid cryptography. Extensive classical security audits (345+ cumulative days of review for V4) confirm strong classical security but provide zero quantum assurance. Third-party analyses (PQBeat Stage 1, StablePQC, Google Quantum AI March 2026) independently confirm Aave's governance keys are among the highest-value quantum-exposed targets on Ethereum. The protocol's ERC-1271 compatibility means it could theoretically accept PQ smart accounts in the future, but this provides no current protection. QRI Score of 1 reflects minimal baseline credit for having identifiable value-at-risk combined with the complete absence of quantum security assessment, protection, migration mechanisms, or algorithm assurance.
Category breakdown
QRI Factors
Critical Quantum Blockers
- All spend authorization is ECC-only: Aave inherits Ethereum's secp256k1 ECDSA for all user transactions (supply, borrow, withdraw, repay, liquidate) across all EVM deployments. No PQC or hybrid-PQC path exists for any user operation.
- Governance multisigs are entirely ECDSA-based: Protocol Emergency Guardian (4/7 multisig across 19 networks), Risk Stewards (1-of-1), Governance Emergency Guardian (5/9), GHO Stewards (3/4), and Rewards Multisig (3/4) all use standard ECDSA keys with public keys permanently exposed on-chain.
- No public cryptographic inventory or quantum threat model has been published by Aave or the Aave DAO.
- Oracle dependency: Aave relies on Chainlink price feeds secured by ECDSA oracle operator keys. Quantum-forged oracle prices could trigger cascading liquidations.
- Long-exposure public keys: All Aave governance signers, large depositors, and protocol-controlled addresses that have transacted have permanently exposed ECDSA public keys on-chain — harvestable now for future quantum decryption.
- Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path.
Key Risks
- Governance compromise is the most severe quantum risk: The Protocol Emergency Guardian (4/7 multisig) can pause markets, freeze reserves, and execute emergency actions across all 19 Aave deployments. All signer public keys are permanently exposed on-chain. Third-party estimates place Aave's governance-controlled TVL at ~$10B+.
- Risk Steward single point of failure: The 1-of-1 Risk Steward multisig (Chaos Labs) controls supply caps, borrow caps, and collateral risk parameters. Compromise of this single ECDSA key could manipulate lending parameters to enable protocol draining.
- Oracle manipulation via quantum key recovery: Aave relies on Chainlink price feeds signed by ECDSA oracle operators. Quantum-forged oracle prices could artificially deflate collateral values or inflate debt values, triggering mass liquidations. This attack requires no direct interaction with Aave's contracts.
- Cross-chain cascade risk: With 19 network deployments sharing the same governance infrastructure, a quantum compromise on one network's Guardian deployment could provide a template or access path to others. The V4 Cross-Chain Liquidity Layer introduces additional cross-chain dependencies secured by classical bridges.
- Long-exposure harvest attack surface: Every Aave governance signer, protocol-controlled address, and large depositor that has ever transacted has permanently exposed their ECDSA public key on-chain. These keys are harvestable today for future quantum decryption.
- No migration path exists: Even if Ethereum implements PQ accounts, Aave's governance multisigs, oracle integrations, and cross-chain infrastructure have no documented plan for key rotation or cryptographic upgrade.
- Aave cannot migrate independently of Ethereum: As a smart-contract protocol without its own consensus layer, Aave's user-facing quantum security is entirely dependent on Ethereum's PQC migration timeline (EF targets 2029 for L1 upgrades). Aave has no influence over this timeline and has not begun preparation for the post-Ethereum-upgrade migration of its own infrastructure.
Assurance Notes
- Classical security audits are extensive and current: Aave V4 underwent approximately 345 cumulative days of security review across Trail of Bits, ChainSecurity, Blackthorn, Certora formal verification, Enigma Dark invariant testing, and a 936-participant Sherlock contest (Dec 2025–Jan 2026). No high-severity classical vulnerabilities were identified. These audits provide strong classical assurance but zero quantum-specific coverage.
- Aave V4 launched on Ethereum mainnet on March 30, 2026, with a Hub & Spoke architecture. None of the audits evaluated post-quantum cryptography, quantum threat models, or migration paths.
- Aave supports ERC-1271 for signature validation and is permissionless, making it technically compatible with ERC-4337/EIP-7702 smart contract wallets. If Ethereum gains PQ account support, Aave users could theoretically use PQ-secured smart accounts — but this path is not tested, documented, or endorsed by Aave.
- Third-party analyses (PQBeat, StablePQC, Google Quantum AI March 2026) independently confirm Aave's governance keys are among the highest-value quantum-exposed targets on Ethereum. PQBeat rates Aave V3 at Stage 1 (permissionless + ERC-1271 compatible, but ECDSA governance). StablePQC identifies Aave Pool Admin keys as EXPOSED among ~70 critical Ethereum contracts.
- The Protocol Emergency Guardian was updated to a 4/7 multisig in May 2026 with signer identities not publicly disclosed. Hardware wallet requirements apply but only for ECDSA keys — no quantum protection.
- Aave's Risk Stewards operate under a 1-of-1 multisig controlled by Chaos Labs — a single ECDSA key with authority over supply/borrow caps and collateral risk parameters. This is a quantum-critical single point of failure.
- No formal quantum-specific incident response playbook exists. The Protocol Emergency Guardian could theoretically pause markets, but the Guardian itself is quantum-vulnerable.
- Aave has an active bug bounty program (up to $500K for V4 via Sherlock). No quantum-specific bounty scope has been defined.
- Aave is exploring deployment on Circle's Arc blockchain, which published a post-quantum security whitepaper in May 2026. This may create future PQ integration opportunities but provides no current protection.
Non-Scoring Caveats
- Aave's extensive classical security audits (Trail of Bits, ChainSecurity, Blackthorn, Certora, Sherlock contest) are current and of very high quality for classical vulnerabilities but provide zero quantum assurance. Per the Note-Only Caveat Rule, the absence of quantum audit does not make the classical-only architecture unverifiable.
- Aave supports ERC-1271 and is permissionless, meaning it could theoretically accept PQ smart accounts if/when Ethereum adds PQ account support. This future compatibility is a positive architectural property but provides zero current quantum protection.
- Aave's deployment on Aptos (EdDSA) does not change the quantum vulnerability profile — EdDSA (Curve25519) is equally vulnerable to Shor's algorithm as ECDSA.
- The Protocol Emergency Guardian's ability to pause markets could theoretically serve as emergency response to a quantum incident, but the Guardian itself is quantum-vulnerable, creating a circular dependency.
- Aave is exploring deployment on Circle's Arc blockchain, which published a post-quantum security whitepaper in May 2026. This may create future PQ integration opportunities but is not yet live and provides no current quantum protection.
- Signer identity non-disclosure for the updated 4/7 Protocol Emergency Guardian (May 2026) reduces social-engineering risk but does not protect against quantum key recovery from on-chain transaction signatures.
Evidence record
Claims and Caveats
Assessment
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: Aave has not published any quantum-specific cryptographic inventory or quantum threat model.
Coverage basis: No quantum assessment published by Aave or Aave DAO
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No public cryptographic inventory published
Assurance: Comprehensive review of Aave documentation, governance forum, GitHub repositories, and security pages reveals no quantum-specific assessment. Third-party analyses (PQBeat, StablePQC, Google Quantum AI) have independently assessed Aave's quantum exposure but these are not project-sanctioned assessments.
Assessment
Public evidence record supporting the assessment
Claim: No quantum-specific evidence record has been published by Aave.
Coverage basis: No project-published quantum evidence
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No quantum evidence record published
Assurance: Classical audit reports are publicly available and current. These provide strong classical evidence but no quantum-specific evidence.
Transaction
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: All Aave user transactions rely on host-chain ECDSA (EVM) or EdDSA (Aptos) signatures. No PQC or hybrid-PQC path exists.
Coverage basis: Host-chain inherited cryptography
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All spend authorization is ECC-only with no PQC or hybrid-PQC path
Assurance: Verifiable from public source code and mainnet transaction data. Aave V4's SignatureGateway uses EIP-712 meta-transactions but still uses ECDSA recovery.
Aave supports ERC-1271 for signature validation and is permissionless, meaning it could theoretically accept PQ smart accounts if/when Ethereum adds PQ account support. This provides zero current protection but may facilitate future migration.
Account
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths
Claim: All Aave user accounts are standard Ethereum EOAs or smart contract wallets. Public keys are permanently exposed on first transaction with no rotation mechanism.
Coverage basis: Ethereum account model inherited
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All user and governance accounts have permanently exposed ECDSA public keys with no rotation mechanism
Assurance: Ethereum's account model permanently exposes public keys on first spend. StablePQC independently confirms Aave's Pool Admin/Emergency Admin keys are among ~70 critical Ethereum contracts with exposed admin keys.
Consensus
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: Aave is a smart-contract protocol without its own consensus layer.
Coverage basis: No native consensus mechanism
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
State
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: Aave's protocol state is maintained through standard Solidity state variables enforced by EVM execution. No independent cryptographic commitment schemes, accumulators, or state-binding mechanisms exist.
Coverage basis: EVM-enforced accounting
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: State integrity relies entirely on quantum-vulnerable EVM execution and host-chain consensus
Assurance: Aave's internal accounting is enforced by Solidity code executed on the EVM. There are no ZK commitments, nullifiers, accumulators, or pairing-based state-binding mechanisms native to Aave.
Aave V4's Hub-and-Spoke architecture introduces cross-chain state consistency requirements with no quantum-safe cross-chain state verification mechanisms.
Privacy
Privacy and proof layers are quantum-safe where applicable
Claim: Aave has no privacy layer, ZK proofs, shielded transactions, note encryption, viewing keys, or stealth addresses.
Coverage basis: No privacy features
Implementation score: 0 · 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: Aave is a smart-contract protocol without its own P2P network. Users interact through standard Ethereum RPC nodes.
Coverage basis: No independent P2P network
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Custody
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: All Aave governance multisig signers use standard ECDSA wallets. No PQ/hybrid custody paths exist.
Coverage basis: ECDSA-only governance custody
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All governance multisig signers use ECDSA wallets with exposed public keys
Assurance: The May 2026 Protocol Emergency Guardian update specifies hardware wallet requirements and strict operational security practices. While this is good classical security practice, it provides no quantum protection. The updated 4/7 multisig signer identities are not publicly disclosed but their ECDSA public keys remain visible on-chain from transaction history.
Aave's governance custody architecture includes: Protocol Emergency Guardian (4/7, 19 networks), Governance Emergency Guardian (5/9), Risk Stewards (1-of-1, Chaos Labs), GHO Stewards (3/4), and Rewards Multisig (3/4). All use standard ECDSA. The 1-of-1 Risk Steward is a single point of failure for quantum attacks on risk parameters.
Migration
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: Zero percent of Aave's ~$10B+ TVL is quantum-protected. All value is held in ECDSA-secured accounts on quantum-vulnerable host chains.
Coverage basis: 0% protected value
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 0% of value-at-risk is quantum-protected; all ~$10B+ TVL is ECDSA-secured
Assurance: Third-party analyses (StablePQC, PQBeat) estimate Aave's governance-controlled exposure at ~$10B+. Google Quantum AI (March 2026) identifies Aave Pool Admin/Emergency Admin among ~70 critical Ethereum contracts with exposed admin keys. Coverage is verifiably 0%.
Per QRI coverage thresholds (Section 9.3.1): <25% coverage = score 1/20 for this subfactor. Implementation Score = 1/20 = 0.05. This represents the baseline recognition that value-at-risk exists and can be measured, not that any protection is in place.
Migration
Critical wallets migrated, protected, or inherently PQ-native
Claim: No Aave governance, treasury, or protocol-controlled wallets have been migrated to PQC. All critical wallets use ECDSA.
Coverage basis: No critical wallet migration
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All critical governance and protocol wallets remain ECDSA-only with exposed public keys
Assurance: The May 2026 Protocol Emergency Guardian rotation updated signers but retained ECDSA-based multisig architecture. No PQC migration was considered or proposed.
Critical wallets include: Protocol Emergency Guardian signers (7 addresses), Governance Emergency Guardian signers (9 addresses), Risk Steward (1 address, Chaos Labs), GHO Stewards (4 addresses), Rewards Multisig signers (4 addresses), Aave DAO Executor (short and long timelocks), and treasury/collector contracts. All are ECDSA-based.
Migration
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: Aave has not identified, measured, deprecated, or frozen any quantum-vulnerable pools or accounts. No legacy vulnerability inventory exists.
Coverage basis: No legacy pool identification
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No quantum-vulnerable pool identification, measurement, or deprecation
Assurance: Aave has legacy deployments (V1, V2) with significant dormant value. V2 markets are still active on Ethereum mainnet. No quantum-specific assessment of legacy deployment exposure has been conducted.
Aave V1, V2, and V3 deployments coexist. V2 still has active markets. No migration plan exists to deprecate or freeze quantum-vulnerable legacy positions.
Governance
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Aave has no quantum migration or protection roadmap. No public proposal, timeline, or plan exists.
Coverage basis: No roadmap
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No quantum migration roadmap exists
Assurance: Comprehensive review of Aave's governance forum, documentation, blog, and GitHub repositories confirms zero discussion of quantum migration planning.
Aave's roadmap dependency on Ethereum means even a hypothetical Aave quantum migration plan would be gated on Ethereum's PQC upgrade timeline (EF targets 2029 for L1). However, Aave has not even begun scoping what protocol-specific migration would entail for governance multisigs, oracle integrations, and cross-chain infrastructure.
Governance
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, or user education exists for Aave.
Coverage basis: No migration accessibility
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No PQ migration accessibility, tooling, or user education
Assurance: Aave is permissionless and ERC-1271 compatible, which means it could theoretically accept PQ smart accounts without protocol changes. However, this path is not documented, tested, supported, or communicated to users. PQBeat rates Aave V3 at Stage 1 (permissionless + ERC-1271) confirming this architectural property exists but provides zero current protection.
Governance
Migration enforcement and coordination: enforcement mechanisms exist and exchange, custody, bridge, wallet, and infrastructure coordination prevents unsafe fallback
Claim: No migration enforcement mechanisms exist. No exchange, custody, bridge, or wallet coordination for quantum migration has occurred.
Coverage basis: No enforcement or coordination
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No quantum migration enforcement or coordination mechanisms
Assurance: The Protocol Emergency Guardian can pause markets and freeze reserves, which could theoretically be used in a quantum emergency. However, this has never been tested or planned for quantum scenarios, and the Guardian itself is quantum-vulnerable.
Governance
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No quantum-specific incident response process exists. The Protocol Emergency Guardian can pause markets but has no quantum-specific procedures.
Coverage basis: No quantum incident response
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No quantum-specific incident response or disclosure process
Assurance: Aave's classical incident response includes the Protocol Emergency Guardian, quarterly readiness checks, and annual unannounced fire drills. These are strong classical operational practices but have no quantum-specific scope.
Algorithm
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: Aave uses no PQC algorithms. All cryptography is classical (ECDSA secp256k1, EdDSA Curve25519, keccak256).
Coverage basis: No PQC algorithms deployed
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No NIST-standardized or reviewed PQC algorithms in use
Assurance: Source code review confirms Aave uses only standard Ethereum cryptographic primitives (ECDSA via ecrecover, keccak256 for hashing). No PQC signature verification, key encapsulation, or hybrid constructions exist.
Algorithm
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: All Aave audits cover classical security only. No quantum-specific cryptographic audit exists.
Coverage basis: Classical audits only
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Aave V4 underwent approximately 345 days of cumulative security review: Trail of Bits, ChainSecurity, Blackthorn, Certora formal verification, Enigma Dark invariant testing, and a 936-participant Sherlock contest. All are current (2025-2026) and of exceptional quality for classical scope, but none address quantum threats. Per the Note-Only Caveat Rule, the absence of quantum audit does not make the classical-only findings unverifiable.
Algorithm
Open-source, reproducible implementation
Claim: Aave's smart contracts are open source (MIT/BUSL licensed). However, there is no PQC implementation to be open source.
Coverage basis: Classical code is open source; no PQC code exists
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: score-reducing
Assurance: All Aave smart contracts are publicly available on GitHub with verified deployments on Etherscan. However, since no PQC implementation exists, there is nothing quantum-specific to evaluate for open-source reproducibility.
Algorithm
Parameter agility and future upgrade path are documented
Claim: No parameter agility or PQC upgrade path has been documented for Aave.
Coverage basis: No PQC upgrade path
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: No documented parameter agility or PQC upgrade path
Assurance: Aave's governance system allows protocol upgrades via DAO vote and timelock execution, providing a theoretical upgrade path. However, no specific PQC upgrade path has been documented. The governance upgrade path is itself quantum-vulnerable.
Algorithm
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks are considered
Claim: No PQC stateful-signature schemes are in use. No quantum-specific side-channel or custody risk analysis exists.
Coverage basis: No PQC signature implementation
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Algorithm
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 conducted for Aave.
Coverage basis: No performance analysis
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Aave V4 includes gas snapshot testing for all operations. This provides a baseline for classical performance but no PQC-specific analysis. Per the Note-Only Caveat Rule, the absence of PQC performance analysis is note-only since no PQC path exists.
PQC signature sizes (ML-DSA: ~2.4KB vs ECDSA: 64 bytes) would significantly impact gas costs for Aave operations if implemented. This is a future concern.
Report metadata