NEAR Protocol Advances Toward Quantum Resistance and Economic Redesign with nearcore 2.14.0 Release Candidate

SEOUL, TOKYO, LONDON — In a significant development for the decentralized infrastructure landscape, NEAR Protocol core developers have officially published the first release candidate for nearcore 2.14.0 (2.14.0-rc.1). Marking both a critical protocol upgrade and a complex database migration, this latest software iteration introduces sweeping changes to how the network handles transaction economics, data processing limits, and cryptographic security.

While everyday end-users will not need to interact with the software directly, the release marks a pivotal moment for validator operators, node runners, and smart contract developers. Most notably, the upgrade introduces native support for post-quantum cryptographic signatures—positioning NEAR as one of the forward-thinking layer-1 blockchains preparing for the looming computational paradigm shift.

Main Facts

The nearcore 2.14.0-rc.1 release is a comprehensive infrastructure update that alters fundamental operational mechanics within the NEAR network. Because it introduces simultaneous modifications to the network’s protocol rules and underlying database architecture, it requires careful coordination and rigorous testing by node operators before it graduates to a stable production build.

The core components of the nearcore 2.14.0-rc.1 update include:

• Elimination of Contract Gas Rewards: The protocol update reduces the burnt-gas reward parameter from 30% down to 0%, completely removing contract gas rewards. This adjustment alters the economic incentives for smart contract interactions on the network.
• Promise Input Size Bounds: The release introduces a strict programmatic bound on the combined size of resolved promise inputs. This safeguard prevents excessively large receipt inputs from bloating the network and growing without an explicit protocol-level limit.
• Post-Quantum Cryptography Integration: The inclusion of the ml_dsa_verify host function enables smart contracts to natively verify ML-DSA-65 signatures on-chain. ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a post-quantum digital signature standard, offering a glimpse into a future-proofed blockchain ecosystem.
• Database and Protocol Upgrades: Classified strictly as both a protocol and a database upgrade, the release requires node operators to update their systems to maintain consensus compatibility once the changes are enacted on-chain.

Chronology: The Path to nearcore 2.14.0

To understand the weight of the 2.14.0-rc.1 release, it is necessary to examine the evolutionary trajectory of the NEAR Protocol’s core software development lifecycle.

The Continuous Iteration of nearcore

The nearcore repository serves as the beating heart of the NEAR blockchain, housing the client implementation used by validators to process transactions, maintain state, and reach consensus via a delegated proof-of-stake (DPoS) mechanism known as Nightshade. Over the past several quarters, core developers have accelerated optimization cycles to improve sharding efficiency, state synchronization speeds, and developer ergonomics.

Routine updates to nearcore typically focus on bug fixes, performance tweaks, and minor optimizations that can be rolled out seamlessly. However, major version milestones—such as the transition from the 2.13.x series to 2.14.0—are reserved for structural adjustments that require consensus-breaking changes or state migrations.

The Release Candidate Phase

Following internal testing by the core development teams, software like 2.14.0-rc.1 is pushed to public repositories to enter the Release Candidate (RC) phase. During this window, independent validator operators, infrastructure providers, and decentralized application (dApp) developers deploy the candidate build to testnet environments or controlled staging nodes.

This phase is critical for identifying edge cases, memory leaks, performance bottlenecks, or unexpected database migration errors. Because 2.14.0-rc.1 modifies database storage layouts, improper handling during migration could theoretically lead to node desynchronization or downtime. Consequently, the developer community treats the RC stage as a mandatory stress test before a governance vote or epoch height schedules the activation on the mainnet.

Supporting Data & Technical Deep Dive

A granular look at the technical modifications contained within the 2.14.0-rc.1 changelog reveals a calculated effort to optimize network sustainability, resource management, and cryptographic resilience.

1. Phasing Out Contract Gas Rewards

One of the most economically sensitive changes in this release is the reduction of the burnt-gas reward parameter from 30% to 0%. Historically, NEAR featured a mechanism where a portion of the gas fees paid for executing smart contracts was rebated or rewarded back to the contract deployer or creator, incentivizing developers to build high-traffic applications on the network.

However, tokenomics and fee models across layer-1 networks undergo continuous refinement to prevent exploitation, spam, and misaligned economic incentives. By reducing the contract gas reward parameter to zero, NEAR is shifting toward a model where gas is strictly utilized for network security, validator compensation, and native token deflation (via gas burning), aligning more closely with standard industry practices seen in other major smart contract platforms.

2. Mitigating State Bloat Through Promise Input Bounds

Asynchronous communication between smart contracts on NEAR relies on "promises" and "receipts." In previous iterations, developers could theoretically pass large payloads through resolved promise inputs without strict size caps, creating vulnerabilities related to memory consumption and state bloat.

The 2.14.0 release introduces a hard ceiling on the combined size of resolved promise inputs. By capping these inputs at the protocol level, NEAR core developers are proactively safeguarding validator nodes from malicious or poorly optimized contracts that attempt to exhaust node resources via oversized data payloads. This ensures predictable execution times and preserves the health of the network’s state storage.

3. Introducing ml_dsa_verify: Stepping Into the Post-Quantum Era

Arguably the most forward-looking technical addition in 2.14.0-rc.1 is the introduction of the ml_dsa_verify host function.

To understand its significance, one must look at the existential threat that quantum computing poses to modern cryptography. Traditional blockchains rely heavily on cryptographic primitives like ECDSA (Elliptic Curve Digital Signature Algorithm) and Ed25519 for wallet signatures and transaction authentication. While sufficiently secure today, these algorithms are mathematically vulnerable to Shor’s algorithm running on a sufficiently powerful quantum computer, which could theoretically crack private keys derived from public keys.

To counter this, the National Institute of Standards and Technology (NIST) has standardized post-quantum cryptography (PQC) algorithms, including ML-DSA (Module-Lattice-Based Digital Signature Standard, formerly known as Dilithium).

By integrating the ml_dsa_verify host function, NEAR is providing smart contract developers with a native primitive to verify post-quantum signatures directly on-chain. It is important to contextualize this milestone: this single release does not automatically make the entire NEAR network quantum-proof. User accounts, consensus mechanisms, and legacy wallet keys remain anchored to traditional cryptography for now. However, it establishes a foundational building block. Developers who wish to construct quantum-resistant smart contracts, multi-sig vaults, or specialized authentication layers can now do so natively, without relying on inefficient, gas-heavy software emulation within WebAssembly (Wasm) runtime environments.

Official Responses and Developer Sentiment

The publication of nearcore 2.14.0-rc.1 has generated active discussions across GitHub, developer forums, and validator communication channels.

Core engineering leads have emphasized that the "Release Candidate" label should serve as a clear directive for the community: Test aggressively, but do not yet treat the code as immutable.

In developer update logs accompanying the GitHub release tag (https://github.com/near/nearcore/releases/tag/2.14.0-rc.1), maintainers highlighted the dual nature of the upgrade as both a protocol and database revision. Infrastructure teams managing institutional-grade validator nodes have already begun spinning up test instances to monitor memory utilization under the new promise-input size constraints.

Meanwhile, security-focused community members have welcomed the inclusion of the ml_dsa_verify function. In crypto-governance circles, proactive cryptographic migration is frequently discussed as a multi-year transition. By introducing post-quantum verification primitives at the host-function level today, NEAR developers are signaling a commitment to long-term protocol viability, ensuring that the blockchain does not get caught flat-footed when quantum computing hardware matures.

Implications for the NEAR Ecosystem

The rollout of nearcore 2.14.0 carries distinct implications for the various stakeholders that comprise the NEAR ecosystem.

For Node Operators and Validators

For the backbone of the network—the validators and RPC providers—this release demands proactive operational hygiene. Because 2.14.0-rc.1 involves a database upgrade, operators must thoroughly test the migration scripts provided in the release notes. Failing to update nodes in compatibility with the final protocol activation epoch could result in validation halts or slashing risks if nodes cannot process the newly enforced promise-input limits or economic parameters.

For Smart Contract Developers

Developers building decentralized applications on NEAR must take note of the new constraints and capabilities.

• Economic Adjustments: Teams relying on historical contract gas rewards must re-evaluate their financial models, as the zeroing out of these rewards alters dApp sustainability metrics.
• Payload Optimization: Developers must review their cross-contract call architectures to ensure they do not run afoul of the new size limits on resolved promise inputs.
• Cryptographic Innovation: Advanced developers exploring high-security use cases can begin experimenting with the ml_dsa_verify function to design cutting-edge, quantum-resistant security architectures for their applications.

For End-Users

For the average retail user holding NEAR tokens or interacting with consumer-facing dApps, the release of 2.14.0-rc.1 is entirely invisible in the short term. Users do not need to download software, update browser extensions, or manually migrate funds. However, they will indirectly benefit from a more secure, economically streamlined, and resource-efficient network infrastructure that is better shielded against spam, memory bloat, and future technological threats.

Conclusion

The release of nearcore 2.14.0-rc.1 represents a mature, forward-looking step for NEAR Protocol. By simultaneously tackling economic cleanup (removing contract gas rewards), network safety (capping promise input sizes), and futuristic security (introducing post-quantum signature verification), NEAR core developers are demonstrating a balanced approach to immediate operational health and long-term cryptographic survival.

As the software moves through the rigorous release candidate testing phase, the global validator community will play a decisive role in ensuring a smooth transition to the final stable production build. Once adopted, nearcore 2.14.0 will cement another foundational layer beneath NEAR’s high-throughput ecosystem, keeping the network competitive, secure, and resilient for the decade ahead.