MIP29 - Peg Stability Module

MIP29: Peg Stability Module

Preamble

MIP#: 29
Title: Peg Stability Module
Author(s): Sam MacPherson (@hexonaut)
Contributors: None
Type: Technical
Status: Request for Comments (RFC)
Date Proposed: 2020-11-09
Date Ratified: <yyyy-mm-dd>
Dependencies: n/a
Replaces: n/a
License: AGPL3+

References

Sentence Summary

This proposal provides a smart contract implementation of the Peg Stability Module.

Paragraph Summary

The PSM acts a special vault which is attached to a permissioned gemJoin with 100% Collateralization Ratio and 0% Stability Fees. Instead of crediting gems to the supplier of the tokens, it pools them together and takes out a debt position at 100% Collateralization Ratio issuing the newly minted ERC20 Dai to the person who supplied the collateral. In the reverse direction, anyone can go from ERC20 Dai to the collateral token as long as there is debt available to clear. Optional fees tin and tout can be activated as well which send a fraction of the trade into the vow. This implementation conforms to the description laid out in the Pre-MIP discussion.

Component Summary

MIP29c1: Definitions: defines Toll In (tin) and Toll Out (tout).

MIP29c2: Proposed code: contains snippet of proposed implementation.

MIP29c3: Test cases: lists existing test cases, including integration test

MIP29c4: Security considerations: comments on the limited nature of the security implications of adding the PSM.

MIP29c5: Formal verification/audit information: comments on the amenability of the proposed code to formal verification, even though formal specification, audit, or code review have yet to be conducted.

MIP29c6: Licensing: states the license under which the proposal and code are distributed.

Motivation

Creating more Dai utility through a stable peg

The number one objective of the Maker protocol and Maker governance is to maintain the stability of Dai, so that the people, businesses and DeFi protocols that rely on it can trust that their money is protected from volatility. Delivering against this promise will drive continued growth of the project. The Peg Stabilization Module can restore the peg and utility of Dai to users around the world, which makes it a very important change to consider.

Strengthening the collateral portfolio by replacing collateral types that cannot be liquidated

The Maker protocol currently has a lot of Dai generated from the USDC-A collateral type, which has liquidations disabled. This is an undesirable situation, because the Maker Protocol wasn’t designed to support having collateral types with liquidations turned off, and it could potentially result in Vaults with more debt than collateral value that would be abandoned by their owners, yet still remain in the collateral portfolio.

But having liquidations disabled was necessary due to the fact that the current auction system is not well suited for liquidating low-risk assets, so it was done as a short term solution that would be replaced in the future. The Peg Stabilization Module is such a solution that would be able to replace this collateral type. It would allow Maker Governance to altogether remove stablecoin based collateral types from the system in the short run, solving the issue of disabled liquidations entirely, and removing any risk that the system will end up having abandoned, unliquidated Vaults with more debt than collateral value.

Encouraging natural Dai generation from other collateral types through stability and liquidity

A significant advantage of the Peg Stabilization Module is that it helps with stability and liquidity when the price goes above the peg. It also helps to provide liquidity and stability for when there is Dai supply to sell. This means that it helps encourage vault creation and Dai generation from other assets, such as ETH, because it gives vault users a lot of reliable liquidity to sell their Dai to if they are looking to pull fiat currency out from their vault.

Generally, a reliable peg makes Vault holders more willing to generate Dai. In contrast, an uncertain peg makes it riskier to generate Dai, since it is less clear if it will be possible to later unwind the position again without having to buy back Dai at a price different from the peg. Providing a solution to this issue with the Peg Stabilization Module is a significant advantage in the short run to try to get the Protocol back into a natural balance. Still, it will also continue to be a substantial advantage in the long term. It generally improves the user experience and value proposition the system offers to its users, both Dai users and Vault users.

Natural unwinding

During times when the Maker Protocol is out of balance, the Peg Stabilization Module will keep the Dai peg stabilized by building up potentially large amounts of stablecoins as collateral. Since the Peg Stabilization Module encourages natural Dai generation, the built-up stablecoins within the Peg Stabilization Module will be used by new Vault users to exit to fiat if there is a significant buildup (this will only be temporary).

This means that the Peg Stabilization Module naturally unwinds itself as the system goes back into a balanced state. Therefore, the Peg Stabilization Module will not contribute to the long-term buildup of stablecoins as collateral in the system. Instead, it will work against it by helping to bring the system back into balance quickly. This ultimately minimizes the amount of time the Maker Protocol needs to have substantial exposure to stablecoins.

Becoming the trading hub for stablecoin swaps

Another long term advantage that the Peg Stabilization Module offers is the ability to become a hub for trading different stablecoins against each other.

If Maker Governance adds multiple stablecoins to Peg Stabilization Modules and enables low-fee 1:1 trading for each of them (against Dai), it would allow the trading of different stablecoins against each other as a side-effect. As a result, this would ultimately help with overall liquidity in the DeFi ecosystem. At the same time, Maker would be compensated by charging the Peg Stabilization Module spread twice for providing the service.

Specification

MIP29c1: Definitions

  • Toll In: The fraction of the Gem -> Dai transaction sent to the vow as a fee. Encoded as tin in wad units.
  • Toll Out: The fraction of the Dai -> Gem transaction sent to the vow as a fee. Encoded as tin in wad units.

MIP29c2: Proposed code

see psm.sol. The core functionality is simple:

function sellGem(address usr, uint256 gemAmt) external {
    uint256 gemAmt18 = mul(gemAmt, to18ConversionFactor);
    uint256 fee = mul(gemAmt18, tin) / WAD;
    uint256 daiAmt = sub(gemAmt18, fee);
    gemJoin.join(address(this), gemAmt, msg.sender);
    vat.frob(ilk, address(this), address(this), address(this), int256(gemAmt18), int256(gemAmt18));
    vat.move(address(this), vow, mul(fee, RAY));
    daiJoin.exit(usr, daiAmt);

    emit SellGem(usr, gemAmt, fee);
}
function buyGem(address usr, uint256 gemAmt) external {
    uint256 gemAmt18 = mul(gemAmt, to18ConversionFactor);
    uint256 fee = mul(gemAmt18, tout) / WAD;
    uint256 daiAmt = add(gemAmt18, fee);
    require(dai.transferFrom(msg.sender, address(this), daiAmt), "DssPsm/failed-transfer");
    daiJoin.join(address(this), daiAmt);
    vat.frob(ilk, address(this), address(this), address(this), -int256(gemAmt18), -int256(gemAmt18));
    gemJoin.exit(usr, gemAmt);
    vat.move(address(this), vow, mul(fee, RAY));

    emit BuyGem(usr, gemAmt, fee);
}

MIP29c3: Test cases

see psm.t.sol

  • testFail_sellGem_over_line
  • test_sellGem_fee
  • test_swap_both_other_small_fee
  • test_swap_both_other
  • test_swap_both_fees
  • testFail_swap_both_small_fee_insufficient_dai
  • testFail_sellGem_insufficient_gem
  • testFail_direct_deposit
  • test_swap_both_no_fee
  • testFail_two_users_insufficient_dai
  • test_swap_both_zero
  • test_sellGem_no_fee

MIP29c4: Security considerations

The proposed solution is simple and non-invasive, interacting with only the permissioned gemJoin. The rest of the function calls are all calls into the Maker system that anyone can make.

MIP29c5: Formal verification/audit information

The proposed contract is written in a way which is amenable to formal specification and verification, in accordance with the style and practices of the core multi-collateral DAI contracts, though it has not been formally specified. No audit or code review has taken place yet.

MIP29c6: Licensing

16 Likes

@hexonaut,

That sure is a shiny MIP but sorry for not speaking code.
gemjoin?
vat?
What does this MIP actually do?
Could you please maybe come up with a worked out example? In english?
“Bob the whale has 1 million USDC and heads over to oasis.app” …now how does this story develop?

1 Like

Haha I figured as a technical MIP I would keep it technical. It will do exactly what was described in the pre-mip discussion. You can trade between dai and usdc/tusd/etc at 1:1 for a fee provided there is liquidity. You can picture it like the sai-dai bridge but with fees.

2 Likes

In the present market 1 DAI = 1.01 USDC.
Maker has approved the collateral type USDC-PSM as per MIP29.
Bob the whale has 1 million USDC and heads to Oasis.app.
Bob puts 1 million USDC into USDC-PSM and gets 1 million DAI as per MIP29. Bob happy as it is the cheapest DAI in the market.

is this a correct ELI5 version?

Pretty much except you probably don’t want the fees at exactly 0%, so Bob will get some fraction of 1 million Dai.

So let’s say Bob gets 1 million DAI minus 2x gas fees as we want the spread real tight. Is this approximately correct? Still a lot better than 1.01 spread currently.

The fees are a percent of the transaction amount and don’t have anything to do with gas. They can be whatever we want. If they are 1% then it will be roughly the same as the current stablecoin vaults but with no stability fee.

…story of Bob the whale continues…

Bob takes his DAI, does his thing and then wants his USDC back. He takes 1 million DAI (minus some fees) and starts looking around.
Bob could go to Oasis, but why? If the market peg is not 1:1 there is a better deal elsewhere.
Bob uses some other market, maybe Curve. Bob gets 1010000 USDC (minus fees) as the peg is still 1 DAI = 1.01 USD.
Bob heads over to Oasis again. Rinse and repeat.

edit: is this ELI5 still correct?

The ELI5 is more like:

You want DAI?, I give it to you for 1.01 USDC.
You want USDC? I give it to you for 1.00 DAI if I still have some USDC left from step above.

Parameters can change, but let’s start with the current state.

3 Likes

@Planet_X and all interested: it might be interesting (surely it was for me, @hexonaut kindly pointed it to me) to read the pre-MIP thread: here.

What we can do now is discuss (energetically!) on how:

  1. Properly reward @hexonaut for the code/community contribution. This is extremely important and should be rewarded as such.
  2. Approve some spending of the surplus to pay for third parties (Trail of bits, bounties, etc) to verify the code. We want this as quickly as possible. But at the time we need ultra-safe code. We will have to pay good money to have both of these things.
  3. While the verification (and perhaps code optimisations) are performed, we need to discuss a roadmap to how launch this PSM (for USDC first): What ceiling and what fixed-fees do we want?

This is very exciting. Thanks again @hexonaut.

4 Likes

This is not how I read this MIP. Goal is 1:1 trading, adjusted by fees.
If the fees are indeed 1% this means MIP29 can not help the peg inside the 0.99-1.01 range.
Am I correct?

Edit: outside corrected to inside

1 Like

If the fees both ways are set to 1% it will enforce a hard limit of 0.99-1.01 provided there is debt ceiling room or usdc available because it’s free money otherwise. There are a number of other benefits outlined in the pre-mip though.

1 Like

Does this contract have a enable/disable switch? We definitely want to disable it when the DAI savings rate (DSR) is greater than zero, yes? Maybe it should have a switch for each direction so we can set it to drain DAI liquidity in preparation to increase the DSR above zero.

Hm, can the switch be locked to the condition DSR!=0?

1 Like

It’s a parameter, I used tin at 1% and tout at 0%. I find this solution strictly superior to USDC-A so I don’t want to give the impression that we need to narrow the peg band more that what is currently done.

It can, but it’s not mandatory.

3 Likes

It has all the same controls as a regular vault type. We can turn off minting dai by setting the dc to 0. We cannot turn it off the other way though and we should let it drain first before turning on the dsr (same with usdc-a, etc).

3 Likes

Looks good
Thanks.

That is important :

1 Like

MIP14 allows you to do this, but you need to know specifically where you are sending the DAI. In terms of actually engaging auditors, you’d probably want to approach them and secure an agreement for work provided that DAI is paid upfront.

In terms of using it for bounties, this is currently possible, again, you just need a recipient address.

I’d largely agree with some of the others and say that the first step should be replicating the current stable-coin vault types in terms of fees. The ceiling should probably start low to limit risk.

2 Likes

Thanks LFW. Yesterday in MakerDAO’s chat, @hexonaut said:

So let’s wait a few days to see how this thing evolves. Ideally, the Smart contract team can give us indications on the necessity or not of 3rd party audits and stuff like that.

2 Likes

Awesome work - so glad to see progress on this

Some basic questions.

Is tin and tout in this design expected to be managed by governance or just set and left alone? I can’t imagine these are fixed values because then this part of the code would have to be redeployed on changes to tin/tout?!

Are tin and tout always expected to be above 0 and hence PEG always bracket 1-tout <= PEG <= 1+tin?

What is a scenario where this module actually causes the PEG to regulate around 1? (i.e. what are the tin and tout settings in this scenario and why is the PEG at 1 vs 1+tin and how much stablecoin liquidity is there in the PSM at this time).

Correct me if I am wrong in the understanding here.

with tin = 1% and tout=0. Lets say a user comes to the PSM and wants to swap 1010USDC for 1000 DAI. My understanding of the above code is the contract basically creates a vault and deposits 1010 USDC and mints 1010DAI. 1000 goes back to the USDC depositor and 10DAI goes into the surplus?

What happens in the above code if say for some reason USDC is trading at .985 US while DAI is trading at $1+tin for sake of illustration.

  • In the above example: What is to stop the system from minting 1000 DAI worth (1000+tin*1000)USD for 1000 USDC that is worth only $985US?
  • If there is something that stops the above, how does the price in USD of the stablecoin being converted relate to how much DAI the user gets and is this displayed in the User Interface to the PSM?

I think I disagree with the bolded part of the quote below:

I don’t see how a fixed tin and tout value causes any work other than to act as a pricing bracket at 1-tin as long as there is stablecoin liquidity in the PSM, and 1+tout as long as there is available DAI DC. As @LongForWisdom repeatedly points out without liquidity on either end here the facility ceases to regulate.

What is the backup PEG regulation if the PSM runs out of liquidity?

On the PEG downside everyone feels like stablecoin liquidity will exhaust rather rapidly and Maker has SF and DSR to cause the PEG to rise back to 1. But do we really give up our stablecoin PEG liquidity buffer at 1 PEG price or do we perhaps lower the 1-tout down to .99 and use the stablecoin liquidity in that case to act as a price stabilizer on the low side?

On the PEG highside is there going to be another facility that is available in case the PSM DC exhausts before governance can extend it?

Also on first glance there is no rate control on this. Literally someone could come and eat all of the available liqudiity in one shot (think flash loan here that costs tin% for the entire available DC), killing the PSMs ability to manage the PEG for some time (GSM delay to extend DC?!). Is the DC alone the best way to control capital flows into and out of this facility or should the rate of flow be controlled to some extent.

Looking at this proposal it really just looks like another variation of a USDC vault except fees are taken out up front. I have concerns over how the USD price of stablecoins minting DAI will be managed against the USD PEG price of DAI and what happens here if the collateral value in USD happens to drop below $1 as this will negative affect 1:1 collateral:DAI backing collateral value.

Notice during an ES these USD price oracles on collateral and DAI would be taken into account in normal vault claiming left over collateral… With the PSM the oracle price, if it is considered at all, is only at the time the exchange is made(we don’t care what the price of USDC does because we simply are not going to liquidate positions).
I think this adds an extra hazard for DAI holders in terms of collateral backing. Even at LR of 101 on USDC vaults with SF = 0 if USDC were to drop to what .99 with PEG at 1.01 or higher (for some reason) pretty much puts DAI holders in an ES short some collateral value.

The whole backing value was one of the main reasons I really wasn’t hot to go to LR of 101 on USDC-A with liquidations off mostly because one is limiting the collateral value buffer to only a 1% USD price change on the collateral (.99). If I my understanding is correct the PSM here is no longer has such a collateral USD value buffer as DAI is minted for stablecoins at 1:1 with profit immediately going into the surplus.

1 Like