The Changelog Line Nobody Read
The changelog for nearcore 2.14.0-rc.1 is short. Nine of its lines will be read by node operators in a hurry, because node operators read changelogs the way pilots read checklists โ scanning for anything that forces a restart, a resync, or a migration window. One line matters in ten years. Almost nobody is reading it.
Between a database migration note and a promise-size limit sits a new host function: ml_dsa_verify. It exposes ML-DSA-65 signature verification to any smart contract running on NEAR. ML-DSA is the Module-Lattice-Based Digital Signature Algorithm that NIST standardized in August 2024 as FIPS 204. To my knowledge, no other major L1 exposes post-quantum signature verification as a native, gas-metered host function inside its execution environment. Ethereum does not have it. Solana does not have it. NEAR now does, in a release candidate, without a press tour.
Three lines above, the same changelog does something quieter and more consequential: it moves the burnt-gas reward parameter from 30 to 0. Every contract on NEAR mainnet that has burned gas has been receiving a rebate โ thirty percent of the burned amount, credited back to the contract account. After this release, it receives nothing. The fee is destroyed in full.
One of these changes will generate a press cycle. The other will change the revenue model of every contract on the network. The industry will talk about the first and settle into the second without noticing.
What a Release Candidate Actually Commits You To
nearcore is the Rust implementation of the NEAR protocol โ the software validators and node operators actually run. NEAR's execution architecture is sharded. State is divided into chunks processed in parallel and composed into a single block, with chunk producers, chunk validators, and block producers occupying three different roles with three different data requirements. That architecture is why node software changes on NEAR are heavier than they look in a diff: a change that touches state layout touches every role at once.
A release candidate means the feature set is frozen. Bugs can still be fixed. Features cannot be smuggled in. For a protocol carrying real value, the RC stage exists for exactly one reason โ to let validator operators run the binary against production-shaped data before the network is permitted to change its own rules. This particular release is tagged as both a protocol upgrade and a database upgrade. That is a materially heavier class than a bugfix release. Protocol upgrades require a quorum of validators on compatible software before activation, or the chain partitions along version lines. Database upgrades change how node-local state is laid out on disk, which means the migration path, not the new features, is where the risk actually lives.
I have watched this exact failure mode from inside a codebase. In 2018 I spent three weeks in a line-by-line audit of the Parity Wallet multi-signature library, version 2.1. I found a logic flaw in the ownership update sequence that could be exploited during nested contract calls, and I refused to sign off on the release until it was patched and formal verification proofs were added. Management wanted the Q2 deadline. The delay ran two weeks. The lesson was not that reentrancy is dangerous โ everyone in this industry has that lesson memorized by now. The lesson was that state transition logic breaks in the places nobody writes tests for, and a migration script is nothing but state transition logic executed once, on every node, against data that was written by code that no longer exists.
NEAR's broader posture has been stable for years: Nightshade sharding, a deliberate bet on AI-adjacent workloads, a Swiss foundation structure, roughly fifty to one hundred active contributors to the core repository, and a daily active address count that has held in the low hundreds of thousands through both euphoria and apathy. Staking yields sit around eight to ten percent, funded by protocol inflation rather than by new entrants โ not a Ponzi structure, but a structure that requires watching. The distribution has not moved much: about ten percent to the team, roughly seventeen percent to early investors, thirty percent to community and liquidity programs, and the remainder sitting in a treasury and ecosystem fund that keeps getting spent slowly. Founder Illia Polosukhin came out of the TensorFlow core team, and the engineering culture of the project reflects that lineage โ rigorous, unglamorous, allergic to hype.
That context matters, because it explains why a post-quantum host function showed up in a minor version bump instead of a keynote.
The Deleted Subsidy
Start with the change nobody will cover.
The burnt-gas reward was a refund mechanism. When a contract executed, it consumed gas. A portion of that gas was burned, and thirty percent of the burned amount was credited back to the contract account as a reward. Read that mechanism from the perspective of a contract author and it is a rebate keyed to consumption. Read it from the perspective of the protocol and it is a subsidy paid out of the burn pool โ a transfer from every token holder, proportionally, to whichever contracts happened to burn the most.
Setting the parameter to zero does not change the user-facing gas price. Not a single transaction got more expensive. What changed is the destination of the money. Before the release: thirty percent to contract accounts, seventy percent destroyed. After the release: one hundred percent destroyed. This is a transfer between two non-user parties, and the release note describes it in eight words.
Ethereum made the opposite journey in reverse. EIP-1559 established full burn as the design principle โ blockspace is a sink, not a channel, and the value of the base fee accrues to holders of the asset rather than to any intermediary. NEAR has now converged on the same conclusion, several years later, with the same reasoning: a network that wants to price computation honestly cannot simultaneously pay a bounty for consuming it. You need the fee to be a fee. You cannot build a real fee market on top of a subsidy, because the subsidy distorts exactly the elasticity you are trying to measure.
There is a subtler distortion the rebate introduced, and this is the part I find most interesting. A thirty percent refund on burned gas makes computation cheaper relative to storage. Every contract on the network that had to choose between computing a value on the fly and storing it for later retrieval faced a marginal price that was skewed toward computation by the existence of the rebate. Compilers optimize; so do protocol designers; so do the developers reading the documentation. A rebate is a signal, and the signal pointed away from the state layer โ which on a sharded chain is precisely the layer that should be expensive.
When I reverse-engineered the Uniswap V2 constant-product invariant in 2020 and built a Python simulation across more than five hundred liquidity pools, the lesson I took was not about the formula. The formula is four lines. The lesson was that almost every protocol's published economics assume the second-order terms are zero. The gas rebate was a second-order term in the P&L of every contract on NEAR. It is now exactly zero, and contracts that were profitable on a thirty percent margin of error are no longer profitable. That is a real category of application, and it is not a large one. High-frequency bots, order-book routers, anything whose margin per call was thinner than the rebate โ those either reprice or leave.
The burn itself is a mild deflationary tailwind, competing against an inflation schedule that is capped annually. It is not a supply shock. It is an alignment.
The Promise Input Ceiling
the second change reads like housekeeping and is not.
NEAR's execution model is asynchronous. A cross-contract call is expressed as a promise, and the result of that call is delivered later as a receipt. Receipts carry input data. A contract can, in principle, produce a promise whose resolved input is arbitrarily large, and every node that validates the chunk must store and process that receipt.
Version 2.14.0 adds a ceiling on the total size of resolved promise inputs. This is a resource-abuse defense, and it belongs to a family of mechanisms every mature chain eventually grows: Ethereum's calldata pricing and block gas limit, Solana's per-transaction compute-unit budget. The mechanisms differ. The principle is identical. Bound the worst case; price the average case.
What interests me is the timing. Nobody adds a cap on resolved promise input size in a release candidate as an act of imagination. Caps like this appear after someone observes receipts growing in a shape the economic model did not anticipate. The cost of a large receipt is borne by every node in the validator set โ socialized โ while the benefit accrues to the single contract that created it โ privatized. That asymmetry is the defining negative externality of every blockchain ever built, and it is never solved, only repriced.
In 2021 I wrote a report demonstrating that sixty percent of popular NFT collections failed when a single gateway provider altered a caching policy. The report was framed as a critique of metadata centralization, but the durable finding was structural: the expensive layer in a decentralized system is almost never the computation. It is the storage and the indexing, and its cost is always paid by someone who did not choose to incur it. A promise input ceiling is that same finding, arriving three years later, on a different chain, wearing a changelog entry.
ML-DSA-65, and the Gas Schedule Nobody Published
Now the interesting one.
ML-DSA is a lattice-based signature scheme standardized by NIST in August 2024 under FIPS 204. Its security rests on the hardness of module-lattice problems โ learning with errors and short integer solution variants โ rather than on the discrete logarithm or integer factorization assumptions that ECDSA and EdDSA rely on. Shor's algorithm breaks the latter two. No known quantum algorithm breaks the former at the parameter sizes NIST selected.
The parameter set in question is ML-DSA-65. Its public key is 1,952 bytes. Its signature is 3,309 bytes. Compare that to the Ed25519 primitives NEAR uses today: a 32-byte public key and a 64-byte signature. Post-quantum verification is roughly a hundredfold increase in public key size and a fiftyfold increase in signature size.
Those numbers are the whole story on a blockchain, because on a blockchain signatures are data, and data is state, and state is priced.
A contract-side integration looks like this:
// the runtime exposes verification as a host function, not an opcode
let pk: [u8; 1952]; // ML-DSA-65 public key
let msg: Vec<u8>; // the signed payload
let sig: [u8; 3309]; // ML-DSA-65 signaturelet ok: bool = ml_dsa_verify(pk, msg, sig); if !ok { return PromiseResult::Rejected; } ```
Four lines. The entire post-quantum posture of a contract is those four lines plus whatever the runtime decides to charge for them. The art is the hash; the value is the proof.
And that charge is the actual engineering content of this release, because the cryptography was standardized by someone else. Verifying an ML-DSA signature is cheap relative to signing it โ no rejection sampling, no repeated norm checks against freshly sampled noise, just a matrix-vector product and a norm bound. But it is still orders of magnitude more expensive than verifying an Ed25519 signature. If the gas price of ml_dsa_verify is calibrated against the average case and not the adversarial case, the runtime has handed the network a new denial-of-service primitive: a single contract call that verifies a few thousand lattice signatures, charged at a flat and underpriced rate, while every validator in the set performs the arithmetic.
The changelog does not state the gas cost. Neither does the release announcement. That number is the thing I want to see, and it is the thing that will not be in a press release.
NEAR was also honest about the boundary of the feature, which is rarer than it should be. This host function does not make the network quantum-resistant. NEAR's account keys, its transaction signatures, its validator signatures, its threshold schemes โ none of them change in this release. If a cryptographically relevant quantum computer existed tomorrow morning, an ML-DSA verifier sitting inside a contract would not protect the account that holds the NEAR paying for the call. The feature is a tool for developers, not a shield for the network. Saying so in the release notes is the kind of statement that costs nothing and buys credibility, and most teams still refuse to make it.
So what is it for? Three uses, in descending order of how ready the ecosystem is to support them. Long-lived verifiable credentials โ attestations that must remain valid across a time horizon on which quantum hardware may arrive. Hybrid signature schemes, where a security-critical action requires both a classical and a post-quantum signature and the contract enforces the conjunction. And identity, which is where my own work has lived. In 2025 I helped design a proof-of-personhood protocol for autonomous agents, in which agents prove origin and intent without revealing proprietary algorithms. The hard problem was never the proof. It was key lifecycle: who rotates keys, who revokes them, and what happens to a credential that must survive twenty years. Post-quantum verification answers the third question and only the third question. That is more than anyone else has answered.
The Competitive Frame
Ethereum has no native post-quantum verification primitive. Solana has none. Among the large L1s, NEAR is now first, and the gap is not a marketing claim โ it is a host function with a Rust implementation and a parameter set defined in a NIST standard.
That is worth something, and it is worth less than the market will eventually price it at. NEAR's differentiation has always been technical foresight: sharding when sharding was unfashionable, AI-adjacent workloads before AI-crypto became a category, and now lattice signatures before quantum hardware exists. Technical foresight compounds slowly and pays out in lumpy installments. The lumpy installment here would be an enterprise or public-sector deployment that needs an on-chain credential type resistant to a threat model measured in decades. That customer type does not FOMO. It procures.
The Post-Quantum Narrative Is Not a Security Upgrade
Here is where I depart from the coverage this release is about to receive.
Exposing ml_dsa_verify is not a security upgrade. It is an optionality purchase. Optionality has a cost, and the cost is paid today by parties who will not receive the benefit for another decade.
Discipline about threat models first. Shor's algorithm breaks discrete-log and factoring assumptions, which is why ECDSA and EdDSA are the targets. Grover's algorithm gives a square-root speedup against symmetric primitives, which is why AES-128 is considered marginal post-quantum and AES-256 is not. A cryptographically relevant quantum computer โ one with millions of physical qubits and the error correction to keep them coherent โ has not been built, and the timelines are uncertain in both directions. The honest sentence is not that quantum computers will break NEAR. The honest sentence is that the migration horizon for a blockchain's key material runs ten to twenty years, and twenty years is comfortably inside the useful life of any chain that intends to hold institutional value. Doing this early is not paranoia. It is the only correct time to do it, because doing it late is impossible.
But there is a road missing. Exposing verification without exposing key aggregation and rotation means the destination exists and the highway does not. An ML-DSA-65 public key is 1,952 bytes. NEAR charges accounts to hold state. Push one post-quantum key into every account and you have added roughly sixty times the storage cost of a 32-byte Ed25519 key, for a threat that is not here yet. Whether the ecosystem wants to pay that premium is a governance question, not a cryptographic one, and the governance question has not been asked out loud.
The real story in this release is neither the lattice signature nor the rebate. It is the database upgrade โ the one changelog line that will receive zero coverage and carries the highest probability of an incident. Migrations execute once, against every historical edge case that ever reached disk, with no second attempt. Reentrancy doesn't care about your release calendar, and neither does a migration script that has to read a state layout written by a version of the code that no longer exists in the repository.
And the coordination risk is the most probable failure of the entire release, with nothing to do with lattices. If fewer than two-thirds of validators are running 2.14.0 before the activation point, the chain does not degrade gracefully. It stops producing blocks from the perspective of whichever side is in the minority, and the recovery is a social coordination exercise, not a technical one.
One more asymmetry worth naming. Post-quantum primitives are on the federal procurement timeline โ NIST standardization, CNSA 2.0 migration guidance, a decade-long compliance clock for government systems. A chain with native ML-DSA verification can answer a government RFP that no competitor can currently answer. That is a business development advantage wearing cryptographic clothing. But the same engineering that makes a network attractive to a state buyer also makes it legible to a state auditor. Compliance infrastructure is bidirectional, and every project that has ever built identity gates at the protocol layer has learned that the gate opens in both directions. Whether ML-DSA becomes the foundation of sovereign-grade accountability or sovereign-grade surveillance depends entirely on who ends up holding the keys, and the changelog is silent on that question. It always is.
There is also the unaudited surface. NIST reviewed the mathematics of ML-DSA. NIST did not review nearcore's Rust binding, its parameter validation, its handling of malformed encodings, or its behavior at the FFI boundary. Those are the parts that historically break. A standardized algorithm behind an unstandardized implementation is a standard only on paper.
Takeaway
Watch three numbers over the next ninety days, not the price chart.
First, the validator version distribution. The distance between "released" and "two-thirds adopted" is where this protocol upgrade either activates or stalls, and that gap is currently the least visible risk on the network.
Second, the first contract on mainnet that actually calls ml_dsa_verify with a real workload behind it. The day a named enterprise commits an ML-DSA credential to production, post-quantum stops being a narrative and becomes a fact. Until that day, it is a host function with an audience of zero.
Third, the published gas cost of lattice verification, and whether anyone outside the core team has audited the binding before the stable tag goes out. The math is standardized. The meter is not.
We do not build for today. The network that survives the next decade is the one that priced its worst case before it needed to โ and NEAR has taken one honest step here, plus one step that will be misunderstood by everyone who reads only the announcement. The changelog deserves every validator's scrutiny.