What Are Negative Fees?
There are two types of fees that a lightning node can charge when routing a payment:
- Base fee: a flat fee charged for payment routed;
- Proportional fee: a fee that is a percentage of the amount being routed;
In the current state of the lightning network, these fees can only be either zero or a positive number.
This implies that when a node routes a payment, it receives some amount of money from the fees that it charges. It also means that the node that sent the payment has to take fees into consideration when making a payment. Let’s see an example:
Carol requests Alice to pay her 3 satoshis. Bob has a 1 satoshi base fee, and no proportional fee. Alice sends 4 satoshis in total, 3 for the payment to Carol and 1 for paying Bob’s base fee. Bob receives the coins, keeps one for himself as the fee, and sends 3 coins to Carol.
With negative fees, one would be able to set their node fees as negative numbers. This suggests that if a node has negative fees, it would forward more money than the amount it received. The node sending the payment gets a discount: he sends less money than the amount due and the node with negative fees tops up.
In this instance, Bob has a -1 base fee. Alice needs to send only 2 satoshis to Bob, and he’ll forward 3 satoshis to Carol.
Who would use Negative Fees?
The concept of negative fees is simple. But who would want to pay for routing a transaction? Why would anyone even use negative fees? The answer to these questions lies in a very common problem for routing nodes: channel depletion.
Channel depletion is what happens when a node exhausts its outbound liquidity and can’t send any more payments through a payment channel because all of the available liquidity is on the other side of the channel.
Currently, routing nodes can use circular rebalances for getting outbound liquidity back to a payment channel. A circular rebalance is a payment that a node does to itself that pushes outbound liquidity available in another channel to the depleted channel.
Although it solves the problem, circular rebalance has its issues.
- You have to pay fees for at least two forwards, so it can become expensive;
- Sometimes your node can’t find this circular path;
- Unbalances your peer’s channels;
But what if there was a way to incentivize nodes to send payments through your depleted channel so you can reuse your liquidity? This is where negative fees become extremely helpful. You could pay people to push liquidity!
Negative fees address the problem of channel depletion avoiding the issues that circular rebalancing causes. There’s no need to find a circular path to pay yourself, your peer’s nodes don’t get unbalanced, and you don’t have to pay fees for every peer in the circular path.
Routing nodes need to rebalance liquidity quite often, so negative fees would be pretty useful for them. But generally, any node that depletes its outbound capacity and wants to reuse that liquidity could use negative fees to rebalance the channel liquidity.
Another possible use case for negative fees is people trying to profit from rebalancing other’s people channels. They could send payment to themselves using routes that only have payment channels with negative fees. As the payment gets routed, it rebalances channels and in the end, he’ll end up with more money than he began with.
How do Negative Fees Affect the Lightning Network?
Although this seems like a good idea, there are lots of side effects to consider. To understand these consequences, let’s first think about the lifecycle of a payment channel that uses negative fees.
Initially, the payment channel would route payments normally, with positive fees set. Once the channel becomes depleted, the user would update the fee policy to use negative fees. After getting the liquidity back, he would update the policy again, this time setting positive fees. This cycle would repeat until the payment channel closes.
One possible issue for the user, in particular, is that if he forgets or is unable to update the fees back to positive numbers, he would lose his money. This is because people would still want to use the “discounted” payment channel and he would still be paying the fee for every payment that goes through that channel. Continually changing a channel’s fee policy could also leak information about when payments are being made on a specific channel, which is also not optimal for privacy reasons.
Every time a node updates the fee policy for a channel, it communicates the change to other nodes by broadcasting a message using the gossip protocol. With negative fees, more messages are going to be broadcasted, as nodes would change fees at least two times per lifecycle. So it’s expected that this feature will increase resource consumption for a lightning node, not only in terms of bandwidth but in computing resources as well, as it needs to transmit and receive more messages, and also update its channel graph.
Finally, let’s think about how negative fees could impact payment reliability:
Obviously, it is preferable to be paid to use a route than to pay to use a route. This means that users would prefer to pay through routes with negative fees over routes with regular fees. Consequently, the pathfinding algorithm would give preference to “discounted” routes.
But what if the node’s channel graph isn’t up to date, and it thinks that a route has a discount when in reality the node just didn’t receive the latest channel update message that changed the fee back to a positive number? Then the payment would fail as the amount sent won’t be enough to cover the fees plus the actual value of the transaction.
Therefore, negative fees could decrease payment reliability in the lightning network, as payments would fail more frequently. This is not all bad, since more payment failures mean more traffic in the network, which can enhance privacy, as it adds more noise to the network.
Current State of Development
As of today, there are no official proposals for implementing negative fees on the lighting network. Lisa Neigut is formalizing a proposal for fee rate cards, an alternative fee structure that could be used instead of the current base and proportional fees. With fee rate cards, the user specifies four different fee rates to be charged for routing a payment, depending on the available liquidity.
This means that the fee charged would be dynamically set based on how much liquidity you have available to be consumed. If you have the majority of the liquidity on your side, you could set a negative fee, to incentivize peers to use that payment channel and rebalance it. If you have a minority of the liquidity on your side, you could set a very high fee, to disincentivize people to use that route and unbalance the channel even more. Finally, if the liquidity is balanced you can charge the current market average price for using the payment channel.
Fee rate cards solve some of the side effects mentioned earlier: the fee policy won’t have to be constantly changing from positive to negative values through the lifecycle of a payment channel. This also implies less overhead on broadcasting channel updates and changing the channel graph regularly. This doesn’t solve the issue of payment unreliability, though. But you could choose to pay the higher fee rate if you need reliability.
Concluding
Negative fees allow a node to pay to forward a payment instead of charging to forward a payment. This feature would be extremely useful for routing nodes because they deal with channel depletion quite often, and circular rebalance – the current method of rebalancing a channel – has a lot of drawbacks.
It also creates an economic incentive for the network to rebalance naturally, as people would prefer to use routes that offer “discounts” and rebalance the payment channels as the payment gets routed, instead of having to pay to use a route. Someone could even profit by making payments to himself using routes with negative fees.
The challenge is how to implement negative fees because if no other changes are made and nodes gain the ability to set negative fees the network would suffer some consequences. We could expect an increase in the volume of gossip, as nodes would be constantly changing their fees as liquidity gets consumed and rebalanced. Nodes that are unable or forget to update the fee policy could also lose money if their fee is set to a negative value. Payments would fail more frequently because of the unevenly distributed information on fee policy on the network.
Finally, the fee rate cards proposal, by Lisa Neigut, addresses some of the problems mentioned above, by making fees dynamic, depending on how the liquidity is balanced on a channel. This is not yet a formal proposal, so it can still change. It’s also worth noting that the lightning network is open source, so other proposals can be made as well.
Get started today running your own or building with our Lightning Enterprise solution.
