Repository navigation
Inbound fees send support #3590
Description
Activity
We should probably see how things go with the new gossip - there's been some discussions to add this as a formal part of gossip in the new gossip format, and that discussion may inform us about what the arguments are for or against this going forward (and also might actually enable positive inbound fees, or maybe only positive inbound fees and not negative ones).
Can of course wait for that, but keep an eye on this in the mean time to make sure that not too many sats are left on the table.
Reacted by Matt CoralloEarlier exploration: #1942
- marked blip18 negative inbound fee support #4285 as a duplicate of this issue
on Dec 14, 2025 I'll add the link to my google sheet where I keep track of the current state of blip18 fees in the network
You can check the status of adoption in this sheet
At the time of writing, 40% of all public channels have the blip18 TLV stream set and 14% of the channels offer negative inbound fees.
Also, there is an open but ready to be merged ACINQ/eclair#3126 PR in eclair that would enable full blip18 support.
Reacted by feelancer21Nodes with at least one negative channel: 263 3.0%
Hmm, right, still relatively anemic adoption at the node level, though surprising to see more channels. Probably makes sense to include the actual negative fee itself (maybe also as a % of the mean/median fees on the node), if its small there's still not much incentive to do it still, if its larger maybe moreso.
Hmm, right, still relatively anemic adoption at the node level, though surprising to see more channels.
Over the last week I did 34'651 payments a total of 353 BTC.
In all my routes only 368 nodes appear. 30% of those nodes offer negative inbound fees.129 nodes cover 99% of my traffic. 40% of those nodes offer negative inbound fees
58 nodes cover 90% of my traffic. 44% of those nodes offer negative inbound fees.This is a pretty high correlation.
Probably makes sense to include the actual negative fee itself (maybe also as a % of the mean/median fees on the node), if its small there's still not much incentive to do it still, if its larger maybe moreso.
Median negative inbound fee was -402 ppm on the payments that included inbound fees for my node over the las 7 days.
And my node is in the worst possible position to take advantage of other nodes inbound fees, as my node is position at the lowest fee position in the network.
(in a position to offer negative inbound fees to everyone, but is a source to everyone)edit: added a column for average negative inbound fee per node
Will do median calculation laterRight, a node doing rebalancing (and thus strongly preferring cheap paths) is highly likely to select paths that have things like high negative fees. I'm not convinced that this is representative :). But it is interesting that this is as high for you, your neighborhood clearly has lots of inbound fees. Probably worth making sure this gets included in gossip v1.5.
I have a few more data points that might be of interest
My node has 2.8 BTC local liquidity.
I forwarded a total of 177.41 BTC over 48’657 transaction in the last 7 days.
Over 99.9% of those forwards made use of my offered inbound rebate.My node is intentionally positioned at the lowest point in the network so it con offer best possible fees to all my peers via inbound rebates.
It is not surprising that all my forwards make use of my inbound rebate.Nodes that do not support inbound fees have blind spots in the network. If they are looking for economically routes, thy can not go unnecessary downward in their paths as every unnecessary downward move means higher fees.
If you look at my scatter plot you see the 50 nodes with the highest traffic as measured by my node.
In red are the nodes that offer negative inbound fees. As you can see the deeper you go the higher the number of such nodes.I am also pretty sure that those nodes on the lower end of the graph will not show up on your paths very often. It would be very uneconomically for you to use them and that basically turns the whole lower half of the network into one big blind spot for all of LDK.
LND version 0.18 which was released on May 30, 2024 included support for negative inbound routing fees. This feature allows routing node operators to offer a discount for traffic that comes in through specific channels.
Background information:
Now that almost a year has passed since, it seems that there is some uptake of the feature by node operators. LDK ignores negative inbound fees and therefore senders using LDK are potentially overpaying.
To address just that, LDK would only need to get send support. Receive support is exclusively relevant to routing nodes.
Additionally, it is worth considering extending the rapid gossip sync protocol to become more flexible with regards to extra channel update parameters - for inbound fees and also for what else might be added going forward.
In the network, there are currently (Feb 2025) around 2000 channel ends for which the node on that end advertizes a non-zero inbound fee. For a list of those nodes and the number of inbound fee channels per node, see Inbound fees analysis - nodes.csv
For 95% of the channels, the base fee is set to zero with just a proportional inbound fee set. The proportional inbound fee distribution (non-zero, down to -20 basis points) is shown here: