MIP31: Active Reserve Via AMM

MIP31: Active Reserve AMM (dss-ara)


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


Sentence Summary

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

Paragraph Summary

This MIP will adapt the open source contract from Uniswap to create a reserve DAI/MKR.

It will keep the main method, the swap, remove the fix fees to be changeable via a governance parameter.
It will also remove the ‘share’ token creation as we will be the only owner and modify the add and remove liquidity part to be more direct, accessible only by the governance and fees-less.

It will also refactor the flash minting part to be moved out the swap and add a poke call during the update.

Component Summary

MIP31c1: Parameter Definitions: List of governance parameters

MIP31c2: Functions: List of functions

MIP31c3: swap(): Specification for the swap function

MIP31c4: deposit(): Specification for the deposit function

MIP31c5: withdraw(): Specification for the withdraw function

MIP31c6: flashLoan(): Specification for the flash loan functionality

MIP31c7: flashMint(): Specification for the flash mint functionality

MIP31c8: extra feature: extra feature not linked to any functions

MIP31c9: Proposed code: Contains snippet of proposed implementation.

MIP31c10: Test cases: Lists existing test cases, including integration tests

MIP31c11: Spell: Spell for deployment/install

MIP31c12: Security: Comments on the security implications of using CropJoin

MIP31c13: Economic / Governance considerations: Discusses insolvency and liquidity risks, governance and example parameters

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


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 active reserve based on Uniswap V2 AMM. It uses DAI and MKR
as asserts inside the liquidity pool. The DAI/MKR will be the trading pair.
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
    • onchain oracle
    • 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.

How does it work?

The initial deposit (50% DAI,50% MKR) needs to be relatively high to have some liquidity - probably around 1M 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 1M Dai inside the AMM and a 1000 Dai put inside we should have around 0.1% slippage)
We can adjust the % taken to control the slippage.

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.

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 …


The overall logic is based on uniswapV2 contract

The swap mechanism won’t change dramatically, we will add fee as parameter, a poke() call during the update and non used mechanism will be clean up.
mint and burn, will be replaced by deposit and withdraw.

The flash minting part will be moved outside the main method to be independent and fees will be setted separately. They will respect the new standard introduced by Sam.

MIP31c1: Parameter Definitions

  • fees : percentage of the amount takes as fees for each swap.
  • flash_fees : percentage of the amount takes as fees for each flashmint/flashloan.
  • period : period of time between each poke() call
  • poker : pocker contract interface with the poker.

MIP31c2: Functions

there are forth external functions :

  • swap() : uniswap function to swap two token.
  • flashLoan() : Allow flash loan on the token from the reserve.
  • flashMint() : Allow flash mint on the dai from the reserve.
  • getReserves() : To get the reserve

there are five admin functions :

  • deposit() : to deposit some liquidity or reserve.
  • withdraw() : to withdraw the reserve.
  • file(bytes32 what, data) : To change parameters
  • rely(address contract) : To add authorized address
  • deny(address contract) : To remove authorized address

MIP31c3: swap()

  • Three parameters are needed amount0Out, amount1Out, addressTo

  • Should allow swap between two tokens using uniswap formula.

  • A fees is taken during the swap amount * fees parameter

  • Update the reserve after each swap

MIP31c4: deposit()

  • No parameter is needed

  • Should be allowlisted.

  • The call will update the reserve and take into account the tokens send to the contract.

MIP31c5: withdraw()

  • Three parameters are needed amount0Out, amount1Out, addressTo

  • Should be allowlisted.

  • Should be able to withdraw any amount of both tokens.

MIP31c5: flashLoan()

  • Three parameters are needed receiver, amount, data

  • Allow flashLoan on the token inside the AMM

  • A fee is taken, the fee is equal at : amount * flash_fees

  • The amount is return before the end of the transaction.

  • Update the reserve after each flashLoan

MIP31c6: flashMint()

  • Three parameters are needed receiver, amount, data

  • Allow flashMint on the dai inside the AMM

  • A fee is taken, the fee is equal at : amount * flash_fees

  • The amount is return before the end of the transaction.

  • Update the reserve after each flashMint

MIP31c7: extra feature

  • poker.poke() is called during the update phase.

  • poke() sends 5 parameters addressToken, priceDaiCumulativeLast, priceTokenCumulativeLast, daiReserve, tokenReserve, daiBalance, tokenBalance

  • It is call only if the period after the last call is over.

  • The balance is updated after poke() is called

MIP31c8: Proposed Code


MIP31c9: Test Cases

dss-ara test

MIP31c10: Spell


MIP31c11: 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.

MIP31c12: 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 probably when we will 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.

MIP31c13: Licensing


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


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.


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.

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.


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?


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.


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