Reserve Protocol
The Reserve Protocol is the first platform that allows for the permissionless creation of asset-backed, yield-bearing & overcollateralized stablecoins on Ethereum. The end goal of the Reserve Protocol is to provide highly scalable, decentralized, stable money in contrast to volatile cryptocurrencies such as Bitcoin and Ether.
In our view, clear flaws can be demonstrated with many existing stablecoin designs. In the 2018 Reserve Protocol whitepaper, we present arguments for why a widely used stablecoin should implement an exchange rate peg to a fiat currency first and a basket of assets later, using off-chain foreign collateral that has been tokenized by a diversity of issuers.
Furthermore, we believe that open exploration and competition can lead to the discovery of the best type of basket and governance system for ideal on-chain money. There's a lot to explore, and it's better not to keep that under the control of the initial founding team. For this reason, the Reserve Protocol is entirely permissionless—allowing anyone to deploy a Reserve stablecoin (RToken) with their preferred collateral basket, governance system and revenue distribution.
Watch this introduction video to know exactly why we built Reserve Protocol:
Overview
The Reserve Protocol allows anyone to create stablecoins backed by baskets of ERC20 tokens on Ethereum. Stable asset backed currencies launched on the Reserve protocol are called “RTokens”.
Once an RToken configuration has been deployed, RTokens can be minted by depositing the entire basket of collateral backing tokens, and redeemed for the entire basket as well. Thus, an RToken will tend to trade at the market value of the entire basket that backs it, as any lower or higher price could be arbitraged.
RTokens can be overcollateralized, which means that if any of their collateral tokens default, there's a pool of value available to make up for the loss. RToken overcollateralization is provided by Reserve Rights (RSR) holders, who may choose to stake their RSR on any RToken. Staked RSR can be seized in the case of a collateral default, in a process that is entirely mechanistic based on on-chain price-feeds, and does not depend on any governance votes or human choices.
RTokens can generate revenue, and this revenue is the incentive for RSR holders to stake. Revenue can come from yield from lending collateral tokens on-chain or revenue shares with collateral token issuers. Governance can direct any portion of revenue to RSR stakers, to incentivize RSR holders to stake and provide overcollateralization. If an RToken generates no revenue, or if none of it is directed to RSR stakers, it probably won't have any RSR staked on it, and thus won't be protected by overcollateralization.
Each RToken is governed separately, and each can have an entirely different governance system. Initial RTokens will likely have relatively simple governance systems, which will probably evolve over time. That evolution is up to those that hold power in the initial governance systems.
Governance defines not just the basket to back an RToken, but also an ordered list of emergency collateral. So there's a current basket, and a series of assets that can be deployed to the basket in the case of a default. A collateral token is considered to have defaulted if it's gone down in value more than a defined amount for a long enough time, relative to its reference or target unit (described in the Monetary Units section).
For the kinds of RTokens the core team is imagining, default will be an extremely rare "black-swan" situation, not something that occurs regularly. But still, it could happen, and the purpose of the overcollateralization mechanism is to preserve RToken holders’ value if it does.
Governance can update the basket configuration regularly. When the current basket is updated, or in the case of a default, the protocol makes on-chain trades to reach the new basket composition. This trading is modularized so that it can happen in different ways over time as on-chain liquidity evolves. Currently, there is a plugin built for Gnosis Auctions (batch auctions) but in the future, once on-chain protocol trading can be done without danger of front running, then we expect AMMs and other trading methods to be an option.
As with any smart contract application, the actual behavior may vary from the intended behavior, and it's safest to wait for an application to be in use for a long period of time before trusting it to behave as expected. This overview and subsequent documentation describes the intended behavior.
Our long term goal
Taking a look at the history of currency reveals that, whenever a major world empire gives way to the next one, the value of the currency that the empire issued tumbles. Besides this phenomenon having happened with currencies such as The Dutch Guilder & The British Pound, recent speculation Ray Dalio states that “the US dollar is not destined to remain the world’s reserve currency”.
Bloomberg reported that “His concern — shared by BlackRock Inc.’s Larry Fink, among others — is that swelling U.S. budget deficits will eventually irk big buyers overseas. You easily could have a 30 percent depreciation in the dollar as the Fed has little choice but to monetize the national debt.”
This is the reason why the Reserve community intends to create a Reserve stablecoin (RToken) that is designed to go off of the peg from the US Dollar. In the very long run, the best outcome for cryptocurrency isn’t just to extend an existing currently-stable asset class, but to create something new that is equally stable in the short run, and much more stable in the long run.
The value of the US Dollar continues to depreciate as time goes on.
We think it’d be really neat if there was a stable currency that kept its value with no inflation for centuries. Think about it. What if you could earn some money today and set it aside for your grandchildren, and when they spent it 100 years from now, they got to buy something just as valuable as what you could have bought right now? That’s not how fiat currencies tend to work, even the best ones like the US dollar.
The way we think this cryptocurrency should be built is by backing it with a diverse and well-structured basket of many different tokenized assets that will hold its overall value for a long time. These could include all kinds of precious metals, commodities, debt & equities.
With a sufficiently diversified basket of assets backing this new currency, its value might be able to follow the global GDP, which, during the world financial crisis of 2008 only dipped ~2%.
However, there are two major challenges that we expect to face on this journey:
-
Right now, most financial assets like equities, commodities, and derivatives don’t exist on Ethereum - they aren’t tokenized. Yet. We imagine a world where nearly everything gets brought on-chain and is available for use in Reserve stablecoin baskets. The way the Reserve platform is built, anyone can make new Reserve stablecoins and try out any basket.
We don’t know what will be tokenized, on what timeline, and what the regulatory limitations will be for how tokenized assets can be used around the world. This is out of our hands – the Reserve protocol is a way of building asset-backed coins that can be used as currencies, not a tokenization project. -
We believe that the decentralized governance systems for cryptocurrencies that exist today do not meet the requirements that the governing of a world reserve currency would need. The simple token voting mechanism that is the most prevalent today is ultimately flawed, and the cryptocurrency community as a whole will need to evolve these mechanisms in order to get them to a place where they are truly fair & sufficiently decentralized
While the Reserve core team intends to work on improving decentralized governance systems, community input & cooperation between different projects will be crucial.
All that being said, we are extremely excited to start working on this part of the project together with the Reserve community and anyone else willing to join in. As more and more assets get tokenized, and decentralized governance systems evolve, we’ll be able to create more and more robust stable cryptocurrencies - and while we’re getting there, we’re building the platform to make it spendable everywhere you want in parallel.
What are RTokens?
RToken is the generic name for a stablecoin that gets created on top of the Reserve Protocol. RTokens are fully asset-backed by any combination of ERC-20 tokens and can be protected against collateral default by Reserve Rights (RSR) staking. Each RToken is governed separately.
Anyone can create an RToken
In a similar way as how anyone can create a new trading pair on Uniswap, anyone can permissionlessly create a new Reserve stablecoin (RToken) by interacting with Reserve Protocol’s smart contracts. The protocol applies a system of factory smart contracts that allows anyone to deploy their own smart contract instance.
Creating an RToken can be done either by interacting directly with the Reserve Protocol’s smart contracts or any user interface that gets built on top of it. The first user interface for these smart contracts will be released by LC Labs, a company connected to the Reserve core team that's helping with protocol development. Besides the creation of RTokens, this user interface will also support exploring usage and stats related to RTokens, RToken minting & redeeming, and RSR staking.
Non-compatible ERC20 assets
The following types of ERC20s are not supported to be used directly in an RToken system. These tokens should be be wrapped into a compatible ERC20 token to be used within the protocol. A concrete example is the use of Static ATokens for Aave V2.
- Rebasing Tokens that return yields by increasing the balances of users
- Tokens that take a "fee" on transfer
- Tokens that do not expose the decimals() in their interface. Decimals should always be between 1 and 18.
- ERC777 tokens which could allow reentrancy attacks
- Tokens with multiple entry points (multiple addresses)
- Tokens with multiple entry points (multiple addresses)
- Tokens that do not adhere to the ERC20 standard in general
Advanced RToken parameters
When deploying an RToken, the deployer has the ability to configure many different advanced parameters. The following list goes into detail about what these parameters do and some of the factors the deployer should keep in mind to set them.
As many of these parameters concern the Protocol Operations, we advise reading through that section of the documentation first—as it will give the deployer the necessary context to fully understand all parameters.
Trading delay(s)
The trading delay defines how many seconds should pass after the basket has been changed before a trade can be opened.
A collateral asset can instantly default if one of the invariants of the underlying DeFi protocol breaks. If that would happen, and we would not apply a trading delay, the protocol would react instantly by opening an auction. This would give only auctionLength seconds for people to bid on the auction, making it very possible for the protocol to lose value due to slippage.
The trading delay parameter may only be needed in the early days - before we get to a point where there is a robust market of MEV searchers. We expect that this parameter can be set to zero later on (once a robust market of MEV searchers is established).
Auction length(s)
The Reserve Protocol includes a generic trading system which can be integrated with any type of trading mechanism, but will only have an implementation for Gnosis EasyAuctions at-launch.
The auction length determines how long auctions stay open for. The situations to keep in mind when determining this value are:
- If it is set too low, back-to-back auctions may not give arbitrageurs enough time to complete arbitrage loops that involve centralized exchanges. We don’t want capital-constrained traders to have to sit out every-other auction.
- If it is set too high, fewer auctions will fill and the protocol will take more time holding the asset being sold. This is because the price can swing more than maximum trade slippage in the unfavorable direction.
Backing buffer (%)
As collateral tokens appreciate, RTokens can be minted by the protocol whenever it gathers the correct ratios of all collateral tokens. This is the most efficient form of revenue capture, because it requires minimal trading of the excess collateral (and thus, a minimal spend on gas fees and trading slippage).
When the protocol is able to gather all the required parts of an RToken, these parts (collateral tokens) get sent to the RevenueTrader contract, where it performs an internal mint to create more RTokens. These new RTokens are then used as yield for both RToken holders and RSR stakers.
The backing buffer parameter is a percentage value that describes how much additional collateral tokens the protocol should hold on to before sending collateral tokens to the RevenueTraders. If this were set to “0”, then it’s possible (though unlikely) that collateral could “take turns” appreciating, causing the protocol to forward individual collateral tokens to the RevenueTraders and never assemble it into new RTokens.
Max trade slippage (%)
The maximum trade slippage is a percentage value that describes the maximum deviation from oracle prices that any trade that the protocol performs can clear at. Oracle prices have ranges of their own; the maximum trade slippage permits additional price movement beyond the worst-case oracle price.
Setting this percentage too high could cause the protocol to take high losses if auctions are illiquid.
Minimum trade volume
The minimum trade volume represents the smallest amount of value that is worth executing a trade for.
Setting this too high will result in auctions happening infrequently or the RToken taking a haircut when it cannot be sure it has enough staked RSR to succeed in rebalancing at par.
Setting this too low may allow griefers to delay important auctions. The variable should be set such that donations of size minTradeVolume would be worth delaying trading auctionLength seconds.
We expect auction bidders to pass-through any gas fees they pay during trading to the protocol. They are under competition, so those that do not will find themselves with less capital over time relative to those that do.
In order for the protocol not to take losses it’s important it knows that bidders will bid in the auction near market prices, which requires that gas prices are not significant relative to the volume of the auction.
Note: Every collateral in the basket should be a large enough portion of the basket that is worth trading at the configured minTradeVolume, even when we are only looking at 5% or 10% of its balance.
RToken max trade volume
This represents the maximum sized trade for any trade involving RToken, in terms of value.
It is important to remark that in addition to the RToken, each collateral plugin will also have its own max trade volume defined.
RToken supply throttles
In order to restrict the system to organic patterns of behavior, we maintain two supply throttles, one for net issuance and one for net redemption.
When a supply change occurs, a check is performed to ensure this does not move the supply more than an acceptable range over a period; a period is fixed to be an hour.
The throttling mechanism works as a battery, where, after a large issuance/redemption, the limit recharges linearly to the defined maximum at a defined speed of recharge.
Limits can be defined (for issuance and redemption) in rToken amounts and/or as a percentage of the RToken supply.
Issuance throttle amount
A quantity of RToken that serves as a lower-bound for how much net issuance to allow per hour. This quantity is defined in RToken amounts.
Must be at least 1 whole RToken. Can be set to a very high numer (e.g. 1e48) to effectively disable the issuance throttle.
Issuance throttle rate (%)
A fraction of the RToken supply that indicates how much net issuance to allow per hour.
Can even be set to 0, to solely rely on throttle amount.
Redemption throttle amount
A quantity of RToken that serves as a lower-bound for how much net redemption to allow per hour.
Defined in RToken amounts.
Must be at least 1 whole RToken. Can be set to a very high numer (e.g. 1e48) to effectively disable the redemption throttle.
Redemption throttle rate (%)
A fraction of the RToken supply that indicates how much net redemption to allow per hour.
Can be 0 to solely rely on the throttle amount.
Long freeze duration(s)
The number of seconds a long freeze lasts.
Long freezes can be disabled by removing all addresses associated to the role.
Unstaking delay(s)
The unstaking delay is the number of seconds that all RSR unstakings must be delayed in order to account for stakers trying to frontrun defaults.
In the case of a collateral token default, RSR holders are not given a choice as to whether their RSR is used to cover the default, since selfish anonymous actors would often choose not to follow through. So, there must be a delay when withdrawing RSR from the staking contract.
In practice, whenever an RSR staker chooses to withdraw their RSR, they must submit a transaction, wait X amount of time, and then submit another transaction to complete the withdrawal. During the waiting period, their RSR continues to be subject to forfeiture in the case of a collateral token default, but stops earning its pro-rata share of the RToken’s revenue.
The goal of this delay is to make it so that at any point in time, staked RSR that has not had a withdrawal transaction initiated is at least X time away from being withdrawn.
Reward ratio (decimals)
The reward ratio is the percentage of the current reward amount that should be handed out per block.
Default value: 3209014700000 = a half life of 30 days at a period of 12s.
Mainnet reasonable range: 1e11 to 1e13
Use cases of RTokens
The RToken platform is a tool to aggregate relatively stable assets together to create basket-backed stablecoins. Our intention in the long term is to facilitate the creation of an asset-backed currency that is independent of fiat monetary systems. We envision this becoming possible once enough asset types are tokenized.
We are laying the groundwork early, as not many assets are tokenized yet. Today, the main use-cases we see are (1) a more decentralized USD-backed coin, which reduces dependence on any one fiatcoin issuer, and (2) a single simple USD-based coin that packages the yield of DeFi protocols.
The main purpose of allowing and encouraging many RTokens is so that open exploration and competition can lead to the discovery of the best type of basket and governance system. There's a lot to explore, and it's better not to keep that under the control of the initial founding team. That said, we still anticipate a single dominant RToken emerging over time through that evolutionary process, and we think consolidation into one or two dominant options is a good thing, since simplicity and ubiquity are important for an asset to really be a currency.
We also can imagine fintech companies using the protocol to launch their own branded basket-backed stablecoins, though this wasn't the central intent of opening up the platform.
We don't expect lots of RTokens to be created right after protocol launch. Rather, we think that if one or two RTokens become large and known, that will inspire the creation of more over time.
