LND Caps Outside Fee Estimates at 10,000 Sat/vB. Here's Why That Number Matters

How much would you pay to move a transaction? If your node answers that by phoning a stranger, the ceiling on that stranger's answer just became the most interesting line in a release note.

LND pushed v0.21.5-beta.rc1 on October 22. It's a pre-release, not a final build, and per the notes it requires no database migration. Tucked into the changelog is a fix to fee estimation: values pulled from an external fee API used to get a lower bound without the matching upper bound. Now they get both.

The Fix, in Numbers

The ceiling is 10,000 satoshis per virtual byte. Put that somewhere you can feel it. A plain two-input, two-output transaction lands around 200 vbytes. Multiply through and you're authorizing 2,000,000 sats, or 0.02 BTC. At a six-figure bitcoin price that's a four-figure fee for a payment that might carry three figures.

That's the guardrail. The same change also bounds the minimum-relay estimate coming back from that API, which closes the opposite failure, where a bad value quietly strands a transaction instead of overpaying it.

Two bounds. One constant. Roughly forty lines of diff, if that.

Also in the build, and buried deeper: a fix for a native SQL connection-pool deadlock. That one probably matters more for uptime than the fee cap does, and it got a fraction of the attention.

Why a Remote Number Needs a Fence

A fee estimate isn't an instruction. It's an input to a decision. That distinction gets flattened constantly in infrastructure code, where whatever the remote service returns flows straight into the wallet path because the service is assumed honest and assumed correct.

Assumed is carrying a lot of weight in that sentence. An API returns junk for boring reasons. A schema change. A dependency compromised two levels up the stack. A cache serving values from a congestion spike that ended six hours ago. None of that requires an attacker. All of it ends with your node overpaying or your channel open sitting stuck in the mempool.

Bounding an external input is the cheapest defensive move in software. It's also the one teams skip, because the happy path never shows you the failure.

Sit with the 10,000 sat/vB number for a second. It isn't a claim that such a fee is reasonable. It isn't a description of network conditions. It's a threshold that says something upstream has clearly broken, stop listening to it. Publishing that as an explicit constant beats burying it in validation logic, because now an operator can reason about it and argue with it.

There's a process angle here too. Software that holds money needs two things working at once: a way to find problems, and a fast path for getting repairs into production. Bitcoin Core has been reworking the disclosure side of that equation. LND's job is the deployment side, and a bounded input is the cheapest version of a repair.

The Agentic Question

Now the part that should bother you more.

Wallets are getting a brain. Agentic payment flows, where a model picks the fee, picks the route, and decides when to retry, are being built right now on top of node software that treats a remote API's output as gospel within a generous range. If the AI can hold a wallet, who writes the risk model? Because at the moment, the answer is a fee oracle with a ceiling somebody else picked.

I've shipped enough ML to know how this goes. The model doesn't fail loudly. It fails by confidently doing the wrong thing at 3am while the dashboard stays green. An agent that trusts an unbounded fee input is a liability with a private key.

The intersection is real. Ninety percent of the projects aren't. The ones that will matter are the ones that treat the node's trust boundary as their own, not as somebody else's problem downstream.

And keep two threat models separate, because people keep merging them. Keeping signing authority secure is one job. Keeping a payment node alive and answering is a different job. Custody arrangements and insurance-backed recovery don't touch the second one. A process that stays running while its storage layer stops completing requests will fail every application depending on it, insurance or no insurance. Ask anyone who's run a routing node through a real congestion event and they'll tell you the same thing: the expensive failures are the quiet ones.

What to Watch

First, rc1 isn't final. There's no date attached to the stable build, so watch the release path rather than the tag.

Second, know which fee backend you're actually running. If your node leans on a local estimator, this change is largely inert for you. If it points at an external service, go verify the cap landed before you trust the upgrade.

Third, the test sequence that actually answers something. Regtest first. Then signet. Then a staging node with real storage and real connection counts, because "no database migration required" removes one category of risk and proves nothing about how existing data behaves under load. Watch the pool metrics after the SQL fix, not just whether the process stayed up.

Last, watch whether other implementations adopt a similar ceiling. If one node implementation caps external estimates and the rest don't, the cap is a local opinion about safety, not a property of the network. That's a gap worth closing, and it's a lot cheaper to close now than after an agent with a wallet and a bad oracle finds it for us.

The ceiling is a good default. The fact that it needed to exist at all is the story.