Skip to content
Blockchain Posts

protocol

NEAR ships v2.13 to mainnet: FIPS-204 ML-DSA signatures and dynamic resharding go live

NEAR activated protocol upgrade 2.13 on July 20, adding NIST-approved ML-DSA-65 as a third signature scheme and automatic shard splitting at epoch boundaries.

by 6 min read
protocolnearpost-quantumshardinginfrastructure

NEAR Protocol activated network upgrade 2.13 on mainnet on July 20, 2026, moving the shared state to protocol version 86. The release stabilises FIPS-204 (ML-DSA-65) as a third transaction-signature and access-key scheme alongside ed25519 and secp256k1, and it ships dynamic resharding — automatic shard splits at epoch boundaries when a shard crosses a state-size threshold, with no protocol upgrade required. Primary reference is the nearcore 2.13.0 release notes. Independent coverage from The Crypto Times, PRNewswire and Coinpaprika. Exchange-side confirmation: Bybit's v2.13.0 upgrade support notice.

What shipped

Voting for protocol version 86 opened at 00:00 UTC on Monday, July 20. NEAR's stateless-validation model means the fork lands on the epoch boundary once a supermajority of stake runs the new binary; no coordinated halt, no downtime for applications. Bybit paused NEAR deposits and withdrawals around the switchover as a routine precaution.

Three items in the release matter for anyone building on NEAR or holding validated stake:

  • ML-DSA-65 as a first-class access-key scheme (PR #15731). NEAR now supports the NIST-standardised FIPS 204 module-lattice signature as a third signing method, next to Ed25519 and secp256k1. It is available immediately from the NEAR CLI as an account-level key rotation.
  • Dynamic resharding (PR #15823). Shards split automatically at epoch boundaries when the runtime state exceeds a defined size; the split is validated by state witnesses in roughly 1.5 epochs and requires no protocol version bump or validator vote.
  • Gas keys (NEP-611) and account-creation cost adjustment (NEP-642). A new access-key type carries pre-funded balances with up to 1,024 independent nonce sequences; account creation cost rises from ~0.0008 to ~0.007 NEAR, with total transaction cost held roughly constant by gas-refund changes.

Mechanism — how ML-DSA fits under the account model

NEAR account keys have always been public-key-first: an account can hold multiple keys and rotate them independently. The 2.13 upgrade adds a third key type without touching the account model itself. Under the hood, the change is smaller than the marketing implies:

  • On-trie storage. Full ML-DSA-65 public keys are 1,952 bytes. Instead of storing them raw on the trie, NEAR stores a 32-byte SHA3-256 hash of the key. The full key is supplied at verification time.
  • Verification cost. ML-DSA verification adds a 100 Ggas charge per signature — visibly heavier than Ed25519, but sized so that dApps can budget for it without breaking existing gas estimates.
  • Opt-in, not migration. Existing accounts keep whatever key type they already use. Builders who want the post-quantum guarantee call add_key with the new key type — the same code path used to rotate to a new Ed25519 key today.

Dynamic resharding is the second load-bearing change. Every prior split on NEAR required a protocol upgrade: a hard-coded shard-layout change, a validator upgrade window, and a full epoch of state sync. 2.13 replaces the coordination step with a runtime rule. When a shard's state exceeds the threshold, it splits at the next epoch boundary; state witnesses prove the split; downstream nodes reconstruct the new shards from the witnessed state rather than re-syncing from genesis.

Numbers block

- Release                  : nearcore 2.13.0
- Protocol version         : 84 → 86
- Mainnet voting start     : 2026-07-20 00:00 UTC
- Post-quantum scheme      : FIPS-204 ML-DSA-65 (NIST-standardised)
- Prior schemes retained   : Ed25519, secp256k1
- Public key size          : 1,952 bytes; stored on-trie as 32-byte SHA3-256
- Verification cost        : +100 Ggas per ML-DSA signature
- Dynamic resharding       : automatic split at epoch boundary above state-
                             size threshold, ~1.5 epochs to complete, no
                             protocol upgrade or validator vote required
- Gas keys (NEP-611)       : new access-key type, up to 1,024 nonce sequences
- Account creation cost    : ~0.0008 NEAR → ~0.007 NEAR (NEP-642)
- Key PRs                  : #15731 (ML-DSA), #15823 (resharding),
                             #15183 (gas keys), #15476 (continuous epoch sync)
- Primary source           : github.com/near/nearcore/releases/tag/2.13.0

Impact

The ML-DSA rollout puts NEAR in a very small club: layer-1 chains with a NIST-approved post-quantum signature scheme available on live mainnet as a first-class transaction path. Stellar shipped ML-DSA support for Soroban earlier this year but as a smart-contract primitive; NEAR is offering it as an account-level access key — the same layer at which Ed25519 sits today. That matters because migration off Ed25519 in a hypothetical post-quantum emergency is an account-model operation, not a contract deployment.

Dynamic resharding is the more consequential change for the immediate roadmap. NEAR has run six shards since Nightshade 2.0; every shard added meant coordinated validator work. Removing that friction is the piece missing between NEAR's advertised horizontal scalability and what teams could actually plan against. If the runtime threshold logic behaves as designed, dApps hitting throughput ceilings this year no longer need a chain-wide upgrade cycle to absorb growth.

Gas keys are the third-order change that ships quietly and matters most for onboarding. Applications can now provision an access key with a pre-funded NEAR balance and up to 1,024 independent nonce sequences, which is the primitive teams need to sponsor user gas without running a full meta-transaction relay.

Action checklist

  1. Validators — run 2.13.0 before the epoch boundary that includes block-time crossing of the vote threshold; without it, your node forks off and misses the epoch's rewards. Bybit and other exchanges already coordinated deposit/withdrawal pauses for the switch.
  2. dApp builders — audit any code path that hardcodes signature-scheme enumerations. Wallet SDKs that parse access_key.permission need to accept the ML-DSA key type. Gas-cost estimators need to account for the +100 Ggas ML-DSA verification adder if you plan to sign with the new scheme.
  3. Wallet teams — the NEAR CLI supports ML-DSA key rotation today; user-facing wallets should ship the option before they market it as "post-quantum," since keying an account off ML-DSA while other keys remain Ed25519 does not eliminate the quantum attack surface.
  4. Infrastructure teams — dynamic resharding changes state-sync assumptions on non-validator nodes. Indexers, archive nodes and RPC providers should confirm their state-witness handling matches the runtime split logic before the first automatic split fires in production.

Context — a slow drift from "eventual PQ" to "PQ shipped"

Post-quantum signature schemes at the layer-1 base layer have moved from conference-talk material to shipping code over the last twelve months. Stellar activated ML-DSA in Soroban with its quantum-preparedness plan; Cardano and Algorand have research tracks in flight; Ethereum's post-quantum work still lives at the L1 research level with no timeline. NEAR's decision to ship ML-DSA as an access-key type rather than a contract primitive is the aggressive read of NIST's FIPS 204 finalisation — it treats the scheme as production-ready, not experimental.

The dynamic-resharding piece is a different lineage. NEAR's Nightshade design has assumed automatic resharding since the whitepaper; every prior mainnet expansion still required a coordinated protocol upgrade. Landing the runtime-driven version is the culmination of the "stateless validation → chunk validators → dynamic resharding" arc the Near One team has been pushing quarter-by-quarter since 2024.

The near-term reads: whether the first production shard split fires without incident, how many wallet SDKs actually ship ML-DSA key rotation UIs in the next 30 days, and whether Ethereum's L1 research group moves off "watch and learn" once a peer chain has ML-DSA live in production.

Sources:

Related stories