The MakerDAO community recently reactivated the DAI Savings Rate (DSR) providing a 1.00% variable yield natively streamed by the Maker protocol to all DAI holders that opt in. This effectively offers any DAI holder the opportunity to earn a low risk yield by depositing their DAI into the DAI savings rate (DSR) smart contract. The DAI remains in the DSR contract until the user withdraws (at any time they choose) and is not rehypothecated or lent out. The DSR doesn’t change depending on the amount of funds pooled (different from every single other DeFi protocol that rewards staking).
The DSR was first introduced in 2018 and Compound was an early supporter but has since deactivated it as the DSR rates have been negligible for the past few years. We propose the reactivation of the DSR in Compound so users can have direct access to this low risk base DeFi yield.
Here is the link to the post where the DSR compliant implementation was phased out.
The MakerDAO DSR contracts are still at the same addresses - but in the interest of clarity, the address set that should be configured for the Compound cDAI Delegate Contract should be:
To implement these items need to be completed: the cDAI implementation to go back to the DSRSweep. Change the DAI interest rate model to account for the DSR rate.
These addresses can (and should) be checked against our chainlog.
It should be noted that the DSR annual yield is determined by Maker Governance participants via Executive vote, and is subject to periodic future adjustments.
I’m currently taking a look into this and there is a nuance to the existing implementation which seems off.
The current DSR IRM enforces a max borrow rate pre-kink that is equal to the stability fee of ETH-A + a small gap, which is 1.5% (below current cDAI market rate). This might have been comparable years ago when it was used; however, currently, the min collateral ratio of ETH-A is 145% while cETH has a collateral factor of 83% (ratio of ~120%). ETH-B has a closer ratio of 130% and 3% stability fee although I’m reluctant to say this is on par with cETH-cDAI pair.
I think our options are either remove the peg to a stability fee or use the higher rate of ETH-B instead. Thoughts?
While I agree that they are not equivalent, it makes a lot of sense to take into account ETH-B stability fee in the Dai IRM. However, I may be cleaner to have an IRM independent from the stability fee, but whose parameters have been chosen in order to take it into account.
Personally, I think it would be better to remove reference to Maker vault stability fees (borrow rates). There are pretty significant differences between Maker vaults and Compound (Maker oracle delay, differing liquidation ratios, etc), and Maker has a bit less liquidity constraints so benchmarking optimal borrow rate to Maker vault rates might lead to the optimal rate at Compound being too low to preserve market liquidity in some cases.
Spitballing here but I think a reasonable DSR IRM could be something like:
I was asked to take a look at this proposal by other community members to see if it warrants an audit before being submitted. While the prior implementation was actually audited by OpenZeppelin back in 2020, a lot of time has passed since then. We’re currently exploring whether this warrants another audit to avoid any potential integration issues.
I’ll let you know by end of the week if an audit is warranted and propose a timeline for completion if so. You can reach out to me directly at my contact details below if you have questions or would like to coordinate further:
Note that an other path is still possible: using the same IRM as for other assets, with parameters that has been determined with the DSR in mind, like the one given by @monet-supply:
This has the benefit of not introducing new code to the Compound protocol. It would obviously not react dynamically to the update of the stability fee of ETH-B and to the DSR rate, but it may not be a big deal.
After consulting with the OpenZeppelin audit team, we’ve decided that another audit is warranted, primarily to ensure no integration issues are present and that the process of rolling back an upgrade does not introduce unexpected behavior. We are starting an audit of the Optimism Comet deployment next week so we are planning to conduct an audit of the DSR proposal afterwards, starting Feb 20th.
In the meantime, I’d like to propose the following timeline, based on our recent draft CIP for contribution policies that lays out a process for community feedback and quality assurance. I start by retroactively recognizing steps that have already been taken in this forum thread.
Idea Review (started Dec. 16th) - The idea was posted in the forum to solicit community feedback and support.
Developer Review (started Jan. 18th, current stage) - Code to implement the idea was shared with the community to solicit feedback.
We are currently at this stage as the community reviews the implementation and discusses alternative paths such as those suggested by @MathisGDabove. An external audit is now being scheduled.
Community Review (suggested to start by Jan 30th) - This starts once @MakerGrowth finalizes the design of their implementation and shares tests and simulations of the proposal changes with the community.
In this case, if @MakerGrowth does not intend to change the current proposal design, they just need to provide simulations for community review. To ensure community feedback is received and everything is finalized one week before the audit starts on Feb. 20th, I’d recommend reaching this stage by Jan. 30th.
External Review (scheduled to start Feb 20th) - This stage consists of receiving an external audit from OpenZeppelin and then addressing any issues that might be raised. A frozen commit of the code should be provided one week prior. We estimated that the audit and fix reviews should be finished by Mar. 10th at the latest.
Final Review (estimated by Mar. 10th) - The final state of the PR and simulation testing is shared with the community following the audit ahead of the on-chain submission of the proposal and vote.
While this process might seem long, I believe it is a necessary one for ensuring a contribution has incorporated every possible quality assurance check, audits are successful and community feedback has been addressed. The community is always grateful for contributions such as this and so this process is intended to ensure that it has the highest chance of success for adoption.
I’ll also note that this is all a suggestion based on a CIP draft that has not yet been adopted by the community. The timeline in this case is also longer than it might otherwise be due to our current audit backlog. In the future, similar proposals could pass through each stage rather quickly, especially if any necessary audit was already scheduled in advance.
I’m happy to discuss this plan further in this thread or directly with @MakerGrowth over chat or video call. @jbass-oz will also be available to answer general questions about the Contribution CIP in the community call next Wednesday.
I’m happy to share that OpenZeppelin’s security assessment of the DSR reactivation is complete. This took more time than expected due to a need to investigate potential edge-cases but the report is now ready to review here.
While no major security issues were found, the surface area of the Compound V2 and
MakerDAO protocols is quite large so the security of this upgrade does depend on a few specifics that should be carefully considered. We’ve communicated these considerations to both the @MakerGrowth and @compound.finance teams over the course of our security assessment. I encourage the community to read our conclusions below and refer to the report for additional details before voting to approve any upgrade.
After further discourse and fixes, there are two lingering issues that will need attention
from the community:
As highlighted in M01, the Dai Savings Rate proposal has many variables that will affect
interest rates. Passing any such proposal should include thoughtful decisions for these
variables’ values. Parameters such as blocksPerYear and SECONDS_PER_BLOCK , while
seemingly simple at first glance, are used in conjunction with other variables to determine how
interest rates behave (particularly, see gapPerYear and its derivative gapPerBlock ). Below
is a chart of different interest rates computed from the getBorrowRateInternal function
under different parameters. This chart is not comprehensive and meant only to demonstrate a
few sample parameter differences. We encourage the Compound community to discuss and
decide on the global values within this proposal.
In reference to L01, an error in setting the interest rate model would catastrophically impact
the cDai market. No such error is caught or handled. And while the risk of this occurring is
minimal, we encourage the Compound community to make sure that any DSR proposal
ensures that such an error will revert the deployment or immediately return the model to its
original setting.
