NEAR Protocol Post-Quantum Migration: Roadmap, Risks, and Holder Options

NEAR Protocol post-quantum migration is a topic that is gaining traction among security-focused holders as the quantum computing threat to blockchain cryptography moves from theoretical to engineering roadmap. This article examines what NEAR's current cryptographic architecture looks like, whether the NEAR Foundation has published any formal post-quantum roadmap, what a real migration would technically require, and what individual holders can do in the interim to reduce exposure. The goal is a clear-eyed analyst view, not speculation dressed as fact.

NEAR Protocol's Current Cryptographic Foundation

NEAR Protocol uses Ed25519 as its primary signature scheme for account keys and transaction signing. Ed25519 is an elliptic-curve signature algorithm built on Curve25519. It is widely regarded as one of the most efficient and secure classical signature schemes available today, offering strong resistance to classical attacks and relatively compact key and signature sizes.

However, Ed25519 shares the same fundamental vulnerability as all elliptic-curve and RSA-based schemes when it comes to quantum adversaries. A sufficiently powerful quantum computer running Shor's algorithm can, in theory, derive a private key from a public key in polynomial time. The moment a NEAR account's public key is visible on-chain, which it is after the first outgoing transaction, it is theoretically susceptible to a "harvest now, decrypt later" attack once capable quantum hardware exists.

NEAR also supports secp256k1 keys for Ethereum-compatible wallet integrations, which carries the same elliptic-curve vulnerability profile.

What Makes NEAR's Architecture Distinct

NEAR's account model is meaningfully different from Bitcoin's UTXO model. Each account is a named entity (e.g., `alice.near`) with associated key pairs stored in a dedicated on-chain account structure. This abstraction has a double-edged implication for post-quantum migration:

---

Does NEAR Have a Post-Quantum Roadmap? The Honest Answer

As of mid-2025, NEAR Protocol has no publicly announced, formal post-quantum cryptography migration roadmap. There is no NEAR Enhancement Proposal (NEP) that has reached draft or accepted status specifically addressing the replacement of Ed25519 or secp256k1 with a NIST PQC-approved algorithm. The NEAR Foundation's published research agenda and the NEAR Protocol GitHub repositories do not contain a dedicated post-quantum workstream at an active development stage.

This is not unique to NEAR. The vast majority of layer-1 blockchains, including Ethereum, Solana, and Avalanche, are in a similar position: acknowledged awareness of the long-term quantum threat, but no merged, production-ready migration plan. Ethereum researchers have discussed abstract pathways (such as Verkle trees and account abstraction as enabling infrastructure), but even Ethereum's post-quantum timeline remains undefined.

What does exist in the NEAR ecosystem:

The bottom line: holders and developers should not assume an imminent protocol-level fix. Planning personal security strategies around the assumption that NEAR will resolve this at the protocol layer on a known timeline would be imprudent.

---

What a Real Post-Quantum Migration Would Require

If NEAR were to undertake a post-quantum migration, it would be one of the most complex protocol upgrades in its history. Understanding the mechanics helps holders appreciate both the challenge and the timeline likely involved.

Selecting a NIST-Approved Algorithm

The first step is algorithm selection. In 2024, NIST finalised its first set of post-quantum cryptographic standards:

AlgorithmTypeStandardKey Use Case
**ML-KEM** (Kyber)Key encapsulationFIPS 203Key exchange / encryption
**ML-DSA** (Dilithium)Digital signatureFIPS 204Transaction signing (most relevant)
**SLH-DSA** (SPHINCS+)Digital signature (hash-based)FIPS 205Signature fallback
**FN-DSA** (FALCON)Digital signatureDraft FIPS 206Compact signatures

For a blockchain like NEAR, ML-DSA (Dilithium) or FN-DSA (FALCON) would be the most likely candidates for replacing Ed25519 as the transaction-signing scheme. Both are lattice-based. FALCON produces smaller signatures (closer to Ed25519 in size), while Dilithium offers simpler, more conservative implementation at the cost of larger key and signature sizes.

Protocol-Level Changes Required

A migration is not a simple swap. It would require:

  1. A new key type enum in NEAR's runtime. NEAR's `PublicKey` type currently enumerates `ED25519` and `SECP256K1`. A new variant (e.g., `DILITHIUM`) would need to be defined and supported across the runtime, RPC layer, and all SDKs.
  2. Transaction format updates. Signature fields in `SignedTransaction` structs would need to accommodate larger PQC signatures. Dilithium signatures are roughly 2.4 KB vs Ed25519's 64 bytes, a significant on-chain data cost increase.
  3. Validator key migration. The ~300+ NEAR validators each operate with Ed25519 keys for block production and attestation. All would need to rotate to new PQC keys, requiring coordination and a likely hard fork.
  4. Wallet and tooling ecosystem updates. Every wallet (MyNEARWallet, Meteor Wallet, Ledger integration, etc.) would need to generate and store PQC key pairs. Hardware wallet support for lattice-based schemes is still nascent.
  5. Smart contract interactions. Contracts that verify signatures on-chain (e.g., multisig contracts, cross-chain bridges) would need audited updates.
  6. A migration window for existing accounts. Users would need to add a new PQC access key to their existing NEAR accounts and eventually deprecate Ed25519 keys, ideally before the quantum threat window opens.

The Timeline Problem

Ethereum researchers have estimated a "safe" window of 10 to 20 years before cryptographically-relevant quantum computers (CRQCs) exist at scale, though some threat models compress this to 5 to 10 years given classified government hardware advances. The honest analyst position is that nobody knows the exact timeline, which is precisely why preparation now, rather than later, is the prudent approach. A migration of this complexity typically takes 3 to 5 years from specification to full network adoption, meaning the planning phase for any L1 arguably should already be underway.

---

Interim Options for NEAR Holders

While waiting for protocol-level solutions, NEAR holders are not without options. The risk is real but manageable with deliberate key hygiene.

Minimise Public Key Exposure

The core quantum attack vector requires knowing a public key. On NEAR:

Use Hardware Wallets for Key Storage

While hardware wallets do not currently offer post-quantum signature schemes for NEAR, they do provide strong protection against classical attacks and reduce the risk of private key extraction from software environments. This matters because most near-term threats remain classical, not quantum.

Monitor the Ecosystem for PQC Wallet Solutions

A small number of crypto projects are already building quantum-resistant infrastructure at the wallet layer rather than waiting for protocol-level changes. Projects implementing NIST PQC-aligned, lattice-based cryptography, such as BMIC.ai, demonstrate that post-quantum wallet security is achievable today with current NIST standards. For holders who want quantum-resistant custody of broader crypto portfolios while NEAR itself catches up, tracking this layer of innovation is worthwhile.

Diversify Custody Risk

Do not rely on a single access key or a single wallet application. NEAR's multi-key account model allows genuine key diversification across different devices and custody methods. This reduces single-point-of-failure risk in both classical and quantum threat scenarios.

---

What the NEAR Community Can Do to Accelerate Progress

Post-quantum migration does not have to wait for a top-down Foundation decision. The NEAR ecosystem has mechanisms for community-driven protocol development:

---

Comparing Post-Quantum Readiness Across Major Layer-1 Protocols

To contextualise NEAR's position, it is useful to benchmark against peers.

ProtocolSignature SchemeFormal PQC RoadmapKey Migration Flexibility
**NEAR Protocol**Ed25519, secp256k1No public planHigh (named accounts, multi-key)
**Ethereum**secp256k1Research-stage (EIP discussions)Medium (account abstraction helps)
**Solana**Ed25519No public planLow (address = public key hash)
**Algorand**Ed25519No public planMedium
**QRL**XMSS (hash-based PQC)Native, liveN/A (built PQC-first)
**Bitcoin**secp256k1No public planLow (UTXO model, complex)

NEAR's account abstraction model gives it a structural head-start relative to Bitcoin and Solana when migration eventually occurs, but that advantage is only realised if the migration is actually planned and executed.

---

Key Takeaways

Frequently Asked Questions

Does NEAR Protocol have a post-quantum cryptography migration plan?

As of mid-2025, NEAR Protocol has no publicly announced, formal post-quantum migration roadmap. There are no active NEPs (NEAR Enhancement Proposals) addressing the replacement of Ed25519 or secp256k1 with NIST PQC-approved algorithms. Community awareness of the issue exists, but there is no active engineering workstream committed to a timeline.

Which cryptographic algorithms does NEAR Protocol currently use, and why are they quantum-vulnerable?

NEAR primarily uses Ed25519 (elliptic-curve) for account keys and secp256k1 for Ethereum-compatible integrations. Both are vulnerable to Shor's algorithm, which a sufficiently powerful quantum computer could use to derive a private key from a publicly visible public key. On NEAR, public keys are visible on-chain after the first outgoing transaction.

What NIST-approved algorithms would NEAR likely use in a post-quantum migration?

The most relevant NIST-finalised candidates for transaction signing are ML-DSA (Dilithium, FIPS 204) and FN-DSA (FALCON, draft FIPS 206), both lattice-based digital signature schemes. FALCON produces more compact signatures closer to Ed25519 in size, while Dilithium is simpler and more conservative but generates larger signatures (~2.4 KB vs Ed25519's 64 bytes).

Is NEAR Protocol's account model an advantage for a post-quantum migration?

Yes, relatively speaking. NEAR's named-account model with native multi-key support allows users to add a new post-quantum key and remove the old elliptic-curve key without creating an entirely new account. This is architecturally friendlier than Bitcoin's UTXO model or Solana's address-equals-public-key-hash approach. However, this advantage only materialises if the protocol actually implements PQC key type support.

What can NEAR holders do now to reduce quantum risk before a protocol migration?

Holders can: (1) use scoped function-call access keys for dApp interactions to limit exposure of full-access keys; (2) periodically rotate full-access keys using NEAR's native key management; (3) use hardware wallets to reduce classical private key extraction risk; and (4) monitor PQC-native custody solutions that implement NIST PQC standards at the wallet layer while waiting for protocol-level changes.

How long would a full NEAR post-quantum migration realistically take?

Based on comparable protocol upgrades in the blockchain industry, a full migration, from specification through to widespread wallet and validator adoption, would realistically take 3 to 5 years. This includes time for NEP drafting, community consensus, runtime implementation, security audits, wallet ecosystem updates, validator coordination, and a user-facing key rotation window.