Wallet Shows the Wrong Balance? Fix Sync With Your Node

When a wallet connected to your own node shows the wrong balance or misses transactions, check four things in this order: the node is fully synced, the Electrum server’s index has caught up with it, the wallet is really talking to your server, and the wallet has refreshed its addresses with a wide enough gap limit. The steps below walk through each check; background on wallet synchronization follows them.

Step-by-Step Guide

Diagnosing and resolving wallet synchronization issues requires a systematic approach that traces the data path from the Bitcoin network through your node to the wallet software. Follow these steps when your wallet shows incorrect balances, missing transactions, or delayed confirmations.

Data flows from the Bitcoin network to Bitcoin Core on your node, from Bitcoin Core to the Electrum server on the same node, and from that server to your wallet. Check each link in order. 1, node synced: its height matches the newest block on mempool.space. 2, index synced: Fulcrum or Electrs has reached your node's height too. 3, your server: the wallet talks to your server, not a public one, which would also see your addresses. 4, all addresses: refresh, then check the address type and the gap limit. In the example, the network and Bitcoin Core are at height 975,000 but the Electrum server is at 974,996, four blocks behind, so the wallet is out of date too. — **Check each link in the order the data travels.** In this example the node is up to date but its index is four blocks behind, so the wallet shows the blockchain as it was four blocks ago. With Sparrow connected straight to Bitcoin Core there is no index, so skip check 2. Heights are examples.

Step 1: Verify Your Node Is Fully Synchronized. Open your node’s dashboard or run bitcoin-cli getblockchaininfo and compare the “blocks” field against the current block height reported by a trusted source like mempool.space (accessed over Tor). If your node is behind, the wallet cannot show recent transactions. Common causes of sync lag include insufficient disk I/O speed (especially on SD cards), low peer count due to firewall restrictions, or the node having been offline for an extended period. Allow the node to catch up fully before investigating further.

Step 2: Confirm the Electrum Server Index Is Current. If you use Sparrow, Electrum, or another wallet that connects via the Electrum protocol, the indexing server (Fulcrum or Electrs) must also be fully synced with Bitcoin Core. Check its log output or dashboard for the current indexed block height. A lag between Bitcoin Core and the indexer means the wallet will show stale data even though the underlying node is current. A gap that doesn’t close points to an indexer that has stopped, or one still building its first index.

Step 3: Check Wallet Connection Status. In your wallet software, confirm it is connected to your personal server rather than a public one. In Sparrow, the toggle at the right of the status bar is switched on when the wallet is online, and its colour shows the server type: blue for a private Electrum server, green for Bitcoin Core and yellow for a public server. Hover over it to see the server’s name and the block height it reports. In Electrum, open Tools → Network: in Auto-connect mode Electrum switches to another server when yours is unresponsive or lagging, so choose “Connect only to a single server” and enter your own. A public server may show a different view of your transaction history, and it learns your addresses.

Step 4: Refresh or Rescan the Wallet if Transactions Are Missing. If your node and indexer are both current but specific transactions do not appear, the wallet’s local copy may have missed them during a sync gap. In Sparrow, choose View → Refresh Wallet (Cmd/Ctrl+R). If Sparrow connects straight to Bitcoin Core and the missing transactions are older than the wallet’s birth date, set an earlier date in the wallet’s Settings (the Advanced… button), which makes Bitcoin Core rescan the blocks from that date for Sparrow; the same dialog holds the gap limit. Electrum has no rescan command, because it asks your server about each of its addresses every time it connects. If funds are still missing there, raise the gap limit: open the Console tab (tick Console in the View menu if it is hidden) and run wallet.change_gap_limit(100).

Two ways a wallet finds your past payments. Through an Electrum server, Fulcrum or Electrs on your node: the server keeps an index by address, so your wallet asks about each address and gets every payment, however old; no birth date is needed and there is nothing to rescan. With Sparrow connected straight to Bitcoin Core: Bitcoin Core scans the blocks for Sparrow from the wallet's birth date to today, so a payment in an earlier block is missed while a later one is found; set an earlier birth date and it rescans. If you are unsure of the date, pick one well before your first payment. — **A birth date only matters when the blocks themselves have to be scanned.** An Electrum server already knows every address’s history. When Sparrow connects straight to Bitcoin Core, Bitcoin Core looks only from the birth date onward, and an earlier date only makes the scan longer.

Step 5: Verify Transaction Propagation for Outgoing Payments. If a payment you sent doesn’t appear in the recipient’s wallet, look up its transaction ID (txid) on your node with bitcoin-cli getmempoolentry <txid>. This command finds only transactions still waiting in your node’s mempool. If it finds yours, the payment is simply waiting for a miner: during high-fee periods, low-fee transactions can stay unconfirmed for hours or days. If it answers “Transaction not in mempool”, the payment may already be in a block, so look it up in your wallet’s history or your own block explorer first. If it isn’t in a block either, your node rejected it or dropped it. A payment rejected for paying too little, or dropped after waiting too long, hasn’t moved any coins, but it is still valid and other nodes may still hold it. To send it again with a higher fee, spend at least one of the same coins, with your wallet’s fee bump (RBF) or coin control, so only one version can confirm. A new payment from other coins could let both confirm and pay the recipient twice. A payment whose coins were already spent by another transaction can’t go through: that other transaction is the one that counts.

Step 6: Compare State Across Multiple Wallet Implementations. Import the same extended public key into a second wallet application connected to the same node. If both wallets show the same balance and transaction history, the data is consistent and any remaining discrepancy is likely a display or caching issue in the original wallet. If the wallets disagree, the problem may lie in derivation path differences — verify both wallets use the same derivation path (e.g., m/84'/0'/0' for native SegWit) and gap limit settings.

Step 7: Check Your Node’s Connections. A node with too few peers hears about new blocks and transactions late. Run bitcoin-cli getnetworkinfo and look at connections_out: Bitcoin Core keeps 10 outgoing connections by default, 8 that relay transactions and blocks and 2 that relay only blocks. If the number stays well below 10, check the internet connection, the firewall and, if your node runs over Tor, whether Tor is working. A wired Ethernet connection is also steadier than Wi-Fi. The node connectivity troubleshooting guide walks through each check.

Common Mistakes to Avoid

Wallet sync issues often stem from configuration oversights rather than software bugs. Recognizing these patterns can save significant debugging time.

1. Running Bitcoin Core on an SD Card Without SSD. SD cards have dramatically lower random read/write speeds compared to SSDs. Bitcoin Core’s database operations — particularly UTXO set lookups and block validation — require fast random I/O. A node running on an SD card will fall behind during periods of high transaction volume and may struggle to stay synchronized. Always use an SSD (even an inexpensive SATA model) for the Bitcoin data directory.

2. Insufficient Gap Limit Configuration. HD wallets derive addresses sequentially and stop scanning when they encounter a “gap” of unused addresses. The default gap limit is 20 in most implementations. If 20 or more addresses in a row were handed out but never paid (common when a shop or payment server creates an address for every invoice), the wallet stops scanning before reaching later addresses with balances. Increase the gap limit in your wallet settings — Sparrow supports this under the wallet’s advanced settings.

Your wallet adds up only the addresses it scans. On the bc1q addresses (path m/84'), the type this wallet scans, addresses 0 and 1 received payments and are found; addresses 2 to 21 are 20 unused in a row, so the scan stops there and a payment to address 22 is missed. Fix: raise the gap limit, in Sparrow under Settings, Advanced, or in Electrum's console with wallet.change_gap_limit(100). A payment to a 1 address (path m/44'), another type, is never scanned; fix: restore the same words with that address type too. A block explorer shows any address you paste; your wallet shows only what it scans. — **When a wallet and a block explorer disagree, the wallet is usually looking in the wrong place.** Most wallets stop after 20 unused addresses in a row and look only at their own address type. The coins are still on the blockchain.

3. Time Zone and Clock Drift on the Node. Bitcoin Core uses timestamps in block headers and for peer protocol timing. A system clock that is significantly wrong can cause the node to reject valid blocks or misbehave during peer handshakes. Ensure your node’s system clock is synchronized via NTP (Network Time Protocol): on Linux, timedatectl status should show System clock synchronized: yes. If NTP service shows inactive, sudo timedatectl set-ntp true starts the time service the system has installed, such as systemd-timesyncd or chrony. The node time sync guide covers the other fixes.

4. Confusing Unconfirmed Transactions with Missing Transactions. A transaction that has been broadcast but not yet included in a block will appear as “unconfirmed” or “pending” in most wallets. During fee spikes, transactions with low fee rates may remain unconfirmed for days. This is normal behavior, not a synchronization error. If you need to accelerate a stuck transaction, use Replace-By-Fee (RBF) to broadcast a new version of it with a higher fee, or use Child-Pays-For-Parent (CPFP) by spending an output of the stuck transaction with a high fee. The RBF and CPFP walkthrough shows both.

You send a payment and it has 0 confirmations: it is pending in each node's mempool, where higher fee rates go first. Either a miner puts it in a block and it is confirmed, or, with Bitcoin Core's defaults, nodes drop it after 14 days unconfirmed, or when the mempool passes 300 MB and it pays among the least. Dropped is not cancelled: the coins never moved, but the signed payment stays valid and can be broadcast again until those coins are spent. Stuck for too long? The sender can replace it with a higher fee (RBF); the receiver can spend it onward with a high fee (CPFP). — **A pending payment is waiting, not lost.** If nodes drop it, the coins stay where they were. To cancel it, spend the same coins in a new payment with a higher fee: once that one confirms, the old one never can.

5. Ignoring Wallet Birth Date During Recovery. When you restore a wallet from its seed phrase into a setup that scans the blocks for your addresses, such as Sparrow connected straight to Bitcoin Core (Bitcoin Core does the scanning), it needs to know how far back in the blockchain to look. Through an Electrum server the birth date doesn’t matter, because the server’s index already holds every address’s history. If you set the birth date too late, the wallet misses earlier transactions and shows an incorrect balance. Always record the approximate date you created each wallet alongside the seed phrase. If unsure, set the birth date to a date well before you believe the first transaction occurred, at the cost of a longer rescan time. On a pruned node the scan can’t go back further than the oldest block the node kept.

Frequently Asked Questions

Why does my wallet show a different balance than a block explorer?

The most common cause is that the block explorer looks up whatever address you paste, while your wallet only adds up the addresses it scans, usually of a single address type. For example, if your seed generates both legacy (1...) and native SegWit (bc1q...) addresses, but your wallet only scans the SegWit path, funds on legacy addresses will not appear. Another cause is the gap limit: if a paid address comes after a run of 20 or more unused ones, the wallet stops scanning before it reaches that address. Finally, if your wallet is connected to a node or server that is not fully synced, it may display a stale balance that does not include recent transactions.

How long should it take for a new transaction to appear in my wallet?

If your wallet is connected to a fully synced node or Electrum server, a transaction you broadcast yourself shows up within seconds. An incoming payment has to reach your node first. Bitcoin Core passes each new transaction on to its peers after a short random delay, about 2 seconds on average to the peers it connected to and 5 seconds to the ones that connected to it, so a payment usually reaches your node within seconds. A node with few connections, for example one whose internet connection or Tor keeps failing, hears about it later. By default Bitcoin Core keeps 10 outgoing connections: 8 that relay transactions and blocks, and 2 that relay only blocks. A confirmation needs a block, and blocks come every 10 minutes on average, though the gap between two blocks varies widely.

Can I use multiple wallet applications connected to the same node simultaneously?

Yes. Your Electrum server (Fulcrum or Electrs) supports multiple concurrent client connections. You can have Sparrow, Electrum desktop, and a mobile wallet all connected to the same server simultaneously. Each client independently queries addresses and receives notifications for new transactions. This setup is actually beneficial because it lets you cross-verify balances across implementations. The only consideration is that each additional client adds a small amount of load to the Electrum server, but even modest hardware handles dozens of simultaneous connections without difficulty.

What causes a transaction to disappear from my wallet after being visible?

This typically occurs with unconfirmed transactions that get evicted from the mempool. Bitcoin Core nodes purge transactions from the mempool if they remain unconfirmed for more than 14 days (by default) or if the mempool exceeds its size limit (300 MB by default) and the transaction’s fee rate is below the eviction threshold. When this happens, the transaction can disappear from your wallet’s history. The coins never left the sender’s address, but dropped is not cancelled: the signed transaction stays valid and can be broadcast again until those coins are spent in another transaction. The sender can replace it with a higher-fee version that spends the same coins, or rebroadcast it once mempool congestion subsides.

Background: how wallets, nodes and servers stay in sync

The reliability and security of Bitcoin wallet implementations represent critical components in the broader cryptocurrency ecosystem. This analysis explores the technical intricacies of wallet synchronization, transaction propagation, and the importance of running self-hosted nodes for sovereign Bitcoin custody.

Network synchronization between Bitcoin nodes and wallet software presents unique technical challenges that directly impact user experience and security. When running a full node connected to wallet software, several critical factors influence transaction detection and confirmation visibility, including network latency, block propagation, and proper implementation of the Bitcoin peer-to-peer protocol.

One of the most fundamental aspects of Bitcoin wallet security is the ability to independently verify transactions through self-hosted infrastructure. Running a personal full node connected to wallet software enables users to validate transactions without trusting third-party servers. This setup requires careful configuration of both the node software and wallet implementation to ensure proper communication and synchronization.

The relationship between different wallet implementations and node software can introduce complexities in transaction detection and confirmation. Hardware wallets, software wallets, and node implementations must all properly implement the Bitcoin protocol specifications to maintain consistency. Variations in implementation details can sometimes lead to temporary discrepancies in transaction visibility across different software.

Transaction propagation through the Bitcoin network follows specific technical patterns that affect confirmation visibility. When a transaction is broadcast, it first enters the mempool of nodes that receive it. The speed at which different nodes receive and propagate transactions can vary based on network conditions, leading to temporary inconsistencies in transaction visibility across different wallet implementations.

Block propagation represents another critical factor in transaction confirmation visibility. When a new block is mined, it must propagate through the network before all nodes become aware of the included transactions. This process can introduce delays between when a transaction is confirmed and when different wallet implementations display the confirmation.

Proper node configuration plays an essential role in maintaining reliable wallet synchronization. Network connectivity, peer connections, and proper firewall configuration all impact how quickly a node receives new transactions and blocks. Users running personal nodes must ensure their setup meets the technical requirements for reliable operation.

The security implications of wallet synchronization extend beyond mere transaction visibility. Proper verification of incoming transactions requires careful validation against the blockchain state. Wallet software must implement robust verification mechanisms to protect against various attack vectors while maintaining usability.

Looking toward the future, ongoing developments in Bitcoin protocol improvements and wallet implementations continue to enhance synchronization reliability and security. Projects focused on improving block propagation, transaction relay, and node performance contribute to a more robust ecosystem for Bitcoin custody solutions.

For users prioritizing sovereignty and security in their Bitcoin holdings, understanding these technical considerations remains crucial. Running properly configured personal infrastructure provides the highest level of security and reliability, though it requires careful attention to implementation details and ongoing maintenance.

The broader implications for Bitcoin’s continued development emphasize the importance of robust wallet implementations and node software. As the network grows, maintaining reliable synchronization while preserving decentralization and security represents an ongoing challenge for the technical community to address.

Related Resources

Part of our free Bitcoin course: This topic is covered in Setting Up Your Bitcoin Node Step by Step, from the Lightning Network & Bitcoin Nodes course.

Filed under: Bitcoin Nodes & Infrastructure