<p>Yes the gap is an issue with the HD wallet.  Blockchain made a blog post about working with this issue. See here: <a href="https://blog.blockchain.com/2016/06/15/receive-payments-api-update-address-gap-limits/#more-9024" rel="nofollow noreferrer">https://blog.blockchain.com/2016/06/15/receive-payments-api-update-address-gap-limits/#more-9024</a></p>

<p>Let’s say you get paid to the first address, address 1 — the wallet will look ahead 2-21 addresses to see if there are any additional funds or transaction history in those addresses. If it doesn’t find anything, it will stop looking. So, if you get paid to address 22, the wallet software will not see the funds because it stopped at 21. However, if you get paid to address 2, the wallet software will look ahead addresses 3-22, see the funds that were sent to the address 22, and then look an additional 20 ahead (addresses 23 – 43).</p>

<p>Starting from August 1st, 2016, we will respond to API requests that would push you past the 20-address gap limit with an HTTP error, and we will not generate any new addresses for your xpub until we detect a payment that would close the gap below that limit. This ensures that you will never have unreachable funds through the use of Receive Payments API V2, but might lead to not generating addresses when your users request them.</p>

<p>You can call the checkgap API via the following endpoint:</p>

<p><a href="https://api.blockchain.info/v2/receive/checkgap?xpub=" rel="nofollow noreferrer">https://api.blockchain.info/v2/receive/checkgap?xpub=</a>{xpub}&amp;key={apikey}</p>

<p>You’ll get a JSON response that looks like:</p>

<pre><code>{ "gap": 1 }
</code></pre>

<p>This gap value represents the difference between the index of the most recent address paid to, and the most recently-requested address. If that value is 20 or greater, funds paid to any further addresses created will be hard to access until earlier addresses receive funds.</p>

CC BY-SA 4.0
2019-06-02T04:00:19.973Z
what is the status of this now in May 2019? is there a way to reduce the gap invalidating non paid addresses? maybe some expiration time?
Enrique
CC BY-SA 4.0
2020-01-25T04:29:33.097Z
I noticed with this blockchain.info company, most of their old URLs don't work. Like the one you posted to that blog post. (And it's not in the way-back-machine either.)
c00000fd
CC BY-SA 3.0
2016-08-18T00:21:55.497Z
2018-04-19T16:54:07.033Z
2018-04-19T16:54:07.033Z
m1xolyd1an
<p>Before new API limits happened a proper way to handle Bitcoin payments was</p>

<ul>
<li>Request separate address (public/private key) for each user</li>
<li>Store new address in user's account and display public part for transaction</li>
<li>Listen to callback from Blockchain.info</li>
<li>When callback arrives, check who's address made a payment, how much has been paid, conduct business logic and request a new address for this user.</li>
</ul>

<p>After new API introduced limits to the total number of requested addresses, it became useless from my point of view. At least I can not see how "reliably" handle payments from multiple user accounts simultaneously.</p>

CC BY-SA 3.0
2017-01-03T10:56:40.653Z
-1 please focus on answering the question instead of presenting a now obsolete solution and complaining about its obsolescence.
Murch
CC BY-SA 3.0
2016-12-28T01:43:20.523Z
2016-12-28T01:43:20.523Z
mrz
<p>We currently offer Bitcoin withdrawals and deposits on our website. Blockchain API is used to handle all operations.</p>

<p>Only problem is Blockchain Receive API's 20 address gap limit, as mentioned here: <a href="http://bitcoinx.io/news/articles/blockchain-info-updates-receive-payments-api-version-to-address-edge-cases/" rel="noreferrer">http://bitcoinx.io/news/articles/blockchain-info-updates-receive-payments-api-version-to-address-edge-cases/</a></p>

<p>Now we get a lot of curious users who click on Bitcoin deposit button and commit to it without actually sending any transaction, which easily build up to 20 addresses. What are some ways of removing this limitation? I have few ideas but they are rather bulky and some require complete re-write of code and replacement of Blockchain API. Can you guys offer any insight and/or advice? How can this problem be solved in elegant and efficient way?</p>

CC BY-SA 3.0
2016-08-17T18:41:58.697Z
I don't think I have a full understanding of your problem, but couldn't you just keep displaying the same address to the user who wishes to deposit until they actually deposit something to that address? Granted, this would take more API calls to check for any transactions that pay to that address.
morsecoder
CC BY-SA 3.0
2016-08-17T18:42:22.350Z
You should also be able to request more addresses after you use the initial 20, correct?
morsecoder
<blockchain.info><address-management>
How to solve Blockchain 20 address gap-limit problem?
Bitcoin Billionaire
# How to solve Blockchain 20 address gap-limit problem?

(Asked by: username_0 on 2016-08-17)

We currently offer Bitcoin withdrawals and deposits on our website. Blockchain API is used to handle all operations.

Only problem is Blockchain Receive API's 20 address gap limit, as mentioned here: <http://bitcoinx.io/news/articles/blockchain-info-updates-receive-payments-api-version-to-address-edge-cases/>

Now we get a lot of curious users who click on Bitcoin deposit button and commit to it without actually sending any transaction, which easily build up to 20 addresses. What are some ways of removing this limitation? I have few ideas but they are rather bulky and some require complete re-write of code and replacement of Blockchain API. Can you guys offer any insight and/or advice? How can this problem be solved in elegant and efficient way?

**Tags:** blockchain.info, address-management

> **Comments:**
> **username_1**: I don't think I have a full understanding of your problem, but couldn't you just keep displaying the same address to the user who wishes to deposit until they actually deposit something to that address? Granted, this would take more API calls to check for any transactions that pay to that address.  
> **username_1**: You should also be able to request more addresses after you use the initial 20, correct?  

---

## 2 answers

### Answer by username_2 on 2016-08-18. Score: 3

Yes the gap is an issue with the HD wallet.  Blockchain made a blog post about working with this issue. See here: https://blog.blockchain.com/2016/06/15/receive-payments-api-update-address-gap-limits/#more-9024
Let’s say you get paid to the first address, address 1 — the wallet will look ahead 2-21 addresses to see if there are any additional funds or transaction history in those addresses. If it doesn’t find anything, it will stop looking. So, if you get paid to address 22, the wallet software will not see the funds because it stopped at 21. However, if you get paid to address 2, the wallet software will look ahead addresses 3-22, see the funds that were sent to the address 22, and then look an additional 20 ahead (addresses 23 – 43).
Starting from August 1st, 2016, we will respond to API requests that would push you past the 20-address gap limit with an HTTP error, and we will not generate any new addresses for your xpub until we detect a payment that would close the gap below that limit. This ensures that you will never have unreachable funds through the use of Receive Payments API V2, but might lead to not generating addresses when your users request them.
You can call the checkgap API via the following endpoint:
https://api.blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response that looks like:
{ "gap": 1 }

This gap value represents the difference between the index of the most recent address paid to, and the most recently-requested address. If that value is 20 or greater, funds paid to any further addresses created will be hard to access until earlier addresses receive funds.

> **Comments:**
> **username_3**: what is the status of this now in May 2019? is there a way to reduce the gap invalidating non paid addresses? maybe some expiration time?  
> **username_4**: I noticed with this blockchain.info company, most of their old URLs don't work. Like the one you posted to that blog post. (And it's not in the way-back-machine either.)  

---

### Answer by username_5 on 2016-12-28. Score: 0

Before new API limits happened a proper way to handle Bitcoin payments was

* Request separate address (public/private key) for each user
* Store new address in user's account and display public part for transaction
* Listen to callback from Blockchain.info
* When callback arrives, check who's address made a payment, how much has been paid, conduct business logic and request a new address for this user.

After new API introduced limits to the total number of requested addresses, it became useless from my point of view. At least I can not see how "reliably" handle payments from multiple user accounts simultaneously.

> **Comments:**
> **username_6**: -1 please focus on answering the question instead of presenting a now obsolete solution and complaining about its obsolescence.  

---

