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. 2,000,000 rtokens) and/or as a percentage of the RToken supply (e.g. 10% 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. 2,500,000 rtokens) and/or as a percentage of the RToken supply (e.g. 12.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

ERC-20 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 ERC-20 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:

1. Dutch Auctions
2. 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:

1. 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
2. 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
3. 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
4. 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.