Compound DSR Proposal

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:

  • Dai: 0x6B175474E89094C44Da98b954EedeAC495271d0F
  • Vat: 0x35D1b3F3D7966A1DFe207aa4514C12a259A0492B
  • Pot: 0x197E90f9FAD81970bA7976f33CbD77088E5D7cf7
  • DaiJoin: 0x9759A6Ac90977b93B58547b4A71c78317f391A28

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.

5 Likes

Excited by this proposal !

Just wanted to note that the old DaiInterestRateModelV3 available at 0xfed941d39905b23d6faf02c8301d40bd4834e27f may not be reusable as is, because of the number of seconds between each blocks that it uses for getSupplyRate (see issue 230).

3 Likes

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?

5 Likes

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.

3 Likes

I’m not really seeing any downsides to supporting this proposal. If someone knows of any, please let me know.

1 Like

We changed the DAIInterestRateModel to V4 to fix this: Wrong seconds per block in the DAI interest rate model · Issue #230 · compound-finance/compound-protocol · GitHub

2 Likes

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:

  • Base rate: DSR (currently 1%)
  • Optimal rate: DSR + 3% (currently 4%)
  • Max rate: DSR + 40% (currently 41%)
1 Like

Hi, we have sent a PR to Compound’s Comet GitHub repository containing our proposal’s data.

Here is a list of the proposed actions:

Action 1 - Set the cDAI implementation back to the cDaiDelegate contract:

  • Target: 0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643 (cDAI)
  • Function called: _setImplementation(address,bool,bytes)
  • Params:
    • 0: 0xbB8bE4772fAA655C255309afc3c5207aA7b896Fd (cDaiDelegate)
    • 1: true
    • 2 (params for cDaiDelegate._becomeImplementation(daiJoin, pot)
      • 0: 0x9759A6Ac90977b93B58547b4A71c78317f391A28 (DaiJoin)
      • 1: 0x197E90f9FAD81970bA7976f33CbD77088E5D7cf7 (Pot)

Action 2 - Set the IRM for cDAI back to DAIInterestRateModelV3:

  • Target: 0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643 (cDAI)
  • Function called: _setInterestRateModel(address)
  • Params:
2 Likes

@MakerGrowth Thanks for posting these details.

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:

1 Like

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.

  1. Idea Review (started Dec. 16th) - The idea was posted in the forum to solicit community feedback and support.
  2. 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 @MathisGD above. An external audit is now being scheduled.
  3. 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.
  4. 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.
  5. 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.

1 Like