Full Node

Overview

A full node receives transactions and blocks from peers, verifies signatures and consensus conditions, executes or checks state transitions, applies fork choice, and maintains the canonical ledger state without trusting an explorer or remote validator. Full does not always mean archival. Many full nodes prune old bodies or historical states after validation while retaining current state and enough data for network operation. Validator, mining, RPC, and archive roles are separate capabilities.

Payment services benefit from their own full nodes but must monitor synchronization, peer diversity, disk integrity, software versions, and network identity. An RPC response is trustworthy only when the underlying node is healthy and canonical. Historical investigations may require archive or indexed data beyond a pruned full node. Infrastructure health must be assessed independently from settlement status. Fast responses do not establish node correctness; synchronization, canonical-chain status, retained history, and active network rules must be verified independently.

Redundant providers should be independent enough that one regional, routing, certificate, or software failure does not disable every path. Operational deployments should define availability, latency percentiles, capacity, authentication, encryption, rate limits, and failure boundaries.

Monitoring should correlate transport and service metrics with node synchronization, chain progress, block propagation, and finality. Timeouts and retries need idempotent behavior, while recovery should rescan canonical history instead of assuming that an unavailable response means no transaction occurred. Operational takeaway: Full nodes independently enforce consensus, while archival depth, RPC service, validation duties, and operational health remain separate concerns. A full node independently validates blockchain transactions and blocks against consensus rules while maintaining enough state and history to follow the network.