Chunk-only producers are a specialized validator role in the NEAR Protocol's Nightshade sharding architecture, responsible for producing chunks (shard blocks) within an epoch but not participating in block production or consensus. This operational separation allows validators to contribute to network scalability and earn rewards with a distinct hardware, networking, and monitoring profile compared to full block producers. The role is critical for maintaining shard throughput and ensuring state parts are generated and distributed efficiently across the network.

Chunk-Only Producer Operations
Introduction
Operational profile and monitoring requirements for NEAR validators running chunk-only producer nodes.
Operators running chunk-only producers must manage a unique set of responsibilities: generating state_parts for each chunk they produce, distributing those parts to other validators tracking the same shard, and maintaining low-latency connections to the block producer assigned to their shard. Unlike block producers, chunk-only producers do not run the full consensus loop, which changes their failure modes—missed chunks result in reduced rewards rather than slashing, but chronic underperformance can lead to ejection from the validator set. Monitoring must track chunk production success rate, state part generation latency, and peer connectivity to the assigned block producer.
Teams deploying chunk-only producers should validate their configuration against the specific resource requirements of their assigned shards, as state part generation is CPU and I/O intensive. Chainscore Labs provides configuration reviews and monitoring setup assessments for validators transitioning to or scaling chunk-only operations, helping operators establish performance baselines and alerting thresholds that prevent missed chunks and reward leakage.
Quick Facts
Operational profile, dependencies, and health signals that distinguish chunk-only producers from block producers on NEAR.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
State Part Generation | Chunk-only producers must generate and distribute state parts to block producers; failure to do so degrades network data availability. | Chunk-only validators, block producers | Monitor state part generation success rate and distribution latency; set alerts for failures. |
Hardware Requirements | CPU and RAM demands differ from block producers due to state part computation; storage IOPS requirements increase with shard state growth. | Validator infrastructure teams | Right-size hardware against current shard state size; benchmark before deploying new chunk-only nodes. |
Consensus Participation | Chunk-only producers do not produce blocks but must endorse chunks; missed endorsements reduce validator rewards and can signal node health issues. | Chunk-only validators, staking pool operators | Track chunk endorsement success rate; investigate drops below expected baseline. |
Network Connectivity | State part distribution requires reliable, high-bandwidth connections to block producers; network partitions can cause systemic chunk production failures. | Validator node operators, network engineers | Verify peer connectivity and bandwidth to block producers; test failover paths. |
Monitoring Signals | Standard block-producer dashboards do not capture chunk-only health; missing metrics include state part generation time, distribution success, and endorsement latency. | Monitoring and SRE teams | Deploy chunk-producer-specific Prometheus metrics and Grafana dashboards; set distinct alerting thresholds. |
Upgrade Compatibility | Nearcore releases may alter state part formats or distribution protocols; chunk-only producers must upgrade in sync with block producers to avoid incompatibility. | Node operators, release managers | Validate chunk-producer behavior on testnet before mainnet upgrades; follow the protocol version upgrade playbook. |
Slashing Risk | Persistent failure to produce chunks or distribute state parts can lead to validator slashing or ejection from the validator set. | Validators, staking pool delegators | Implement automated failover or graceful shutdown if chunk production consistently fails; review slashing conditions. |
Configuration Validation | Misconfigured chunk-producer nodes may produce invalid state parts or fail to participate in the correct shards, wasting resources without earning rewards. | DevOps and infrastructure teams | Review config.json settings against current shard assignments; Chainscore offers configuration validation before deployment. |
Technical Context: State Part Generation and Distribution
How chunk-only producers generate and distribute state parts to support Nightshade sharding without producing blocks.
On NEAR Protocol, chunk-only producers are validators that do not participate in block production but are responsible for generating ChunkStateWitness messages and distributing state parts to block producers. This mechanism is a direct consequence of Nightshade sharding, where the network state is partitioned across shards, and no single validator holds the full state. When a block producer needs to execute transactions in a chunk for a shard it does not track, it must receive the relevant state—called a state part—from chunk-only producers that maintain that shard's state.
The operational workload for a chunk-only producer is dominated by state part generation. For each chunk, the producer must construct a Merkle proof over the subset of state required for execution and transmit it to the block producer within a tight time window. This process is CPU- and I/O-intensive, as it requires rapid reads from the node's RocksDB storage and cryptographic proof construction. Operators must monitor near_state_parts_generated_total, near_state_part_generation_time_bucket, and near_chunk_state_witness_compilation_time metrics to ensure generation latency stays within consensus bounds. Failure to deliver state parts on time degrades chunk endorsement success rates and can lead to missed rewards, even if the node remains in consensus.
State part distribution also imposes bandwidth requirements distinct from block propagation. Chunk-only producers must maintain low-latency connections to all block producers, as state parts are sent directly via the network's gossip overlay. Operators should verify that their network.max_peer_count and network.outbound_peer_count configurations allow sufficient connectivity to the validator set. Configuration reviews and pre-deployment validation of chunk producer nodes are critical to avoid under-provisioning that manifests only under full shard load. Chainscore Labs provides readiness assessments for teams deploying chunk-only producers, including metric baseline analysis and configuration audits to ensure state part generation keeps pace with the network.
Affected Actors
Chunk-Only Producers
Chunk-only producers are the most directly affected by any change in this operational profile. They must maintain specialized infrastructure distinct from block producers, with a focus on state part generation and network distribution rather than block production.
Key Actions:
- Validate that CPU, RAM, and storage IOPS meet the higher requirements for state part generation, which is more resource-intensive than block validation.
- Monitor
near_chunk_producer_state_parts_generatedandnear_chunk_producer_state_parts_distributedmetrics to ensure parts are created and gossiped within the strict epoch deadlines. - Set up distinct alerting thresholds for chunk endorsement success rates, as failures here directly impact network shard progress.
- Test configuration changes in a staging environment before deploying to production, as misconfigured chunk producers can stall shard advancement.
Operational Impact Areas
Chunk-only producers face a distinct operational risk profile from block producers. Their core responsibility—generating and distributing state parts—introduces unique failure modes, resource pressures, and monitoring requirements that demand specialized operational controls.
State Part Generation and Distribution
Chunk-only producers must generate state parts for their assigned shards and distribute them to the block producer within strict time windows. Failure to produce or distribute parts on time degrades the block's state witness and can lead to the chunk being excluded from the block. Operators must monitor near_chunk_producer_state_part_generation_duration and near_chunk_producer_state_part_distribution_duration metrics to ensure they stay within protocol deadlines. Under-provisioned storage IOPS or network bandwidth directly causes missed distributions.
Storage I/O and Database Pressure
Generating state parts requires reading large volumes of state data from disk, making chunk-only producers highly sensitive to storage latency and throughput. Unlike block producers, which are primarily CPU-bound, chunk producers can saturate NVMe drives during state part generation. Operators should benchmark RocksDB read performance under realistic shard sizes and monitor near_rocksdb_read_latency metrics. A database compaction coinciding with state part generation can cause cascading distribution failures. Chainscore helps teams validate storage configurations before deployment.
Network Egress and Peer Connectivity
Chunk-only producers push large state parts to the block producer, creating significant egress traffic spikes at the end of each block. Insufficient bandwidth or poor peer connectivity to the block producer can cause parts to arrive late, even if generated on time. Operators should measure egress throughput to block producer peers and set alerts on near_network_peer_egress_bytes for those specific connections. Network partitions between chunk producers and block producers are a silent failure mode not captured by generic peer-count alerts.
Shard Assignment and Resharding Events
Chunk-only producers are assigned to specific shards, and their workload changes when the network undergoes resharding or shard rebalancing. A producer assigned to a new shard must begin tracking that shard's state immediately, which can cause a temporary spike in resource usage and state part generation latency. Operators must monitor shard assignment changes via near_validator_shard_assignment and have playbooks to warm up state caches after reassignment. Missing state part production during the transition epoch risks chunk exclusion.
Memory Pressure and State Caching
Chunk-only producers benefit from aggressive state caching in RAM to reduce disk reads during state part generation. Insufficient memory allocation leads to cache thrashing and elevated generation latency. Operators should tune RocksDB block cache sizes and monitor near_rocksdb_block_cache_hit_ratio specifically for the shards they serve. A drop in cache hit ratio often precedes a spike in state part generation duration. Chainscore provides configuration reviews to optimize memory allocation for chunk producer workloads.
Alerting Thresholds and Health Signals
Generic validator alerting on block production rate is irrelevant for chunk-only producers. Operators need distinct alerting on state part generation success rate, distribution latency to the block producer, and shard state sync health. Critical alerts should fire when near_chunk_producer_state_part_generation_success_rate drops below 100% or distribution latency exceeds the protocol deadline. Chainscore helps teams design chunk-producer-specific monitoring dashboards and runbooks that catch failures before they impact network health.
Risk Matrix
Operational risk areas unique to chunk-only producers, covering state part generation, distribution, and health monitoring signals that differ from block producer profiles.
| Risk Area | Failure Mode | Severity | Affected Actors | Mitigation |
|---|---|---|---|---|
State Part Generation | Chunk producer fails to generate state parts within the allotted time window, causing chunk production misses | High | Chunk-only producers, validators relying on state parts, network throughput | Monitor chunk production success rate and state part generation latency; provision adequate CPU and I/O resources |
State Part Distribution | Generated state parts fail to propagate to other validators due to network issues or peer connectivity problems | High | Chunk-only producers, block producers assembling blocks, network health | Verify peer count and outbound bandwidth; monitor state part distribution success metrics |
Database I/O Saturation | RocksDB compaction or read amplification during state part generation causes I/O bottlenecks and missed production slots | Medium | Chunk-only producers, validators on same hardware | Benchmark storage IOPS under load; separate state database from OS disk; monitor disk latency percentiles |
Memory Pressure | State part generation consumes excessive RAM leading to OOM kills or GC pauses that delay chunk production | Medium | Chunk-only producers, node operators | Set appropriate JVM or Rust memory limits; monitor heap usage and GC pause times; right-size RAM per current hardware benchmarks |
Epoch Transition Timing | Chunk producer fails to adapt to new validator set or shard assignment at epoch boundary, causing missed chunks during transition | High | Chunk-only producers, newly seated validators | Schedule maintenance outside epoch transitions; verify chunk producer reconfiguration completes before next chunk slot |
Sync Lag After Restart | After node restart, chunk producer falls behind and cannot catch up in time to produce chunks for assigned shards | Medium | Chunk-only producers recovering from maintenance or crashes | Use fast sync or snapshot recovery; verify sync status before chunk production slots resume; monitor block and chunk head lag |
Configuration Drift | Chunk producer runs with suboptimal thread count, garbage collection settings, or network config compared to current recommendations | Low | Chunk-only producers, infrastructure teams | Regularly audit config.json against current optimization guide; review after each nearcore release for new tuning parameters |
Operator Readiness Checklist
A targeted checklist for infrastructure teams preparing to deploy or maintain chunk-only producers on NEAR. Each item confirms a critical operational requirement distinct from block producer duties, focusing on state part generation, distribution, and health monitoring signals.
Chunk-only producers must generate and distribute state parts within strict time windows. Validate that your node can consistently produce state parts for its assigned shards without delays.
- What to check: Monitor
near_state_parts_generated_totalandnear_state_part_generation_duration_secondsmetrics. - Why it matters: Slow part generation causes missed chunks and reduces network throughput. If your node cannot keep up, validators on other shards cannot process receipts targeting your shard.
- Readiness signal: State part generation duration consistently under 2 seconds with no spikes above 5 seconds during epoch transitions.
Canonical Resources
Use these sources to verify nearcore behavior, release requirements, sharding semantics, and live network conditions before changing chunk-only producer infrastructure.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Answers to common operational questions for teams running chunk-only producers, covering state part generation, monitoring signals, and configuration differences from block producers.
Chunk-only producers are primarily CPU and I/O bound due to state part generation and distribution, rather than consensus-bound like block producers.
Key differences:
- CPU: Higher sustained load from transaction execution and state part encoding.
- RAM: Large state cache requirements to avoid disk reads during chunk production.
- Storage IOPS: Heavy read/write during state part generation; NVMe storage is strongly recommended.
- Bandwidth: Must distribute state parts to all validators in the shard, requiring reliable and sufficient egress.
Operators should benchmark against current mainnet state size and shard count, as Nightshade phases progressively increase per-shard state size.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


