Hands-on · payment channels
Channel simulator
Imagine two friends sharing one notebook. A line in the notebook only counts if both of them sign it. They never call a notary for each line. They call once to open the notebook, and once to close it.
That is a payment channel. Below, you play both friends. You decide how much each puts in, you send payments in either direction, and you watch two counters: how many updates happened between you, and how many transactions had to touch the base chain.
- Fund it. Choose what Alice and Bob each lock in. Any numbers work, they are only examples.
- Open it. One on-chain transaction creates the shared account.
- Pay. Send either way as often as you like. Watch the update count climb.
- Close it. Both sign the final split. One more on-chain transaction pays it out.
L1 · Mechanics
The channel, live.
Every amount here is an editable example, in a small unit called a sat (one hundred millionth of a coin). Nothing is real, nothing leaves your browser.
What the two of you see
Solid cyan is Alice's share. Striped lilac is Bob's share.
Alice
0
Bob
0
- Channel state
- Not opened
- Off-chain updates
- 0
- On-chain transactions
- 0
Open a channel and send a few payments. This line will tell you how many separate on-chain transactions you would have needed otherwise.
Cooperative close: final settlement
- Alice receives
- 0
- Bob receives
- 0
- Off-chain updates
- 0
- On-chain transactions
- 0
Send payments
Inside one payment
- The sender proposes a new split and signs it.
- The receiver checks it, countersigns, and both agree.
- Both keep the new state and stop trusting the old one.
Close cooperatively
When you are done, both of you sign one last message that says where the money ended up. One on-chain transaction pays each side its share. It is the fastest, cheapest way out, and it needs both people to be around.
Event log
- readyNothing has happened yet. Open a channel to begin.
L2 · Fine print
Assumptions and edge cases.
This is a teaching model, so it leaves things out on purpose. Here is what it simplifies, and what real channels do about it.
- Fees are ignored. Real on-chain transactions cost fees, and real channels reserve a little for them. Here, the funding split is the whole story.
- Units are sats. A sat is one hundred millionth of a coin. The cap on total funding is the 21 million coin supply limit, expressed in sats. Bigger numbers are refused with a friendly message.
- Payments need both signatures. That is why the offline switch stops a payment. Nothing is lost, the old state simply stays in force.
- You cannot spend what your side does not hold. A channel moves value around inside its capacity. It never creates any.
- One-sided funding is allowed. If Alice funds all of it, Bob starts at zero and can only receive until Alice has paid him something.
Not simulated: disputes. If one person vanishes or tries to publish an out-of-date split, real channels have a way out. The honest side can publish its latest signed state alone, wait out a safety delay, and recover. Old states are made unsafe to publish by a revocation mechanism. This simulator only models the cooperative path.
Not simulated: routing. Real networks connect many channels so you can pay someone you share no channel with, by relaying through intermediaries with conditional payments. That adds liquidity questions this two-person model does not have.
Keyboard and reduced motion. Every control is reachable with Tab, and Enter sends or opens. If your system asks for reduced motion, packets do not fly. Instead each payment waits for you to press Next step through its three stages.