Pruned Node
Pronunciation: PROOND NOHD
Definition
A pruned node validates blockchain history but deletes selected older block or state data after retaining what current operation requires. It can continue enforcing consensus and validating new blocks without keeping a complete archival copy. Some nodes keep headers and recent blocks, while state-pruned systems may retain snapshots or current state but cannot answer arbitrary historical queries.
Overview
Meaning and scope
A pruned node reduces storage by discarding historical data after validating it and advancing the current chain state. It can continue enforcing consensus and validating new blocks without keeping a complete archival copy. Some nodes keep headers and recent blocks, while state-pruned systems may retain snapshots or current state but cannot answer arbitrary historical queries.
How it works
Reindexing can require downloading and validating history again. Operators should document pruning mode, retained window, backup strategy, and RPC limitations. A pruned full node can provide stronger consensus assurance than a remote explorer, but it is not an archive node . Applications needing old receipts, traces, proofs, or address history must use suitable archival infrastructure and reconcile provider results. Connection success measures service availability, not whether the underlying node follows the canonical chain or can provide the required history. Practical implication: Pruned nodes preserve current validation while sacrificing historical query depth, so archival requirements need separate infrastructure.
Operational checks and limits
A pruned node validates blockchain history but deletes selected older block or state data after retaining what current operation requires. A pruned node can validate the chain while deleting older block data after it is no longer required locally. Historical query availability is therefore different from validation capability.
Practical example
A merchant runs a pruned Bitcoin node for current validation and uses a separate archive or index for older customer-payment investigations.
Distinctions
Pruned nodes are not equivalent to light clients: pruning reduces retained history after verification, whereas light verification relies on a different evidence model.
How to evaluate it
Node roles differ in the information they retain and the checks they perform; an application relying on Pruned Node should know whether its provider verifies chain rules independently, supplies historical data, or merely forwards another system’s response. When evaluating Pruned Node, to troubleshoot a missing deposit, compare chain inclusion, indexing progress, and application notification separately; a delayed balance display does not always mean an absent transaction. Related concepts: node; full node; node.
Example
A merchant runs a pruned Bitcoin node for current validation and uses a separate archive or index for older customer-payment investigations.
Comparison
Pruned nodes are not equivalent to light clients: pruning reduces retained history after verification, whereas light verification relies on a different evidence model.
Key Takeaway
Plan archival needs separately from live validation.
Sources
- Ethereum Documentation: Networking Layer — Ethereum Foundation (2026-07-30)
- Bitcoin Developer Guide: P2P Network — Bitcoin.org (2026-07-30)