How to Connect a Monero Hardware Wallet to a Remote Node

After Binance delisted Monero in February 2024 and Kraken pulled XMR for European users the same year, a lot of people moved their coins off exchanges and into self-custody for the first time. That usually means two purchases at once: a hardware wallet to hold the keys, and a decision about how the wallet talks to the Monero network. The second part trips people up, because Monero's blockchain is roughly 200 GB and growing, and most users don't want to run a full node on a laptop.

The shortcut is a remote node — someone else's running daemon that your wallet connects to for block data. Pairing a Ledger or Trezor with a remote node gives you cold-storage security without a multi-hour sync. But it also introduces a metadata trade-off most guides gloss over. This article explains exactly what the node operator can and can't see, how the signing flow protects your funds, and how to wire the two together over Tor. If you bought your XMR through a no-log service like MoneroSwapper, this is the natural next step to lock it down.

Why pair a hardware wallet with a remote node

A hardware wallet keeps your secret spend key on a dedicated chip that never touches an internet-connected machine. A remote node solves a different problem: where your wallet gets its copy of the blockchain. These two concerns are independent, which is exactly why the combination works.

• Storage you don't have: a fully synced node needs ~200 GB of disk plus a long initial sync. A remote node removes that entirely — your wallet just queries an existing daemon.
• Keys stay offline: the device signs transactions internally, so connecting to a stranger's node never exposes your spend key, your seed, or your ability to move funds.
• Fast onboarding: a Ledger or Trezor restore plus a remote node can have you transacting in minutes instead of waiting for a 200 GB download.
• Portability: you can point the same hardware wallet at a different node from a different machine without re-syncing anything locally.

The cost of that convenience is metadata. The node sees your IP address and the transactions you broadcast through it. None of that lets it steal coins, but it can erode privacy if you don't route the connection carefully. The rest of this guide is about getting the convenience while closing that gap.

How the hardware-wallet plus remote-node setup actually works

It helps to separate two jobs the wallet performs: scanning the chain to find your incoming funds, and signing outgoing transactions. The hardware wallet and the remote node each touch only one of these.

The signing path stays on the device

When you build a transaction, the desktop wallet assembles the unsigned data and hands it to the hardware device. The device displays the destination address and amount on its own screen, you approve physically, and it returns a signed transaction. The secret spend key used to authorize the spend is generated and stored on the secure element and never leaves it. A compromised remote node — or even a compromised PC — cannot forge that signature.

The scanning path uses your view key locally

To detect coins sent to you, Monero relies on stealth address output detection and your view key. Your wallet software downloads blocks from the remote node and scans them on your own machine. Crucially, you do not upload your view key to the node — the node just serves raw block data and has no idea which outputs belong to you. RingCT hides amounts on-chain, so even the data the node serves reveals nothing about your balance.

What the node actually does

The remote node (a running instance of monerod) does three things for your wallet: it answers requests for blocks and outputs, it relays the transactions you submit into the mempool, and it reports the current chain height. Transaction propagation across the network then uses Dandelion++, which routes a new transaction through a randomized relay path before broadcasting it widely — designed to make the true originating node harder to pin down.

What a remote node can and cannot see

This is the single most misunderstood part of the setup. Your keys and balance are safe; your network metadata is not automatically safe. Here is the precise split.

The risk scenario is a logging node that records "IP X submitted transaction Y at time Z." On its own that's weak, but combined with other data it can chip away at the fungibility Monero is built to protect. The fix is straightforward: never expose your real IP to an untrusted node. Connect through Tor or I2P, or — best of all — run your own node and point the hardware wallet at 127.0.0.1.

How to connect your Ledger or Trezor over a remote node

The steps below use the official Monero GUI, which supports both Ledger (Nano S Plus, Nano X, Stax, Flex) and Trezor (Model T, Safe 3, Safe 5). The command-line wallet and Feather Wallet follow the same logic with different menus.

1. Prepare the device. Update firmware, then install the Monero app on your Ledger via Ledger Live (Trezor needs no separate app — its firmware handles Monero directly).
2. Get verified software. Download Monero GUI from getmonero.org and verify the GPG signature or hashes before running it. Skipping this step is how people get fake wallets.
3. Unlock and connect. Plug in the device, enter your PIN, and open the Monero app (Ledger). Leave it on the device's home screen.
4. Create a wallet from the device. In Monero GUI choose "Create a new wallet from hardware device," select your Ledger or Trezor, and let it generate the wallet bound to that device.
5. Choose remote node mode. Under Settings → Node, pick "Remote Node" and enter the address and port (clearnet defaults to 18081; many public nodes use the restricted port 18089).
6. Route through Tor. If you use an .onion node, set the SOCKS proxy to 127.0.0.1:9050 with Tor running. This hides your IP from the node operator.
7. Sync and verify. Let the wallet scan to the current height, then have the device display your primary address and confirm it matches the wallet.
8. Test a send. Build a small outgoing transaction, confirm the destination and amount on the device screen, and approve. The device signs; the node only relays.

Always verify the receiving address on the hardware wallet's own screen, not just in the desktop window — malware can rewrite what your PC shows, but it cannot rewrite the device display.

A privacy-first workflow in practice

Here is how the pieces fit for someone who wants strong privacy end to end. Say you acquire 2 XMR through a no-KYC swap on MoneroSwapper, sending from BTC or USDT without handing over identity documents. You withdraw directly to a receiving address generated by your Ledger — the coins land at a stealth address that only your view key can recognize.

Your Monero GUI is configured against a trusted .onion remote node through Tor, so the operator sees Tor traffic, not your home IP. When you later spend, the unsigned transaction goes to the Ledger, you confirm the amount on the small screen, and the signed result is relayed through the node and propagated via Dandelion++. At no point did a third party hold your keys, learn your balance, or tie your IP to the transaction.

For maximum assurance, swap the remote node for your own: sync monerod once on a home server or a spare machine, expose it over your LAN or a Tor hidden service, and point every wallet — hardware or hot — at it. You then trust no one for block data, and the only thing the public network sees is a Dandelion++-shaped transaction with no clear origin.

How to choose a trustworthy remote node

Not all public nodes are equal, and the one you pick is the party that sees your IP and your broadcasts. A few rules narrow the field fast.

• Prefer .onion over clearnet: a node published as a Tor hidden service signals the operator cares about privacy, and connecting to it hides your IP by default.
• Avoid "convenient" defaults you didn't choose: a node pre-filled by a random wallet fork is a node you have no reason to trust. Pick one deliberately.
• Watch the port: 18089 is the conventional restricted public RPC port, exposing only the calls a wallet needs; 18081 is the full unrestricted port and is usually meant for local use.
• Rotate or self-host for sensitive activity: if a transaction would be damaging to link to you, broadcast it through your own node rather than any public one.

If you already run a desktop full node occasionally, you can also enable trusted-daemon mode so the wallet trusts that specific node for certain RPC responses — only ever do this with a node you control. For everyone else, a reputable community node reached over Tor is the pragmatic default, and you can change it any time without touching the hardware wallet itself.

FAQ

Can a remote node steal my Monero if I use a hardware wallet?

No. Spending requires your secret spend key, which is generated inside the hardware wallet's secure element and never leaves it. A remote node only serves block data and relays transactions you have already signed on the device. The worst a malicious node can do is log your IP and broadcast timing, not move your funds.

Does the remote node see my balance or which coins are mine?

No. Your wallet scans the blockchain locally using your view key, which you never send to the node. Amounts are hidden on-chain by RingCT, and recipients are hidden by stealth addresses, so the node cannot link any output to your wallet or compute your balance.

Should I use Tor when connecting a Ledger or Trezor to a remote node?

Yes, unless you fully trust the operator. Without Tor or I2P, the node sees your real IP address and the transactions you submit, which is the main metadata leak in this setup. Running Tor and using an .onion node closes that gap with no effect on the device's signing security.

Is running my own node better than using a remote node?

For privacy, yes — your own node means no third party sees your IP or your transactions before the wider network does. The trade-off is roughly 200 GB of storage and an initial sync that can take hours to days. A remote node over Tor is a reasonable middle ground for most hardware-wallet users.

Do Ledger and Trezor handle remote nodes differently?

Not at the network level. Both devices only sign transactions; the desktop wallet handles all node communication identically whether the signer is a Ledger or a Trezor. The differences are in setup — Ledger needs the Monero app installed, while recent Trezor firmware supports Monero without a separate app.

Conclusion

Connecting a Monero hardware wallet to a remote node is the practical sweet spot between airtight key security and avoiding a 200 GB sync. Your spend key stays locked in the device, your view key stays on your machine, and RingCT keeps your balance opaque to everyone — including the node. The only thing you have to actively defend is network metadata, and Tor plus a trusted node (or your own daemon) handles that cleanly. Set it up once and you have cold-storage-grade privacy you can carry between machines. When you're ready to fund or top up that wallet without an exchange account, you can buy Monero anonymously through MoneroSwapper and withdraw straight to your hardware-wallet address.