Aztec docs and the public Yellow Paper enumerate every primitive at protocol level. Deductions only for the fact that the sequencer-attestation aggregation scheme is described as future optimization rather than a finalized choice.

Every public-key surface is Shor-vulnerable; the symmetric layer (AES-128) is itself Grover-soft because the key length is 128, not 256.

Every public-key primitive in active use sits in the discrete-log family (BN254 pairings, Grumpkin DL, secp256k1 DL, BLS12-381 pairings). No lattice, hash-based, code-based, or isogeny family is deployed at any layer of the stack.

No NIST-PQC primitive (ML-DSA, ML-KEM, SLH-DSA, Falcon/FN-DSA) is present.

Barretenberg has internal correctness testing; no machine-checked formal verification in the Formosa-Crypto / EasyCrypt sense for the proving stack; Poseidon is research-tier (cryptanalytic Tier 4). Material 2026 finding: the March 17 2026 critical vulnerability in Alpha v4 affects the proving system as a whole and is not mitigated by committee re-execution; fix is bundled into v5 (planned July 2026). Aztec asks users not to deposit funds they are not willing to lose. This is a live, undisclosed-by-design vulnerability against the live Alpha mainnet.

Account contracts hold balances under Schnorr/Grumpkin or ECDSA secp256k1 keys. Every account public key that has signed a transaction is on-chain in the encrypted-note tree but the public-key material visible to the sequencer/attester layer is Shor-vulnerable. Mitigation: native AA enables per-account signature-scheme migration. Without a deployed PQ scheme, all active accounts are forgeable post-Shor.

Alpha mainnet launched 2026-03-31, so cold-key population is ~1 month at evaluation. Cold balances are limited by definition. The user-warning around the v4 vulnerability materially suppresses balances at risk during the Alpha period.

Every historical sequencer attestation (ECDSA secp256k1) and every historical user-account signature (Schnorr/Grumpkin or ECDSA) is a publicly observable signature on a publicly observable message at the L1 boundary. Privacy-chain context makes this sharper: the sequencer-attestation set links every checkpoint to the committee that signed it, retroactively.

Validator p2p, RPC, and prover-coordination channels use classical TLS with X25519/ECDH key agreement, Shor-vulnerable. No hybrid KEM deployed at any transport surface.

Every encrypted note on Aztec is sealed by an ECDH key-agreement on Grumpkin between sender and recipient (using the recipient's incoming viewing public key, ivpk) producing a shared secret, with AES-128-GCM applied to the note payload using a derived key. Both halves of the construction are HNDL-broken under Shor: the ECDH key agreement on Grumpkin is a discrete-log instance directly broken by Shor; the resulting AES-128 has only 64-bit Grover security. An adversary harvesting all note ciphertexts plus all ivpks now decrypts every shielded payload, sender, recipient, asset type, amount, contract being called, once a CRQC against Grumpkin DL exists. There is no hybrid PQ KEM testnet, no announcement, no plan.

Aztec is the only mainnet L2 with full smart-contract execution under shielded private state. Private function calls are committed via UltraPLONK proofs over BN254; public function calls are visible on the L1 settlement layer. The mixed model is by design, the strongest currently-deployed tx-graph privacy on Ethereum, behind only Monero (hidden) and Zcash (shielded-only) in the structural taxonomy.

Aztec official RPC plus community sequencer endpoints; concentration is not measured publicly but the 3,500+ sequencer / ~1,000-validator-set / 50+ prover topology is materially more decentralized than typical L2s. The per-epoch committee of 48 staking validators (33-of-48 attestation threshold) sees private-tx commitments but not contents. Validator metadata retention policy undeclared at mainnet.

The L1 bridge between Ethereum and Aztec is the single bridge in scope at Alpha mainnet; a passive observer trivially correlates deposits and withdrawals at the L1 boundary unless the user mediates via a third-party mixer. No major third-party general-purpose bridges (LayerZero, Wormhole, CCIP, Axelar) operate Aztec endpoints at evaluation date.

All historical shielded-tx privacy-side commitments use UltraPLONK over BN254 (Shor-break-via-pairings) and Pedersen commitments over Grumpkin (Shor-break-via-DL); the proof system is zero-knowledge under DL/pairing assumptions, which fall to Shor. Every historical shielded transaction retroactively de-anonymizes under CRQC. For privacy-focused-chain profile this is the single largest structural exposure.

Aztec provides on-chain commit-reveal via 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-Grumpkin + AES-128-GCM, no PQ KEM, no announcement, no testnet, no plan.

A proof-system swap on Aztec is structurally expensive: every privacy-side primitive (UltraPLONK, Honk, Goblin PLONK, ECCVM, Translator) is wired to the BN254/Grumpkin half-pairing cycle. A FRI/STARK migration to a transparent-setup PQ-safe proof system is theoretically possible (Plonky2/Plonky3, Stwo, etc.) but would replace the entire proving stack and the Noir compiler backend. No spec, no production instance.

Native protocol-level account abstraction. Every account is a smart contract; signature scheme is account-developer-chosen at deployment (Schnorr, ECDSA, BLS, multi-sig today; any future scheme tomorrow including ML-DSA / SLH-DSA / Falcon if Noir gains the precompile). Account-contract migration is the strongest PQ-readiness primitive Aztec has. No PQ signature scheme is currently selectable at the account-contract layer (Noir + barretenberg do not yet expose ML-DSA / SLH-DSA / Falcon precompiles or in-circuit verifiers in production).

The network shipped Aztec Connect (2022) → sunset Aztec Connect (March 2024) → public testnet → adversarial testnet → Ignition Chain → TGE (Jan 2026) → Alpha mainnet (March 2026) → planned v5 (July 2026, with the v4 critical-vulnerability fix bundled). Coordination demonstrated at small scale; the v5 fork will be the first under-mainnet-load coordinated upgrade.

Hybrid PQ deployment at the proving layer would require running a FRI-based system in parallel with PLONK/Honk; architecturally feasible but no announcement. Hybrid at the signature layer is structurally trivial via AA 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 33-of-48 threshold. BLS keys are registered by validators specifically to enable signature aggregation as a future optimization, but at evaluation date attestation aggregation uses ECDSA / individual signatures. No PQ-safe aggregation path declaration: no hash-based+SNARK plan, no authenticated-channels/MPC consensus, no staged-checkpoint PQ-sig path.

Zero PQC primitives signing any byte on Aztec mainnet.

Barretenberg and aztec-packages contain no ML-DSA / ML-KEM / SLH-DSA / Falcon / FRI implementation in any merged production path.

Validators register ECDSA + BLS12-381 keys; 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). 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: Obsidion (Aztec-native, passkey/social login), Azguard (Aztec-native browser extension), MetaMask (deposit-side only, L1). Neither Aztec-native wallet has published a PQC roadmap; MetaMask has no public PQC roadmap.

Top-3: Aztec L1 bridge (canonical), no major third-party bridges live at evaluation date. LayerZero / Wormhole / CCIP / Axelar have no Aztec endpoints at Alpha; the canonical L1 bridge has no PQC roadmap.

No major custodian has launched Aztec custody at Alpha mainnet. Institutional custody integrations not yet announced. The user-warning around v4 vulnerability also suppresses custodian onboarding.

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

~1,000-strong sequencer validator set, 3,500+ sequencer participants across testnet/mainnet phases, 50+ provers, 15,000 nodes across 50+ countries / 6 continents. Per-epoch committee of 48 selected via Fisher-Yates shuffle seeded by L1 RANDAO. 33-of-48 attestation threshold. Strong by L2 standards; client diversity is a single-implementation issue.

The v5 release (July 2026) will be the first coordinated upgrade under live mainnet load with a known undisclosed critical vulnerability. Cadence has been demonstrated at testnet scale; mainnet record begins with the v5 fork.

Aztec Labs is the named foundation; CEO (PLONK co-inventor) and President are named technical and business leads. Public mandate is the Aztec roadmap. No PQC-specific coordination lead is named.

The Aztec Connect sunset (March 2024) demonstrated decommissioning capability and user-fund-withdrawal coordination over a 12-month window. The currently-active precedent is the v4-vulnerability response: public disclosure + user warning + scheduled v5 fix. Neither 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.