DOCS

RToken Deployment Guide

Reserve’s mission is to increase accessibility to sustainable, inflation proof currency.

To facilitate this, the Reserve Protocol allows anyone to unleash their creativity and create RTokens, backed 1:1 by collateral assets of their choosing. There are also limitless options in terms of governance design and RToken operational parameters available to deployers.

This guide will walk through the main steps and considerations of deploying an RToken using the Reserve Register interface.

Step 0: Deployer Checklist

Before deploying, it is important to consider what goes into creating a successful RToken. Each RToken will have its own ecosystem use-cases, community, and unique go-to-market strategies.

Just because anyone can deploy and/or mint and RToken does not mean adoption is guaranteed. Important factors to consider include:

  • [ ] Diverse and attractive collateral backing
  • [ ] Yield targets (if any) for the RToken
  • [ ] Interesting revenue share approaches
  • [ ] Branding, messaging and unique use cases
  • [ ] Potential partnerships and integrations

To explore different RToken collateral basket mixes, fork the model here, using DefiLlama to identify desirable pools. To supplement the model, we have created a backtester to allow deployers to visualize aggregate yield with different basket compositions.

RToken revenue-sharing is a multi-faceted problem that should be carefully considered. It is possible to direct underlying revenue in a number of possible ways. Consider the following advantages of sharing revenue with different entities:

  • [ ] RToken holders: incentivizes minting and holding as a savings vehicle
  • [ ] RSR stakers: incentivizes decentralized governance and overcollateralization
  • [ ] Arbitrary address: can incentivize a DAO to actively manage/advise the RToken

The above checklist is an abridged version of the full checklist here, which we encourage all prospective deployers to read: https://blog.reserve.org/the-rtoken-deployer-checklist-7d92466c1304

Step 1: Getting Started

  1. Navigate to Reserve Register
  1. Connect your wallet using the Connect button in the top right
  1. Scroll down and click “Open RToken Deployer”

Step 2: Define your RToken

Your RToken’s name, ticker and mandate are important as unique identifiers which serve to convey its core purpose, setting it apart from other products in the marketplace.

  1. Token Name - the name of the RToken

  2. Ticker - abbreviated symbol of the RToken

  3. Mandate - the mandate describes what goals its governors should try to achieve. By briefly explaining the RToken’s purpose and what the RToken is intended to do, it provides common ground for the governors to decide upon priorities and how to weigh tradeoffs.

Step 3: Configure RToken Basket

Next, we define what collateral assets back your RToken, and in what proportion. Emergency collateral can also be defined as fallbacks in the event any primary collateral defaults.

  1. Under Primary Basket, click “Add to basket”
  2. Select your desired collateral assets. In this example, a number of yield bearing stablecoin positions will be used.

Users must have these collateral assets in their wallet to mint the RToken after it is created (or otherwise use the zap utility).

  1. Once satisfied with the selected assets, click “Add to primary basket”.

  2. Select your asset distributions, as well as the number of target units (e.g. USD, BTC, ETH) your “Target Basket” comprises.

According to this example, a user would have to deposit 1 USD + 1 BTC to mint 1 RToken. This is a very skewed, and so a more reasonable BTC weight may be 0.0001 BTC.

Step 4: Configure Backup Basket

  1. It is generally recommended to configure Emergency Collateral in a backup basket. These are defined separately for each target unit.

  2. The ‘Diversity factor’ of your backups dictates the number of backup assets the RToken will scale into when exiting defaulted collateral (split evenly if there are multiple backups).

Step 5: Configure Parameters

This section discusses what each configuration parameter does, and why it’s important.

Register provides sensible defaults and unless you are an advanced user, you can deploy your RToken using the defaults and skip this section.

Backing Manager Parameters

Trading delay - how many seconds should pass after the basket has been changed, before a rebalancing trade is opened. This helps to avoid losses due to poor liquidity.

  • Auction length - defines how long Gnosis EasyAuction auctions should be. Gnosis EasyAuction is a platform enabling fair price discovery for tokens through the use of batch auctions.

  • Backing buffer - percentage value that describes how much additional collateral tokens to keep in the BackingManager before forwarding tokens to the RevenueTraders. The RevenueTraders here refers to the RToken and RSR traders. This allows collateral tokens to be periodically converted into the RToken, which is a more efficient form of revenue production than trading each individual collateral for the desired RToken. It also provides a buffer to prevent RSR seizure after trading slippage. See more info here.

  • Max trade slippage - maximum deviation from oracle prices that any trade (during protocol operations, such as recollateralization auctions) can clear at. This is important because it acts as a form of slippage protection. Issuance throttle rate - allows the issuer to limit the amount of RTokens issued per hour based on a percentage of the current RToken market cap. This matters in the event of an exploit where an attacker tries to issue more RTokens. This buys time for users with pause or freeze permissions to temporarily prevent new RToken minting. For more info see the “Issuance throttle” section here.

  • Issuance throttle amount - similar to the ‘Issuance throttle rate’ above, but rather than being expressed as a percentage, the throttle limit is set as an absolute number of RTokens.

  • Redemption throttle rate - allows the issuer to limit the amount of RTokens redeemed per hour based on a percentage of the current RToken market cap. This matters in the event of an exploit where an attacker tries to redeem RTokens. This buys time for users with pause or freeze permissions to temporarily prevent RToken redemptions.

  • Redemption throttle amount - similar to the ‘Redemption throttle rate’ above, but rather than being expressed as a percentage, the throttle limit is set as an absolute number of RTokens

Other Parameters

  • Short freeze duration - Short freezers have the responsibility of freezing an RToken if anything dangerous or suspicious is happening. This is a one-shot freeze and the role will be revoked after a single use. This field determines how long the RToken will remain frozen until the freeze expires or is extended by another actor.

  • Long freeze duration - freeze an RToken’s system for a longer period of time. A long-freezer has 6 charges before losing the ability to freeze any more.

  • Unstaking delay - number of seconds that RSR stakers must wait before they are finally able to withdraw. This is done to prevent stakers from frontrunning defaults. This should be longer than the "governance cycle" to ensure stakers participate during basket changes.

  • Reward ratio - amount of the current reward amount that should be handed out in a single block. The default corresponds to a half life of approximately 30 blocks

  • Minimum trade volume - minimum sized trade that can be performed (during protocol operations, such as revenue auctions), in terms of the unit of account eg. USD

  • Maximum trade volume - maximum sized trade for any trade involving RToken, in terms of the unit of account eg. USD

Step 6: Deploy RToken

Once you are satisfied with your RToken’s name, basket composition, and governance parameters, you can click ‘Deploy RToken’ which will prompt you to sign a transaction.

Congratulations! You have successfully deployed your RToken. However, no governance system has been configured at this point yet. Continue reading to learn how to set up decentralized governance on your RToken using Governor Alexios.

Step 7: Set up Governance

  1. If you wish to use Governor Alexios (recommended), ensure the following toggle is active
  1. Carefully select addresses for Guardian and Pauser roles. See here for more details on system roles.

  2. Guardian - the Guardian has the permissions of the Pauser, the ability to invoke a LONG_FREEZE, and the ability to cancel any active proposals prior to execution. The Guardian is a highly permissioned role which should be entrusted to a multi-sig wallet

  3. Pauser - the Pauser can PAUSE and SHORT_FREEZE. When an RToken is paused, all interactions besides redemption, issuance cancellation, ERC20 functions and staking of RSR are disabled. When an RToken is frozen, all interactions besides ERC20 functions and staking of RSR are disabled
  1. Next, configure the ‘Governance parameters’

Register provides sensible defaults and unless you are an advanced user, you can deploy Governance using the defaults and skip this section

Governance parameters

  • Short freeze duration - Short freezers have the responsibility of freezing an RToken if anything dangerous or suspicious is hap
  • Snapshot delay - Delay (in number of blocks) since the proposal is submitted until voting power is fixed and voting starts. This can be used to enforce a delay after a proposal is published allowing for users to stake more RSR, or delegate their votes
  • Voting period - Length (in number of blocks) from when the proposal starts until voting ends
  • Proposal execution delay - The minimum amount of time after a proposal passes before it can be executed
  • Proposal Threshold - The minimum percentage of stRSR ownership on an RToken to be able to create a proposal
  • Quorum - The minimum percentage of stRSR voter participation (either For or Abstain) on a proposal before it can be passed

  • Select whether your RToken will be left in a paused state or whether it will be functional after configuring governance

The deployer should decide whether or not post deployment if the RToken should be active immediately, or whether or not governors should decide to start in a paused state.

Once you have completed that step, please click “Deploy Governance”. Once that transaction confirms, the RToken is live onchain with the RToken live state parameters you chose in Step 4.

Closing

All relevant contracts can be viewed under the “Related Contracts” section of the UI. The RToken is now ready to accept collateral assets and be used throughout the ecosystem. The process is complete!

The RToken is now ready your for your support to flourish.

If you need some assistance at any point in this process, feel free to reach out on Discord.