Foundation protocol spec at protocol.penumbra.zone explicitly names every primitive. Minor deduction: TLS / P2P transport cipher suite for CometBFT gossip is not separately specified by Penumbra Labs (default CometBFT secret-connection uses X25519+ChaCha20-Poly1305, but no explicit Penumbra-side declaration).

Every signing, encryption, key-agreement, proof-system, and consensus primitive in active use depends on the discrete-logarithm or pairing problems on BLS12-377 / decaf377, all of which Shor's algorithm solves in polynomial time on a fault-tolerant quantum computer. No PQ-safe primitive is in mainnet use.

0 PQ families on mainnet. No lattice, hash-based, code-based, or isogeny PQ primitive deployed. Diversity Cap (lattice-monoculture) is not yet triggered (pre-cap state).

No primitive in active use maps to NIST PQC categories 1-5. BLS12-377 targets ~125-128-bit classical; decaf377 inherits ~125-bit classical from the underlying Edwards curve; Ed25519 targets ~128-bit classical; Poseidon parameter sets target 128-bit classical. Under Grover, symmetric/hash levels halve to ~64-bit effective; under Shor, every EC / pairing primitive is fully broken.

NCC Group published a 2022-09-12 audit covering decaf377 reference Rust implementation and Poseidon parameter selection. Penumbra Labs runs a public Summoning Ceremony (multi-party trusted setup for Groth16 over BLS12-377, two phases concluded in 2023-2024), strong setup hygiene. Constant-time engineering for decaf377 documented as a goal in spec; formal verification NOT documented. Library provenance: penumbra-zone/decaf377 and penumbra-zone/penumbra Rust crates. Cryptanalytic-maturity tier mixed: Ed25519 tier 1, Schnorr-RedDSA derivation tier 1-2 (Zcash-derived), Poseidon and decaf377-fmd / eddy threshold tier 4 (research-grade).

Every Penumbra address is a structured commitment that includes a decaf377 group element. When a user spends a note, decaf377-rdsa SpendAuth signatures are published on-chain, revealing public key data tied to spend authority via Schnorr signature equations. Once Shor is operational, every active spending address is forgeable. Mitigating factor: diversified addresses (per-address randomization) so the same root spend authority can produce many unlinkable receiving addresses, but the underlying spend-verification key is shared and recoverable from any single SpendAuth signature once Shor lands. Validator consensus signing uses Ed25519, every CometBFT vote signature is forgeable post-Shor.

Cold/dormant Penumbra holdings sit inside the shielded pool as Pedersen-style note commitments anchored to a decaf377 spend-verification key. Unlike Bitcoin P2PKH where pubkey is hashed and only revealed at spend, dormant Penumbra notes are never public-key-revealed at all (address is a commitment; spend-verification key not on-chain until first SpendAuth signature). However, ANY past spend by the same root key that already published a SpendAuth signature exposes the spend-verification key for every diversified address derived from it. Cold-key exposure is bimodal.

Every SpendAuth and binding signature on chain since 2024-07 is verifiable post-Shor against a forged version. Combined with on-chain pubkey publication via signature equations, historical authorization records lose non-repudiation once Shor lands. CometBFT block-signing Ed25519 votes from validator set are likewise retroactively forgeable, undermining integrity of historical block headers under any Shor-aware re-validation.

Validator-to-validator gossip in Penumbra runs over CometBFT's secret-connection (default: X25519 ECDH + ChaCha20-Poly1305, classical). RPC endpoints typically run TLS at infrastructure-provider level. No PQ-hybrid TLS / hybrid KEM is announced for either layer.

Every Penumbra note is encrypted to its recipient via a decaf377-ka Diffie-Hellman key agreement. The DH long-term key is a decaf377 element on a Shor-vulnerable curve. An adversary harvesting note ciphertexts plus public ephemeral DH terms today can decrypt every shielded note once Shor is operational, exposing balances, asset types, sender-receiver pairs, and ZSwap auction inputs. Same vulnerability extends to flow-encryption (eddy) ciphertexts protecting batch ZSwap sealed-bid amounts. No announced PQ KEM migration, no testnet hybrid encryption, no historical re-encryption plan in UIP repo or Penumbra Labs blog. **Dominant catastrophic finding for Penumbra.**

Penumbra is shielded by default, no transparent transaction path exists for native Penumbra activity (IBC inbound deposits do reveal source-chain origin, but the destination on Penumbra is a shielded note immediately). On-chain visible state is a nullifier set + note commitments + encrypted note ciphertexts + Groth16 proofs. Stronger than chains with both shielded record and transparent paths. Address reuse mitigated by diversified addresses. Slight deduction (−4) for IBC-boundary metadata leakage on cross-chain deposits/withdrawals.

Penumbra ecosystem is small, dominant RPC path is Penumbra Labs-operated `pd` nodes plus a handful of community validators (Polkachu, Lavender.Five). (i) RPC concentration: small ecosystem, one dominant operator handling significant share of `pclientd` proxy requests; concentration risk is HIGH but no published share data. (ii) Mempool gossip observable to all CometBFT validators by design (full-mesh broadcast). (iii) Validator metadata retention policy: undeclared. Sender FMD (S-FMD) limits detection-key leakage to wallet-controlled detection probabilities, partially offsetting RPC trust.

Penumbra connects to broader Cosmos ecosystem via IBC (Inter-Blockchain Communication). IBC packet flows are public on both source chain and Penumbra side at the boundary, a passive observer watching e.g. Osmosis-side IBC transfer events and Penumbra-side first-spend timing can correlate amounts and rough timing windows. IBC is the only major bridge surface; no Wormhole/LayerZero integration. The IBC boundary is the structural weak link for Penumbra's anonymity guarantee.

Dominant confidentiality risk and headline finding. The privacy guarantee for every shielded transaction relies on (a) secrecy of recipient's incoming-viewing key derived from a decaf377 secret, (b) secrecy of random scalar used in decaf377-ka note-encryption ECDH, and (c) soundness/zero-knowledge of Groth16 over BLS12-377 (binding witness commitments via pairing equations). All three are protected only by discrete-log / pairing hardness on decaf377 / BLS12-377. Once Shor lands, every historical Penumbra note encrypted to a published transmission key is decryptable by anyone who has harvested the chain, exposing every shielded transfer, every ZSwap sealed-bid auction input, every governance vote, and every amount on the chain since 2024-07. Penumbra is shielded-by-default; every privacy primitive is Shor-broken. There is no transparent path that limits exposure; the entire shielded pool decrypts in one Shor event.

Penumbra does not run a mix-network or cryptographic shuffle protocol at the protocol layer. Privacy comes from the shielded UTXO model itself (hidden inputs/outputs), not from active mixing. Diversified addresses + S-FMD provide some indistinguishability and outsourceable detection. ZSwap batch-auction matching provides a form of structural indistinguishability for trades within the same batch. No on-chain commit-reveal mix, no cMix-class IT-secure shuffle, no precomputation/cover-traffic.

No Penumbra Labs blog post, UIP, governance proposal, or community forum thread announces post-quantum migration of note encryption (decaf377-ka), flow encryption (eddy), or the underlying Groth16-over-BLS12-377 proof system. Visible UIP repository through 2026-05-01 lists IBC packet-forwarding middleware, governance refinements, DEX upgrades, no PQ KEM, no hybrid encryption testnet, no announced sunset of decaf377-based primitives.

Penumbra is built on Cosmos-SDK-compatible CometBFT consensus with Penumbra Labs' own state machine. Module-based architecture is theoretically extensible, but the Groth16 proof system, decaf377 group, and BLS12-377 proving curve are deeply embedded in every shielded-pool component (note commitments, nullifiers, SpendAuth signatures, binding signatures, FMD detection keys, eddy threshold encryption). Spec acknowledges proving-curve choice is 'fundamentally disruptive to users, requiring new addresses and fund migration' if changed. No on-chain crypto-agility primitive (e.g., per-tx algorithm-tag) documented.

Penumbra has no native account-abstraction primitive comparable to ERC-4337 / EIP-7702. Custody model is hierarchical-deterministic with full viewing key / spend key / detection key separation, sophisticated for privacy but not algorithm-agile. Key rotation is per-address (move funds to a new spend authority). No documented client-layer PQC path. `pclientd` (trusted local custody daemon) could theoretically be a migration locus, but no PQ-aware design exists.

In ~22 months since mainnet Phase 0 began (July 2024), Penumbra has executed coordinated chain upgrades (Candidate Mainnet Upgrade 2 was discussed in governance forum); the network proceeded through Phase 0 → Phase 1 → Phase 2 staged launch. No contested hard-fork splits documented. Track record short and small-set, but clean.

No public hybrid PQ design exists for any layer (signing, encryption, proof system). Architecturally, the Groth16-over-BLS12-377 proof system is the deepest constraint on agility, replacing it with a FRI-based PQ-safe proof system (Plonky3, STARK, Stwo, Circle STARK) is technically feasible but would require a full re-instantiation of the shielded-pool circuit and a new trusted setup obviation. Note encryption could in principle be migrated to a hybrid KEM (ML-KEM concatenated with current decaf377-ka) more cheaply, but no UIP exists.

Penumbra does not use stateful hash signature schemes (XMSS / LMS / leanXMSS) anywhere in the stack. Schnorr-RedDSA on decaf377 and Ed25519 at consensus are stateless. Per rubric, stateless-by-default chains score full 15.

Penumbra consensus is CometBFT with Ed25519 validator block-signing (NOT BLS aggregation). Since Penumbra does not use BLS-aggregating signatures at consensus, 4f is N/A. The non-aggregating Ed25519 consensus path is itself Shor-vulnerable but is captured in 1b/2c rather than 4f. Renormalized to /80 → Dim 4 raw 16/80 → 20/100 on rubric scale.

0% of consensus signing, transaction signing, note encryption, flow encryption, FMD detection, or proof generation runs on a PQC primitive as of 2026-05-01.

penumbra-zone/penumbra contains no merged PQC primitive (no ML-DSA, no SLH-DSA, no ML-KEM, no FRI proof system) as of 2026-05-01.

0 of the active Penumbra validator set runs PQC consensus keys; CometBFT validator keys are Ed25519 across the board.

VOIDED to 0 per v3.1 rule (5a = 0). Even ignoring the void rule, no dated, enforcement-mechanism-backed PQ milestone exists in any UIP, Penumbra Labs blog post, or governance forum thread.

Announced PQC = 0 in trailing 12 months (no Penumbra Labs blog post, UIP, social post, or press claim). Shipped PQC = 0. Per rubric, no deduction; chain scores full 15. Penumbra is honest about its current pre-PQC posture by silence.

Undisclosed. With no announced PQ scheme, bytes-per-block footprint under PQ is unknown. If Penumbra were to migrate consensus from Ed25519 (~64 byte sigs) to ML-DSA-65 (~3,300 byte sigs), the multiplier across all CometBFT votes per block would be ~50×, beyond the rubric's >38× threshold. SLH-DSA would be far worse (~110-125× raw). A FRI-based proof system would massively expand transaction proof bytes.

Top wallets are Penumbra's own `pcli` CLI client, Prax (browser extension by Penumbra Labs), and Keplr / Cosmos wallet integration for IBC inbound flows. None has published a PQC roadmap. Shielded model means custody software must hold spend authority key and detection keys locally, extra constraints on hardware-wallet support.

IBC is the sole bridge surface. The Cosmos IBC stack has no PQC roadmap as of 2026-05-01, IBC light-client verification depends on chain-specific consensus signature schemes (Ed25519 here), and IBC has no hybrid PQ work-track. No Wormhole / LayerZero integration. Penumbra cannot upgrade its bridge surface unilaterally, IBC requires coordinated PQ work across the Cosmos ecosystem.

No major institutional custodian (Coinbase Custody, BitGo, Fireblocks, Anchorage, Komainu, Copper) has announced Penumbra native asset custody. Shielded UTXO model with spend authority + diversifier + detection key separation is an unusual custody integration target. None of named custodians has a published PQC roadmap that covers Penumbra keys.

RPC providers are Penumbra Labs nodes plus a small set of Cosmos infrastructure providers (Polkachu, Lavender.Five). No mainstream RPC provider (Infura/Alchemy/QuickNode) supports Penumbra. HSMs: no documented Ledger / Thales / YubiHSM integration for decaf377 / decaf377-rdsa keys (Penumbra's curve is non-standard and not on any HSM vendor's supported list). TEEs not used in core consensus path.

Penumbra mainnet has a modest active validator set (small ecosystem; Phase 0 began with an initial validator set finding genesis block, additional validators joined per the staged launch). Maximum validator count and current Nakamoto coefficient are not published as headline metrics by the foundation. Client diversity is effectively single-client (penumbra-zone/penumbra reference implementation). Stake distribution is concentrated by genesis allocation (16% airdrop, 25% community pool, balance to investors/team with 2-3 year locks per tokenomics summary).

Penumbra has executed staged-launch coordinated upgrades (Phase 0 → Phase 1 → Phase 2; Candidate Mainnet Upgrade 2 governance discussion). No demonstrated coordinated upgrade under live attacker pressure (no major active exploit in this period). Cadence is moderate.

Penumbra Labs is the named core development organization (founders include Henry de Valence, ex-Zcash cryptographer; cryptography work attributed to Penumbra Labs team in the protocol spec). On-chain governance via the UIP process, void.vote / vote.penumbra.zone, and forum.penumbra.zone provides public coordination surfaces. No named PQ migration WG or PQ-lead role.

Penumbra's mainnet launch in July 2024 had no documented adversarial-attack coordination precedent. The 'proposal NFT' governance mechanism with deposit-burn-on-spam-vote is a thoughtful adversarial design but has not been stress-tested at scale.

No community honeypot, no rate-limited spending rule, no cryptographic tripwire, no automated-response mechanism for Shor / decaf377-break / Groth16-soundness-break published.