Sui publicly documents every primitive in active production use, and each one above is reconstructible from the published source rather than from prose. Naming and specificity excellent. Minor deduction because Sui does not publish a single canonical primitive-inventory page. Narwhal was replaced by Mysticeti on mainnet in July 2024 and no longer exists in the repository, so the validator transport keys sit with anemo over QUIC.

Every signing primitive in production at the consensus layer, account layer, bridge layer and ZK-verification layer is Shor-breakable. zkLogin compounds exposure by adding RSA on the issuer side to a pairing-based proof system.

Families deployed in production: 0. The rubric counts families at the mathematical-foundation level and the Cryptographic-Diversity Cap lifts only on a second family deployed at Dim 5 sub-scores 5b/5c, so the family count keys off deployed primitives, not announced ones. On that reading Sui is at the paper-and-code floor, not at the two-family band. What the 2026-08-06 announcement adds is evidentiary quality: two families are named with exact parameter sets and real repository code rather than research framing. ML-DSA-65 (lattice, FIPS 204) exists as library code merged into fastcrypto on 2026-08-12; SLH-DSA-SHA2-128s (hash-based, FIPS 205, a finalized standard that would lift diversity fully once deployed) has its Winternitz, FORS and XMSS-hypertree building blocks merged into the production cryptography library behind an experimental flag, with the top-level sign and verify pull request closed unmerged. Neither is reachable from any runtime path a transaction can hit, and neither is referenced anywhere in the node repository. The score credits that step from research intent to primitive code, and no further. If both ship as announced, Sui would hold two families and the Cryptographic-Diversity Cap would not bind.

No production primitive carries a NIST post-quantum category: Ed25519 ~128-bit classical; secp256k1 ~128-bit; secp256r1/P-256 ~128-bit (curve per NIST FIPS 186-5); BLS12-381 ~128-bit; Groth16 over BN254 ~100-bit (BN254 falls below the 128-bit floor under tower-number-field-sieve analysis of the pairing-target field); SHA3-256 and Blake2b-256 128-bit Grover-resistant. What is new is an explicit category selection with a stated reason for the announced track: ML-DSA-65 at NIST Category 3. The score credits publishing a per-primitive category choice with rationale where none existed. It goes no higher for three reasons: no NIST-categorized post-quantum primitive is in production; the second announced scheme, SLH-DSA-SHA2-128s, is the Category 1 parameter set of FIPS 205, which does not carry the margin the ML-DSA-65 choice was justified by; and the published rationale compares Level 3 against a cheaper Level 1, where FIPS 204 defines no Category 1 ML-DSA parameter set at all, the cheapest being ML-DSA-44 at Category 2.

Production cryptography is unchanged by the announcement: primitives ship via fastcrypto (Rust), a Mysten Labs-maintained wrapper around well-vetted upstream crates; Ed25519 uses ed25519-consensus 2.1.0 (ZIP-215 compliant), BLS12-381 uses blst, secp256k1 and secp256r1 use the libsecp and arkworks lineages. External audits by Common Prefix cover the Pedersen DKG and threshold-BLS construction, the Groth16 verifier, and ECDSA secp256r1, alongside earlier reviews of ECDSA secp256k1, BLS12-381, ECVRF and Ristretto255; there is no machine-checked formal verification of the library. Production primitives are tier 1, Groth16 over BN254 is tier 4. The post-quantum code added to that library is mixed on quality. In its favour: the ML-DSA-65 layer wraps a named upstream C implementation with formally verified NEON and AVX2 assembly backends behind a runtime CPU probe, pins the dependency to an exact commit, and gates on a five-vector byte-exact interop test against an independent reference implementation, with a published verify benchmark of 24 microseconds against 28 for Ed25519 on the same machine. Against it: the SLH-DSA module states on its own README that it is a hand-written Rust implementation rather than a port of an established post-quantum library, is cross-checked only against reference sub-vectors, and has no merged top-level sign or verify path; no independent audit of any post-quantum code has been published, only a statement that audits are underway. On sub-component (vi), deployed-verifier provenance, the score is 0 by construction: no post-quantum verifier is deployed, so there is no compiled artifact to match against audited source. Net 13.

Sui's account model exposes the public key the moment an account first transacts: the address is Blake2b-256(flag || pubkey), but signing requires revealing the pubkey in the transaction envelope. Mainnet has run since 2023-05-03, roughly 39 months as of 2026-08-12. No P2PKH-style quiet hashing. TVL is concentrated in active accounts; treasury and exchange holdings are signed-on-demand.

Younger chain than Bitcoin or Ethereum, so a smaller dormant surface. Foundation and Mysten Labs holdings are operated under classical schemes (Ed25519 and ECDSA secp256k1). Sui has no native pubkey-hashing-only resting state for inactive accounts: once a key has signed, the public key is on chain and Shor-recoverable.

All historical signatures are Ed25519, ECDSA secp256k1, ECDSA secp256r1 or BLS12-381 min-sig, every one Shor-forgeable post-CRQC. Sui's checkpoint history runs roughly 3.3 years from the 2023-05-03 genesis and is not anchored to any post-quantum commitment, so a future quantum attacker could in principle forge historical certificates against a non-checkpointed full-node sync.

Validator gossip runs over anemo/QUIC with a TLS handshake keyed to Ed25519 network identities, and RPC is gRPC over TLS 1.3. Both rely on classical key agreement: the node pins rustls 0.23 built on the ring provider, which exposes X25519 and the NIST prime curves and no hybrid post-quantum group, so X25519MLKEM768 is not available in the shipped build even as a non-default option. No declared PQ-KEM hybrid on validator-to-validator or validator-to-RPC links, and the 2026-08-06 announcement does not touch transport.

Transparent ledger. The object-centric model means each owned object is traceable to its current owner; transfers are linkable on chain. Sui has no native shielded-pool protocol. zkLogin proves OAuth-issuer linkage but does not anonymize the on-chain graph.

RPC providers active for Sui include the Mysten Labs public RPC, BlockVision, Shinami, Triton and the Suiscan/SuiVision explorers. No public composite share data exists, and LayerQu makes no share claim; the concentration reading is an analyst judgement recorded as such in the source-disagreement block. Sui has a fast path for owned-object transactions and a consensus path for shared-object transactions; consensus-path traffic is observable at validators.

Sui's primary bridges are Sui Bridge (native, operated by a committee whose members sign under ECDSA secp256k1 recoverable signatures) and Wormhole/Portal (multi-chain). LayerZero/Stargate is also active. All three produce on-chain correlations between source-chain and Sui addresses; passive observers can link both legs. No bridge in this set declares a PQC roadmap.

A future Shor-equipped adversary recovers private keys from any address whose public key has been revealed, which is every active Sui address. Combined with the transparent graph, this enables full retroactive ownership attribution. zkLogin's privacy boundary against the OIDC issuer is preserved, but a quantum adversary breaking the issuer's RSA signing key could forge the JWTs zkLogin proofs are built over.

No on-chain mixer, no commit-reveal or batch-ordering mechanism, no cryptographic shuffle, no mix-node infrastructure. Confidential transactions have been named as a 2026 protocol-level priority in Foundation communications, but no cryptographic scheme is named and no specification is published, so there is no mechanism to cite and the rubric scores 0. The 2026-08-06 post does not address metadata, anonymity or transaction-graph exposure at all.

Sui's signature dispatch is built around a unified flag-byte plus enum wrapper, verifiable in the SignatureScheme enum: 0x00 Ed25519, 0x01 secp256k1, 0x02 secp256r1, 0x03 MultiSig, 0x04 BLS12-381 (annotated in source as not supported for a user Sui address), 0x05 zkLogin, 0x06 Passkey. Native multi-scheme support is in production today: three classical account schemes coexist alongside zkLogin and Passkey and are mixable inside MultiSig accounts, with BLS12-381 reserved for authority signing and Move-runtime verification rather than user addresses. Adding a new scheme is a protocol upgrade coordinated through Sui's epoch-based protocol versioning. secp256r1 was added post-launch via protocol upgrade, so the agility path has been exercised.

Address aliases became active on Sui mainnet with release mainnet-v1.68.1, published 2026-03-25, which raised the maximum supported protocol version to 118; the address_aliases feature flag itself activates at protocol version 116, and protocol version 118 sets only use_coin_party_owner as a general-purpose authorization mechanism, and are now the declared post-quantum rebind vehicle. Sui's documentation states an address may carry at most 8 aliases and that a transaction requires a signature from one of the signers in its alias set, so this is deployed native key rotation, not a design. The docs list basic key rotation for an address as a use case and make no post-quantum claim, which matters: the mechanism was not built as a quantum feature and is being repurposed as one. Account-model component sits at 17, the AA-plus-documented-migration-path band: Sui has zkLogin (OAuth-derived accounts, which have no single Ed25519 seed, so the scheme floor does not apply to them), Passkey and MultiSig, plus a deployed rotation primitive and a Foundation-documented migration path in which an ML-DSA-65 private key is the same 32-byte seed size wallets already store, derived from the existing recovery phrase through a new derivation path. It is not the 20 band because no post-quantum key type exists to rotate to and there is therefore zero migration transaction volume. For single-key Ed25519 accounts the seed-rebind floor (6) remains subsumed by the higher account-model component under the MAX rule. PQ-rebind bonus is +2, the paper-stage band: the zero-knowledge seed-witness design is no longer the chain's chosen method, and the method now chosen involves no prover at all, so it cannot reach the testnet-prover band by construction. The freeze conjunct is also explicitly absent, the Foundation having stated there will be no forced migration and that nothing existing changes, which independently caps the bonus at the paper-stage band. 17 + 2 = 19. The residual risk a reader should hold: because the alias set authorizes on a signature from any one member, adding a post-quantum alias does not protect the account; removing the Ed25519 alias does, and nothing in the published design requires it.

Sui has shipped multiple coordinated protocol upgrades since the 2023-05-03 mainnet launch, including Mysticeti v1 to mainnet in July 2024 and Mysticeti v2 announced 2025-11-06, and releases reach mainnet roughly weekly (mainnet-v1.77.3, carrying protocol version 134, published 2026-08-23). The version stated in a release note is the maximum protocol version that binary supports, not the version the network is running: on 2026-08-24 mainnet was live on protocol version 133 at epoch 1229 while testnet ran protocol version 134 at epoch 1201. Upgrades are version-gated: Sui's documentation states that if two-thirds or more of validators vote to switch, the new protocol version takes effect at the beginning of the next epoch. No contested forks have occurred. Two deductions. First, no published Sui source states validator participation above 90% of stake within the target epoch, so only the documented two-thirds activation rule is credited. Second, and more material, the v1.72 release, which introduced address balances for gas payment, produced three separate mainnet halts across 2026-05-28 and 2026-05-29, so the most recent feature-carrying protocol upgrade on record did not land cleanly. That is directly relevant here, because adding a signature scheme is the same class of change.

The rubric asks whether hybrid classical-plus-post-quantum is architecturally possible rather than merely announced, and Sui now clears that bar with an unusually short remaining path: the MultiSig authenticator (flag 0x03) is already in production and already composes multiple schemes, and the Foundation has named the exact pair it will carry, an account requiring both an Ed25519 key and an ML-DSA-65 key. The composing machinery is deployed; only the post-quantum verifier is missing. Three deductions hold the score at 11 rather than higher: the ML-DSA-65 integration stops inside fastcrypto, where it merged on 2026-08-12 with no node dependency on it, nothing is on testnet, and no SUF-CMA-preservation or non-malleability analysis of the combiner has been published, which is what Gate 1a-Sig requires and what keeps that gate failing.

Full credit by rubric: chains using only stateless schemes score 15 by default, and SLH-DSA-SHA2-128s per FIPS 205 is stateless. A precision point a reviewer should not misread: the production cryptography library now contains an XMSS module, merged 2026-04-28, but that is the internal hypertree component of the FIPS 205 construction, not a standalone stateful XMSS deployment under RFC 8391 or SP 800-208. A second point, recorded but not scored: the same module's README also documents three draft SP 800-230 IPD parameter sets, which are signature-count-limited to 2^24 with a single XMSS tree. Those remain stateless, but a count-limited set would carry usage-tracking obligations if one were ever selected, and none is. Sui therefore has no stateful hash-based scheme in production or planned at any layer, the 4e state-management requirements do not bind, and the Stage-5 90-day state-management record requirement does not apply to it.

Undeclared, and the gap survives the 2026-08-06 announcement. Sui's node source types the authority key as BLS12-381 in min-sig mode and aggregates authority signatures into quorum certificates, so Sui sits squarely inside 4f scope. The consensus history sharpens rather than softens this: under Mysticeti v1 validators collected BLS signatures on each transaction's validity and aggregated them before re-broadcast, and Mysticeti v2 moved that signing into consensus block signing so that validators batch many transactions per signature. Both designs place BLS12-381 on the critical path. LayerQu read the announcement in full and its body contains no mention of Mysticeti, BLS, consensus signatures, aggregation or validator signing; it states positively that adding a signature scheme is a routine protocol-feature update and not a change to consensus or existing state. A repository sweep found zero occurrences of ML-DSA, MLDSA, SLH-DSA, SPHINCS, Dilithium or the new post-quantum crate anywhere in the node repository, so no post-quantum code touches the consensus-authority signing path or anything else in it. There is still no published specification for replacing BLS12-381 in the aggregation path. Under the consensus standing-exposure clause, a BLS-aggregating BFT chain whose validator public keys are epoch-public and which scores 0 here is flagged consensus-layer-exposed regardless of block time: fast finality is not a defence, because a capable quantum attacker forges an attestation or fabricates a quorum certificate without racing a confirmation window. Score 0, and Stage 5 is unreachable while it stands.

0%. No PQC primitive is deployed on Sui mainnet at the account-signing, consensus-signing, ZK-verification, or KEM layer. Re-verified 2026-08-24 three ways: against the latest mainnet release (mainnet-v1.77.3, published 2026-08-23, carrying protocol version 134), whose notes name neither ML-DSA nor SLH-DSA; against the latest testnet and devnet releases, which name neither either; and against a code search of the node repository, which returns zero hits for any post-quantum primitive name. The announcement itself states quantum-safe vaults are targeted for mainnet rather than shipped.

The score rests on verifiable merged code, then is heavily discounted for reachability. In favour: FIPS 205 primitive code is now merged into fastcrypto, the cryptography library the node builds against, across two dated pull requests (Winternitz one-time signatures merged 2026-04-21, 623 added lines; FORS, the XMSS hypertree and Merkle machinery merged 2026-04-28, 996 added lines), leaving roughly 44 KB of Rust across nine files in the sphincs module, whose README documents the twelve approved FIPS 205 parameter sets and the six draft SP 800-230 IPD sets, written as six and three rows respectively in {SHA2,SHAKE} brace notation and cites FIPS 205 final as normative. That is inspectable shipped code, a different evidentiary class from the prose roadmap that carried the claim before those merges. Against it, and why the score stays near the floor: the module sits in fastcrypto-pq, a crate the node does not declare as a dependency, so it is absent from default builds; the pull request that would have added top-level SLH-DSA sign and verify with NIST ACVP known-answer tests was closed without merging, so the merged code cannot produce or verify a single SLH-DSA signature as it stands; the ML-DSA-65 trait layer merged into the same library on 2026-08-12 with nothing in the node built against it; no node release names either primitive; and the node repository contains no reference to either primitive at all. Merged bytes exist in a library, a usable post-quantum signing path does not.

Zero validators on Sui hold or use PQC keys for consensus signing. All validators sign under BLS12-381 in min-sig mode, which is the only authority key type the node source defines.

VOIDED to 0 per the v3.1 rule (5a = 0). Sui does publish named dated milestones as of 2026-08-06: quantum-safe vaults targeted for mainnet in 2026, native ML-DSA-65 accounts targeted for testnet by end of 2026, native account authentication targeted for mainnet in Q1 2027, with wallet, SDK and CLI support alongside. They are qualified as targets while independent audits and testnet feedback continue, and the post states plainly that it reflects current direction and is not a finished, fully audited release. Under the rubric a chain with no shipped mainnet post-quantum traffic cannot bank milestone-discipline credit, so the sub-score is 0 regardless, and the Milestone-Discipline Cap fires on that voided value and binds Migration Stage at 2 or below. Two further deductions would apply even if the void lifted: the milestones are not protocol-enforced, and there is no delivery record to score them against, since these are Sui's first dated post-quantum commitments.

The score follows from literal application of the rubric. Eleven distinct post-quantum capability and milestone claims are made in the trailing twelve months, all of them in the 2026-08-06 post and all itemized in the pqc_washing block so a third party can reproduce the count, against zero mainnet bytes signed under any claimed primitive. That exceeds the 1.5 threshold and carries the 10-point deduction, taken here on the 15-point sub-score, giving 15 minus 10 equals 5, and it exceeds the 2.0 threshold, which adds a QRI cap of 65 that is non-binding at this score. LayerQu does not apply the narrative-only tag that the rubric fires above 5.0, and records that as a disclosed deviation rather than an application: that tag exists for a primitive claim with no technical artifact behind it, and Sui's claims are backed by merged FIPS 205 primitive code, an integration pull request merged on 2026-08-12 carrying published benchmarks and byte-exact interop vectors against an independent implementation, and a mainnet-deployed rotation primitive. Sui also labels its own status accurately. The deduction is for the distance between claim and deployment, not for dishonesty. With shipped mainnet bytes at zero the quotient is undefined rather than large; the reported figure is the announced-claim count.

The score is 0; the rubric band is applied exactly as written. The announced primitives now let the multiplier be computed rather than left blank: ML-DSA-65 per FIPS 204 carries a 3,309-byte signature with a 1,952-byte public key, roughly 52 times the 64-byte Ed25519 signature baseline in raw signature bytes, and SLH-DSA-SHA2-128s per FIPS 205 carries a 7,856-byte signature, roughly 123 times. Both sit above the 38-times band, which scores 0. Sui discloses the direction qualitatively, that transaction size rises while per-signature verification cost does not, and its own benchmark supports the second half of that (ML-DSA-65 verification measured at 24 microseconds against 28 for Ed25519 on an M2 Max), but it publishes no bytes-per-block figure, no aggregation or batching design for post-quantum signatures, and no recalibration of transaction-weight accounting that would stop post-quantum transactions being fee-penalised against classical ones. The post states only that the transaction size limit and programmable transaction blocks absorb the rest and that further optimization work is underway, which is not a design.

Wallets active for Sui include Slush (the Mysten Labs first-party wallet, formed in 2025 by merging Sui Wallet and Stashed), Suiet and Phantom (multi-chain, with Sui support). No published composite share data exists, so the top-3 reading is an analyst judgement, recorded as such. None publishes a PQC roadmap. The score rests on two thin but real signals: the Foundation has now stated that wallet, SDK and CLI support will arrive alongside the native account rollout, which is a first-party commitment covering the first-party wallet though it carries no date of its own; and the migration design is deliberately wallet-compatible, since an ML-DSA-65 private key is the same 32-byte seed size wallets already store and derives from the existing recovery phrase, so backup and restore are unchanged. Android 17's Keystore, verified independently against Google's own post of 2026-03-25, exposes ML-DSA-65 and ML-DSA-87 through the standard KeyPairGenerator API with key material generated inside the device's secure hardware, so a hardware-backed path exists for mobile wallets to adopt. Sui's post asserts that Android 17 skips the ML-DSA-44 parameter set entirely; Google's post names only ML-DSA-65 and ML-DSA-87 and makes no exclusion statement, so LayerQu records absence of mention, not a documented exclusion. None of this is a dated vendor roadmap, which is what full credit requires.

Bridges active for Sui include Sui Bridge (native, committee-operated), Wormhole/Portal and LayerZero/Stargate; no published composite share data exists, so the top-3 reading is an analyst judgement. None has a public PQC roadmap. Sui Bridge does not inherit the validator BLS12-381 key. The node source types the bridge committee key separately as an ECDSA secp256k1 keypair producing recoverable signatures, so the bridge is secured by secp256k1 and is Shor-breakable via discrete log without pairings, a different exposure class from the consensus authority key. No bridge assessed for Sui publishes a PQC roadmap under either announced primitive.

Institutional custodians documented as supporting SUI include BitGo, Copper, Fireblocks and Anchorage; no published composite share data exists, so no top-3 ranking is asserted, and no unnamed placeholder custodian is counted, because an unnamed vendor cannot be verified. None has shipped PQC-MPC custody. Checked and recorded because Sui now names a hash-based scheme: the 6c cap that limits chains mandating SLH-DSA to 15 of 25 does not apply here, because SLH-DSA-SHA2-128s is an opt-in scheme inside Move contracts for vaults rather than a mandated account scheme, and the native account scheme is ML-DSA-65, which is amenable to threshold multi-party computation, so a custodian path exists in principle.

HSM component: AWS KMS, a named vendor in the standard tooling Sui validators use, ships ML-DSA signing with three key specs, ML_DSA_44, ML_DSA_65 and ML_DSA_87, under the ML_DSA_SHAKE_256 signing algorithm. That is verified directly against the vendor's own notice, which is dated 2025-06-13, so this is established capability rather than a 2026 development, a point worth holding because the 2026-08-06 announcement cites it without a date. The vendor notice makes no FIPS 140-3 statement at any level and no substitute primary source was found, so no assurance level is attributed to those key specs here. RPC component: the RPC providers active for Sui, including the Mysten Labs public RPC, BlockVision and Shinami, publish no PQC roadmap, scoring zero. TEE component: no post-quantum remote-attestation path is declared for any trusted-execution use in Sui's stack, scoring zero. Other validator HSM options publish no shipped post-quantum key storage for this use.

Sui publishes that roughly three-quarters of all SUI is staked across more than 100 validators. Figures of about 116 validators from H1 2025 data and a top validator holding about 2.9% of total stake appear in no published Sui source, so neither is carried. What is documented is that voting power is proportional to stake within a 10,000-unit total. The validator set is permissioned-by-application, with the Foundation Delegation Program gating new entrants. There is a single canonical implementation of the Sui node, so single-client risk is real and is the main driver of the deduction.

Confirmed: a mainnet stall of roughly six hours on 2026-01-14, root-caused by an edge case in consensus commit logic under garbage-collection conditions in which an optimization path led validators to different commit conclusions; no certified state forks, no rolled-back certified transactions, and RPC reads continued serving last-certified state. Then three further halts across 2026-05-28 and 2026-05-29, all attributed to release v1.72, which introduced address balances for gas payment: roughly six and a half hours, then roughly three and a half hours from the same underflow reached through a masked cancellation reason, then roughly five and three-quarter hours from validators failing to persist distributed-key-generation status across restarts during an epoch transition. No committed transactions were reverted in any of them. Upgrade cadence itself remains high and mechanically sound: releases reach mainnet roughly weekly, and a protocol-version change activates at the next epoch boundary once two-thirds or more of validators vote for it. Three findings hold the score down. The incident count is four multi-hour liveness failures inside seven months. Three of them were caused by a single feature-carrying protocol upgrade, which is the same class of change a new signature scheme would be. Cryptographic machinery was involved: the third May halt was a distributed-key-generation state-persistence failure at an epoch boundary, which is exactly the coordination surface a post-quantum protocol-version bump would have to cross.

Named institutions: Sui Foundation for governance, grants and community; Mysten Labs for engineering. The score credits post-quantum direction now issued as institutional Foundation communication carrying dated public milestones and a stated independent-audit process, which is a published mandate rather than individual-researcher framing; the April 2025 predecessor piece on the same subject carried an individual byline and no dates, while the 2026-08-06 post is credited to the Foundation as an institution. Deductions: there is no Sui Improvement Proposal or equivalent numbered track for the change. A direct search of the improvement-proposal repository on 2026-08-24 returned no quantum-related issue, pull request or file at all, and the repository itself has not been pushed to since 2025-12-19. Named technical ownership is on the public record: a second Foundation post on 2026-08-18, 'From the cryptographer's desk: how we chose Sui's post-quantum signature schemes', is published under two named Mysten Labs cryptographers and sets out the parameter-set choice, the rejection of FN-DSA, the implementation provenance, the deferral of the zero-knowledge rebind path and an open invitation for external review. What remains absent is a chartered coordination body and a numbered improvement proposal, so the deduction is narrowed rather than removed.

No precedent of coordinated cryptographic change under live attacker pressure. Multiple smooth upgrades demonstrate baseline coordination capacity, and the 2026 incident record demonstrates that validators can be assembled to patch and re-vote a protocol version inside hours. No emergency-cryptographic-rotation drills are disclosed publicly.

No canary, no rate-limited spending rule, no cryptographic tripwire embedded in Sui consensus. No public proposal for one. The 2026-08-06 announcement introduces none, and its no-forced-migration policy means exposed classical keys will persist without any monitored or rate-limited exposure surface to serve as an early warning.