LND v0.21.5-beta.rc1 caps external Bitcoin fee estimates at 10,000 sat/vB

3 min

LND v0.21.5-beta.rc1 introduces ceilings on external fee estimates to reduce wallet risk and fixes a native SQL connection-pool deadlock. The build is a pre-release and requires no database migration. Verification confirms download integrity; operators still need deployment-focused testing.

TL;DR

Published build: v0.21.5-beta.rc1 pre-release.
Fee inputs from an external API now have an upper bound and bounded minimum relay value.
Binary verification differs from testing node behavior in real configurations.

Remote fee estimates now have enforced limits

The release notes state that external fee estimates previously had a lower bound without an upper bound. The change applies a ceiling of 10,000 satoshis per virtual byte and bounds the API’s minimum-relay estimate. The ceiling acts as an extreme-value guardrail. It does not indicate that such a fee is normal or economical under current network conditions.

Fee estimates serve as inputs to decisions. An external service can return unusable values due to errors, format changes or compromised dependencies. Bounding the input limits how an upstream issue can influence a wallet. The broader operational point aligns with Bitcoin Core’s revised disclosure process: money-handling software needs methods to find problems and pathways to deploy fixes.

Pre-release status and the need for deployment evidence

The GitHub release page identifies the build as a pre-release and notes no database migration is required. It provides signatures and binary-verification steps. These confirm what was downloaded. They do not demonstrate behavior across all node configurations.

The notes document a native SQL connection-pool deadlock fix. Node reliability depends on storage behavior and network communication. A process that stays running while requests stop completing still fails dependent applications. Testing should cover actual service work: receiving requests, accessing storage, handling failures and restarting cleanly. The absence of a migration removes one change category but does not prove every interaction with existing data is unchanged.

Operational responsibilities for payment providers differ from custody controls described in shared-key Bitcoin lending. Keeping signing authority secure and keeping a payment node functioning are distinct. This also explains why custody and recovery arrangements cannot replace software maintenance. The candidate provides specific changes to evaluate. Final release and operator deployment decisions remain separate steps.