LND v0.21.5-beta.rc1 Caps External Bitcoin Fee Estimates at 10,000 sats/vB

Lightning Network Daemon (LND) published version v0.21.5-beta.rc1 on October 22, a pre-release candidate that introduces a ceiling of 10,000 satoshis per virtual byte for external Bitcoin fee estimates. The update addresses a gap in the software’s handling of data received from external fee APIs, which previously had a lower bound but lacked a corresponding upper limit.

Guarding Against Extreme Fee Inputs

The release notes specify that the new change applies a hard ceiling to values supplied by external services. This limit also bounds the API’s minimum-relay estimate. The developers describe this threshold as an extreme-value guardrail rather than an indication that such fees are normal, economical, or required by current network conditions.

A fee estimate functions as an input to a decision process rather than an instruction that must be obeyed at any cost. External services can return unusable values due to errors, changed data formats, or compromised dependencies. By bounding the input, the software limits one pathway through which an upstream problem can influence wallet operations. The larger operational context involves the need for software that handles money to have both a method for identifying problems and a path for deploying repairs.

Verification and Deployment Testing

The GitHub release page identifies the build as a pre-release and states that it requires no database migration. The page provides instructions for signature and binary verification, which support checking the integrity of the downloaded files. However, these verification steps do not demonstrate how the build will behave in every specific node configuration.

The release notes also describe a fix for a native SQL connection-pool deadlock. This change is relevant because node reliability depends on storage behavior as well as network communication. A process that remains running while requests stop completing can still fail the applications that depend on it. Therefore, testing a candidate build requires covering the service’s actual work, including receiving requests, accessing storage, handling failures, and restarting cleanly.

The absence of a database migration removes one category of potential change, but it does not prove that every interaction with existing data remains unchanged. For payment providers, this software maintenance is distinct from custody controls. Keeping signing authority secure and keeping a payment node functioning are separate responsibilities. Custody and recovery arrangements cannot replace the need for ongoing software maintenance. The final release decision and an operator’s deployment decision remain additional steps beyond evaluating this candidate build.