Rescue a Wallet: a Forgotten Passphrase, an Old wallet.dat, a Missing Balance

1Before you start: copies, and where wallets live

Divi Core keeps wallet.dat in its data folder. The defaults, from DataDirectory.cpp in the Divi Core source:

Testnet wallets sit one level down, in a testnet3 folder. Other wallet apps may keep their own folder; look in the app's settings for a "data directory" entry before searching the disk.

Divi Core keeps its own backups. Every time it starts it copies the wallet into a backups folder inside the data folder, named like wallet.dat.2026-10-22-11-24. The newest 20 copies are kept and older ones are deleted. A second folder, monthlyBackups, gets one copy a month. A copy is only made when the wallet passes an integrity check at start, so a damaged wallet never overwrites the good copies. Look there first in every rescue below.

2An old wallet.dat

You found a wallet.dat on an old laptop or a USB stick. Open it in Divi Core 3.0.0 without disturbing your current wallet:

# 1. stop the node
./divi-cli stop

# 2. copy the old file into the
#    data folder, under a new name
cp /media/usb/wallet.dat ~/.divi/old-2020.dat

# 3. start the node on that file
./divid -wallet=old-2020.dat -daemon

# 4. look
./divi-cli getwalletinfo
./divi-cli getbalance

What we saw with a wallet made in Divi Core 1.0.8 and opened in 3.0.0: it opened with no conversion step, still encrypted ("encryption_status":"locked"). Both versions use the same Berkeley DB 4.8 file format. The node then scanned the chain on its own, and the log in the data folder's debug.log said:

Some keys lack metadata. Wallet may require a rescan
Scanning... from height 360718 to 360847
addToWallet 384e999a3a new
addToWallet 59e09927cc new
Scanning...done

Both payments appeared and the balance read 17. The scan starts at the wallet's first key, minus two hours, so it does not read years of blocks the wallet cannot be in. The "lack metadata" line is the 1.0.8 file talking. Old wallets did not store a birth time for every key, and 3.0.0 notes it and carries on.

When you are done, stop the node and start it again without -wallet= to go back to your own wallet.

When the balance still looks short: a full rescan

-rescan at start reads the chain again, but in our test it started at the same height, because it also skips blocks older than the first key. If the wallet's key dates are wrong, for example after keys were imported from somewhere else, start once with -force_rescan. That reads from block 0. It is in the source (wallet.cpp) but not in divid -help. On our testnet node the log said Scanning... from height 0 to 360893, and the whole scan took 18 seconds. Testnet blocks are nearly empty; a mainnet scan on a laptop takes much longer. The normal scans above, on a tiny fresh wallet, took under a second.

./divid -wallet=old-2020.dat -force_rescan -daemon

3A forgotten passphrase

Nobody can reset a wallet passphrase. There is no server that knows it. What you can do is try the passwords you might have used, and if none fits, rebuild the wallet from its recovery phrase.

Try your own guesses

Write every candidate you can think of into a file, one per line: old passwords, with and without a capital, with the year, with a ! on the end. Then let the wallet test them. A wrong guess answers:

error: {"code":-14,"message":"Error: The wallet passphrase entered was incorrect."}

# only you can read the file
umask 077
nano ~/guesses.txt

# test each line; stops at the
# first one that unlocks
n=0
while IFS= read -r p; do
  n=$((n+1))
  if ./divi-cli walletpassphrase "$p" 1 >/dev/null 2>&1; then
    echo "Found it: line $n of guesses.txt"; break
  fi
done < ~/guesses.txt

# then wipe the file
shred -u ~/guesses.txt

We ran this exact loop with two wrong guesses and the right one third. It printed Found it: line 3 of guesses.txt. A longer run of 50 guesses took 6.2 seconds, about 8 guesses a second on our test machine. A list of a few thousand is an evening; a blind search of every possible password is not something this approach can do.

The 1 unlocks for one second only, so a hit does not leave the wallet open. Once you know the passphrase, open the wallet and choose a new one you will remember, then write it down where your recovery phrase is kept:

# the leading space keeps the line
# out of your shell history
 ./divi-cli walletpassphrasechange "the-old-one" "a-new-one"

We changed the test wallet's passphrase this way: the old one was refused afterwards and the new one unlocked it.

When no guess works

If you have the recovery phrase, the passphrase does not matter. The phrase rebuilds the wallet in a new, empty data folder, and you set a new passphrase there. Restoring from the phrase walks through it step by step. The phrase brings back only the keys made from it. Keys you imported, watch-only and multisig addresses, and the vaults a staking node manages are not in it, and without the passphrase they cannot be exported from the old file. So if the wallet held any of those, keep the file and keep trying passphrases. Failing that, look for a copy of the wallet made before it was encrypted, as described in the first step.

4A damaged wallet file

Disks fail and USB sticks get pulled out mid-write. We wrote 64 KiB of random bytes into the middle of a copy of the test wallet. Divi Core 3.0.0 refused to start on it and stopped with one line in debug.log:

Error: Wallet integrity check failed.

Try these in order.

1. The backups folder. Copy the newest wallet.dat.<date> from it into the data folder under a new name and open it with -wallet= as in step 2. Coins received after that copy was made still show up, because the scan finds them.
2. The recovery phrase. It rebuilds every key made from the seed, which no file repair can promise. Keys you imported, watch-only and multisig addresses, and the list of vaults a staking node manages are not in it; step 6 lists how to carry those. See restoring from the phrase.
3. A manual salvage, only when neither exists. It is below.

Manual salvage, on a copy

This uses the Berkeley DB tools on Linux (sudo apt install db5.3-util on Ubuntu or Debian). Copy the damaged file to that machine. The -r dump reads every page it can and skips the broken ones; the rest of the commands rebuild a clean file from what it found.

cp wallet.dat broken.dat
db5.3_verify broken.dat
# reports the bad page, e.g.
# Page 75: bad page number 2512285094

db5.3_dump -r broken.dat > salvage.dump

# keep the records, put them
# under one header
awk '/^HEADER=END/{s=1;next} /^DATA=END/{s=0} s&&/^ /' salvage.dump > body.txt
{ printf 'VERSION=3\nformat=bytevalue\ndatabase=main\ntype=btree\nHEADER=END\n'
  cat body.txt; echo DATA=END; } > rebuilt.dump

db5.3_load -f rebuilt.dump rebuilt.dat
db5.3_verify rebuilt.dat
# Verification of rebuilt.dat
# succeeded.

Copy rebuilt.dat into the data folder and open it with -wallet=rebuilt.dat. We ran this on two damaged copies, damaged in the same place:

So a salvage can return a file that looks fine to the database tools and still will not open as a wallet. That is why the phrase, and the backups folder, come first.

5A missing balance

The wallet opens, but the number is wrong or zero. Go down this list; each check was run on the test wallet.

6Moving an old wallet into IronDivi

IronDivi does not read wallet.dat. Its own wallet is a folder named wallet in the data folder, and a wallet.dat next to it is never opened. We put one in an IronDivi data folder; IronDivi ignored it and made a brand new wallet next to it, logging new wallet created; retrieve the seed with the dumphdinfo RPC. Nothing warns you that your file was skipped.

Move the keys instead. Open the old wallet in Divi Core as in step 2, unlock it, and export each address's key. Then import it into IronDivi:

# Divi Core, old wallet unlocked
./divi-cli dumpprivkey <address>

# IronDivi
irondivi-cli importprivkey <key>

IronDivi 0.2.6 scans the chain on import, like Divi Core, so the coins show as soon as the command returns. If you import many keys, pass "" false after each key to skip that scan, then run irondivi-cli rescanblockchain once at the end. On our testnet node (the 0.2.6 release on 23 October 2026, on two 2.6 GHz Xeon E5-2670 processors and a spinning disk) a full scan of about 363,000 blocks took 14 minutes the first time and about 40 seconds on each of the next two runs; mainnet is longer. irondivi-cli 0.2.6 gives up after 30 seconds and prints error: couldn't connect to server: connection timed out, but the scan carries on inside the node. Other commands time out the same way until it is done, so wait for the line Rescan complete: scanned … blocks in the node's log before you check the balance. rescanblockchain also takes a start height to scan only recent blocks, and on 0.2.6 that leaves the coins it already knows in place.

Divi Core 1.0.8 had dumpwallet to export every key at once. Divi Core 3.0.0 no longer has it, and neither program has importwallet, so export the addresses that hold coins one by one. listunspent in the old wallet lists them.

If the old wallet has a recovery phrase, restore it first (restoring from the phrase): it brings back every address made from the seed in one go. Then carry by hand what the phrase does not hold. In the old wallet, validateaddress shows an hdkeypath only for addresses made from the seed; any address that holds coins and has no hdkeypath is an imported key.

• Imported keys: dumpprivkey in Divi Core, importprivkey in IronDivi, as above.
• Watch-only addresses: irondivi-cli importaddress <address>.
• Multisig addresses: irondivi-cli addmultisigaddress <n> '["key1","key2",…]' with the same keys in the same order, so the address comes out the same.
• Vaults you manage (a staking node): irondivi-cli addvault "OWNER:MANAGER" <funding txid> again for each vault. The owner's side needs nothing: the owner key alone makes the vault the owner's.
• Labels: irondivi-cli setaccount <address> <label>.

Keep the old wallet.dat until getbalance in IronDivi, after its scan, matches the old wallet's. On testnet the phrase alone is not enough to compare: IronDivi 0.2.6 makes testnet addresses with coin type 301, the same as mainnet, while Divi Core uses 1 on testnet. So the same words give different testnet addresses in the two programs; on mainnet both use 301.

If something goes wrong