2021 version of the Reserve protocol¶
The Reserve protocol allows anyone to create stablecoins backed by baskets of ERC-20 tokens on Ethereum. Reserve stablecoins are called RTokens.
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.
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 insured, which means that if any of their collateral tokens default, there's a pool of value available to make up for the loss. RToken insurance 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 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 transaction fees, revenue shares with collateral token issuers, or yield from lending collateral tokens on-chain. Governance can direct any portion of revenue to RSR stakers, to incentivize RSR holders to stake and provide insurance. 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 insured in the case of a collateral token default.
Each RToken is governed separately, and each can have an entirely different governance system. The initial RTokens the core team is deploying will 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 one basket to back an RToken, but a series of baskets arranged in a tree-like structure. So there's a current basket, and a series of backups that are selected algorithmically 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 any of its available backup tokens further down in the tree-like structure.
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 that's the purpose of the insurance mechanism.
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. Accessing existing AMMs and running batch auctions are the main anticipated methods for on-chain trade in the near term.
The core team is releasing two RTokens upon initial protocol launch:
The first is a pure USD coin, backed only by USD fiatcoins, much like the current RSV. This will be essentially the same as RSV today – it will be stable against USD, will not generate revenue, will not be insured, and will continue to be governed with a core-team-held multisig and a timelock, like RSV is today.
The second is a yield-bearing USD coin, backed by defi USD tokens, such as cUSDC, aUSDC, cDAI, aDAI, cUSDT, aUSDT, and aBUSD. Because these tokens generate yield, the RToken naturally appreciates in USD terms, so long as the underlying protocols and stablecoin issuers work like they are supposed to.
A portion of the yield for this RToken can be offered to RSR stakers, by way of reducing the size of the basket that the RToken is redeemable for, and minting new RTokens to distribute to stakers. This means that the underlying collateral yield is split between the RToken holders and the RSR stakers. In exchange, the staked RSR provides insurance.
This second RToken will be governed by its RSR stakers, through Compound-like token voting, where 1 staked RSR is equal to 1 vote.
This video walkthrough gives and overview of how the updated protocol works, and explains how it's similar to and different from the prior version:
This documentation is still high level. Low-level documentation will be added along with or before mainnet launch, once it's been fully written.
Deploying an RToken¶
Through the use of a factory contract, anyone can deploy a new RToken on Ethereum, similar to how anyone can deploy a new Uniswap trading pair. This can be done by interacting directly with the factory contract via any tool that permits submission of Ethereum transactions, or through a dApp web interface, if/when dApps come to support this feature of the protocol.
Whoever deploys an RToken determines how it is governed. The governing body could be a DAO, a multi-sig, or even a single Ethereum address. The governing body can replace itself with another governing body, if it chooses to do so.
Thus, some RTokens could be governed centrally, and others could be governed through an arbitrarily decentralized and complex system of rules, including timelocks and any other mechanism that can be programmed into a smart contract. By setting the governing body to an address nobody controls, they can also be static and ungoverned.
Governance sets the basket that backs an RToken, as well as all of the backup baskets that the protocol will automatically select from in the case of a default. It can update this set of baskets any time, per its own internal rules.
Governance can set several further parameters, including:
- The delay on un-staking staked RSR
- The portion of revenue that goes to RSR stakers and/or other recipients, including the RToken's treasury
- The threshold in price deviation needed for a collateral token to be considered in default
- The amount of time a deviation needs to exist to declare a default
- RSR staking reward period
- Min minting quantity
- Issuance/redemption spread (can be set of zero)
- Global minting limit per block (necessary for preventing a class of attacks)
- Max RToken supply (for reducing risk to users in the early days)
as well as some others, depending on which type of on-chain trading module is in use.
Governance can set a global pauser role, which is able to instantly pause all functions of the RToken in the case of a bug discovery. Since governance can re-assign this role through its normal process, if the pauser role is abused, it can be transferred to another party in order to unpause.
Governance can also replace contracts in the RToken system of contracts with entirely different contracts. This means that by default, governance has the power to profoundly change the functionality of the RToken it governs. This may not always be desirable. More mutability means more flexibility, but with that flexibility comes more uncertainty. As the RToken contracts mature, governance systems can choose to limit their own ability to alter the RTokens they control, in order to offer greater predictability to RToken holders and RSR stakers.
Issuance and Redemption¶
RTokens have a 1-1 correspondence with the basket that backs them. In order to issue 100 RTokens, you have to deposit 100 units of the basket that backs that RToken. If you redeem 100 RTokens, you get 100 units of the basket the backs that RToken.
This is similar to an ETF, except that there is no custodian in charge of the underlying collateral tokens in the basket, which are just held by the smart contracts that implement the RToken.
Issuance is not immediate. In order to prevent an attack that would otherwise exist during collateral default scenarios, issuance has a global (all users) rate limit per block, set by governance. Suppose the rate limit is 25k RToken per block, and you wanted to mint 1M RTokens. You'd have to initiate minting, and then wait 1M/25k = 40 blocks in order to withdraw your newly minted RTokens. If someone else is in the middle of minting, you'd need to wait for the queue before your RTokens are released. See the default section below for more info on why this is.
RTokens can generate revenue in three ways.
1. Lending collateral tokens¶
Collateral tokens can be lent out with overcollateralization, much like Compound, Aave, and so on.
Or, more simply, collateral baskets can contain the tokenized outputs from Compound, Aave, and so on, e.g. cUSDC, aDAI, etc. This is essentially the same thing, but pays a portion of the yield collected from borrowers to these other protocols for the work they do in operating lending marketplaces, and simplifies the RToken logic. In order to book revenue with this approach, the RToken can track the appreciation of its collateral tokens in USD terms, and decrement the redeemability accordingly. Thus, appreciation can be split among RToken holders and revenue receivers, e.g. RSR stakers. RToken holders would be able to redeem their RTokens for less and less of the collateral basket, but more and more USD value, since the basket would have appreciated more than redeemability was decremented.
2. Revenue share with collateral token issuers¶
Tokenized assets, e.g. tokenized currencies, will sometimes have a business model of earning interest on the underlying assets they hold in custody. For example, a USD stablecoin issuer may hold short-term treasuries that pay a yield. If an RToken reaches a large scale, asset tokenizers will compete to have a greater share of the basket, in order to increase their deposits. Thus, it would be rational for the tokenizer to offer part of the revenue they earn. RTokens can accept revenue share arrangements from these tokenizers in exchange for increasing that collateral token's basket share.
As in many aspects of governance, the potential for corruption exists. An asset tokenizer could offer a revenue share directly to participants in the governance system in exchange for increasing their share, thus cutting the RToken holders out of the loop. This is a good example to keep in mind when picking and evolving RToken governance systems.
3. Transaction fees¶
Fees could be charged on each transfer of an RToken. Such fees need not be a fixed amount or a single percentage. Any computationally efficient function can be specified.
However, transaction fees present two problems. Many smart contracts assume that ERC-20 tokens do not have fees subtracted during the transfer process, so including a fee can break defi integrations. Also, and more fundamentally, if tokens end up mostly transacted on L2 or sidechains, it's often not possible or at least not practical to charge fees, as the process of ownership changing is out of the hands of the original L1 token contract – think of this like trying to collect on-chain transaction fees if all transfers happened in centralized exchange accounts off-chain. As a result, we don't plan to include transaction fee logic in the RToken contracts, though it could be added to any particular RToken through governance if appropriate.
RToken revenue can be allocated in any proportion to any set of addresses. The two main places governors will likely allocate revenue are:
- RSR stakers (to incentivize insurance)
- The treasury for that RToken
The treasury for an RToken can be used to pay for operating costs, e.g. oracles, or bounties for performing transactions that the protocol needs to operate.
RToken creators and governors can also allocate revenue to themselves. So, a person, team, or company could create and promote an RToken as a business, and be rewarded if it succeeds. The initial RTokens the core team creates will not pay any revenue to the core team or the Reserve project, since as RSR holders they will have an opportunity to earn income from staking, but others in the future may be motivated by this mechanic, and it's good to reward innovation and exploration as time goes on.
RSR holders can choose to stake their RSR on any RToken, or none at all.
When RSR is staked on an RToken, it's deposited into a staking contract specific to that RToken, and the staker receives a further ERC-20 token, which represents their staked RSR position on that particular RToken. This token is transferrable and fungible with other staked RSR balances for that RToken, so you can send any portion of the staked position to someone else or trade it, and the new holder can un-stake it.
Staked RSR can earn rewards, based on three factors:
- The amount of revenue the RToken generates
- The portion of revenue that governance has directed to RSR stakers
- Your portion of the total RSR staked on that RToken
As a simple example, suppose (these numbers are just made up for simplicity, to make the arithmetic clear):
- A fictional RToken generated $100 in revenue in a period
- 20% of revenue was designated for RSR stakers
- 1000 total RSR was staked
- You had staked 100 RSR of the 1000
In this simple example, you would get $100 * 20% * (100/1000) = $2 for that period.
The protocol stores revenue in RTokens, but when staking rewards are distributed, it market-buys RSR on DEXs with those RTokens in order to distribute the rewards to stakers in RSR. Thus, as rewards are earned, staked RSR balances increase.
When RSR is staked, it is actually at stake. Staked RSR can be seized by the protocol in the unlikely event of a collateral token default, in order to cover losses for RToken holders. It's seized pro-rata if this happens.
Un-staking RSR comes with a delay, which is configurable by governance, and predicted to usually be between about 7 and 30 days. This delay is necessary so that in the event of a default, the staked RSR will remain in the staking contract for long enough to allow the RToken to seize any RSR it needs to cover losses.
During the unstaking delay period, the staker does not earn any rewards. This is necessary to prevent stakers from withdrawing and re-depositing over and over in order to subvert the withdrawal delay mechanism.
An RToken relies on price feeds if it is insured and needs to react to collateral token defaults.
The optimal price feed will depend on the type of collateral tokens within an RToken. For defi tokens like cUSDC, prices must be computed with the combination of the redemption ratio between cUSDC, and the market value of USDC. The redemption ratio can be accessed through the Compound contracts directly, and the market value of USDC can be taken either from Oracle sources such as ChainLink or Time Weighted Average Prices (TWAPs) from on-chain liquidity pools such as Uniswap.
The protocol has a parameter called the "default flag," which can be "raised" or "lowered."
Anyone can submit a transaction to raise the default flag if any collateral token has a short-term price-feed value that is sufficiently less than one of its corresponding backup tokens in a backup basket. The definition of short-term and the price deviation threshold are governance parameters, with plausible values of 5 minutes and 5% deviation.
Any time the default flag is raised, issuance is paused. This is to prevent market participants from minting RTokens for cheaper than usual, in anticipation of RToken value being restored with insurance shortly thereafter.
If the mid-term price-feed value of the token in question is back within the normal range after 6 hours (configurable), anyone can submit a transaction to lower the default flag.
If the default flag stays raised continuously for 24 hours (configurable), all baskets containing the defaulted token are disabled. If the current basket contains the defaulting collateral token and is thus disabled, then it is replaced with the next remaining active basket in line, and the default flag is lowered.
Once the current basket has been updated and the default flag lowered, issuance is re-enabled. Redemption was never paused, but redeeming before this point would likely be unattractive as the redeemer would receive the defaulted collateral token as part of the basket. Once the basket has been updated, issuance and redemption are both for the new basket.
The new basket is capitalized by trading collateral from the prior basket, and as much staked RSR as is needed in order to purchase the correct amount of the new collateral basket, despite the defaulted collateral token. RTokens holders still may take some loss, since the backup basket will likely be worth somewhat less than the prior basket. This is becasue backup baskets will tend to include more conservative tokens which are less likely to appreciate than the collateral tokens they are insuring.
If there is not sufficient RSR to make up for the default and purchase the entire new basket, then RToken holders will take the corresponding loss. This is why it's important to offer plenty of reward to RSR stakers, in order to ensure sufficient insurance. For staking to be positive in expected value, the expected loss from potential default must be less than the expected gain from staking rewards. This will likely be true for many viable types of RToken collateral, but may not be true for some highly novel and risky defi tokens, which must be considered when constructing new RTokens and governing existing ones.
As with any Ethereum application, anyone can publish a user interface. Initially, LC Labs, a company connected to the Reserve core team that's helping with protocol development, will be the first to publish a web UI. This initial UI will support RToken minting and redeeming, RSR staking, and exploring usage and stats related to RTokens.
Use-cases of RTokens¶
The RToken software 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. Thus our plan to launch each of these ourselves.
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 – maybe one the founders create, maybe not – 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.