Most of you are familiar with Ryan's "late-receipt penalty". By 2010-2012 this penalty was the full payment, but earlier back in 2006 it was continuous with a "late-receipt penalty rate" (mentioned on https://sourceforge.net/p/ripple/mailman/message/1307752/). The "late-receipt penalty" solves a "stuck decision" problem when finishing the payment, it enforces that each hop (from the seller towards the buyer) propagates the decision to finish the payment. But, the use of a continuous penalty (a "penalty rate") required a decision that could also get stuck, so Ryan abandoned that idea (but he did not abandon the "late-receipt penalty", instead he made the penalty the full payment. Interledger later by 2018 tried to "fix" the problem with the full payment penalty by reducing the size of the payment, but this is not the right approach).

The problem introduced with the "late-receipt penalty rate" (that it requires a decision that can get stuck) is solved with a "late-cancel penalty", that is also proportional to the same "penalty rate". This "late-cancel penalty" is the exact opposite of the "late-receipt penalty". The "late-receipt penalty" reduces the amount that can be finalized, whereas the "late-cancel penalty" reduces the amount that can be cancelled. While "late-receipt penalty" acts on whoever is at the end of the payment (thus at first the seller and then the next hop, etc), the "late-cancel penalty" acts on whoever is at the beginning of the payment (thus first the buyer and then next hop, etc).

The "late-receipt penalty" is a form of "continuous cancellation" (i.e., it reduces the amount that can be finalized), whereas the "late-cancel penalty" is a form of "continuous finalization" (i.e., it reduces the amount that can be cancelled).

The "late-receipt penalty" is used to finish the payment and the "late-cancel penalty" is used to start the payment.

Conveniently, the decision to go from the "continuous finalization" during the "late-cancel penalty" step to the "continuous cancellation" during the "late-receipt penalty" step, is naturally enforced as well (if that decision gets stuck, there is a net penalty on the person that caused it to get stuck).

These two penalty mechanism, the "late-receipt penalty" defined by Ryan 19 years ago and the "late-cancel penalty" defined by me this spring (does anyone know if it has been suggested by someone else earlier?) provides the incentive for true decentralized multi-hop payments. As what Ryan envisioned with Ripple Inter Server Protocol.

These two opposite penalty mechanisms work in every case except when the attacker is both the buyer and the seller (naturally). To also deter that scenario, fees have to be added on top of the payment (that are paid out to each person in the payment chain, in proportion to how long the payment got stuck).