NEAR Developers Launch nearcore 2.14.0 Release Candidate Marking Major Protocol and Database Upgrade

Developers within the NEAR Protocol ecosystem have officially published the first release candidate for nearcore version 2.14.0, initiating a critical testing phase for a comprehensive suite of protocol and database modifications. Designated formally as version 2.14.0-rc.1, this new iteration represents a substantial structural evolution for the underlying architecture of the blockchain network. Unlike routine maintenance patches or minor bug fixes that primarily address backend anomalies, this release introduces fundamental adjustments to how the network handles gas rewards, processes promise inputs, and incorporates post-quantum cryptographic primitives.

Because the release candidate encompasses both protocol-level alterations and underlying database schema changes, it demands heightened scrutiny from validator operators, node administrators, and infrastructure engineers across the global NEAR network. Although the software is currently confined to a release candidate status—meaning its feature set is not yet permanently locked for production deployment—it signals the imminent arrival of architectural shifts designed to optimize network efficiency and prepare smart contracts for future cryptographic paradigms. For ordinary token holders and decentralized application (dApp) users, the immediate installation of software is unnecessary, yet the ripple effects of these foundational adjustments will ultimately dictate the capabilities and performance of the user-facing ecosystem.

Main Facts of the nearcore 2.14.0-rc.1 Release

The rollout of nearcore 2.14.0-rc.1 introduces three primary technical modifications to the core codebase, alongside critical adjustments to node database operations. First, the software alters the economic incentives surrounding smart contract execution by completely eliminating contract gas rewards. Previously, a portion of the gas consumed by smart contracts was rebated or rewarded in specific capacities; the new update reduces this burnt-gas reward parameter from 30% to zero, fundamentally altering the revenue distribution mechanics for contract deployers and network validators.

Second, the release implements a strict boundary on the combined size of resolved promise inputs. By capping these inputs, the protocol prevents excessively large receipt inputs from bloating blocks and consuming unbounded computational resources, thereby mitigating potential denial-of-service vectors and memory-overflow vulnerabilities.

Third, and perhaps most notably for long-term technological positioning, the update introduces a new host function designated as ml_dsa_verify. This function grants smart contracts the native capability to verify ML-DSA-65 signatures directly on-chain. ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a prominent post-quantum digital signature standard. While the integration of this host function does not instantaneously transform the entire NEAR network into a quantum-proof fortress, it equips developers with a vital cryptographic primitive. Consequently, developers who wish to future-proof their decentralized applications against the theoretical computational threats posed by quantum computing can now implement advanced signature verification schemes natively.

Chronology and Background Context

To understand the weight of the 2.14.0-rc.1 release, it is necessary to examine the evolutionary trajectory of the nearcore client and the broader philosophy governing NEAR Protocol upgrades. The nearcore repository serves as the beating heart of the NEAR blockchain, housing the Rust-based implementation of the protocol that powers validators, RPC nodes, and archive nodes.

Historically, the NEAR development roadmap has prioritized gradual, meticulously tested upgrades to maintain high throughput, low latency, and uninterrupted uptime. Major upgrades are rarely deployed instantaneously; instead, they follow a rigorous, multi-stage lifecycle. The process typically begins with internal code freezes and security audits, progresses to release candidate deployment on testnets such as Testnet and Betanet, and ultimately culminates in mainnet activation following governance approval and consensus-wide node adoption.

The introduction of nearcore 2.14.0-rc.1 fits squarely into this established chronological framework. Weeks prior to this release, core contributors discussed optimizations regarding state storage and gas economics within community governance forums and GitHub pull requests. As decentralized networks mature, the underlying database engines—which manage state transitions, account balances, and contract storage—frequently require restructuring to prevent storage bloat and latency degradation. The designation of 2.14.0-rc.1 as both a protocol and a database upgrade underscores the structural nature of these changes, recalling past milestones where state pruning and data layout optimizations were required to sustain the network’s high-speed transaction processing capabilities.

Supporting Data and Technical Specifications

Evaluating the scope of nearcore 2.14.0-rc.1 requires analyzing the specific economic and computational metrics affected by the upgrade. The reduction of the burnt-gas reward parameter from 30% to 0% represents a decisive shift in NEAR’s tokenomics model. In blockchain architectures, gas fees serve a dual purpose: compensating validators for computational effort and managing network congestion. By adjusting reward parameters, core developers can fine-tune the economic incentives aligning validators, developers, and the protocol treasury.

Simultaneously, the introduction of the promise input size boundary addresses a vector of resource exhaustion. In asynchronous execution environments like NEAR, smart contracts frequently utilize promises to handle cross-contract calls and asynchronous data resolution. Without explicit protocol-level caps, maliciously crafted or inefficiently coded contracts could theoretically pass massive payloads through promise inputs, stalling node execution threads and degrading consensus performance. The new size bound establishes a deterministic ceiling, ensuring predictable resource utilization across all validating nodes.

On the cryptographic front, the inclusion of the ml_dsa_verify function aligns NEAR with global initiatives led by organizations like the National Institute of Standards and Technology (NIST) to standardize post-quantum cryptography. As quantum computing research advances, traditional asymmetric cryptographic algorithms such as RSA and Elliptic Curve Cryptography (ECDSA/Ed25519) face long-term vulnerability threats. By introducing native support for ML-DSA-65—a lattice-based signature scheme selected for standardization—NEAR provides developers with an early-adopter mechanism to secure high-value or long-duration digital assets against future cryptographic decryption methods.

Official Responses and Validator Community Reactions

As is standard practice within decentralized open-source ecosystems, the publication of a major release candidate elicits immediate, methodical responses from professional validator operations, infrastructure providers, and community contributors. While formal executive statements from foundational entities are often consolidated closer to mainnet activation dates, technical leads within the validator community have already begun evaluating the build in staging environments.

Node operators have emphasized the necessity of treating database upgrades with extreme caution. Unlike purely functional software updates that can be rolled back or patched dynamically, modifications to the underlying database schema require careful state migration testing to prevent data corruption or synchronization failures. Conversations across developer Discord channels and GitHub issues highlight a proactive approach, with node runners setting up auxiliary testnet nodes to monitor memory consumption, CPU utilization, and state sync times under the new 2.14.0 parameters.

Furthermore, developer relations channels have noted a positive reception regarding the inclusion of post-quantum signature verification tools. While immediate adoption of ML-DSA-65 is expected to be niche—given the higher computational overhead associated with lattice-based cryptography compared to standard elliptic curves—security-conscious projects and enterprise-grade applications have expressed enthusiasm for future-proofing their smart contract architectures.

Broader Impact, Analysis, and Industry Implications

The release of nearcore 2.14.0-rc.1 extends far beyond the immediate technical adjustments of the NEAR ecosystem, offering broader implications for the layer-1 blockchain landscape. As networks scale, the delicate balance between economic sustainability, computational safety, and cryptographic longevity becomes increasingly pronounced.

The elimination of contract gas rewards reflects a broader industry trend toward rationalizing developer incentives. Many early-stage blockchain networks subsidized contract deployment and execution to bootstrap developer adoption. However, as networks mature and transaction volumes surge, protocols must transition toward sustainable economic models where fee distribution accurately reflects resource consumption and validator security requirements. By reducing the burnt-gas reward parameter to zero, NEAR is refining its economic parameters to ensure long-term fiscal health without disincentivizing legitimate network participation.

Simultaneously, the proactive integration of post-quantum cryptographic primitives positions NEAR as a forward-thinking player in blockchain security. While the mainstream cryptographic community debates the exact timeline of cryptographically relevant quantum computers, forward-looking protocol design dictates that infrastructure must evolve years ahead of actual threats. Smart contracts that manage institutional capital, decentralized autonomous organizations (DAOs), and digital identity frameworks will eventually require robust post-quantum defenses. By embedding ml_dsa_verify into the core protocol host functions, NEAR ensures that its developer base is not caught unprepared when the transition to post-quantum security becomes an industry-wide imperative.

Conclusion and Next Steps

The publication of nearcore 2.14.0-rc.1 marks a critical juncture in the ongoing development of the NEAR Protocol. By combining structural database upgrades, economic adjustments to gas reward parameters, promise input size limitations, and cutting-edge post-quantum cryptographic support, the core development team continues to fortify the network’s foundation.

As the software moves through the release candidate pipeline, the primary responsibility shifts to validator operators and testing frameworks to validate stability under realistic operational conditions. Once these rigorous testing phases conclude and any necessary adjustments are finalized, the release candidate will pave the way for a stable production build and subsequent mainnet activation. For the broader blockchain community, nearcore 2.14.0 serves as a compelling reminder of the continuous, meticulous engineering required to maintain a secure, scalable, and future-proof decentralized network.