At launch, Multi-Collateral Dai will include a feature called the Dai Savings Rate (DSR).

A person who holds Dai can lock and unlock Dai into a DSR contract at any time. Once locked into the DSR contract, Dai continuously accrues, based on a global system variable called the DSR.There are no restrictions or fees for using DSR other than the gas required for locking and unlocking.

For example: If the DSR is 2%, a user who locks 100 Dai into DSR mode, and keeps it locked for a full year, would earn two additional Dai which will automatically be added to their wallet when the Dai is unlocked. Anyone can “lock” their Dai into DSR mode using a simple UI.

This creates a whole new dimension of incentives for balancing the supply and demand for Dai. This model allows for capital to be more efficiently deployed while still fulfilling its core role of providing users with strong, decentralized stability.

How it works

The DSR is funded out of the Stability Fees paid by CDPs. For example, if the average Stability Fees collected on CDPs is 3%, it could be used to fund a DSR of 2%.

The DSR helps balance supply and demand of Dai and will be one of the monetary policy levers that decentralized Maker Governance can control.

It is a global parameter that needs to be adjusted often to deal with short-term changes in market conditions of the Dai economy. This is in contrast to Risk Governance, which is a long-term process that involves setting Stability Fees, and other risk parameters individually for each collateral type.

Together, these two mechanics provide a set of tools to guard Dai stability both in the short-term and long-term.

Governance of the DSR

As a part of the governance process in Multi-Collateral Dai, Maker Governance will choose a Rates Policy Oracle that has restricted access to modify the DSR in real time within a predefined interval set by governance. The Rates Policy Oracle also has other cryptoeconomic protections; most importantly a localized emergency shutdown mechanism that allows the Maker Governance Risk Teams to swiftly react to turn off the DSR Oracle until it can be replaced in an MKR holder vote.

The Rates Policy Oracle will be operated by a Risk Team, or jointly by multiple Risk Teams, chosen by Maker Governance to carry out Rates Policy according to a predefined goal. The Maker Foundation is currently in the process of doing an independent research study on the optimal decentralized Rates Policy strategy. However, the fundamental logic that the Rates Policy Oracle will follow is simple:

• • If the market price of Dai is below 1 USD, the DSR will increase. This boosts demand and stifles supply, by incentivizing more Dai holders, and fewer CDP users, which should increase the market price up towards the 1 USD target price.

• If the market price of Dai is above 1 USD, the DSR will decrease. This stifles demand and boosts supply, which should reduce the market price of Dai down towards the 1 USD target price.

This logic is very similar to what was described in a recent post about the Stability Fee increase, as the Long Run Balancing Mechanism of Dai. DSR adjustments are basically the same, except that with the DSR, incentives for Dai holders are also affected in addition to the existing effect of Stability Fee adjustments on CDP users.

Because there is now a double effect where the DSR both increases Dai demand while reducing Dai supply, we expect that the DSR will result in overall lower borrowing costs for CDP users over time.

As with all the other Risk Parameters controlling the system, this new initiative will be activated through the direction and control of Maker voters.

Please join us in our subreddit or in our Rocket chat to discuss the DSR, and to be notified of the date for a special community call where we will go into greater detail on the mechanics, economics, and timelines associated with the new incentive.

— -

Changelog Aug 31, 2018:

• • replaced instances of ‘Reward Rate’ with ‘Dai Savings Rate’

• • first person pronouns updated to generic impersonal

• • removed marketing material for inclusion in follow up post

• removed use-cases for inclusion in follow up post