By Heath Muchena · Source review: 13 November 2026 · DN Lightning Direction Budget Record v1.0.0
What Matters
Owning bitcoin does not establish that the next Lightning payment can be sent or received. Direction, channel constraints, fee allowance and route evidence answer different questions.
- Keep local, remote, unsettled and pending-open observations separate.
- Compare one documented usable budget with one stated requirement.
- A favorable comparison is neither route approval nor settlement evidence.
The useful question is whether this task has a defensible budget
An AI agent paying for data needs more than a small invoice and an optimistic description of instant payments. Its operator needs to know which amount the agent is allowed to use, what that amount represents and how the payment outcome will be reviewed.
DN’s thesis is that Lightning adoption should start with a directional operating record. The record can expose a missing fee allowance or a gross balance mistaken for capacity without pretending to solve pathfinding. That is a practical decision aid for a buyer, merchant or operator considering an agent workflow.
1. Choose whether the agent is sending or receiving
Describe the task before looking at the balance. Is the agent paying for a data request, collecting an invoice, or forwarding somebody else’s payment? These activities can involve the same node while creating different operational needs. An account with funds is not automatically prepared for every direction of payment.
Lightning Labs distinguishes local and remote channel balances. Spending moves value toward the remote side; receiving moves it toward the local side. The channel’s initiator is a separate fact from where its current balances sit. [1]
For an agent that mainly buys services, the practical question is whether the intended outbound payment has an appropriate budget and route. For a merchant agent, the question is whether the intended receipt has appropriate inbound capacity. A routing business adds a different objective and operating model; this article does not estimate its profitability.
Write the direction next to the task, amount and intended counterparty in your private record. If one workflow both receives customer payments and pays suppliers, create separate records. Netting the two expected flows can conceal a timing problem: money that might arrive later does not establish the ability to make the next payment now.
The tool therefore starts with an unknown direction. Selecting “receive” also makes the send-fee field inactive, preserving its old text in the export without silently applying it to a different calculation.
2. Keep channel categories separate
A dashboard can present several useful numbers without making them interchangeable. Keep the original field name, scope and observation reference. “Balance” is an inadequate label when the record might concern a wallet, one channel, a collection of channels or funds involved in unfinished activity.
LND’s ChannelBalance response distinguishes local, remote, unsettled local/remote and pending-open local/remote amounts. Its older undifferentiated balance fields are marked deprecated. Those categories should survive the trip from the API response into an agent’s explanation. [2]
Consider an invented report with 100,000 sat labelled local and another amount labelled pending-open local. The worksheet does not add them to produce a payment budget. It also does not subtract one from the other, because the reader has not established the exact meaning, scope and relation of those observations.
The optional reference-balance field is deliberately passive. You can record one observed amount and classify it as local, remote, unsettled, pending-open or other. The calculation uses the separately entered budget. A reference balance cannot become “usable” merely because it occupies the largest box on the page.
When the source is a hosted wallet rather than a node you operate, keep the provider’s own terminology and applicable terms. This LND documentation example does not establish that every wallet exposes the same fields or gives its customer direct control over channels.
3. Explain how the usable budget was obtained
The most consequential input is the usable budget. It might be an operator allocation below a verified technical limit, or an amount derived from relevant implementation data. Either way, the derivation needs a record. A label is not enough.
Lightning Labs’ liquidity guide notes that local balance includes a reserve. LND’s current channel response separately exposes local and remote constraints, including a channel reserve and HTLC constraints. A raw balance is therefore not a universal formula for the largest payment that can be made. [1] [3]
The tool asks whether the budget is declared usable after applicable constraints, only a gross balance, or still unresolved. It also asks for a budget-evidence reference. These controls do not verify the derivation. They make the distinction visible so the next reviewer knows what is being asserted.
For a send record, enter a budget available to allocate to the payment and its separate routing-fee allowance. Do not subtract the allowance inside the budget and then subtract it again in the tool. If your operating system already reports a different net quantity, document the conversion into this worksheet’s convention before using it.
No universal reserve percentage is supplied here. The right deduction cannot be recovered from a marketing screenshot or inferred from another node’s configuration. If the usable basis is unknown, preserve the gross observation and leave the budget claim unresolved. A less complete record is more useful than a fabricated capacity figure.
4. Make the send-fee allowance explicit
A payment amount and the amount allocated to make that payment are different budget inputs. Keep the fee allowance visible even when it is small relative to the purchase. For repeated agent payments, a hidden assumption can be reproduced many times without anybody noticing it.
LND’s SendPaymentV2 documentation describes a routing-fee limit and warns that its default is zero sat. A zero limit restricts attempts to routes without fees; it is not a promise that all payments have no cost. This is a fact about that API, not a universal default for every wallet. [4]
The invented send example allocates 20,000 sat to the payment and 200 sat to fees, against a declared budget of 20,100 sat. The requirement is 20,200 sat and the entered budget is short by 100 sat. A separate 100,000-sat local-balance observation does not repair that specific budget comparison.
Blank fees remain unknown. If a 21,000-sat payment already exceeds a 20,000-sat budget, the tool can preserve that minimum shortfall while leaving the full requirement unknown. It does not invent a fee rate to complete the calculation.
The allowance is a planning input. This page does not write it into a wallet, enforce it, estimate the eventual fee or establish that a route exists within it. Record the actual configuration and observed fee separately when you review a real payment.
5. Do not turn a node total into a route guarantee
A favorable budget comparison answers a narrow arithmetic question. It does not show that the intended recipient can be reached. This matters when an agent reports “enough funds” as if it had already completed the route assessment.
Lightning Labs’ payment guide explains that payments traverse channels along a route, while the distribution of balances in other channels is not generally disclosed. Advertised capacity alone can therefore be insufficient to establish that the required directional balance is available along the path. [5]
Imagine two channels whose balances appear adequate in aggregate. The worksheet will not combine them into one guaranteed payment capacity. Nor will it decide whether a particular multipart payment can use them. Those questions depend on actual implementation behavior, route conditions and the destination.
Use the result language carefully. “The entered requirement is below the entered budget” is defensible. “The payment will succeed” adds a conclusion that the tool has not tested. A small positive margin cannot bridge that evidential gap.
DN’s agent payment protocol comparison addresses broader rail selection. This article stays inside a Lightning operating decision: what the available records can establish about a specified directional budget, before a real payment has been observed.
6. Separate an attempt from settlement
A workflow needs a way to explain what happened after it tried to pay. The budget worksheet is not that payment ledger. It should remain connected to the real record without being promoted into evidence of settlement.
The LND payment guide distinguishes dispatch time from total settlement time. Its monitoring discussion separates committing an HTLC along a route from settling it and updating balances. The API returns payment updates, rather than making the original budget estimate a receipt. [5] [4]
For a real case, retain the relevant payment or invoice identity, the implementation’s status, the observation time and the evidence that supports the final business conclusion. Keep sensitive identifiers in the appropriate private system; the public worksheet only needs local aliases.
A timeout, disconnected interface or missing notification should prompt a status investigation appropriate to the implementation. This article does not prescribe a retry sequence. Repeating a business request while its payment outcome is unresolved can create a separate accounting problem even when the liquidity calculation was correct.
Likewise, a successful payment record does not by itself show that a purchased API result was useful or accepted. DN’s cost of an agent buying an API call separates purchase costs from accepted outcomes. Keep the payment outcome and the service outcome as related, distinct records.
7. Budget for maintaining the operating position
A node that can perform the next task may still need work to remain useful over time. The recurring question is how its pattern of payments changes the direction in which capacity is needed. An agent that sends repeatedly and one that receives repeatedly do not create the same maintenance problem.
Lightning Labs describes rebalancing as moving liquidity between channels and notes that it takes time and incurs costs. Its guide also discusses replenishing inbound or outbound capacity according to the node’s purpose. [1]
For your operating budget, keep liquidity management separate from the fee allowance for a single payment. Relevant bills might include infrastructure, operational oversight or an applicable provider charge. Their inclusion depends on the setup; this article supplies no universal monthly figure or break-even promise.
Do not treat funds committed to an operating position as ordinary expense without explaining the accounting convention. A balance that remains owned, a service fee that has been spent and a temporarily restricted amount answer different financial questions. Combining them into one “Lightning cost” can distort both cash planning and performance reporting.
The worksheet intentionally covers one task rather than forecasting a month of traffic. If you reuse it, preserve each snapshot and the changes to the budget basis. A historical example should not automatically authorize another payment after the operating position has changed.
8. Keep evidence, authority and the next action distinct
The final check concerns what the agent is allowed to do with the finding. A record showing a budget shortfall does not authorize it to acquire liquidity, change peers, raise a fee limit, move bitcoin or alter a custody arrangement. Those are separate actions with separate consequences.
A useful review ends with a specific next question. Is the payment direction wrong? Is the amount in the wrong unit? Is the budget actually a gross balance? Is the send-fee allowance missing? Is the payment outcome still unresolved? Each question points to a different source of evidence.
The export keeps the raw inputs, normalized quantities, comparison, unresolved fields and example provenance. It does not contain a payment payload or a signing mandate. An explicit context mismatch remains visible even if the arithmetic happens to be favorable.
When several people operate the workflow, agree who owns the liquidity evidence, who can change the budget and who reconciles the service result. DN’s wallet authority register can support the permission part of that discussion. The budget record answers only the stated arithmetic and evidence questions.
The useful outcome is a bounded operational statement: “This declared send requirement is 100 sat above this entered budget,” or “The budget basis is unresolved.” Neither statement requires promoting Lightning as the inevitable currency of AI agents or claiming that a local worksheet has tested the network.
DN Lightning Direction Budget Record
Enter one direction and a separately documented usable budget. For a send record, the requirement is payment amount plus your explicit fee allowance. For a receive record, it is the amount compared with your declared receiving capacity. A reference balance never changes either calculation.
Use whole satoshi amounts. The budget convention and evidence declarations are yours; the instrument does not certify spendable or receivable capacity.
Start with unknowns or explicitly load an invented example. No assessment has run.
This instrument runs locally in the browser. It sends no entered values to an account, API or external service. The rest of the site remains subject to its privacy policy. Do not enter credentials, secrets or private personal records. The download preserves your raw inputs and their evidence limits.
Invented cases and bounded conclusions
These cases are authored to test record interpretation. They are not observed node balances, network fees or payment results.
| Case | Entered inputs | Bounded finding | Still unresolved |
|---|---|---|---|
| Send with allowance | 20,000 payment + 200 allowance; budget 20,100. | Requirement 20,200; budget minus requirement −100. | Actual capacity, route, fee and payment outcome. |
| Unknown send fee | 21,000 payment; budget 20,000; allowance blank. | Full requirement unknown; payment alone is 1,000 above budget. | The complete requirement and actual route outcome. |
| Receive equality | 15,000 payment; declared receiving budget 15,000. | Arithmetic equality, with a zero margin. | Whether that capacity is valid for the intended receipt and whether settlement occurs. |
Try changing the first example’s budget basis to “gross balance only.” The arithmetic remains visible, but the record stops applying it as a usable-budget finding. Change the observation declaration to a mismatch and the context issue remains visible even if the margin is positive.
Changing the fee allowance from blank to zero is a substantive declaration. It completes the arithmetic under a zero-fee assumption; it does not establish that a zero-fee route is available. The export records that distinction for the next reviewer.
Methodology and limits
For send records, required sat = payment sat + entered fee allowance sat. For receive records, required sat = payment sat. The margin is entered budget minus requirement. The receive calculation does not add sender routing fees or model separate receiver/provider charges.
Amounts are nonnegative whole-satoshi integers with up to 18 digits. This is the local worksheet’s input boundary, not a Lightning limit. Exact integer arithmetic avoids floating-point rounding; raw strings and normalized strings are both retained. Blank amounts are unknown, zero is known, and negative values, fractional satoshi and exponent notation are rejected.
When a send-fee allowance is unknown, the payment amount is a lower bound on the requirement under the permitted nonnegative-fee model. A known payment-only shortfall is reported without inventing the full total. Invalid active quantities suppress that bound. Optional reference-balance issues do not erase an independent payment calculation.
Scope and arithmetic are independent. A reader-declared context match needs the scope, observation and budget references. A usable-budget declaration is separate from a gross reference. Missing or mismatched context does not change subtraction; it limits what the subtraction can establish about the intended task.
The model does not derive reserves, aggregate channels, estimate fee rates, select paths, evaluate multipart payments, assess liquidity providers, issue invoices or send bitcoin. Route success and settlement remain “not assessed” in every record. A zero payment is not promoted into a successful operation.
Editing invalidates the previous result and its download. The download action also compares all current raw controls with the assessed snapshot. Clear removes the entries and example provenance. The JSON schema describes structure; it does not authenticate evidence or approve a payment. Review dates remain attached rather than being refreshed by a new download timestamp.
Frequently asked questions
Does a positive margin mean the payment will work?
No. It means the entered requirement is below the entered budget. The budget basis, route, implementation constraints, actual fee and outcome are not verified by this tool.
Can I use total channel capacity as the budget?
A total is a reference observation until you establish the usable directional basis. The worksheet deliberately performs no channel aggregation or automatic reserve deduction.
Why does a blank fee still allow a shortfall finding?
A payment already above the budget remains above it when a nonnegative fee is added. The full requirement stays unknown; only that lower-bound finding is preserved.
Why is the fee field inactive when receiving?
The receive mode compares the payment amount with declared receiving capacity. It does not apply the sender’s routing-fee allowance or model other receiver-side charges.
Does the tool support hosted Lightning wallets?
It can record your declared budget, but the LND examples do not establish a hosted wallet’s custody, limits or terms. Use the provider’s actual evidence and keep the basis explicit.
Primary sources
The source list establishes the stated documentation scope. It does not authenticate reader-entered records or certify a deployed system.
- Lightning Labs: Managing Liquidity on the Lightning Network — Local/remote direction, reserves and the cost of managing liquidity. It does not supply a universal maximum-payment formula.
- LND API: ChannelBalance — Separate local/remote, unsettled and pending-open balance categories; deprecated legacy fields.
- LND API: ListChannels and ChannelConstraints — Channel context, active state and local/remote constraints. No live node was queried.
- LND Router API: SendPaymentV2 — Implementation-specific routing-fee limit and streamed payment updates; not a fee quote.
- Lightning Labs: Sending Payments — Route uncertainty, dispatch versus settlement and monitoring. No route or payment was tested.
Resolve the operating assumptions before automating payments
For a documented comparison of payment workflows, budget assumptions or evidence gaps, explore the DN Research Desk. A useful brief identifies the intended task, implementation and unresolved decision. Scope and availability are agreed separately; an enquiry does not certify a route, wallet or investment.
Disclosure: this article promotes DN’s own research service. Commercial enquiries do not purchase a favorable conclusion. The instrument is educational decision support.
Related DN research
About the Author
