The Next Step for Stablecoins: Decentralized Oracles
Analyzing how stablecoins approach price feeds
Stablecoins are called by some the holy grail of cryptocurrencies. They are an experimental technology aimed at creating cryptocurrencies pegged to the value of an asset which is considered to be “stable.” Most commonly, stablecoins are pegged to the US Dollar. Much has been researched and written about stablecoins, like the recent reports from Blockchain, Metastable or Consensys.
In this post, we’ll first provide a brief general description of the types of stablecoins being created in the blockchain space. Then, we’ll look at how each type of stablecoin handles price feeds (the mechanisms that feed price data to the systems) and specifically at how some of the most popular stablecoin designs plan to implement oracles. Finally, we will assess the pros and cons of the oracle systems proposed.
1. An Overview: Stablecoins
The main purpose of a stablecoin is to protect its owner from the volatility inherent to many cryptoassets. Most designs do this by pegging their value to the value of the U.S. Dollar, which provides the target price considered stable in the short and mid-term. Some projects also have plans to shift their peg towards crypto-native assets in the long term future.
So, how does a stablecoin achieve its desired stability? There exist mainly 3 types of systems:
- Fiat-collateralized: these coins are an IOU redeemable for $1 with the issuing company. The issuer deposits a certain amount of dollars into a bank account and issues the same number of stablecoins into the market. When a user wants to liquidate a coin back into USD, the company responds by sending them the money. This design is simple and can stand crypto market crashes well, but it is completely centralized as you need a custodian to store the fiat money, and that poses transparency and trust challenges.
Popular examples of fiat-collateralized stablecoins that are live are Tether, TrueUSD and USDC.
- Crypto-collateralized: these are coins which have another cryptocurrency as collateral, but are still pegged to $1. Since the collateral handled by the smart contracts is a volatile cryptocurrency, they are usually over-collateralized to better handle price fluctuations. Although they are more complex and are tied to more volatile collateral, they are designed to be less centralized and can be audited transparently through records on the blockchain by design.
Examples of crypto-collateralized stablecoins are Dai (live) and Reserve (pre-launch).
- Algorithmic: algorithmic or seignorage shares stablecoins do not rely on collateral, but rather incorporate elastic supply mechanisms where a central-bank-like algorithm influences circulating supply to keep the exchange rate as close to the peg as possible. Their complex designs usually involve an opportunity to earn some type of “dividend” (shares) for its holders, called seignorage shares. They are not tied to any other crypto or fiat currency, but they are also the most vulnerable to market crashes.
Designs along these lines is pursued by projects like Kowala, Terra and the now defunct Basis.
Use cases for stablecoin technology vary on a case by case basis. Some stablecoins like DAI seem to be well suited to be the medium of exchange of choice for decentralized applications. These use cases are normally examples of how money can be locked up for a long time. Others common use cases for DAI and stablecoins like it are related to avoiding a certain degree of trading volatility on the open market.
Fiat-collateralized stablecoins are represented dollar-for dollar by collateral off-chain, and their users choose to trust this fact. In that design, trustless price feeds are irrelevant. For our price feed analysis, we will focus on the other two types: on-chain collateralized and algorithmic stablecoins.
2. Price Feeds: Stablecoin Oracles
Currently, on-chain collateralized or algorithmic stablecoins built using blockchain smart contract technology have no access to price feed data regarding their exchange rate to the USD (or whatever peg). Smart contracts can’t access real world data on their own, so they are unable to check even the simplest contextual information about their performance or overall system health.
Oracles are a fundamental component to any stablecoin’s base functionality. An oracle, in relation to blockchain technology) is a system built to feed data to smart contracts. For example, oracles are used to gather data about exchange rates of assets. This is a technical challenge that different stablecoins approach differently. We’ll now look at how 6 different stablecoin designs handle this issue (or plan to as stated in their whitepapers).
2.1. Dai
Dai is is an on-chain collateralized stablecoin, and stands by far as the most popular stablecoin live on the Ethereum mainnet. It currently has around $248 million locked in collateral, which amounts to around 1.95% of all ETH in circulation.
MakerDAO defines oracles in the DAI whitepaper as “Ethereum accounts (either contracts or users) selected to provide price feeds into various components of Maker Platform.” Recently, we spoke with Mariano Conti, their Head of Oracles, who told us that “oracles are the weakest link of any blockchain project, and they just cannot fail.”
The MKR token is MakerDAO’s governance token. It allows holders to perform certain actions intentioned to keep DAI as stable as possible. One of these crucial functions is choosing the set of trusted oracles. As stated in their whitepaper:
“The Maker Platform requires real time information about the market price of the assets used as collateral in CDPs in order to know when to trigger liquidations…MKR voters choose a set of trusted oracles to feed this information to the Maker Platform through Ethereum transactions.”
One of the components of this fairly complex system is the Medianizer, a the smart contract that provides the reference price for DAI. It maintains a list of the accepted price feed contracts and a record of the prices reported by each address. Every time a new price update is received, the contract computes the median of all those and the value is updated.
There are currently 14 active price feeds. The decision to include or exclude one particular oracle follows Maker’s governance framework. The oracles’ activity reporting the price of ETH to the system can be visualized with this really cool tool built by mkr.tools.
The MKR token also allows holders to perform global settlement, a mechanism that acts as a backstop to possible attacks.
“Global Settlers are external actors similar to price feed oracles and are the last line of defense for the Dai Stablecoin System in the event of an attack. The set of global settlers, selected by MKR voters, have the authority to trigger global settlement.”
2.2. Reserve
Reserve is building a stablecoin aimed at becoming a universal store of value that can provide people around the globe with a safe asset to store their money in. The project hasn’t launched yet, but has outlined its design in a whitepaper and secured funding from well known investors.
The plan for the Reserve protocol is to start out as a “substantially centralized fiatcoin, and over time each protocol component will be migrated on-chain and released from control by the founding team, eventually becoming fully decentralized.”
The whitepaper outlines the decentralized phase with the Reserve stablecoin being collateralized with on-chain assets. We will analyze how this design is affected by the use of oracles.
In section 5.4, the Market Feed is described. It is composed of an on-chain Record Book that tracks the data reported by the collection of off-chain trusted Reporters.
“Each Reporter is a program running outside the Ethereum blockchain and inside a secure, trusted execution enclave. At launch, we plan to rely on reporters we build ourselves.” These reporters will have the following properties:
- “Each secure enclave provides cryptographic remote attestation of the installed program.
- Each secure enclave provides read-and-tamper-proofing of Reporter memory.
- Each Reporter runs a distinct implementation of the market-summarization program.”
Reports summarize the last 30 minutes of trading data from each major exchange selected. The Record Book compares reports coming from the different Reporters. The aggregation method, although not fully specified, punishes minority reports by taking away their authorization. If there’s not an agreement at all, it is concluded that not sufficient information is available.
2.3. Basis
Although the Basis project shut down in December due to concerns around U.S. securities laws, it was one of the most promising approaches to building an algorithmic stablecoin, and its design has influenced other projects in the space. Let’s take a look at how the late protocol planned to deal with price data.
Basis’ whitepaper outlined a price-stable cryptocurrency with an algorithmic central bank. The Basis protocol defined a target asset to stabilize against (i.e. USD), oracles monitored the Basis-USD exchange rate and the protocol expanded and contracted the supply of Basis tokens in response to deviations of the exchange rate from the peg.
“If Basis is trading for more than $1, the blockchain creates and distributes new Basis… If Basis is trading for less than $1, the blockchain creates and sells bond tokens in an open auction to take coins out of circulation.”
Regarding the specifics of the oracle system to be implemented, Basis mentioned the 3 possible implementations: a single trusted feed (like an exchange’s API), a delegated decentralized feed (a small group of feed uploaders selected by token holders) or a fully decentralized Schelling point scheme, acknowledging the superior qualities of the latter:
“The trusted feed and delegated decentralized feed approaches are easy ways to securely bootstrap the protocol, with some sacrifices to decentralization. The Schelling point scheme is more novel, but we believe we can make it robust by properly engineering its incentives.”
2.4. Terra
Terra is a stablecoin that aims to peg its price to a basket of currencies, much like the IMF’s SDR does today. At genesis, the composition of the basket will mirror that of the SDR, but will eventually evolve to include other assets like gold or timber.
“This approach frees Terra from the monetary policies of any one government, and eventually allows it to transition to a completely fiat-independent monetary policy regime.”
To access price data, Terra plans to implement a “Price estimation via deposit holder vote” system.
- “The system defines “stability providers,” users with a significant stake in cold deposits in the stability reserve of the system.
- Every n blocks, stability providers cast their vote on what they think the exchange rate for Terra was. These votes are all cast on the same block, and the votes that exceed the block size are disregarded.
- The weighted median of the votes is taken as the true exchange rate. A part of the stake of the voters who voted outside 1 standard deviation is taken, and rewarded to voters who voted within. The punishments / rewards are calibrated by the system every vote to ensure that a sufficiently large portion of the stakeholders vote.”
The design combines a delegated price feed with a stake-based assignation of the reporting tasks amongst “stability providers”, who are then rewarded or punished based on their deviation from the weighted median.
2.5. Kowala
The Kowala whitepaper defines a method for building a set of asset-tracking algorithmic cryptocurrencies, each one designed to maintain a close one-to-one peg to currencies like USD, EUR or JPY.
To provide price data, the protocol proposes a mining mechanism that includes reporting price data.
“The price oracles are expected to be independent, highly-motivated miners who determine the data used to calculate the market price of kUSD… To pay for oracle rewards, a small amount of the newly minted amount for each block will be deducted and placed into a system account called the oracle account.”
The design selects eligible reporters by their stake in the network. “Only eligible miners can participate as oracles. To be eligible, a miner must maintain a minimum stake of mUSD (currently set at 6 million, but subject to change in the future) and not be banned by a majority of other oracles.”
How the protocol’s algorithm will weigh reported data is “still under development.” The team mentioning that it will include data coming from a simple majority while weighing recent reports more heavily than older ones.
2.6. Celo
Celo aims to remove the barriers for large-scale adoption of cryptocurrencies as means-of-payment. The protocol proposes stable tokens pegged to fiat currencies, such as the US Dollar, to minimize volatility. Tokens in circulation are backed by a diversified, overcollateralized, and publicly auditable crypto-asset reserve.
Its whitepaper is still request-only. In section 3.4. it delves into Price Discovery mechanisms.
“To determine the price of Celo stable currencies, we use a Schelling-point scheme amongst bonded stakeholders, with the weight of a stakeholder’s vote dependent on the amount of Celo Gold at stake at the time remaining in the bond.”
The protocol relies on the incentives for truthful reporting that bonded stakeholders have. Their incentive to provide data that drives up the price and provides them an early overvaluation of their stake is avoided by the long term devaluation of the coin if it deviates from the actual exchange rate of its peg.
3. Assessment: Advantages and Vulnerabilities
When talking about non fiat-collateralized types, a stablecoin is as stable as the price data it is fed.
As stated in Mastering Ethereum, “when considering the use of an oracle be very careful about the trust model. If you assume the oracle can be trusted, you may be undermining the security of your smart contract by exposing it to potentially false inputs.”
Data retrieval stands, in the stablecoins evaluated by our team, as the most vulnerable part of every design. Let’s take a look at this from a few different perspectives.
Trust
Trusted feed models, like the one implemented in the current design of Dai, are vulnerable to attacks derived from centralization and collusion. This model can work for the initial stages of a stablecoin as it grows into a more decentralized stage, and it is a reasonable approach given the complexity of developing a decentralized oracle solution. That said, it is not scalable long term. Simply put, the future of DeFi should not rely on 14 people (or 100, for that matter).
The most decentralized approach to handling oracles is to rely on a trustless Schelling scheme. The Reserve team has at one point explored the vulnerabilities to manipulation that these type of oracles face:
“Reputation systems have been proposed as ways to protect schelling oracles from Sybil attacks. Such systems do increase both the capital and time costs of attacks, but these protections are unlikely to be effective in the long run. An attacker can still make an arbitrary number of fake reporters and run them honestly until their reputation accrues enough to control the majority of votes.”
This attack vector does indeed exist, like 51% attacks on any cryptocurrency are viable in theory. In practice, the probability that oracles solutions with the right incentives in place are vulnerable to a majority attack is similar to that of cryptocurrencies like Bitcoin or Ether. Even if this attack was to happen, in Witnet’s reputation design, having 50% of the system’s reputation gives you a 40% probability of being elected to fulfil a data request.
Complexity
Most designs imply a shift towards a fully decentralized approach to price feeds. Some suggest building oracles in-house for their stablecoin implementation. Is this really feasible for projects whose main focus is building a stable cryptocurrency? A data oracle is one of the most complex infrastructure challenges across the blockchain space. This should be a completely separate project for a team to build in parallel to a stablecoin, and creates implied risks and challenges.
There comes a point in time where, for those who follow the in-house development route at first, the availability of general purpose oracles whose sole purpose is to help systems like stablecoins gather data in a trustless way proves to be much more valuable for the long term sustainability of a price feed mechanism. Reserve, for example, already mentions in their whitepaper that decentralized aggregator oracle solutions are their preferred choice for the protocol, and that they are likely to switch over to one solution of this kind once they gain traction and adoption.
Although scaling is said to be one of the biggest challenges that blockchains face, data availability is one issue that should be solved before that. Why scale a blockchain when it can’t access data from outside its own system? For projects like stablecoins, whose connection to price data is continuous and recurring, the process should be automated in the long term through data oracles rather than relying on people’s inputs.
Stablecoins are a young experiment, but one worth getting excited about. As technology advances, designs that explore models which are not necessarily pegged to the US Dollar in the long term will be built, and availability of multi-collateral for these coins will open up a lot of possibilities. For them to become fully trustless, which is one of the main purposes of decentralized technology, a long term shift in the way they access price data should take place. Witnet can help.
All teams mentioned in the post were contacted for feedback. Special thanks to Mariano Conti from MakerDAO for providing feedback and corrections.
