Skip to content
Blockchain Posts

protocol

NEAR opens voting for protocol version 84 — Wasmtime runtime on mainnet

Validator voting for NEAR protocol version 84 opened June 10, 2026, 00:00 UTC. nearcore v2.12.0 switches the contract runtime to Wasmtime and enables Wasm bulk memory ops.

by 6 min read
protocolnearinfrastructure

NEAR validators began voting on protocol version 84 at 00:00 UTC on Wednesday, June 10, 2026, the activation gate for the nearcore v2.12.0 mainnet release. If the vote carries in one epoch, the upgrade ships 7–14 hours after the voting epoch ends — landing on mainnet during the June 10–11 window. The primary source is the GitHub release nearcore v2.12.0, tagged on June 3, 2026.

What ships in v2.12.0

The release carries two protocol-level changes and a queue of non-protocol items that affect validator and archival operators. The headline is the runtime swap: contract execution moves from NEAR's legacy WebAssembly runtime to a Wasmtime-based runtime, and the EVM-equivalent step is the enablement of WebAssembly bulk memory instructions in contract code.

nearcore v2.12.0
- Tag             : 2.12.0
- Released        : 2026-06-03
- Type            : mainnet
- Protocol upgrade: yes (83 → 84)
- Database upgrade: yes
- Security        : no

Protocol changes
- Contract runtime → Wasmtime-based runtime
- Wasm bulk memory instructions enabled in contracts

Non-protocol highlights
- New RPC method  : EXPERIMENTAL_receipt_to_tx (receipt → tx hash)
- New sync handler: sync-v2 state machine (replaces legacy sync)
- Validator       : epoch-based registered-key consistency check;
                    misconfigured nodes shut down
- Archival        : cold-storage cold-DB migration on startup, 1–2h
- Storage         : epoch-boundary proofs maintained incrementally;
                    block headers GC'd on non-archival nodes
- Cleanup         : deprecated fields removed from EpochConfig,
                    GenesisConfig, ProtocolConfigView

Voting
- Start           : 2026-06-10 00:00 UTC
- Activation      : 7–14 hours after voting epoch ends
- Action required : validators must run ≥ v2.12.0 before voting starts
Source: github.com/near/nearcore/releases/tag/2.12.0

Mechanism — what the runtime swap actually changes

Wasmtime is the Bytecode Alliance's production WebAssembly runtime; it powers Substrate, Fastly's edge stack, several wasm-on-server platforms, and is the de facto reference Wasm engine outside browsers. NEAR previously shipped a heavily-customized fork of an older Wasm engine. Moving onto Wasmtime brings NEAR's contract execution path closer to the upstream Wasm spec and to the security advisories the Bytecode Alliance ships on a fixed cadence (most recently in April 2026).

The bulk memory activation is the matching primitive enablement: Wasm opcodes memory.copy, memory.fill, memory.init and data.drop are now legal in compiled contract code. For contract authors, those four opcodes turn what were inlined byte-by-byte loops into single instructions — a meaningful gas-and-size win on any contract that moves blob data around.

The VM compilation and cache metrics rework is the operational side of the same change: nearcore now exposes Prometheus-style metrics that distinguish in-memory cache hits from disk hits across the deployment and pipelining paths, so operators can see the post-Wasmtime baseline clearly. The release also adds an EXPERIMENTAL_receipt_to_tx RPC method — given a receipt ID and the right tracking config, you get back the originating transaction hash — closing a real gap for indexers and explorers that previously had to walk back from receipts manually.

Sync-v2 and the archival migration

The other big quality-of-life item is sync-v2: a new state-machine sync handler that replaces the legacy implementation, routing nodes onto the right sync path (block sync, state sync, epoch sync) based on how far behind head they are. The release notes emphasize this is a clean rewrite, not a wrap of the old code — so operator-facing bugs in the legacy sync are the natural watch item for the first week after activation.

For archival operators with cold storage, the upgrade carries a one-shot migration on startup of 1–2 hours. That's the price of the epoch-sync-proofs change: proofs are now maintained incrementally at epoch boundaries rather than derived on demand, which trims later sync work but requires backfilling the existing dataset once. Non-archival operators see a smaller upside — block headers can now be garbage-collected on non-archival nodes, shrinking the on-disk footprint.

Impact

  • Validators must run ≥ v2.12.0 before 00:00 UTC June 10. Anything older drops out of consensus when the vote epoch begins. The release notes are explicit on this point.
  • Contract authors get bulk-memory primitives. Existing contracts continue to run; new compilation targets can opt into the opcodes for size and gas wins on byte-blob workloads (serialization, image processing, large message buffers).
  • Wallet/exchange operators have a maintenance window. Binance announced support for the upgrade with a temporary suspension of NEAR deposits and withdrawals during the activation window; trading continues. Other CEXes typically follow the same pattern.
  • Indexers can lean on the new RPC. EXPERIMENTAL_receipt_to_tx removes a known pain point for receipt-tracing tools — though the EXPERIMENTAL_ prefix means the API may move before it's stable.
  • Validator-key safety net. The epoch-boundary consistency check that shuts a node down on key misconfiguration is the kind of guardrail that prevents the long-tail "I rotated keys and didn't notice for three epochs" failure mode.

What to watch

  1. Voting outcome at the first epoch boundary. Protocol version 84 needs supermajority validator support in a single epoch to ship at the 7–14h cadence stated in the release notes. A no-vote pushes the timeline.
  2. Activation block on mainnet. The exact block height the upgrade lands at is what indexers and bridges will key off — watchable on any NEAR explorer once the voting epoch closes.
  3. First Wasmtime-runtime contract panics. A runtime swap of this scope hides edge cases. The first week of mainnet activity is the empirical test of the gas-meter parity between the legacy runtime and Wasmtime; any drift shows up as either out-of-gas reverts on contracts that worked yesterday, or as cheaper execution on common paths.
  4. Sync-v2 stability for archival nodes. Cold-storage operators going through the 1–2 hour migration are the natural canary for sync-v2 — any regression here surfaces in archival RPC providers (FastNEAR, Pagoda's RPC, exchange archival fleets) before it affects end users.
  5. The follow-up release. Mainnet protocol upgrades historically get a fast-follow patch release for the bugs that ship together with them. The next v2.12.x or v2.13.0 milestone is the diagnostic timeline for whether v2.12.0 went clean.

Context — Wasmtime adoption among non-EVM L1s

NEAR is the most-trafficked L1 to date to put Wasmtime in the contract path. Stellar's Soroban runtime already runs on Wasmtime; Polkadot's Substrate-derived chains have used Wasmtime for runtime execution for years; Internet Computer ships Wasmtime as well. The interesting precedent NEAR sets is at the application layer rather than the runtime layer — most prior Wasmtime adoption was for chain runtime; NEAR is putting it under user contracts.

The trend across non-EVM L1s in 2026 is toward consolidation on a small set of well-maintained Wasm engines (Wasmtime, Wasmer's runtime, the Polkadot WASM family) rather than bespoke forks. The maintenance and security argument is the dominant driver: a Bytecode Alliance security advisory now translates into a coordinated patch cycle for a meaningful share of non-EVM execution. NEAR's switch puts it in that lane.

Sources:

Related stories