How does the mechanism work?
Channel state is more than an informal balance display. The transaction construction gives participants ways to enforce their rights on chain, subject to protocol conditions and monitoring needs.
Capacity and usable liquidity differ. Sending depends on value being available in the needed direction. A routed payment also depends on a usable route and the conditions along it, so a channel with funds cannot guarantee every payment will succeed.
The signed-state model explains why channel operations require more than a balance display. Participants must agree on updates through the protocol, retain the information needed for enforcement and handle interrupted or failed payment attempts. A payment shown as in flight can affect available liquidity before the final result is known. Returning to the simplified allocation is useful, but only after identifying which contracts remain unresolved. When you read a channel diagram, ask what each participant can enforce if cooperation stops. That question connects off-chain convenience to the underlying transaction conditions without pretending that every update must wait for another block.
What would you see in an example?
Imagine you fund a channel and then send a payment through it. The balance available on your side decreases while the balance on the other side increases under a new signed state. That update does not require its own block entry. Later, settlement determines which base-chain outputs can be spent under the closing transaction.
How can the same funding support changing balances?
Consider an invented channel with capacity of 1,000,000 satoshis. To isolate balance arithmetic, ignore fees, reserves and in-flight payments. Let your side initially have 700,000 satoshis and the other side 300,000. A 100,000-satoshi payment shifts the simplified allocation to 600,000 and 400,000. The sum stays 1,000,000; no new bitcoin is issued by the update.
The protocol turns that conceptual allocation into enforceable transaction arrangements. In the basic funding construction, a 2-of-2 funding output requires both parties’ signatures. Commitment transactions provide ways to settle the channel under its rules. Exchanging a newer state involves a defined update sequence; changing an unsigned number on a screen does not update enforceable ownership.
A participant cannot assume that the entire headline capacity is available for every direction of payment. Local and remote allocations differ. Channel reserves, fees and unresolved contracts also affect usable amounts. The simplified example deliberately omits these deductions so you can see the conservation of value first, then understand why a real interface may show lower available liquidity.
Routed payments add conditional contracts and timelocks. A route needs liquidity in the required direction at each hop, not merely a large total somewhere in the network. Contracts connect revealing a payment secret with the ability to claim funds, while expiry conditions support recovery if the payment does not complete. The numbered protocol fields and ordering are specified by the channel documents linked below.
Common misunderstandings
An off-chain update does not mean there is no underlying chain enforcement. Funding establishes the anchor, and unilateral closure can depend on block-based delays and monitoring. State backups and correct protocol handling matter because old and current states have different consequences.
Channel capacity is not the same as your spendable balance, inbound liquidity or a guarantee of route success. A provider’s custodial balance can also conceal who controls the funding keys. Use the mechanism to ask precise questions about control rather than assuming that every Lightning-labelled interface implements the same custody arrangement.
Check yourself
In the simplified million-satoshi example, does moving 100,000 satoshis to the other side increase capacity?
Reveal the answer
No. The allocation changes while the total remains 1,000,000 satoshis. Real usable liquidity also accounts for fees, reserves and pending contracts.
What does this diagram leave out?
This diagram leaves out routing contracts, timelocks and dispute details. Monitoring, backups and software behaviour matter. A custodial payment account may hide channel operations from you while leaving a provider in control. Do not infer self-custody from the word Lightning alone. The lesson is a mechanism explanation, not instructions to fund a channel.
Which primary sources explain the rules?
Sources: Payment channel peer protocol; Payment channel transaction specification.