NEAR Testnet Starts Protocol 88 Vote; Mainnet Upgrade Remains Planned

BTCLiveETHLiveSOLLiveXRPLiveBNBLiveDOGELiveADALiveAVAXLive
CHARTING PARTNERTradingViewAdvanced charts, indicators and market tools.OPEN CHARTS →
Start with today’s trader mapBefore you leave: see the cross-asset levels, confirmations, invalidations and catalysts NetNapz is tracking for the next session.DAILY TRADER BRIEF →STRATEGY DESK →

NEAR Testnet Starts Protocol 88 Vote; Mainnet Upgrade Remains Planned

NEAR’s testnet moved into protocol-version 88 voting on 21 October. The production-network binary and its two-stage upgrade path are still planned work, not a completed mainnet activation.

Published 21 October 2026 · Testnet vote opened 21 October 2026 · NEAR protocol engineering

Black NEAR Protocol logo on a white background
NEAR Protocol logo. Wikimedia Commons, File:Near Protocol Logo.png; source listed as near.org/brand. Uploaded by Snpark369; author unknown. CC0 1.0 public-domain dedication. Editorial identification; trademark rights may still apply.

What opened on 21 October

The official nearcore 2.14.0-rc.4 release schedules testnet voting to move from protocol version 87 to 88 from 00:00 UTC on 21 October. The release tells testnet consensus operators to upgrade before voting and says activation is expected seven to fourteen hours after the voting epoch ends if the vote succeeds.

That wording describes a conditional process. NetNapz did not verify a completed vote or activation at publication time, and the release is explicitly marked as a testnet pre-release. It should not be read as evidence that NEAR mainnet has already moved to protocol 88.

Version 88 is a narrower follow-on step

The version-88 release notes identify two protocol changes. Repeating universal-state initialization on an account that is already initialized would refund the entire deposit, rather than also adding to storage staking. The same state-initialization input would also be accepted only in its canonical Borsh encoding, so one account and initialization have one valid encoding.

The release also says a receipt-promise input-size limit introduced at version 87 is effectively disabled at version 88 by setting it to the maximum value. A separate cold-store change keeps its loop running under RocksDB 10 stall, time-to-live and compaction-I/O conditions. The latter is listed as a non-protocol change.

Mainnet still has a separate release path

An open NEAR MPC release-tracking issue distinguishes the testnet build from the final mainnet binary. As of the checked issue, the mainnet binary was planned for about 26 October, with a tentative mainnet vote from protocol 85 to 87 around 2 November and a second vote from 87 to 88 around 3 November.

Those dates are planning markers, not completed events or guarantees. The issue remains open, the acceptance checklist is incomplete, and the final MPC release is still described as either 3.17.2 or 3.18.0 depending on whether additional features are ready.

The earlier mainnet step carries the broader changes

The two-stage plan matters because the larger 2.14 release line contains changes before the final move to version 88. Its release notes include removing the 30% function-call gas reward to contract accounts, adding an ML-DSA signature-verification host function, applying storage-proof limits more broadly and reassigning chunk-production work sooner when a producer repeatedly misses its slots.

Those changes have different operational and economic effects. Ending gas rewards changes one source of contract-account receipts; it does not itself establish lower user fees or higher token demand. Early chunk-producer reassignment aims to reduce the time that an unhealthy producer retains work, but its real-world effect requires mainnet observation after activation.

NetNapz assessment: watch the gates, not the calendar alone

Assessment: the testnet vote is a meaningful engineering checkpoint, but the investment-relevant evidence is still ahead. The next verifiable gates are a final mainnet binary, completed operator upgrades, successful version-87 and version-88 votes, actual activation and post-upgrade stability.

Readers should also separate protocol readiness from price conclusions. A successful upgrade can improve network capabilities and resilience without creating an automatic change in NEAR demand, validator economics or application usage. Conversely, tentative dates can move if release blockers or test results require more work.

Sources and verification limits

Checked 21 October 2026: the signed nearcore 2.14.0 release-candidate notes and the open NEAR MPC mainnet-release tracker. NetNapz verified the release labels, stated voting schedule, protocol-change descriptions and the tracker’s provisional mainnet sequence. It did not independently run a node, reproduce testnet voting, verify activation or treat the planning dates as final. The existing featured image and attribution were checked. This report is not investment advice.

Scroll to Top