MIP31: Active Reserve Via AMM

MIP31: Active Reserve AMM (dss-ara)

Preamble

MIP#: 31
Title: Active Reserve AMM (`dss-ara`)
Author(s): Alexis
Contributors: n/a
Type: Technical
Status: TBD
Date Proposed: <yyyy-mm-dd>
Date Ratified: <yyyy-mm-dd>
Dependencies:  the keg(https://github.com/makerdao/keg) module
Replaces: n/a
License: AGPL3+

References

Sentence summary

This MIPs is a technical proposal for an active reserve based on Uniswap V2 contract.

Paragraph summary

Currently, governance uses the surplus buffer as reserve, but in fact the surplus buffer hasn’t been designed to serve this purpose due to the nature of it. The surplus buffer is meant to be a protocol security reserve for Dai owners in case of failure. Therefore to some extent, It should be considered part of the collateral as it is redistributed to Dai Owner in case of emergency .
This proposal aims to add an missing piece to Maker, the Maker Reserve.

It is a technical proposal to create a Maker Owner reserve based on Uniswap V2 AMM. It uses DAI and MKR as asserts inside the liquidity pool for trading pair. The proposal will allow MakerDAO to build its own reserve. As a side effect it should bring :

  • burn process efficiency - swap vs dutch auction
  • more MKR price stability by creating a buffer
  • an important piece for future improvement
    • small amount Liquidation
    • decrease burning inefficiency
    • Oasis swap
    • etc … (DeFi is based on AMM)

The AMM on DAI/MKR pair will have a similar effect of the burn mechanism. Instead of burning we will stack 1/2 of MKR and 1/2 of DAI. The module will allow governance to withdraw DAI, MKR or Both. It will be plugged to the keg.

Component - new feature

The overall logic is based on uniswapV2: https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2Pair.sol

The swap mechanism won’t change, only fee parameters and non used mechanism will be clean up. mint and burn, will be replaced by deposit and withdraw. To secure eventual issue these new methods will be placed behind an allow-list. Only the swap needs to be “external”.

List of modification to apply:

Fees

swap()

MIP31a1:
fees need to be parametrized and managed by governance with fees parameter

_mintFee()

MIP31a2: _mintFee need to be removed The entrance fees doesn’t apply here we need to remove the method and call to the method.

skim()

MIP31a3: can be removed.

Mint and Burn

UniswapV2ERC20

MIP31b1: Remove the token implementation

Mint()

MIP31c1: Remove the token generation - _mint() method

MIP31c2: Rename method to deposit() method

MIP31c3: No parameter is needed

MIP31c4: should be allowlisted and accessible by keg and gov to withdraw.

Burn()

MIP31d1: Remove the token destruction. _burn() method

MIP31d2: Rename method to withdraw() method

MIP31d3: should be allowlisted and accessible by keg and gov to withdraw.

two options here

option 1:

MIP31e1: should be able to withdraw any amount of both tokens.

MIP31e2: three parameters are needed amount0Out, amount1Out, addressTo

####### option 2: (secure option)

MIP31g1: Should be able to ask for withdraw any amount of DAI.

MIP31g2: the withdrawal action will take an equal amount of DAI and MKR, the MKR is burn.

MIP31g3: The DAI is transferred to the surplus buffer or any vault pass as parameter at the creation.

MIP31g4: One parameter needed amountOut

MIP31: How does it work?

The initial deposit (50% DAI,50% MKR) needs to be relatively high to have some liquidity - probably around 500K each. Smaller the deposit is, higher the slippage is.

Then the idea here is to divert some % of the DAI from the MKR burning mechanism and redirect it into the AMM. When the Dai is inside the AMM, it will move the MKR price down and create an incentive to buy the MKR against the market. Note, the slippage should decrease when the liquidity increase. ( with 500000 Dai inside the AMM and a 10000 Dai put inside we should have around 1% slippage)
We can adjust the % taken to control the slippage.

There are two options for the withdraw method,
first option, we can withdraw any amount of DAIs or MKRs or both, but slippage will apply. DAI can be withdraw for whatever reason to any address, the address is pass as parameter (the method is behind a whitelist - governance), same for MKR. We can withdraw the same amount of MKR and DAI without any slippage, Burn the MKR and use the DAI.
The second option, is a more secure option. Note using whitelist only (first option) is common in MakerDao.
We won’t let the contract withdrawing any coins, instead we burn the MKR and transfer the Dai into the surplus buffer or any vault predefined. That way even if the contract/method is compromised, we don’t allow an easy way to transfer the deposit to any address.

A small fee is collected each swap and the fee is managed by governance (Uniswap uses a fixed percentage). Although I would advise to match the PSM fee, 0.1% or event less 0.04% as curve. We should not forget that we charge for the DAI inside and MKR was supposed to be burned.

Ultimately, I expert the AMM to be more efficient than the dutch auction.

Furthermore, we can add more reserve based on Dai. We can redirect small liquidation to it and decrease the dust. We can swap MKR to burn. We can add the swap to oassis. etc …

MIP31: Security

Uniswap contract

Errors or security vulnerabilities in the Uniswap contract. The contract has been used and well tested.

Contract Modification technical risk

In addition to the technical risk inherent to Uniswap contract, this implementation add some risk too. However, due to the design and the separation from the main system, the worst-case losses is limited to the deposited inside the AMM. I believe we would like to audit it.

MIP31: Economic / Governance considerations

Economic risks

impermanent losses

Difference between AMM and burn

  • 1/2 MKR and 1/2 DAI are locked vs 100% MKR burn
  • With the AMM, MKR supply doesn’t decrease
  • Due to impermanent losses and the AMM nature, amount of token stacked inside will change depending of the price fluctuation.
  • AMM reserve can be retrieve. MKR burn can’t be retrieve but can be minted again.

Nice plus,The Dai reserve increase when MKR decrease which it is when we need the reserve). On the other hand Dai reserve decrease when the MKR increase, but that should not be a problem as we can mint MKR instead.

MIP31: Licensing

13 Likes

This is super cool. Has the Risk Team taken a look? I know they are pretty backed up, but I think it’s important to make sure we’re not exposing ourselves to potential attacks on the LP we set up.

One other note, it looks like the “pre implementation” link is broken, I’d love to take a look when that is fixed so I can have a better idea of what’s going on the backend with this proposal. Overall, really love the idea and as long as it doesn’t expose us to extra risk (seems like the Uni platform risk is about to exist anyway) I’m all for it.

1 Like

I switched the repo to public, sorry for that.

Uni platform is a different contract, however I believe we will need an audit.

1 Like

@alexis,

I am fully aware that you got a bunch of likes for this proposal but I am going to stir the pot by opposing it.

In my opinion there is no point adding complexities such as a fund when financing of worthy activities can be achieved by simply siphoning off some portion of the continuous revenue. After we have added a fund we need rules for spending it and someone to sit and watch it and periodically evaluate it. All this is adding complexity.

I want the opposite. I want smaller and simpler, enabling us to move people out of the running of the protocol.

5 Likes

I don’t think it will be use to finance worthy activities but more as an insurance, that we don’t have.
This found react systematicaly at the opposites of maker. If we are in trouble the dai increase.

Worthy activities can be financed by minting MKR. But we can’t mint MKR during bad event.

Tho I see it more as a feature. A first block to plug stuff on it.

MKR will only be printed to refinance the system in case of undercollateralization as happened in March. That is the only reason MKR will ever be printed.

Yes we can. It is just that the price will not be high.

Well that is exactly my point, you print at 1/3 of the price.

So we should set the surplus buffer at an appropriate level for the level of risk. Or we can take out actual insurance from an insurance platform. I don’t see how adding another system with complex economics helps with this.

1 Like

One can go with the other.
I am at 100% to increase the surplus buffer, after we get the peg back, find demand for dai boring and decrease our exposure on USDC. As currently increasing the surplus buffer mean increasing the USDC vault by the same amount. I am not sure if it is very smart.

Back to AMM, But what happen if we have a surplus buffer of 10M, lost 20M. the surplus buffer is negative, how do you want to withdraw found from it? . as I said surplus buffer is dai owner reserve not a maker reserve.

@alexis
If the surplus buffer is DAI 10 million, but losses are DAI 20 million then MKR will be printed to make up the remaining 10 million. It is that simple.

1 Like

at which price? 200 dollars
That is the whole point of this reserve.

A rather poor price. That is suboptimal but fully acceptable. Reserves will never be able to backstop the system.

2 Likes

I agree. Reserves will not be sufficient for larger defaults anyway.

I think it’s foolish to try to avoid printing MKR. It’s basically market giving us ‘fair’ price when all risks are taken into account. Also, market should get used to printing MKR occasionally. Reserves only reduce number of such events.

1 Like

Well this reserve, it is here to mitigate this issue.

1 Like

Unfortunately I don’t think this is a great time to devote resources to this. I fully sympathize with the intent and really appreciate the work that was put into it! We are already biting almost more than we can chew with tasks related to Maker’s core mission. Once the dust settles after we’ve moved past integrating new collateral types, giving more control to domain teams, improving vote participation/delegation, we may look at moving some of the reserves to a hedge such as this AMM concept (with no need to change the core protocol). On the idea itself, I am not sure I get how it is economically better than reserve+dilution. Could you give a worked out example?

1 Like

I think this idea can be merged with the Strategic Reserves Fund by being more specific about how we want to use the Strategic Reserves Fund, the same effect that is being proposed here can be achieved by diverting some percentage of protocol income and then mainly using the SRF to provide liquidity in MKR pairs on uniswap/balancer/sushiswap.

A possible advantage of directly providing liquidity on other protocols this way, rather than creating our own AMM protocol, is that we then get to sell directly to a pre-existing userbase rather than having to bootstrap a new userbase for this new AMM from scratch.

The current proposal is about issuing DAI (Maker liability) to generate DAI and MKR assets (or maybe issue MKR liability as well not sure). This would increase the Maker risk with the MKR price volatility (it is strictly worse than having MKR vaults). Having some DAI on the asset side and almost the same number on the liability side doesn’t have any impact. If we take that road I would go directly to ETH/DAI and ETH/MKR for profitability or DAI/WBTC for business development.

The current issue I have with Strategic Reserves (beside not having much time) is that it doesn’t play well with the DAI system. It basically mean you have to pay cash all the asset in the Strategic Reserves. At the same time the world want Maker to live at credit (big demand of DAI).

Notice that we can hedge the volatility of ETH by issuing DAI and borrowing ETH with a positive carry (as everyone ants to do the opposite). Basically, we make money by lending DAI vs borrowing ETH and we make money by having a DAI/ETH LP. And the icing on the cake is that it’s a risk free arbitrage if we keep the same amount of ETH on the asset and liability side.

But no idea how to blend this concept of balance sheet management with the current Maker system, but MIP31 is probably a first step.

1 Like

Yes true, tho we need to gather more idea, get it voted, audited, get it voted again …
It is clear that won’t happen before Q3 2021, but if we don’t start the process now. we won’t get anything.

Also worse noted, it is dependent of Keg module, which is not planned before end Q1-Q2.

The code is DAI based, any pair with Dai.
MKR/DAI is the cheapest to start with, as we have both of them.

It is the opposite AMM works on the opposite sense MKR decrease DAI reserve increase, MKR increase DAI reserve decrease.

1 Like

This is a great idea. Maybe the LP rewards can be used to fund NXM premiums. Kill multiple birds with one stone.

Hi @alexis, posting this message on this proposal as well:

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).

1 Like