LND release candidate caps external fee estimates at 10,000 satoshis per vbyte

2 min

LND’s v0.21.5-beta.rc1 focuses on risk controls for external fee estimates and reliability fixes. The build is a pre-release and introduces guardrails on remote fee data that influence wallet behavior.

TL;DR

v0.21.5-beta.rc1 is a pre-release build.
A new ceiling caps extreme external fee estimates.
Verification proves download integrity; testing proves runtime behavior.

External fee inputs need ceilings before they reach the wallet

The release notes report that external fee estimates previously had a lower bound without an upper bound. The fix constrains the value before it can affect fee-sensitive wallet operations.

The change sets a ceiling of 10,000 satoshis per virtual byte and also bounds the API’s minimum-relay estimate. The ceiling acts as an extreme-value guardrail. It does not imply that such a fee is usual or required by current network conditions.

A fee estimate is an input to a decision. A service can return unusable values due to errors, format changes, or a compromised dependency. Bounding inputs reduces how upstream faults can influence a wallet.

This aligns with the need, highlighted by Bitcoin Core’s revised disclosure process, for both effective issue discovery and timely deployment of fixes in money-handling software.

Pre-release status requires environment-specific testing

The GitHub release page marks the build as a pre-release and notes no database migration. Instructions for signatures and binary verification confirm what was downloaded but do not demonstrate behavior across node configurations.

The notes include a native SQL connection-pool deadlock fix. Node reliability depends on storage as well as networking. A running process can still fail dependent applications if requests stop completing.

Testing should cover real workloads: receiving requests, accessing storage, handling failures, and restarting cleanly. The absence of a migration removes one change category but does not guarantee unchanged interactions with existing data.

Operational reliability is separate from custody design such as shared-key Bitcoin lending and custody and recovery arrangements. Custody controls do not replace software maintenance. This candidate provides specific changes to evaluate, while the final release decision and each operator’s deployment remain distinct steps.