Forum Poll: Deciding the Peg Stabilization Modules Implementation Timeline

Over the past few days, there have been ongoing discussions on whether the Peg Stabilization Modules (PSM) should be proposed for implementation as an expedited measure or if the community should implement them after a more extended period of review.

In short, a PSM is very similar to using a stablecoin like USDC as collateral for Dai, except it enforces a price of 1 USDC per Dai directly in the market. This concept ultimately makes Dai significantly more liquid and stable.

The results of this poll may affect the speed at which the PSM implementation will proceed through Governance. Given that this is a ‘new’ concept (despite the reuse of code from the Sai to Dai migration bridge implementation from the Multi Collateral Dai upgrade), it is vital to see a large majority of the Maker community in favour of implementing this as an expedited measure in order to pursue that path. Accordingly, this forum poll will allow the Maker community to signal their desired way forward for the PSM implementation timeline.

Should we implement the PSM, and if so, what process should we follow?

  • I don’t want to see this implemented.
  • I would like to see this implemented only using the MIPs process (longer-term implementation).
  • I would like to see this implemented, but after a few weeks of discussion.
  • I would like to see this implemented as soon as possible as an expedited measure.

0 voters

Notes:

  • The poll will be live for at least 24 hours but might be extended based on the results after the initial 24 hour period has passed.
  • Regardless of the winning option here, the PSM will also be formalized as a MIP at a later date and proposed in the monthly governance cycle.
4 Likes

While I would directly benefit from this being implemented immediately I voted agaist my financial interests by voting to discuss this a bit more.

I really want to know details of what would be pushed immediately.

  • We will be using SAI-DAI bridge code with 1:1 bidirectional facility but what will the DC be?
  • Are there other parameters we need to be aware of?
  • Why not put a bi-diretional fee so we end up with a real spread vs. pegging this 1:1 for free out of the gate?
5 Likes

I want to provide some data points that are relevant for the PSM poll. Recently in the Foundation we have been observing that integration partners in DeFi have been switching from Dai to USDC, or launching with USDC support instead of Dai, and it has in many cases been attributed directly to the peg.

One example was the new gnosis prediction (omen.eth) market which had planned to use Dai, but felt forced to switch to USDC because the broken peg would mean an unacceptable user experience. There’s also examples of distribution channels (wallets, exchanges) in South America that currently are Dai exclusive that are seriously considering switching to USDC because of the peg.

This is all something that has been happening slowly ever since march 12 when the peg first broke, but recently it has been definitely been happening a lot more - given that it is accelerating, I think this is a situation where every day matters, and there should be a very good reason to delay fixing the peg.

It’s also important context that any decision now could easily be switched later by governance, meaning that even if the initial implementation is quite simple, it obviously doesn’t mean that Maker is somehow permanently chained to that version. Rather it could simply act as a short term solution that provides some much needed relief to the peg, only to later be replaced by a more sophisticated solution that the community has had plenty of time to discuss and design

Edit: Apparently omen.eth does support Dai now, however if you look at the site in practice I think it is clear that USDC is the de facto main currency on the site, and I believe that this has been attributed to the broken peg as, as far as I know, the original plan was that it would be Dai focused, or even Dai exclusive.

10 Likes

Going to provide a little more clarity around this poll and how it’s going to work and what the different options will mean in practice.

Due to the nature of this change (very different to what we’ve done in the past) and the timeline and recent holidays we will require a 66% majority on the ‘expedited’ (read emergency) measure option in order to pursue that route.

If we do pursue implementation as an emergency measure:
Maker Governance will get a chance to vote on parameters in ranked on-chain polls. Unfortunately there will not be a large amount of time for discussion around the merits of various parameters, however we will address it on a governance and risk call before the polls close.

If we do pursue implementation after a few weeks of discussion:
We’ll discuss the PSM and possible parameters further over the next three weeks and within multiple governance and risk calls. On week four we will vote on the parameters during the weekly governance cycle, with the PSM being included in the executive on Friday.

If we do pursue implementation only using the MIPs process:
A MIP will be written and shared and will follow the rules of the MIPs process and the monthly governance cycle.


Just as an aside, I’ll be keeping track of any sybil-like behaviour on the poll. If you’ve only joined the forum recently and you vote in this poll, please leave a short reply with your reasoning so I don’t have to try to figure out if anyone is trying to manipulate the result.

1 Like

Could a proponent of PSM as an emergency measure weigh in on whether or not they view PSM as a mitigation of the Compound problem, and if so, sketch how it would help?

It seems like Compound is the reason we are considering emergency measures, but it’s far from clear how PSM would address it. For that reason, I voted in favour of considering the PSM as part of the MIPs process but against implementing it as an emergency measure.

6 Likes

This decision seems strange to me. Here on the forum, it’s one person one vote. In contrast, on-chain polls are one MKR one vote. Hence, this poll should be regarded as unrepresentative. It’s a straw poll. If there is really doubt in the will of MKR holders then the same poll can be placed on-chain in a rank-choice format or some other on-chain process can be followed.

3 Likes

The PSM would help against COMP, or any other disruptions to the peg if governance is willing to increase the debt ceilings of stablecoins enough to accomodate it. It means Maker governance will always have a “fix the peg” button available at all times, as an option.

It would have a big impact right now, even without further increases to debt ceilings by making sure that the approved 40 million debt ceiling for USDC would actually be used (as right now it is not used, likely due to the strict risk parameters)

And even with limited stablecoin debt ceilings, the existence of a large amount of stablecoins available to buy Dai at 1 USD makes the protocol more attractive to vault users, as it provides them guaranteed liquidity for their Dai even when generating large amounts of Dai at once.

This dynamic of guaranteed liquidity in fiat backed stablecoins at the peg is also crucial in cutting through the chicken and egg problem that exists with onboarding real world assets as collateral to the system, as real world loan originators need a large amount of liquidity before it becomes worth it to spend the enormous amount of effort that it would require to learn how to engage with the Maker protocol. The PSM helps provide this guaranteed liquidity directly, even if governance is unwilling to increase the stablecoin debt ceilings beyond the current 40 million. So it will in all circumstances be a big step forward towards solving the long term issues with the peg.

However, as a separate argument I do believe that it is absolutely the best option for maker governance to begin much larger scale onboarding of stablecoins as collateral (this works even better with the PSM due to the multiplier effects noted above, but even without the PSM it is better than doing nothing).

The alternative is to let the peg fail, or work towards implementing negative rates. To continue to let the peg fail is suicidal, as it is eroding the organic growth that the project has built up for years, and this erosion is happening at an accelerating pace as we now approach month 4 of a broken peg. I know the numbers look good right now on daistats, but what we’re seeing is that organic users are being replaced by artificial demand driven by compound.

Yet the dogma is that maker governance should just continue to let the peg fail, on the basis of an emotional argument that “centralized stablecoins are of the devil, and ETH is pure”, and keeping maker “pure” is more important than the delivering on the one promise that Maker governance has made to its userbase, which is to keep Dai stable at 1 USD.

The systemic reliance that ETH and BTC has on Tether and Binance is conveniently overlooked every single time someone argues against USDC as collateral, but the fact is that USDC, PAX and other regulated and legit stablecoins actually are among the only options for hedging the indirect exposure that Maker has to Tether and Binance right now.

IMO someone who is not willing to take action to fix the peg through higher debt ceilings and different risk parameters, should then argue for implementing negative rates (which I would completely respect, it’s just important to be realistic about how big of a challenge that actually is).

Just letting the peg fail is a betrayal of the users of the system, especially when it is being done based on a purist argument that ignores the role of Tether in crypto markets and the indirect exposure Maker has.

Edit: something that add that obviously needs to be clearly spelled out, is that of course no one would want to see a large concentration of stablecoins for a long time in the portfolio, just like it wouldn’t be good to have a lot of any other asset. The end goal in all cases is a diversified collateral portfolio.

But the whole point is that choosing to fix the peg in the short term through a lot of stablecoins, enables the ecosystem to then move forward to a state where a lot of e.g. real world assets can be onboarded to proper diversify the collateral portfolio.

Choosing to keep the peg broken, means choosing to wither and die by alienating all the organic users of the system who aren’t in on the purity-but-lets-ignore-tether religion.

11 Likes

I don’t think it’s about doubting the will of the MKR Holders in this case, it’s more that moving this quickly on something new, especially proposed during a major holiday is not something we should be doing unless there is a very good reason for it.

If it was something we’d done before, then sure, a simple majority to make it an emergency action seems reasonable.

If it had been proposed on a regular Monday rather than on the 4th of July weekend, sure, maybe it would be a simple majority.

As it is, it’s new and it was badly timed. If 2/3rds of people want to see happen as an emergency action anyway, then sure. But we should not normalize this short of a timescale around new proposals.

4 Likes

Chris Mooney and I are working on a critical response, because we feel it deserves an opposing perspective that it currently lacks. However, we are still digesting the information on this proposal and the comments and we are feeling rushed to formulate a reasonable response under this time frame. I’d like to request that we extend the time frame on this signal request to give people enough time to adequately respond.

10 Likes

This is a reasonable request, but I think it would be difficult to justify delaying action if after 24 hours more than 66% of voters want to continue under an emergency process.

I will point out that if we don’t do this as an emergency process now, that doesn’t mean that we can’t follow it as an emergency process at some point in the future if the peg worsens, or if @Risk decides to support it as an emergency measure (Cyrus is currently undecided, and also wants more time to consider the impact before weighing in.)

Given that that is the case, I would like to recommend that people avoid voting precipitously to follow this as an emergency process now before hearing an opposing perspective.

Apologies @BrianMcMakerDAO and @cmooney, I would recommend that you either aim to get a short summary done in the next few hours, or attempt to convince people to wait for your piece before voting.

As always, even if this does proceed as an emergency measure, it will need to pass an on-chain executive, and unless there is a sudden disaster, we won’t allow that executive to go up before Friday. There will be time for MKR Holders to read your piece before voting on-chain.

One additional point. If ‘emergency / expedited’ response reaches a majority, but not 66%, then we’ll go with the option of ‘taking a few weeks.’ I think this is the fairest compromise option in that situation.

3 Likes

For voters that would like to see immediate action, I would like to point out that you should only vote for the “as soon as possible as an expedited measure” option and NO OTHER OPTIONS. If you split your vote among other options, even if you are comfortable with these other courses of action, then you drop the percentage in favor of the expedited option.

Oops, @LongForWisdom says that I’m wrong (below). Nevermind.

No, you don’t need to do this. The percentages for each option are calculated as ‘votes for option’ / ‘total voters’ (not total votes.)

23/35 = ~65%
23/45 = 51%

The only thing you do when voting for multiple options is drop the percentage for options that you aren’t voting for, and increase it for options you are voting for. Which is what is supposed to happen.

1 Like

I think the PSM has the potential to smooth peg fluctuations and hold us closer to the peg, on average, and given the cursory investigation I’ve had time to do today seems to be implementable safely. However, this feels very rushed and I am concerned about the possibility of overlooking subtle bugs, especially involving multi-contract interactions. This will also increase the complexity of governing the system (particularly PSM-DSR interactions), and it seems prudent to explore those issues as far as possible before taking on-chain action. Thus I am personally in favor of a slower, MIPs-based process, unless a strong argument can be presented that a swift implementation of a PSM is an existential necessity for the Maker protocol. In the meantime, why not consider a significant ETH debt ceiling increase to combat the high peg deviation? Is something going on with COMP farming that makes that a bad idea?

7 Likes

Peg is the most critical and basic feature of Dai, comparing with other stable coins we have seen unhappy development on both mint & adoption due to the unstable rate of Dai .

Some stable coins focus Dex such as Curve has been showing the strong needs for a bridge of stable coins.

Via 1:1 with USDC , and maybe tusd,pax in future, a good link to real world will be established.

So we should implement the PSM ASAP.

2 Likes

I’m a bit concerned that the full spectrum of views aren’t expressible in this poll.
I suspect many people are in the “few weeks of discussion” camp, but with an open mind on whether or not it should be implemented.

5 Likes

I agree with this sentiment. I don’t understand why the MKR holders are being deprived of immediate action if that’s (potentially) what the majority of MKR wants? A forum poll doesn’t seem like it’s targeting the right group of decision makers for something this important/significant.

5 Likes

A brief inquiry on process (and borne from my ignorance): is the 2/3rd’s majority (66%) required for passing an “emergency/expedited” response in Forum Signal Requests generally? Or is that 66% cutoff present only for the current situation?

2 Likes

I agree that fixing the peg should be the first priority. I don’t think DAI should be a wrapper for other stablecoins - we must find our own way to be stable and that means developing new features (negative rate support, undercollateralization etc.). PSM might buy us some time so let’s use it.

1 Like