A full node provides no self-custody benefit unless wallets actually query it. The wallet-to-node connection is the practical step that converts node operation from "I have one" into "I use one." The standard pattern: the node runs Bitcoin Core plus an Electrum server (Electrs is the canonical choice); the wallet (Sparrow, Specter, Nunchuk, Electrum, BlueWallet) is configured to query the local Electrum server rather than a third-party server. The configuration is typically a one-line change in the wallet settings; the operational change is total — every wallet query now hits the holder's own node rather than a third party. This note treats the practical setup: how to wire each major coordinator to a custom node; the Tor consideration (for the privacy-conscious, the wallet's queries should themselves be Tor-routed); the testing pattern (verifying the wallet is actually using the node rather than falling back to a default); and the patterns that work for desktop vs mobile vs air-gapped configurations.
Why this note matters
The wallet-to-node connection is often skipped or misconfigured. A holder runs a node, then continues querying third-party servers via the wallet’s defaults. The privacy and verification benefits of the node are not realized. The note matters because:
- It establishes the practical step that connects the node-running practice to the wallet-using practice
- It clarifies how each major coordinator handles the connection — the specifics matter; defaults vary
- It surfaces the verification pattern — how to confirm the wallet is actually using the node
The defensible position: a node that no wallet queries is a node that delivers no self-custody benefit. The wallet-to-node connection is the operational closing of the loop.
What this is
The wallet-to-node connection involves:
- The node runs Bitcoin Core (validates the chain)
- The node runs an Electrum server (provides the API the wallet queries)
- The wallet is configured to point at the local Electrum server (rather than a default third-party server)
- The wallet’s queries flow: wallet → Electrum server (on node) → Bitcoin Core (on node) → local blockchain copy
Without step 3, the wallet defaults to:
- A vendor-hosted server (Trezor Suite uses Satoshi Labs’s; Electrum uses one of several public servers; Sparrow has reasonable defaults)
- A third-party API (BlueWallet historically; some others)
- A selected server (typically a public server with no privacy properties)
With step 3, the wallet queries the holder’s own infrastructure — full sovereignty.
The Electrum protocol
The Electrum protocol is the API by which most Bitcoin wallets query a backend. It allows the wallet to:
- Get the balance of any address (without revealing private keys)
- Get the transaction history of any address
- Subscribe to new transactions for any address
- Broadcast signed transactions
The protocol is implemented by Electrum servers — distinct from the Electrum wallet (which is a wallet). The common Electrum-server implementations:
- Electrs (Romanian Bitcoin developer Roman Zeyde) — most common in the Umbrel/Start9 ecosystems
- ElectrumX — older implementation
- Fulcrum — newer, performance-focused
For the holder, the choice of Electrum server is typically pre-made by the node platform (Umbrel uses Electrs; Start9 uses Electrs; Raspiblitz uses Electrs). The wallet doesn’t care which implementation it’s talking to as long as the protocol is supported.
How to wire each major wallet coordinator
Sparrow Wallet
Sparrow has strong native support for custom node configuration.
- Open Sparrow → File → Preferences → Server
- Choose “Private Electrum” (or “Bitcoin Core” for direct RPC)
- Enter the local server URL: typically
127.0.0.1:50001for Electrs on localhost, or192.168.x.x:50001for a node on the home network, or a Tor onion address for remote access via Tor - Test the connection — Sparrow displays the connection status
- Save
For a node on the home network, the wallet must be on the same network (or use VPN/Tor for remote access). For a node accessed via Tor, the wallet’s Tor configuration must be enabled.
Specter Desktop
Specter is multisig-focused and integrates tightly with Bitcoin Core.
- Specter typically discovers Bitcoin Core automatically if both are on the same machine
- For remote node: Configuration → Connect to a remote Bitcoin node
- Enter the RPC connection details (URL, username, password from the node’s configuration)
- Specter can also use an Electrum server; the configuration is similar to Sparrow
Nunchuk
Nunchuk supports both desktop and mobile use; the configuration is per-platform.
- Desktop: Settings → Network → Electrum server → enter URL
- Mobile: Settings → Network → Electrum server → enter URL (typically the Tor address of your home node)
For mobile use, Tor is the standard remote-access pattern. Some holders maintain a “home setup” where the mobile wallet queries the home node via Tor; the privacy is preserved.
Electrum Wallet
Electrum (the wallet, not the protocol) is the original Bitcoin desktop wallet.
- Tools → Network → Server
- Switch from “Auto-connect” to manual
- Add your local server URL
- Verify connection
BlueWallet
BlueWallet is a mobile-first wallet. Custom Electrum server support is available:
- Settings → Network → Electrum server → enter URL
- For remote access, use the Tor address; BlueWallet supports Tor-routed queries
Bitcoin Core (directly)
For the technically inclined, Bitcoin Core itself can be the wallet — no Electrum server in between. The operator manages keys directly through Bitcoin Core’s RPC interface. This is operationally heavy but provides maximum control. Sparrow can also connect to Bitcoin Core’s RPC directly (rather than via Electrs) for some operations.
When to use Tor
Running the wallet-to-node connection over Tor adds privacy:
- The wallet’s connection to the node is not observable on the local network
- The connection from remote locations (mobile, traveling) reveals neither the wallet’s IP nor the node’s IP
- Network observers cannot correlate wallet activity with the node’s IP
For sovereignty-aligned holders, Tor is the default. For convenience-first users, Tor adds complexity without the corresponding benefit. The trade-off is genuine; the right choice depends on threat-model priorities.
Most node platforms (Umbrel, Start9, Raspiblitz) provide Tor onion addresses for the Electrum server. Configuring the wallet to use this address routes the connection through Tor.
Testing the connection
After configuration, verify that the wallet is actually using the local node rather than falling back to a default:
Visual verification
Most wallets display the connected server’s URL or fingerprint in the network settings. Verify that:
- The displayed server is the local server (your node’s URL or onion address)
- The connection status is “connected” rather than “connecting” or “fallback”
- The block height matches your node’s block height
Functional verification
A more thorough check:
- Stop the local Electrum server (briefly)
- Trigger a wallet operation (refresh balance, create a transaction draft)
- Observe that the operation fails or hangs — this confirms the wallet was actually using the local server
- Restart the local Electrum server — wallet operations resume
If the operation succeeds while the local server is down, the wallet is falling back to a default. The configuration needs to be adjusted.
Block-height verification
The simpler check:
- Note the current block height as reported by the wallet
- Compare to the block height on your node’s dashboard (Umbrel, Start9, etc., show this)
- The two should match — within a few blocks of each other due to refresh timing
If they don’t match, the wallet may be using a different server than expected.
Tradeoffs and considerations
The remote-access question revisited
How does the wallet reach the node when you’re not at home?
- Local network access only: the wallet works only when you’re on the same network as the node
- VPN to home network: the wallet works wherever the VPN reaches; requires VPN setup
- Tor onion access: the wallet works anywhere with internet; uses Tor for the connection; modest performance hit
- Vendor cloud relay (Umbrel offers this): the wallet works via a relay; introduces a vendor dependency
For sovereignty-aligned holders, Tor is the standard. For convenience-first users, VPN or relay is reasonable.
Performance considerations
The wallet-to-node connection has some performance implications:
- First sync of a wallet against a freshly-restored backup can take a while (scanning historical blocks for the wallet’s addresses)
- Routine queries are fast — the node has the data locally; the wallet displays balances and history immediately
- Tor routing adds latency (typically a few hundred ms per query); usually unnoticeable for batched operations
For most holders, performance is not a limiting factor.
Falling back to defaults
A common configuration issue: the wallet is configured to use the local node, but on connection failure, it falls back to a default third-party server without notification. The privacy is then quietly compromised.
The defence: explicit testing (per the testing section above); disabling fallback in wallet settings where possible; periodic verification.
The multisig coordinator question
For multisig, the coordinator (Sparrow, Specter, Nunchuk) is the wallet — it’s what builds PSBTs, displays the multisig configuration, and orchestrates signing. All major coordinators support custom node configuration. The wallet-to-node connection at the coordinator level is the same pattern.
The hardware-wallet implications
Hardware wallets themselves don’t directly connect to nodes — they sign transactions handed to them by the coordinator. The wallet-to-node connection is at the coordinator level. The hardware wallet is unaffected by the node configuration.
The implication: the hardware wallet works the same way regardless of whether the coordinator queries a custom node or a default server. The sovereignty benefit is at the coordinator-and-node layer.
Tiered application
Tier 0: Custom-node configuration is rare; most Tier 0 wallets don’t easily support it. The convenience of defaults dominates.
Tier 1: Strongly consider. The privacy benefit accrues at any scale; the setup is one-time.
Tier 2: Standard practice. The verification benefit is relevant; the discipline aligns with broader self-custody practice.
Tier 3: Multiple wallets queried against multiple nodes (redundancy); Tor by default; explicit verification.
Common pitfalls
Configuring the wallet but never verifying it’s actually using the node. The default-fallback pattern means the wallet may be using a third-party server you don’t realize.
Forgetting to update the wallet when the node’s URL changes. If the node moves (different hardware, different IP, network changes), the wallet’s configuration is stale. The wallet falls back to defaults.
Skipping Tor for sovereignty-aligned configurations. The wallet-to-node connection over the home network is private; over the internet without Tor, it reveals correlations. For mobile use specifically, Tor is the standard.
Using a coordinator’s “auto-discover” feature that finds public servers. Some wallets default to discovering and using public Electrum servers. This is the opposite of what you want; verify the configuration explicitly.
Treating the wallet’s local-node connection as the only sovereignty step. It’s necessary but not sufficient — broader operational security (per Operational security practices) is part of the picture.
Mixing hot wallets with custom-node configuration. Phone hot wallets are structurally hot regardless of node configuration. Using a custom node for a hot wallet is fine but doesn’t change the wallet’s exposure profile.
Tooling and resources
Coordinator software (all support custom-node connections):
- Sparrow Wallet — strongest native support
- Specter Desktop — Bitcoin Core RPC and Electrum support
- Nunchuk — desktop and mobile
- Electrum — the original wallet
- BlueWallet — mobile
- Bitcoin Core — direct RPC
Electrum server implementations:
- Electrs — the standard
- ElectrumX — legacy
- Fulcrum — performance-focused
Tor configuration:
- Most node platforms (Umbrel, Start9, Raspiblitz) provide Tor onion addresses for the Electrum server
- Wallet-side Tor configuration is per-wallet
The synthesis document: Bitcoin Self-Custody & Security (LegacyCipher, April 2026) — wallet-to-node connection treated as part of the sovereignty layer.
As of 2026-05-14: the wallet-to-node connection is well-supported across the major coordinators. The configuration is typically one-line; the verification is straightforward.
Open questions for further development
- The “wallet falls back silently to a default server” failure mode is real. Should wallets prompt the operator when fallback happens, rather than failing silently?
- Mobile-first wallet patterns are increasingly common. The “wallet on phone + node at home” pattern requires reliable Tor connectivity. Are there emerging tools that improve this experience?
- The lightning operation alongside Bitcoin nodes adds another layer of wallet-to-node connection. How does the framework treat the Lightning case?
- BIP-157/158 (compact block filters) are an emerging alternative to the Electrum protocol. They have different privacy properties. As adoption grows, will the wallet-to-node connection pattern shift?
Related notes
The framing context:
- Running a full node — the framework on whether to run a node at all
- Node hardware options — the platform choices
Adjacent operational notes:
- Operational security practices — wallet-to-node connection is part of opsec
- Common attack vectors — third-party server queries as an attack surface
Coordinator software (referenced):
- The wallet coordinators are not separately noted; their support for custom nodes is part of their general functionality
Hardware wallets:
- Hardware wallets overview — unaffected by the node configuration
- All per-device notes
Custody configurations:
- Multisig setups — the coordinator’s node configuration is part of the setup
- Collaborative custody services
Storage and key concepts:
- PSBT and wallet descriptors — the wallet-to-node connection handles PSBTs and descriptors
Specific platform notes:
- Umbrel — provides the Electrum server alongside Bitcoin Core
- Start9 — similar; with sovereignty-aligned defaults
The principal practitioners:
- Andreas Antonopoulos — Mastering Bitcoin covers wallet-to-node connections
The sub-MOC home: