Informal Poll: Guidance on Rates V2

Following up on this post from @Primoz, a few of us have been meeting for the past two weeks to try and come up with an evolution of the current rates paradigm. After discussing a few iterations we have found it is becoming increasingly difficult to pin down an exact, common formula for all asset types. Things such as the Base Rate made sense when we are only dealing with volatile crypto assets. Now that we have stablecoins, RWAs and farming tokens coming online, we need to have completely different mechanisms for determining the Stability Fee for each of these assets.

An idea that came up today was to move the process out of governance altogether. Instead of restricting ourselves to a rigid formula, governance could provide high-level, English instructions to the risk team such as “we want the Stability Fees on stablecoins to be 0%” which would then be factored into the weekly executive. This would give the risk team some flexibility to come up with whatever Stability Fees are most appropriate on an ongoing basis. This is not to imply that there will not be transparency of how these rates are determined by the risk team, but it frees them up to be more flexible with pricing novel assets such as farming tokens. MKR holders, as always, can veto any changes that come up.

I wanted to put up this poll to see if the community is okay with this shift in rate setting or if we should proceed with trying to evolve the current rates paradigm.

Note: This is an informal gauge of opinion. A more formal proposal will follow after this.

  • The Risk team should be given more autonomy to come up with Stability Fees
  • Evolve the Rates governance constructs to take new assets into account
  • Abstain

0 voters

6 Likes

Do you mean a [Poll]?

1 Like

Yes. LFW corrected it, thanks.

1 Like

I like the approach. We should be careful to vote for detailed enough specs, some debate on semantics after the code is written is the last thing we want.

Also execute votes should still contain detailed description of changes as an intermediary step between “governance high-level spec” and “read the spell code”.

Pretty sure I tried to warn people this would get to difficult in MCD for governance to deal with when the whole idea of Base Rate was proposed. I suggested at that time if any meta variables were used there still should be a list of all the changes for every variable. The reason was so people could look at what a meta variable change would do to everything in detail and quality assurance check make sure a meta change doesn’t do something to the underlying variables that was bad or had unintended consequences… The same suggestion still stands and is even more important in the context of what this poll is proposing against the general principle of bundling in executives.

A variation of this req
uest:

Coupled in with the above is a general idea that domains and domain leaders should not just be providing reports, but also ‘guidance’ in their areas of responsibility. Then reports and guidance a putt out for a community Quality assurance check as well as a RFC review mostly to catch any major gotchyas or things that a domain may have missed, as well as implications of one domains changes on another domain. I still am not seeing domain reports as well as guideance coming out in forum posts before a CC as this would likely shorten CC’s and allow for a focus on what needs to be discussed vs. just reviewing reports and guidance during a CC and then trying to talk about things without having time to review.

Easiest for governance is simply to say yes/no to some changes from a bandwidth point of view. But we rapidly are going to run our heads up against this bundling issue that @LongForWisdom has talked about for so long now. We are going to start to have so many changes going into executives that the likelihood of one addition in the bundle causes someone to vote no to the bundle grows. Worse is they will say yes because 15 things are desperately needed, and only 1 or 2 are bad, not so bad as to cause a voter to say no. So we build up garbage trying to pass needed stuff.

I also have concerns here that we will start to have an issue crop up where no-one is looking at executives in total, wondering if one domain groups change has implications against another groups changes. Hence once every domain group comes up with their reports and proposed changes, and everyone agrees. At that point ALL EPCs and domain groups then need to look at the total changes going into the upcoming executive to determine that nothing from anyone else has impact on their domain authority/reponsibilities and all of them give a thumbs up to the total executive as it is written.

I liken this to a software version release where 5 different groups are working on changes, but then these need to be merged into a version release and then each of those 5 groups needs to make sure nothing those other 4 groups did in the global version update breaks anything they were working on and was included in the update.

This can be overcome but it does take some forethought and implementing additional development/process steps to make sure things don’t get messed up.

2 Likes

This is a really interesting point to come to.

Base Rate, etc. was pretty nice but has been outgrown.

To put this “rate paradigm evolution” another way, temporarily delegate to the current risk team the responsibility to propose monetary policy to be executed by Maker Token Holder vote.

Temporary because in the future there will be more risk teams and possibly other relevant domain teams.

I don’t really think a single risk team should also take on proposing all monetary policy, but I have no doubt the current risk team would make excellent proposals.

If they want to do it (they may not, it’s a different role from risk assessments), I support delegating monetary proposals to the risk team with this strict requirement:

Monetary policy proposals are their own executive spells, not bundled with any other changes.

This means delegating the pace, but not the priority, so they should queue up a monetary policy executive spell when they think it is called for, but a separate governance process might need to decide when to fit it in (since at present only one target at a time is wanted).

Only if there is sufficient dissatisfaction with the risk team’s monetary policy would Maker Token Holders need to “provide high-level, English instructions to the risk team.”

I want to be fully transparent here that this idea didn’t come from me. We spent about 2 weeks drafting the formulas that would make rate setting governance as efficient as possible and solve some issues that are still in place. The idea was that the risk team regularly provides markups for each vault type on different classes of Base rate, depending on asset class that vault type fits in (i.e. crypto volatile assets would be using different Base rate as for instance stablecoins or RWA). The markup calculated by our team would be based on a formula that includes risk compensation and simultaneously aims to maximize fees based on the competitive landscape.

Although the Base rate setting simplifies the governance to some extent, in practice this means that governance still needs to perform few calculations with our proposed markups to determine what the final SF for each asset will be.

To illustrate, consider the current situation with stablecoins where we might use different markups for each type of stablecoins (some are more risky, some have higher market rates, etc). In such case governance needs to perform backward calculation using our inputs to determine how low it needs to set Base rate in case it wants to reach final 0% SF. It can get even more complicated when we start onboarding farm assets where SF is a function of farming yield and so on.

From that perspective it would be easier if governance gives us some guidance and we start proposing SF adjustments according to it. Although such approach probably scales better, I see few downsides or open questions:

  • Can a risk team get really proper guidance from governance with some high level instructions in words?

  • If we bundle proposed changes but some of them might not be preferred by governance, we might lose too much time repeating the weekly procedure.

  • Can we make sure that proposed SF changes are always communicated and well explained in a timely manner so that the community can evaluate our proposals before moving to the executive vote?

  • I am not sure if only one risk facilitator alone can do this job properly as:

    • we would ideally want to have more than two or three people generating proposals or concluding on final numbers proposed

    • this task might be very intensive and carries very high responsibility

    • our team is very small, most of new members consist of collateral evaluators

  • Risk team alone shouldn’t really be making proposals that are not related to risk but also include business or peg related decisions. The group which releases these proposals should ideally include also others non-risk focused members (either respected community members or other domain team members).

4 Likes

Yeah, we can’t just shovel all the responsibility onto the Risk team to set rates.

1 Like

Can confirm.

This is may be a good idea. We could elect a group to produce these weekly rather than having that group be the risk team.

1 Like

I’ve closed the poll, and put up the more formal proposal: [Signal Request] Rates V2

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.