A full Monero node now stores well over 200 GB of blockchain data, and the file keeps growing every two minutes as new blocks arrive. Not everyone wants to dedicate that much disk to a currency they just want to verify or use privately. This is where pruning comes in. A pruned node keeps the parts of the chain the network needs from every peer and throws away the parts it does not, and the savings are large. Here is what pruning actually removes, what it costs you, and how to set it up without breaking anything.
What a pruned node deletes
The bulk of a Monero transaction is not the amount being sent. It is the cryptographic proof that the spend is valid: the ring signature data that proves the signer owns one of the referenced outputs without revealing which one. Once a transaction has been in the chain for a while and enough blocks sit on top of it, that proof has done its job. Nobody re-verifies old ring signatures from scratch during normal operation.
Monero’s pruning design exploits exactly that. The chain is divided so that roughly 7/8 of the prunable signature data is deleted, keeping 1/8 evenly spread across the history. The parts that are never pruned include the transaction outputs, the amount commitments, and the key image set, which is the information wallets need in order to scan for incoming payments and detect spent outputs. In practice you get a node that still validates new blocks, still serves wallets, and still relays transactions, at a fraction of the disk usage.
What a pruned node cannot do
There are two real costs, and they matter.
First, a pruned node cannot serve complete historical data to other nodes. If someone tries a full sync from your node, they will not get the whole chain from you. A pruned node is a consumer of network resources more than a provider of historical blocks. If your motivation for running a node includes strengthening the network, a full node gives more.
Second, and this is the one that bites people: restoring an old wallet from scratch against a pruned node can fail. A wallet created years ago, restored from seed with no height hint, needs data that pruning has partially removed. The practical fix is simple. Always set the wallet creation date or restore height when you create the wallet. With a correct height, scanning works against a pruned node. Without one, you may have to fall back to a full node or a trusted remote node just to get the wallet up. If you restore wallets often, or you help other people do it, keep a full node or accept the friction.
Prune during sync, or prune later
You have two ways to get there, and the choice is permanent in one direction.
Sync pruned from the start. Launch monerod with --prune-blockchain. The node syncs the same blocks but writes the pruned version as it goes, so the disk never holds the full history. This is the option to use on a small VPS, a home server with a modest disk, or a Raspberry Pi with a large SD card or external drive. The sync takes the same time as a normal sync; the verification work is identical, only the storage differs.
Prune a full node in place. If you already have a full chain, monerod --prune-blockchain run against the existing database will rewrite it into pruned form. Two warnings. One, this is effectively one-way: going back to a full node means syncing the missing history again from scratch or from a backup. Two, it reads and rewrites the entire database file, so give it hours, not minutes, and make sure you have free space for the operation. Back up data.mdb first if the node matters to you.
Hardware that works in practice
A pruned node has the same CPU profile as a full one. Blocks arrive every two minutes and verification is CPU work, so a weak ARM board will fall behind during initial sync even though the disk stays small. A workable setup for most people is a 4-core mini PC with an SSD, 8 GB of RAM, and a few hundred gigabytes of free disk held in reserve for growth. The SSD matters more than anything else. Syncing on a spinning disk turns a multi-day job into a multi-week one, because the monerod database does small random reads constantly.
For bandwidth, a node that relays transactions to a handful of peers needs a connection that is solid rather than fast. A home line is fine. What you want to avoid is metered bandwidth, since a node that stays connected is pulling new blocks around the clock plus serving data to peers.
Remote node versus pruned node
The privacy argument is the reason to prefer your own pruned node over a public remote node. When your wallet talks to someone else’s node, that operator sees your IP address, the timing of your balance checks, and the transaction data your wallet requests. The encryption on the wire does not help, because you are handing the information to the endpoint itself. A pruned node on hardware you control closes that hole at a disk price most people can pay. It is not perfect privacy by itself, but it removes one of the easiest observation points there is.
Public remote nodes are still useful as a fallback. The official wallets ship with a list of them, and for a small amount held in a hot wallet, that is a reasonable trade. For anything you actually care about, sync your own.
Costs and expectations
The honest budget for a pruned node is a machine you already own plus electricity. A low-power mini PC idles at well under 20 W, which is a few dollars a month. The disk footprint after pruning depends on chain height at the moment you read this, since the chain grows continuously, but the design’s 7/8 reduction on the prunable portion puts it far below the full node figure, and the gap widens as history accumulates.
Expect maintenance to be near zero. Upgrades to monerod a few times a year, an occasional check that the daemon is still connected, and nothing else. If you run the wallet on the same machine, point it at localhost with the RPC settings locked to local access and it will just work.
Who should prune and who should not
Prune if you want a personal, always-on node and disk is your limiting factor. Do not prune if you are deliberately running a node to strengthen the network for others, if you regularly restore old wallets without restore heights, or if you run services that need to hand out arbitrary historical chain data. Those cases want the full chain.
The wider context is covered in our guide to running a Monero node in 2026, including hardware options and setup steps, and the fee mechanics that keep transactions cheap are explained in Monero transaction fees explained. A pruned node changes none of the economics on the fee side; it is purely a storage decision, and for most people running their first node it is the right one.