2.8.1-rc.1

CODE_COLOR: CODE_RED_TESTNET
RELEASE_VERSION: 2.8.1-rc.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: TRUE

Note

This release fixes a critical flaw that could cause the chain to stall.
Upgrade as soon as possible to avoid node downtime.

2.9.1

CODE_COLOR: CODE_RED_MAINNET
RELEASE_VERSION: 2.9.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: TRUE

Note

This release fixes a critical flaw that could cause the chain to stall.
Upgrade as soon as possible to avoid node downtime.

2.9.0

CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 2.9.0
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Protocol Changes

This release will reduce the maximum inflation of Near Protocol from 5% to 2.5%.

Protocol Upgrade Voting

This release upgrades the protocol version from 80 to 81.
Voting for protocol version 81 is scheduled to begin on Tuesday, October 28th, 2025, at 01:00:00 UTC.

To prevent any downtime, please upgrade your mainnet node before this time if you support the protocol change included in version 2.9.

If the vote passes by end of the epoch that includes 01:00:00 UTC on Tuesday, October 28th, 2025, the protocol is expected to upgrade to version 81 approximately 7-8 hours after that voting epoch ends.

Conversely, if the vote does not succeed within the designated timeframe, the voting window will remain open for up to an additional 23 days. In this scenario, the protocol upgrade to version 81 is expected to occur in the epoch following the one during which more than 80% of stake has been upgraded. Should voting fail to conclude within 30 days, the release will be invalidated and withdrawn.

Note

This initial halving upgrade is a principles-driven and adaptive approach to maintain sustainability of issuance around the NEAR token, while also laying the foundation for a long-term and more systematic inflation strategy. This upgrade is based on community feedback and an initial vote across the entire NEAR ecosystem. Going forward, House of Stake will play a critical role in the decision-making process around the economic parameters for the NEAR ecosystem.

Our rationale for the upgrade is as follows:
The current 5% rate, originally designed to accelerate early-stage participation, now introduces unnecessary dilution. At the same time, it reduces the incentive for holders to engage in DeFi and other productive activities within the NEAR ecosystem.
The initial community based voting proposed by Hot_DAO has already gathered an overwhelming 91% pro from those who were able to vote. (Many validators operated by exchanges and funds refrained from voting due to compliance reasons.)
There will not be any forking of NEAR Protocol because such an upgrade will not be effective until the threshold has been reached.

Halving Impact: Inflation will be reduced to ca. 2.5%. Staking yield will accordingly change to ~4.75% assuming 50% of the total supply remains staked. This more sustainable inflation model aims to encourage greater on-chain participation in the NEAR ecosystem.

To support this transition, MetaPool, LiNEAR, HOT and Gauntlet have proposed two complementary programs designed to boost returns for the NEAR community for them to continue thriving in this new era of abundance.

1. Proposal – HSP-002: Support smaller validators to ensure network decentralization
2. Proposal – HSP-003: Increase rewards for veNEAR holders to reward early governance participation

2.8.0

CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 2.8.0
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Protocol Changes

The total number of chunk validators supported by the network is increasing from 300 to 500 allowing more validators to join the network. To maintain the network safety, the number of mandates per shard will also increase from 65 to 105.

Protocol upgrade voting

This release upgrades the protocol version from 79 to 80.
Voting for protocol version 80 will start on Tuesday, September 23, 2025, at 01:00:00 UTC.
To continue participating in consensus, you need to upgrade your mainnet node before this time.

If voting succeeds in one epoch, the protocol upgrade to version 80 is expected to happen 7-8 hours after the voting epoch ends. The targeted upgrade time is Tuesday, September 23, 2025, between 09:00 and 16:00 UTC.

Non-protocol changes

This release addresses an issue in the state snapshot migration, specifically when the hot database path is an absolute path.

Added a neard subcommand tool that can be used to recover data that was lost due to a bug in resharding. (#14185)

Note

Instructions how to use the archival data recovery tool:

# (optional) check that the data is missing 
# each of the following commands should fail with MissingTrieValue
neard database archival-data-loss-recovery --protocol-version 75 --check-only
neard database archival-data-loss-recovery --protocol-version 76 --check-only
neard database archival-data-loss-recovery --protocol-version 78 --check-only

# recover the missing data
neard database archival-data-loss-recovery --protocol-version 75
neard database archival-data-loss-recovery --protocol-version 76
neard database archival-data-loss-recovery --protocol-version 78

# check that the data is no longer missing
neard database archival-data-loss-recovery --protocol-version 75 --check-only
neard database archival-data-loss-recovery --protocol-version 76 --check-only
neard database archival-data-loss-recovery --protocol-version 78 --check-only

2.8.0-rc.2

CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.8.0-rc.2
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Non-protocol changes

This release addresses an issue in the state snapshot migration, specifically when the hot database path is an absolute path.

Added a neard subcommand tool that can be used to recover data that was lost due to a bug in resharding. (#14185)

Note

Instructions how to use the tool:

# (optional) check that the data is missing 
# each of the following commands should fail with MissingTrieValue
neard database archival-data-loss-recovery --protocol-version 75 --check-only
neard database archival-data-loss-recovery --protocol-version 76 --check-only
neard database archival-data-loss-recovery --protocol-version 78 --check-only

# recover the missing data
neard database archival-data-loss-recovery --protocol-version 75
neard database archival-data-loss-recovery --protocol-version 76
neard database archival-data-loss-recovery --protocol-version 78

# check that the data is no longer missing
neard database archival-data-loss-recovery --protocol-version 75 --check-only
neard database archival-data-loss-recovery --protocol-version 76 --check-only
neard database archival-data-loss-recovery --protocol-version 78 --check-only

2.8.0-rc.1

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.8.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Protocol Changes

The total number of chunk validators supported by the network is increasing from 300 to 500 allowing more validators to join the network. To maintain the network safety, the number of mandates per shard will also increase from 65 to 105.

Protocol upgrade voting

This release upgrades the protocol version from 79 to 80.
Voting for protocol version 80 will start on Tuesday 2025-09-09 14:00:00 UTC.
To continue participating in consensus, you need to upgrade your node before this time.

If voting succeeds in one epoch, the protocol upgrade to version 80 is expected to happen 7-8 hours after the voting epoch ends. The targeted time is Wednesday 2025-09-10 between 09:00 and 16:00 UTC.

2.7.1

CODE_COLOR: CODE_GREEN_MAINNET
RELEASE_VERSION: 2.7.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Note

While this release is marked as CODE_GREEN, it contains important stability and reliability improvements for nodes during both binary and protocol upgrades. We strongly encourage all node operators to apply this patch.

Non-protocol changes

• Added a configuration option protocol_version_check_config_override, making the node exit early if it has not been upgraded, instead of continuing to run and potentially corrupting the database. The option allows choosing whether to check protocol version compatibility against the Next or NextNext epoch (defaults to NextNext). (#14090)

• Fixed an issue with state snapshot migration — previously migration code only ran on the main database, which could prevent reading the snapshot after upgrading the binary. Now snapshots are properly migrated. (#13950)

• Fixed build issues on macOS by adjusting the process to statically link openssl regardless of whether it is vendored or not. This improves reproducibility and ensures builds work reliably across environments. (#14120)

Protocol upgrade voting

No protocol upgrade scheduled.

2.7.1-rc.1

CODE_COLOR: CODE_GREEN_TESTNET
RELEASE_VERSION: 2.7.1-rc.1
PROTOCOL_UPGRADE: FALSE
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Note

While this release is marked as CODE_GREEN, it contains important stability and reliability improvements for nodes during both binary and protocol upgrades. We strongly encourage all node operators to apply this patch.

Non-protocol changes

• Added a configuration option protocol_version_check_config_override, making the node exit early if it has not been upgraded, instead of continuing to run and potentially corrupting the database. The option allows choosing whether to check protocol version compatibility against the Next or NextNext epoch (defaults to NextNext). (#14090)

• Fixed an issue with state snapshot migration — previously migration code only ran on the main database, which could prevent reading the snapshot after upgrading the binary. Now snapshots are properly migrated. (#13950)

• Fixed build issues on macOS by adjusting the process to statically link openssl regardless of whether it is vendored or not. This improves reproducibility and ensures builds work reliably across environments. (#14120)

Protocol upgrade voting

No protocol upgrade scheduled.

2.7.0

CODE_COLOR: CODE_YELLOW_MAINNET
RELEASE_VERSION: 2.7.0
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: TRUE
SECURITY_UPGRADE: FALSE

[2.7.0]

Note: this is an upgrade from protocol version 77 directly to 79.

Protocol Changes

One more shard will be added

A new shard layout for production networks (#13324), using 650 as the split boundary #13609. The number of shards will increase from 8 to 9 shards.

Non-upgraded validators will be kicked out after the voting epoch

When the protocol update version voting takes place, validators that did not upgrade to the latest version will be scheduled for removal (aka kickout) in the epoch the new version takes effect (#13375). This helps avoid missed blocks in the first epoch of the new version, as un-upgraded validators would produce invalid blocks. Upgrading the node after the voting took place won’t prevent the kickout.

• With 2.7.0, non-upgraded nodes won’t be able to progress after the voting epoch.
• In future network upgrades, non-upgraded nodes would be able to progress in the epoch between voting and the network upgrade.

If you don’t upgrade your node in time, it will corrupt your database and require a reset (e.g. from snapshot or using Epoch Sync).

Other changes

• Implement NEP-536: Reduce the number of refund receipts by removing pessimistic gas pricing. Also introduce a gas refund penalty, but set it to 0 to avoid potential negative impact. (#13397)

• Implement P2P sync for state sync headers. (#13377)

• Increased the threshold for rejecting transactions due to missing chunks to 100 chunks, improving resilience during high congestion periods. (#13881)

• Enable saturating float-to-int conversions in runtime. (#13414)

Non-protocol Changes

• Add RPC query for viewing global contract code. (#13547)

• Add promise batch host functions for global contracts. (#13565)

• Stabilize EXPERIMENTAL_changes RPC method and rename it to changes. (#13722)

• Rename TxRequestHandlerActor to RpcHandlerActor to reflect the change in the scope of its responsibilities. Otherwise its API change is fully backward-compatible, so the dependent services can handle it by simply renaming the type where it is mentioned explicitly. (#13259)

• Improved state sync reliability by removing the assumption that the fallback source will eventually succeed. Sync now keeps trying both sources until the required part is obtained. (#13891)

Protocol upgrade voting

Voting for protocol version 79 will start on Monday 2025-08-18 01:00:00 UTC.

• You MUST upgrade your node before this time to continue participating in consensus.

Protocol upgrade to version 79 is expected to happen 7-14 hours later on Monday 2025-08-18 between 08:00 and 15:00 UTC.

Notes

Hardware requirements

After the binary update until the resharding (in protocol version 79), nodes that track the state need to load shard 0 into memory. This includes RPC, archival, indexers and validators with the exception of chunk validator nodes (outside of top 100) because they do not track any shards. To successfully go through resharding these nodes need at least 64GB of memory.

As with all the hardware requirements, validators that expect to become producers are also encouraged to have 64GB of memory.

The high memory requirements are in place from the moment of the binary update until the resharding process is finished in the epoch where protocol version 79 is adopted. After that, nodes that do not load memtries can be downscaled.

Recovery if it crashes during resharding

If neard is restarted or crashes immediately after the transition to the new protocol upgrade 79 (SimpleNightshadeV6), there's a possibility that the process won't be able to start correctly because resharding got interrupted.

The error you might see is:
Chain(StorageError(MemTrieLoadingError("Cannot load memtries when flat storage is not ready for shard s10.v3, actual status: Resharding(CreatingChild)")))

To remediate run the following command until completion:
neard flat-storage resume-resharding --shard-id 0

And finally start neard again.

Rollback from 2.7 to 2.6

If a node experiences issues after updating from 2.6 to 2.7, it’s possible to roll it back to 2.6, but it requires manual action to undo the database migration.
Rolling back is only possible before the end of the voting epoch - after that the network won’t be compatible with neard 2.6.
Please keep the logs from the rollback process in case you run into any issues.

To roll back a node from 2.7 to 2.6, do the following:

1. Stop the node.
2. Using a 2.7 neard binary, run neard database rollback-to26 and confirm the rollback. After confirmation the rollback process will start. Please don’t interrupt the rollback process, it could corrupt the database. Wait for the process to finish, it should be instant.
3. Database will be rolled back to the version used by neard 2.6.
4. Start the node using neard 2.6 binary.

Tracked shards config

Note: this config change is optional, and we will give a clear heads-up before old fields are fully deprecated.
The new way of specifying the tracked shards in config.json, is to use the tracked_shards_config field (introduced in #13154).

• For validators, use: "tracked_shards_config": "NoShards".
• To track all shards (e.g. RPC or archival nodes), use "tracked_shards_config": "AllShards".
• For failover shadow validator, use: "tracked_shards_config": { "ShadowValidator": "<validator_id>" }.

This config field cannot be used simultaneously with any of these deprecated fields (doing so will result in a panic at the neard startup): tracked_shards, tracked_accounts, tracked_shadow_validator, or tracked_shard_schedule.

Block production delay

It is advised (though not mandatory) to use the reduced (from 100ms to 10ms) block production delay (introduced in #13523). Doing so, would slightly improve your node performance. You can do it by changing the value in config.json: consensus.doomslug_step_period={"secs":0,"nanos":10000000}

Snapshot migration

For anyone encountering this error after upgrading their node:
ERROR sync: Cannot build state part err=StorageError(StorageInconsistentState("No state snapshot available
This issue should resolve itself after the epoch ends. It is not strictly required to take any action, but if you want to fix it immediately, you can run the following script (set NEAR_HOME and NEARD_BINARY appropriately, and run it before starting the new binary):

NEAR_HOME=/home/ubuntu/.near/
NEARD_BINARY=neard

cd $NEAR_HOME
SNAPSHOT_PATH=$(find $NEAR_HOME/data/state_snapshot/ -mindepth 1 -maxdepth 1 -type d | head -n 1)
cp config.json genesis.json node_key.json $SNAPSHOT_PATH
$NEARD_BINARY --home $SNAPSHOT_PATH database run-migrations
rm $SNAPSHOT_PATH/*.json

2.7.0-rc.4

CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.7.0-rc.4
PROTOCOL_UPGRADE: YES
DATABASE_UPGRADE: FALSE
SECURITY_UPGRADE: FALSE

Protocol Changes

• Increased the threshold for rejecting transactions due to missing chunks to 100 chunks, improving resilience during high congestion periods. (#13881)

Non-protocol Changes

• Improved state sync reliability by removing the assumption that the fallback source will eventually succeed. Sync now keeps trying both sources until the required part is obtained. (#13891)
• Fixed JSON‑RPC transaction status logic so that it only skips receipts that are actual refunds, preventing incorrect status reporting after the NEP‑536 gas‑refund reduction. (#13979)

Protocol upgrade voting

Voting for protocol version 79 will start on Tuesday 2025-08-05 02:00:00 UTC.

Protocol upgrade to version 79 is expected to happen 7-14 hours later on Tuesday 2025-08-05 between 9:00 and 16:00 UTC.