Charge Interest

[ethanfrey]

We need to define a charge_interest method which is invoked by many other methods before performing other actions. Basically, it may return a Vec<CosmosMsg>, which we need to prepend on other actions. There may well be some issues of message ordering that come up (I assume this to be non-trivial), but I will define the basic behaviour:

• We define an epoch_size (in seconds) on instantiate, interest is charged this often. Only once per epoch, and for complete epochs. This let's us charge every 5 minutes and avoid per-second calculations.
• Before minting/burning B tokens or L tokens, we must charge any overdue interest to make sure they enter at the proper point (and pay all due interest, don't collect interest due to previous payments)
• Interest payments are define here: https://confio.slab.com/posts/lending-pool-aifto3zi#hf4qb-interest-payments

More technically,

• we define a last_charged on creation to be env.block.time.seconds() - env.block.time.seconds() % epoch_length. This is stored
• On a check, we calculate epochs_passed as (env.block.time.seconds() - last_charged) / epoch_length.
• If epochs_passed is 0, we do nothing
• Otherwise
  • We update last_charged += epochs_passed * epoch_length
  • Increase Btokens by ratio = calculate_interest() * epochs_passed * epoch_length / 31.556.736. ExecuteMsg::Rebase{ratio} on B-Token
  • Increase LTokens by l_ratio = b_supply() * ratio / l_supply(). Then ExecuteMsg::Rebase{ratio: l_ratio} on L-Token

Please bring up any questions... The actual deposit/withdraw etc are defined in base assets and will be adjusted by the new multiplier automatically if they are returned after the other messages from charge_interest

[uint]

So this method would produce zero or two CosmosMsgs? One to trigger BToken increase, one to trigger LToken increase? Or was there something else you had in mind with the Vec<CosmosMsg>?

[ethanfrey]

So this method would produce zero or two CosmosMsgs? One to trigger BToken increase, one to trigger LToken increase? Or was there something else you had in mind with the Vec<CosmosMsg>?

That is a correct understanding. I had nothing else in mind

[ethanfrey]

This requires #31 which is not yet merged. The logic is implemented but not yet tested.

Please either wait for that to merge, or base on top of that branch.

[ueco-jb]

I'm aware, I've created branch on top of his.