MIP32: Peg Stability Module - Compound Mixed Exposure

alexis · December 15, 2020, 4:02pm

MIP32: Peg Stability Module - Compound Mixed Exposure

Preamble

MIP#: 32
Title: Peg Stability Module - Compound Mixed Exposure
Author(s): Alexis
Contributors: None
Type: Technical
Status: Request for Comments (RFC)
Date Proposed: 2020-12-18
Date Ratified: <yyyy-mm-dd>
Dependencies: PSM, Uniswap, Vat, Join Usdc-lendler, Join Dai-lendler 
Replaces: n/a
License: AGPL3+

References

The proposed implementation : dss-psm-cme

Sentence Summary

This proposal define a new Peg Stability Module which converts USDC to DAI and DAI to USDC, during the conversion it lends the gem via lender token and
leverage the position using cdai.

Paragraph Summary

The PSM Compound Mixed Exposure is based on the classic PSM but with a second join plug in serie to leverage the position with Dai.
It also uses a “lending gem join” which lend dai to cdai and usdc to cusdc.

The join is a generic ‘maker join’ and can be plugged to any vaults.
It takes as input a collateral and lends it behind the scene to compound,
on the output the join redeems the position and return the collateral.
It can be applied to Dai or any compound collaterals.

Optional fees tin and tout can be activated as well which send a fraction of the trade into the vow.

This PSM will have 2 urns one cDai and one cUsdc, but the maker position for this PSM is still on uscd and dai.

Global Overview Diagram

Component Summary

MIP32c1: The PSM Contains snippet of proposed implementation.

MIP32c2: The Lending Join

MIP32c3: The Burn Delegator

MIP32c4: The Harvest contract

MIP32c5: Proposed Code

MIP32c6: Test cases Lists existing test cases

MIP32c7: Security considerations Comments on the security implications

MIP32c8: Licensing States the license under which the proposal and code are distributed.

Motivation

Currently, the usdc token inside the PSM is inefficient and needs to be diversified.
By using cDai and cUsdc we will bring some diversification.
The leverage is also motivated by a better outcome and a better diversification.

Specification

The PSM Mixed Exposure is articulated around 3 main components:

The PSM (entry point)
The Join (urn)
The excess delegator (excess token conversion)
The harvest contract

MIP32c1: The PSM

It is very similar at the actual PSM (MIP 29) with two vaults, one in Dai and one in Usdc.

It has three methods:

sell(address usr, uint256 gemAmt)
buy(address usr, uint256 gemAmt)
reserve()

It also has three admin methods

file(bytes32 what, data) : To change parameters
rely(address contract) : To add authorized address
deny(address contract) : To remove authorized address

There are three prameters:

tin : The fraction of the Gem → Dai transaction sent to the vow as a fee. Encoded as tin in wad units.
tout: The fraction of the Dai → Gem transaction sent to the vow as a fee. Encoded as tout in wad units.
line: The maximum amount of Usdc owns by the PSM. Encoded as line in wad units.

sell will take in input usdc, convert usdc into dai via the new lending join (usdc/dai). Then it will take the dai and convert it to dai via another lending join (Dai/Dai) and take the fees and return the Dai.

buy will take in input dai, convert the dai after fee into dai via the lending join (dai/dai). Then it will take the dai and convert it to usdc via the lending join (Dai/Usdc) and return the Usdc.

reserve will return the reserve inside the contract in dai,token - this is based on the uniswap reserve() call.

Additional specification:
The same level of debt is maintained for both positions (the leverage urn and the gem urn).

MIP32c2: The Lending Join

This uses a classic maker join with on top the conversion from and to the lender. There is an additional method harvest() behind an allowlist.
The collateral is register and allow borrowing on it exactly like a normal collateral, but the lending join lends it to compound.

The join is an auth-join type accessible only by the PSM.

The extra method ‘harvest()’ have 2 actions:

move the excess token to the delegator.
move the bonus token to the delegator.

The join has one external methods

exit(address guy, uint256 amount)

The join has two authenticated methods

join(address guy, uint256 amount)
harvest() : To move excess to the delegator

The join also has forth admin methods

file(bytes32 what, data) : To change parameters
rely(address contract) : To add authorized address
deny(address contract) : To remove authorized address
cage() : To cage the join

The join has one parameter:

excess_delegator : excess Delegator address

Additional specification:
In order to calculate the excess, we add a total variable which represent the amount own by the join. Then we subtract this amount from the lendler underlying collateral.

MIP32c3: The Burn Delegator

The Delegator is replaceable, its main purpose is to manage the token conversion and what we do with it.

This delegator has three public methods:

processUsdc() convert the usdc to dai via the psm.
processComp() convert token bonus to dai via uniswap.
processDai() convert dai to MKR via uniswap and burn the MKR.

The join also has forth admin methods

file(bytes32 what, data) : To change parameters
rely(address contract) : To add authorized address
deny(address contract) : To remove authorized address
cage() : To cage the join

There are six parameters :

psm : psm address - can be changed
route : uniswap route address - can be changed
bonus_auction_duration: min time is sec between 2 uniswap swap
max_bonus_auction_amount : max comp amount by swap.
dai_auction_duration: min time is sec between 2 uniswap swap
max_dai_auction_amount : max dai amount by swap.

MIP32c4: The Harvest contract

This contract will have only one external method harvest() which calls the authenticated harvest() method from the join.
Two contract will be deployed to call both join.

This contract has only one public methods:

harvest() call harvest from the join

We separated this method from the PSM to allow more flexibility for update.

MIP32c5: Proposed code

The code : dds-psm-cme

MIP32c6: Test cases

Unit tests:

MIP32c7: Security considerations

Compound technical risk

Errors or security vulnerabilities in the Compound system could result in the underlying USDC deposits to be lost or stolen.

Implementation technical risk

In addition to the technical risk inherent to Compound, the adapter implementation itself is non-trivial and could increase the attack/error surface.

Due to the design of multi-collateral DAI, worst-case losses should be limited to the collateral deposited in the adapter, and the debt ceiling should be set with this in mind.

There is security consideration about the code itself, compound tokens.
In this implementation as we don’t use leverage on compound, the c-token can’t be sized.

Another risk: uniswap interaction, but limited to the extra bonus.

MIP32c8: Licensing

AGPL3+

charlesstlouis · December 15, 2020, 6:27pm

Hey @alexis, if you could kindly fork the MIPs repo and make a PR to the RFC branch for this proposal that would be great. Once that’s done, I will do the review and move it to Request for Comments (RFC) status. This is a requirement for it to enter the RFC. If you have any other questions regarding MIP requirements or the MIPs Lifecycle, please check out the MIP Lifecycle overview in MIP0 or reach out to me on Rocket.chat (@charlesstlouis).

alexis · December 15, 2020, 11:30pm

Hi @charlesstlouis,
Here again, just for record, I have also created a pull request for it :

Thanks for pushing it forward

charlesstlouis · December 16, 2020, 9:12pm

Thanks for pushing the PR! It would be helpful if you could use the Technical MIPs template as a reference for the structure of a Technical MIP. Additionally, some great examples of well written technical MIPs are:

For now, I’m going to go ahead and make some formatting changes to MIP21 and MIP32 as well as make some comments for you to consider when the proposals get moved to RFC.

alexis · December 26, 2020, 9:45pm

Hi Everyone,

I have updated the MIP32 and improved the specification over the last 2 weeks. I have also implemented it and unit tested it. However the integration needs to be tested too but I failed to get support.

If anyone wants to have a look at it and give me some feedback on both the MIPs and the code.

The code is here :

The pull request for the MIPs is here :

I do believe this proposal can generate some income and asserts diversity for maker over the time as we will lend the dai that we can’t sell.

Davidutro · January 6, 2021, 2:02pm

Adding this for discoverability/visibility

Replenish2030 · January 6, 2021, 3:10pm

Can we use Aave pls? Would be nice to not be supporting a project that’s trying to build a maker clone and is taking active steps to harm dai on their platform. They would look for ways to use this integration to damage dai in order to promote their own stablecoin. Considering they were using deception by claiming not to build a stablecoin, while secretly working on it, who knows what other trick they might pull out of their sleeve? Maybe they’d even seize the funds.

Instead by using aave it would be a lot more synergetic and potentially encourage aave not to create their own maker clone, but instead have a healthy symbiosis with maker.

alexis · January 6, 2021, 4:03pm

@Davidutro Thanks for bringing it here.
just to clarify the join-lending-leverage-auth.sol is not part of this MIP, once we will get the specification done and some code review on this MIP. I will push another MIP for it as it is very similar to this one but with more complexity/more risk.

@Replenish2030 don’t get it wrong in that case we push the overflowed Dai into compound and remove the underflowed dai from compound. I don’t think it will serve compound on a long term as they will face the same problem as we are currently facing. You might think that will help them by increasing their exposure but it also creates a lot of instability into their price which is what maker is selling at the end of the day - a fixed rate and an understanding price.
However, I think if this situation last - difficulty to sell our debt position - I agree we will need to integrate with Aave too. But my hope is that by the end of this year with RWA, we will be able to sell all our debt position and more instead of using second market lending.

alexis · January 11, 2021, 2:26pm

Hi @charlesstlouis,

Just to let you know that I’ve changed some elements of the specification. I pushed a PR to RFC and I have also updated this MIP.

I also added some clarity regarding the sol files and the spell.

Davidutro · January 18, 2021, 4:22pm

An alternative version of this MIP has been posted, the implementation includes farming COMP, not just lending the PSM Dai as cDai.

alexis · January 26, 2021, 10:46am

Add Harvest Contract to add more flexibility

alexis · February 7, 2021, 10:57am

Hi,

I have updated the code to add the line parameter and remove the cage.
I have also updated the specification with this new parameter.
I have added the classic function to the spec too.

Davidutro · May 14, 2021, 7:33pm

@alexis Is the case the same with this MIP as MIP44?Can we mark this proposal withdrawn and archive it?