ain
ain copied to clipboard
Automatic Setting of Negative Interest
Summary
- Set the negative interest rate automatically.
- Introduces a new RPC call to estimate the negative interest rate.
RPCs
- New estimatenegativeinterest RPC call
defi-cli estimatenegativeinterest
{
"dusdBurned": 2463205.39186885,
"dusdLoaned": 94262062.35901081,
"negativeInterest": -15.88792800
}
Implications
-
Storage
- [ ] Database reindex required
- [ ] Database reindex optional
- [ ] Database reindex not required
- [x] None
-
Consensus
- [x] Network upgrade required
- [ ] Includes backward compatible changes
- [ ] Includes consensus workarounds
- [ ] Includes consensus refactors
- [ ] None
IMHO this way of doing it can not work and should not be merged.
The goal is to payout half of the stabilization fee. It is currently done as a workaround manually by setting the interest rate of DUSD negatively. The workaround is done via averages and max values cause of the limitations of the manualy workaround.
Originally this was defined to be payed out to the address of the loan holder, the same way we currently pay commission. so its kind of a "special commission" and every dusd loan holder automatically holds the LP-token for it. But since ppl are now used to the negative-interest way, which allows for looped vaults etc. I understand if we keep the payout to be done via negative interest rates. But keep in mind that this is not correct and can never be more than an estimation of the real payout.
If the goal of this PR is to stop the need for manual setting of values, keep in mind that this will be in the code forever. I am not sure if its worth it to add such code and the according risk and maintenance need. Specially since this will not remove the need for manual updates. Cause we will still have the basefee itself to be set (based on algo ratio), the discount fee (based on DUSD price) and once activated: the real dynamic interest (also based on DUSD price).
If we decide to accept that, we still need to rework this IMHO:
do not base calculations on time because of the workaround. (In theory it would be best to just distribute the burn directly, even if we do it via negative interest rates. But I understand that users are now used to small volatility which would change if we go from average to daily direct update)
We now have an additional discount fee, which "messes" this calculation up:
The DUSD fee is now the combination of basefee
and discount fee
(DUSDFee = BaseFee + DiscountFee
)
BaseFee is the stabilization fee which is based on the algo ratio, currently set to a fixed value of 30%. half of the DUSD burned via this fee is supposed to be distributed to loan holders
DiscountFee is an additional fee which is burned completely. this fee is set based on the DUSD price in the stablecoin pools.
So IF we want to go forward with this PR, we need to add parameters telling the chain how much of the current fee should be distributed in payout. and the node summing it up accordingly.