RTokens

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.

The Reserve Protocol applies a system of factory smart contracts that allows anyone to deploy their own smart contract instance.

When someone decides to create an RToken, they will have to define exactly what the initial configuration of that RToken will look like. This includes choosing which ERC-20 assets & back-up assets the RToken will be backed by, what weight each of these assets will have in the basket, but also how and by whom the RToken will be governed. There are also many more nuanced parameters that the RToken creator will have to consider.

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)

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:

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. Setting this percentage too high could cause the protocol to take high losses if auctions are illiquid.

Issuance rate (%)

The issuance rate is a percentage value that describes what proportion of the RToken supply to issue per block. It controls how quickly the protocol can scale up RToken supply.

The main reason to set an issuance rate is as front-running protection in the case of a collateral default. A savvy trader could frontrun the protocol in the same block that it recognizes the default in order to issue a massive amount of RToken using (partially) a defaulted token. Once the protocol sells all the defaulted tokens for pennies and uses RSR to recapitalize, the trader then redeems everything for a mighty profit. This ends up being a transfer from the RSR stakers to the trader equal in magnitude to the total value of the defaulted token the trader fed into the protocol before it recognized default.

The protocol is always “late to the game”, so to speak. There is no way to eliminate this, but by having a rate-limit on issuance the size of the loss can be limited. At the moment a default is detected all pending issuances are canceled. This forces the attacker to do a small issuance in order to make sure it can vest before the protocol notices default.

Max redemption charge (%)

The max redemption is a percentage value that describes what proportion of the RToken supply to allow redemption of per-hour. It controls how quickly the protocol can scale down RToken supply.

In the case of an attack/exploit of any of the Reserve Protocol smart contracts, the max redemption charge can limit the extracted value, as the Pauser can pause the system before the full exploited value is redeemed.

This redemption 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. It only gets applied after redeems of a size larger than Redemption Virtual Supply (see below).

Scaling Redemption Rate (%)

The max redemption is a percentage value that describes what proportion of the RToken supply to allow redemption of per-hour. It controls how quickly the protocol can scale down RToken supply.

Redemption rate floor

The redemption rate floor is the minimum quantity of RToken to allow redemption of per-hour, and thereby the rate to charge the redemption battery at.

Short freeze duration (s)

The number of seconds a short freeze lasts. Governance can freeze forever.

Long freeze duration (s)

The number of seconds a long freeze lasts.

Unstaking delay (s)

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 period (s)

The Reserve Protocol automatically launches auctions whenever it can sell excess collateral tokens to buy RToken/RSR with them in order to pay out the RToken holders & RSR stakers. After the auction has happened, the protocol deposits the resulting RSR revenue into the staking pool. However, this RSR does not automatically get assigned to all stakers.

Instead, every reward period a small amount can be handed out. If multiple of these reward periods have passed since the last auction, a larger amount is handed out (the reward period just describes the finest grain). The main reason the protocol applies this method of reward sharing is because continuous payouts discourage gaming the protocol versus all-at-once payouts.

Reward ratio (decimals)

The reward ratio is the percentage of the current reward amount that should be handed out in a single reward period (see above). This parameter must be set in conjunction with the reward period parameter in order to achieve a desired payout rate.

Minimum trade volume

The minimum trade volume represents the smallest amount of value that is worth executing a trade for.

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.

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.