NEAR Protocol is one of the more developer-friendly Layer 1 blockchains, known for its human-readable account names, sharded architecture, and the WASM-based smart contract environment. It has attracted significant developer activity and a growing DeFi ecosystem. But like most modern blockchains, NEAR was built around elliptic curve cryptography that a sufficiently powerful quantum computer will be able to break. Understanding exactly where NEAR's quantum exposure lies, and what a migration path would look like, matters both for current NEAR holders and for developers building on the network.
Is NEAR Protocol Quantum Safe?
No. NEAR Protocol uses Ed25519 as its default signature scheme, which is vulnerable to Shor's algorithm on a cryptographically relevant quantum computer. NEAR also supports secp256k1, equally vulnerable. Neither the NEAR Foundation nor the protocol roadmap has published a concrete post-quantum migration plan as of mid-2026.
The short answer is that NEAR is not quantum safe, and it is not uniquely exposed either. Ed25519 is the dominant signature scheme across modern blockchain networks precisely because it is fast, compact, and has strong classical security properties. The problem is that "strong classical security" and "quantum resistant" are not the same thing. Shor's algorithm, running on a fault-tolerant quantum computer with enough logical qubits, can derive a private key from a known public key in polynomial time. Ed25519 key pairs are no exception.
NEAR's Signature Schemes
NEAR supports two signing algorithms at the protocol level: Ed25519 (the default) and secp256k1 (for compatibility with Ethereum tooling). Both are based on elliptic curve discrete logarithm problems. Both are vulnerable to Shor's algorithm at the same fundamental level, though the specific quantum circuit requirements differ slightly between the two curves. Practically speaking, a quantum attacker who can break one can break the other.
Ed25519 uses the Curve25519 elliptic curve and produces 64-byte signatures. It is faster to verify than secp256k1 and is the recommended choice in NEAR's official documentation for most use cases. secp256k1 is the same curve used by Bitcoin and Ethereum, and NEAR's support for it is primarily to ease migration for developers coming from those ecosystems. From a quantum security standpoint, the choice between the two is irrelevant: both fall to the same attack.
Quick Win
Check whether your NEAR wallet uses a named account (e.g., alice.near) or an implicit account (a 64-character hex string). Named accounts can have multiple key pairs registered, which means changing your key pair after a quantum migration is straightforward. Implicit accounts are derived directly from a single Ed25519 public key, making them structurally more exposed.
NEAR's Account Model and Public Key Exposure
NEAR's account model is one of its distinguishing design features, and it has direct implications for quantum exposure analysis. Unlike Bitcoin or Ethereum, where an address is typically derived from a hash of the public key, NEAR has two account types that behave differently.
Named accounts (e.g., alice.near, myapp.near) are human-readable identifiers registered in the NEAR name registry. A named account can have multiple key pairs associated with it at different permission levels: full-access keys (which can do anything, including transfer NEAR and manage other keys) and function-call keys (restricted to calling specific contract methods). The public keys for all access keys associated with an account are stored on-chain in the account's state. This means every named account's public keys are fully visible to anyone who queries the chain.
Implicit accounts are 64-character hex strings derived directly from a single Ed25519 public key. The derivation is deterministic: the implicit account ID is the lowercase hexadecimal encoding of the 32-byte Ed25519 public key. This means that for implicit accounts, the account address and the public key are the same data expressed differently. There is no hash protecting the public key from the account ID. Any implicit account that has ever sent a transaction has its full public key on-chain.
For named accounts, the public key exposure is equally direct: the access keys are stored in account state and visible in any account query. The intermediate hash-to-address step that Bitcoin P2PKH and Ethereum provide (which offers some protection as long as an address has never sent a transaction) does not apply to NEAR accounts at all. Both named and implicit accounts have their public keys permanently and fully exposed.
This makes NEAR's entire active account base vulnerable in a post-quantum environment, not just the subset that has reused addresses or sent transactions. Unlike Bitcoin, where roughly 25 percent of BTC value sits in P2PKH addresses whose public key has never been revealed, NEAR has no equivalent protected category. Every active NEAR account is fully exposed by design.
Quick Win
If you hold NEAR in a custodial exchange account, your exposure depends on the exchange's key management practices, not on NEAR's protocol-level exposure. However, the underlying NEAR protocol keys used by the exchange to custody funds are still Ed25519 and equally vulnerable to a quantum attacker who can access the chain's key data.
Comparing NEAR's Exposure to Bitcoin and Ethereum
The contrast with Bitcoin is instructive. Bitcoin has three main address formats with different quantum risk profiles. P2PK addresses (very early Bitcoin) contain the raw public key in the locking script, fully exposed. P2PKH addresses hash the public key, providing protection until the address spends (which reveals the public key in the transaction). P2WPKH (SegWit) adds another layer of indirection. The net result is that a meaningful fraction of Bitcoin's supply, including most coins that have never moved, sits in addresses where the public key is not yet on-chain.
Ethereum is closer to NEAR: once an Ethereum address sends a transaction, its secp256k1 public key is revealed in the transaction signature. But Ethereum addresses that have only received funds and never sent have some hash protection, since the address is derived by taking the last 20 bytes of the Keccak-256 hash of the public key.
NEAR offers no equivalent hash protection for any account type. Named accounts expose their keys in account state. Implicit accounts are the key. For a more detailed comparison of exposure patterns across chains, see our analysis of which cryptocurrencies are most vulnerable to quantum attacks.
NEAR's Quantum Migration Roadmap: What Exists
As of mid-2026, the NEAR Foundation has not published a formal post-quantum cryptography roadmap. The NEAR Enhancement Proposal (NEP) process is the standard mechanism for protocol changes, and no NEP addressing quantum-resistant signatures has advanced to the draft stage. Academic and community discussions about post-quantum readiness exist in NEAR's developer forums, but they have not translated into a concrete timeline or a technical specification for migration.
This is not unusual for a chain of NEAR's age and focus. Most blockchain projects have prioritized scaling, ecosystem growth, and developer experience over cryptographic migration planning. The assumption, implicit or explicit, is that cryptographically relevant quantum computers remain far enough away that migration can be deferred. The quantum computing timeline debate is genuinely uncertain, but the trend of timeline compression in 2025-2026 makes deferral increasingly risky.
The specific technical challenge for NEAR is that a post-quantum migration would require changes at several layers of the stack. The signature scheme used for user key pairs, the scheme used for validator consensus signatures (which also uses Ed25519), and the serialization format for transactions would all need updating. NEAR's account model, while flexible, would need new primitives to support post-quantum key types.
What NEAR Validators Would Need to Do
NEAR's consensus mechanism (Nightshade, a sharded proof-of-stake protocol) relies on Ed25519 signatures for validator attestations. Validators sign blocks and shard chunks with their Ed25519 key pairs. Migrating validator signatures to a post-quantum scheme is a protocol-level change that would require hard fork coordination across the entire validator set, numbering in the hundreds of active validators at any time.
The validator migration has different timing considerations than user key migration. A sophisticated quantum attacker targeting NEAR would find user funds the more attractive target, since breaking a validator key provides short-term protocol disruption rather than direct financial gain. But validator key compromise would enable double-signing attacks and potentially allow a quantum attacker to manipulate block production, which is a systemic risk that goes beyond individual account theft.
The coordination challenge for validators is also different. Unlike wallet holders who can act unilaterally, validators must coordinate a simultaneous protocol upgrade. Any validator running old signature software after a hard fork would be incompatible with the network. The operational complexity of a validator migration is significant and requires months of lead time even with full community buy-in.
Signature Scheme Comparison
| Property | NEAR Protocol | QuanChain |
|---|---|---|
| Default signature scheme | Ed25519 | ML-DSA-87 (FIPS 204) |
| Secondary scheme | secp256k1 | SLH-DSA-SHA2-256f (FIPS 205) |
| Quantum resistant | No | Yes (from genesis) |
| Public key exposed on-chain | Yes, all accounts | Addresses are hash-derived; keys managed via TADEQS |
| PQC migration plan | None published | Native from day one |
| Validator key scheme | Ed25519 | ML-DSA-87 |
Timeline Risk for NEAR
The question of when NEAR faces real quantum risk depends on two variables: the timeline to a cryptographically relevant quantum computer, and the lead time required for NEAR's migration. On the quantum timeline, the honest answer is that estimates have compressed significantly in 2025-2026. The Coinbase Quantum Report released in early 2026 cited credible assessments placing a cryptographically relevant quantum computer in the 2028-2033 window under optimistic scenarios for error correction progress. The harvest now, decrypt later attack pattern, where adversaries record encrypted data or public keys today to decrypt later, means that exposure starts accumulating before Q-Day arrives.
On the migration lead time side, a realistic NEAR post-quantum migration would require: a NIST-standard algorithm selection, a NEP specification and security review, a testnet deployment period, validator client updates across the validator set, a wallet ecosystem update across all major NEAR wallets, a user key migration campaign, and a hard fork activation. End to end, this process is unlikely to complete in under 24 months from the decision point. The absence of even a draft NEP today means the clock has not started.
The combination of full public key exposure for all accounts and a migration process that has not yet begun puts NEAR in a position where it would need to move fast if quantum timelines accelerate. Chains that started their post-quantum work earlier are better positioned. Chains like QuanChain that were designed with post-quantum cryptography from the start have no migration problem to solve.
Compare Your Chain to QuanChain
QuanChain is the only blockchain built with post-quantum cryptography at the protocol layer from genesis. See how it compares.
Explore the Technology
