Inbound fees: clarification

[SunnySarahNode]

I know the answer is already somewhere nearby, so I'm sorry for asking : )
Very quick question.

Is it possible for me to lose some sats if my outbound fee in the channel is lower that my peer's inbound fee in the same channel?

In other words. I have a channel and set my outbound ("normal") fee as 200 ppm in this channel. My peer set his inbound fee as 300 ppm in the same channel. Does it mean that I lose 100 sats if I send 1M sats to my peer in this channel?

[bitromortac]

By "sending", do you mean to forward, or making a payment to your peer? What do you mean by "losing", paying a fee? And the 300 ppm you mention are positive or negative (inbound fee discount)?

In general, inbound fees are computed by looking at the incoming edge's inbound fee policy and the outgoing edge's outbound fee policy and negative inbound fees are capped such that they are not allowed to be more negative than the outbound fee, for a routing node to not lose money when forwarding.

[SunnySarahNode]

I should have asked more clearly, sorry. I mean the situation when I forward some sats (my node is a part of the route) and the next hop of the route (after me) has a big (for example, VERY big) positive inbound fee in our channel. Is there a chance I will lose sats? Who exactly will pay this (very big) fee?

So, is there any chance to lose sats for routing node in any scenario with any fees (inbound or outbound, positive and negative)?

[ViktorTigerstrom]

As the forwarding node, there's no risk that you'll lose sats for the forwarding the HTLC, regardless of if the next node in the path has set any inbound fees for the channel or not.

So, is there any chance to lose sats for routing node in any scenario with any fees (inbound or outbound, positive and negative)?

The only scenario where you might "lose" sats is if you, as the routing node, have set negative inbound fees for the channel over which the HTLC is forwarded to you. By definition, setting negative inbound fees means offering a discount on fees when forwarding an HTLC through that channel.

In some sense, you could count this discounted fee as "losing" sats because it reduces the effective fee you charge for forwarding the HTLC to the next channel. However, as @bitromortac explained, there’s no scenario where you would actively lose sats in the sense of forwarding more sats than you received (e.g., receiving 1,000 sats and forwarding 1,100 sats). The cap ensures that won't happen.

Who exactly will pay this (very big) fee?

So to clarify, the actual fees payed in the route is always specified by the sender of the payment, and pays the fees incurred along the route.
Let's imagine the following scenario:

A -> B -> C -> D

Say A is sending payment of 1000 sats to D.
In this scenario, B will charge an outbound fee of 10 sats for forwarding the HTLC over the channel to C.
C will also charge an outbound fee of 10 sats for forwarding the HTLC over the channel to D.
C has a negative inbound fee for the channel to B, amounting to 5 sats in this scenario.

When constructing the payment A will ensure that:
B Gets forwarded an HTLC of 1015 sats
C Gets forwarded an HTLC of 1005 sats
D Gets forwarded an HTLC of 1000 sats

When B receives the 1015 HTLC, B will check that the difference in HTLC that B should forward of 1005 sats to C (1015-1005=10), is >= than the expected 10 sats outbound fee B charges for that channel.

When C receives the 1005 HTLC, C will check that the difference in HTLC that C should forward of 1000 sats to C (1005-1000=5), is >= than 10 sats outbound fee C charges for the channel to D - sum of the 5 sats negative inbound fees discounted for the channel to B (10-5=5).

So to summarize, when forwarding the HTLC, all you as the forwarding node care about is that the amount you received - amount you forward, is >= then the fee your expecting, given that the cap that @bitromortac mentioned is upheld.

Hope that clarifies it for you!

[SunnySarahNode]

@ViktorTigerstrom, thanks for the very detailed explanation. this looks like it should be in some documentation as an example!

[ViktorTigerstrom]

Thanks @SunnySarahNode! Sorry, confused the terminology in the answer above. When I referred to positive inbound fees, I ment negative inbound fees.

I will update my answer above so that it's correct. The logic checks on B & D still applies though, regardless of if it's positive or negative fees (just that C would flip the value for the inbound fee). Obviously A would need to send more sats if C actually was charging positive inbound fees though :).