Nearprotocol Nearprotocol sharding: NEAR Scaling Trade-Offs
NEAR Protocol uses Nightshade to distribute state and transaction processing across shards. This increases parallel capacity without requiring every node to handle the entire network's workload. Performance still depends on where work is concentrated and how contracts coordinate across shards; confidential execution has its own private-shard trust model.
State Distribution and Account Placement
NEAR's account model places each account on a single shard and allows it to hold a smart contract. Sharding distributes the network's accounts and processing work across these partitions. The network can expand its overall capacity while each account resides on one shard at a time.
A workload concentrated in one account therefore needs a different performance assessment from activity spread across many accounts. Increasing network-wide capacity does not establish an equivalent increase in the throughput of that one account or contract.
Shard Expansion and Single-Shard Performance
- Dynamic resharding
- Changes the number of shards and redistributes state as demand changes. NEAR describes live splitting and merging of shards without downtime. This expands or reorganizes the network's parallel processing capacity.
- In-memory state
- Addresses database latency within a shard. This improves the performance of an individual shard, addressing a different bottleneck from the number of shards available.
Shard expansion and faster execution within a shard are complementary. Their usefulness depends on whether the limiting work is distributed across partitions or concentrated within one. NEAR describes aggregate capacity as scaling roughly linearly with shard count; that relationship is not a fixed speed multiplier for every application.
Cross-Shard Coordination
Contract interactions require execution semantics as well as capacity. NEAR's account documentation describes smart-contract execution as asynchronous. NEAR: The Definitive Guide, published March 6, 2026, attributes separation of consensus from execution and atomic cross-shard transactions to Nightshade 3.0.
In NEAR's documented promise-based calls, an external call's failure does not automatically revert state changes already made by the calling function. An atomic group requires its participating changes to succeed or fail together. Applications requiring that all-or-nothing outcome need the guarantee to apply to their actual execution path; sharding alone does not establish atomicity for an arbitrary collection of calls.
Cross-shard coordination concerns partitions inside NEAR Protocol. Chain Signatures addresses a separate interoperability task: enabling NEAR accounts and contracts to sign transactions for other blockchains.
Throughput and Completion Time
Throughput counts transactions processed per second. Block time measures the interval between blocks, while finality concerns when a result is settled. A multi-contract operation can require several execution steps, so a block interval does not establish its total completion time.
NEAR reports more than 1,000,000 transactions per second in a scalability benchmark cited in its March 6, 2026 guide. That result describes benchmark capacity. It does not establish everyday transaction demand, the throughput of an individual contract or the completion time of a particular application. Performance comparisons need the workload and shard configuration alongside the rate.
Private Shard Trust Model
NEAR identifies a live private shard as part of Nightshade 3.0. Its blockchain overview specifies seven permissioned validators and a bridge based on trusted execution environments (TEEs) connecting that shard to NEAR mainnet. The private shard supports confidential execution with selective disclosure and underpins Confidential Intents.
Confidential execution therefore carries the private shard's validator and bridge assumptions. Ordinary sharding distributes processing work; it does not by itself make all NEAR transactions confidential.
Sharding Decision Checklist
- For activity concentrated in one account, assess single-shard performance alongside aggregate network capacity.
- For dependent contract calls, establish which changes share an atomic outcome and how the application handles failures between separate asynchronous calls.
- For a throughput comparison, match workload and shard configuration before applying a benchmark rate to an application.
- For confidential execution, include the private shard's seven permissioned validators and TEE-based bridge in the trust assessment.
