NEAR Stateless Validation: Phase 2 Sharding

NEAR stateless validation is the Phase 2 upgrade to NEAR Protocol's Nightshade sharding framework, in which chunk validators no longer maintain a persistent local copy of shard state. Instead, the chunk producer packages all required state data into a state witness, a cryptographic data structure containing every account balance, contract storage entry, and access key needed to execute a specific chunk, and delivers it alongside the chunk to validators. This design decouples validator hardware requirements from network state size, allowing NEAR to scale horizontally by adding more shards without forcing proportional storage cost increases onto its validator set.

This article covers what NEAR Protocol is, how Nightshade sharding works, the precise mechanics of stateless validation including the state witness lifecycle and validator role hierarchy, the benefits for decentralization and scalability, a direct comparison with Ethereum's stateless roadmap, and the implications for validators, stakers, developers, and anyone evaluating NEAR for dApp deployment.

What Is NEAR Protocol?

NEAR Protocol is a layer-1, proof-of-stake blockchain that uses Nightshade sharding (NEAR's proprietary sharding framework) to divide transaction processing across multiple parallel shards, enabling high throughput at near-zero transaction fees. NEAR is designed for deploying decentralized applications at scale, with developer tooling and a consensus architecture built around the assumption that shard count will grow over time.

NEAR's Core Architecture

NEAR operates as a proof-of-stake network in which validators stake NEAR tokens to participate in consensus and are randomly assigned to shards each epoch, a fixed time period roughly equivalent to half a day. NEAR Protocol was co-founded by Illia Polosukhin, co-author of the landmark machine learning paper "Attention Is All You Need," and Alexander Skidanov; the NEAR Foundation oversees ongoing protocol development and ecosystem grants.

The NEAR token serves two primary functions: paying gas fees for transactions and contract execution, and staking as collateral for validators to earn the right to participate in consensus. NEAR smart contracts compile to WebAssembly (WASM), a portable binary format that allows contracts written in Rust or JavaScript to execute within a deterministic runtime. Transaction processing on NEAR follows a chunk-based model, where each shard produces a chunk (a shard-level block processed in parallel) in every block interval, and all chunks are aggregated into a single canonical block.

What Makes NEAR Different from Other L1 Blockchains?

NEAR distinguishes itself from other layer-1 blockchains primarily through its execution sharding model, which divides both state and transaction processing across shards rather than handling all execution on a single chain. Key differentiators include:

• Nightshade execution sharding: NEAR shards both state and computation, not just data availability. This differs from Ethereum's Danksharding approach (EIP-4844), which targets data availability sharding for Layer 2 rollups rather than execution sharding.
• Stateless validation (Phase 2): Chunk validators operate without local state storage, a design choice with direct implications for decentralization and shard scalability, covered in depth in this article.
• WASM smart contract runtime: Contracts run in a WASM sandbox, supporting Rust and JavaScript as primary development languages.
• Human-readable account names: NEAR accounts use named identifiers rather than raw public key hashes.
• Storage staking model: Contracts pay for on-chain storage by staking NEAR tokens, linking storage costs to staked collateral rather than per-byte fees.
• Near-zero transaction fees: NEAR's fee structure is designed to remain accessible even under moderate network load.

Solana scales through single-chain parallelism using its Sealevel runtime; NEAR scales through sharding across independent parallel shards. These are different architectural responses to the same throughput problem. The Ethereum comparison receives dedicated treatment later in this article.

What Is Stateless Validation?

Stateless validation is a blockchain validation model in which validators process transactions without maintaining a persistent local copy of the network's state, receiving all required state data as part of each block or chunk they validate. The word "stateless" refers to the validator's relationship to state storage, not to the blockchain's state itself, which continues to exist and grow. From the validator's perspective, each validation job arrives pre-packaged with everything needed to complete it.

Stateful vs. Stateless Validation: The Key Difference

The difference between stateful and stateless validation comes down to where state data lives during execution: with the validator, or with the work.

In stateful validation, the validator is the state custodian: it owns a copy of the relevant shard's data and consults it during every transaction. In stateless validation, the state data travels with the work. The validator receives exactly what it needs, uses it, and discards it.

Why NEAR Needed Stateless Validation

Under NEAR's original stateful architecture, every chunk validator assigned to a shard had to maintain a full local copy of that shard's state, and as NEAR's shard count grew, so did the storage hardware requirements for every validator in the network. Each new shard added proportional storage obligations for the validators assigned to it. This created a direct coupling between NEAR's scaling ambitions and the hardware cost barrier for validator participation. As the network added shards to increase throughput, it simultaneously raised the cost of becoming a validator, concentrating participation among operators with large storage infrastructure.

Stateless validation breaks this coupling. A chunk validator no longer stores any shard state. It receives exactly the state data needed for each chunk it validates, executes transactions against that data, and discards it. Adding more shards increases network throughput without increasing per-validator storage requirements. This addresses one of the core tensions in the blockchain scalability trilemma: NEAR can add shards to scale throughput without forcing hardware centralization, while the cryptographic integrity of the state witness preserves security.

Understanding Sharding: The Foundation of NEAR's Scalability

NEAR's stateless validation operates within the Nightshade sharding architecture, which divides the network's global state and transaction processing across multiple parallel shards. Understanding this architecture is a prerequisite for the mechanism explanation that follows, because stateless validation is a specific upgrade to how validators participate within Nightshade's structure.

How Nightshade Sharding Works on NEAR

Nightshade is NEAR Protocol's sharding framework, in which the blockchain's global state is divided across multiple shards, each producing a chunk (a shard-level block) in every block interval. Multiple chunks are produced in parallel across all active shards and aggregated into a single canonical block by the block producer for that interval.

The core design principle behind Nightshade is that all shards are treated as components of one logical blockchain, not as separate chains. Each NEAR block contains one chunk per active shard. This means the global ledger remains unified even as transaction processing is distributed. Cross-shard transactions are handled through an asynchronous receipts mechanism that passes messages between shards.

Validators are randomly assigned to shards each epoch, which limits the risk that any single shard's validator set could be selectively attacked or captured. A validator does not permanently own a shard assignment; it rotates with each epoch, distributing both responsibility and risk across the network.

Nightshade's full implementation proceeds across three phases. Phase 1 established basic sharding with chunk processing, where validators maintained full local state copies. Phase 2 is stateless validation, the subject of this article. Phase 3 is dynamic resharding, which gives NEAR the ability to automatically adjust its shard count based on real-time network demand. For complete technical documentation on NEAR's sharding model, see docs.near.org/concepts/advanced/sharding.

How NEAR Stateless Validation Works

NEAR stateless validation works because the state data required to validate a chunk travels with the chunk itself, packaged by the chunk producer as a state witness. Chunk validators receive the chunk and its state witness together, execute all transactions using only the witness data, and never consult a local state database. The result is that the most numerous class of validators in NEAR's network can operate with near-zero state storage requirements.

What Is a State Witness?

A state witness is a cryptographic data structure generated by the chunk producer that contains every piece of state data required to execute the transactions in a specific chunk, including affected account balances, contract storage entries, access keys, and contract code.

Think of a state witness like a case file prepared by a court clerk before a hearing: it contains every document the judge needs to reach a verdict, assembled in advance so the judge does not need to search the court archives mid-proceeding. In NEAR's architecture, the state witness is that case file. The chunk validator receives it alongside the chunk and executes all transactions using only its contents, without ever querying a local state store.

The state witness lifecycle covers five distinct stages:

1. Contents: The state witness includes the account balances, contract storage entries, access keys, and contract code for every account touched by the transactions in the chunk. Only the state that is actually read or written during execution is included; the entire shard state is not packaged.

2. Generation: The chunk producer, the validator role responsible for building the chunk, reads the relevant state entries from its local shard state copy and packages them into the state witness. The chunk producer retains its local state because it must be able to generate witnesses for future chunks.

3. Transmission: The chunk producer broadcasts the chunk and its state witness together to the chunk validators randomly assigned to that shard for the current block interval.

4. Execution: Each chunk validator executes the chunk's transactions using the state witness data exclusively. No local state lookup occurs at any point. After execution, the chunk validator produces an attestation confirming the chunk is valid.

5. Discard: After validation is complete, the chunk validator discards the state witness. The witness is not retained, not stored, and not used to update any local state database.

The state witness structure is formally specified as a NEAR Enhancement Proposal (NEP). For the precise specification and current NEP number, see the NEAR NEPs repository on GitHub. For implementation details in the core protocol client, see the nearcore repository on GitHub.

The Role of Chunk Validators vs. Block Producers

NEAR's validator architecture under stateless validation involves three distinct roles: chunk producers, chunk validators, and block producers, each with different responsibilities and different state storage requirements.

The key structural insight is that chunk validators are the most numerous class in the network, and under stateless validation they no longer need expensive storage hardware. Only chunk producers, a much smaller set, retain the state storage requirement because they must read local state to generate the witness for each chunk. This asymmetry is what allows the validator set to grow without proportionally increasing total storage costs across the network. The decentralization gains are concentrated precisely in the largest validator class.

The Validation Flow Under Stateless Validation

The following steps describe what happens from the moment a new block interval begins to the moment a validated block is finalized on NEAR.

1. Chunk production: The chunk producer assigned to each active shard builds a chunk (a shard-level block) containing the pending transactions to be processed in this block interval.

2. State witness generation: The chunk producer reads the relevant state entries from its local shard state copy and packages them into a state witness, which contains every account balance, contract storage entry, and access key touched by the transactions in the chunk.

3. Transmission to chunk validators: The chunk producer broadcasts the chunk and its state witness to the chunk validators randomly assigned to that shard for this block interval.

4. Stateless execution: Each chunk validator executes the chunk's transactions using only the state witness data, with no local state lookup at any point. After execution, the chunk validator attests to the chunk's validity and discards the state witness.

5. Block assembly: The block producer for this interval collects the attested chunks from all active shards, aggregates them into a single canonical block, and broadcasts it to the network for finalization.

At no point in steps 3 and 4 does a chunk validator require local state storage. The state witness provides all state access needed for the duration of the validation operation.

Benefits of NEAR Stateless Validation

Stateless validation delivers three categories of improvement to NEAR's network: it reduces hardware requirements for the most numerous validator class, it removes the scaling ceiling that stateful validation imposed on shard count and throughput, and it improves the infrastructure conditions for developers building decentralized applications on top of the network.

Lower Hardware Requirements and Greater Decentralization

The most direct consequence of stateless validation for NEAR's validator set is the removal of shard state storage as a hardware requirement for chunk validators. Under stateful validation, storage demands for chunk validators grew with the shard's state size over time, scaling from hundreds of gigabytes toward terabytes as the network processed more transactions and accumulated more state. This created a progressive hardware cost barrier.

Stateless validation eliminates this burden entirely for chunk validators. Storage requirements for this role drop to near-zero for state-related infrastructure, leaving only the compute and network bandwidth requirements for transaction execution and attestation transmission within block time constraints.

The decentralization effect runs directly from this hardware change. Lower storage costs reduce the total operating cost of running a chunk validator, lowering the effective economic barrier to participation. This enables a larger and more geographically diverse validator set, which in turn reduces the risk of validator concentration. A network whose most numerous validators can run on commodity hardware is structurally more resistant to centralization than one where validator eligibility requires significant capital expenditure in storage infrastructure. Current hardware requirement specifications for chunk validators under stateless validation are maintained at docs.near.org/validator; consult that documentation for current figures.

Scalability Without Sacrificing Security

Stateless validation decouples NEAR's shard count from validator hardware requirements, which removes the scaling ceiling that stateful validation imposed on network throughput. Under the previous stateful model, doubling the number of shards would have required every validator assigned to those new shards to provision proportional additional storage, making large shard counts economically restrictive. Stateless validation breaks this relationship: adding shards increases network capacity without increasing per-validator storage obligations.

Network throughput on NEAR scales roughly proportionally with shard count. More active shards mean more chunks processed in parallel per block interval, which increases the number of transactions the network can confirm per second. Stateless validation is the prerequisite for NEAR reaching higher shard counts at scale. The NEAR Foundation's documentation provides current throughput figures as they are updated; for current TPS data tied to specific shard configurations, see docs.near.org.

This addresses the scalability leg of the blockchain scalability trilemma directly. The historical tension between scalability and decentralization on sharded networks arises because adding capacity typically increases validator hardware costs, reducing decentralization. Stateless validation removes the mechanism that caused this tradeoff, allowing NEAR to pursue shard count increases without the corresponding centralization pressure. The scalability model reaches its full expression in Phase 3, dynamic resharding, where NEAR gains the ability to automatically adjust shard count based on real-time network demand without any manual coordination.

What This Means for Developers Building on NEAR

If you are evaluating NEAR as a deployment platform, stateless validation affects your applications at the infrastructure layer, not at the contract layer. There are four practical implications worth understanding before you commit to an architectural decision:

No contract changes required. Stateless validation is a protocol-level change. Your smart contracts require no modification to benefit from it. Contracts already deployed on NEAR automatically operate on the upgraded, more scalable network. There is no migration step, no redeployment requirement, and no API change.

Higher throughput as shard count grows. As NEAR adds more shards enabled by stateless validation, the network's total transaction capacity increases. For your dApp, this means lower congestion probability during periods of high demand and more stable, predictable transaction costs as the network scales.

More resilient infrastructure. A more decentralized validator set, produced by lower hardware barriers to chunk validator participation, reduces the risk of centralization-related network disruptions. Production dApps benefit from a validator network that is harder to disrupt through operator concentration or hardware failures clustered among a small number of well-resourced validators.

Ethereum developer path. NEAR supports Aurora, an EVM-compatible execution environment that allows Ethereum developers to deploy Solidity contracts on NEAR without rewriting them in Rust or JavaScript. Those contracts run on the same underlying network and benefit from the same stateless validation infrastructure improvements.

NEAR Stateless Validation vs. Ethereum's Stateless Roadmap

Developers familiar with Ethereum's stateless client roadmap will find that NEAR's stateless validation addresses the same underlying problem: decoupling validator and node hardware from network state size. The two approaches operate at different architectural levels and through different mechanisms, shaped by the fundamentally different structures of the two networks. They are not competing designs but parallel responses to the hardware burden of blockchain state growth.

Both approaches package the state data a validator or client needs alongside the block or chunk to be validated, so the executing party never needs a local state database. The structural difference is that NEAR's stateless validation applies within a sharded system, targeting the chunk-level validators that form the majority of its network. Ethereum's stateless roadmap targets full nodes on a monolithic execution layer, where the entire chain's state must eventually be addressable through Verkle tree witnesses rather than a local state trie.

On the sharding dimension specifically: NEAR's Nightshade framework is an execution sharding design, dividing both state and computation across shards. Ethereum's Danksharding proposal targets data availability sharding for Layer 2 rollups and is not an execution sharding design. These are architecturally different goals serving different network structures, and direct comparisons between Nightshade and Danksharding require acknowledging that they solve different problems.

Where Does Stateless Validation Fit in NEAR's Roadmap?

Phase 2 of Nightshade is stateless validation. This equivalence is worth stating plainly because the NEAR documentation and community discussions sometimes use "Phase 2" and "stateless validation" interchangeably, and understanding which phase is current tells you the state of the network's scaling architecture.

Nightshade's Three Phases Explained

Nightshade's full implementation proceeds across three distinct phases, each building on the previous one and establishing the preconditions for the next.

Phase 1: Basic Sharding (Complete)

NEAR divided its network state across multiple shards, with each shard processing transactions in parallel. Validators maintained full local copies of their assigned shard's state. Block producers aggregated chunks from all shards into single canonical blocks. Phase 1 established the Nightshade chunk-based architecture but left hardware requirements directly coupled to shard state size, which created the scaling ceiling that Phase 2 addresses.

Phase 2: Stateless Validation (Current Phase)

Chunk validators no longer maintain local shard state. Chunk producers generate state witnesses and deliver them alongside chunks. This decouples chunk validator hardware requirements from shard state size and enables the network to scale to more shards without proportionally increasing validator hardware costs. As of the time of writing, Phase 2 has been activated on NEAR mainnet; for the precise activation date and current network status, consult the NEAR Foundation blog and docs.near.org, as protocol phases are activated progressively and documentation is updated accordingly.

Phase 3: Dynamic Resharding (Planned)

NEAR will gain the ability to automatically increase or decrease its shard count based on real-time network demand, without manual coordination or validator hardware upgrades. Stateless validation is a direct prerequisite for dynamic resharding: without Phase 2 active, adding shards would force proportional storage cost increases onto validators, making automated shard adjustment economically impractical. Phase 3 is the architectural step that enables theoretically unlimited horizontal scaling on NEAR.

Together, the three phases represent NEAR's progression from a sharded blockchain with fixed shard assignments and stateful validators, to a dynamically scalable network that adjusts its own processing capacity without requiring its validator set to grow proportionally in hardware cost.

NEAR Stateless Validation: Implications for Validators and Stakers

For chunk validators, stateless validation removes the largest single hardware cost driver in NEAR's previous architecture: the requirement to maintain a full local copy of shard state. This has direct implications for the economics of validator operation and the practical accessibility of validator participation.

Previously, a chunk validator needed storage capacity proportional to the state size of its assigned shard, and that requirement grew as the network accumulated more accounts, contract data, and transaction history. The operational cost of a chunk validator included not just compute and bandwidth but ongoing storage infrastructure that scaled with network growth.

Chunk validators running under stateless validation no longer provision for state storage. Their hardware requirements shift to compute capacity for transaction execution and network bandwidth for receiving state witnesses and transmitting attestations within block time. This is a fundamentally different cost profile: stable rather than growing, and lower at any given shard count than the previous model.

Stateless validation changes hardware requirements for chunk validators but does not alter the fundamental staking contract mechanics. Validators still stake NEAR tokens above the seat threshold to participate in consensus, and they remain subject to slashing for validator misbehavior. The hardware cost of meeting that participation requirement decreases for chunk validators, which directionally expands the pool of participants who can run a chunk validator node at economically viable operating costs. For current hardware specifications and staking seat thresholds, see docs.near.org/validator.

Note that chunk producers still require full local shard state to generate state witnesses. The hardware reduction applies to chunk validators, the most numerous role in the network. Chunk producers retain their state storage requirements, though they represent a smaller portion of the total validator count.

To become a validator on NEAR, a participant stakes NEAR tokens above the current seat threshold and runs the validator software. For full setup instructions and current hardware specifications updated to reflect stateless validation requirements, consult docs.near.org/validator directly.

Frequently Asked Questions

What is NEAR Protocol used for?

NEAR Protocol is a layer-1 blockchain designed for deploying decentralized applications, including DeFi protocols, NFT platforms, gaming applications, and developer tooling. It uses Nightshade sharding to process transactions across multiple parallel shards, enabling high throughput with near-zero transaction fees. The NEAR token pays gas fees for transaction and contract execution, and validators stake NEAR tokens as collateral to participate in consensus.

How does NEAR Protocol work?

At its core, NEAR operates as a proof-of-stake blockchain divided into multiple shards, each processing transactions in parallel. Each shard produces a chunk (a shard-level block) in every block interval; a block producer aggregates these chunks into a single canonical block. Validators are randomly assigned to shards each epoch and are responsible for executing and attesting to the transactions in their assigned shard's chunk, with stateless validation enabling chunk validators to perform this role without maintaining local shard state.

What is Nightshade sharding?

Nightshade is NEAR Protocol's sharding framework, in which the network's global state and transaction processing are divided across multiple parallel shards. Unlike designs that treat each shard as a separate blockchain, Nightshade treats all shards as components of one logical blockchain, with each block containing one chunk per active shard. Nightshade is implemented across three phases: basic sharding (Phase 1), stateless validation (Phase 2), and dynamic resharding (Phase 3).

What is a state witness in blockchain?

A state witness is a cryptographic data structure containing all the state data required to validate a specific block or chunk, packaged and delivered to validators so they do not need to access a local state database during execution. In NEAR Protocol, the state witness for a chunk includes the account balances, contract storage entries, and access keys touched by the transactions in that chunk. The chunk producer generates the state witness and transmits it alongside the chunk to chunk validators, who execute transactions using the witness data and then discard it after producing their attestation.

How do NEAR validators work?

NEAR validators operate in three distinct roles under stateless validation: chunk producers, chunk validators, and block producers. Chunk producers build chunks (shard-level blocks) and generate state witnesses by reading relevant state from their local shard state copy. Chunk validators receive the chunk and state witness, execute transactions using only the witness data without local state storage, attest to the chunk's validity, and discard the witness. Block producers aggregate attested chunks from all active shards into a single canonical block. Validators stake NEAR tokens above a seat threshold to participate in consensus and are randomly assigned to shards each epoch.

How does stateless validation improve scalability?

Stateless validation improves scalability by decoupling shard count from validator hardware requirements. Under stateful validation, adding more shards required validators assigned to each new shard to maintain proportional local storage, creating a hardware ceiling on how many shards the network could practically support. With stateless validation, chunk validators receive all required state data per chunk as a state witness and discard it after use, so adding shards does not increase per-validator storage requirements, allowing NEAR to scale horizontally by increasing shard count to process more transactions in parallel.

Is NEAR a good blockchain for developers?

NEAR Protocol offers developers WASM-based smart contracts writable in Rust or JavaScript, a storage staking model that ties contract storage costs to staked NEAR tokens, Aurora EVM compatibility for Ethereum developers deploying Solidity contracts, and human-readable account names. Stateless validation is a protocol-level infrastructure improvement that benefits all deployed contracts automatically, without requiring any code changes. As shard count increases, network throughput capacity grows and contracts benefit from reduced congestion. Developers evaluating NEAR for production dApp deployment should consult docs.near.org for current SDK specifications and tooling documentation.

Is NEAR stateless validation live?

Phase 2 of Nightshade, which is stateless validation, has been activated on NEAR mainnet. Protocol phases are rolled out progressively and documentation is updated by the NEAR Foundation as each phase reaches full activation. For the most current deployment status, including the precise activation date and any phase-specific notes, consult the NEAR Foundation blog and the official NEAR Protocol documentation.