• View
• Edit
• History
• Print
• Links
• Rename

OldInterestPage

The contents below are deprecated, but may still be of historical interest. At one point ripple project was going to be interest-aware, along the following lines.

Current plans

Since it is impossible to stop two mutually-consenting people from charging interest on each other's obligations, Ripple will acknowledge this by including an interest rate for each account partner so these can be formalized in the Ripple protocol. Interest charges will not be passed back along payment chains.

Note: The following is a discussion of how to pass interest charges fairly back along payment chains.

Tracking interest on accounts

To start with, nodes should be able to charge interest on balances owed by their neighbours. They should be able to declare the rate they will charge ahead of time to each neighbour so there are no surprises.

Interest on a balance has two parameters: rate and compounding period. To simplify things, always compound continuously (the difference in practice is usually negligible anyway). The rate is a little more complicated, each intermediary's interest charges may get passed back along the payment chain, but 1% compounded plus 2% compounded doesn't give 3% compounded over the same time!

This shows the need to keep a separate balance for each interest rate that is being charged on the account. And there may be many, as interest rates can pile up on a transaction.

Actual interest charges could be calculated on the average balances for each interest rate over a period and charged to the main balance at the end of the period.

For example, suppose A owes B 100: A's balance with B is -100. A's outstanding interest balances are -200 at 2%, -100 at 5%, and 50 at 3% (the latter interest is owed to him by B).

To give an example of how interest would be calculated in this situation, this measn that at the end of a month, A's balance adjustment for interest charges would be:

Passing interest back along the chain

Nodes must have the ability to pass interest charges back along a payment chain. Interest charges would be declared in the path-available message. Each rate charged would go in a list, with the principal it is being charged to, in transaction units. There could be repeats. For example, if three intermediaries charged 2% on the entire 1000-unit transaction, the list would look like: 2% on 1000, 2% on 1000, 2% on 1000. This could simplify to 2% on 3000 -- not 6% on 1000! This shows the need to keep balances for each interest rate separate from the main balance -- they are not the same.

Of course, any intermediary may report back any interest charges that it wants. Inflating the interest charges will only decrease the chance of that path being used. Nodes/implementations may also decide not to pass on interest charges for simplicity. Of course, this means they may end up paying for the privilege of being an intermediary, if other nodes are charging interest. They may also round off interest rates in order to simplify data storage.

The fact that balances for calculating interest are kept separate from the main account balance means that there may be interest charges even when the main balance is zero. But there is nothing preventing nodes from adopting strategies to minimize this effect.

A simple example is that I may owe my neighbour 100 at 5%, but generally charge her only 2% on balances owing to me. When the chance comes for her to send me IOUs, I may decide to charge her 5% specifically to zero out that 5% balance -- in other words, demand my outstanding IOUs at 5% back in payment. My neighbour will naturally pass that 5% down the chain, because presumatbly she charged it to defray charges from another of her neighbours during a transaction, and still needs to collect it somewhere.

A more complex example would involve weighted targetting of each outstanding interest balance based on the ratio of the payment amount to the overall main balance. Generally, adding these interest charges on to a through payment will make that path less appealing to the payer. Note that nodes may attach negative interest on a certain principal to a payment -- which would be interpreted as positive interest on a negative principal -- in order to make payment paths more appealing.

The simplest, and possibly the fairest, strategy, though, is to simply ignore existing interest charges on an account and treat each transaction independently.

In any event, to avoid getting "stuck" with a high interest chunk in perpetuity, nodes should be careful to accept transactions that only consist of comfortably low-interest chunks. This ensures that it will be possible and likely that interest charges will be wiped away by future transactions.

Releasing interest charges

Since each intermediary presumably passes back interest charges in order to defray their charges for participating in the payment chain, there ought to be a mechanism for indicating when the balance that originated the interest charge has been settled, and those charges no longer need to be defrayed. A message could be passed back up the payment chain that originally caused the interest charge informing each intermediary of its full or partial release. The message could take the form of a 0-unit payment with a negative balance for the appropriate interest rate.

Why would anybody voluntarily reduce the interest they are collecting? If one's neighbours are following the strategy of targetting high-interest balances to zero, it makes payment paths that cancel out their neighbours' obligations to them more attractive. It's also not nice to take advantage of your neighbours...

Exceeding credit limits

Interest charges may bring an account into overdraft. Deal with it.

Closing accounts

When an account is closed, no more interest charges may be collected, even if there are still some nonzero balances for some interest rates.

Addendum and comment on the notion of interest

It is proposed by this user (whos comments will likely be removed by system admin - ha) that compounding interest of any form is usury and morally should not be implemented. Also, interest creates a mathematical imbalance whereby the outstanding debt in a currency can never be repaid except by taking out more debt. The notion of applying interest to Hour balances when the previous statement is taken into consideration then just becomes silly.

Conflicts with simplicity and neighbourliness

It seems to make sense to provide an API so that plugins can be independently developed to cover charges etc. If this concept takes off, many will want to implement servers and nodes without making charges, and will prefer a system where these are not included by default. Others might see this as a commercial opportunity and charge commission where the endpoints of a chained transaction involving them are between non-neighbours. Let them do so and risk being undercut. If those keeping accounts with neighbours make charges or don't based on bilateral agreements, there is no need to complicate the protocol by making allowance for these. There will also be all kinds of unneccessary disagreements about the ethics etc. so why not keep this bit out of the main protocol and let those keeping accounts and servers apply third party charging modules based on an API that allows those favouring particular policies to program and implement these, and those disliking such policies to avoid neighbouring with charging nodes.

Treating interest as pseudo-currencies

Effectively, debt at a particular interest rate is almost in a separate currency with a predictable, gradually changing exchange rate.

• Basically, all debts at the same interest rate can be re-calculated to refer to the same base date.
  • Once they refer to the same date, they can be added together.
  • Example: If I borrow $100 at 3.5% today, it would instead be recorded as a loan of $78.82 (as of 2000); half a year later, I repay $101.77, which is converted to a repayment of $78.82 (as of 2000).
• All debts can be converted to a "current value" - the amount of money it would take to pay them off right now.
  • They can be set off against each other at the current value (even if they have different interest rates).
  • This is how they should be displayed to the user, regardless of how they're stored internally.
    • Continuing the above example, I will see the debt as "$100.00 at 3.5%" today and "$100.01 at 3.5%" tomorrow.
• Intermediary offers with interest would be treated similarly to offers of a different currency.
  • To charge interest on a plain dollar amount of $100, just say so and pass the rate along.
  • To charge interest on something that already has interest, simply add the two rates together.
    • 1% + 2% does in fact equal 3%.
      • This is because exp(q*t) * exp(r*t) = exp((q+r)*t).
      • In words, this means is that you're borrowing interest for the second person from the first.
• Apart from the predictable exchange rate, these would be currencies like any other, so they could do anything a currency can do - they could be loaned, used for payment, rippled, etc.
  • In practice, they probably wouldn't be used that way in general, but the concept helps designing the special cases where they are in fact used.
  • For instance, it answers the question of what happens when an account is closed: all the balances need to be zero first.

Notes:

• Instead of a fixed base date (such as 1.1.2000), the implementation could use a different base date at each calculation (obvious choices being "date of youngest debt" and "now"). That's just an implementation detail, though.
  • Theoretically identical, but leads to different kinds of rounding errors.