Author: Hover Labs, [email protected]
Created: 10/04/2021
Status: DRAFT
Overview
kUSD minted against an oven is charged an interest rate (currently set at 19.5%). This interest rate is adjustable by the protocol. When loans are repaid, interest is allocated to the developer fund (10%) and stability fund (90%).
The Developer Fund is meant to be a discretionary fund to reimburse, create or develop projects and integrations with Kolibri. The stability fund is meant to be a liquidator of last resort, who will help to liquidate underwater ovens (Oven’s whose collateral is worth less than the loan).
Lastly, the protocol has a Liquidity Pool, where users can pledge kUSD to be used in oven liquidations. This creates a pool of capital that is waiting to liquidate ovens.
Rationale
The Liquidity Pool is pretty large (495k kUSD as of 10/4/2021) and KIP-006 would likely cause it to grow since the Liquidity Pool will receive priority in liquidations. Additionally, we’ve seen healthy collateral ratios (an average of X%) and most liquidations are processed in seconds by private liquidators.
The stability fund is also large (148 kUSD as of 10/4/2021) and grows consistently. If KIP-009 passes, the savings pool will grow even faster, since accruals will happen continuously rather than at repayment time.
Some amount of fees from interest could be passed back to kUSD holders, in the form of a savings rate. This could encourage holding of kUSD. The rate would be adjustable with governance.
Implementation
The implementation of a savings rate pool would look very similar to the implementation of the Liquidity Pool contract. Users would deposit kUSD in the pool, and receive an LP token called ibkUSD (Interest Bearing kUSD). The LP tokens would be redeemable for a ratable share in the pool, and thus would grow in value as the pool accrued interest. Users could redeem their LP tokens for their underlying kUSD at any time.
The pool could keep a counter verifying the last time it accrued interest. When a new interaction with the pool occurs, the newly accrued interest could be calculated as:
let totalPoolBalance = …
let interestRatePerPeriod = self.data.interestRatePerPeriod
let lastInterestUpdateTime = self.data.lastInterestUpdateTime
# Calculate number of 60 periods elapsed
let numberOfInterestPeriods = floor((currentTime - lastInterestUpdateTime) / 60)
# Update period state
self.data.lastInterestUpdateTime = lastInterestUpdateTime + (numberOfInterestPeriods * 60)
# Accrue new interest via linear approximation
let newTotalBalance = totalPoolBalance * (1 + (numberOfInterestPeriods * interestRatePerPeriod))
let newlyAccruedInterest = newTotalBalance - totalPoolBalance
Like Kolibri, interest compounding would use linear approximation rather than pure exponentiation, as michelson does not have an exponentiation function.
To actually retrieve the interest, the pool would send a request to the stability fund. The stability fund would need to be updated to handle this request, and to privilege requests to the savings pool.
This does introduce some unique challenges however. If the savings pool requests more kUSD than the stability fund had, then the request to deposit or withdraw would fail. This requires the governable interest rate to be set very carefully (See below). However, A special entry point on the contract could let users withdraw their contributions and forfeit interest. It is very likely that in this scenario that the DAO would step in to make these users whole, lest they loose faith in the Kolibri protocol.
Initial Interest Rate
The stability fund will fund the savings rate, so in practice we must have a savings rate set as:
0 < savings rate < (stability fee * stability fund split)
Or in practice, with a 19.5% stability fee and 90% split:
0 < savings rate < 17.55%
However, we’d also like value to continue to accrue in the stability fund (to ensure that the protocol can cover black swan events) and interest is only accrued at repayment time, rather than at accrual time. This means that over the long run, the protocol will earn the stability fee in interest, but in the short term, returns will be more volatile (at least until / when KIP-009 passes).
The developers suggest a rate of 3% APY for the pool. This value is chosen to be safe in the worst case using the current state of the system:
- The current kUSD issued is 4.9M
- The current stability pool size is 1.48k
- All existing kUSD will be deposited into the pool
- KIP-009 does not pass, and no existing kUSD is repaid and thus the stability fund will not accrue any interest
After one year, the protocol will need to pay out 147k kUSD (4.9M * 1.03). This obligation can be covered by the stability fund today and means the protocol would have one year before it became insolvent.
In reality, this is a worst case scenario. It is likely that not all kUSD will end up in the pool, and that the protocol will receive interest. Additionally, the protocol can make adjustments prior to one year which will help maintain solvency if the above assumptions do not hold.
Lastly, KIP-009 suggests a feature where interest is paid at accrual time, rather than at repay time. This would theoretically bound the interest rate of the savings pool between 0% and the current stability fee.
Reference Implementation
A rollup and summary of the code to be deployed is here: https://github.com/Hover-Labs/kolibri-contracts/pull/20. The code contains unit tests, and a migration script which has been tested extensively on both the Kolibri Sandbox and testnet.
This code is deployed on testnet at Kolibri.
Stability Fund Multisig
As part of the migration, a new stability fund contract will be deployed. The governance lambda will move any value in the stability fund that exists at submission time. However, due to the delay between submitting a proposal and its execution, more value will accrue in the stability fund due to loans being repaid.
In order to mitigate this problem, we propose setting the governor of the old stability fund contract to a new multisig. After migration, holders of the multisig will agree to transfer any residual value to the new stability fund. We propose using a 2 of 3 multisig, with 0 second timelock, held by the following entities:
- yoursoulismine, Community Member, Discord moderator and Harbinger Poster operator - edpkvVfi9djFLdHaHwAJLygUDYYPsv3M7JhJxYZEGrWCi6y1Q8rEDG
- Gabe Cohen - Kolibri community member, Co-founder at Ecomint - edpktrq8HSok3LaMHuK17kn8yShsC5AQnpb4WKkYApQcHZNAsewt5B
- Keefer Taylor, Hover Labs - edpkuLh768382911CBbWkCN9joZkaZinKKeqPeMnxSoUb3X4TV7GpJ
In addition, the new stability fund contains a new entry point, sendAll, which transfers all value in the stability fund to a new location. This new entry point removes the need for a trusted multisig contract in the future.
Changlelog:
12/9 - Revised the reference implementation section to point to up to date code, and added information about the proposed multisig to transfer value.
)
!