Using the latest commit of lnd-manageJ ( it is now possible to send transactions with reduced fees if one of the hops along one of the paths includes negative inbound fees. I tested this by topping-up the channel from to my test node lnd v0.18.0-beta.rc1 (
The route taken:>Kraken 🐙⚡->ACINQ->lnd v0.18.0-beta.rc1->
  • Amount received: 227,943.000sat
  • Amount sent: 228,194.475sat
  • Fees paid: 251.475sat
Fee breakdown for the last (interesting) hop lnd v0.18.0-beta.rc1->
  • outbound fee 1,000ppm: 227,943sat / 1,000,000 * 1,000 = 227.943sat
  • incoming fee from ACINQ is -500ppm: (227,943sat + 227.943sat) / 1,000,000 * -500 = -114.0854715sat
  • total fee: 227.943sat - 114.0854715sat = 113.8575285sat
This is rounded to 113,858msat, which the forwarding node lnd v0.18.0-beta.rc1 happily accepted! Interestingly, this corresponds to a fee rate of around 499.5ppm, even less than "outbound + inbound" (1,000ppm - 500ppm), because the inbound fee is also applied to outbound fees (227.943sat in this case).
Note that this is possible even if the sending node does NOT run lnd v0.18, as lnd-manageJ is smart enough to extract the necessary data itself. However, due to the complexities of path finding (#PickhardtPayments), negative inbound fees are NOT used when finding (cheap) routes using lnd-manageJ. As such, this can only make actual payments cheaper, without having any effect on how to find cheap routes.
0 sats \ 1 reply \ @OT 4 May
Why would someone do negative inbound fees?
Amazing! This makes a lot of sense.
Just thinking, what would it be like if everyone starts taking this route.
It should happen automatically once enough nodes upgrade, set their fees, and implementations tweak their pathfinding algorithms. I think lnd has already done it, so we just have to wait a bit.
Is lndg compatible?
I don't know lndg.