The keys documentation, the v5.0.0 release notes, the governance AZIPs and the aztec-packages source at the v5.2.0 tag together enumerate every primitive at protocol level, including the V5 changes (AZIP-8 hash-only master keys, Schnorr message hash moved to Poseidon2, cheaper in-circuit secp256r1). Deductions: the operator guide states that the validator BLS key signs proposals and attestations while the shipped code signs attestations with ECDSA secp256k1; the BN254 (not BLS12-381) choice for validator BLS keys and the AES-128-CBC mode of note encryption are documented only in source comments; the aggregation role of the registered BLS keys is not described as a finalized choice.

Every public-key surface is Shor-vulnerable. The symmetric layer (AES-128-CBC, Poseidon2, SHA-256) is Grover-weakened but not broken; it is the Grumpkin ECDH in front of the AES layer that turns every harvested note into a future plaintext. The V5 account-layer change (cheaper in-circuit ECDSA secp256r1) is another classical elliptic-curve discrete-log primitive, not a PQ option.

Every public-key primitive in active use sits in the discrete-log family (BN254 pairings for KZG and validator BLS keys, Grumpkin DL for ECCVM, IPA, Schnorr and note-encryption ECDH, secp256k1 and secp256r1 DL, BLS12-381 pairings at the EIP-4844 blob boundary). No lattice, hash-based, code-based, or isogeny family is deployed at any layer of the stack.

No NIST-PQC primitive (ML-DSA per FIPS 204, ML-KEM per FIPS 203, SLH-DSA per FIPS 205, FN-DSA / Falcon, not yet a finalized FIPS) is present.

Barretenberg ships internal correctness testing plus SMT-based circuit-checking tooling (acir_formal_proofs, smt_verification modules); no end-to-end machine-checked proof of the proving stack in the EasyCrypt sense was located. Poseidon2 is research-tier (cryptanalytic tier 4). Two successive proving-system critical vulnerabilities within five months: the v4 flaw found 2026-03-17 (disclosed 2026-03-27, details withheld until the V5 vote) was resolved by the V5 hard fork activated 2026-07-21, and a new critical flaw in the V5 proving system was found 2026-07-27 and disclosed 2026-08-07, allowing an attacker to construct a proof that passes verification for a transaction the network should reject. Prior exploitation cannot be determined, the fix is deferred to V6 later in 2026, and guidance is to treat V5 funds as exposed to protocol-level failure until incident response completes.

Account contracts authorize spends with Schnorr/Grumpkin, ECDSA secp256k1 or ECDSA secp256r1 keys, all Shor-vulnerable once the public key is known. The shipped account contracts verify the signature inside the client-side private proof and keep the signing public key in a private note that is delivered on-chain as a ciphertext to the owner (or commit to it through the instance's immutables hash), so the signing key is not harvested in the clear; a CRQC reaches it in two Shor-broken hops, first the note-encryption ECDH on the address point, then the signing-key discrete log. AZIP-8 (shipped in v5.0.0, live 2026-07-21) stores the nullifier, outgoing-viewing and tagging master public keys (npk_m, ovpk_m, tpk_m) only as Poseidon2 digests rather than raw Grumpkin points, an explicitly harvest-now-decrypt-later-motivated change that removes three master key types from passive on-chain harvesting; AZIP-10 applies the same digest treatment to the two new message-signing and fallback keys while noting that the message-signing master point leaks to counterparties. The incoming viewing key ivpk_m remains a raw Grumpkin point by design, native AA offers no selectable PQ scheme, and v4-era instances (2026-03-31 to 2026-07-21) published raw master points, so all active accounts remain recoverable post-Shor.

The Alpha network went live on Ethereum mainnet 2026-03-31, so the cold-key population is under five months old at evaluation. Cold balances are limited by definition, and two successive risk cycles suppressed them further: users were warned to withdraw V4 funds before the 2026-06-25 governance step, and current guidance is to treat V5 funds as exposed to protocol-level failure until the V6 fix ships.

Publicly observable long-lived signatures are the committee checkpoint attestations and proposals (ECDSA secp256k1, recovered and checked against the committee at L1) and the L1 staking, governance and portal transactions (ECDSA secp256k1). User-account signatures are consumed inside client-side private proofs and are never published, so the user-signature surface is not a public signature-on-public-message surface; its exposure runs through the encrypted key note described under 2a. Validator keys are epoch-public and the attestation set links every checkpoint to the committee that signed it, retroactively, so the consensus-side exposure is permanent.

Validator and prover p2p runs over libp2p with the Noise handshake (X25519 Diffie-Hellman) and yamux; node RPC runs over ordinary HTTPS/TLS. Both key agreements are Shor-vulnerable. No hybrid KEM is deployed at any transport surface.

Every encrypted note and message on Aztec is sealed by an ECDH key agreement on Grumpkin between a fresh ephemeral sender key and the recipient's address public key (derived from the incoming-viewing master key ivpk_m and the pre-address hash), app-siloed and expanded with Poseidon2 into AES-128-CBC keys and IVs (PKCS#7 padding), with the ephemeral public key's x-coordinate prepended to the ciphertext. The key-agreement half is a discrete-log instance directly broken by Shor; the AES layer is Grover-weakened, not broken, and is irrelevant once the shared secret is recovered. An adversary harvesting all ciphertexts plus all address points decrypts every shielded payload, sender, recipient, asset, amount and contract being called, once a CRQC against Grumpkin DL exists. There is no hybrid PQ KEM testnet, no announcement, no plan. AZIP-8 (v5.0.0) explicitly could not cover this surface: ivpk_m must remain a raw Grumpkin point for the encrypt-to-address scheme, so the note-encryption construction is unchanged.

Aztec runs full smart-contract execution under shielded private state on the live network. Private function calls are proven client-side (Chonk, Honk over BN254/Grumpkin) and only commitments, nullifiers and encrypted logs reach the chain; public function calls and L1 settlement data remain visible to sequencers and in the EIP-4844 blobs. The mixed private/public model is by design: private state is hidden from passive observers while public calls and L1 settlement remain fully visible.

Aztec official RPC plus community sequencer endpoints; concentration is not measured publicly. The validator set is large for the network's age (3,230 active attesters in an independent on-chain snapshot of 2026-08-16; more than 3,500 sequencers per the foundation's 2026-07-21 announcement) but a 48-member per-epoch committee (33-of-48 quorum) sees the private-transaction commitments, encrypted logs and full proof objects in the mempool, not their contents. Validator metadata retention policy is undeclared.

The canonical L1 portal between Ethereum and Aztec plus the third-party bridges Shield (human.tech) and TRAIN, both listed by the foundation as live on Alpha V5, are the bridge surfaces at evaluation date; a passive observer correlates deposits and withdrawals at the L1 boundary unless the user mediates via a third-party mixer. No LayerZero, Wormhole, CCIP or Axelar endpoint for Aztec was located.

Every historical shielded transaction de-anonymizes retroactively under a CRQC, through the key material rather than the proofs: the address public key of every account is on-chain as a Grumpkin point, so Shor recovers the address secret (and with it the incoming-viewing secret), which decrypts every note ever sent to that account (sender, recipient, asset, amount, contract); v4-era instances also published the raw nullifier master key npk_m, whose recovery lets an attacker compute nullifiers and link spends, the exact scenario AZIP-8 was written against. The zero-knowledge of the published MegaZK hiding-kernel proof is a simulation property that does not rest on the discrete-log assumption the way soundness does (a CRQC forges proofs, it does not open blinded commitments), so the de-anonymization path is the encryption and key layer, not the proof system. For the privacy-focused-chain profile this is the single largest structural exposure.

Aztec provides on-chain commit-reveal via the shielded note model (computational, capped at 10 by rubric) but does not run a structural mix-network with cover traffic or independent mix nodes. The privacy property is hidden-payload, not mix-net unlinkability.

Identical underlying construction to 2e. ECDH on Grumpkin against the address public key plus Poseidon2-derived AES-128-CBC, no PQ KEM, no announcement, no testnet, no plan. Unchanged by the V5 hard fork: AZIP-8's hash-only master keys explicitly exclude ivpk_m, the key this construction depends on.

A proof-system swap on Aztec remains structurally expensive: every privacy-side component (Chonk/Honk, HyperNova-style folding, Goblin Plonk, ECCVM, Translator, KZG over BN254, IPA over Grumpkin) is wired to the BN254/Grumpkin half-pairing cycle, and a FRI/STARK migration to a transparent-setup PQ-safe proof system would replace the entire proving stack and the Noir compiler backend, with no spec and no production instance. AZIP-8/AZIP-10, shipped in the V5 hard fork (2026-07-21), reworked the account/address-derivation layer in a breaking change explicitly motivated by a future-quantum-adversary threat model, demonstrating that Aztec can execute a quantum-motivated protocol change end to end at the key-representation layer without touching the underlying discrete-log primitives.

Native protocol-level account abstraction. Every account is a smart contract; the signature scheme is account-developer-chosen at deployment. Shipped reference contracts verify Schnorr/Grumpkin, ECDSA secp256k1 and ECDSA secp256r1 (P-256 / WebAuthn passkeys) inside private proofs; the docs list BLS and multi-signature as implementable; any future scheme, including ML-DSA, SLH-DSA or FN-DSA, becomes selectable if an in-circuit verifier exists in Noir. Account-contract migration is the strongest PQ-readiness primitive Aztec has. No PQ signature scheme is currently selectable at the account-contract layer (Noir and barretenberg expose no ML-DSA / SLH-DSA / FN-DSA blackbox or in-circuit verifier in production).

Sequence: Aztec Connect (sunset: deposits closed 2023-03-21, sequencer stopped 2024-03-31) → public testnet → adversarial testnet (2025-07-22) → Ignition Chain (November 2025) → Alpha network on Ethereum mainnet (2026-03-31) → Alpha V5 (AZUP-2, activated 2026-07-21 by on-chain token-holder governance; release train v5.0.0 published 2026-07-13, v5.0.1 2026-07-15, v5.1.0 2026-07-22, v5.2.0 2026-08-17, with rc.1 2026-06-15 and rc.2 2026-06-29 tagged as testnet release candidates). The v4 → V5 hard fork is the one governance-executed rollup hard fork on the live network since it went live; it bundled the v4 critical-vulnerability fix and four address-changing protocol changes including AZIP-8. Deductions: the mainnet fork record is one event deep, and the shipped release introduced its own critical proving-system flaw.

Hybrid PQ deployment at the proving layer would require running a FRI-based system in parallel with Honk; architecturally feasible but no announcement. Hybrid at the signature layer is structurally trivial via account abstraction but no PQ signature is selectable today.

Aztec uses no stateful hash signatures (XMSS / LMS / leanXMSS) at any layer. Stateless schemes only.

The per-epoch committee of 48 sequencer-validators attests with a floor(2/3·48)+1 = 33-of-48 quorum. At the v5.2.0 tag each checkpoint attestation is an individual ECDSA secp256k1 signature, recovered and matched to the committee index at L1; the BLS keys over BN254 registered at staking (with proof of possession, in a library written for key aggregation) do not sign attestations in production. No PQ-safe aggregation path declaration: no hash-based+SNARK plan, no authenticated-channels/MPC consensus, no staged-checkpoint PQ-sig path. Validator keys are epoch-public, so the consensus layer is flagged consensus-layer-exposed regardless of finality speed.

Zero PQC primitives signing any byte on Aztec mainnet.

Barretenberg and aztec-packages contain no ML-DSA / ML-KEM / SLH-DSA / FN-DSA / FRI implementation in any merged production path. Confirmed at evaluation date via repository-wide code search: zero hits for ml-dsa, dilithium, ml-kem, kyber, slh-dsa, sphincs and falcon; the only substantive post-quantum reference in the repository is the docstring of an alternative Poseidon2-permutation message-encryption option in aztec-nr, which states that it does not provide post-quantum privacy and points users who want decades-long privacy to the AES path that is already the default.

Validators register an ECDSA secp256k1 Ethereum key and a BLS key over BN254; no PQ key registration.

VOIDED to 0 per v3.1 (5a = 0). Aztec has no PQ-named milestones in its public roadmap regardless.

Ratio: 0/0 (no announcement, no shipment of any PQC primitive). AZIP-8's hash-only master keys are explicitly quantum-harvest-motivated but neither claim nor ship a post-quantum primitive, so they enter neither side of the ledger. Aztec is not engaged in PQ-washing; it is engaged in PQ-silence.

No PQ-signature footprint has been measured because none is deployed.

Top-3: Azguard (Aztec-native browser-extension wallet, alpha-testing), Obsidion (Aztec-native wallet), MetaMask (deposit-side only, L1; the foundation also lists a Nethermind wallet on Alpha V5). No PQC roadmap located for either Aztec-native wallet; MetaMask has no public PQC roadmap.

Top-3: the canonical Aztec L1 portal, Shield (human.tech) and TRAIN, the two third-party bridges the foundation lists as live on Alpha V5. No PQC roadmap located for any of the three. No LayerZero, Wormhole, CCIP or Axelar endpoint for Aztec was located.

No major custodian has launched Aztec custody at Alpha mainnet. Institutional custody integrations not yet announced. The funds-exposed guidance around the V5 proving-system vulnerability continues to suppress custodian onboarding.

Top-3: Aztec official RPC, community sequencer RPC endpoints. No HSM / TEE PQC posture published for Aztec validator/prover infra.

3,230 active attesters and 645.576 million AZTEC of active stake in an independent on-chain snapshot of 2026-08-16; more than 3,500 sequencers per the foundation's 2026-07-21 V5 announcement. Per-epoch committee of 48 sampled without replacement from the active set, seeded by L1 prevrandao fixed two epochs in advance; quorum 33 of 48. Mainnet activation threshold 200,000 AZTEC per validator, ejection at 100,000, four-day exit delay. The 2025-07-22 testnet-era figures (nearly 1,000 sequencers, 15,000 nodes, 50+ countries, six continents) are not current-network figures. Client diversity is a single-implementation issue.

Alpha V5 was activated on the live network 2026-07-21 by on-chain token-holder governance (AZUP-2), shipped on the published AZIP → AZUP → vote pipeline with the v4 critical-vulnerability fix bundled and with users warned ahead of the 2026-06-25 step to withdraw V4 funds. The counterweight is response latency to the successor flaw: the critical V5 proving-system vulnerability found 2026-07-27 has its fix deferred to V6, later in 2026, leaving the network running with a known critical flaw for a second consecutive release cycle.

Aztec Labs is the named coordinating organization. Its team page currently lists a Founder & CEO and a CTO as the named business and technical leads; the co-founder who once held the CEO title (a PLONK co-inventor) no longer appears on the team page and is quoted in the 2026-07-21 V5 announcement as a co-founder of the Aztec Foundation. No public explanation of the change was located, so leadership continuity is recorded as an observed fact with the cause unverified. No PQC-specific coordination lead is named.

The Aztec Connect sunset (deposits closed 2023-03-21, sequencer stopped 2024-03-31) demonstrated decommissioning and user-fund-withdrawal coordination over a 12-month window. The v4-to-V5 cycle is now a completed precedent: users were publicly warned to withdraw V4 funds before the 2026-06-25 governance step, whose execution made the vulnerability details public, and the governance-activated V5 fix then shipped. A second disclosure cycle is live for the V5 proving-system flaw (found 2026-07-27, disclosed 2026-08-07, interim funds-exposed guidance). A validator-infrastructure operator that announced a wind-down on 2026-07-16, asked delegators to exit by 2026-08-05 and planned to complete by 2026-08-15 still had seven attesters in the VALIDATING state on 2026-08-16 holding 1.386 million AZTEC, about 0.21% of active stake, a small-scale live stress test of the four-day exit flow. None of these is yet a coordinated cryptographic-primitive replacement under attacker pressure.

No canary, honeypot, rate-limiting rule, or cryptographic tripwire is documented. The v4-vulnerability disclosure functions as a public risk-bulletin but is not a mechanical tripwire.