saveDAI: More secure savings via a simpler saver experience

saveDAI’s objectives, design decisions, and how we’re addressing key trade-offs

The driving force behind saveDAI is the belief that we can help more savers protect their savings by making deposit insurance dead simple. To follow through on that belief, we are adhering to two principles:

• saveDAI Principle I: More secure savings
• saveDAI Principle II: Simple saver experience

While these two principles are often aligned — that’s the whole point of saveDAI, after all — occasionally they are at odds. And when they are, we need to make careful decisions about how saveDAI handles those situations.

In our first post — an introduction to saveDAI — we outlined why we’re building saveDAI and what savers can expect once it’s available.

This post goes into further detail about what exactly we’re looking to accomplish, the trade-offs inherent in those goals, and how we’re addressing them.

I: More Secure Savings

Security is saveDAI’s priority. If it can’t increase the security of DeFi savings accounts over the status quo, then it shouldn’t exist.

We define saver security as the likelihood that savers will keep the value of their savings over a given period. Savings security can be compromised by the loss of tokens themselves (e.g., from a bug or hack on the smart contracts) or by a decrease in the value of the tokens (e.g., from adverse financial circumstances or protocol governance failures).

Distinguishing between these two types of risks is useful because it allows us to trade them off against each other. For example, it may be the case that accepting a slightly increased risk of stuck tokens can significantly diminish the risk of token devaluation, netting out to less risk and better security overall.

And that is exactly what saveDAI seeks to do: create a new smart contract to wrap a savings account and protect it against devaluation risks. A new smart contract inevitably adds some risk of stuck or lost tokens, but boosts overall saver security by reducing token devaluation risk.

How our smart contract accomplishes that brings us to principle II.

II: Simpler Saver Experience

The saveDAI smart contract boosts overall saver security by adding deposit insurance automatically for savers. Just as the best line of code is the one you don’t need to write, the best user experience is the one you don’t force your users to have. We believe that removing the extra step will bring more savers into DeFi and secure more of their savings.

Reducing friction is one way to improve the DeFi saver experience, and we’re not stopping there. Since most savers are familiar with traditional savings accounts, we aim to emulate their good parts as much as possible. Here are the primary ways saveDAI does that:

DAI, DAI, DAI

Opening a traditional savings account only requires one currency. For saveDAI, savers will only need to use DAI (with the possible exception of ETH).

When a saver opens a DeFi savings account with saveDAI, our smart contract will go get cDAI (the interest-generating component) and ocDAI (the insurance component). Since the latter can only be bought on uniswap, it would be easiest and cheapest for our contract to ask the saver to provide ETH for the swap.

However, sticking with our DAI-only approach means that instead our contract uses some of the saver’s DAI to make a tokenToTokenSwap for ocDAI. As you’ll see in the next section, this choice influences how we handle the initial saver deposit.

We’re also exploring ways to allow savers to avoid paying gas with ETH — initially this will be possible for savers using an Authereum wallet. And ultimately, we want to make it possible for crypto newbies to go directly from fiat to saveDAI.

Savers deposit; they don’t purchase or swap

Most of DeFi is oriented around tokens. We love tokens — saveDAI benefits from tokens’ transferability and flexibility as both programming interfaces and user interfaces — but the standard acquisition patterns of purchasing or swapping tokens is misaligned with the concept of opening a savings account.

Savings accounts take deposits, and so does saveDAI. Behind the scenes savers are technically purchasing saveDAI tokens with their DAI tokens, but saveDAI abstracts that away. Instead, saveDAI asks savers to simply decide how much DAI they want to deposit, and then saveDAI estimates how much saveDAI to mint and transfer to the saver.

Why an estimate? Because we’re using part of the saver’s DAI “deposit” to purchase ocDAI on unsiwap and the ocDAI price changes with market forces, which leaves a variable amount of DAI remaining to exchange for cDAI.

Even knowing the current price of ocDAI, making such an estimate is a non-trivial budget-optimization problem and would be expensive to execute on-chain — not to mention introduce significant attack surface area. saveDAI therefore handles it off-chain. The front-end estimates the number of saveDAI tokens to create with the saver’s DAI deposit, and then calls the smart contract’s mint function with that value as the sole parameter.

Transparency

The Opyn protocol — from which saveDAI draws deposit insurance — is fantastic; it allows savers to permissionlessly purchase deposit insurance on their savings in the form of put options on their cDAI tokens. Because of its option-oriented structure, however, insurance from Opyn introduces some oddities for savings accounts that saveDAI needs to handle.

Insurance Expiration
Most importantly, Opyn insurance options have an expiration date. The current available version of ocDAI expires on February 10, 2021; after that date, savers won’t be able to make a claim (redeem ocDAI for ETH). Of course, a new term of ocDAI will then be available to cover savings until 2022, but saveDAI savers will need a way to transition to the new version.

It turns out the the best option is actually to not have our current contract handle the transition directly. Instead, saveDAI provides a way (removeInsurance) to unbundle the insurance and the interest-generating portions, allowing savers to recombine with the new term of ocDAI insurance. We’ll publish a second saveDAI contract to enable the transition to the new term of ocDAI and mint a new version of saveDAI (i.e., ‘saveDAI20220210’).

This is one scenario where the saver experience and security are at odds. Under our approach, savers will have to take action to renew their insurance once it expires. Enabling a transition to the new ocDAI within the same saveDAI contract would have been a smoother saver experience, but it also would have added reduced security via a larger attack surface and required an admin to manage the contract — hardly a decentralized solution.

Instead, the saveDAI UI makes insurance terms clear and shows savers a countdown to when they will need to renew. As that date approaches, the saveDAI will allow savers to transition to the new version manually.

Multiple versions of ocDAI
In addition to new insurance terms, we anticipate a proliferation of Opyn option versions with varying costs and insurance coverage to meet a wider distribution of preferences. As an example, more risk-tolerant savers may prefer coverage of only 50% of their principal for half the price.

saveDAI will handle these scenarios in the same way it handles insurance terms. On the smart contract side, it will enable graceful unwinding of the current version and re-bundling into new tokens (e.g., ‘saveDAI20220210–50%’). And the saveDAI front end will allow savers to select their desired insurance version from the available options, as well as to convert from one to the other.

Up-front insurance premium
Because cDAI generates interest continuously, the ideal insurance for saveDAI would be paid for continuously, too. In that scenario, at any given point in time the insured interest rate would be

insured_interest_rate = raw_interest_rate - insurance_premium

where insurance_premium = cost_of_insurance / principal. For example, with a raw interest rate of 8% and a premium of 2%, the insured interest rate — the rate at which the principal is increasing — would be 6%. Simple.

However, this is not how Opyn insurance works today. Instead, ocDAI must be bought fully up-front, which creates a more complex relationship between interest income and insurance payments. Over the full term of the insurance, the insured interest rate works out to the same arithmetic as above, but over any other period the story is different.

Once the ocDAI is purchased, the insured_interest_rate is actually the same as the raw_interest_rate — in our example, 8%. But because the principal was reduced by insurance_premium = 2% to start with, that interest rate is applied on a smaller base.

Crucially, for saveDAI, this means that when a saver looks at the value of their saveDAI tokens immediately after they make a deposit, it will look like they’ve lost money! This violates the premise of a savings account, but unfortunately — until, perhaps Opyn develops perpetual options — there is no way around it.

saveDAI prevents confusion by showing savers exactly what will happen to their deposit and how that will progress over the length of the insurance term. Most importantly, saveDAI shows savers a projected break-even date — the point at which accrued interest will have brought their saveDAI value equal to the value of their original deposit.

A saveDAI deposit with our example interest rate and premium would break even around day 93. Of course, since the cDAI interest rate can change, this is always an estimate, but it will help explain to savers what is happening with their saveDAI. And, the saveDAI UI will update to show the current estimate based on the current cDAI raw interest rate.

Wrapping Up

This post explored how saveDAI secures savings by creating a simpler saver experience. We also previewed how saveDAI handles some of the rough edges of insured DeFi savings accounts.

Stay tuned for an upcoming technical post looking at the saveDAI smart contract.

Get Involved

• See our previous post introducing saveDAI
• Visit the saveDAI website
• Follow saveDAI on Twitter
• Contribute to saveDAI in Gitcoin Grants Round 5!