NEAR's Dynamic Resharding: How the Network Scales Itself
NEAR's v2.13 upgrade ships shards that split automatically when they fill up — no governance vote, no coordinator. Here's how it works and what it changes.
Every sharded blockchain eventually hits the same ceiling: the shard count is fixed at protocol launch, and changing it requires a full network upgrade — weeks of coordination, a governance vote, a staged rollout. When actual demand outpaces the original shard count, the network slows down. Developers plan around it, protocols adjust, and users pay more in fees until a new upgrade ships. NEAR Protocol's v2.13 upgrade, shipping in June 2026, removes that ceiling. Shards now split automatically when they fill up, with no human intervention required. It is the first major Layer 1 to deploy autonomous resharding, and NEAR shipped post-quantum signatures in the same upgrade.
The Coordination Problem Sharding Hasn't Solved Until Now
Sharding divides a blockchain's state and transaction load across multiple parallel chains called shards. Each shard processes a subset of transactions independently, so adding shards in principle multiplies network throughput. The structural problem is that "adding shards" in practice has always meant stopping and making a deliberate governance decision.
NEAR's existing sharding system, Nightshade, launched with four shards. The original architecture required that any change to the shard count — whether splitting a congested shard or adding new capacity — go through a full protocol upgrade. That involves developer team coordination, a validator governance vote, testnet deployment, and a staged mainnet rollout. The process takes weeks at minimum.
Static shard counts create predictable failure modes. DeFi activity tends to cluster: trading, lending, and bridging volume concentrates on specific protocols, which means specific shards. When a popular DeFi protocol lives on shard 2, shard 2 congests while shards 0, 1, and 3 sit underutilized. The bottleneck is not total network capacity — it is the inability to rebalance capacity without a governance event.
This is the version of the scaling problem that every Ethereum rollup is also trying to solve, just at a different layer. Ethereum L2s essentially externalize the shard management problem by letting individual rollup teams add sequencer capacity, but that introduces fragmentation and cross-rollup friction of its own. Solana's Alpenglow upgrade addressed the speed and block space problem through consensus changes, not sharding.
How Dynamic Resharding Works
NEAR v2.13 introduces automated shard management. Instead of a fixed shard count that requires a governance decision to change, the protocol monitors each shard's state size continuously.
When a shard crosses a predetermined capacity threshold, the protocol splits it deterministically — no human intervention, no vote, no coordinator. State witnesses validate the split. The resulting child shards resume operation without any break in service. When demand drops and shards become underutilized, the protocol can merge them to reduce validator overhead.
The process works as follows:
| Step | Old behavior | v2.13 behavior |
|---|---|---|
| Shard hits capacity | Fee spike; wait for governance | Protocol detects threshold breach |
| Coordination required | Developer proposal + validator vote | None — deterministic split |
| Rollout time | Weeks (protocol upgrade cycle) | Real-time |
| Validator overhead | Fixed regardless of load | Adjusts with shard count |
The theoretical ceiling under dynamic resharding scales with hardware rather than with a fixed parameter. NEAR's long-term projections describe 70+ active shards, which puts throughput into the range of major payment networks' peak capacity. Whether that ceiling is ever needed depends on demand — what v2.13 changes is that the network no longer needs to pre-plan for it.
One thing that doesn't change: state witnesses remain the validation mechanism. Dynamic resharding works within NEAR's existing Nightshade architecture rather than replacing it. Validators still need to download state witnesses for the shards they track, and the witness data per shard grows as those shards are split. The upgrade includes optimization work on witness size and propagation to keep validator overhead manageable as shard count increases.
NEAR Intents, a multichain transaction framework that lets users specify a desired outcome while external parties compete to fill the order most efficiently, was also announced as part of the same protocol roadmap. Intents operate across NEAR's shard boundaries, which makes dynamic resharding a meaningful infrastructure prerequisite — an Intents system that can span an arbitrary number of self-scaling shards scales differently than one capped at four.
Post-Quantum Signatures: The Other Half of v2.13
The same upgrade adds post-quantum cryptographic signatures to NEAR's signing infrastructure. NEAR chose FIPS-204, known as ML-DSA (formerly CRYSTALS-Dilithium), a lattice-based digital signature algorithm that NIST standardized in August 2024 as part of its first batch of post-quantum cryptography standards.
The threat model is worth stating plainly: no quantum computer capable of breaking current elliptic curve signatures (ECDSA or Ed25519) exists today. The upgrade is forward defense — cryptographic agility before the threat materializes rather than after. Most blockchain protocols are running on signing algorithms that would be broken by a sufficiently large quantum computer; the question is when that computer exists, not whether ECDSA is vulnerable in principle.
ML-DSA signature sizes are substantially larger than Ed25519 signatures. That carries a small on-chain footprint cost per transaction. The tradeoff is that the signing infrastructure is hardened against a class of attacks that will eventually arrive, rather than requiring an emergency protocol upgrade when that inflection point comes.
No other major Layer 1 has shipped both autonomous resharding and post-quantum signatures in a single upgrade. Ethereum's post-quantum roadmap exists but is years out from execution. Solana has not announced a post-quantum signing upgrade. NEAR is alone in having shipped both in production.
What Changes for Users, Protocols, and What to Watch
The most direct effect of dynamic resharding is that fee spikes caused by shard congestion become structurally less likely. When a shard fills up, it splits rather than congesting. Users transacting on a protocol during a high-traffic event — a token launch, a high-volume trading session on a NEAR-based DEX — are less likely to encounter elevated fees caused by the shard they happen to land on being overloaded.
DeFi protocols on NEAR no longer need to model a fixed shard count when planning for growth. A protocol that expects to handle ten times its current transaction volume doesn't need to secure a governance commitment to expand shard capacity before that volume arrives. The network adapts.
For users moving assets across chains, NEAR Intents is the more immediately visible product — it is the user-facing interface through which the underlying shard infrastructure becomes relevant. An Intents-based cross-chain swap doesn't expose shard mechanics to the user, but the reliability and cost of that swap depends on whether the underlying NEAR network can absorb demand without congesting.
v2.13 is scheduled for June 2026. The signals worth tracking after launch:
- Shard count at 30 and 90 days post-upgrade. If traffic remains at current levels, the shard count will hold near its current value. Meaningful growth in NEAR-based DeFi activity or NEAR Intents usage should trigger observable shard splits — the first real-world test of autonomous resharding under production load.
- State witness sizes. The witness optimization work in v2.13 aims to keep per-validator overhead manageable as shards multiply. If witness sizes grow faster than projected, it creates pressure on validator hardware requirements and could slow shard-count expansion in practice.
- Protocol adoption of ML-DSA. Post-quantum signatures are available at the protocol level after v2.13, but individual wallets and applications need to integrate the new signing scheme for users to benefit. Wallet support timelines vary; the upgrade is a prerequisite, not an immediate rollout to all users.
The comparison to draw here is architecture, not speed. Ethereum's Glamsterdam upgrade targets gas reduction and parallel execution through EIP-level changes. Solana's Alpenglow addressed finality and block space by replacing consensus. NEAR v2.13 addresses capacity planning by making the shard count itself a runtime variable. Each approach reflects a different theory of where the scaling bottleneck actually lives.