Guide · privacy
This is the largest privacy improvement a Sparrow user can make, and it costs nothing but patience. Everything else on this site is about protecting your keys. This page is about protecting the list of addresses those keys control.
Unofficial
A lightweight wallet does not hold the blockchain, so it has to ask somebody. The Electrum protocol works by handing the server a list of the addresses you care about and asking for their history. That is efficient, and it is also a complete disclosure: the operator now knows that this particular set of addresses belongs to one wallet, sees the total balance, sees each new address as you generate it, and — unless you are behind Tor — ties all of it to the IP address that asked.
None of that lets anyone spend your coins. Your keys never leave your machine, and the server cannot forge a signature. The damage is informational, and informational damage is permanent in a way that a stolen password is not: you can change a key, but you cannot un-tell someone which addresses were yours in 2026.
Most public servers are run by decent volunteers. Some are run by researchers, and some are run by people who would very much like a map of who holds what. You have no way to tell them apart, which is the actual argument for answering your own questions.
It removes the third party from the lookup entirely — nobody outside your household learns which addresses you watch. It also means you are verifying against a chain you validated yourself rather than trusting somebody's summary of it.
It does not anonymise money that arrived with a name attached. If you bought bitcoin on a platform that recorded your identity and withdrew it to an address, that link exists in their records no matter which server you query afterwards. Your own node stops the leak going forward; it does not rewrite history. The privacy page deals with the rest of that problem.
Preconfigured, instant, no maintenance. Correct choice while you are learning, and while the balance is small enough that you would not mind a stranger knowing it. Turn on Tor to at least keep your IP out of it.
Choose if: you want the wallet working in the next minute.
Sparrow talks to your node's RPC interface. Fewest components, nothing extra to keep running, and the strongest position: you validated the chain you are trusting. Rescans of a long wallet history are the slow part.
Choose if: you already run a node and your wallet is not huge.
Electrs, Fulcrum or similar in front of your node, answering address queries from a purpose-built index. Fast even with thousands of transactions, and it serves several wallets at once. One more service to maintain.
Choose if: your history is long, or you connect more than one wallet.
Walkthrough one
Sparrow can only ask questions a synced node can answer. Check the block height in Bitcoin Core against a public block explorer before you touch Sparrow — a node still catching up will report a zero balance for a wallet that is perfectly fine, and people conclude their coins are gone when the truth is that their node has not reached the block those coins arrived in.
Bitcoin Core needs its RPC server enabled (server=1 in bitcoin.conf)
and it needs to accept a connection from the machine running Sparrow. If both run on the same
computer, the loopback default is enough. If the node lives on another box on your network, Core
must be told to listen on that interface and to allow your wallet machine's address; a firewall
that silently drops the port is the most common reason a connection test fails for no visible
reason. Restart Core after any configuration change — it reads the file once, at startup.
Core writes a .cookie file into its data directory each time it starts, and
Sparrow can authenticate with that if it can read the file — the simplest option when node and
wallet share a machine. Across a network you will use an RPC username and password instead. Never
reuse a password you use elsewhere, and never expose the RPC port to the public internet: it is a
control interface, not a read-only API.
In Sparrow's server preferences choose Bitcoin Core, enter the host and RPC port, supply the cookie path or the credentials, then run the connection test before saving. A successful test reports the node it reached. If it fails, the cause is almost always one of three things: the node is not running, the port is blocked, or the credentials do not match.
The first connection triggers a rescan of your wallet's addresses against the node's data, which can take a while on an old wallet. When it settles, compare the balance and the newest transaction against what you saw before you switched. A balance that comes back short after a restore is usually a gap-limit problem rather than a connection problem — the setup guide covers raising it.
Describe your setup, do not copy someone else's
Configuration flags, default ports and file locations differ between operating systems, Bitcoin Core versions and appliance builds. What has to be true is stable — the node is synced, the RPC interface is reachable from the wallet machine, and the credentials match — but the exact lines belong to your own installation's documentation, not to a guide written against a different version. Treat any config snippet you find online, including ours, as a description of intent rather than something to paste.
Walkthrough two
Appliances exist so that you do not have to hand-configure any of the above. The trade is that their app store, not a wallet guide, is the authority on the address you should use.
Umbrel, Start9, RaspiBlitz and similar appliances all ship an app store containing an Electrum-server implementation — usually Electrs or Fulcrum — that sits in front of the Bitcoin Core node they already run. Install that app rather than trying to reach Core's RPC port across your network; the Electrum protocol is what Sparrow is happiest speaking, and it handles large wallet histories far faster.
An Electrum server builds an address index over the whole chain, and that takes hours on a Raspberry Pi even when Bitcoin Core is already synced. The app's own status screen tells you when it is ready. Connecting early produces confusing, partial results.
The app page shows the host and port to use, and usually both a LAN address and a Tor onion address. Take them from there rather than from a guide: the exact port and hostname differ between appliance versions and between server implementations, and a stale copied value is the single most common failure. If the app offers a QR code or a one-click "connect wallet" panel, use it.
Choose the private Electrum server option, paste the host and port, and enable SSL if the app
provides a certificate. For an onion address, leave Sparrow's built-in Tor proxy switched on —
that is what resolves .onion hostnames. Test the connection, then save.
Sparrow shows the connected server in its status area. Check it after every update, because a failed connection can fall back to a default public server, and a wallet that quietly reverts is leaking exactly the information you set this up to protect. Then read the privacy toolkit for the habits that make the rest of it count.
Never expose the interface to the open internet
Bitcoin Core's RPC port and an appliance's admin panel are control interfaces. Forwarding either of them through your router so you can "check the wallet from anywhere" is how people hand over their node, and on a machine that also holds a hot wallet, their coins. Reach it across your own network, or over the Tor onion address the appliance generates for exactly this purpose. Never through a plain port forward.
Tor is built into Sparrow, so there is nothing to install. It routes the wallet's server
traffic through the Tor network, which does two useful things: it hides your IP address from
whichever server you are querying, and it lets you reach .onion hostnames like
the one your appliance publishes.
What it does not do is hide what you asked. A public server queried over Tor still receives your address list; it simply does not know whose network it came from. Tor and your own node solve different halves of the same problem, which is why the private setup is worth the effort even if you already route everything through Tor.
Work top to bottom and resist the urge to restore from your seed phrase to "fix" a display problem. A wallet showing the wrong balance is a wallet being told the wrong thing by its server. Your coins are recorded on the chain either way, and re-entering your recovery words on a whim is how a bad afternoon becomes an expensive one. The setup guide explains the gap limit properly.
No. Sparrow works out of the box against preconfigured public servers, and for a small balance that is a reasonable place to start. What you give up is privacy, not security: the wallet still holds your keys and still verifies signatures, but the server operator learns which addresses belong to one wallet and, unless you use Tor, the IP address asking about them.
If you have a node and a modest wallet history, connect straight to Bitcoin Core: fewest moving parts, nothing extra to maintain. If your wallet has thousands of transactions, or you connect several wallets, put Electrs or Fulcrum in front of it. Sparrow supports Fulcrum, ElectrumX, Electrs, Electrs-Esplora, EPS and BWT, over SSL and Tor, according to the project's own feature documentation.
No. Sparrow stays a lightweight client — the chain lives on the node. The disk cost is on whichever machine runs Bitcoin Core, and that is hundreds of gigabytes plus an address index if you add an Electrum server. Your wallet machine only stores the wallet file.
You can connect to one, but pruning removes the old block data a full rescan needs, so importing an existing wallet with history from before the pruning horizon will not find those transactions. A pruned node is fine for a wallet created after the node was set up, and a poor fit for restoring an old backup.
Not for reaching it. On your own network there is no third party to hide from, and Tor only adds latency. Tor earns its place when you are reaching an onion address, when the node is somewhere else, or when you are stuck on a public server and want to keep your IP out of the operator's logs.
Work through it in order. Confirm the node is fully synced. Confirm Sparrow says it is connected to the server you intended. Let any rescan finish. Then raise the gap limit above the default 20 and rescan again, which resolves most cases where a restored wallet shows less than it should. Your coins are on the chain regardless of which server you ask — the wallet is only reporting what it has been told.