The protocol documentation names the scheme and curve for each account prefix explicitly, including tz3 as ECDSA over P-256 and tz4 as BLS over BLS12-381. tz5 and ML-DSA-44 are named in the Ushuaia proposal post, in the heads-up post, and in the Octez protocol 025 release notes. The transport primitives come from the Octez peer-to-peer documentation and the crypto_box source module header. The Sapling primitives come from the Octez Rust dependency lock file, which pins jubjub, bellman and the librustzcash stack. Deduction is for the general accounts documentation page still not listing tz5 at this check, which is consistent with the flag being off.

Four of the five deployed signature families are Shor-broken and the fifth is disabled on mainnet. BLS12-381 is consensus-relevant, not incidental: aggregate_attestation reads true on live mainnet, and of the 196 active bakers, 81 (41.3%) have a BLS12-381 consensus key as their most recent registered consensus key, holding 34.7% of voting power, measured 2026-08-20 from the on-chain update_consensus_key operation history cross-referenced against the active delegate set.

Families present in the base protocol: lattice (one, ML-DSA-44 via Ushuaia) and classical elliptic curve (four deployed). Lattice is the only declared post-quantum family. No hash-based, code-based or isogeny path appears in the Ushuaia release notes, the proposal post, or the published four-step roadmap. The separate TzEL research rollup uses WOTS+ (hash-based) and ML-KEM-768 (lattice KEM) but runs outside the base protocol on a test network and carries no deployed-diversity credit. Lattice-only scores the hard cap of 5 under v3.1 and fires the Cryptographic-Diversity Cap at QRI 60.

FIPS 204 states that ML-DSA-44 is claimed in security strength category 2, ML-DSA-65 in category 3 and ML-DSA-87 in category 5. Tezos chose the category-2 parameter set rather than ML-DSA-65 or ML-DSA-87. Ed25519, ECDSA secp256k1 and ECDSA P-256 target 128-bit classical security. No primary source states the exact classical security level of BLS12-381, which does not affect the Shor classification above.

Classical primitives in Octez are backed by HACL* and EverCrypt, which carry machine-checked functional correctness, memory safety and secret independence, and secp256k1 goes through bindings to the libsecp256k1 reference library. The ML-DSA-44 path is Octez module src/lib_ml_dsa over a vendored crate that pins upstream libcrux-ml-dsa at version 0.0.5 with the mldsa44 feature. Two facts cut against the formal-verification claim as applied to this deployment. First, the upstream project states that all its crates are pre-release at versions below 0.1 and asks users to contact the maintainers before production use; the pinned 0.0.5 is four releases behind the 0.0.10 published upstream at this check. Second, an independent 2026 preprint reports thirteen vulnerabilities in that library family, including two FIPS 204 specification violations in the ML-DSA verifier and one wrong multiplication specification that the paper states renders axiomatized AVX2 proofs unsound. the public record shows no independent audit or reproducible-build evidence tying the ML-DSA verifier Octez actually ships to audited source, which is the deployed-verifier provenance test. Cryptanalytic tier: tier 1 for the classical elliptic-curve and hash primitives, tier 3a for ML-DSA as a finalized FIPS algorithm.

Tezos implicit accounts stay unrevealed until they send their first outgoing operation, after which the plaintext public key is permanently on-chain. Measured 2026-08-20: 2,295,067 applied reveal operations against 5,511,961 user accounts, and among the 10,000 largest user accounts by balance, 7,464 have revealed keys and 94.7% of the 844.7M tez they hold sits at revealed addresses. That balance is roughly three quarters of total supply. ML-DSA-44 protects none of it: tz5 is feature-flagged off on mainnet.

Never-spent accounts keep the public key behind the tz1, tz2 or tz3 hash, which is mitigated-until-spend under the address-type classification; any still-funded account that has revealed is exposed-after-spend. Delegates are revealed on-chain by construction, because an account must be revealed to bake. The mitigated cohort is small by value: of the 10,000 largest user accounts, 2,536 are unrevealed but hold only 5.3% of that cohort's balance, measured 2026-08-20. This tile is scored on that measurement, which is unfavourable. There is no in-place key rotation for an implicit account, so migrating scheme means moving funds to a new address until stateful addresses ship.

Every historical signature on Tezos mainnet is Ed25519, ECDSA secp256k1, ECDSA P-256 or BLS12-381, all Shor-broken. Ushuaia declares no retroactive re-signing and no commit-to-hash mechanism.

Node-to-node connections are encrypted with the NaCl authenticated-encryption construction: an X25519 Diffie-Hellman channel key with XSalsa20-Poly1305, implemented through HACL* bindings, per the Octez peer-to-peer documentation and the crypto_box module. This layer is not TLS. This is a classical key exchange with no hybrid or post-quantum option, so recorded traffic is harvestable now and decryptable once discrete log falls. At the client-facing edge, a hybrid-only TLS handshake to the two most-used public indexer and RPC hosts was refused with a handshake_failure alert on 2026-08-20, so those endpoints offer no ML-KEM group either; the chain's own web properties, which sit behind a CDN and carry no chain traffic, do negotiate X25519MLKEM768. Ushuaia addresses signatures only.

Transparent ledger by default. Sapling was integrated into the Michelson language at protocol Edo (protocol 008), whose promotion period ended 2021-02-13, but adoption is limited and the dominant mode is fully transparent.

The protocol documentation lists several independent public mainnet RPC providers, including a Trilitech-operated endpoint, a Tezos Commons endpoint, a Tezos Foundation endpoint and the TzKT indexer endpoint. Provider count fell in 2026: the long-running free public RPC service operated by ECAD Labs shut down on 2026-05-31 after the Tezos Foundation declined to renew funding, and a replacement Trilitech endpoint was announced two days before that. No validator-metadata retention policy is published by any of them. Mempool gossip is observable.

Etherlink is an EVM-compatible optimistic Smart Rollup on Tezos, and Smart Rollups are enshrined in the protocol with protocol-defined commitment periods, bonds and refutation periods. Value moves between layer 1 and the rollup through the protocol's own inbox and outbox message path, so a passive observer can link the two sides without needing a third-party bridge operator. No other bridge could be confirmed as currently live for Tezos from a primary source.

Sapling note encryption on Tezos runs on Jubjub, a twisted Edwards curve whose base field is chosen to be the scalar field of BLS12-381; it is not a Curve25519 derivative. Octez vendors the Zcash Sapling stack, with jubjub, bellman and bls12_381 pinned in its Rust dependency lock file, so the proof system is Groth16 over BLS12-381. Both the Jubjub key agreement and the Groth16 proofs are Shor-breakable, so a future adversary can de-anonymize historical Sapling notes. Practical impact is limited because Sapling adoption on Tezos is small. The TzEL research project is building post-quantum shielded payments using ML-KEM-768, WOTS+ one-time signatures, BLAKE2s and recursive STARKs as a Smart Rollup on a test network, and its own repository warns that neither the scheme nor the implementation should be assumed secure and that it must not be used for real value. It does not change the retroactive exposure of existing Sapling notes.

No on-chain or protocol-layer mixnet.

Self-amending governance has carried 21 accepted amendments from Athens, whose promotion period ended 2019-05-30, through Ushuaia, whose adoption period ended 2026-06-30, with no hard fork required. Ushuaia added a new signature scheme (ML-DSA-44) and a new account prefix (tz5) through that process, which is the production instance the rubric asks for, now completed through the full five-period vote and activation rather than pending. Seoul (adoption period ended 2025-09-19) had already added the tz4 BLS12-381 account family the same way. Tallinn added no BLS aggregation feature: the aggregate attestation and preattestation operations were introduced at Seoul, and Tallinn replaced the all_bakers_attest_activation_level parameter with all_bakers_attest_activation_threshold and set it to 50%, which the live mainnet constants confirm as a one-half ratio.

No native account abstraction and no ERC-4337 equivalent. Multi-curve account selection across tz1 through tz5 gives per-account scheme choice at creation only. The Ushuaia proposal states verbatim that a later step is to enable 'stateful addresses which allow for key rotation while preserving an account's address and history', so key rotation is not shipped. The heads-up post describes the intended end state as letting users 'attach multiple keys to their existing account', which would render the implicit account stateful. Seoul shipped protocol-native multisig on tz4 addresses, which is account flexibility rather than full account abstraction, and the heads-up post states native multisig signing is not yet supported for tz5. Score includes the RFC 8032 Ed25519 seed floor, which is exceeded by the account-model component here; no post-quantum rebind bonus is earned, because no chain-specific rebind design has been published.

The on-chain amendment record shows 21 accepted proposals from Athens through Ushuaia and no contested chain split. Brest A and Carthage are sometimes both described as rejected. Carthage was accepted. The record shows three rejected proposals, at governance epochs 34, 50 and 67, each failing an exploration or promotion supermajority, plus twelve periods that closed without quorum. Those are orderly in-protocol rejections, not forks.

Ushuaia ships pure ML-DSA-44 in a parallel account type, not a hybrid composition with Ed25519 or any other scheme. Architecturally Tezos can already run multiple schemes side by side, and the roadmap points at a multi-key account once stateful addresses exist, which would be an OR-composition. No hybrid-composition specification has been published, no commit-to-hash rule is documented for the future OR path, and the November 2025 community research post that recommended a hybrid classical-plus-post-quantum approach as the immediate migration path was not adopted in the shipped design.

ML-DSA-44 is stateless, which is full credit by default. The base protocol uses no stateful hash scheme such as XMSS per RFC 8391 or LMS. The separate TzEL research rollup uses WOTS+ one-time signatures under a Merkle root of 65,536 one-time keys per address, with single-use consumption enforced inside a STARK circuit and address rotation before key exhaustion documented as an operational requirement. That system runs on a test network, entirely outside the layer 1 account and consensus path.

Tenderbake is BFT-style with deterministic finality. Attestation and preattestation aggregate operations were introduced at Seoul and run on BLS12-381, a Shor-vulnerable pairing scheme; the aggregate_attestation protocol constant reads true on live mainnet, queried 2026-08-20. The Ushuaia post-quantum deployment excludes baking: the proposal post states 'baking support will follow later', the heads-up post states 'Baking is not supported (yet)', and the protocol 025 release notes state that even on networks where the flag is enabled, tz5 accounts cannot be registered as delegates and tz5 keys cannot be used as consensus keys. No specification for a post-quantum aggregation path has been published. Consensus-layer-exposed: consensus keys are public on-chain for the whole cycle, so fast finality is not a defence here.

Mainnet PQC traffic: 0%, exactly. Ushuaia activated on mainnet 2026-06-30 carrying the tz5 and ML-DSA-44 code, and the feature flag stays off: the protocol constant tz5_account_enable reads false on live mainnet, queried 2026-08-20 at the same head that reports protocol PsUshuai9QapM5TGj1JpuVGkdxz5GykdnEvS6Rh8SUVrARvZLCY on chain NetXdQprcVkpaWU, and the protocol 025 release notes state the flag is disabled by default on the mainnet. tz5 accounts cannot be constructed or broadcast against mainnet, so the figure is zero rather than small. Activation is testnet-only, on Ushuaianet. As of 2026-08-20 the on-chain proposal period opened after Ushuaia, index 180, held no submitted proposal, so no flag lift is in the voting pipeline.

Ushuaia's activation put ML-DSA-44 support inside the live mainnet protocol, gated by a feature flag. The code is verifiable in the Octez repository: module src/lib_ml_dsa builds the octez-ml-dsa library against a vendored crate that pins upstream libcrux-ml-dsa 0.0.5 with the mldsa44 feature, and the protocol release notes record that environment V16 introduces signature V3 supporting ML-DSA-44 and tz5 addresses. Octez is the dominant client. This is shipped production code that has never been exercised on mainnet while the flag is off.

Zero. The protocol 025 release notes state that even on networks where the tz5 flag is enabled, tz5 accounts cannot be registered as delegates and tz5 keys cannot be used as consensus keys, so no validator post-quantum key adoption is possible under the current protocol on any network. The signing key on the most recent block is time-varying and not load-bearing: the block read at level 14,575,608 on 2026-08-20 was produced by a tz3 delegate and carries a BLsig-prefixed BLS12-381 signature. Both tz1 Ed25519 and tz3 BLS12-381 baker keys are classical.

Voided to 0 per the v3.1 rule that milestone credit requires non-zero mainnet PQC traffic. The published roadmap names four ordered steps and names the artefacts (ML-DSA-44, tz5, stateful addresses, later baking support), and the heads-up post states the flag will be removed once stateful addresses are live, but no step carries a public date and no sunset date exists.

Three primary announcements: the heads-up post of 2026-02-04, the joint Ushuaia proposal post of 2026-04-22, and a Decrypt article of 2026-05-14 quoting the co-founder. All three label the shipped state accurately, including the section heading 'In the protocol, but not available yet'. The chain's own Ushuaia upgrade page makes no post-quantum claim at all. No press inflation found.

FIPS 204 Table 2 gives ML-DSA-44 a 2,420-byte signature and a 1,312-byte public key, against 64 bytes and 32 bytes for Ed25519. That is about 38 times the signature bytes and about 41 times the public-key bytes, and both matter on Tezos because the reveal operation publishes the public key on-chain. This falls in the 10-to-38-times band, worth 5 points. No per-block bandwidth budget under post-tz5-adoption assumptions has been published. Ushuaia separately raised data-availability-layer bandwidth from about 0.66 MB/s to 10 MB/s, a 15-fold increase, which the co-founder publicly connected to absorbing large post-quantum shielded-transaction payloads; that headroom serves rollup and data-availability payloads, not tz5 signature bytes in layer 1 blocks, so no footprint credit moves.

Published PQC roadmap count: 0. Code searches on 2026-08-20 returned zero matches for tz5 and zero for ML-DSA in the Temple wallet extension repository, the Kukai web wallet repository, and the Ledger Tezos wallet application repository, all three of which were pushed to within the last eight months. The dominant TypeScript SDK is worse than silent: Taquito v25.0.0, published 2026-06-29 as the Ushuaia support release, carries the tz5_account_enable field in its RPC constants type but its forging layer throws InvalidKeyHashError on any tz5 address, asserted in its own test suite, and contains no ML-DSA code path. Any wallet built on that forging layer cannot construct a tz5 transaction even against a network where the flag is on. On the tz4 generation before it, the Ledger Tezos wallet application parses tz4 addresses and BLS signature fields but its own protocol documentation states that consensus keys cannot be BLS public keys, and a May 2026 baker analysis on the public forum cites the lack of Ledger BLS support as one reason tz4 consensus-key adoption stalled.

Published PQC roadmap count: 0. The protocol-enshrined path is Etherlink, an EVM-compatible optimistic Smart Rollup, with movement between layers handled by the protocol's own inbox and outbox messages and kernel upgrades governed through Etherlink's own governance process. No third-party Tezos bridge could be confirmed as currently live, so none is carried unverified. No post-quantum roadmap exists for the rollup kernel: the three Etherlink kernel upgrade proposals published between June and August 2026 are security and liveness work with no cryptographic migration content.

Published PQC roadmap count for Tezos asset support: 0. Named from the on-chain delegate registry rather than from marketing material, the largest custodial and staking operators on Tezos are a publicly listed US exchange at 16.0% of voting power, Kraken at 10.6% and Kiln at 7.8%, with a Ledger-branded Kiln baker at a further 2.1%, measured 2026-08-20. None publishes a post-quantum roadmap covering Tezos asset support, and none can hold tz5 keys today because the protocol forbids tz5 delegates and tz5 consensus keys.

This tile is scored on documented degradation, not on absence of a roadmap. The signing tile rests on Signatory, the protocol-aware remote signer that delegates to YubiHSM2, AWS KMS, Azure KMS, Google Cloud KMS, Hashicorp Vault, PKCS#11 and AWS CloudHSM, Ledger, AWS Nitro Enclaves and Google Confidential Space. Its maintainer announced on 2026-06-09 that the Tezos Foundation stopped funding it at the end of January 2026, that a reduced 50,000 US dollar maintenance proposal was also declined, and that it is winding down support, telling bakers, exchanges and custodians to plan migration. The same vendor shut its free public Tezos RPC service on 2026-05-31 for the same reason. That matters directly for post-quantum readiness: in February 2026 an engineer from that vendor stated on the public forum that they were working on ML-DSA-44 support in Signatory for both baking and non-baking contexts, explicitly conditioned on being able to sustain development, and that condition has since failed. This is the only stated tz5 signing-infrastructure intent the public record shows anywhere in the ecosystem. Independent public RPC providers do exist, including Trilitech, Tezos Commons, Tezos Foundation and TzKT endpoints, and none publishes a post-quantum roadmap. Tezos remains cloud-HSM-friendly at tz3 because P-256 is widely supported by cloud HSMs, which does not extend to tz5.

Two findings set this tile. First, measured concentration is high: 196 active bakers, 3,038 stakers and 138,841 delegators, with the top 3 bakers holding 34.4% of voting power, the top 10 holding 63.1% and the top 20 holding 78.2%, measured 2026-08-20. Second, there is no partial client diversity through a secondary Rust implementation: that project's own repository states development has ceased and its last push was 2024-06-25, so Octez is the only maintained node implementation LayerQu could verify. Stake distribution across a 196-baker delegated proof-of-stake set is still reasonable for a layer 1; single-client dependence is not.

The on-chain record shows 21 accepted amendments since Athens in 2019, with Rio, Seoul, Tallinn and Ushuaia all activating in 2025 and 2026 at roughly one upgrade every three to four months. Cadence has been consistent across the chain's history, and the Ushuaia cycle ran its full five periods from 2026-04-20 to activation on 2026-06-30 without slipping.

Three development teams are named jointly on both the heads-up post and the Ushuaia proposal post: Nomadic Labs, Trilitech and Functori. That is a real, named, multi-team coordination structure and the Octez post-quantum module carries a Nomadic Labs copyright header. Two findings cut against this tile. A fourth organization is not named as a contributor in either post. More materially, the Tezos Foundation, which funds ecosystem work outside those teams, declined in 2026 to renew funding for both the public RPC service and the only enterprise-grade protocol-aware remote signer, and the vendor operating both wound them down; a signer and HSM path is exactly the tooling a user-key migration needs. No post-quantum working group is formally named, and the migration roadmap has no named owner outside the three protocol teams.

The 2018 founder governance dispute was resolved through the Tezos Foundation and subsequent governance has run on-chain. The on-chain record contains three rejected proposals and twelve periods that closed without quorum, all resolved inside the protocol. No coordinated cryptographic change under active attack has been exercised.

No canary, no rate-limited spending rule and no embedded cryptographic tripwire is declared. The roadmap's step 4 condition, deprecating elliptic-curve signatures if and when a clear and present danger exists, is a stated trigger with no named metric, monitor or dashboard behind it.