5satoshi is one of the first core-lightning nodes that is operating since spring 2019, first setup for experimental purposes. With growing experience, we developed it to a mid scale routing node aiming for alternative configurations different from the big central routing nodes.
Our goal is to find a configuration, that allows low budget node operators to setup a profitable mid size routing node, with a low routing local failure rate.
Peer connection and channel creation we manage with the services of lightningnetwork.plus.
Technically we consider summer 2022 as the starting point for our routing node activities. Starting with a first phase to evaluate our positioning in the network topology. In this phase routing fees are set to a minimum of 1 ppm to attract maximum traffic with zerobasefee. Lower liquidity channels only have a ppm higher fee.
Current number of channels and the fees looks as follows. We show the fee distribution across our channels and who opened the channel (remote or local). You’d expect remotely opened channels to have a higher risk for lacking outbound liquidity, which is leading to higher ppm fees.
Both information are publicly available and shared amongst the nodes. More details can be found in established lightning node explorers:
Re-balancing strategies can be expensive and time consuming, while the value for the network is limited. Especially loop-outs remove liquidity from the network, when the loop-out node is closing depleted channels. But also re-balance transactions from on channel to another of the same node do not improve the overall network capabilities. Instead, it moves liquidity to more expensive routes, which leads to a negative impact by higher fees for the lightning users.
With that said, we at 5satoshi follow a no-re-balancing policy. Each channel is left alone breathing with its own frequency. Fast depleting channels, that do not organically refill, we consider of no value, unless you can cover channel opening and closing cost with the fees earned by the depletion.
So, doing local channel openings as swaps with lightningnetwork.plus and no liquidity balance management leads us to the following inbound and outbound figures:
Now, let’s have look at the number of payments we’ve routed through our node over time. We’re displaying two interesting metrics, the long-term trend, showing the last year per month and the short term trend, each day of the last 6 weeks.
Another important information is to understand the amount of routed payments. We’re presenting two kinds of insights. The first is showing the distribution of payment amounts, the second the evolution of the avarage payment amount over time.
How do the activity numbers of our node compare to the overall network, how are we doing? We’re trying to bring more light into that by looking at the total network graph, with all its channels and routing fees.
It’s possible to calculate the share of ‚cheapest‘ (shortest) paths per node a transaction is optimally taking through the network. This calculation is dependent on the size of the transaction. We’re presenting the share of our node for a common transaction (50,000sat), a micro transaction (200sat) and a macro transaction (4,000,000sat). Also we show, how this share was changing over time for common transactions.
What can be analyzed are the timestamps of transaction requests hitting the node. If we put the timesamps for the received routing requests of the last 8 weeks with our Lightning node in a weekly heatmap, we get the following overview in Coordinated Universal Time (UTC).