MIP#: 50 Title: Direct Deposit Module Author(s): Sam MacPherson (@hexonaut) Contributors: None Type: Technical Status: Accepted Date Proposed: 2021-04-07 Date Ratified: n/a Dependencies: n/a Replaces: n/a License: AGPL3+
This proposal provides a smart contract implementation of a Direct Deposit Module for Maker.
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.
MIP50c1: DssDirectDeposit: summary of
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.
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.
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.
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.
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.
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.