Temporary solution for DAO resync loop

To all users suffering with the constant dao resync issue at Bisq start, this is how I partially resolved mine, so you maybe want to try it too.
After you start bisq, and it returns the error popup, leave it running and check the running bisq.log file (under linux, tail -f /home/youruser/.local/share/Bisq/bisq.log and in Windows… well have fun refreshing notepad :sweat_smile: ), it should show at some point something like

We request blocks from peer devinsn2teu33efff62bnvwbxmfgbfjlgqsu3ad4b4fudx3a725eqnyd.onion:8000 from block height 577747.

depending on the seednode you are connected to, and after a while it should start the second batch of blocks, and so on, until current blockheight.

When it completed the last batch of blocks, close bisq and try restarting, it may be solved.

1 Like


Since I cannot edit the above post anymore, I need to make a new one to amend that.
While the method explained above “works”, in my experience it will still lead to an unstable state where Bisq will still ask you to resync the DAO even if you are in consensus with seed nodes.

My current “working” solution, is to build Bisq from source (sorry, Windows users…) using this page as a guide:

and making sure to select branch 1.9.16 in the example of the first bullet, so using:
git clone --branch release/v1.9.16 https://github.com/bisq-network/bisq

It will not be rock solid, but at least for a decent amount of time after a DAO resync, you will be synced and able to do normal operations.
I do use my own bitcoin node though, so also check out



Currently, those who updated to bisq 1.9.16 to solve the DAO issue, could have new issues with DAO sync again, so the advised solution is to go back to 1.9.15, as the issues there have been fixed in the meantime.

Make sure you delete the version file in the root of the data directory to be able to downgrade.

1 Like