A Monero pruned node is a node that throws away part of the old transaction data to save disk space, while still checking the chain and working with your wallet. The Monero project's README listed about 95 GB for a pruned blockchain versus about 280 GB for a full one in June 2026. For most people who run a node for their own wallet, pruned is the sensible choice. This guide explains what is kept, what is lost and how to switch.
- Pruning drops most of the old ring signature data and saves about two thirds of the disk space.
- A pruned node works with wallets the same way a full node does.
- Turn pruning on from the first sync. Adding it later does not shrink the file straight away.
- A pruned node helps new nodes sync less than a full node does, up to one eighth as much, but still relays blocks and transactions.
- There is no official un-prune. Going back to a full node means syncing again.
The short answer
If you want a node for your own wallet and do not need to serve the whole history to others, run it pruned. It is the same job in a third of the space. If you have plenty of disk and want to be a full resource for the network, run a full node. You can do the full setup in how to run a Monero node, which covers downloads, verification and ports. This page is about the pruned part.
What pruning removes and keeps
Monero transactions carry a lot of data that proves they are valid, mostly ring signature material (see ring signatures). A node needs that data to check a transaction when it first arrives. Years later, it is mostly useful for one thing: helping a brand new node sync from scratch.
Pruning takes advantage of that. According to the Monero announcement of pruning, a pruned node keeps a random 1/8 of the prunable transaction data, and that kept share is what it uses to help other nodes. The official glossary describes it as saving 2/3 of storage space while keeping the full transaction history.
- Kept: block headers and the non-prunable data of every transaction, so the chain history is intact, plus a random one-eighth stripe of the prunable data.
- Dropped: the other seven eighths of the prunable data.
- Why it is safe: the network as a whole still holds every stripe, because different nodes keep different ones.
Storage numbers
These figures come from the README in the monero-project repository, dated June 2026:
| Node type | Approx. disk use |
|---|---|
| Full | About 280 GB |
| Pruned | About 95 GB |
That is roughly a third, which matches the two-thirds saving in the docs. For comparison, the 2019 announcement described a chain of about 65 GB and a pruned node of about 25 GB, so the chain has grown a lot. Plan for growth, use an SSD, and check the README for the latest numbers. The first sync also needs working space beyond the final size.
About 95 GB pruned vs about 280 GB full, per the Monero README in June 2026. Leave headroom, because both keep growing.
Can a pruned node serve wallets
Yes. The monerod reference says pruning saves 2/3 of disk space "w/o degrading functionality," and the README says a pruned node can only serve part of the historical chain data to other peers but otherwise works the same as a full node. Your wallet uses the same connection, the same port and the same steps. It does not notice the difference.
Pruning saves 2/3 of disk space w/o degrading functionality.
Monero monerod reference
This also means a pruned node is a good base for a private setup. Pointing a wallet at your own node avoids telling a third party which payments it is looking for, the main drawback of a remote node. If you do not want to run any node, a light wallet is a different trade-off.
The flags: prune and sync-pruned-blocks
There are two options to know, both described in the monerod reference.
--prune-blockchain
monerod --prune-blockchainThe reference says that for maximum effect, it should be used already on the first sync. If you add it later, past data is only pruned logically, without shrinking the file size, and the gain is delayed. It also states the trade-off: you contribute less to the peer to peer network in helping new nodes sync, up to 1/8 of normal contribution, while still being useful for relaying new transactions and blocks.
--sync-pruned-blocks
monerod --prune-blockchain --sync-pruned-blocksThe reference describes this as accepting pruned blocks instead of pruning yourself, which should save network transfer when used with --prune-blockchain. As we read it, this means you take pruned blocks from peers rather than downloading everything and pruning it locally. That saves bandwidth. If you prefer to process the full data yourself before it is discarded, leave it off. Check the reference for your version before relying on it.
When to choose a full node
- You have the space and want to help. A full node can serve the whole history to nodes that are syncing.
- You run infrastructure for others. Block explorers, payment services and public nodes often want complete data.
- You want maximum independence. A full node keeps everything locally, with no reliance on other nodes' stripes for old data.
- Disk is not the limit. If you already own a large SSD, the extra 185 GB or so may cost you nothing.
If instead you are on a small laptop, a mini PC or a Raspberry Pi, the pruned node is the practical option, as the node guide says.
How to convert
Starting new
Start monerod with --prune-blockchain on the first sync. Nothing else is needed.
Converting an existing full node
The monerod reference says that if you already have an unpruned blockchain, see the monero-blockchain-prune tool. The README adds that pruning an existing chain temporarily needs enough disk space for both the full and pruned blockchains. So you need free space at least equal to the pruned result while it runs. Stop the daemon first, and read the tool's help text for the exact options before you run it.
Going back to full
The official documentation describes no reverse tool, so we treat pruning as one-way. To get a full node again, delete the pruned database and sync from the start without --prune-blockchain. That takes hours or days, so choose carefully. See the node guide for sync times and the syncing guide if your wallet gets stuck meanwhile.
Which one to pick
| You are | Pick |
|---|---|
| Running a node for your own wallet | Pruned |
| On a Pi, mini PC or small disk | Pruned |
| Wanting to give new nodes a full history to sync from | Full |
| Running a service that needs complete data | Full |
Whichever you choose, running your own node beats borrowing one. Get the basics in what a Monero node is, then follow the setup guide.
Frequently asked questions
What is a Monero pruned node?
A node that drops about 7/8 of the prunable transaction data (mostly ring signature material) and keeps the rest. The Monero documentation says it saves about two thirds of disk space without degrading wallet functionality, while keeping the full transaction history.
How big is a pruned Monero blockchain?
The Monero project's README gave about 95 GB for a pruned blockchain and about 280 GB for the full one as of June 2026. Both numbers grow over time, so check the README before you buy a drive.
How do I prune the Monero blockchain?
On a new node, start monerod with the --prune-blockchain option from the first sync. On an existing full node, use the monero-blockchain-prune tool, which needs enough disk space for both the full and pruned copies while it works.
Can a pruned node serve wallets?
Yes. The Monero documentation says pruning does not degrade functionality, and a wallet connects to a pruned node the same way. The node simply cannot serve all historical data to other peers.
Does a pruned node still verify transactions?
A pruned node checks new blocks and transactions like a full node, per the Monero README, which says it otherwise works the same. Pruning removes stored data for old transactions, not the validation of the chain.
What does --sync-pruned-blocks do?
The monerod reference describes it as accepting pruned blocks instead of pruning yourself, which should save network transfer when used with --prune-blockchain. If you want to check everything yourself, you may prefer to leave it off.
Can I turn a pruned node back into a full node?
The official documentation describes no way to un-prune. To get a full node again, you would delete the pruned data and sync again from the beginning without the prune option.
Should I run a full node instead?
Choose a full node if you have the disk space and want to help new nodes sync by serving the entire history. A pruned node contributes less to that (up to one eighth, per the docs) but still relays blocks and transactions.