Summary:

Deposit $77M DAI into the the DAI Savings Rate Earn Strategy

Motivation:

MakerDAO recently increased the DAI savings rate (DSR) to 1% as a result of the revenues earned by their Real-World Asset (RWA) activities. Olympus Treasury being one of the largest DAI holder, should take advantage of the new savings rate to increase its revenues.

Risk Assessment:

The DSR contract has been live since November 2019, was audited by Trail of Bits, has held at its peak usage over $350M of DAI holders assets and to this date has not suffered any exploit. This makes the Dai Savings Rate smart contract one of the oldest and most battle-tested set of code in the Defi ecosystem. Due to the time in production and significant TVL over time the DSR contract is seen as a low risk contract by the treasury team.

The allocator contract is developed by Olympus, and is an adapted copy of the same allocator contract that is used for all other treasury assets held in allocators (Fraxswap, CVX, Aave etc). The Olympus allocator has been used for a long time with significant value. The risk of asset loss is seen as low by the treasury team. However, this specific allocator deployment is not audited and therefor we suggest that the significant treasury reserve deposit is done in two tranches. It is proposed that a first deposit of 1M DAI is done to encourage potential exploit of the allocator contract. After 2 weeks this is followed by the main deposit.

How Does the DSR work?

  • Dai holders can lock their Dai into the DSR smart contract at any time. Once locked, Dai continuously accrues to the users balance, based on the current DSR.

  • Dai holders can earn savings automatically and natively while retaining control of their Dai. The DSR smart contract has no withdrawal limits, deposit limits, or liquidity constraints

Source: https://github.com/makerdao/community/blob/master/faqs/dsr.md

In regards to Treasury assets needed to conduct market operations under RBS, note that:

  • Deposit and withdrawals can be done at any moment. There are no lock-ups and no fees for using the Dai Savings Rate.

  • Twice the total of DAI used by RBS for the last completed month will remain unstaked in the Olympus Treasury.

Initially, the RBS contract/ new Treasury would be replenished when/if needed by executing withdrawals manually from the DSR contracts.

Eventually, RBS contract will be able to interact directly with the DSR contract which would remove the need for an intermediary manual transaction.

Execution

Deposit 1M DAI from reserves to DAI Savings Rate module via Olympus Allocator.

After 2 weeks follow up with the main $76M deposit.

References

The Olympus Dai Savings Allocator is currently deployed to https://etherscan.io/address/0x0EA26319836fF05B8C5C5afD83b8aB17dd46d063#code

Allocator Code: https://github.com/OlympusDAO/olympus-contracts/blob/allocators/contracts/allocators/DSRAllocator.sol

Voting
Voting on the forum will be up for 72 hours after which it will go to snapshot.

In favor of proposal

This poll has ended.

So long as we maintain DAI is a Protocol Reserve Assets, this is a fairly risk off place to keep it in the contract and recognize interest. $76M compounding at 1% is a non trivial number.

Ship it.

I can offer 1.33% APY, feel free to transfer funds to dr00.eth 😜

In all seriousness, happy to see us at least get some yield even if it's not much!

"It is proposed that a first deposit of 1M DAI is done to encourage potential exploit of the allocator contract." is one of the scariest lines i've read in an OIP…but yeah it seems like a good idea even still 🙂 General note that I don't think we should be making any riskier moves ahead of the (to be hired) new treasury manager starting, so they have a relatively clean slate - but this seems simple.

Any specific reason behind 77M but not 100M and why deposit 1M first and then 76M after that? Thanks

    Peter33

    The $77M is because we wanted to hold liquid reserves to refill RBS (And to be conservative we did a 2x Refill amount). Eventually RBS can talk directly to the DSR Allocator but this was a conservative approach. As for the 1M then 76M is was a risk hedge to test out the allocator with 1M, let it bake for two weeks and make sure it operates as intended and then move the rest of the liquidity.

    Just conservative moves.

      Probably it's not good to expose 1M just for testing.

        Peter33

        While I see your position, take the word 'testing' with a grain of salt. The amount we ever decide to put into a new contract always comes with risk but, what risk is acceptable has to be (and was) subjectively decided. We did an exercise on figuring out an acceptable hurdle rate compared to the missed income and the numbers passed the smell test. There's been more than 100M in the DSR Contract before our deposit as well.

        As a thought exercise, maybe think through how much and why you would start with knowing that ultimately you'll be depositing 77M and share your reasoning! =D

            Relwyn Isn't part of the reality that the amount needs to be big enough to attract hackers? Testing with $1000 won't lure anyone to check it out. Whereas$ 1M will make it worth probing, but not end-the-world if it does get hacked. Maybe we need to survey some hackers to see what their "get out of bed for" price is? 😉

                thomasscovell This is exactly it. How much is needed to create a race condition with potential exploiters?

                What is new is our allocator, which does not have any complicated logic, the base contract has been audited and the changes are minor. However, it is still a new deployment and considering how much reserves we propose to deposit I suggest safety first.

                A recent example is the Bond Protocol exploit, which was for ~$300k basically one day after the bond auction concluded.

                Also to you first comment. I agree that we should hand over a pretty clean slate to the new treasury team, but not at the expense of low hanging income.

                  2 months later
                  Write a Reply...