blockchain network
Aptos APT
Aptos is a Move-based PoS L1 blockchain that relies entirely on classical cryptography in production: Ed25519 for user transaction signatures, BLS12-381 for validator consensus authentication and per-epoch threshold encryption, and Groth16/BN254 for zero-knowledge proof verification. All active production cryptographic primitives are quantum-vulnerable to Shor's algorithm. AIP-137, authored by Aptos Labs Head of Cryptography Alin Tomescu and accepted by governance in early 2026, proposes adding SLH-DSA-SHA2-128s (FIPS 205, NIST-standardized hash-based PQ signature) as an optional post-quantum account signature scheme. The implementation code has been merged into aptos-core v1.41.5 (PRs #18293, #18300) behind feature flag 107, with unit tests, e2e smoke tests, and feature-gated gas pricing. However, the feature flag is NOT enabled on mainnet—no user can create or use a PQ account, and 0% of signing traffic or value-at-risk is protected. The Aptos account model provides a strong structural advantage: public keys are stored as account metadata with mutable authentication keys, allowing users to rotate to a PQ key without moving assets. This makes migration architecturally straightforward once the PQ scheme is activated. However, consensus (BLS12-381), ZKP verifiers (Groth16/BN254), Bulletproofs, and KZG commitments have no PQ migration proposals or implementation timelines. QRI Score of 20 reflects Stage 2 (Mitigation/Development): a well-designed PQ proposal exists with merged code and accepted governance, but no production users are materially protected against quantum attacks as of the evaluation date. The score is capped at 40 by both the Stage 2 cap and the Readiness & Risk Cap for active production spend authorization remaining entirely ECC-only.
Roadmap OnlyECC-Only Production
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
8 / 20
Migration Mechanism, Governance & Ecosystem Coordination
3.5 / 15
Migration Status & Value-at-Risk
1 / 25
Production Cryptographic Protection
3.5 / 35
Security Assessment & Evidence Preparedness
4 / 5
Critical Quantum Blockers
- Active production spend authorization remains entirely Ed25519/ECDSA-only on mainnet. SLH-DSA-SHA2-128s code (AIP-137) is merged but feature flag 107 is NOT enabled. No user can create or use a PQ account. All APT is held in quantum-vulnerable classical accounts.
- Validator consensus authentication uses BLS12-381 multi-signatures and threshold encryption with no PQ alternative proposed or implemented. A quantum adversary could forge validator signatures and compromise consensus finality.
- ZKP verifiers use Groth16/BN254 (quantum-vulnerable pairings). Bulletproofs range proofs and KZG commitments (encrypted mempool) are also quantum-vulnerable. No PQ migration proposal exists for any of these layers.
Key Risks
- All native APT and token value on Aptos mainnet is held in Ed25519/ECDSA accounts that are vulnerable to offline quantum key-recovery attacks. A sufficiently capable CRQC could derive private keys from exposed public keys and drain all classical accounts with no time constraint.
- Validator consensus finality can be compromised by forging BLS12-381 multi-signatures, enabling a quantum adversary to finalize fraudulent blocks or prevent honest finality.
- ZKP-based features (Keyless accounts via Groth16/BN254, Confidential Assets via Bulletproofs) and encrypted mempool (KZG commitments) rely on quantum-vulnerable pairing assumptions. A quantum adversary could forge ZK proofs to create counterfeit assets or decrypt mempool transactions.
- No migration, freeze, deprecation, or burn mechanism exists for quantum-vulnerable legacy accounts. If a CRQC emerges before migration is complete, all exposed classical value could be stolen with no protocol-level recourse.
- The AIP-137 SLH-DSA implementation has no independent cryptographic audit. The dependency on RustCrypto slh-dsa v0.2.0-rc.4 (community-maintained, pre-release) introduces supply-chain and implementation-correctness risk.
- CLI, indexer, and developer documentation gaps mean that even if feature flag 107 were enabled today, practical user migration tooling would be incomplete.
Assurance Notes
- AIP-137 (SLH-DSA-SHA2-128s) code is merged into aptos-core v1.41.5 (PRs #18293, #18300) behind feature flag 107, but the flag is disabled on all networks (mainnet, testnet, devnet) as of 2026-08-12.
- No independent cryptographic audit of the SLH-DSA implementation exists. zkSecurity audit (March 2026) covered encrypted mempool BLS/KZG/DKG components for classical security only, not PQ readiness.
- CLI support, indexer support, and developer documentation for SLH-DSA remain pending per AIP-137 milestones, preventing practical user PQ account creation even if feature flag 107 were activated.
- Validator consensus uses BLS12-381 multi-signatures and threshold encryption (AptosBFT v4/Jolteon) with no PQ migration proposal or implementation beyond informal blog discussion.
- ZKP verifiers (Groth16/BN254), Bulletproofs range proofs, and KZG commitments (encrypted mempool) are quantum-vulnerable with no PQ migration path proposed. AIP author rates these as 'Difficulty: High' with no timeline.
- Account model provides structural advantage: auth-key indirection (AIP-55) allows key rotation without asset transfer and supports future hybrid composition via MultiKey.
Non-Scoring Caveats
- Aptos account model stores public keys as account metadata with mutable authentication keys, enabling key rotation to PQ schemes without moving assets—a strong structural advantage for future migration, but currently not usable because no PQ key type is enabled on mainnet.
- AIP-137 author's blog (April 2026) states: 'Like all other blockchains that I know of, Aptos is currently not PQ-secure.'
- SLH-DSA is a stateless hash-based signature scheme (FIPS 205), avoiding the state-management risks of XMSS/LMS-style stateful signatures.
- The SLH-DSA implementation uses the RustCrypto slh-dsa crate (v0.2.0-rc.4), a community-maintained dependency without formal third-party audit.
- AIP-137 milestones still pending: CLI support, indexer support, developer documentation, TypeScript SDK full support.
- No formal quantum-specific incident-response playbook is documented.
- Feature flag 107 for SLH-DSA has no scheduled governance vote or activation timeline—PQ protection remains indefinitely deferred.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory and quantum threat model
Claim: Aptos official documentation details all supported signature schemes (Ed25519, ECDSA, MultiEd25519, MinPK/MinSig BLS on BLS12-381) and proof systems (Groth16/BN254, Bulletproofs). AIP-137 and the AIP author's research blog provide quantum threat context.
Coverage basis: Public documentation, accepted AIP, research blog
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Cryptographic inventory is well-documented in official docs. Quantum threat awareness is acknowledged through AIP-137 and author blog but is spread across multiple documents rather than consolidated as a single formal threat model.
The cryptographic inventory is comprehensive and publicly accessible. Quantum threat context is present but informal.
Security Assessment & Evidence Preparedness
Public evidence record
Claim: Aptos provides code references in official docs, an open-source repository (aptos-core), an accepted AIP-137 with detailed rationale, and the AIP author's research blog with cryptographic analysis.
Coverage basis: Open-source code, official docs, governance proposal
Implementation score: 0.75 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: Source code, specs, and governance artifacts are publicly verifiable. No independent audit of the SLH-DSA implementation limits confidence for audit-dependent claims.
Evidence record is strong for classical cryptography documentation and PQ proposal rationale.
Production Cryptographic Protection
Spend authorization / transaction signatures
Claim: All mainnet transaction signatures use Ed25519 or ECDSA (secp256k1). SLH-DSA-SHA2-128s code is merged into aptos-core v1.41.5 behind feature flag 107 but is NOT enabled on mainnet. No user can create or use a PQ account.
Coverage basis: ECC-only production spend authorization
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: Active production spend authorization remains entirely Ed25519/ECDSA-only. Feature flag 107 is disabled on mainnet. All APT is held in quantum-vulnerable classical accounts vulnerable to offline Shor attacks on exposed public keys.
Assurance: Production signature status confirmed by official docs, source code, on-chain feature flag state, and independent secondary analysis.
This is the most critical quantum vulnerability. Triggers the Readiness & Risk Cap of 40 for 'Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only.'
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design
Claim: Aptos stores public keys as account metadata with mutable authentication keys. The account::rotate_authentication_key function allows key rotation to a new scheme without moving assets. However, no PQ key type is currently enabled, so all accounts remain classically-keyed and quantum-vulnerable.
Coverage basis: Design supports PQ migration; PQ controls not yet active
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Account rotation mechanism is a live mainnet feature. PQ key-type support (SLH-DSA) is merged but disabled. The rotation mechanism supports PQ migration architecturally but provides no current quantum protection.
Implementation Score of 0.50 reflects that the rotation mechanism is a production feature that directly supports PQ/hybrid controls, but the PQ key type is not accessible. Long-exposure quantum-vulnerable ownership paths exist for all current accounts.
Production Cryptographic Protection
Consensus-critical authentication
Claim: AptosBFT v4 (Jolteon) consensus uses BLS12-381 multi-signatures for validator authentication, block certification, and an on-chain randomness beacon using BLS threshold signatures. No PQ alternative exists.
Coverage basis: BLS12-381-only consensus authentication
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: Validator consensus uses BLS12-381 multi-signatures with no PQ alternative. A quantum adversary could forge validator signatures and compromise consensus finality.
Assurance: zkSecurity audit (March 2026) covered encrypted mempool BLS/KZG/DKG components for classical security only. AIP author's blog discusses PQ consensus options but rates as research-stage only.
The AIP author describes consensus PQ migration as 'Difficulty: Low' for a protocol upgrade and cites Ethereum Foundation research, but no formal proposal, testnet, or implementation timeline exists.
Production Cryptographic Protection
State-integrity and data-availability mechanisms
Claim: Encrypted mempool uses KZG polynomial commitments (pairing-based, quantum-vulnerable). Batch threshold encryption uses BLS12-381 pairings. No quantum-safe alternatives exist.
Coverage basis: KZG/BLS-based state integrity mechanisms
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: KZG commitments and BLS-based threshold encryption used in encrypted mempool are quantum-vulnerable.
Assurance: zkSecurity audit (March 2026) found classical security issues in these components but did not evaluate quantum security.
The encrypted mempool is a differentiating feature of Aptos. Its KZG/BLS dependency creates a quantum-vulnerable data-availability surface.
Production Cryptographic Protection
Privacy and proof layers
Claim: Keyless accounts use Groth16 ZKP verification over BN254 pairing-friendly curve. Bulletproofs ZK range proofs are supported. Both pairing-based proof systems are quantum-vulnerable. AIP-143 (Confidential Assets) uses Bulletproofs and Twisted ElGamal encryption.
Coverage basis: Groth16/BN254 and Bulletproofs—quantum-vulnerable
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Groth16/BN254 ZKP verifier and Bulletproofs are quantum-vulnerable. A quantum adversary could forge ZK proofs for Keyless accounts or Confidential Assets.
Assurance: No audit covers the quantum security of Groth16/BN254 or Bulletproofs in Aptos production. PQ migration for Bulletproofs is 'in the works' per AIP author but not deployed.
Affects Keyless accounts (AIP-61) and Confidential APT (AIP-143). The AIP author's blog acknowledges the difficulty of migrating these proof systems to PQ alternatives.
Production Cryptographic Protection
P2P transport, node identity, and peer authentication
Claim: No evidence of PQ protection for P2P transport or node identity layers. Since spend authorization is not PQ-secure, P2P is not satisfied by design under the QRI spec rules.
Coverage basis: No PQ P2P protection; spend-auth not PQ-secure
Implementation score: 0 · Evidence confidence: Low
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: No public documentation specifically addresses P2P quantum security. P2P node identity is not directly custody-critical, but the satisfied-by-design condition requires PQ spend authorization which is not met.
Low-priority subfactor (weight 2). P2P is applicable because the QRI spec's satisfied-by-design condition for P2P is not met.
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows
Claim: No evidence of PQ wallet, custody, HSM, or hardware-wallet support for Aptos. SLH-DSA key generation and signing require CLI/SDK support which is pending per AIP-137 milestones.
Coverage basis: No PQ wallet/custody support
Implementation score: 0 · Evidence confidence: Medium
Issue classification: operational/product caveat · Score treatment: score-reducing
Assurance: AIP-137 milestones list CLI support, indexer support, and developer documentation as pending. No wallet, custody, or HSM vendor has announced SLH-DSA support for Aptos.
Even if feature flag 107 were enabled, practical PQ account creation and signing would be limited without CLI, SDK, wallet, and custody tooling.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected
Claim: 0% of APT circulating supply or any economically relevant value is protected from quantum key-recovery attacks. All accounts use Ed25519 or ECDSA keys. No PQ accounts exist on mainnet. Feature flag 107 is disabled.
Coverage basis: 0% coverage—all value in classical accounts
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: cap-applying
Quantum blocker: 0% of value-at-risk is protected. All circulating APT and token value is vulnerable to offline quantum key-recovery attacks.
Assurance: Coverage confirmed by on-chain feature flag state (107 disabled) and independent verification.
Aptos is not PQ-native—it launched with classical accounts and all value remains in classical accounts.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) are migrated to PQ. No PQ wallet support exists.
Coverage basis: No critical wallet migration
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No public evidence of any exchange, custodian, foundation, or protocol treasury migrating to PQ on Aptos.
Critical wallet migration is impossible until feature flag 107 is enabled and CLI/SDK/wallet tooling is complete.
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts identified, measurable, deprecated, migrated, frozen
Claim: The existence of quantum-vulnerable classical accounts is publicly acknowledged through AIP-137 and the author's research blog. However, no measurement, deprecation, freeze, or migration mechanism exists for legacy vulnerable accounts.
Coverage basis: Vulnerability acknowledged; no measurement or deprecation
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: No on-chain measurement, tagging, deprecation, freeze, or burn mechanism exists for quantum-vulnerable legacy accounts.
The vulnerability is publicly identified and acknowledged (roadmap/proposal level), but no measurement or deprecation mechanism is implemented.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap
Claim: AIP-137 (accepted) provides a roadmap for PQ account signatures. The AIP author's blog outlines a 3-phase plan: (1) consensus and account signatures, (2) graceful fallbacks, (3) privacy features. Phase 1 is partially implemented. Phases 2 and 3 are research-stage only.
Coverage basis: Accepted AIP with merged code; incomplete roadmap
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: The roadmap covers account signatures (partial implementation) but consensus, ZKP, and privacy layers have no formal proposals, timelines, or implementation.
Score of 0.50 reflects that a detailed proposal exists with merged code for one layer (accounts), but other critical layers are unaddressed.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults
Claim: No PQ account creation is available to users on mainnet. Feature flag 107 is disabled. CLI support, indexer support, and developer documentation are pending.
Coverage basis: No accessible PQ migration path
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Account rotation mechanism is a live mainnet feature. The structural design supports PQ migration without asset movement. But no PQ key type is available to rotate to.
Score of 0.25 reflects that the design supports migration (beyond zero) but no PQ account creation, wallet tooling, or migration prompts exist for users.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination
Claim: No enforcement mechanisms, deprecation deadlines, legacy signing restrictions, freeze capabilities, or mandatory migration requirements exist. No exchange, custody, bridge, wallet, or infrastructure coordination for PQ migration is evidenced.
Coverage basis: No enforcement or coordination
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: No public evidence of exchange, custody, or infrastructure coordination for PQ migration.
The absence of enforcement mechanisms means that even after PQ accounts become available, vulnerable classical accounts can persist indefinitely.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process
Claim: Aptos has a functioning AIP governance process (used for AIP-137). No quantum-specific incident-response playbook or emergency disclosure process is documented.
Coverage basis: General governance exists; no quantum-specific IR
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The AIP governance process provides a mechanism for emergency upgrades via feature flags. No quantum-specific incident-response playbook is documented.
Score of 0.25 reflects that general governance exists and was used for AIP-137, but no quantum-specific emergency process is documented.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms
Claim: AIP-137 proposes SLH-DSA-SHA2-128s, which is NIST-standardized as FIPS 205. The algorithm relies solely on SHA2-256 hash function security. Code is merged into aptos-core but behind disabled feature flag 107.
Coverage basis: NIST-standardized algorithm; code merged, not enabled
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: none · Score treatment: not applicable
Assurance: SLH-DSA-SHA2-128s is FIPS 205 standardized (August 2024). Algorithm choice is conservative and well-motivated. However, the implementation is not independently audited and the feature flag is disabled.
Score of 0.50 reflects that a NIST-standardized algorithm is selected and implemented in merged code, but it is not accessible on mainnet.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit
Claim: No independent cryptographic audit of the SLH-DSA-SHA2-128s implementation in aptos-core has been published. Existing audits do not cover the quantum-critical SLH-DSA scope.
Coverage basis: No independent audit of quantum-critical implementation
Implementation score: 0 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: confidence-only
Assurance: Under QRI v3.1, audit absence for an otherwise verifiable open-source implementation is a confidence issue, not a score cap.
The SLH-DSA implementation has unit tests and e2e smoke tests but no independent cryptographic review.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: Aptos-core is fully open-source (Apache 2.0). The SLH-DSA implementation is in the public aptos-core repository with unit tests, e2e smoke tests, API tests, and feature-gated gas pricing.
Coverage basis: Fully open-source implementation
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: Code is publicly accessible, well-structured, and includes tests. The implementation can be independently verified and reproduced.
Full credit for open-source reproducibility.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path
Claim: Aptos account model supports authentication key rotation, providing a mechanism to upgrade to new key types or parameters. No formal parameter agility specification exists for SLH-DSA specifically.
Coverage basis: Rotation mechanism provides upgrade path
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The authentication key rotation mechanism provides structural parameter agility. No documented process exists for SLH-DSA parameter upgrades specifically.
Score of 0.25 reflects that the rotation mechanism exists as a general upgrade path.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, hardware-wallet, HSM, or custody implementation risks
Claim: SLH-DSA is a stateless hash-based signature scheme (FIPS 205), avoiding the state-management risks of XMSS/LMS. However, no side-channel analysis, fault-injection assessment, or HSM/custody security evaluation has been published.
Coverage basis: Stateless algorithm avoids stateful risks; other risks unassessed
Implementation score: 0.25 · Evidence confidence: Low
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: SLH-DSA is stateless by design, which eliminates the state-reuse vulnerability class. No side-channel or hardware security evaluation has been published.
Score of 0.25 reflects that the algorithm choice avoids the most critical stateful-signature risks, but other risks are unassessed.
Algorithm & Implementation Assurance
Performance and resource-impact analysis
Claim: AIP-137 documents that SLH-DSA signatures are 7,856 bytes (82× larger than Ed25519) with 32-byte public keys. Feature-gated 5× higher gas cost is implemented.
Coverage basis: Preliminary performance analysis in AIP-137
Implementation score: 0.5 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: AIP-137 provides signature size comparison and gas cost analysis. No formal benchmark of block validation impact exists.
Score of 0.50 reflects that performance impact is documented at proposal level with concrete metrics.
Report metadata