Aptos APT

Claim: Aptos has publicly documented its cryptographic primitives (Ed25519, ECDSA/secp256k1, BLS12-381, Groth16/BN254, Bulletproofs, KZG) and published quantum threat analysis via AIP-137, Alin Tomescu's research blog (April 2026), and Coinbase advisory board recognition.

Coverage basis: Official documentation, AIP specification, and research publications

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Cryptographic inventory is well-documented in official docs. Quantum threat analysis is discussed in AIP-137, the AIP author's April 2026 blog post, and Circle/Coinbase reports. A comprehensive formal threat model document systematically mapping all attack surfaces to assets and layers does not exist, reducing this from full credit.

Score of 0.75 reflects strong but informal threat analysis. The AIP author explicitly acknowledges Aptos is 'not PQ-secure' and provides a 3-phase roadmap for mitigation.

• https://aptos.dev/en/build/smart-contracts/cryptography
• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md
• https://alinush.github.io/post-quantum-aptos
• https://www.circle.com/en/blog/quantum-computing-and-blockchains

Claim: Evidence includes official documentation, open-source code (aptos-core), AIP-137 specification, mainnet explorer, multiple audit reports, and independent third-party analysis from Circle, Coinbase, and LayerQu.

Coverage basis: Multiple primary and secondary sources

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Code is reproducible from public repository. AIP-137 provides detailed specification. Third-party analysis from Circle, Coinbase advisory board, and LayerQu corroborates quantum vulnerability assessment. Existing audits are not quantum-focused.

Full credit for comprehensive evidence record across primary and secondary sources.

• https://github.com/aptos-labs/aptos-core
• https://explorer.aptoslabs.com/
• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md
• https://reports.zksecurity.xyz/reports/aptos-encrypted-mempool/

Claim: Production spend authorization uses Ed25519 and ECDSA/secp256k1 by default. SLH-DSA-SHA2-128s (FIPS 205) code is merged into mainnet release v1.41.5 behind feature flag 107 but is NOT enabled by governance. No user can create or use a PQ account on mainnet.

Coverage basis: Code merged but feature-gated; not accessible to mainnet users

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Active production spend authorization remains entirely Ed25519/ECDSA-only. SLH-DSA feature flag is not enabled on mainnet.

Assurance: SLH-DSA code is merged, unit-tested, and e2e-tested but feature-gated behind flag 107. AIP-137 itself states 'In the next year, there is no urgency to deploy this on any of the networks.' CLI support, indexer support, and developer documentation remain pending. No independent audit of the SLH-DSA implementation exists.

Score of 0.25 reflects that this is a public design/accepted proposal with merged code. It does not qualify as 'optional mainnet support' (0.75) because users cannot actually opt in — the feature is not enabled by governance.

• https://aptos.dev/en/build/smart-contracts/cryptography
• https://github.com/aptos-labs/aptos-core/releases/tag/aptos-node-v1.41.5
• https://github.com/aptos-labs/aptos-core/pull/18300
• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md
• https://alinush.github.io/post-quantum-aptos

Claim: All existing Aptos accounts store Ed25519/ECDSA public keys on-chain. Account addresses are derived from authentication keys. Public keys are long-exposed and visible to quantum adversaries. No PQ account rotation mechanism is available on mainnet.

Coverage basis: Protocol design — all accounts expose public keys on-chain

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All existing Aptos accounts have long-exposure Ed25519/ECDSA public keys enabling offline quantum key-recovery attacks.

Assurance: Public-key exposure is inherent in Aptos account model. Coinbase advisory board (April 2026) notes Aptos users can rotate to PQ keys without changing addresses, which is an architectural advantage for future migration. However, no PQ rotation mechanism is available on mainnet.

Aptos's account model allows key rotation without address change (public key is stored as metadata, not hashed into address). This is a recoverability advantage but does not protect currently exposed keys from quantum attack.

• https://aptos.dev/en/build/smart-contracts/cryptography
• https://explorer.aptoslabs.com/
• https://docs.dune.com/data-catalog/aptos/signatures

Claim: AptosBFT consensus uses BLS12-381 multi-signatures for validator authentication, block certification, and per-epoch batch threshold encryption. No PQ alternative is proposed or in development.

Coverage basis: Official documentation and source code

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Validator consensus uses BLS12-381 multi-signatures and per-epoch batch threshold encryption. A quantum adversary can forge validator signatures and break threshold encryption, compromising consensus finality.

Assurance: zkSecurity audit (March 2026) covered the encrypted mempool's BLS/KZG/DKG components and found classical security issues. Aptos Labs research discusses PQ consensus options (hash-based multi-signatures, MAC-based approach) but no AIP or implementation timeline exists. The AIP author rates PQ consensus as 'Difficulty: Low' for a protocol upgrade but no concrete proposal exists.

The AIP author notes consensus BLS 'can be changed to a PQ variant via a simple protocol upgrade' and cites Ethereum Foundation research on hash-based multi-signatures, but no formal proposal or implementation exists as of 2026-06-01.

• https://aptos.dev/en/network/nodes/validator-node/consensus
• https://aptosnetwork.com/whitepaper/aptos-whitepaper_en.pdf
• https://github.com/aptos-labs/aptos-core/pull/18442
• https://reports.zksecurity.xyz/reports/aptos-encrypted-mempool/

Claim: Core state integrity uses hash-based Merkle trees (quantum-safe). However, Groth16/BN254 ZKP verifier (Keyless accounts), Bulletproofs range proofs (Confidential Assets), and KZG commitments (encrypted mempool) are pairing-based and quantum-vulnerable.

Coverage basis: Protocol design and official documentation

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Groth16/BN254, Bulletproofs, and KZG commitments are quantum-vulnerable and can compromise state integrity in Keyless accounts, Confidential Assets, and encrypted mempool subsystems.

Assurance: Aptos Labs is researching PQ zkSNARK replacements (Spartan, WHIR, HyperPLONK) and notes Bulletproofs PQ migration 'is already in the works.' No deployed PQ alternatives exist. Circle research report (January 2026) confirms quantum vulnerability of Groth16.

Hash-based core state integrity (Merkle trees) is quantum-safe by design. The quantum vulnerability is in specific subsystems (Keyless ZKPs, confidential assets, encrypted mempool).

• https://aptos.dev/en/build/smart-contracts/cryptography
• https://alinush.github.io/keyless
• https://alinush.github.io/keyless-zkp
• https://www.circle.com/en/blog/quantum-computing-and-blockchains
• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-143-confidential-apt.md

Claim: Keyless accounts use Groth16/BN254 ZKPs. Confidential Assets (AIP-143) use Bulletproofs and Twisted ElGamal encryption. Encrypted mempool uses BLS threshold encryption and KZG commitments. All are quantum-vulnerable.

Coverage basis: Official documentation and AIPs

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All privacy and proof layers (Groth16, Bulletproofs, Twisted ElGamal, BLS threshold encryption, KZG) are quantum-vulnerable.

Assurance: Confidential APT (AIP-143, Accepted) is not yet on mainnet but is in testnet. Keyless accounts are live on mainnet. Aptos Labs rates PQ migration for Keyless as 'Difficulty: High' requiring both OIDC provider transitions and a PQ zkSNARK. For Confidential Assets, PQ soundness migration from Bulletproofs is 'in the works.'

Aptos has not deployed any PQ privacy or proof layer. The research roadmap outlines Phase 3 for quantum-proofing differentiating features but rates most as 'Difficulty: High.'

• https://alinush.github.io/keyless
• https://alinush.github.io/post-quantum-aptos
• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-143-confidential-apt.md
• https://reports.zksecurity.xyz/reports/aptos-encrypted-mempool/

Claim: P2P node identity uses classical cryptography but is not consensus, spend, bridge, or custody-critical. AptosBFT authenticates validators via BLS signatures on consensus messages, not via P2P-level identity.

Coverage basis: Protocol architecture

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: P2P transport uses TLS/noise with classical key exchange. A quantum adversary breaking P2P could observe or delay network messages but cannot forge consensus votes or steal assets without also breaking BLS or Ed25519 respectively.

Satisfied by design under QRI v3.1. Node identity is not consensus-critical because AptosBFT authenticates validators via BLS signatures on consensus messages, not via P2P-level identity.

• https://aptos.dev/en/network/nodes/validator-node/consensus

Claim: No PQ wallet, custody, or hardware-wallet support exists since SLH-DSA feature is not enabled on mainnet. Hardware wallet signing with SLH-DSA takes approximately 75 seconds on Trezor Model T per AIP-137 discussion.

Coverage basis: No PQ path available to users

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: AIP-137 notes hardware wallet signing with SLH-DSA takes ~75 seconds on Trezor Model T. No wallet (Petra, Martian, Pontem, etc.) has announced PQ support. This is expected since the feature is not enabled. Even after SLH-DSA is enabled, hardware wallet support remains a significant challenge.

Score of 0.00 because no PQ wallet path exists for mainnet users.

• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md

Claim: 0% of APT value is protected by PQ signatures. SLH-DSA feature flag is not enabled. All APT is held in Ed25519/ECDSA accounts with exposed public keys. All mainnet transactions use classical signature types.

Coverage basis: Mainnet transaction data and explorer

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: 0% of value-at-risk is protected. All APT in Ed25519/ECDSA accounts with long-exposure public keys.

Assurance: Dune Analytics and Aptos Explorer confirm all mainnet transactions use classical signature types (ed25519, secp256k1_ecdsa, multi_ed25519). No SLH-DSA transactions exist on mainnet.

Coverage <25% scores 1 out of 20 per QRI coverage thresholds. Aptos has 0% coverage. Even if SLH-DSA were enabled tomorrow, migration is opt-in and most value would remain vulnerable indefinitely.

• https://explorer.aptoslabs.com/
• https://docs.dune.com/data-catalog/aptos/signatures

Claim: No critical wallets (treasuries, exchanges, foundations, bridges, major protocols) are migrated to PQ protection. PQ accounts are not available on mainnet.

Coverage basis: No PQ path available

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No exchange, custodian, or foundation wallet has migrated to PQ because the feature is not enabled. Coinbase (April 2026) notes Aptos is 'well positioned' for transition but no migration has occurred.

Expected given that SLH-DSA is not enabled on mainnet.

Claim: All Ed25519/ECDSA accounts are implicitly vulnerable. Aptos has not published a formal inventory of quantum-vulnerable value pools or a deprecation/freeze policy for legacy accounts.

Coverage basis: Architecture documentation implies universal vulnerability

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Dune Analytics provides signature type breakdowns. Aptos Explorer shows account data. No formal quantum-vulnerable value inventory exists. Aptos architecture makes identification straightforward (all accounts are vulnerable) but no official measurement or deprecation plan has been published.

Score of 0.25 reflects that the vulnerable pool is implicitly known from architecture but not formally measured, deprecated, or targeted for migration.

• https://aptos.dev/en/build/smart-contracts/cryptography
• https://docs.dune.com/data-catalog/aptos/signatures

Claim: AIP-137 provides a detailed proposal for optional SLH-DSA-SHA2-128s accounts with specific milestones, feature-gating, gas pricing, and ecosystem impact analysis. Status: Accepted. The AIP author's blog post describes a 3-phase roadmap for full PQ readiness.

Coverage basis: AIP-137 (Accepted) and research publications

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: AIP-137 Status is Accepted with last-call-end-date 02/09/2026. Code merged to mainnet release v1.41.5. Phase 1 (consensus and account signatures) is partially implemented. Phase 2 (graceful fallbacks) and Phase 3 (privacy features) are research-stage only. No timeline for consensus PQ migration exists beyond informal blog discussion.

Score of 0.75 reflects a detailed roadmap with merged code but incomplete coverage: consensus migration, fallback mechanisms, and privacy-layer PQ remain research-stage or unaddressed by formal proposals.

• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md
• https://alinush.github.io/post-quantum-aptos

Claim: No PQ account creation, wallet tooling, or migration prompts are available to mainnet users since SLH-DSA feature flag is not enabled. CLI support, indexer support, and developer documentation are pending.

Coverage basis: Feature not activated on any network

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: AIP-137 milestones show CLI support, indexer support, and developer documentation as unchecked. TypeScript SDK support is marked complete in milestones but PR #802 is unchecked. Even with feature flag enabled, migration would be opt-in only with no user-facing prompts or warnings.

Score of 0.00 because no user can create or use a PQ account on mainnet.

• https://github.com/aptos-labs/aptos-core/pull/18300
• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md

Claim: No enforcement mechanisms exist. Classical signatures are not deprecated. No exchange, custody, bridge, or wallet coordination for PQ migration has occurred. AIP-137 is opt-in only.

Coverage basis: No enforcement or coordination activity

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: AIP-137 is opt-in only with no enforcement mechanism. There are no plans to deprecate Ed25519/ECDSA, freeze vulnerable accounts, or mandate migration. The AIP author's Phase 2 discusses 'graceful fallbacks' as a research topic (rated 'Difficulty: High').

No enforcement or coordination infrastructure exists. Even when SLH-DSA is enabled, classical accounts remain fully usable and are the default.

Claim: Aptos has general security processes (bug bounty, security contacts, governance process) but no published quantum-specific incident-response playbook.

Coverage basis: No published quantum-specific IR process

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: No quantum-specific incident-response playbook is publicly documented. The feature-gated SLH-DSA deployment could be activated quickly via governance if a quantum threat emerged, but no formal process for this scenario is published. Per QRI v3.1 Note-Only Caveat Rule, absence of a formal quantum-specific IR playbook is a note-only caveat unless it leaves a current quantum-vulnerable path unresolved.

Score of 0.00 reflects that no quantum-specific IR process is published. Treated as note-only per QRI v3.1. General security infrastructure exists but is not quantum-specific.

Claim: AIP-137 selects SLH-DSA-SHA2-128s (FIPS 205), a NIST-standardized stateless hash-based signature scheme relying solely on SHA2-256.

Coverage basis: AIP-137 specification and NIST FIPS 205

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: SLH-DSA is a conservative, well-reviewed NIST standard relying only on hash function security. AIP-137 explicitly justifies the choice over more 'aggressive' PQ schemes citing the Rainbow break. Not scored at 1.00 because it's not default, mandatory, or complete by design.

Strong algorithm choice. The conservative hash-based approach avoids novel assumptions.

• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md
• https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

Claim: No independent cryptographic audit of the SLH-DSA implementation in aptos-core has been published. Existing audits do not cover the quantum-critical scope.

Coverage basis: No quantum-focused audit exists

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: The zkSecurity audit (March 2026) covered encrypted mempool BLS/KZG/DKG — relevant to consensus but not to SLH-DSA. Formal verification (FMBC 2024) covered Aptos Framework correctness, not crypto primitives. Go SDK audit (January 2026) covered WebAuthn only. No independent review of the SLH-DSA implementation in aptos-crypto exists. Per QRI v3.1, audit absence is a confidence issue, not a score cap, since the implementation is open-source and has unit/e2e tests.

Score of 0.00 reflects no independent review. This is treated as confidence-only per QRI v3.1 since the implementation is verifiable from public code.

• https://reports.zksecurity.xyz/reports/aptos-encrypted-mempool/
• https://github.com/aptos-labs/aptos-go-sdk/blob/main/SECURITY_AUDIT_REPORT.md

Claim: SLH-DSA implementation is in the aptos-core public repository using the slh-dsa crate from RustCrypto/signatures ecosystem. Full source code is publicly available and reproducible.

Coverage basis: Public GitHub repository

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Implementation uses the well-established RustCrypto/signatures slh-dsa crate (pinned to v0.2.0-rc.4). Code includes unit tests for correctness, serialization, key generation, and deterministic signing. E2E smoke tests and API tests with golden files exist. Feature-gated with flag 107.

Full credit for open-source reproducible implementation.

• https://github.com/aptos-labs/aptos-core
• https://github.com/aptos-labs/aptos-core/commit/be9ff3ec5ea5cdb23e3096cc1220bcdb4893a917
• https://github.com/aptos-labs/aptos-core/pull/18300

Claim: AIP-137 acknowledges the need for faster, more succinct PQ schemes and uses feature-gated deployment. The crypto_algebra module in Move supports generic curve arithmetic for future flexibility.

Coverage basis: AIP-137 and Move framework design

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: AIP-137 explicitly plans for future PQ schemes: 'both can be mitigated against via adequate gas pricing and by adding support for faster, more succinct PQ schemes.' The crypto_algebra module's generic curve support enables future algorithm additions. However, no formal upgrade path specification or timeline exists for adding alternative PQ schemes.

Good design for agility. The feature-gated approach allows governance-controlled activation.

• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md
• https://aptos.dev/en/build/smart-contracts/cryptography

Claim: SLH-DSA-SHA2-128s is a stateless hash-based signature scheme (up to 2^64 messages). AIP-137 discusses side-channel protections: deterministic signing is used, hedged signing is disabled but 'could easily be enabled.'

Coverage basis: AIP-137 security considerations section

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: AIP-137 acknowledges: (1) hedged signing is disabled but 'could easily be enabled' for differential power/EM attack protection; (2) SLH-DSA is naturally free of secret-dependent branches (excluding Haraka variant, which is not used); (3) hardware wallet signing is very slow (~75 sec on Trezor). No formal side-channel evaluation has been performed.

Score of 0.50 reflects awareness and documentation of side-channel considerations but hedged signing not enabled and no formal evaluation.

• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md

Claim: AIP-137 provides benchmarks: 7,856-byte signatures, 5x slower verification than Ed25519, gas pricing analysis, and congestion mitigation strategy.

Coverage basis: AIP-137 benchmarks section

Implementation score: 0.75 · Evidence confidence: Medium

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: AIP-137 provides single-threaded x86_64 benchmarks and gas pricing (5x higher than standard). Signature size impact (82x larger than Ed25519) is documented with mitigation strategy (gas pricing + future faster PQ schemes). No mainnet-scale simulation or formal performance analysis under load exists. Hardware wallet benchmarks (Trezor: 75s/sig) are cited from external sources.

Good analysis for proposal stage. Treated as operational/product caveat per QRI v3.1 since it does not create a current quantum-vulnerable path.

• https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137-post-quantum-aptos-accounts-via-slh-dsa-sha2-128s.md