Node Types
Monolythium nodes can be configured with different pruning strategies depending on their purpose. The pruning setting determines how much historical state a node retains, which directly affects storage requirements, query capabilities, and suitability for different workloads.
Overview
| Type | Pruning Setting | Storage | Sync Time | Use Case |
|---|---|---|---|---|
| Archive | nothing | Grows continuously | Longest (full replay) | Indexers, explorers, snapshots, historical queries |
| Full (Default) | default | Stabilizes after initial growth | Moderate | Validators, RPC endpoints, general operation |
| Pruned | custom | Minimal | Fastest | Relays, sentries, development |
Pruning controls state retention, not block storage. Even a pruned node stores block headers. The distinction is whether the node can answer queries about historical state at arbitrary heights.
Archive Nodes
Archive nodes retain all historical state from genesis. Every state transition at every block height is preserved, enabling queries against any point in the chain's history.
Configuration
In ~/.mono/config/app.toml:
pruning = "nothing"
Using Monarch CLI:
monarch join --network Testnet --archive --moniker my-archive-node
Using monod directly:
monod start --pruning nothing
When You Need an Archive Node
| Requirement | Why Archive |
|---|---|
| Block explorer / Monoscan | Needs state at every height for address balances, contract state |
| Indexer service | Backfill requires replaying historical state |
| Snapshot generation | Snapshots must include complete state |
| Historical balance queries | Only archive nodes can serve eth_getBalance at old block numbers |
| Contract state archaeology | Debugging requires inspecting past contract storage |
| Bootstrap node | New nodes syncing from genesis need a full-history peer |
Storage Characteristics
Archive node storage grows continuously and never stabilizes. The growth rate depends on chain activity:
| Metric | Estimate |
|---|---|
| Growth rate | Varies with transaction volume |
| Initial sync | Full replay from genesis (longest) |
| Disk type | NVMe SSD strongly recommended |
| Filesystem | ext4 or xfs |
Archive nodes require ongoing storage capacity planning. Monitor disk usage and plan for expansion. Running out of disk space on an archive node can corrupt the state database and require a full re-sync.
Testnet Reference
On the Monolythium testnet, seed2 operates as an archive node. This provides:
- A known-good archive peer for bootstrap sync
- Snapshot generation source
- Historical query endpoint for development
Full Nodes (Default)
Full nodes use the default pruning strategy, keeping a window of recent state while discarding older state. This is the recommended configuration for most operators, including validators.
Configuration
In ~/.mono/config/app.toml:
pruning = "default"
Using Monarch CLI:
monarch join --network Testnet --moniker my-full-node
The default pruning strategy retains the most recent 362,880 states (approximately 25 days at ~1 second block times) and runs a pruning pass every 10 blocks.
When to Use a Full Node
| Requirement | Why Full Node |
|---|---|
| Validator operation | Needs recent state for consensus, not full history |
| RPC endpoint (recent data) | Can serve queries for recent blocks |
| General participation | Standard network participant |
| Relay node | Adequate for transaction relay |
Storage Characteristics
Full node storage grows during initial sync but stabilizes once the pruning window is filled. Old state outside the window is garbage-collected.
| Metric | Estimate |
|---|---|
| Stable size | Fraction of archive node size |
| Initial sync | Full replay, then pruning begins |
| Disk type | SSD recommended |
Pruned Nodes
Custom-pruned nodes retain only a minimal window of recent state. This provides the smallest storage footprint at the cost of being unable to serve most historical queries.
Configuration
In ~/.mono/config/app.toml:
pruning = "custom"
pruning-keep-recent = "1000"
pruning-interval = "10"
Using monod directly:
monod start --pruning custom --pruning-keep-recent 1000 --pruning-interval 10
When to Use a Pruned Node
| Requirement | Why Pruned |
|---|---|
| Sentry node | Relays blocks and transactions, no queries needed |
| Development / testing | Fast sync, disposable state |
| Relay-only node | Forwards transactions, does not serve queries |
| Resource-constrained environments | Minimal disk and memory footprint |
Limitations
Pruned nodes cannot:
- Serve
eth_getBalanceoreth_callat historical block heights - Support indexer backfill operations
- Generate snapshots for other nodes
- Act as bootstrap nodes for genesis sync
- Answer Cosmos SDK queries for heights outside the retention window
Configuration Reference
All pruning parameters are set in ~/.mono/config/app.toml:
| Parameter | Values | Default | Description |
|---|---|---|---|
pruning | default, nothing, custom | default | Pruning strategy |
pruning-keep-recent | Integer (states) | 362880 | Number of recent states to keep (only with custom) |
pruning-interval | Integer (blocks) | 10 | How often the pruning routine runs (only with custom) |
min-retain-blocks | Integer (blocks) | 0 | Minimum block height offset to retain (0 = all blocks retained) |
How the Parameters Interact
pruning = "nothing": Ignorespruning-keep-recentandpruning-interval. All state is kept.pruning = "default": Uses built-in defaults (keep 362,880 recent states, prune every 10 blocks). Thepruning-keep-recentandpruning-intervalfields are ignored.pruning = "custom": Uses the values you set forpruning-keep-recentandpruning-interval.
A lower pruning-interval means more frequent cleanup passes, which keeps disk usage tighter but adds minor I/O overhead. A higher interval reduces I/O at the cost of temporarily higher disk usage between passes. The default of 10 is a reasonable balance for most workloads.
Changing Pruning After Sync
Whether you can change pruning settings on an existing node depends on the direction of the change:
| Change | Possible Without Re-sync? | Notes |
|---|---|---|
| Archive to Full/Pruned | Yes | Old state will be pruned on next interval. May take time. |
| Full to Pruned | Yes | Reduces retention window. State outside new window is pruned. |
| Pruned to Full | Yes | Only expands future retention. Past state is already gone. |
| Full/Pruned to Archive | No | Discarded state cannot be recovered. Must re-sync from genesis or restore from an archive snapshot. |
Once state is pruned, it cannot be recovered by changing configuration. If you need archive capabilities on a node that was previously pruned, you must re-sync from genesis using a bootstrap node or restore from an archive-mode snapshot.
Storage Estimates
Approximate storage requirements based on current chain activity. These numbers will grow as the network matures:
| Node Type | Testnet (Estimate) | Mainnet (Estimate) | Growth |
|---|---|---|---|
| Archive | Largest | Largest | Continuous |
| Full (Default) | Moderate | Moderate | Stabilizes |
| Pruned (1000 states) | Smallest | Smallest | Stable (minimal) |
Exact figures depend on transaction volume, contract deployments, and state complexity. Monitor your node's actual disk usage after initial sync to establish baselines for your workload.
Monitoring Disk Usage
# Check data directory size
du -sh ~/.mono/data/
# Check available disk space
df -h ~/.mono/
# Watch growth over time
watch -n 3600 du -sh ~/.mono/data/
Using Monarch CLI:
monarch status
# Includes disk usage in the status output
Monarch CLI
Monarch CLI simplifies node type selection during setup:
| Command | Node Type |
|---|---|
monarch join --network Testnet | Full node (default pruning) |
monarch join --network Testnet --archive | Archive node (pruning = "nothing") |
monarch join --network Testnet --validator | Full node configured for validation |
After initial setup, pruning can be adjusted by editing app.toml directly or using:
monarch config set pruning "custom"
monarch config set pruning-keep-recent "1000"
monarch config set pruning-interval "10"
Decision Guide
I want to...
| Goal | Node Type | Why |
|---|---|---|
| Run a validator | Full (default) | Validators need recent state, not full history |
| Run a public RPC endpoint | Full or Archive | Full for recent queries, archive for historical |
| Run a block explorer backend | Archive | Explorers query state at arbitrary heights |
| Run an indexer | Archive | Backfill requires complete state history |
| Protect my validator (sentry) | Pruned | Sentries relay traffic, no queries needed |
| Develop and test locally | Pruned | Fast sync, minimal resources |
| Generate snapshots | Archive | Snapshots capture full state |
| Relay transactions only | Pruned | Minimal footprint, no query serving |
Related
- Peer Roles - How node roles interact with pruning
- Snapshots - Using snapshots for fast sync
- State Sync - State sync as an alternative to full replay
- Requirements - Hardware requirements per node type