Introduction
If you run a Lightning Node, you will notice after some time that there is a shift of your balance between the Local Balance and the Remote Balance at single channels.
This shift results from the own node being used by other nodes to route payments.
This article describes how to analyse the transactions that are routed via your own node and how to operate a successful Lightning Channel Management and Rebalancing.
How to adjust fees to earn a few satoshis from it because your node is used as a routing node by other peers.
How to rebalance and optimize your different channels to get your channels well balanced.
That there is always enough outbound liquidity with the channels that are heavily used as outbound channels and allow us to generate revenue.
Table of contents
- Lightning Liquidity
- Inbound and Outbound Liquidity
- Opening a channel to another peer
- Shift between Local Balance and Remote Balance
- Routing Node
- Analysis of routed Lightning transactions
- What is a routing fee?
- Routing Fee Analysis
- How to determine your own routing fee?
- Change routing fees
- Earn a few sats as a routing node
- Rebalancing
- Rebalancing per RTL
- Rebalancing Successful
- Conclusion
Lightning Liquidity
Inbound and Outbound Liquidity
To operate your own Lightning Node you need liquidity, to send Lightning payments you need outbound liquidity and to receive Lightning payments you need inbound liquidity.
- Send payments ==>Outbound Liquidity – My Balance – Local Balance
- Receive payments ==> Inbound liquidity – (Foreign) balance of the other node – Remote balance
Outbound liquidity can be generated by opening a channel to another peer and providing an amount to the channel. Lightning payments can then be sent via this channel.
Inbound liquidity is obtained when another peer opens a channel to your Lightning Node and provides an amount from their side. Lightning payments can then be received via this channel.
The outbound liquidity is your balance and the inbound liquidity is the balance from the other nodes.
In order for you to receive inbound liquidity to receive Lightning payments, you should convince other Node to open a channel to you and provide liquidity.
When you make a payment, your outbound liquidity becomes inbound liquidity. When you receive a payment, your node’s inbound liquidity becomes outbound liquidity.
We have described in detail how to obtain corresponding Lightning liquidity in the article Lightning liquidity.
Opening a channel to another peer
It is recommended to have at least 8-10 channels to other nodes and the own node should have at least 5 million Satoshi.
We recommend a channel size of at least 1 million Satoshi. A channel opening of less than 500,000 sats is not recommended.
On-chain transaction fees are incurred when opening (and closing) a channel. These costs are to be recovered through the routing fee. With small channels, only microtransactions can be routed and the fees collected rarely lead to a refinancing of the channel opening costs.
With large channels, higher fees can be implemented, as higher amounts can also be routed via them.
When choosing channel partners, you should select some peers from your personal network. Here you can open channels to each other or participate in a Ring of Fire.
Additionally, you should connect to some peers that have a good connection within the Lightning network.
An overview of the most important and largest Lightning Nodes can be found at:
- BOS Score List: https://lightningwiki.net/bos/
- Terminal Web: https://terminal.lightning.engineering/#/
- Anvil: https://amboss.space/
There are nodes that have very high liquidity needs, such as Bitcoin exchanges. If you open channels to such peers and equip them with the appropriate local balance, then these nodes will suck your liquidity and will not send back any transactions themselves or close the channel to you.
How to behave as an owner with a lot of outbound liquidity towards the liquidity suckers and take advantage of an earning opportunity, we will describe a little later.
Shift between Local Balance and Remote Balance
So far we have talked about outbound liquidity and inbound liquidity. Outbound liquidity is the sum of our own Lightning credit on our entire Lightning Node.
The balance in a single channel is the Local Balance.
The sum of all Local Balance from our channels thus forms our Outbound Liquidity on our Node and corresponds to our Lightning Balance.
If we open a channel to another peer and put liquidity in the channel accordingly, the Local Balance in that channel will increase. If another peer opens a channel to our node and provides liquidity from their side, then this will show up as Remote Balance on our end.
Thus, with a new channel, there is liquidity on one side and nothing on the other. If you open a channel to another peer, you will find two channels in your overview, one side with 0 sats and the other side with 100% of the corresponding channel capacity.
It is currently not yet possible to open a joint channel in which both peers provide a corresponding amount.
If our own node has been running for some time, then the Local Balance and Remote Balance will shift. Depending on which payments we make or receive ourselves or if other peers route Lightning payments through our node.
Channel opening toanother peer
If you have opened a channel over 500k sats to Peer A, then you have a Local Balance of 500k. You can send a total of 500k through this channel.
If you then pay 300k via Peer A, your Local Balance decreases by 300k and your Remote Balance increases by 300k.
Likewise, your original outbound liquidity of 500k is reduced by 300k and is still 200k after that.
In return, your inbound liquidity or remote balance increases by 300k.
Channel opening fromanother peer to your node
If peer A opens a channel to you and provides 500k, then you can receive Lightning payments up to 500k through that peer.
After receiving a payment of 200k, you will have a Local Balance of 200k and a Remote Balance of 300k in this channel.
Routing Node
Analysis of routed Lightning transactions
We have learned that there are shifts in our various channels as a result of other peers routing transactions through our node. Using Ride the Lightning (RTL), we are now reviewing these transactions and with which peers our node is so popular and what is the reason for the appeal.
To do this, we go to the RTL backend:
Lightning => Routing => Routing Peers und finden dort die Anzeigeoptionen „Forwarding History“ und „Routing Peers“
In the “Forwarding History” we can find in a chronological order all transactions that were routed through our node.
In the Routing Peers view we get the number of transactions (Event) with the sum of the routed amount (Total Amount). Transactions are grouped into incoming peers and outgoing peers, respectively.
- Incoming = A payment comes in from this peer to our node
- Outgoing = The payment from our node goes out to this peer.
As a routing node, you earn a fee on outgoing transactions. Accordingly, it is worth taking a look at the forwarding history, as it shows how much you have earned on which channel.
Click on View Info to get detailed information about the routing transaction.
In the case below, we received 50,002 sats from the inbound peer Freedumbmoney and passed 50,001 sats to the outbound peer Coincharge.
The outgoing peer paid our specified fee of 1,050 mSats, which is slightly more than 1 sats.
What is a routing fee?
If other peers use your node to route their payments, you can earn a few satoshi as a routing peer. You earn the share that you have set as fees in your outgoing channel.
Let’s take a closer look at the fee structure of the following channel.
We have here the channel between Coinpages and the exchange Bitstamp about a capacity of 2 million Satoshi. Coinpages opened this channel and provided the 2 million Satoshi. At the time of channel opening, the Local Balance at Coinpages was correspondingly 2 million sats and the Remote Balance is 0 sats.
But let’s take a look at the outgoing fees, which have been set by the respective peer.
The Lightning transaction fees (routing fee) consist of a base fee and a percentage fee depending on the amount transferred.
The respective outgoing fees are displayed behind the respective peer as Base Fee and Fee Rate per Sat at 1ml.com.
The base fee is given in mSats and the default value is 1,000 mSats
The fee rate is expressed in ppm (parts per million) and means millionths or parts per million.
The default value for the fee rate is 1 ppm.
With a base fee of 1000mSat and 1 ppm, the RTL update fee policy looks like this:
Routing Fees are then calculated according to the formula:
Routing Fee = Base fee + Volume * Fee Rate
If the payment is two million satoshi, it would then read:
Routing Fee = 1.000 mSat + 2.000.000 Sat * 1/1.000.000
Routing Fee = 1 Sat + 2.000.000 Sat * 0,000001
Routing Fee = 1 Sat + 2 Sat
Routing Fee = 3 Sat
Routing fee would have to be paid at our node 3Sat for routing through this Lightning transaction.
These routing fees are borne by the payer. If a payment route is made via several peers (hops), a routing fee must be paid at each peer.
Accordingly, the payer will choose a route on which as few routing fees as possible have to be paid and at the same time enough liquidity is available to route this transaction as well.
To get a feeling for the routing fee, it is recommended to take a closer look at the channels of your own node. What fees do other peers charge to pass transactions to our node.
At https://amboss.space/ you can search for your own node and then you will get an overview of all your channels including the corresponding routing fees.
Likewise, it’s a good idea to take a closer look at a few other nodes and see what fees have been set.
Routing Fee Analysis
If you want to earn some satoshi as a routing node, you have to find out the nodes to which a lot of outflow goes via the outbound channel. To do this, we go back to the routing peers analysis under Lightning => routing and find the peers with the corresponding outgoing volumes.
The number of events shows you how often a transaction was made via your node and the total amount.
This also allows you to draw conclusions about the relationship between the number of transactions and the average transaction volume.
Search for the channels with the most transactions or the highest amount.
These channels should be looked at a little more closely, because these connections are where the potential lies to earn money from the routing fee.
When analyzing, one should ask the question, why is our node used for routing.
Is it the favorable conditions, the high liquidity or the good connection to other nodes?
Does your node tend to have many transactions with smaller volumes or few transactions with larger amounts?
The pre-set default setting is a base fee of 1000 mSats and 1 ppm. We can adjust these default settings to control the routing behavior on the particular channel according to our interest.
We have two fee components that have already influenced the routing behavior of our channel partners in the past. A low base fee is attractive for mictro transactions and a low fee rate is attractive for larger amounts.
Now it’s time to try out how to easily increase fees without losing its appeal in the routing network. Similarly, the transaction fee can also be reduced to make it more attractive.
The highest transaction volume usually flows to exchanges and trading venues such as: LNmarkets, Bitrefill, Bitfinex, Loop, Opennode and River Finance.
Higher volumes are deposited on an exchange and the transactions fee are rather secondary for the depositor. Since higher fees are tolerated, one should especially increase the volume-based fees and less the base fee per transaction.
If you have a lot of liquidity on local balances, you can make that liquidity available to the volume suckers mentioned above.
However, one should be aware that the exchanges will gladly accept volume from you, but will not send transactions back to you in return. It may happen that you suck the volume and even close the channel to you.
If you have a high level of liquidity, set high fees and ensure permanent liquidity with a well-managed rebalancing, you can generate attractive income.
If you have numerous small microtransactions, then you have certainly set a low base fee, because this is especially attractive for small amounts.
Smaller nodes and wallet operators (e.g. Wallet of Satoshi) tend to route lower volumes and can increase their attractiveness with low fees.
How to determine your own routing fee?
If you are unsure about the fees, you can also take a closer look at the fee structure of other routing nodes. If nodes have high fees to other nodes, then these are usually their important outbound channels.
For better understanding, let’s look at the channel between the peer flow with the lnmarkets exchange.
Those who want to learn more information about the channel can enter the Short Channel ID or the Channel ID in the search at 1ml.com and can view the fees for the channel between lnmarkets.com and Flow.
The outgoing fees of Flow are 0.890 sats as base fee and the fee rate per sat is 0.000009 (=0.09%).
The peer flow charges a low base fee and a high fee rate per sat for the amount.
It can therefore be assumed that high volumes will flow out to the stock exchange and accordingly the focus is on the volume fee.
The fees charged by Flow are very high and therefore it is clear that lnmarkets must be a significant outgoing peer for Flow, which can be earned accordingly.
The money is made on the high volumes that flow off to the liquidity suckers, but nothing will come back from their side.
Accordingly, you should build a lower fee structure to your other channel partners in order to increase your attractiveness or to optimally balance your liquidity on local balance and remote balance.
With your own fee policy, you need to find an optimal fee mix that allows you to earn a few Satoshi with a few volume channels and remain attractive with the other channels to transfer transactions back and forth on a regular basis.
For the channels you have opened to other nodes, you can use the following fees as a guide:
| Situation | Explanation | Base Fee | Fee Rate |
| Standard | preset default setting | 1000
|
1 |
| Default | Trying out and increasing your own attractiveness | 500
|
50 |
| Family & Friends | Connection with good friends | 100
|
10 |
| Exchange | Earn money on liquidity sucker | 50000
|
10000 |
| High remote balance | if your remote balance is very high and you want to prevent further outflows | 50000
|
10000 |
| High Local Balance | Earn money from microtransactions | 1000
|
50 |
In order for other nodes to route their transactions through you, you should provide attractive fees.
In order to route through your node, the following situations may occur:
- Another peer has opened a channel to you, but you have not opened a return channel in return.
- You want to get a balanced channel with a balance score of 1.
- You have a connection to a great peer, with high liquidity and a good BOS score.
Depending on whether you prefer many small transactions or high volumes, you can set the following fees:
| Situation | Explanation | Base Fee | Fee Rate |
| Micro transactions | Many transactions with smaller amounts | 500 | 1 |
| Macro transactions | Few transactions with high amounts | 1 | 50 |
These transaction fees are always to be understood as orientation and should be modified to the individual situation. Experiment with the charges a bit and observe how the routing behavior changes.
Dieser Empfehlung kommen wir mit unseren eigenen Nodes nach und haben deshalb die Base Fee auf 0 gesetzt und die Fee Rate auf 1000.
Eine Auflistung der Nodes, die sich zu #zerobasefee entschieden haben und die Hintergründe dazu findest Du in englischer Sprache auf: https://basefee.ln.rene-pickhardt.de/
Wer sich an #zerobasefee beteiligen möchte, der findet in der folgenden Tabelle eine Orientierung für die geänderte Gebührenstruktur.
| Situation | Explanation | Base Fee | Fee Rate |
| Standard | given default setting of LND | 1000
|
1 |
| Default | Coincharge Default Settings | 0
|
1000 |
| Family & Friends | Connection with good friends | 0
|
100 |
| Exchange | Earn money on liquidity sucker | 0
|
100000 |
| High remote balance | if your remote balance is very high and you want to prevent further outflows | 0
|
100000 |
| High Local Balance | Earn money from microtransactions | 0
|
500 |
Change routing fees
Wer seinen eigenen Node als Routing Node verwenden will, muss über Kanäle mit hoher Liquidität verfügen, die an entsprechend attraktiven Nodes angebunden sind.
After we have dealt with the fee structure, we check ourselves which outgoin fees are deposited with us or which fees our channel partners have set as fees to us.
The adjustment of the own outgoing fee is done by changing the own fee policy.
What fee our node charges and what fee charge when a Lightning transaction is passed to our node can be seen in the Peer/Channel overview.
There click on Actions and then you can check which fee the channel partner charges to his own peer and which fee you have deposited yourself:
- Remote Fee – The fee charged by the channel partner as an outgoing fee.
- Fee Policy – The fee we have set ourselves as the outgoing fee.
Earn a few sats as a routing node
Wir haben bereits erfahren, dass mit der Anbindung an Peers, die einen hohen Bedarf an Liquidität nachfragen, sich ein paar Sats verdienen lassen.
So far, we have charged the standard uniform fees (Base Fee 1000 and Fee Rate 1mSat), accordingly, the channels to the exchanges enjoyed great popularity.
The favorable conditions and the available volume has led to an immediate shift of the channels with the exchanges from Local Balance to Remote Balance.
In this specific case, we had opened a channel for the Bitfinex exchange and its two lightning nodes (bfx-lnd0 and bfx-lnd1) and placed corresponding liquidity in the channel.
Our low fees have caused our channel balances to shift immediately from Local Balance to Remote Balance.
In turn, however, there were no significant payments from Bitfinex to our node. Although Bitfinex has set very moderate fees as outgoing fees to our node, no payouts were made by Bitfinex through our nodes.
We do not have any influence on the fact that Bitfinex executes payments via the channel, so that a shift from Remote Balance to Local Balance takes place.
Thus, Bitfinex “sucked up” our liquidity and after that we lost our attractiveness.
Apparently there is a need for good channels to the two nodes of the Bitfinex exchange.
Therefore, we will drastically increase the fees to Bitfinex. First, to stop further transactions until we have provided new liquidity and to see if Lightning volumes are still routed through our channel with such high fees.
We set the transaction fee at a base fee of 9,998mSats and a fee rate of 600mSats (0.000600sat).
Now we have to provide new liquidity on the local balance. If we have an account on the Bitfinex exchange, we could have the funds there paid to us in Lightning. If the disbursement is made through our channel, then there would be a shift of the Remote Balance to our Local Balance.
Another possibility is that we use rebalancing to move unused local balance to the channel where local balance is needed.
Rebalancing
In rebalancing, we move Local Balance credit in one channel to another channel where it is needed.
When rebalancing, we make a Lightning payment to ourselves.
We transfer from a channel with a lot of local balance to a channel with little local balance.
| Local Balance | Outbound
(for outgoing payment) |
Send payments | My Lightning Credit |
| Remote Balance | Inbound
(for incoming payment) |
Receive payments | The Lightning credit of my channel partner |
Routing payments can unbalance our channel balance.
- Inbound transaction, increases our Local Balance
- Outbound transaction, reduces our Local Balance
Ideally, a channel should have a balance score of 1. If the value is lower (to 0), then we should balance the channel.
In the above case, we would take away from our Local Balance at lnmarkets and add to it at bfx-lnd0.
- In ==> wenig Local / viel Remote
- Out ==>much local / little remote
Rebalancing per RTL
We have noticed that we have a lot of Local Balance on the lnmarkets channel, but very little on the Bitfinex node bfx-lnd0 for that.
So we would like to move something from our Local Balance at lnmarkets to bfx-ld0.
We select the channel where we have “too much” Local Balance and select the sub-item “Circular Rebalance” under Actions.
There we enter the amount we want to transfer in the “Amount” field. We choose a smaller amount at the beginning, such as 100,000 Sat.
In the “Receive from Peer” field we select the peer where we want to increase the Local Balance. The designation is a bit unfortunate, but we select bfx-lnd0 here.
Then we click on “Estimate Fee” and are shown what fees we should expect.
Here we get a suggestion that we can adopt with “Use Estimate”.
By the way, the Estimate fee is displayed in mSats, but when you fill in the corresponding field, it is displayed in Sats.
Once again, the note that 1,000 mSats = 1 sats.
Instead of a fixed amount, you can also choose a percentage for the amount, such as 2%.
After that we click on Rebalance.
After that, in most cases, we get a notice that “Payment failed”.
This means that no route was found because:
- Insufficient liquidity available on the route
- The outgoing fees of the other peers are higher than the amount we were willing to pay.
Now we have to try and try with lower amounts or higher fees until it finally works.
There are several tools and analysis options to check what a route from my node to another peer might look like.
So we want to look at the route to the peer of bfx-lnd0 with the pubkey 033d8656219478701227199cbd6f670335c8d408a92ae88b962c49d4dc0e83e025
take a closer look.
Under Lightning => Transactions => Query Routes we can determine what the route to the peer bfx-lnd0 is by putting the above pubkey in the Destination Pubkey field and the amount we want to route in the Amount field.
We then get the following view:
Here we see the maximum amount that can be routed via the respective peer (capacity) and additionally the fee that would have to be paid to the respective outbound peer.
Wir sehen dabei, dass der Peer von BTCPay Billpay eine Fee von 200 mSats verlangt und mit dem Klick auf View Info erhalten wir weitere Informationen.
Unfortunately, it is not possible to draw a clear conclusion as to why the payment cannot be made in our specific case.
But it’s worth experimenting with different amounts to get a feel for how a Lightning route works.
Rebalancing Successful
After repeated trial and error, we finally managed a successful rebalancing.
However, we paid far too high a price for it. We paid a total of 87524 mSats, which is over 8 sats.
We will not be able to run a successful routing node with such fees for rebalancing. But it also shows which fees could be achieved by optimizing your own rebalancing.
So let’s take a look at how and where these fees were incurred.
To do this, we switch to the Transactions section and find all Lightning transactions there.
In the Payments section we can find our rebalancing transactions and by clicking on Show the detailed information.
We see that there were 3 attempts to find the optimal route. The HTLC 3 route has brought the desired success with a fee of 87 sats over a total of 5 hops.
RTL’s presentation and information options are unfortunately not very recommendable.
If you want to analyze routing and fees in more detail to achieve an optimal routing fee and balancing of your node, you should use an alternative software solution such as Balance of Satoshis (BOS for short).
Conclusion
To earn a few sats with your Lightning Node, it’s necessary to invest a lot of time with trial and error in addition to extensive liquidity in the beginning. Rebalancing in particular is a lengthy process because most attempts unfortunately fail.
But it equally points out that there is a need for liquidity and favorable fees.
A Lightning node is usually operated out of interest in Lightning and to contribute to the stability of the Lightning network.
Experimenting with lightning fees, rebalancing, and trying to balance your channels is definitely very educational, even if you don’t want to run a professional routing node yourself.
