[Signal Request] New IAM-vault-type for WBTC with lower LR

Governance Signal Requests
, ,
#1

Overview

We face the situation where people tend to be more optimistic about the market and are willing to pay more fees to have a lower liquidation ration. We see this with the ETH-B vault type that got proposed in July, implemented in October, reduced its DC by 50% in November because of inactivity and shortly after got IAM with a line of 50 MM and since then provides a good portion of the DAI-minted-from-ETH.

This Signal Request is about to find out the feelings of the community to start something similar with WBTC: a new Vault-type WBTC-B that allows for higher leverage with a lower LR a higher SF.

Pros

  • more DAI in circulation
  • more fees collected

Cons

  • a lower LR creates a bigger exposure WBTC volatility

Should we add WBTC-B as a vault option?

    • Yes
    • No (please explain in the comments)
    • Abstain

0 voters

How high should be the Stability Fee?

  • Let the Risk Team decide
  • 10 %
  • 8 %
  • 6 %
  • Abstain

0 voters

How high should be the initial line set? (Aka IAM-DC)

  • Let the Risk Team Decide
  • 30 MM
  • 20 MM
  • 10 MM
  • 5 MM

0 voters

Next Step

Poll will run until January 7th and depending on the result will move on-chain assuming the outcome of the poll deems it necessary.

3 Likes
Maker Relay Ep. 27 - en español (Feliz 2021)
Maker Relay Ep 27- Happy 2021
Collateral Status Index
Maker Relay Ep. 26 - en español
Maker Relay Ep. 26
#2

I Voted no. I think the DAO is still trying to understand the risk around WBTC, but long story short it could carry significant slippage risks especially considering that your exposure is in the $100MM ballpark. IMO the exposure should be left alone for the time being. There are also recently added BTC leveraging options to mitigate dc problems.

The particulars would need investigation based on what the community decides on but my gut feeling is the current exposure is risk enough until that investigation is done.

5 Likes
#3

I voted no because I think the volatility risk is too big and can’t be compensated just by increasing the SF.

ETH-B is already big enough to eat out stability buffer.

That’s mainly a gut feeling.

1 Like
#4

Well, we have to increase the surplus buffer then. We can’t keep resisting loan growth because our risk bandwidth is already eaten up.

3 Likes
#5

@ultraschuppi hey man did you consult with the B.Protocol Team and/or Risk Team – or you’re thrown it out there as a feeler with your own personal parameters?

1 Like
#6

I’ve voted yes with the assumption that the Risk Team will appropriately take into account the potential for an OSM-delay attack.

1 Like
#7

I agree with the questions from @ElProgreso. With B.Protocol already engaging the community on this exact type of vault structure (they even took the time to attend a community collateral call to explain their thoughts and get feedback), I think this signal request is premature. Obviously B.Protocol’s system will involve more scrutiny and more dev work so we shouldn’t be halting all similar proposals while that’s worked out, but it seems like this is just trying to dump a whole bunch of work into the SC team’s lap at a time when they clearly have enough on their plate. That coupled with there being a similar proposal that is taking the effort to go through our process, I think it would be premature to green light this poll and encourage community members to abstain or vote no.

3 Likes
#8

I just want to check out if people are ready for this step or if this is a crazy idea. Did not check anyone directly. Would also hope that risk chimes in here, not only for parameters but with a general pov

#9

I don’t think that this proposal and the BProject approach are conflicting, I guess this one cannot give the same amount of leverage as the other one

Don’t assume, it makes an ass of u and me :wink:

I just tried to start a debate - I am sure both risk and the SC are mature enough to push back in their own on a stupid idea if they see one

This is btw NOT a similar proposal as the Bprotocol one:
A) there is no additional 3rd party risk here
B) we don’t need to (partially) give away liquidation penalties
C) we onboarded -B-types before, this is (maybe naive here) basically configuration

That’s fine, I am not here to win, I am here to start a discussion. If this does not get enough support (and thanks all of you for the push back), this will clearly not move onchain

2 Likes
#10

Ooooh this is for the IAM!! Okay I misunderstood— unfortunately I have to change my vote to “No”

As a few others mention — IMO, I am more than happy to continue with ETH-B for now and see how well it works.

Hopefully the others who voted did understand the question correctly. Maybe you should put (IAM-ceiling) on the title like you did for the ETH-B signal request? Not sure if that would help…

2 Likes
#11

What are your metrics for determining the IAM “works well”? It’s pretty straightforward no? And I don’t think there’s much incentive at this point (if ever) to really exploit it. I hope we don’t wait too too long to harness this new power. Any way we can reduce governance overhead at low risk is a win in my book.

2 Likes
#12

fixed, better now?

1 Like
#13

IMO—80%+ utilization and no griefing attacks.

Yesssss—thank you Sir.

#14

I definitely owe you an apology here, fired off my comment hap haphazardly and didn’t mean to imply that you were bringing this proposal with bad faith. You proposed this because you think it is good for our system, and ultimately I agree with that, I just didn’t like that it went straight to a signal request. Sorry for being so careless with my words, I appreciate you and all your contributions.

I guess my frustration came from sitting on all the calls with B.Protocol, because this entire time they have been asking how to move their proposal forward, and were advised against creating a signal request so they went with an informal poll instead. I don’t like that this signal request gives the possibility of creating a vault with extremely similar CF parameters on the same asset in a quicker fashion.

To me, this accelerated timeline has a real possibility to beat B.Protocol to the punch and I don’t think that is fair. I think this should be considered a completing proposal, as otherwise the community will likely pass this one and all the work B.Protocol has done with rounding support will be a waste. I’m admittedly curious if others agree with this assesment, or if my bias for the B.Protocol idea is causing me to throw up road blocks where there shouldn’t be any. Either way, it’s clear that a more leveraged WBTC offering is desired by the community, so I think the discussion should center around how we do that safely. To me, B.Protocol’s idea makes a lot of sense from a risk management prospective as we would have committed liquidators, with a sizable backstop already deposited into our system. Currently, I’m not convinced we should be rolling out more leveraged options on our own platform without Liquidations 2.0 in place.

4 Likes
#15

Easier to ask for forgiveness than permission. I always advocate going straight to signal requests because then it’s real and can get real involvement. There’s more of a sense of urgency and then real debate can happen. I encourage you to try and change your mindset to be more action oriented so that we as a community can actually move forward instead of always talking in the hypothetical while others pass us by.

Edit: Signal requests should usually have 2 week minimum for discussion and MIPs (for bigger changes) have a month RFC phase for this reason.

#16

Well I just authored this post “Are we moving too fast?” so safe to say we’re coming at this from opposite perspectives. While it’s important to move fast, I would posit that a decentralized community is not set up to do so. Fundamentally, we are a slower moving origination compared to a traditional corporate hierarchy. I think that’s a good thing, but it’s incredible valuable to have community members push the sense of urgency. Personally, I’m willing to move as fast as responsible risk management dictates, and with our SC team having so much turnover I would argue we are already moving too fast for what we can handle.

#17

I voted no, although I am not necessarily opposed to it. Any new vault type like this should be treated like a new collateral onboarding from the Smart Contract team perspective, and would therefore bump the priority of some other token. I guess it’s worth some further analysis on whether we’d get more value out of this than from some of the other prospective collateral types in the prioritization framework. My knee-jerk reaction is that we are better off diversifying collateral types, for example, to Uniswap and Sushiswap LP tokens, which can provide a lot of new liquidity, instead of adding different flavors of old vault types.

7 Likes
#18

We see that as the market recognizes WBTC, WBTC has more and more liquidity and transactions. At present, the amount of DAI that WBTC can theoretically generate still has a lot of room for growth. Therefore, we can try to set WBTC-B to a smaller debt ceiling and lower the LR parameter to improve the competitiveness of WBTC assets.

#19

imvho both perspectives can be taken into account: move fast - for generating ideas - but pick your wars carefully. i would be more than happy to park an idea for some while (-> just put it into the backlog) and revisit once in a while.

I always had the (obviously naive) impression that adding another flavor for an existing collateral-type is just “a couple of lines in the exec” SC-wise and would be more a concern from the risk-perspective. thanks for clarifying @BrianMcMakerDAO

diversification wise: that makes total sense to me.

1 Like
#20

We do get the benefit of re-using the existing oracles here, but yeah, from our end it requires all the new contract deployments, authorizations, configurations, and oversight that a new collateral type would.

I hope that we can start using the new dss-exec-lib early next year, which will streamline the spellcrafting portion of the onboarding process, but I think this leaves an opportunity to automate the deployment of the ancillary contracts around collateral onboarding as well. I’ll add a ticket to the backlog.

9 Likes