Aptos publishes a Move-level cryptography reference naming Ed25519, secp256k1, secp256r1, BLS12-381, Ristretto255, Groth16 over BN254, Bulletproofs, ElGamal and the hash natives with module paths; the transport primitive (Noise/X25519) and the SLH-DSA authenticator are documented in aptos-core source rather than in that reference. The state Merkle tree (Jellyfish) and transaction accumulator use SHA3-256 throughout.

Every signature, key-exchange, and zk-SNARK primitive currently in production on mainnet is quantum-vulnerable. The one PQ-safe primitive in the shipped node software (SLH-DSA-SHA2-128s) is enabled on devnet only.

One PQ family exists in the shipped node software: hash-based SLH-DSA-SHA2-128s per FIPS 205 (finalized standard), merged via AIP-137 and decoded ENABLED on devnet 2026-08-19, the only Aptos network where a PQ account scheme is accepted by the VM. Zero PQ families are callable on testnet or mainnet (flag 107 decoded DISABLED on both, same date). Scored 4 of 20: partial credit toward the hash-family tier, discounted because the family is usable on a development network only, and no second PQ family (lattice or code-based) has any implementation code in the repository (zero ML-DSA implementation PRs; ML-DSA is roadmap text inside AIP-137 only).

No PQ primitive in production on mainnet. The devnet-enabled SLH-DSA-SHA2-128s maps to NIST security category 1 per FIPS 205, and AIP-137 documents the parameter set explicitly. Scored 2 of 20: the category mapping is published and attaches to a scheme live on devnet, but no production mainnet PQ primitive exists.

Production primitives use blst (BLS12-381) and the dalek family (ed25519-dalek / curve25519-dalek for Ed25519 and Ristretto255), widely-reviewed constant-time libraries. Move has formal-verification tooling (Move Prover); the cryptographic primitive wrappers themselves are not machine-verified. The SLH-DSA path wraps the RustCrypto slh-dsa crate pinned to a release-candidate version (=0.2.0-rc.4 in the workspace Cargo.toml, set by the Feb 2026 maintenance PR) with deterministic signing; No third-party audit of the Aptos SLH-DSA integration is published. No PQ primitive in production on mainnet.

Aptos accounts expose the authentication key as part of account state. The auth key is a hash and can be rotated independently of the address, but on the first signed transaction the public key is attached to the transaction record and the address-to-pubkey link becomes permanent. Value at stake: stablecoin circulating supply on Aptos of about 1.23 billion USD (DefiLlama, 2026-08-19); DeFi TVL on the same tracker is about 58 million USD, compared with about 1.0 billion USD in July 2025.

Mainnet genesis 2022-10-12 (block 1 timestamp on the archival fullnode), so about 3.9 years of history at scan date. Auth-key indirection means dormant accounts that have never signed have not revealed a public key (auth key is SHA3-256(pubkey || scheme byte)), but any account that has signed even once is exposed. Lower historical surface area than older chains.

All historical Ed25519 signatures and BLS12-381 consensus aggregates are forgeable post-Shor. The AIP-79 randomness beacon's BLS12-381 weighted-VUF outputs are likewise forgeable by an attacker recovering the epoch's shared secret. No retroactive proof-of-possession or hash-binding mechanism documented.

Validator and full-node P2P transport uses a stripped-down Noise_IK_25519_AESGCM_SHA256 handshake: X25519 ECDH (Shor-vulnerable) with AES-256-GCM AEAD and SHA-256, per the aptos-crypto noise module. Public RPC endpoints terminate standard TLS with classical key exchange. No documented hybrid PQ KEM deployment on validator transport, RPC endpoints, or bridge relay channels.

Pseudonymous transparent ledger. Move resource model exposes object ownership and balances. No native shielded pool, but Confidential APT (AIP-143) is live on mainnet as an opt-in confidential-balance feature (enabled for APT by governance proposal 188, resolved 2026-04-24): transfer amounts and balances are hidden under Twisted ElGamal over Ristretto255 with zero-knowledge range proofs, while sender and recipient addresses remain visible by design; a governance-assigned auditor key can be configured, and the AIP states none is assigned at launch. Verified on-chain 2026-08-19: confidentiality enabled for APT, not emergency-paused, roughly 13,730 APT held in confidential balances, so usage is real but a small fraction of supply. Transaction-graph visibility is unchanged; only amounts are hidden, and only for opt-in users.

Public RPC providers include Aptos Labs (fullnode endpoints), NodeReal and Ankr; LayerQu has no traffic-share measurement and does not credit or debit concentration from evidence. Mempool gossip observable. No published validator-metadata retention policy, which zeroes that component.

Bridges into Aptos verified: LayerZero (Aptos is a listed LayerZero endpoint; the former Aptos Bridge domain now redirects to Stargate, and the LayerZero transfer API lists Aptos) and Wormhole (Aptos token bridge maintained in the Wormhole repository). Both are observable by passive cross-chain indexers, allowing source-to-destination linking. No privacy bridge in mainstream use.

Aptos Keyless (AIP-61) uses Groth16 over BN254 with OIDC JWTs. Shor on BN254 breaks Groth16 soundness, which is a forgery risk scored under Forge exposure; it does not by itself unmask Keyless identities, because the identity commitment is a Poseidon hash blinded by a 256-bit pepper and Groth16's zero-knowledge property does not rest on a hardness assumption. The retroactive de-anonymization surface is Confidential APT (AIP-143, live on mainnet): its Twisted ElGamal balance encryption is over Ristretto255, so every confidential balance and transfer amount harvested today becomes decryptable once Shor breaks the curve. The confidentiality feature has no post-quantum shelf life and no PQ migration plan of its own. For the transparent default ledger there is little left to de-anonymize retroactively.

No protocol-level mixnet or commit-reveal shuffle. Application-layer privacy primitives are limited.

AIP-55 (Accepted, created 2023-10-16) introduced SingleKey and MultiKey containers over an AnyPublicKey / AnySignature enum, designed so new signature schemes can be added without breaking existing accounts; the SLH-DSA-SHA2-128s variant was added to that enum by PR #18300. Live precedent for adding schemes without a hard fork: Keyless (AIP-61, feature flag 46 enabled on mainnet) and the AIP-75 prover service. AIP-104 (Account Abstraction) proposes a second, Move-code-defined agility path; the AIP remains Draft status, while the derivable-account-abstraction feature flag (88) reads enabled on mainnet in LayerQu's 2026-08-19 decode.

Authentication-key indirection is the structural advantage: the account address is fixed at creation while the auth key (a hash binding pubkey plus scheme byte) is mutable. account::rotate_authentication_key (proven, signed RotationProofChallenge) and account::rotate_authentication_key_call (unproven, for schemes such as passkeys that cannot produce proofs of knowledge) allow scheme migration without asset transfer, and the OriginatingAddress reverse-lookup preserves recovery; safety hardening of that address mapping is proposed in AIP-101, which remains Draft status. Account-model component 17. The seed-rebind floor (6) is present for single-key Ed25519 accounts but subsumed by the deployed native rotation (MAX selects 17), and no post-quantum seed-knowledge rebind verifier has shipped, so the PQ-rebind bonus is 0. Dim 2 Forge exposure unchanged. 17.

Active AIP cadence with on-chain governance: 203 mainnet governance proposals as of 2026-08-19, including framework upgrades v1.41 through v1.48 in 2026. AIP-55, AIP-61, AIP-75 and AIP-131 (Single-Hop Block Time, Status Final) all landed without contested forks within 3 years.

Architectural support exists via MultiKey (AIP-55), which composes K-of-N over heterogeneous AnyPublicKey schemes including the SLH-DSA-SHA2-128s variant. AIP-137 as drafted is a replacement scheme: an account selects either Ed25519 or SLH-DSA-SHA2-128s, not a mandatory AND-hybrid. No AIP mandates a hybrid Ed25519 AND SLH-DSA composition with commit-to-hash-of-both-pubkeys, but a holder can natively construct a 2-of-2 MultiKey {Ed25519 + SLH-DSA-SHA2-128s}; any authenticator carrying an SLH-DSA leg is gated behind feature flag 107, decoded 2026-08-19 as enabled on devnet and disabled on testnet and mainnet, so the hybrid is constructible on devnet but not usable where value lives.

SLH-DSA is a stateless hash-based scheme (FIPS 205). No state-management burden. Default 15 applies.

Aptos uses BLS12-381 multi-signature aggregation (minimal-pubkey-size variant with proof-of-possession, over blst) in AptosBFT consensus voting and a BLS12-381 weighted PVSS / weighted VUF for the AIP-79 on-chain randomness beacon. AIP-137 covers account signatures only. No published spec, testnet, or mainnet pilot for a PQ aggregation path at consensus; validator keys are epoch-public, so the chain is consensus-layer-exposed regardless of finality speed.

0% of mainnet signing traffic uses PQ primitives. Feature flag 107 (SLH_DSA_SHA2_128S_SIGNATURE) decoded by LayerQu on 2026-08-19 from the on-chain features bitvector on all three networks, using the byte-index/bit-mask logic in features.move: ENABLED on devnet, DISABLED on testnet and mainnet. No PQ account type is accepted on mainnet until governance enables it, and the public mainnet-proposals repository contains no proposal to do so (203 proposals as of 2026-08-19).

SLH-DSA-SHA2-128s is merged into aptos-core (PR #18293, aptos-crypto crate, merged 2025-12-10; PR #18300, VM transaction authenticator, feature gate, 5x base gas, API/protobuf/indexer types, merged 2026-01-15) alongside the existing ed25519, multi_ed25519, secp256k1_ecdsa, secp256r1_ecdsa, bls12381 and ristretto255 modules, and the code path is maintained: a Feb 2026 dependency bump (PR #18787, pinning the slh-dsa crate to =0.2.0-rc.4) was cherry-picked to the aptos-release-v1.41 release branch (PR #18791). The mainnet gas schedule already carries the slh_dsa_sha2_128s.base parameter (framework upgrades v1.41 onward). On-chain decode 2026-08-19 shows the path ACTIVE on devnet and inactive on testnet and mainnet. Scored 3 of 15: merged, release-branch-maintained, and live on one public development network, but devnet enablement follows from the client's default feature set rather than a governance activation, the path covers account authentication only (consensus voting stays BLS12-381), and it is disabled on both networks that carry value.

No validator runs a PQ consensus key. AptosBFT consensus voting and the randomness beacon both use BLS12-381 across the entire active validator set (90 validators, verified on-chain 2026-08-19).

VOIDED to 0 per v3.1 because 5a = 0. AIP-137 is Accepted and merged, but mainnet enablement (feature flag 107) has no enforcement-mechanism-backed dated milestone: no flag day, no mandatory sunset, no on-chain governance proposal filed to flip it on. The AIP's own deployment text says there is no urgency to deploy on any network in the next year and targets only a preliminary devnet deployment, which is the state observed.

Announcements: AIP-137 (created 2025-12-09) and December-2025 press coverage (Yahoo Finance, Cointelegraph, Bitget News, all verified retrievable 2026-08-19) carry nine distinct forward-dated primitive-level claims, enumerated in the pqc_washing block. Shipped: 0 mainnet PQ bytes signed. The AIP's milestone list also marks TypeScript SDK support complete while the released SDK carries only an enum placeholder annotated 'Full implementation not yet available in this SDK' and the SDK pull request is an open draft (verified 2026-08-19), an announced-vs-shipped gap at the integration layer.

SLH-DSA-SHA2-128s signatures are 7,856 bytes vs 64-byte Ed25519, a ~123x raw-byte multiplier (AIP-137 states 82x on a signature-plus-public-key baseline; either figure is far above the >38x threshold). Verification is about 4.9x slower on the AIP's own benchmarks (294 us vs 60 us; the AIP rounds this to 5x). The published mitigation is a feature-gated 5x base gas charge (slh_dsa_sha2_128s.base = 138,000,000 vs min_transaction_gas_units = 27,600,000 internal gas units) on top of the existing per-byte intrinsic gas above the 600-byte cutoff, plus deferring to faster PQ schemes later; there is no signature-aggregation or compression plan, and a 2-of-2 hybrid carries this cost on top of the 64-byte Ed25519 signature.

Wallets assessed: Petra (built by Aptos Labs), OKX Wallet (OKX Connect is one of the two wallet-adapter standards named in the Aptos developer docs), Pontem Wallet. None publishes a PQ roadmap or a commitment to support AIP-137 once activated. The official TypeScript SDK (v7.3.1), the integration surface these wallets build against, carries only an SLH-DSA-SHA2-128s enum placeholder annotated 'Full implementation not yet available in this SDK' as of 2026-08-19; the implementation sits in an open draft pull request, so no wallet can add support through the standard SDK path yet.

Bridges verified: LayerZero / Stargate (Aptos is a listed LayerZero endpoint and transfer-API chain), Wormhole (Aptos token bridge in the public Wormhole repository). Neither has published a PQ aggregation-key or PQ-validator roadmap for Aptos.

Custodian / exchange surfaces verified to carry APT on 2026-08-19: BitGo (public sdk-coin-apt module), Kraken (APTUSD), Binance (APTUSDT), OKX (APT-USDT). None of them publishes an Aptos-specific PQ key-management product or PQ roadmap statement. Per v3.1 rule: chains mandating SLH-DSA without a documented custodian-MPC alternative are capped at 15/25; AIP-137 itself lists thresholdizing hash-based signatures as an open question.

RPC providers verified: Aptos Labs fullnodes, NodeReal, Ankr. No PQ-TLS / hybrid-KEM termination on public RPC endpoints. HSM/TEE chain not documented as PQ-pilot anywhere in the stack. The machine-readable OpenAPI specification served by mainnet fullnodes already defines SLH-DSA-SHA2-128s public-key and signature schemas, and the indexer protobuf carries the type, so RPC-facing vendors have a discoverable integration surface; none has published a PQ roadmap.

Active validator set verified on-chain 2026-08-19: 90 validators, none pending in or out. Per-validator counted stake is capped at 50,000,000 APT and validator-set entry requires 1,000,000 APT (StakingConfig, verified on-chain), structurally bounding single-validator voting power in any future PQC enablement vote. Derived from the live voting-power vector: 14 validators together exceed one third of voting power (consensus-stake Nakamoto coefficient 14); the largest single validator holds 3.5% and no validator sits at the cap; 752.1M APT of voting power against 1,207.4M APT total supply (62.3%). Hosting-provider and jurisdiction concentration were not measurable from a primary source and are not scored. One-client stack (aptos-core).

AIP-131 (Single-Hop Block Time) carries Status Final and a published staged rollout plan (mainnet from September 2025); AIP-55, AIP-61, AIP-75 and the 2026 run of monthly framework-upgrade proposals (v1.41 to v1.48) show consistent governance throughput. No deadline-driven crypto migration yet executed.

Aptos Labs cryptography is led by a Head of Cryptography who authored AIP-137 and co-authored AIP-143; the AIP's commit history shows no second author or working group. The Aptos Foundation operates governance and ecosystem coordination. Mandate is partially implicit, there is no published PQ migration working group charter, but the named lead and AIP authorship trail are clear.

No documented coordinated cryptographic change executed under active adversarial pressure.

No canary, honeypot, rate-limited spending rule, or in-consensus cryptographic tripwire documented. The public security policy and bug-bounty program are general-purpose, not PQ-specific.