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:
- Easier key rotation: NEAR's native account model supports multiple access keys per account. Users can add and remove keys without creating an entirely new account, which is architecturally friendlier to a future migration than Bitcoin's address model.
- Broader attack surface: Because public keys are persistently associated with named accounts rather than single-use addresses, they are perpetually visible on-chain, extending the window during which a harvested key could be exploited once quantum hardware matures.
---
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:
- General acknowledgment in community discussions that quantum resistance is a future requirement.
- NEAR's account abstraction model (named accounts, multi-key support) is cited informally as a structural advantage for any future migration, since it avoids the need to create entirely new address formats.
- BOS (Blockchain Operating System) and chain abstraction work that could, in principle, facilitate a smoother key-management migration, though this is an indirect benefit rather than a stated goal.
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:
| Algorithm | Type | Standard | Key Use Case |
|---|---|---|---|
| **ML-KEM** (Kyber) | Key encapsulation | FIPS 203 | Key exchange / encryption |
| **ML-DSA** (Dilithium) | Digital signature | FIPS 204 | Transaction signing (most relevant) |
| **SLH-DSA** (SPHINCS+) | Digital signature (hash-based) | FIPS 205 | Signature fallback |
| **FN-DSA** (FALCON) | Digital signature | Draft FIPS 206 | Compact 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:
- 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.
- 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.
- 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.
- 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.
- Smart contract interactions. Contracts that verify signatures on-chain (e.g., multisig contracts, cross-chain bridges) would need audited updates.
- 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 fresh access keys for high-value operations rather than relying on a single long-lived full-access key whose public key is widely broadcast.
- Leverage NEAR's function-call access keys for dApp interactions. These are scoped, limited-permission keys. Compromising a function-call key exposes far less value than compromising a full-access key.
- Rotate full-access keys periodically. NEAR's account model allows this natively. Adding a new key pair and removing the old one is a supported, non-destructive operation.
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:
- Submit a NEP (NEAR Enhancement Proposal). The NEP process is the formal channel for proposing protocol changes. A well-researched NEP outlining PQC key type support would be the correct first step for any developer or researcher wanting to move this issue forward.
- Fund research through NEAR grants. The NEAR Foundation has historically funded protocol research. A proposal targeting PQC benchmarking on NEAR's runtime (measuring the throughput and storage impact of Dilithium or FALCON signatures) would be a tractable, fundable workstream.
- Engage validators. Validators are key stakeholders in any hard fork. Early engagement with the validator community around the operational requirements of PQC key management will be essential for any successful migration.
---
Comparing Post-Quantum Readiness Across Major Layer-1 Protocols
To contextualise NEAR's position, it is useful to benchmark against peers.
| Protocol | Signature Scheme | Formal PQC Roadmap | Key Migration Flexibility |
|---|---|---|---|
| **NEAR Protocol** | Ed25519, secp256k1 | No public plan | High (named accounts, multi-key) |
| **Ethereum** | secp256k1 | Research-stage (EIP discussions) | Medium (account abstraction helps) |
| **Solana** | Ed25519 | No public plan | Low (address = public key hash) |
| **Algorand** | Ed25519 | No public plan | Medium |
| **QRL** | XMSS (hash-based PQC) | Native, live | N/A (built PQC-first) |
| **Bitcoin** | secp256k1 | No public plan | Low (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
- NEAR Protocol's Ed25519 and secp256k1 keys are vulnerable to a sufficiently powerful quantum computer running Shor's algorithm.
- As of mid-2025, no formal NEAR post-quantum migration roadmap exists. Community awareness is present; engineering commitment is not.
- A real migration would require new key type support, transaction format changes, validator coordination, wallet ecosystem updates, and a user-facing key rotation process. It is a multi-year effort.
- NIST's finalised PQC standards (ML-DSA/Dilithium, FN-DSA/FALCON) provide the algorithm candidates that any such migration would most likely draw from.
- NEAR's named-account, multi-key model is a genuine structural advantage for a future migration compared to UTXO-based chains.
- In the interim, holders should minimise unnecessary public key exposure, rotate access keys, use hardware wallets, and monitor the emerging layer of PQC-native custody solutions.
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.