NEAR Protocol NEAR

Claim: NEAR has published a comprehensive cryptographic inventory identifying Ed25519 (default), secp256k1 (alternative), and the Chain Signatures MPC threshold schemes as quantum-vulnerable, with threat model covering accounts, consensus, and cross-chain infrastructure.

Coverage basis: Public documentation and official blog posts

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Primary sources from NEAR Protocol team (CTO blog post May 2026, official blog May 2026). Inventory is detailed and specific about affected layers and algorithms.

The cryptographic inventory explicitly identifies Ed25519, secp256k1, and MPC threshold ECDSA/EdDSA as quantum-vulnerable. The threat model covers account spend authorization, consensus validator signatures, and Chain Signatures cross-chain infrastructure.

• https://www.near.org/blog/making-near-protocol-post-quantum-safe
• https://near.org/blog/how-the-near-one-and-near-intents-teams-are-making-near-protocol-post-quantum

Claim: NEAR provides code references (nearcore GitHub), protocol specification (Nomicon), design documents, and reproducible analytics supporting the quantum risk assessment.

Coverage basis: Open-source code, protocol specification, design documentation

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: All evidence is publicly verifiable. nearcore is open-source (Rust). Nomicon provides protocol-level specification. ML-DSA implementation commit history is traceable with design rationale.

Evidence record is strong for the account/transaction layer. Consensus and P2P cryptographic documentation is available through Nomicon and source code. Chain Signatures MPC documentation is less detailed for cryptographic specifics.

• https://github.com/near/nearcore
• https://nomicon.io/Network/
• https://github.com/near/nearcore/blob/master/docs/architecture/how/post_quantum_signatures.md

Claim: ML-DSA-65 (FIPS-204) is available as an optional third signature scheme on mainnet since July 20, 2026 (upgrade 2.13, protocol version 86). Default signing remains Ed25519. Users can rotate access keys to ML-DSA via NEAR CLI in a single transaction.

Coverage basis: Optional mainnet PQ support; not default, mandatory, or enforced

Implementation score: 0.75 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Default spend authorization remains Ed25519/secp256k1; users can still create new quantum-vulnerable accounts by default (cap 60).

Assurance: Mainnet activation confirmed by nearcore 2.13.0 release notes, PR Newswire announcement, and GitHub commit history. ML-DSA-65 is gated by protocol feature flag, stabilized at protocol version 85/86. Implementation uses aws-lc-rs backend. No independent audit of the ML-DSA implementation exists.

Score 0.75 reflects optional mainnet support. Full 1.00 would require default, mandatory, or enforced PQ signing. The upgrade went live only ~5 days before evaluation; ecosystem tooling (wallets, exchanges) has not yet adopted ML-DSA.

• https://github.com/near/nearcore/releases/tag/2.13.0
• https://www.prnewswire.com/news-releases/near-protocol-brings-quantum-safe-signing-to-mainnet-302829646.html
• https://github.com/near/nearcore/commit/7b3c1a3838eb45aa0a57b1c2851ce79a594cd755

Claim: NEAR accounts use human-readable account IDs decoupled from cryptography with rotatable access keys. Migration to ML-DSA does not require address changes. However, existing accounts have exposed Ed25519/secp256k1 public keys on-chain creating long-exposure attack surfaces.

Coverage basis: Structural design advantage with existing exposed classical keys

Implementation score: 0.75 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The decoupled account model is a verified architectural property present since mainnet launch in 2020. Key rotation is a standard account operation. However, all accounts that have ever transacted have exposed classical public keys on-chain, creating a long-exposure at-rest attack surface.

Score 0.75 rather than 1.00 because while the account model elegantly solves address-migration problems, existing exposed public keys remain quantum-vulnerable at rest. The design prevents new exposure only if users rotate to ML-DSA.

• https://docs.near.org/
• https://www.prnewswire.com/news-releases/near-protocol-brings-quantum-safe-signing-to-mainnet-302829646.html
• https://www.near.org/blog/making-near-protocol-post-quantum-safe

Claim: NEAR's Doomslug consensus requires validators to sign endorsement and skip messages using Ed25519 signatures. Block production and finality depend on these validator signatures. No PQ path exists for consensus authentication.

Coverage basis: Ed25519-only validator signatures; no PQ path

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Consensus/validator authentication remains Ed25519-only. Quantum forgery of validator approval signatures could compromise finality and block production. Official blog (May 2026) confirms consensus requires longer-term research. Cap 70 applies.

Assurance: Confirmed by Nomicon protocol specification and nearcore source code. The CoinMarketCap secondary source claiming validator signatures were made PQ-safe in 2.13 is contradicted by the official nearcore 2.13.0 release notes which describe ML-DSA only as a 'transaction-signature and access-key scheme' and by the May 2026 official blog stating consensus requires longer-term research.

This is a critical quantum blocker. NEAR is a PoS chain where validator authentication is a core applicable layer. The 2.13 upgrade did not include consensus PQ protection. The secondary claim (CoinMarketCap) that validators were made PQ-safe is not corroborated by any primary source and is treated as a misunderstanding.

• https://nomicon.io/Network/
• https://near.github.io/nearcore/ChainSpec/Consensus.html
• https://near.org/blog/how-the-near-one-and-near-intents-teams-are-making-near-protocol-post-quantum
• https://qrindex.org/projects/near/

Claim: NEAR uses hash-based Merkle state commitments (SHA-256/Keccak variants) without KZG/pairing-based commitments, ZK proof systems, or other quantum-vulnerable cryptographic accumulators at the protocol level.

Coverage basis: Hash-based state integrity; satisfied by design

Implementation score: 1 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Verified from Nomicon specification and nearcore architecture. No independent audit specifically confirming the absence of quantum-vulnerable state-binding mechanisms, but the hash-based design is well-understood and verifiable from public code.

Satisfied by design. NEAR's Nightshade sharding uses hash-based Merkle proofs for state verification. Unlike Ethereum's planned KZG-based data availability sampling, NEAR uses Reed-Solomon erasure coding which does not depend on pairing assumptions.

• https://nomicon.io/Network/
• https://github.com/near/nearcore

Claim: NEAR Protocol does not have a native privacy layer, shielded transactions, or ZK proof system at the protocol level.

Coverage basis: No privacy layer exists

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Confirmed by protocol documentation and architecture review. No privacy features exist at the base layer.

N/A. Application-layer privacy solutions built on NEAR (if any) are outside the native asset evaluation scope.

• https://docs.near.org/
• https://nomicon.io/

Claim: NEAR nodes use Ed25519-based identities for P2P peer authentication and message signing. No PQ protection exists for the P2P layer.

Coverage basis: Classical P2P cryptography; not satisfied by design

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: P2P identity is not directly asset-spending-critical, but it is consensus-adjacent (nodes sign and propagate consensus messages). A quantum-enabled P2P identity compromise could enable eclipse attacks or consensus message manipulation. Not satisfied by design because spend authorization is not universally PQ-signed.

Score 0.00 reflects classical-only P2P cryptography. While P2P compromise does not directly enable asset theft, it is a network-layer vulnerability that could affect consensus message propagation.

• https://nomicon.io/Network/
• https://github.com/near/nearcore

Claim: NEAR CLI supports ML-DSA key rotation. Hardware wallets (Ledger, etc.) do not support ML-DSA. Software wallet ecosystem support is not yet available. Exchange/custody integration (Rosetta) does not support ML-DSA.

Coverage basis: CLI-only PQ tooling; no hardware or institutional custody support

Implementation score: 0.25 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: Hardware wallet gap is confirmed by official PR and QRI draft report. NEAR is collaborating with Ledger but no PQ hardware wallet exists. This is primarily an operational/product caveat—the protocol-level PQ path exists but critical custody infrastructure cannot use it.

Score 0.25 reflects that CLI tooling exists (prototype-level integration for the custody path) but hardware wallets, exchanges, and institutional custody—which secure the majority of value—cannot use ML-DSA.

• https://www.prnewswire.com/news-releases/near-protocol-brings-quantum-safe-signing-to-mainnet-302829646.html
• https://qrindex.org/projects/near/
• https://github.com/near/nearcore/releases/tag/2.13.0

Claim: ML-DSA went live on mainnet ~5 days before evaluation. Migration is opt-in. No data on migration coverage exists. Effectively ~0% of value-at-risk is protected by PQ signatures.

Coverage basis: Negligible migration coverage; <25%

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Near-zero migration coverage; all value (~$3B+ market cap, ~$200M+ DeFi TVL) remains on quantum-vulnerable Ed25519/secp256k1 keys with exposed public keys.

Assurance: No on-chain migration metrics are publicly available. The upgrade activated ~5 days before evaluation. Given the opt-in nature and lack of wallet/ecosystem support, migration coverage is reasonably estimated at <1%. Exact coverage cannot be verified without on-chain analytics.

Score 0.05 reflects <25% coverage per QRI coverage thresholds (score 1 out of 20 subfactor weight = 0.05 Implementation Score). NEAR's decoupled account model means migration is technically simple (one transaction), but ecosystem readiness and user awareness are the bottlenecks.

• https://www.prnewswire.com/news-releases/near-protocol-brings-quantum-safe-signing-to-mainnet-302829646.html
• https://github.com/near/nearcore/releases/tag/2.13.0

Claim: No evidence that NEAR Foundation treasury, major exchanges, custodians, bridges, or protocol-controlled wallets have migrated to ML-DSA keys.

Coverage basis: No critical wallet migration evidenced

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No public attestations or on-chain evidence of critical wallet migration. Given the upgrade recency (~5 days) and lack of hardware wallet support, it is highly unlikely any major institutional holder has migrated.

Score 0.00. Critical wallets (treasuries, exchanges, bridges) hold disproportionate value-at-risk. Their migration status is unknown but almost certainly unmigrated given the upgrade recency and ecosystem readiness gaps.

Claim: NEAR has identified the vulnerable surface (all Ed25519/secp256k1 accounts) but has no deprecation, freeze, burn, or enforcement mechanism for unmigrated classical keys.

Coverage basis: Identified but not deprecated or enforced

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The vulnerable surface is well-documented in official blogs. However, there is no published policy for deprecating, freezing, or burning unmigrated vulnerable value. No enforcement mechanism exists to prevent users from keeping or creating new classical keys.

Score 0.25 reflects that the vulnerable surface is identified (public inventory exists) but no measurable deprecation, freeze, or enforcement mechanism exists. The protocol allows indefinite coexistence of classical and PQ keys with no migration deadline.

• https://www.near.org/blog/making-near-protocol-post-quantum-safe
• https://near.org/blog/how-the-near-one-and-near-intents-teams-are-making-near-protocol-post-quantum

Claim: NEAR has published a phased roadmap: Phase 1 (accounts/ML-DSA) delivered July 2026; Phase 2 (consensus/validators) in longer-term research; Phase 3 (Chain Signatures MPC) in research by Defuse team.

Coverage basis: Partial roadmap with delivered Phase 1; later phases in research

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Phase 1 (account-level ML-DSA) delivered on schedule. Phase 2 (consensus) and Phase 3 (Chain Signatures MPC) have no committed timelines—described as 'longer-term research' and 'actively working' respectively. Roadmap is public and specific for delivered phase but uncertain for remaining phases.

Score 0.75 reflects a concrete, versioned roadmap with specific algorithm choice (FIPS-204) and delivered Phase 1, but incomplete sequencing for consensus and bridge layers with no committed dates for remaining phases.

• https://www.near.org/blog/making-near-protocol-post-quantum-safe
• https://near.org/blog/how-the-near-one-and-near-intents-teams-are-making-near-protocol-post-quantum
• https://www.prnewswire.com/news-releases/near-protocol-brings-quantum-safe-signing-to-mainnet-302829646.html

Claim: NEAR CLI supports ML-DSA key rotation. No default PQ account creation. No migration prompts or warnings. No hardware wallet support. No browser-extension or mobile wallet PQ support. No exchange custody path.

Coverage basis: CLI-only tooling; no defaults, prompts, or broad ecosystem support

Implementation score: 0.5 · Evidence confidence: High

Issue classification: operational/product caveat · Score treatment: score-reducing

Assurance: CLI support is confirmed by PR Newswire and release notes. Hardware wallet gap confirmed by multiple sources. The absence of default PQ, migration prompts, and broad wallet support means migration is accessible only to technically sophisticated users.

Score 0.50 reflects prototype/limited integration status: CLI tooling exists (comparable to testnet-level accessibility for the average user) but the broader ecosystem—wallets, exchanges, hardware devices—cannot use PQ signing.

• https://www.prnewswire.com/news-releases/near-protocol-brings-quantum-safe-signing-to-mainnet-302829646.html
• https://github.com/near/nearcore/releases/tag/2.13.0
• https://qrindex.org/projects/near/

Claim: No enforcement mechanisms exist. Classical keys (Ed25519/secp256k1) remain fully supported with no deprecation timeline. No freeze, burn, or mandatory migration policy. No exchange or custody coordination for migration.

Coverage basis: No enforcement or coordination mechanisms

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No enforcement, deprecation, or freeze mechanism for classical keys. Users can indefinitely maintain quantum-vulnerable accounts and create new ones by default.

Assurance: The 2.13 release notes confirm ML-DSA is added alongside existing schemes with no deprecation of Ed25519 or secp256k1. No migration deadline or enforcement mechanism has been proposed or documented.

Score 0.00. The protocol currently treats ML-DSA as an additive option rather than a migration. There is no path to deprecate classical keys, no mechanism to prevent new classical accounts, and no coordination with exchanges or custodians for migration.

• https://github.com/near/nearcore/releases/tag/2.13.0
• https://www.near.org/blog/making-near-protocol-post-quantum-safe

Claim: No formal quantum-specific incident-response playbook or emergency governance process has been published.

Coverage basis: No quantum-specific emergency process

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Absence confirmed by QRI draft report and lack of any published quantum-specific IR documentation. NEAR likely has general security incident processes but nothing quantum-specific is publicly documented.

Score 0.00. While NEAR likely has general governance and upgrade processes (demonstrated by the 2.13 upgrade itself), no quantum-specific emergency response playbook, disclosure process, or accelerated governance path for quantum breakthroughs has been published.

• https://qrindex.org/projects/near/

Claim: NEAR uses ML-DSA-65 (FIPS-204), a NIST-standardized post-quantum signature scheme formally standardized in August 2024.

Coverage basis: NIST FIPS-204 standardized algorithm

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: ML-DSA-65 (FIPS-204) is a NIST-standardized module-lattice-based signature scheme. This is the strongest possible algorithm choice for post-quantum signatures. NEAR's selection of a NIST standard rather than a bespoke or pre-standardization algorithm is appropriate.

Full score. ML-DSA-65 is the appropriate NIST-standardized choice for general-purpose post-quantum signatures.

• https://github.com/near/nearcore/commit/7b3c1a3838eb45aa0a57b1c2851ce79a594cd755
• https://github.com/near/nearcore/releases/tag/2.13.0
• https://csrc.nist.gov/pubs/fips/204/final

Claim: No independent third-party audit of the ML-DSA-65 implementation in nearcore has been identified. The PR #15731 received internal code review from multiple NEAR contributors but no external cryptographic audit was conducted.

Coverage basis: No independent audit; internal review only

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No independent audit of the ML-DSA-65 implementation exists. Implementation correctness for this security-critical new primitive is unverified by external review.

Assurance: PR #15731 received review from @frol, @ssavenko-near, @Trisfald, and @wacban—all NEAR contributors. While the review appears thorough (multiple rounds, 31 files changed), it does not constitute an independent third-party cryptographic audit. The aws-lc-rs backend provides some assurance for the underlying ML-DSA primitive, but integration correctness, key handling, signature verification logic, and protocol-level security require independent validation.

Score 0.00. The absence of independent audit is a quantum-critical uncertainty—while the implementation may be correct, this cannot be verified without external review.

• https://github.com/near/nearcore/pull/15731
• https://qrindex.org/projects/near/

Claim: The nearcore reference client is fully open-source (Rust) with public commit history, build instructions, and reproducible verification paths.

Coverage basis: Open-source repository with public commit history

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: nearcore is a well-maintained open-source repository with clear contribution history. The ML-DSA implementation is traceable through specific commits with design documentation. Build and test infrastructure is publicly available.

Full score. The implementation is fully open-source with detailed commit history, code review records, and design documentation.

• https://github.com/near/nearcore
• https://github.com/near/nearcore/commit/7b3c1a3838eb45aa0a57b1c2851ce79a594cd755
• https://github.com/near/nearcore/commit/ab0dc49772a4a152fe15a77d273c2b2b19260906

Claim: NEAR's multi-scheme key architecture (KeyType enum with Ed25519, secp256k1, ML-DSA-65) demonstrates parameter agility. Design document addresses future considerations.

Coverage basis: Multi-scheme architecture with documented upgrade path

Implementation score: 0.75 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: The KeyType enum with borsh tags (0=Ed25519, 1=secp256k1, 2=ML-DSA-65) provides clean parameter agility. The design doc explicitly addresses resolved vs. remaining work. Mirror/fork-network and Rosetta gaps are documented as known limitations.

Score 0.75 rather than 1.00 because: (1) mirror/fork-network PQ-key support is documented as incomplete follow-up work, (2) Rosetta API does not support ML-DSA-65, and (3) the upgrade path for consensus and Chain Signatures MPC layers is not yet designed.

• https://github.com/near/nearcore/blob/master/docs/architecture/how/post_quantum_signatures.md
• https://github.com/near/nearcore/commit/7b3c1a3838eb45aa0a57b1c2851ce79a594cd755
• https://github.com/near/nearcore/commit/ab0dc49772a4a152fe15a77d273c2b2b19260906

Claim: ML-DSA-65 is a stateless signature scheme (unlike XMSS/LMS), eliminating state-management risks. The implementation uses aws-lc-rs backend. No side-channel analysis, fault-injection assessment, or hardware security evaluation has been published.

Coverage basis: Stateless scheme; no published side-channel or hardware security analysis

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: ML-DSA is stateless, which eliminates the state-management risks associated with XMSS/LMS-style hash-based signatures. However, lattice-based schemes like ML-DSA have their own side-channel considerations. No side-channel evaluation, fault-injection assessment, or hardware security analysis has been published.

Score 0.25 reflects that the stateless nature of ML-DSA eliminates one class of risk, and the aws-lc-rs backend provides some implementation assurance, but no formal side-channel or hardware security evaluation exists.

• https://github.com/near/nearcore/commit/7b3c1a3838eb45aa0a57b1c2851ce79a594cd755

Claim: NEAR has documented ML-DSA-65 key sizes (1,952 bytes public key, 3,309 bytes signature, 4,032 bytes secret key), on-trie storage optimization (32-byte SHA3-256 hash), and verification cost (+100 Ggas). No comprehensive performance benchmark across validator, indexer, and archival infrastructure has been published.

Coverage basis: Basic gas costing and size documentation; no comprehensive benchmark

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The 2.13 release notes document the +100 Ggas verification charge and the on-trie hash optimization (32 bytes vs 1,952 bytes). However, no comprehensive benchmark exists covering: block validation impact with multiple ML-DSA signatures, mempool size implications, archival storage growth, bandwidth impact for validators and indexers, or resource requirements for hardware wallets and mobile devices.

Score 0.50 reflects that basic performance analysis exists (gas costing, storage optimization) but comprehensive resource-impact analysis across the full infrastructure stack is not published.

• https://github.com/near/nearcore/releases/tag/2.13.0
• https://github.com/near/nearcore/commit/7b3c1a3838eb45aa0a57b1c2851ce79a594cd755