CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.12.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: TRUE
SECURITY_UPGRADE: FALSE
Protocol Changes
- The contract runtime has been upgraded to use the new Wasmtime-based runtime.
- The contract runtime now allows for bulk memory instructions in Wasm code.
Non-protocol Changes
- Fix VM compilation and cache metrics (
near_vm_runner_compilation_seconds,near_vm_compiled_contract_cache_*) not being reported for contract deployment, global contract distribution, and pipelining code paths. Add newnear_vm_compiled_contract_memory_cache_hits_totalmetric to distinguish in-memory cache hits from disk hits. (#15580) - Removed deprecated fields from
EpochConfig,GenesisConfig, andProtocolConfigView:num_block_producer_seats_per_shard,avg_hidden_validator_seats_per_shard,num_chunk_only_producer_seats. - New
EXPERIMENTAL_receipt_to_txRPC method that resolves a receipt ID back to the originating transaction hash and sender account. Requiressave_receipt_to_txconfig enabled and all-shards tracking. (#15414) - New sync handler (sync-v2) replaces the legacy sync implementation with a clean state machine. Nodes are routed through one of two paths based on how far behind they are: near-horizon nodes sync blocks directly, while far-horizon nodes follow the full pipeline (epoch sync, header sync, state sync, block sync). (#15335)
- Epoch sync proofs are now maintained incrementally at each epoch boundary instead of being derived on demand. Block headers are garbage collected alongside block bodies on non-archival nodes, reducing disk usage. (#15412)
- Validator key consistency check runs once per epoch to detect mismatches between the node's validator key and the key registered on chain. Misconfigured nodes will exit via panic. (#15417)
- State sync status now shows download and apply parts progress. (#15391)
- Fix: allow
Disconnectmessage on Tier3 connections. (#15405) - Fix: gracefully handle expired peer in
peer_connection_attempt. (#15390) - Archival nodes with split storage (cold store) will run a one-time migration on startup that is expected to take 1–2 hours depending on disk performance. Expect downtime. Nodes without cold store are not affected. (#15503)
Protocol upgrade voting
This release upgrades the protocol version from 83 to 84.
Voting for protocol version 84 will start on Monday June 1st 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 83 is expected to happen 7-14 hours after the voting epoch ends.