Issuance + redemption
The concepts behind issuance & redemption of RTokens are very simple. Anyone can bring the protocol X amount worth of collateral baskets and receive X RTokens in exchange for it. Anyone can also bring the protocol Y RTokens and receive Y worth of collateral baskets in return.
Issuance throttle
As a way to limit the extractable value in the case of an attack or exploit of an RToken, the protocol allows the RToken deployer (and governance) to set a limit on how much RToken can be issued.
The throttling mechanism works as a battery, where, after a large issuance, the issuance limit recharges linearly to the defined maximum at a defined speed of recharge.
The idea is to ensure net issuance for an RToken never exceeds some bounds per unit time (hour). Limit can be set as a fixed amount of Rtokens (e.g. 1,000,000 rtokens) and/or as a percentage of the RToken supply (e.g. 5% as default).
Redemption throttle
Similar to the issuance throttle, each RToken can have a redemption throttle to limit the amount of extractable value in the case of an attack or exploit.
The throttling mechanism works as a battery, where, after a large redemption, the redemption limit recharges linearly to the defined maximum at a defined speed of recharge.
The idea is to ensure net redemption for an RToken never exceeds some bounds per unit time (hour). Limit can be set as a fixed amount of Rtokens (e.g. 1,000,000 rtokens) and/or as a percentage of the RToken supply (e.g. 2.5% as default).
Note: It is recommended that the redemption throttle is greater than the issuance throttle, to avoid to consume all the redemption throttle with an issue-redeem operation.
Staking and un-staking
Reserve Rights (RSR) holders can decide to stake their RSR tokens on RTokens to make RToken holders whole in the unlikely event of a collateral token default, and receive a portion of the revenue the RToken makes in return.
This section will go into more detail about the low-level aspects of RSR staking. For a more high-level description, please refer to the Reserve Rights Staking section.
Right after staking RSR tokens on an RToken, the staker receives an stRSR (staked Reserve Rights) token at a particular exchange rate to RSR. This exchange rate starts at 1.00 and will change over time—either by RToken revenue being shared to the RSR stakers, or through overcollateralization slashing.
To participate and vote in Governance proposals, stakers need to delegate their stakes to themselves to activate their voting weight.
If an RSR staker decides to un-stake their RSR tokens, they’ll have to wait the un-staking delay (by default set to 2 weeks) before receiving their RSR tokens back. While in the delay period, the stRSR to RSR exchange rate is locked (the staker is no longer accumulating revenue from the RToken). However, the RSR is still liable to be slashed in the case of a collateral default.
The reason for a stRSR position needing to be slashable, but not earning revenue, during the un-staking delay period is because the alternative would allow for gaming of the system. If revenue was still being accumulated during the delay period, one could immediately un-stake after staking their RSR (and repeat this process) to circumvent the delay period—ultimately resulting in a less consistent overcollateralization pool.
Un-staking a stRSR position requires two transactions, one to initiate the un-staking process and one at the end of the delay period to receive the RSR tokens back. In between these two transactions the stRSR position is not transferable, as stRSR gets burned upon the first transaction).
Asset Management
ERC20 assets that need to be used as part of an RToken system (either as collateral or as revenue assets) need to be registered in the Asset Registry contract for that particular RToken.
Governance is in charge of registering, unregistering, and swapping assets.
register: Adds the asset to the Asset Registry, including all the required details the protocol needs to handle that asset.swapRegistered: Allows to modify/update details and functionality of a previously registered asset.unregister: Removes the asset from the Asset Registry. It will no longer be used by the RToken system. The intended use of this function is for governance to remove bad collateral contracts. It is important that proposals that perform unregistration of assets should include at the end a call to refresh the basket (refreshBasket()).
A detailed list of non-compatible ERC20 assets is included in the RTokens section
Revenue handling
Source of revenue
The revenue that RTokens accrue comes from their collateral baskets including tokenized outputs from DeFi protocols such as cUSDC (Compound USDC), aDAI (Aave DAI), or various AMM LP tokens. These tokens are designed to increase monotonically (ever-increasing) against their base tokens, as they are pegged to the value of the base token + any borrowing/trading fees paid in the relevant pool.
The protocol can track the appreciation of an RToken’s collateral tokens in USD terms, and decrement the redeemability for that RToken accordingly.
The protocol can track the appreciation of an RToken’s collateral tokens in USD terms, and decrement the redeemability for that RToken accordingly.
Revenue distribution
There are several components that are essential to understanding how RToken revenue is distributed to RToken holders or RSR stakers. In this section we will first introduce them one by one, and afterwards consolidate them to present the full picture.
Revenue distribution to RToken holders
After minting RTokens, all collateral tokens provided to the protocol will be stored in the Backing Manager (BM). The BM is responsible for holding on to them, minting more RTokens out of them, or trading them for RTokens or RSR (to later pay out rewards to RToken holders or RSR stakers).
For simplicity reasons, let’s first imagine an RToken X of which the revenue goes entirely to the RToken holders. The BM will periodically mint as many RTokens X as it can from the growing collateral. All the remaining grown collateral that can not be evenly minted into RTokens X will be sent to the RToken Trader, where it will be traded directly for more RTokens X through auctions.
After trading, both the newly minted RTokens X and the newly traded RTokens X will be consolidated in the Furnace. The Furnace is responsible for melting (= slowly burning) these new RTokens, which incrementally increases the exchange rate between the RToken and its collateral basket.
To summarize: the protocol will hold all collateral tokens in the Backing Manager. Whenever it can, it will mint new RTokens or trade excess collateral to RTokens via the RToken Trader. After minting/trading, the RTokens get melted (= slowly burned) via the Furnace—which results in the RToken becoming more valuable (redeemable for more collateral tokens).
The revenue distribution to RToken holders can be visualized as follows:
Revenue distribution to RSR stakers
As mentioned in the previous section, all deposited collateral tokens for an RToken will be stored in the Backing Manager (BM). The BM is responsible for holding on to them, minting more RTokens out of them, or trading them for RTokens or RSR (to later pay out rewards to RToken holders or RSR stakers).
For simplicity, let's now imagine an RToken Y of which the revenue goes entirely to the RSR stakers to compensate them for overcollateralization & governance. In this case, the BM will periodically mint as many RTokens Y as it can from the growing collateral. After this periodical mint, the newly minted RTokens and all the remaining grown collateral that could not be evenly minted into RTokens Y, will be sent to the RSR Trader, where it will be traded directly for more RSR tokens through auctions.
After trading, the protocol will send all the newly acquired RSR to the stRSR pool, where it will slowly be drip out as rewards for the RSR stakers by increasing the stRSR/RSR exchange rate.
To summarize: the protocol will hold all collateral tokens in the Backing Manager. Whenever it can, it will trade excess collateral to RSR via the RSR Trader. After trading, the RSR get slowly handed out via the stRSR pool—which results in stRSR becoming more valuable (redeemable for more RSR tokens).
The revenue distribution to RSR stakers can be visualized as follows:
Summary of revenue distribution
The previous two sections explain how the revenue (growing collateral) of an RToken gets distributed to either RToken holders or RSR stakers via minting/trading (for) RTokens or RSR tokens. In this section we combine the two approaches to present the full picture of revenue distribution.
When deploying an RToken, the deployer defines what portion of the revenue goes to the RToken holders versus RSR stakers. Let’s now imagine an RToken Z where 40% of the revenue goes to RToken holders and 60% goes to the RSR stakers.
In that case, the protocol will periodically take the following actions:
- Out of 40% of all the revenue accrued in the Backing Manager at that point, the protocol will mint as many RTokens Z as it can. The remainder of the collateral (out of which no new RTokens Z can be minted) will be sent to the RToken Trader, where it will be traded directly for RTokens Z. Afterwards, all newly minted/traded RTokens Z will consolidate in the Furnace, where they will be melted (= slowly burned)—thereby positively impacting the exchange rate of RToken Z to its collateral.
- Out of 60% of all the revenue accrued in the Backing Manager at that point, the protocol will mint as many RTokens Z as it can. The newly minted tokens, as well as the remainder of the collateral (out of which no new RTokens Z could be minted) will be sent to the RSR Trader, where it will be traded directly for RSR tokens. Afterwards, all newly acquired RSR tokens will be sent to the stRSR pool, where they will slowly be handed out to stRSR holders—thereby positively impacting the exchange rate of stRSR to RSR.
The full picture of revenue distribution can be visualized as follows:
💡 Reserve Protocol can be configured to send (part of the) revenue of an RToken to any arbitrary Ethereum address (e.g. to compensate the RToken deployer, to build an RToken treasury, etc). In this configuration, the RToken deployer can decide whether to pay out the third-party address in RTokens or RSR. In either case, the part of the revenue designated to the third-party address can be sent to it directly from the RToken Trader or the RSR Trader—it does not have to go through the Furnace or stRSR pool first.
Recapitalization
Fully collateralized vs. fully funded
When we talk about recapitalization, we make a distinction between two states that an RToken can be in:
- Fully collateralized: the protocol is holding the right balances of the right tokens to offer 100% RToken redeemability.
- Fully funded: the protocol is holding the right amount of value, but not necessarily the right amounts of collateral to offer 100% RToken redeemability.
The Reserve Protocol aims to be fully collateralized at all times, but likely won’t always be. For example, right after governance decides to change the collateral basket, the protocol will be fully funded but won’t yet hold all the necessary collateral to offer full redeemability. Similarly, in the case of a collateral default, the protocol might be fully funded through excess collateral or RSR overcollateralization, but likely won’t yet be fully collateralized to offer full redeemability.
When the protocol is not fully collateralized, it will sell off any assets it is holding that are not part of the proper collateral basket until either (a) the protocol is fully collateralized again or (b) RSR from the stRSR contract needs to be sold to recapitalize the protocol.
Recapitalization through Reserve Rights
If any of an RToken’s collateral tokens were to default, the default flag would instantly be raised by the protocol through the default checking mechanisms explained in the Monetary Units section. At that point, the protocol will sell as much of the faulty collateral as it can through auctions and use the proceeds, as well as any excess collateral still in the system, to purchase the predefined emergency collateral (which you can read more about in the How to deploy an RToken section (coming soon)).
In the case that the proceeds of the auction(s) + any excess collateral still in the system do not provide enough value to fully collateralize the RToken with the emergency collateral, the protocol will attempt to recapitalize using RSR tokens staked in the stRSR contract. More concretely, the required amount of RSR tokens will be seized from the stRSR contract and sold for the required amount of emergency collateral through auctions—resulting in an even “haircut” for all RSR stakers.
Auctions
Auctions are employed any time an asset within the RToken system is traded for another asset. Possible scenarios include (1) processing RToken revenue and (2) recollateralization following a basket change or a collateral default. In general, the Reserve Protocol supports any generic trading system, but at present, the protocol provides support for two auction implementations:
- Dutch Auctions
- Batch Auctions
It is anticipated that Dutch auctions will be the preferred trading method, with a fallback to batch auctions being available in scenarios where it is suspected that manipulation has occurred and a more manual trading process is warranted.
Dutch Auctions
A Dutch auction is a type of auction where the item on sale starts at a high price, with the price lowering gradually until a buyer accepts the current price. This process continues until either the product is sold or it reaches a preset minimum price. Dutch auctions facilitate quick price discovery without bidding wars.
The expected price is based on a number of different inputs, including oracle price feeds, exchange-rates sourced from smart contracts, and other collateral-specific values.
The Reserve Protocol's implementation of Dutch auctions utilizes a 4-phase price reduction mechanism which safeguards against potential price manipulations and which accommodates natural price fluctuations which might occur during the course of the auction. The auction phases are as follows:
- The auctioned asset declines from 1000x of its expected price down to 1.5x. Bids are not expected during this period, and serves as a safeguard against price manipulation
- The asset falls from 1.5x its expected price down to 1x the expected price. This stage acknowledges the potential for natural price movements during the auction
- The asset declines from its expected price to its worst possible price, accounting for oracle errors and the max trade slippage parameter. This is where most bids are expected to occur
- The price remains static at the worst price providing an opportunity for manual human bidding in the absence of bots
A Dutch Auction completes when a user places a bid (full-lot bids are required), or when the auction time runs out and a user chooses to close out the auction with no bids. At this point either a new Dutch Auction or Batch Auction can be run for the same assets.
Batch Auctions
Reserve relies on Gnosis' Easy Auction for its implementation of batch auctions. Batch auctions are a market mechanism for matching limit orders of buyers and sellers of a particular good with one fair clearing price. The auction works by fulfilling the entire "batch" of bids which are above an acceptable minimum price and which satisfies the number of assets they wish to sell. Take for example where 10 tokens X are being sold. Bidder A places an order to buy 5 tokens at $10/token, Bidder B places an order to buy 4 tokens at $9/token, and Bidder C places an order to buy 4 tokens at $5/token. Bidders A and B receive 5 and 4 tokens while Bidder C receives 1 token, and all bids clear at $5/token.
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.
