Active primitives are well named in foundation documentation and in nearcore, and NEP-645 plus the in-repo post-quantum design document give an exact specification of the new ML-DSA-65 key type covering parameters, byte sizes, library, hashing, gas pricing and scope boundaries. The key type enum is exhaustive at three schemes with no fourth reserved. Deduction because there is no single foundation-published inventory of all primitives in protocol use, and because the Chain Signatures threshold protocols are named in the implementation repository rather than in user-facing documentation.

Consensus signatures and effectively all access keys in use remain Shor-vulnerable. The sole PQ-safe primitive in protocol use is the opt-in ML-DSA-65 transaction path, and we measured no traffic on it. The specification itself frames the protection as opt-in and per-key, with an account quantum-safe only to the extent that it relies on ML-DSA-65 keys.

One PQ family is deployed at protocol level: lattice, as ML-DSA-65 per FIPS 204. Lattice-only scores 5 by hard cap under the 1c rubric, and the diversity cap fires because no hash-based or code-based fallback is deployed at 5b or 5c. Ed25519, ECDSA secp256k1, the threshold ECDSA variants and threshold EdDSA all still reduce to elliptic-curve discrete log, and the RPC transport key exchange reduces to the same problem.

ML-DSA-65 targets NIST Security Category 3, and both NEP-645 and the in-repo design document state the mapping explicitly at protocol level, with the design document giving the interpretation as roughly 192-bit classical and roughly 96-bit Grover-equivalent. Ed25519 and ECDSA secp256k1 remain roughly 128-bit classical with no NIST PQC category. SHA-256 and SHA3-256 are Grover-weakened to roughly 128-bit. One protocol-level primitive now carries a NIST PQC category; the classical schemes that carry all measured traffic do not.

Credits: ML-DSA-65 is implemented through aws-lc-rs at an exact version pin rather than a range; a known-answer test guards against silent behavioral drift on version bumps; the underlying AWS-LC ML-DSA code is imported from mldsa-native, which is supported by the Post-Quantum Cryptography Alliance within the Linux Foundation, per an import manifest in the AWS-LC tree dated 2026-06-12; the design document reports a benchmarked verification-time distribution with the specific finding that verify time is flat across signature hint weights, so no crafted signature inflates verification; and signature malleability is analyzed and shown not to affect transaction identity, nonce consumption or replay protection. Deductions: the scheme is exposed through an API its maintainer marks unstable; NEP-645 states that no direct audit of the chosen library was performed and records whether to commission a dedicated external audit as raised during design and not formally resolved; a nightly-only protocol feature still fixes two ML-DSA-65 cost-charging defects that shipped to mainnet, one mispricing the gas-key storage fee on wire length instead of on-trie identifier length and one metering meta-transaction inner-signature verification on the wrong shard; NEP-645 records that signature validity is consensus-critical and that a second implementation disagreeing on a malformed-signature edge case would fork the chain, with only a known-answer test as guard; cross-network mirror and fork-network tooling either panics or silently skips ML-DSA-65 keys; a first-party core contract fails to deserialize an ML-DSA-65 key; and NEAR's Ed25519 verification rules remain non-standard versus mainline libraries. Chain Signatures MPC nodes, currently 8, still run threshold ECDSA and threshold EdDSA over Shor-vulnerable curves. Whether the exact vendored build behind the pinned aws-lc-rs version carries the 2026-06-12 mldsa-native import is not established from a public artifact.

NEAR-implicit accounts use the 64-character lowercase hex encoding of the 32-byte Ed25519 public key directly as the account ID, and a funded implicit account receives a full access key whose public key is the decoded account id, so the controlling public key is exposed at funding time rather than at first spend. ETH-implicit accounts derive from a secp256k1 public key through Keccak-256. Named accounts store one or more access keys' public keys on-chain across full-access and function-call permission tiers, and those keys are publicly readable through a standard read-only JSON-RPC view call. Every funded NEAR account exposes the public key or keys controlling its balance.

Same architectural exposure as 2a. Implicit accounts cannot exist on-chain without their public key being the address, and named accounts cannot hold funds without at least one access key being on-chain. Dormant and lost NEAR accounts carry the same exposure as active ones. There is no hash-wrapped address form that delays key revelation until spend. We located no public dataset quantifying dormant balances or the count of implicit accounts, so no magnitude is scored from it.

NEAR transactions bind to a recent block hash and are not replayable beyond a short validity window, so historical signature material does not on its own create new spend authority. Long-term forgery risk concentrates on accounts whose keys are never rotated. Access-key rotation is protocol-native, and a live PQ-safe spend path now exists on mainnet: add an ML-DSA-65 access key, then delete the classical key. We measured no exercise of that path and no public data measures rotation volume of either kind at scale.

We observed client-to-RPC connections on public mainnet endpoints negotiating TLS 1.3 with classical X25519 ECDH key exchange, not a hybrid post-quantum group. The nearcore architecture documentation describes the validator peer-to-peer handshake as Ed25519-signed peer edges over a raw TCP connection, with no TLS or Noise encryption step documented; that document self-flags as somewhat outdated during an in-progress network-protocol refactor, so this is treated as not documented as present rather than as a proven absence. No hybrid PQ KEM, meaning ML-KEM per FIPS 203, is declared in the validator stack, the RPC layer, or the Chain Signatures MPC-node transport.

Pseudonymous and fully transparent. The transaction structure carries signer account, the public key of the access key used to sign, receiver account, actions, nonce and block hash in plaintext, with no encryption, confidential-amount mechanism or account-obfuscation feature anywhere in the transaction or runtime specification. Every transaction, account and access-key entry is readable from any RPC node or explorer. Human-readable named accounts raise observability further versus opaque hex addresses, and many accounts are linked to off-chain identities through wallet flows or social handles.

The RPC layer is concentrated. Official documentation lists the foundation's archival endpoint as severely rate limited with no paid plan available, and lists FastNEAR, QuickNode, Ankr and roughly a dozen other commercial providers as the practical production paths. The foundation's non-archival public endpoint still answers requests but is not listed in the provider table as a supported public endpoint. No foundation-published or third-party per-provider request-share percentages were located, so concentration is inferred from the provider structure rather than measured, and a claim that the foundation's endpoints had been deprecated is unsupported.

Rainbow Bridge, connecting NEAR and Ethereum, and Aurora, NEAR's native EVM layer, link transaction flows in the clear on both sides. Omni Bridge routes outbound transfers through the Chain Signatures MPC service and verifies inbound transfers through light clients for Ethereum, Bitcoin and Zcash and through a third-party general-messaging protocol for Solana, BNB Chain and EVM layer twos. Chain Signatures by design connects NEAR accounts to transactions on Bitcoin, Solana, Cosmos, XRP, Aptos, Sui and EVM networks including Ethereum, Base, BNB Chain, Avalanche, Polygon and Arbitrum, all transparent, making cross-chain linkage explicit and observable.

Because NEAR is already pseudonymous and transparent at protocol level, a future Shor break does not expose meaningfully more than is already on-chain. Retroactive privacy regression is small relative to chains holding encrypted state on-chain. No NEAR-specific clustering or deanonymization study was located, so this rests on the structural transparency argument rather than on a third-party result.

No protocol-level mixnet, shuffle, or commit-reveal at consensus. No application-layer mixing infrastructure documented as live in the NEAR ecosystem at audit cutoff.

The access-key data structure is curve-pluggable in production fact, not just in principle. nearcore 2.13.0 extended the key-type enum with ML-DSA-65 at borsh tag 2 alongside Ed25519 at tag 0 and ECDSA secp256k1 at tag 1, gated by a single protocol feature and activated through the standard stake-weighted protocol-version vote, with no account redesign and zero state migration, because the action-validation gates guarantee no ML-DSA-65 value can enter state before activation. The design separates the wire-format public key from the on-trie handle at the type level, so a full key in the trie and a hash in a transaction are both unrepresentable. The algorithm-add mechanism is demonstrated in production, which is what this sub-score asks for. Deduction because validator and staking keys and implicit-account derivation are excluded from the mechanism so far.

NEAR's account model is native account abstraction: every named account holds multiple access keys across two permission tiers, added, removed and rotated by transactions with no smart-contract wrapper. The PQ migration is a shipped key-add in practice: the first-party command-line client added ML-DSA-65 key generation in v0.28.0 released 2026-07-09, labelled draft in its own changelog, and added hash-form public-key display in v0.30.0 released 2026-08-17, and the official JavaScript SDK shipped an ML-DSA-65 key pair class in a published release on 2026-07-30. A user can attach a PQ access key and delete the legacy Ed25519 key today. Scored 18 of 20 because the deployed-client-layer anchor requires active migration volume and we measured none. The seed-rebind floor remains subsumed by deployed native rotation, and the PQ-rebind bonus stays 0 because no zero-knowledge seed-rebind verifier is shipped and native rotation makes one unnecessary for live accounts. Forge exposure at Dim 2 is unchanged for any account that keeps a classical key.

The release record shows coordinated protocol upgrades on a regular cadence without contested forks: 2.11.0 on 2026-04-01, 2.12.0 on 2026-06-03, 2.13.0 on 2026-07-09, then patch releases 2.13.1 on 2026-07-15, 2.13.2 on 2026-07-27 and 2.13.3 on 2026-08-04. The 2.13 cycle demonstrates the cadence on a cryptographic change specifically: a release candidate carried the feature to testnet at protocol version 85 with voting opening 2026-06-30, mainnet moved from protocol version 84 to 86 with voting opening 2026-07-20, and three subsequent patch releases shipped with the post-quantum feature still present and not flagged back off.

An account can hold a full-access ML-DSA-65 key and a full-access Ed25519 key at the same time on mainnet, so the machinery for account-layer classical and post-quantum coexistence is live. Coexistence is not hybrid composition: either key alone authorizes a spend, so the account's security is the weaker of the two. The governing specification contains no hybrid-signing requirement, no AND-composition, no commit-to-hash construction and no combiner with a stated unforgeability reduction, and states directly that protection is opt-in and per-key. Credit for machinery that exists and can be used; the hybrid path itself is undocumented and, on our measurement, the machinery is unexercised.

N/A. NEAR deploys no stateful hash-based signature scheme; ML-DSA-65 is a lattice scheme with no one-time-key state to manage. Default 15 by rubric.

N/A. NEAR validator block and chunk approvals use Ed25519, a non-aggregating signature scheme, rather than pairing-based aggregation at consensus, and the consensus design stores one signature per approving validator. Per the v3.1 rubric, 4f is N/A for chains using non-aggregating signatures at consensus. Not scored, so it is left out of the dimension total rather than counted as a zero.

Measured at zero. The ML-DSA-65 signing capability is live and usable on mainnet, key-generation tooling is released in both the first-party command-line client and the official JavaScript SDK, and rotation is a single add-key then delete-key sequence, but no public source meters adoption and no block explorer offers a key-type filter. We measured it directly by two independent read-only methods over randomly drawn recent mainnet blocks: reading the signer key type of every transaction carried in sampled chunks, and reading every access-key change, which captures the nonce bump each signed transaction produces and so enumerates every key exercised per block. The larger run drew 698 blocks at random from the most recent 90,000 and returned 5,934 access-key change events, of which 3,957 were signing events. Every one was Ed25519. No ML-DSA-65 event appeared in either the signing subset or the full set, so no ML-DSA-65 key addition or deletion was captured either. With zero observations in 3,957 signing events the 95% one-sided upper bound on the ML-DSA-65 share of mainnet signing traffic is 0.076%. A separate check of the access-key lists of several large mainnet accounts, one holding over five thousand keys, also returned Ed25519 only. Zero observed is an upper bound rather than proof of zero, and a single rotated account anywhere on the chain would move this sub-score above zero and the stage to 3; that is recorded as a live re-check trigger rather than assumed in NEAR's favour.

ML-DSA-65 signing and verification are merged and stabilized in nearcore, the production client run by validators. The originating pull request was opened 2026-05-14 and merged 2026-05-25, and the code shipped in the 2.13.0 release on 2026-07-09 behind a protocol-feature gate, covering the key-type, public-key and signature enums, the separated on-trie handle type, SHA3-256 trie handling, transaction-size accounting that includes the large signature, and gas pricing in the transaction-validation path. This is mainnet code, not testnet-only, and we confirmed the gating protocol version is live on mainnet. Deduction: scope covers transaction signatures and access keys only, no PQ code touches block or chunk approval signing, and the contract-facing on-chain verification host function sits in the unreleased section of the changelog rather than in a shipped release, consistent with the specification placing it out of scope.

Zero, and structurally so. Validator and staking keys are excluded by protocol rule rather than by operator inertia: the specification keeps staking Ed25519-only and the staking-key validity check returns false for ML-DSA-65, so no validator can register a post-quantum key even voluntarily. Extending post-quantum signing to consensus keys is listed only as a future possibility with no date.

Void under the rule that milestone discipline earns no credit while mainnet post-quantum traffic is zero. On the underlying record: the 2026-05-06 roadmap post named one dated target, ML-DSA signing on testnet before the end of Q2 2026, and testnet protocol-version voting opened 2026-06-30 with activation expected seven to fourteen hours after the voting epoch ends, which lands at or just past the stated boundary rather than ahead of it; a claim that the chain beat its target is not supported. Mainnet followed on 2026-07-20 against no published date. Next steps are named but not dated: implicit-account derivation, validator keys and on-chain contract verification are listed as future possibilities, the on-chain verification host function sits in the unreleased changelog, and hardware-wallet support is described only as in progress. Fewer than three named, dated, enforcement-backed next milestones exist, so no credit would be earned even without the void.

Trailing-twelve-month announced claims: mainnet ML-DSA-65 transaction signing, which shipped and which we verified running; wallet and hardware-wallet support, which has not shipped, since Ledger's public NEAR page carries no post-quantum content of any kind; and a positioning claim describing the network as quantum-resistant infrastructure, which overstates an opt-in per-key capability while consensus signing remains Ed25519-only. Shipped: the mainnet signing capability and released first-party key tooling in both the command-line client and the JavaScript SDK. Ratio three announced to two shipped is 1.5, at the deduction threshold and not above it. The announcement-to-mainnet-capability gap was roughly eleven weeks and the headline claim is code-backed, which is why this is not tagged. The residual risk is that first-party positioning language and secondary coverage read opt-in account signing as chain-wide quantum safety.

Disclosed in full, and the footprint is large: an ML-DSA-65 signature is 3,309 bytes against 64 bytes for Ed25519, roughly 52 times the raw signature bytes, with the full 1,952-byte public key travelling on the wire, and on add-key it travels in addition to the signature. Verification is roughly 2.6 times slower than the classical schemes. The band above 38 times scores zero on the multiplier itself, but the chain earns partial credit for engineering the economics honestly: on-trie storage is a 33-byte hash handle at identical storage-staking cost to an Ed25519 key, verification is priced as a 100 Ggas surcharge burnt at transaction conversion so that classical users are unaffected and post-quantum signers pay their own cost, and the transaction-size accounting was corrected so the witness bound counts the full signature. No signature aggregation or batching plan is published, and pricing the extra wire and witness bytes is explicitly deferred.

No consumer wallet publishes a NEAR PQC roadmap. Ledger, the hardware vendor that NEAR's own coordination messaging names as actively working on support, shows no post-quantum, ML-DSA or quantum-safe content anywhere on its public NEAR page as checked. The layer beneath the wallets matters here: the official JavaScript SDK shipped an ML-DSA-65 key pair class in a published release on 2026-07-30 and a follow-up release on 2026-08-12, with the key type, 1,952-byte public-key size and 3,309-byte signature size all present in its public constants, so wallet builders now have a supported client-side path. The first-party command-line client can also generate ML-DSA-65 keys, though its own changelog labels the feature draft. Credit for a real, released SDK path; the tile stays low because a software library is not a wallet and no wallet vendor has published intent. A first-party core multisig contract still fails to deserialize an ML-DSA-65 key, which blocks one common custody pattern.

The bridge paths NEAR documents are Rainbow Bridge, connecting NEAR and Ethereum through smart-contract Ed25519 verification with a bonded optimistic challenge window; Omni Bridge, NEAR's chain-abstraction bridge, whose outbound transfers run through the Chain Signatures MPC service; and Wormhole, which Omni Bridge's own documentation names as the inbound verification path for Solana, BNB Chain and EVM layer twos. None publishes a PQC roadmap. No ranking of these by volume is asserted, because no published market-share data was located. No primary source shows a zero-knowledge Ed25519 verification upgrade live on Rainbow Bridge. The bridge repository is active, under Near-One/rainbow-bridge, last pushed 2026-04-09.

No custodian publishes a NEAR-specific PQC roadmap, which is what holds this tile down. The Rosetta/Mesh chain-API standard used by exchanges and custodians carries an ml_dsa_65 curve type and signature type, merged upstream on 2026-07-23, and nearcore's own design document records its implementation as complete, with all conversions implemented, no panics remaining, and unit tests. The standard integration path is open, so what remains is vendor intent rather than a technical block. Cross-network mirroring tooling cannot map ML-DSA-65 keys, which constrains institutional fork and replay workflows.

RPC: production traffic runs through commercial providers listed in official documentation, none of which publishes a PQC roadmap, while the foundation's archival endpoint is documented as severely rate limited with no paid plan available. We observed those endpoints negotiating classical X25519 TLS key exchange with no hybrid post-quantum group. HSM: validator key custody varies by node operator, with no foundation-mandated HSM requirement and no post-quantum HSM support named. TEE: no protocol-level TEE attestation chain.

Computed directly from the validators RPC : 411 validators in the current epoch with 423 seated for the next, roughly 619.7M NEAR staked, the largest single pool holding 6.43%, and cumulative stake crossing one third at rank 8, giving a Nakamoto coefficient of 8. Single-client implementation, with no published second-client validator share; the specification's own note that a second implementation disagreeing on signature validity would fork the chain makes that concentration cryptographically material rather than merely operational.

Protocol upgrades ship on a regular multi-week to multi-month cadence and activate through stake-weighted validator voting on a protocol-version feature gate, with the post-quantum feature going through the same gate as any other change and no special-cased governance track. The release record over the past five months shows this cadence sustained without contested forks or reverts. No upgrade under adversarial conditions has been demonstrated.

The PQC program has identifiable coordination. The 2026-05-06 roadmap post is authored by a named officer of the core development company, independently corroborated with the same name and title by two outlets the following day; the governing NEP carries a named author who is also the author of the client implementation and of the upstream chain-API specification change, which is unusually traceable single-thread ownership; and the mainnet launch was fronted by a named co-founder. Deductions: coordination attribution spans several people across the roadmap and launch announcements with no standing post-quantum working group or dedicated portal; and the formal paper trail lags the shipped code. The process runs draft, then review, then a voting period limited to two weeks, then approval or rejection, facilitated by moderators who explicitly do not assess technical feasibility, with a proposal automatically rejected if not approved within two months of review. There is no last-call stage. The post-quantum proposal remains at draft, the first formally tracked stage, roughly two months after the code it describes activated on mainnet.

NEAR has not faced a live cryptographic-break adversarial scenario, so there is no precedent for crisis coordination on a cryptographic change. Foundation-coordinated upgrades have proceeded under business-as-usual conditions.

No published community honeypot, no rate-limited spending rule, no cryptographic tripwire embedded in consensus, and no automated post-quantum incident-response procedure.