Overview
The gap limit is a parameter used by HD wallets to determine how many consecutive unused addresses to derive and check before concluding that no further addresses have been used. Since HD wallets can generate an effectively unlimited number of addresses from a single seed phrase, the wallet needs a stopping rule when scanning the blockchain during recovery or synchronization. The gap limit provides that rule.
The standard gap limit, established by BIP44, is 20. This means a wallet will derive addresses sequentially and, once it encounters 20 consecutive addresses with no transaction history, it assumes all subsequent addresses are also unused. This works well for typical usage patterns but can cause problems for users who generate many addresses in advance — such as merchants, exchanges, or users of certain privacy tools.
How the Gap Limit Works
Address derivation scan during wallet recovery:
Index: 0 1 2 3 4 5 6 7 ... 25 26 27
│ │ │ │ │ │ │ │ │ │ │
Used?: ✓ ✓ ✗ ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✗
│ │ │ │ │ │ │ │ │ │ │
└────┴────┴────┴────┴────┴────┴────┘ └────┴────┘
After index 7, the wallet finds 20 consecutive unused addresses
(indices 8-27). It stops scanning.
Problem scenario:
If address at index 30 was actually used, the wallet will NOT
detect it because it stopped at index 27.
Funds at index 30 appear "missing" until the gap limit is increased.
When the Gap Limit Causes Problems
The default gap limit of 20 is sufficient for most individual users, but certain use cases routinely exceed it:
- Merchant systems: A point-of-sale system that pre-generates a unique address for each customer or invoice may create hundreds of addresses, many of which go unused if customers abandon their purchase
- Exchange deposit addresses: Exchanges generate addresses for many users, with gaps when accounts are created but never funded
- Privacy tools: Some privacy workflows involve generating many addresses to receive CoinJoin outputs or other mixed funds
- Wallet migration: Restoring a wallet with a new application that uses a different default gap limit than the original
Adjusting the Gap Limit
Most advanced wallet software allows users to configure the gap limit:
| Wallet | Default Gap Limit | Configurable? |
|---|---|---|
| Bitcoin Core | 20 | Yes (via keypoolsize) |
| Electrum | 20 | Yes (in console) |
| Sparrow Wallet | 20 | Yes (in settings) |
| Blue Wallet | 20 | Limited |
When recovering a wallet, if the balance appears lower than expected, increasing the gap limit and rescanning is the first troubleshooting step. Setting the gap limit to a very high value (e.g., 1000) increases the scan time but ensures all used addresses are found.
Relationship to Extended Public Keys
The gap limit is particularly relevant when using extended public keys (xpubs) with watch-only wallets or third-party services. If a service generates addresses from an xpub and exceeds the gap limit, the corresponding spending wallet may not detect the incoming funds unless its gap limit is also increased. This is a common source of confusion when integrating Bitcoin payments into e-commerce platforms.
Impact on Blockchain Scanning
The gap limit represents a trade-off between completeness and efficiency. A higher gap limit means:
- More addresses to derive: Each additional address requires BIP32 key derivation (HMAC-SHA512 computation)
- More blockchain queries: Each address must be checked against the blockchain for transaction history
- Longer sync times: Especially significant for light clients that query external servers
For full nodes with local blockchain data, the performance impact is minimal. For mobile wallets and SPV clients, an excessively high gap limit can noticeably slow down wallet synchronization.
Related Concepts
- HD Wallet — the wallet architecture that uses gap limits for address discovery
- BIP32 — the key derivation standard underlying HD wallets
- Extended Public Key — sharing an xpub with services requires awareness of gap limits
- Address — the derived addresses that the gap limit governs
- Seed Phrase — the master secret from which all addresses are derived during recovery