Issuance and 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.
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 per block. That way, anyone with pausing or freezing permissions can step in before the attacker is able to issue massive amounts of RTokens.
If an RToken gets deployed with the default settings, only 0.0025% of the market cap of the RToken can be issued per block (every ~12 seconds), or about 0.1% per minute, or 6% per hour.
When a user wants to issue new RTokens, the protocol will accept the collateral tokens they’ve brought and tell them how long it will take to issue all RTokens, based on the issuance throttle that is being applied on that RToken. If the full issuance can happen in one block, only one transaction will be required from the user. If the full issuance takes multiple blocks, the user will need to come back to the protocol once issuance is completed and perform a second transaction.
Cancelling an issuance¶
The issuer of RTokens can cancel any number of issuances before they are claimed and receive the exact amount of collateral tokens they’ve deposited.
Issuances can not be cancelled partially—if the issuer decides to cancel issuance, they are cancelling the entire batch of to-be-issued RTokens.
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, as anyone with pausing or freezing permissions can step in before the attacker is able to redeem massive amounts of collateral tokens.
The redemption throttle makes it so that, at every block, there is a maximum amount of current RToken supply that can be redeemed—set by default at 5%. The throttle only gets activated if a redemption larger than a predefined threshold is detected.
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.
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 a 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.
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).
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.
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 handed 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.
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.