A Monero wallet needs a node. The wallet holds your keys and produces signatures, but it doesn't store the blockchain. It asks a node for the blocks and transactions it needs to scan, and that request pattern tells the node operator a few things even though Monero amounts and addresses are encrypted on chain by default. Remote nodes are a real convenience and a real trade-off, and the decision is worth making on facts rather than on the word "privacy" alone.
What a remote node actually sees
The big one is your IP address, and the timing of your requests. Every time your wallet syncs, it connects to the node, asks for blocks since its last scan, and then asks for the specific transactions that match your key images and view key. The node can't see which transactions are yours in the sense of reading addresses, because there are no plaintext addresses to read: a transaction's destination is a one-time public key and the amount is encrypted with a blinded value. What the node sees is that your IP requested a specific set of key images, at a specific time, in a specific order.
That matters more than it sounds. A node operator collecting this data can build a profile: this IP runs a Monero wallet, syncs every few days, and is currently scanning blocks from this date range. Combined with anything else that IP address does, it's a meaningful piece of a larger picture. It isn't enough on its own to link you to a specific transaction, and no remote-node attack has demonstrated that link, but "not proven possible" is a weaker statement than "impossible", and Monero's threat model deserves honest language.
What the node can't do: spend your funds. Private spend keys never leave the wallet, so a remote node can't sign anything. This is the hard line in the design, and it holds no matter which node you use.
The lying node problem
there's a second risk that gets less attention than privacy: correctness. A node can withhold transactions. If it does, your wallet scans an incomplete set of blocks and shows you a balance that's wrong, or misses an incoming transfer. This doesn't let anyone steal funds, but it can make you act on bad information, and a vendor or an exchange relying on a hostile node can be manipulated into believing a payment arrived or didn't.
Monero's mitigations here are structural. The wallet only trusts outputs that are confirmed on chain, and a node withholding data can't forge a confirmation. The failure mode is omission, not fabrication. For most users this is a nuisance risk rather than a catastrophic one, but if you're running a business on Monero, a wrong displayed balance has real consequences.
Choosing a remote node sensibly
If a remote node is what you want, choose one deliberately. The open node lists, monero.fail being the best known, show each node's height, uptime, and whether it supports pruned history. Pick nodes that are current, meaning their height matches the network, and prefer ones that have been listed a long time. Tor and I2P nodes exist and hide your IP from the node operator, at the cost of slower sync and a Tor exit correlation with whoever runs the Tor side of the connection.
Avoid the default behavior of connecting to any random node. Wallets and third-party apps sometimes ship with a built-in list, and the operator of a popular wallet's default node learns the wallet's user base patterns by default.
Running your own node
The alternative is a node on your own hardware. A full archival node takes roughly 200 GB and grows, and that number scares people off. The honest engineering answer is that you almost never need an archival node. A pruned node is about 50 to 55 GB, syncs faster, and serves a wallet perfectly well. Pruning removes old outputs that aren't needed for scanning, not recent ones, and wallets that connect to your own pruned node behave the same as with a full node.
On a spare machine, syncing a pruned node over a weekend with decent bandwidth is a few hours of downloading. Once it runs, your wallet requests never leave your network, the correctness problem collapses because you control the data, and you stop depending on someone else's uptime.
If you want both privacy and convenience, a common middle path is running the node on a small VPS. That separates your home IP from the node's IP, but the VPS provider still sees the traffic pattern, so it moves the trust rather than removing it. A node at home behind a VPN achieves the same separation with fewer moving parts.
Practical wallet settings
In the GUI wallet, Settings, then Node, lets you switch between a remote node and your local daemon, and the same setting exists in the CLI with –daemon-address for remote and the default local daemon when running monerod on the same machine. When you change nodes, note that the wallet rescans from its own restore height, so switching back and forth is cheap. The one setting worth checking is trusted daemon. If the wallet and daemon are on the same machine, trust it. If the daemon is remote and run by someone else, leaving trusted mode on means the wallet skips some verification of the data it receives, which is convenient but exactly the omission attack surface described above.
Where remote nodes fit
The honest summary: a remote node exposes your IP and your sync timing to one operator, and puts correctness in that operator's hands. For small amounts and casual use, that's a fair trade for zero setup. For anything you'd be upset to get wrong, a balance you act on, a business, a large holding, run your own pruned node. The same principle applies across Monero tooling. Cold storage works only if the cold side stays cold, and that's a separate decision we covered in the cold signing guide. Multisig spreads trust across several parties rather than one operator, and we walked through the 2-of-3 setup mechanics separately. If you want to prove a payment to someone without revealing your wallet, view keys do that job, and they don't depend on which node you use.