Introducing Sai, our first generation stablecoin

The Maker development team first came up with the idea for a simplified stablecoin last summer. At the time, we thought that a simple centralized collateral custodian model (i.e. ETH IOU's denominated in USD) would be sufficient for the short term, and we called it Simplecoin accordingly. Our motivation to pursue this effort was two fold. We wanted to ensure that the "blockchain stability industry" would evolve around our technology, and we were extremely interested in the learning opportunity that a functioning stablecoin presents.

However, an individual custodian takes on some level of risk, and no one enthusiastically stepped up to take this risk on. Since last fall, the Maker Development Fund has undergone some significant changes, namely the establishment of the Dai Foundation for its administration. Now this legal entity is almost ready and a sizable Ether development fund has been raised. Thus the Dai Foundation, on behalf of the MKR holders, will undertake to launch it's own generation 1.0 stablecoin.

During the time that passed between coming up with the idea for Simplecoin and the Dai Foundation being ready to launch it, our technical lead Nikolai has iterated significantly on the concept of stablecoins with increased trust requirements. The new stablecoin that we intend to launch is much more sophisticated than the one I announced last year at Devcon. This coin will be called Sai, short for Simple Dai. As one might guess from such a name, it closely mirrors many of the essential concepts that make Dai interesting. If the reader does not know how Dai works, there is a cogent whitepaper and technical purple paper that are available for illumination. This post is going to describe the design choices that make Sai different (simpler) than Dai.

One last point before going into Sai mechanics: this is an emergent research effort. This means that the characteristics of Sai are still evolving, even as we make the system accessible to a wider audience. There are still open questions about how some aspects of Sai will work, and they can only be answered by actually running the stablecoin. The Maker development team is very excited to launch and operate Sai, as this will be one of the most useful learning opportunities that we will ever get.

Sai at a high level

The most familiar characteristic of Sai is the fact that each token is backed by an excess of collateral. This collateral is kept in Collateralized Debt Positions, or CDP's, which create and destroy Sai when they are opened and closed by users. To keep it simple, the only accepted form of collateral is ETH, albeit indirectly (see SKR below). The system technically has the ability to charge stability fees on open CDP's, but this functionality still needs to be fleshed out and will be introduced in a later iteration. Like Dai, the total amount of issuable Sai is controlled by a debt ceiling.

Sai does all of its accounting in terms of USD (unlike Dai which uses SDR). It collects this information from a set of price oracles that is provided upon the initialization of the system. This oracle set will be controlled by the Maker Admin Multisig, and the system trusts it completely. This is one of the main departures from the design of the Dai Stablecoin System, which relies on continuous open market auctions to effectively price both Dai and MKR. As we will see below, trusting the price oracle has a cascading effect that simplifies the CDP liquidation process significantly.

The "Target Price" in Sai is controlled by the trusted price oracle rather than a native autonomous feedback loop. This canonical Target Price gives each Sai token a specific internal USD-denominated value. The system uses this price to account for the value of Sai that is returned when closing CDP's or participating in liquidation sales. It is important to note that there is no native mechanism that forces the market price towards this internal accounting value. However since the utility of Sai is its ability to access the underlying ETH collateral, one can expect an efficient market to hover around this price. Initially, the internal value of Sai will be considered 1 USD. In the future, this may switch to a decaying value as fees are introduced to the system (e.g. the price starts at 1 USD and decays 2% per year).

SKR for proportional collateral ownership

ETH is not directly used as collateral when creating CDP's in the system. Rather, all ETH is kept together in a single liquidity pool and used to create the system's collateral token called SKR. Only SKR can be used to open CDP's in the Sai stablecoin system.

SKR is created by anyone who deposits ETH into the system. This new SKR is given out at a rate that maintains the current ratio of ETH to SKR. The ratio starts at 1:1 and will fluctuate as the total SKR supply changes (described below).

SKR represents a proportional claim on all the ETH in the system. This means that at any time, a user can convert SKR into ETH according to the amount they are converting relative to the total SKR supply. A brief example of claiming ETH:

There are 345 ETH in the system  
There are 678 outstanding SKR  
Bob converts 100 SKR, ~14.75% of the supply  
Bob receives 14.75% of the 345 available ETH, 50.885 ETH  

And one for creating SKR:

There are 345 ETH in the system  
There are 678 outstanding SKR  
The ETH:SKR price is 345/678 = 0.5088  
Bob deposits 100 ETH  
Bob receives 100 / 0.5088 = 196.54 SKR  
Now there are 445 ETH in the system  
There are 874.54 SKR  
The ETH:SKR price is 445/874.54 = 0.5088  

Since the system does its accounting in USD, the value of SKR is fundamentally tied to the USD value of the ETH it can claim. As ETH's USD price and the ETH:SKR ratio both fluctuate, the value of the SKR token changes over time. This value is what the system uses to determine if a CDP has become too risky and needs to be liquidated.

Simple liquidations and the role of SKR

When the system claims SKR from risky CDP's that have been liquidated, it sells it for Sai. Like the collateral auction in the Dai Stablecoin System, this mechanism is to remove outstanding Sai that was issued against this liquidated CDP. The difference
between Sai and Dai here is that the trusted price oracle is able to give an exact value to the SKR for sale:

SKR_USD_price = SKR_supply / ETH_collateral_pool_size * ETH_USD_price  

Thus the system knows exactly how much USD value is left in the CDP and how that compares to the Sai that was originally issued. Since the claimed SKR value is known, the system can sell it directly to Sai holders without first going through an auction process. This means that the mechanism is equivalent to a basic liquidity provider that simply trades 1 SAI for 1 USD * Target_Price worth of SKR collateral until all unbacked Sai has been collected.

If the value of ETH relative to USD falls quickly, there could arise a situation where the CDP's claimed SKR collateral is worth less than the Sai that was issued against it. If this happens, new SKR will be minted until the necessary Sai has been collected. From the Sai holder's point of view, they will get enough SKR to claim an equivalent amount of ETH to the Sai they gave up. However this means that the SKR supply will increase, reducing the claim-power of all existing SKR. This is the downside risk of holding SKR.

Where there is a downside of course there must be a corresponding upside. For SKR, this takes the form of a buy and burn sale. Like the Dai Stablecoin System, SKR will be burned in exchange for Sai collected from CDP stability fees. However the system does not need to perform an auction here either, as the USD price of SKR is known ahead of time. Like the liquidation sale, it will also be a simple liquidity pool where SKR holders can easily trade into Sai. As SKR is burned, the claim power of existing SKR will increase, giving each token greater USD value. The initial versions of Sai will not charge stability fees, and thus this component has not yet been fully designed. When fees are introduced, SKR will have positive cash flow in its own right, making it a valuable Ethereum asset. The details of the fee schedule will be expanded upon in a blog post as it is prepared for launch in the system.

It is important to point out that in the worst case scenario, the value of ETH could fall so far that there isn't enough value to back the outstanding Sai, forcing the Sai holders to take a haircut as well. This is a fundamental risk of holding Sai; however it will be mitigated by requiring a very high liquidation threshold for CDP's.

Sai is temporary

Because Sai requires more trust than Dai, it is merely a temporary solution to the problem of volatility on the blockchain. At any time the Dai Foundation can disable all functionality of the system except normal ERC20 operations and the ability to convert outstanding Sai into ETH at a fixed rate. This action is called global settlement. In practice there will be three conditions that cause the Sai contract to be halted:

  • If a serious bug is discovered and the system needs to be emergency settled.
  • When a new Sai contract is ready for launch with extended functionality.
  • When the Dai Stablecoin System is ready for launch.

Although each Sai instance is a temporary system, the core logic should make it a trustworthy Ethereum asset over the course of its lifetime.

Conclusion

The Sai development process is moving along steadily. Last month, we performed our first internal test. We created a Sai system on the main net, issued Sai by creating a CDP, paid our invoices to the Maker development team with it, and then globally settled the system so they could convert back into ETH. At the time of this writing, we've created a new Sai system that will live for a few weeks while we begin to test an automated market making contract that will allow ETH holders to easily trade in and out of Sai.

We then will begin to onboard capital-providing partner institutions to create a whitelisted version of Sai that can meet real world usecases. We will announce who is participating in a later post. We will then iterate on their feedback to improve the system's usability. The last step is to finalize the fee logic.

As our confidence in the system grows, we will leave Sai instances running for longer periods of time and make them more accessible to the wider Ethereum community. This post is just the first in a series of Sai updates and technical deep dives into our design decisions and development process. Stay tuned as we iterate on this exciting project and finally bring financial stability to the Ethereum blockchain!

Andy Milenius

Read more posts by this author.

Subscribe to Maker Blog

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!