Storage nodes keep the full chain history. They receive valid blocks from the network (typically from the path that starts at the mempool) and replicate them for durability and for API consumers who need deep history.
Responsibility
The core job is to persist blocks and the indices that let clients look up headers, transaction ids, and related proofs. A reference design may use distributed consensus between storage operators so all replicas agree on the same head.
Receiving and validating blocks
In practical implementations, new blocks are checked against the expected identifiers and invariants, then written only if they match peer state. If two candidates conflict, consensus rules in the code decide the outcome.
UNiCORN and other witness data
Validation can depend on special random or witness material described inUnicorns. Storage preserves that data so that light clients and auditors can re-check proofs later.
DRUIDs and audit trails
If your product records swap or asset flows with a DRUID-style identifier, storage makes that history available for indexers. Exact storage layout is version-specific; consult the open-source project for the release you target.
HTTP API
Read-oriented routes like block by height, latest block, and entry by hash are documented under Storage API.