MIP50: Direct Deposit Module

MIP50: Direct Deposit Module

Preamble

MIP#: 50
Title: Direct Deposit Module
Author(s): Sam MacPherson (@hexonaut)
Contributors: None
Type: Technical
Status: Request for Comments
Date Proposed: 2021-04-07
Date Ratified: n/a
Dependencies: n/a
Replaces: n/a
License: AGPL3+

References

Sentence Summary

This proposal provides a smart contract implementation of a Direct Deposit Module for Maker.

Paragraph Summary

The Direct Deposit Module interfaces with third party lending protocols to enforce a maximum variable borrow rate for selected assets. Maker Governance is able to pick a target variable borrow rate, and the module will automatically deposit/remove liquidity to ensure that target rate is hit.

Component Summary

MIP50c1: DssDirectDeposit: summary of DssDirectDeposit contract.

MIP50c2: Testing: summary of tests.

MIP50c3: Risk considerations: comments on risk implications of adding Direct Deposit Modules.

MIP50c4: Security considerations: comments on security implications of adding Direct Deposit Modules.

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

Motivation

A big problem with third party lenders is they are unable to offer a stable variable borrow rate. This is undesirable for end users as they may be stuck paying extremely high interest rates during borrow demand spikes. By providing extra liquidity from the Maker protocol, these lending markets will be able to offer certainty to their users. In exchange, Maker is able to earn interest off this excess borrow demand.

Specification

MIP50c1: DssDirectDeposit

The Direct Deposit Module will provide a number of implementations to connect with any third party lender governance desires. This section describes the general format of how these modules should behave.

All Direct Deposit Modules implementations must provide a way for governance to set the target interest rate bar. They will then provide a function to automatically add/remove liquidity based on the difference between the current borrow interest rate and the target. This automatic re-adjustment should take into account things such as the ilk debt ceiling, available debt to pay back as well as available liquidity in the lending pool.

Direct Deposit Modules should be equipped with a permissionless cage() function which can gracefully close out the position in the event one of the underlying assumptions changes (such as the interest rate model changes) or vat.cage() is called. There should be a time limit imposed on closing out the position such that bad debt can be pushed to the vow in the case no liquidity is ever available.

An initial implementation for Aave DAI is provided, but this document is not intended to be specific to that lender / asset.

MIP50c2: Test Summary

Mainnet fork tests should be added for each new contract to test against real world conditions. The tests should cover all possible scenarios.

Tests for Aave DAI can be found here.

MIP50c3: Risk considerations

The primary risk comes from the inability to close out the deposit in the event the lending pool runs out of liquidity. Most third party lenders operate on an interest rate curve which can spike to very large numbers if all the liquidity is removed. It is because of this interest curve the risk due to lack of liquidity alone is small.

MIP50c4: Security considerations

When interfacing with third party lenders we are assuming some of the risks of the protocol. If an exploit is found for the lender then it’s possible to lose the deposited amount. Deposit modules should take this into account by providing defensive programming structures to protect against known attack vectors. It is better to err on the side of caution and close out the direct deposit from a false positive then have something preventable slip by.

MIP50c5: Licensing

9 Likes

Is there an opinion on how deep/liquid a market must be to make use of this?

I like the concept, but we also don’t want to end up taking on risk that’s not properly managed in size and quality.

There is a discussion thread here where the Aave folks can probably better address your question. I’d like to keep this thread to technical discussion only.

1 Like

A summary of this vs. aDAI vaults would be super helpful. It seems like the default choice and knowing what kinds of tradeoffs we’re making seems important.

1 Like

You can think of them as basically the same, but the regular aDAI user vault version being strictly worse as we need to pay some profit out the vault owners. The risk profile is nearly identical to the protocol as the collateralization ratio would need to be 100% or near 100% in both cases.

1 Like

Thanks :slight_smile: Could you expand on “we need to pay some profit out the vault owners”?

Some more questions :

  • Is there a difference in technical risk?
    • Are the consequences of a bug in either implementation the same?
    • Is there the same likelihood of a bug in either implementation?
  • Is there a difference in governance overhead?
    • Does MIP50 by itself mean less governance involvement?
    • Does MIP50 make it easier to get rid of ultra-small-DC collateral types?
  • Is there a difference in usability?
    • Are gas costs comparable or widely different?
    • Does MIP50 impose fewer practical constraints on the user who wishes to borrow DAI from Aave?
  • Do you think it make a difference for Aave whether we use one solution or the other?
1 Like
  • Is there a difference in technical risk?

The regular vault may be marginally safer from a technical perspective just because the code already exists and is well tested. We will be auditing the direct deposit module though, so I don’t think this is a concern.

  • Are the consequences of a bug in either implementation the same?

It depends on the bug, but probably yes.

  • Is there the same likelihood of a bug in either implementation?

Again, the regular is marginally safer, but for practical purposes I would consider the technical risk roughly the same.

  • Is there a difference in governance overhead?

Yes. The regular vault would require more active SF maintenance to maintain a reasonable borrow rate target. Without the permissionless re-adjust we would probably continually be over/undershooting and potentially giving Aave a better deal than our own vaults (which we obviously don’t want to do).

  • Does MIP50 by itself mean less governance involvement?

Yes, whether this is aDAI or cDAI or whatever we can use this tool to automate providing liquidity to secondary lenders.

  • Does MIP50 make it easier to get rid of ultra-small-DC collateral types?

I hadn’t actually considered this until @iammeeoh brought it up on the chat, but yes I actually think this could be a nice by-product. Outsourcing this type of work to a secondary lender makes sense.

  • Is there a difference in usability?

Yes, the regular vault requires users. MIP50 is fully automated and can operate completely behind the scenes.

  • Are gas costs comparable or widely different?

A regular vault gives you DAI for aDAI and that’s it. MIP50 will do all the actions of putting the aDAI in the pool and stuff. Overall performing the same actions will be the same gas cost, but they do different things so it’s not really an important comparison.

  • Does MIP50 impose fewer practical constraints on the user who wishes to borrow DAI from Aave?

Yes. To within the debt ceiling constraints they can assume DAI borrow rates will not go over the target rate we set.

  • Do you think it make a difference for Aave whether we use one solution or the other?

Yes, MIP50 gives them a stronger guarantee to their users. They can promote DAI as the best stablecoin to get leverage with both on L1 and their expansion into L2.

Hope these answers help :slight_smile:

5 Likes

Thanks a lot! As I understand it, MIP50 is two things:

  1. Direct Deposit
  2. Automatic rate targeting

In theory we could have governanceless rate targeting with a smart aDAI vault. Aave could also automatically mint aDAI and draw DAI, as a user, from a regular aDAI vault (this would recreate a simple experience for their users). If I’m right about this, the main advantage of MIP50 is to package all of the above in one module, making life easier for Maker governance and giving Aave preferential access to our credit, assuming we’re not going to have both aDAI vaults and MIP50.

I’m overall for it :slight_smile: Considering audit durations though, why not deploy aDAI vaults in the meantime?

You got it.

We could, although Risk still needs to do their assessment in either case. I’m expecting the audits to be done before then as everyone is very busy with other stuff at the moment. Audits are nice because they can be done in parallel.