Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic Setting of Negative Interest #2816

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Conversation

Bushstar
Copy link
Member

@Bushstar Bushstar commented Feb 7, 2024

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
    • None
  • Consensus

    • Network upgrade required
    • Includes backward compatible changes
    • Includes consensus workarounds
    • Includes consensus refactors
    • None

@kuegi
Copy link
Contributor

kuegi commented Mar 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants