Download the official Monero GUI wallet, create a new wallet, and the first thing it does is sync the entire blockchain from October 2014 onward. On an average home connection that means downloading roughly 250 GB of blocks and verifying every signature along the way. The wallet sits at a progress bar crawling through 2015 while the disk light stays solid. This is normal, it is not a bug, and there is exactly one shortcut worth taking. Here is what is actually happening and what helps.
What the wallet is really doing
Monero wallets do not trust anyone else’s copy of the ledger. Before the wallet shows a balance it downloads every block and verifies each one: the ring signatures, the range proofs that prove amounts are positive without revealing them, and the miner signatures. A full node checks somewhere in the region of 40 million transactions. That verification is CPU-bound, not network-bound. If your connection can pull 100 Mbps but the wallet still crawls, it is because signature verification, not download speed, is the bottleneck.
This is also why the sync speed changes as it goes. Early blocks are tiny and verify in seconds per thousand. Blocks from 2021 onward carry ten to thirty times more transactions, use bigger ring sizes, and since the FCMP++ work landed, heavier proofs. A sync that estimated “2 days remaining” at block 1.5 million can honestly take longer, because the estimate assumes the average block weight so far, not the blocks still ahead.
The one setting that matters: pruning
Run the daemon or GUI with --prune-blockchain and the node keeps about one eighth of the blockchain data needed to verify new blocks, while still scanning every input for your wallet’s outputs. Disk usage drops from roughly 250 GB to about 45 GB. The catch: a pruned node can only serve pruned data to peers, so you are not contributing full blocks to the network, and you cannot export the raw chain from it. For a personal spend wallet, pruning is almost always the right trade. Create the wallet directory fresh with pruning enabled from block zero, because enabling pruning on an existing synced node does not reclaim much space.
Things people try that do not help
Adding --max-connections-per-ip tweaks, VPN “faster routes,” or downloading the blockchain from a random torrent found on a forum: skip all three. The last one is actively dangerous, since a tampered bootstrap file with a corrupted chain is wasted days at best. If you want to skip verification of old history, the official raw blockchain files from getmonero.org are hash-published and can be imported, but note the import itself still takes many hours of disk I/O and you are trusting that hash over your own verification.
What does help: an SSD rather than a spinning disk, since random reads during verification punish mechanical drives badly. More CPU cores help, because verification is parallelized per block batch. And leaving the daemon running overnight matters more than any flag, since a stopped node redoes peer discovery each start.
Sync speed numbers you can expect
For calibration, not a promise: a modern six-core desktop with the chain on an NVMe drive and a 200 Mbps line typically finishes a pruned sync in 12 to 24 hours, with the last third of the chain taking about as long as the first two thirds combined. A Raspberry Pi 5 with a good USB SSD takes roughly a week for the same job, mostly because the ARM cores grind through batch verification slower. An old laptop with a 5400 rpm drive can stretch past two weeks and occasionally loses more time to disk stalls than it gains from a fast connection. If your numbers land far outside these bands, the usual culprits are peer starvation, where the daemon only holds two or three peers behind a restrictive router, or an antivirus product intercepting every file write. Opening outbound port 18080 on the router so other nodes can connect to you improves peer count more than any bandwidth upgrade.
Verifying you synced the real chain
Before moving real funds, check the daemon’s reported block height against a public block explorer and, more rigorously, against the checkpoint hashes published in the official Monero source. A node that synced the genuine chain reports the same top block hash as every other honest node on the network. If the height matches but the hash does not, stop and re-sync from scratch from the official download, because a mismatched chain means something fed you false blocks, which only happens with a hostile peer set or a tampered bootstrap file. It is rare, but it is exactly the failure a self-verified node exists to prevent, and the one thing a remote node can never prove to you.
Remote nodes: the trade you are making
The GUI offers a remote node list, and using one skips the sync entirely. Your private spend key never leaves your machine, so funds are not directly at risk. But the remote node operator learns your IP address, the approximate timing of your transactions, and can withhold blocks to probe which outputs you are scanning for. Over a long relationship that metadata erodes exactly the privacy Monero exists to provide. Treat public remote nodes as fine for checking a balance, weak for spending privately. If privacy is the reason you hold XMR at all, run your own node, even a pruned one on a spare laptop, and point the wallet at localhost.
After the first sync
Once the chain is current, keeping it there costs almost nothing: leave the daemon running and it processes about two minutes of new blocks per day. The painful sync is a one-time cost. Wallet restoration from seed on an already-synced node completes in under an hour even after years away, which is covered in detail in our seed restore guide. If you want the fuller picture of what a node costs to run month to month, hardware included, see running your own Monero node.
The short version: enable pruning, put the chain on an SSD, start it before dinner, and check back the next day. Anyone promising a private Monero sync in twenty minutes is selling you someone else’s node.