LND caps external fee estimates at 10,000 sat/vB in pre-release

3 min

LND’s October 22 release candidate focuses on a quiet wallet risk: external fee estimates that software accepts too generously. Version 0.21.5 adds a ceiling for values received from an external fee API and includes fixes affecting node operations.

TL;DR

Published build: v0.21.5-beta.rc1, a pre-release.
Fee change: caps extreme estimates from an external service.
Verification vs testing: checking signatures differs from validating behavior in deployment.

A remote estimate needs limits before it reaches the wallet

The release notes report that external estimates previously enforced only a lower bound. The fix limits the estimate before it can influence fee-sensitive wallet operations.

The change sets a ceiling of 10,000 satoshis per virtual byte and bounds the API’s minimum-relay estimate. The cap is a guardrail against extreme values, not guidance on typical or economical fees.

Fee estimates are inputs to decisions, not commands. Services can return unusable values due to errors, data format changes, or compromised dependencies. Bounding inputs limits how upstream problems affect a wallet.

This aligns with Bitcoin Core’s revised disclosure process: money-handling software needs ways to find issues and to deploy fixes.

A candidate build still needs evidence from its deployment setting

The GitHub release page labels the build as a pre-release and notes no database migration. It provides signature and binary verification instructions. Verification checks what was downloaded. It does not prove behavior across node configurations.

The notes include a native SQL connection-pool deadlock fix. Reliability depends on storage as well as networking. A process that stays up while requests stop completing still fails dependent applications.

Testing must cover the service’s real workload: receiving requests, accessing storage, handling failures, and restarting cleanly. The absence of a database migration removes one category of change, but it does not guarantee unchanged interactions with existing data.

Operational risk is distinct from custody design. That separation applies to shared-key Bitcoin lending, where securing signing authority differs from keeping a payment node functional, and to custody and recovery arrangements, which do not replace software maintenance. This candidate provides specific changes to evaluate. The final release decision and an operator’s deployment decision remain separate steps.