Gap limit
In a simple way, the gap limit corresponds to the number of new public addresses a wallet consecutively generates after the last one with any transaction associated with it.
According to BIP-44, the gap limit is configurable and its default value is 20. In this configuration, if the blockchain hits 20 empty (no transactions) addresses in a row (external chain), it expects there are no used addresses beyond this point and stops searching the address chain.
The next figure details the gap limit dynamic. The purpose level is hidden in the path derivations of the figure. From a unique seed, the path derivation happens up to the account level. In this example, the first wallet account has the path m/0. Considering just the addresses of change 0 (external addresses), each derived address will be of the form m/0/0/k, with k starting from 0.
Consider every request for address causes the wallet to derive a new one independently if there are transactions associated with it. If the gap limit is configured with this default value (20), after the generation of twenty empty addresses, the wallet stops scanning new addresses. Hence, the twenty-first request and all subsequent other ones will not receive a new address.
It is important to emphasize the consecutive aspect of the gap limit, i.e. when the sequence of addresses with no transactions is broken by an address with one associated transaction at least, the gap limit count restarts.
The next table detail this behavior. After 3 addresses with no transactions, the gap limit value is 3. Once the fourth derived address (m/0/0/3) has one transaction associated with it, the gap limit is restarted to zero. After deriving the next 20 new addresses (m/0/0/4, m/0/0/5, …, m/0/0/23), as the gap limit is configured with this default value, the wallet generates no new addresses. In fact, after the gap limit has reached its threshold value, any request for a new address obtains the same address m/0/ 0/23.
| Get Address | #Transactions | Gap Limit |
|---|---|---|
| m/0/0/0 | 0 | 1 |
| m/0/0/1 | 0 | 2 |
| m/0/0/2 | 0 | 3 |
| m/0/0/3 | 1 | 0 |
| m/0/0/4 | 0 | 1 |
| m/0/0/5 | 0 | 2 |
| Next 17 addresses | 17 empty adresses | 19 |
| m/0/0/23 | 0 | 20 |
| m/0/0/23 | 0 | 20 |
When a wallet returns a new address strictly after the address has at least one transaction associated with it, the gap limit is not ever reached. That is because the gap limit is incremented only after the generation of each address with no transaction associated.
Why the gap limit is needed?
According to BIP-39, a wallet is able to derive up to distinct addresses - infeasible to be handled in memory. Given that, it's impossible to generate all possible addresses and get the corresponding transactions when loading a wallet, then new criteria to stop this load had to be created, the gap limit. It's reasonable to assume that a wallet with 20 empty addresses in a row already loaded all transactions and it can safely stop the load. Some specific use cases require a bigger gap limit and this can be achieved by customizing some wallet parameters but it's important to keep in mind that a huge value in the gap limit increases the load time of a wallet.