Intermediate nodes play a key role in the Lightning Network, allowing users to transact with others without opening a direct payment channel with each peer. Without intermediate nodes the Lightning Network would lose most of its appeal.

In our previous post we explained why routing payments unbalances the channels of intermediate nodes and how this leads to rebalancing. We defined rebalancing as the strategic action a node takes to increase their balance in a payment channel, at the expense of decreasing their balance in another one, to keep routing payments.

This post is an overview of the rebalancing strategies that are being talked about in the Lightning Network community.

To better understand this article, you should be familiar with the basics of payment channels and the Lightning Network. If you are not, we highly recommend reading this post first.


Carol is a node of the Lightning Network. She is connected to Alice and Bob, who want to transact with each other but do not have a direct payment channel. Carol routes payments between them acting as an intermediate node.

In order to route payments, Carol must have her channels funded in advance. Every time she routes a payment, her balance in the sender’s channel increases by the amount transacted, and her balance in the receiver’s channel decreases by the same amount, minus the fee she collects.

Routing payments tends to unbalance Carol’s channels and eventually she will have insufficient funds in a channel to route a payment. When that occurs, Carol will need to rebalance her channels.

Alice wants to pay 2 BTC to Bob but Carol can't route the payment. She needs to rebalance her channels.

Circular payments

Overview and Pros

Circular payments are a completely off-chain rebalancing strategy where a node makes a payment to itself across a circular path of chained payment channels. For the route to be circular, there should be at least 3 nodes involved.

Carol can make an anti-clockwise payment to herself using the closed path between Alice, Frank, Bob and herself.
A 1 BTC payment decreases her balance in her channel with Alice by 1 and increases her balance in the channel with Bob by 1. She can now route a 2 BTC payment from Alice to Bob.

Circular payments are a complete off-chain rebalancing strategy; meaning Carol can successfully rebalance her channels without broadcasting a single transaction to the blockchain. She doesn’t need to pay for on-chain fees or wait for confirmation times.

Carol can also control exactly when to rebalance. All she has to do is make a payment to herself in a favorable direction.


Circular payments are not free. Since there are at least three nodes involved, one being herself, Carol must pay at least two other nodes for routing her payment. The bigger the loop, the more nodes she has to pay.

Moreover, this strategy requires the existence of a circular and well funded route. Carol can make a payment only as big as the smallest balance involved in this route: her balance in channel C-A, Alice's balance in channel A-F, Frank’s balance in channel F-B and Bob's balance in channel B-C. This means the size of her rebalancing payment is capped by the route at the moment of rebalancing. The longer the route, the more chances of getting a smaller cap.

The requirement of finding a well funded route gets harder if Bob happens to be a merchant. In that case, Bob would receive far more money than he sends. Sooner or later, all nodes connected to him will have their channels exhausted, not just Carol. In that case, neither Carol nor other adjacent nodes, like Frank, will be able to find a circular and well funded route.

Finally, let’s analyze the impact of circular payments on the network's routing capacity, meaning the total amount of BTC a node can send to another one at a given moment.

To do this, let's introduce the concept of Atomic Multipath Payments. An AMP occurs when a payment is split into different paths, yet done atomically, meaning it is either done completely or not at all.

As soon as there is a circular path, Alice has two possible routes to pay Bob with an aggregated routing capacity.

Alice can pay Bob (R1 + R2) BTC. R1 and R2 are the routing capacity for the paths A-C-B and A-F-B, respectively.

Because circular payments only redistribute money within a closed path, the routing capacity between Alice and Bob remains unchanged. Although Carol has successfully increased her routing capacity, it was at the expense of Frank’s. Alice can still pay Bob the same amount of money.

Alice can still pay Bob (R1 + R2) BTC. (R1 + P) and (R2 - P) are the routing capacity for the paths A-C-B and A-F-B, respectively and P is the circular payment done by Carol.

Please notice that in these last examples, fees were omitted out of simplicity. By adding fees, the routing capacity is actually modified, but only in the order of magnitude of fees. This should (hopefully) be very small compared to the size of a payment, therefore the routing capacity remains the same for practical purposes.  

Fee management

Overview and Pros

Fee management is a completely off-chain rebalancing strategy by which a node uses fees as a mechanism to economically incentivize and capture payments going in a favorable direction. This could go from charging smaller fees than alternative paths, all the way to not charging fees at all, or even paying a small incentive (sometimes known as negative fees).

This strategy could be seen as a win-win scenario between Bob and Carol. He gets a discount on fees for using a particular path, while she rebalances her channels.

Fee management is off-chain, so there are no Bitcoin fees or downtimes involved. Also, if a mere discount is enough incentive for Bob to choose Carol's path, this strategy is potentially free of charge for Carol.


Fee management is actually, more of an opportunity than a deliberate strategy to tackle unbalanced channels. Carol cannot really control when rebalancing occurs, at best she can take advantage of a particular scenario and give an incentive to be chosen as the router of a certain payment.

This is a competitive strategy, and brings two big implications on the complexity of implementation.

Firstly, it requires Carol to have complete and updated information about the fee management of other nodes. Her fee is now dependent upon Frank's. At the same time, this strategy only works if Bob has complete information of the routing fees for each path. This could be a problem in a more private network, where nodes cannot access all data.

Secondly, it is unclear how much money this strategy might cost, since a mere discount could not be enough. For example, if Bob happens to be a merchant, most probably both Frank and Carol will want to route a payment going from Bob to Alice. Frank and Carol could then enter a race to the bottom behavior and reach the point of negative fees.

Finally, this rebalancing strategy does not solve the problem of poor routing capacity in the network. The starting scenario is exactly the opposite; a payment can follow at least two paths and a particular node can rebalance its channels from routing it.


Overview and Pros

Splicing is an on-chain rebalancing strategy where a node closes and reopens a payment channel in a single transaction, changing how much money it locks in it. A splice in occurs when the node re-opens the channel locking more money. If it locks less money, it’s called a splice out.

Carol closes her channel with Alice and opens a new one, committing 2 BTC. She now has 1 BTC unlocked.
Carol closes her channel with Bob and opens a new one, committing the extra BTC.

When using splices, Carol only needs to consider her adjacent nodes and can simply dismiss what happens in the rest of the network. There's no need for alternative routes, since it only involves the sender, the receiver and the intermediate node. This means splices could work in a poorly connected or poorly funded network.

Also, Carol only gets information about her adjacent nodes, and that is enough to decide when to rebalance. This is why splices are suitable for private networks.

Finally, it is easy to see that making a splice changes the routing capacity of the network, since a payment that was not possible to make before, can be made after rebalancing. This shows why splicing could work well even if Bob happens to be a merchant.

Before rebalancing, Alice can pay Bob following the route A-C-B with a routing capacity of 1.
After rebalancing, Alice can pay Bob following the route A-C-B with a routing capacity of 2.


Though splices are far more convenient than closing and re-opening channels in two different transactions they still involve broadcasting transactions to the blockchain, paying for on-chain fees and waiting for confirmation times.

Because of this, splices could be an expensive rebalancing strategy. In the bullish case for Bitcoin, on-chain fees have great chances of getting higher and this impacts directly on the costs of a node


Circular payments, fee management, and splices, are not excluding solutions and they will probably coexist in the Lightning Network. They work on different levels and in different network topologies.

Perhaps the most important difference is that splices can actually change the payment capacity of the network. Because of this, splices will probably need to be applied sooner or later.

Circular payments and fee management, on the other hand, will probably be applied as a strategy to delay splices. We will most likely see them happening once the network is better connected and better funded.

In the next post, we’ll take a closer look at splices, their costs, and how these impact on the routing fees.

Visit Muun Website:

Follow Muun on Twitter: