Skip to content

Make BDK_CLIENT_STOP_GAP and BDK_WALLET_SYNC_TIMEOUT_SECS configurable #843

Closed

Description

@Copexit

Problem

BDK_CLIENT_STOP_GAP (20) and BDK_WALLET_SYNC_TIMEOUT_SECS (20s) are hardcoded constants in config.rs:

pub(crate) const BDK_CLIENT_STOP_GAP: usize = 20;

const DEFAULT_LDK_WALLET_SYNC_TIMEOUT_SECS: u64 = 30;

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.

Activity

  1. tnull commented on Mar 25, 2026

    @tnull
    Collaborator

    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?

  2. Copexit commented on Mar 25, 2026

    @Copexit
    Author

    Yes, I think we only need a large stop gap during recovery.

  3. added this to the 0.8 milestone on Mar 27, 2026
  4. tnull commented on Mar 27, 2026

    @tnull
    Collaborator

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions