DeFi protocol token
Aave AAVE
Aave is a production DeFi lending protocol with approximately $24B+ 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+ days of cumulative review for V4) confirm strong classical security but provide zero quantum assurance. Third-party analyses (PQBeat, StablePQC, Google Quantum AI) 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 the minimal baseline credit for having identifiable value-at-risk (a prerequisite for any migration scoring) combined with the complete absence of quantum security assessment, protection, migration mechanisms, or algorithm assurance. Aave's quantum readiness is entirely dependent on Ethereum's multi-year PQC migration roadmap (targeting 2029 for L1 upgrades), and even after Ethereum upgrades, Aave's governance multisigs, oracle dependencies, and cross-chain infrastructure will require independent migration efforts that have not been planned.
Quantum VulnerableGovernance Exposure CriticalInherits Host-Chain RiskERC-1271 CompatibleClassical-OnlyNo Quantum Roadmap
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
0 / 20
Migration Mechanism, Governance & Ecosystem Coordination
0 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
0 / 35
Security Assessment & Evidence Preparedness
0 / 5
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 Guardians (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. The project has not formally acknowledged quantum risk.
- Oracle dependency: Aave relies on Chainlink price feeds secured by ECDSA oracle operator keys. Quantum-forged oracle prices could trigger cascading liquidations across all Aave markets.
- Cross-chain attack surface: Aave is deployed on 19 networks with the Protocol Emergency Guardian controlling emergency functions on all of them. Quantum compromise of Guardian signers would affect all deployments simultaneously.
- 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.
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. A quantum attacker compromising 4 of 7 signers could simultaneously attack all deployments.
- 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 — only the ability to forge oracle signatures.
- 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 (Harvest Now, Decrypt Later).
- 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, with full execution-layer migration taking additional years). Aave has no influence over this timeline and has not begun preparation for the post-Ethereum-upgrade migration of its own infrastructure.
Assurance Notes
- Aave's classical security audits are extensive and current: Aave V4 underwent approximately 345 days of cumulative 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. The classical security program for V4 is among the most thorough in DeFi. However, none of the audits evaluated post-quantum cryptography, quantum threat models, or migration paths.
- Aave supports ERC-1271 for signature validation and is permissionless (accepts any msg.sender), making it technically compatible with ERC-4337/EIP-7702 smart contract wallets. This means that if Ethereum gains PQ account support, Aave users could theoretically use PQ-secured smart accounts to interact with the protocol — but this path is not tested, documented, or endorsed by Aave.
- Aave's Protocol Emergency Guardian was updated to a 4/7 multisig configuration in May 2026 with signer identities not publicly disclosed for operational security. While this reduces social-engineering risk, all signers still use ECDSA keys whose public keys are exposed on-chain through transaction history.
- 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 across all deployments.
- Aave V4 introduces a Cross-Chain Liquidity Layer (CCLL) and Hub-and-Spoke architecture with cross-chain messaging that depends on external bridges and oracles — all classically secured. Quantum compromise of bridge signers or oracle operators could cascade across the entire protocol.
- The Aave DAO governance process (AAVE/stkAAVE voting) relies on ECDSA-signed transactions from token holders. Quantum compromise of large delegate voting power could influence or execute malicious governance proposals.
- No formal quantum-specific incident response playbook exists. The Protocol Emergency Guardian could theoretically pause markets in a quantum emergency, but this capability has not been tested against quantum threat scenarios, and the Guardian itself is quantum-vulnerable.
- Aave has an active bug bounty program (up to $500K for V4 via Sherlock) covering classical vulnerabilities. No quantum-specific bounty scope has been defined.
Non-Scoring Caveats
- Aave's quantum readiness is fundamentally constrained by Ethereum L1's lack of PQC support; protocol-level migration cannot fully precede host-chain migration. Ethereum Foundation targets 2029 for L1 PQC upgrades, with full execution-layer migration taking additional years.
- Classical bug bounty programs (Immunefi, Sherlock) do not currently cover quantum-specific attack vectors.
- Aave supports ERC-1271 and is permissionless, meaning it could theoretically accept PQ smart accounts if/when Ethereum gains PQ account support. This future compatibility is a positive architectural property but provides zero current quantum protection.
- Aave's deployment on Aptos (which uses 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 an emergency response to a quantum incident, but the Guardian itself is quantum-vulnerable, making this a circular dependency.
- Third-party analyses (PQBeat, StablePQC, Google Quantum AI) independently confirm Aave's governance keys are among the highest-value quantum-exposed targets on Ethereum, with estimated governance-controlled TVL of ~$10B+.
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: Evidence of absence is strong: comprehensive review of Aave documentation, governance forum, GitHub repositories, and security pages reveals no quantum-specific assessment, inventory, or threat model. Third-party analyses (PQBeat, StablePQC, Google Quantum AI) have independently assessed Aave's quantum exposure but these are not project-sanctioned assessments.
Aave's documentation and security pages cover classical security extensively but contain no mention of quantum threats, post-quantum cryptography, or cryptographic migration planning.
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 (Trail of Bits, ChainSecurity, Blackthorn published Feb 2026). These provide strong classical evidence but no quantum-specific evidence.
While extensive classical audit reports exist, none address quantum threats, PQC algorithm review, or migration readiness.
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 (Solidity contracts in aave-v3-core and aave-v4 repositories) and mainnet transaction data. Aave V3 uses standard EVM ECDSA for all user operations; Aptos deployment uses EdDSA. Both are quantum-vulnerable.
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 architectural property 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. All Aave governance signers, protocol-controlled addresses, and active user positions have transacted and thus have exposed public keys. StablePQC independently confirms Aave's Pool Admin / Emergency Admin keys are among ~70 critical Ethereum contracts with exposed admin keys.
Unlike Bitcoin (where P2PKH addresses hide public keys until spend), Ethereum EOAs reveal public keys on first transaction. This is a host-chain property Aave cannot change independently.
Consensus
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: Aave is a smart-contract protocol without its own consensus layer. This subfactor is N/A for Aave's native architecture.
Coverage basis: No native consensus mechanism
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: While Aave has no native consensus, it inherits Ethereum's quantum-vulnerable consensus (BLS validator signatures). This inherited risk is noted but does not create a separate scorable Aave consensus layer.
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. State integrity is only as strong as the host chain's execution and consensus, both of which are quantum-vulnerable.
Aave V4's Hub-and-Spoke architecture introduces cross-chain state consistency requirements. The Hub maintains global accounting that Spokes read and update. There are 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 for signers. While this is good classical security practice, it provides no quantum protection — hardware wallets protect against remote key extraction but not against quantum cryptanalysis of on-chain signatures.
Aave's governance custody architecture includes: Protocol Emergency Guardian (4/7 multisig, 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.
Migration
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: Zero percent of Aave's ~$24B+ 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 ~$24B+ 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% — no PQC or hybrid-PQC path exists for any Aave user or governance operation.
Per QRI coverage thresholds (Section 9.3.1): <25% coverage = score 1 point out of 20 for this subfactor. Implementation Score = 1/20 = 0.05.
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), GHO Stewards (4 addresses), Rewards Multisig signers (4 addresses), Aave DAO Executor (short and long timelocks), and Aave 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 V4's development roadmap includes no quantum-related milestones.
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, 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 by Aave wallet integrations, or communicated to users.
The PQBeat tracker rates Aave V3 at Stage 1 (permissionless + ERC-1271 support), meaning users could interact via ERC-4337/EIP-7702 smart wallets. This architectural property is a positive foundation but provides zero current quantum protection.
Governance
Migration enforcement and coordination: enforcement mechanisms, exchange/custody/bridge/wallet coordination, unsafe-path blocking
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.
Aave's governance system (DAO voting + Guardian multisigs) could theoretically coordinate a quantum migration, but this would require: (1) Ethereum to first support PQ accounts, (2) Aave governance to pass proposals for protocol upgrades, (3) all multisig signers to migrate their keys, (4) oracle and bridge operators to migrate, and (5) user coordination. None of these steps have been planned or initiated.
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 (market pause, reserve freeze), quarterly readiness checks, and annual unannounced fire drills (per May 2026 update). These are strong classical operational practices but have no quantum-specific scope.
Aave's bug bounty program (up to $500K via Sherlock for V4) covers classical vulnerabilities only. No quantum-specific bounty scope or disclosure process has been defined.
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 in any Aave contract.
NIST published PQC standards in August 2024 (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA). Aave has not adopted or evaluated any of these standards.
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 (Section 7.4), stale or scope-mismatched audits that do not make a quantum-critical claim unverifiable should not reduce the QRI Score. Aave's classical-only posture is verifiable from public code and mainnet evidence regardless of audit scope.
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. The codebase is well-structured and extensively tested. However, this subfactor evaluates whether the quantum-critical implementation is open source — since no PQC implementation exists, there is nothing to evaluate.
Aave's open-source posture is commendable and would support future PQC implementation review, but currently provides no quantum readiness benefit.
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, parameter agility design, or cryptographic algorithm swap mechanism has been documented.
Aave's upgradeability via governance (Executor short timelock: 1 day delay, Executor long timelock: 7 day delay) provides a mechanism for future PQC upgrades, but this is a general protocol feature, not a documented quantum readiness path.
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: note-only
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 for the analysis to validate or invalidate.
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 that does not affect current quantum readiness scoring.
Report metadata