<p>If by seed you are referring to a mnemonic phrase (12 or 24 words is common) then the process goes something like this:</p>

<ol>
<li>The phrase is hashed (or some other process) to produce random or pseudorandom bytes we will call the "seed"</li>
<li>The byte array seed is passed into BIP32 HD master key algorithm to create a BIP32 master key.</li>
<li>Following a standard like BIP44, the wallet then derives sub-keys sequentially in order. Checking for transaction history of each key's output.</li>
<li>If left alone, this loop would last forever, so standards like BIP44 specify a "gap limit" which means that if gap limit = 20, then "If I generate 20 addresses in a row that all have 0 transactions in their history, I will stop checking addresses" For receiving paths, 20 seems common, for change paths 1 is standard.</li>
</ol>

<p>Continue this loop until the gap limit is reached.</p>

<p>This type of methodology doesn't work for merchants or large exchanges, so the gap limit logic of "how far do we keep checking" may vary.</p>

<p>But most HD wallets rebuild themselves in this way.</p>

CC BY-SA 4.0
2019-03-14T01:39:15.790Z
2019-03-14T01:39:15.790Z
user3074620
<p>How does it identify the addresses and transactions on the blockchain in order to rebuild the history of that wallet?</p>

<wallet><address>
How does a wallet rebuild itself from its seed?
Miyamoto Mustashi
# How does a wallet rebuild itself from its seed?

(Asked by: username_0 on 2019-03-14)

How does it identify the addresses and transactions on the blockchain in order to rebuild the history of that wallet?

**Tags:** wallet, address


---

## 1 answers

### Answer by username_1 on 2019-03-14. Score: 2

If by seed you are referring to a mnemonic phrase (12 or 24 words is common) then the process goes something like this:

1. The phrase is hashed (or some other process) to produce random or pseudorandom bytes we will call the "seed"
2. The byte array seed is passed into BIP32 HD master key algorithm to create a BIP32 master key.
3. Following a standard like BIP44, the wallet then derives sub-keys sequentially in order. Checking for transaction history of each key's output.
4. If left alone, this loop would last forever, so standards like BIP44 specify a "gap limit" which means that if gap limit = 20, then "If I generate 20 addresses in a row that all have 0 transactions in their history, I will stop checking addresses" For receiving paths, 20 seems common, for change paths 1 is standard.

Continue this loop until the gap limit is reached.

This type of methodology doesn't work for merchants or large exchanges, so the gap limit logic of "how far do we keep checking" may vary.

But most HD wallets rebuild themselves in this way.


---

