You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make BDK_CLIENT_STOP_GAP and BDK_WALLET_SYNC_TIMEOUT_SECS configurable #843
When a wallet has generated more than 20 consecutive unused addresses and needs to recover from keys_seed with a fresh database, BDK's full scan stops at the gap limit and fails to discover UTXOs at higher derivation indices. The funds appear lost even though they're on-chain and spendable.
What happened
Learned this once I already "lost funds". Could happen to anyone who simply spams the "generate address" button 20 times on a fully working wallet. Once he needs to recover from seed, funds won't show.
Proposal
Expose both values as configurable fields on the Config struct (or as Builder methods), with the current values as defaults.
This would allow wallet recovery without forking or patching the crate. The defaults remain conservative (20 / 30s) for normal operation, but operators/integrationrs can increase them or allow configuration for recovery scenarios.
For the stop gap I am a bit hesitant as it's not the easiest concept to grok and users might easily set values that would have them run into Esplora rate limits, for example. I do wonder if we should rather make this a parameter of the new recovery_mode, i.e., for recovery users would set a higher stop gap once, but on next restart it would be back to defaults? Do you have any opinion on that?
Activity
tnull commentedon Mar 25, 2026
Sync timeouts are configurable since #774
For the stop gap I am a bit hesitant as it's not the easiest concept to grok and users might easily set values that would have them run into Esplora rate limits, for example. I do wonder if we should rather make this a parameter of the new
recovery_mode, i.e., for recovery users would set a higher stop gap once, but on next restart it would be back to defaults? Do you have any opinion on that?Copexit commentedon Mar 25, 2026
Yes, I think we only need a large stop gap during recovery.
tnull commentedon Mar 27, 2026
Tagging this for 0.8 so we make sure to revisit, though given the release is approaching fast I can't promise it won't end up slipping.