Signal Request: Parameters for SCD Shutdown - Date

Now that the previous poll has closed here:

we can further clarify the final Shutdown Parameters. Specifically Shutdown Date in this post.

In the following section I will post a poll that includes options for # of months before SCD Shutdown. Please note that I think it’s in our best interest to not get too granular in our options so the options won’t be all encompassing but should give enough room for fair choice. Please choose the option that is closest to your viewpoint. If you don’t like any of the options or have any other objections or comments please let me know below and if there are enough objections we can modify the options or at least have a discussion. Hopefully we’re closing in on the finish line!

When should SCD Shutdown begin from now:

  • 1 Month
  • 3 Months
  • 6 Months
  • 12 Months
  • More than 12 Months
  • Abstain / Object / No Opinion / Comment Below

0 voters

IF the bridge is left up at 1:1 I see no reason to shut down the SCD. Just keep lowering the DC and use various other parameters to encourage migration.

We have a single CDP holder with 8.2M outstanding CDP 3088 (which has not done anything for almost a year) so I think a reasonable shutdown number provided this user doesn’t close is ~13-15M. I have expected a distinct slowdown in closures when ~35M hits and expect it will take at least 6 months to get SAI down to ~20M

My point here is that the SCD shutdown does NOT have to be a time based close but simply can be an amount of SAI or number of CDPs left to close.

The other problem here is that this 20DAI lint limit is keeping a lot of CDPs from closing but honestly I don’t think these are a ‘big’ deal.

Also I was researching a bit on the top 50-60% remaining CDP holders and all but 2 have been active in the past 60 days.

I also think a well thought out plan regarding shutdown conditions (or if a timeline which I don’t think is a good idea) should be presented to the entire community (SAI and CDP holders) so everyone has been notified in advance of the possibility of the SAI to lose it’s PEG to the dollar AND the conditions which can elicit a SCD shutdown. If the DAI-SAI bridge stays open I honestly don’t see a reason to close the SCD down or the SAI peg to be lost.

Personally I would just keep lowering the SCD-DC, match the borrow rates between the MCD/SCD or have them be slighly higher on the SCD vs. the MCD and just wait. Eventually there will be less and less SAI out there and ANY drag on the SAI peg should be driven by the markets on DAI and the available SAI-DAI 1:1 bridge.

The fact the rates should match pretty close means basically both systems are run with basically the same conditions and should not present additional headaches for the Maker community. In fact one could just put up a proposal to tie the SCD rates to the MCD ETH-A SF rates so community only needs to vote on tieing the SCD/MCD system rates, and then vote on the MCD rates in the future knowing the SCD rates will move to match automatically.

I do not see any outstanding reason to shutdown the SCD based on time but it should be on other conditions outlined above. Hence the reason I abstained.

1 Like

I think the reason to push for an earlier SCD shutdown is to reduce cognitive complexity for the product development people and also generally to reduce attack surface. Hence, I voted for 3 months.

I tend to look at this from many perspectives. Exactly what development needs to be done on the SCD? security maintenance fixes should be the only development. Cognitve complexity? Really? Just keep dropping the SCD-DC, match the rates between the MCD/ETH SCD and keep the SAI-DAI bridge up. Announce again that the vast majority of Maker efforts will go into the MCD and not the SCD.

Are we so concerned about this that we are happier to burn early SCD users than to take the risk as a community to give them more than ample time to act. I mean the outstanding SAI is continuing to drop. Ratio of SAI to DAI 71:41 and growing.

I still see people struggling to find SAI liquidity to migrate and people want to close this out in 3 months.

I will vote no to any time frame closure and would rather have the SAI outstanding be the key parameter but honestly as the ratio of SAI to DAI decreases the collateral in the SCD at risk becomes less and less of an issue. (particularly when we hit 90:20 DAI:SAI which I expect will take at least 6 months provided sufficient liquidity can be found)

2 Likes

Would you then vote for the “More than 12 Months” option? I can change it to include “indefinitely” if you prefer.

I am not sure that helps me since in principle I think ‘at some point’ the SCD can be shutdown with the least ‘collateral’ damage to the remaining users but the ‘point’ is defined by either amount of SAI outstanding relative to DAI or the number of CDP users left.

What has been on my mind of late is this idea that IF the ESM is activated from what I can tell there is no graceful way to re-activate the system AS it WAS and anyone wanting their collateral back basically have to obtain the relevant stable coin to claim their collateral?

Correct me if I’m wrong here.

Is it true if the ESM is activated the entire system (including a new DAI) needs to be re-deployed and every user will have to migrate from the system that was shut down to the new one and a new stable coin will need to be issued?

My only motivation for shutting down Sai is because I have 1 Sai stuck over at Coinbase (it was stuck over at Dharma.io and took a month or two to be able to get it sent to my iOS Coinbase Wallet, which I stupidly sent to Coinbase) and I’m figuring it will be automatically converted when Sai is shut down, or at least converted to ETH or something. Can’t send it back to Coinbase Wallet or I lose more of it. So, it has no value to me, as no one supports it and moving it only loses more of it. :frowning:

After 2 weeks and 31 votes I think we can safely say the “winner” is 6 months with 39% of the vote with 12 votes. Thank you to everyone for participating!

2 Likes

A summary of all SCD Shutdown Parameters can be found here: