RToken Deployment Guide

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

To facilitate this, the Reserve protocol permissionlessly allows anyone to create RTokens backed 1:1 by collateral assets of their choosing. The options for governance design and RToken operational parameters available to deployers are essentially limitless.

This guide walks through the main steps and considerations to deploying an RToken using the Reserve Register app..

Before You Begin

Step 0: Before You Begin

Before deploying, it’s 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.

Questions to consider

Important factors to consider include:

• Is the collateral backing of your RToken diverse and/or attractive to users? (Find available collateral plugins here; alternatively, learn how to create a custom plugin)
• What are the yield targets (if any) for your RToken? (Get inspiration from DefiLlama, and fork this model to model your basket yield)
• Is there an interesting or unique revenue-sharing approach for your RToken? (Fork this model to help with calculation)
• What is the brand name, ticker, and one-line marketing hook for your RToken?
• What will the RToken’s mandate be? (The 256-character mandate describes what goals its governors should try to achieve)

If you’re unsure how to answer any or all of these questions, the Reserve community is welcoming and willing to help! Jump in the Reserve Discord server here.

Collateral and revenue

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

RToken revenue-sharing is multi-faceted and should be carefully considered. It is possible to direct underlying revenue in a number of 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 or send revenue for use in other ways such as incentivizing liquidity

Checklist review

• I know what network I wish to deploy on (Ethereum, Base, Arbitrum)
• I know what assets will comprise the collateral basket
• I know what the revenue distribution configuration will look like
• I have selected a token name and ticker
• I know what the RToken’s mandate will be
• I have studied and know what the RToken’s parameters will be (section 5 below)

Getting Started

Step 1: Getting Started

1. Navigate to the Reserve Register app
2. Connect your wallet using the Connect button in the top right
   
   
   
3. Scroll down to “Deploy your own RToken” and click Go to the RToken Deployer
   
   
   

Define your RToken

Step 2: Define your RToken

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

• Network - The RToken’s native blockchain
• Token Name - The RToken’s full name
• Ticker - The RToken’s abbreviated symbol (Staking token name and ticker are auto-generated)
• Mandate - Description of the goals the RToken’s 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.

Configure RToken Basket

Step 3: Configure RToken Basket

Now it’s time to define what collateral assets back your RToken, and in what proportions. Emergency collateral can also be defined as fallbacks in the event any primary collateral defaults.

A number of collateral plugins can be employed “out-of-the-box.” If a desired collateral plugin doesn’t already exist, developers may create and deploy custom plugins.

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

Note: In order to mint the RToken after it’s created, deployers must either have the selected collateral assets in their wallet, or use the “Zap Minting” utility, which enables minting using just 1 asset (e.g., mint eUSD using just USDC).

• Once satisfied with the selected assets, click “Add to basket”.
• Select your asset distributions, as well as the number of target units (e.g. USD, BTC, ETH) your “Target Basket” comprises.
  
  
  

Configure Backup Basket

Step 4: Configure Backup Basket

1. It’s 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).
   
   
   

Configure Parameters

Step 5: Configure Parameters

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

Note that the Reserve Register app provides sensible defaults and unless you’re 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 can be opened. This helps to avoid losses due to poor liquidity.
• Batch Auction length - defines how long (in seconds) Gnosis EasyAuction auctions should be. Gnosis EasyAuction is a platform enabling fair price discovery for tokens through the use of batch auctions. Read more here.
• Dutch Auction length - defines how long (in seconds) Dutch auctions should be. Dutch auctions are the preferred auction mechanism. Read more here.
• 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. It 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 - limits the amount of RTokens that can be issued per hour based on a percentage of the current RToken market cap. This matters in the event of an attacker front-running the detection of bad collateral.
• 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. The maximum of the 2 numbers is used to limit issuance.
• Redemption throttle rate - limits the amount of RTokens that can be 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. The maximum of the 2 numbers is used to limit redemptions.
• Warmup Period - the number of seconds that a RToken waits after it has reached a status of SOUND (i.e., fully collateralized, with all collateral assets in a “sound” state) in order to begin allowing issuance and trading.
• Unstaking Delay - the number of seconds that must pass after a user has unstaked their RSR before they can withdraw it. 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 - a fraction that represents how much of the accmulated revenue to hand out each second. This applies both to RToken melting in the Furnace and the RSR reward drip in StRSR. It is an exponential decay with a corresponding known half-life.
• Withdrawal Leak - a fraction that represents how much RSR could potentially leave StRSR before forcing an asset registry refresh. This is a gas optimization to help small unstakers.

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.
• Withdrawal leak - the percentage of total RSR that can be unstaked from stRSR before the RToken is forced to refresh its status. This allows smaller stakers to avoid massive gas costs when unstaking smaller amounts of RSR.
• 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

Deploy RToken

Step 6: Deploy RToken

Once you’re satisfied with your RToken’s name, basket composition, and other parameters, you can click “Deploy RToken” button which will prompt you to sign a transaction (“Tx1”).

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

Note that if you aren’t yet ready to set up governance, you can leave your RToken paused and return later to finish.

Set up Governance

Step 7: Set up Governance

1. If you wish to use Governor Anastasius (default; recommended by Reserve), ensure the following toggle is active
   
   
   
2. Carefully select addresses for Guardian and Pauser roles. See here for more details on system roles.
3. 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
4. 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
   
   
   

Next, configure the ‘Governance parameters’

Note that the Reserve Register app provides sensible defaults and unless you’re an advanced user, you can deploy Governance using the defaults and skip this section

Governance parameters

• Snapshot delay - Delay (in number of blocks) — Delay between when 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 (in hours) after a proposal passes before it can be executed
• Proposal Threshold - The minimum stRSR ownership on an RToken required (in percent) to be able to create a proposal
• Quorum - The minimum stRSR voter participation (either For or Abstain) on a proposal (in percent) 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 (In other words, the deployer decides whether the RToken should be active immediately post-deployment, or whether governors should decide to start in a paused state.)

Once you’ve made a selection, click “Deploy Governance”. Once that transaction confirms, the RToken is live onchain with the RToken live state parameters you chose above.

Closing

All of the RToken’s 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 deployment process is complete! That said, your new RToken’s journey has just begun — ongoing attention and marketing are required for RToken’s to distinguish themselves in a crowded marketplace and truly flourish.

Join the Reserve Discord server to share knowledge with and learn from other RToken deployers in the ecosystem.

Appendix

How to create custom RToken collateral plugins

Deployers have the option to create and use custom collateral plugins for an RToken by adding a custom plugin contract address in the Primary Basket or Emergency Collateral during the deployment process.

The following resources will be of use to those wishing to create custom collateral plugins:

• Collateral Plugin Overview describes what a developer needs to know to begin writing and contributing collateral plugins. Familiarity with this material is crucial before jumping into writing a plugin.
• Writing Collateral Plugins describes the general process a developer should follow when writing a new collateral plugin. Filling this out accomplishes 90% of the work necessary before any coding is required.
• Reserve’s Solidity Style details practices and conventions relevant to reading and writing Solidity source code in the Reserve house style.

Troubleshooting questions and feedback are always welcome in the Reserve Discord server. The #🔧|technical-discussions channel is actively monitored by core team engineers.

RToken deployer video tutorial

Coingecko / CoinMarketCap listings

CoinGecko and CoinMarketCap (CMC) are some of the largest information aggregators for crypto. Users considering buying a token will often first consult the relevant pages from these sites. Therefore, it is important for new RTokens to be listed on these sites, to increase the amount of trust and accessible information for prospective users.

View the CoinGecko/CoinMarketCap listing guide here.

Deploy a Curve pool

Creating a Curve pool for your RToken is an excellent way to provide liquidity and trading opportunities for users. The Deploying a Curve Pool guide outlines the necessary considerations for deploying a factory pool for your RToken.

Create Curve/Frax gauges

Liquidity gauges allow projects like Curve and Frax to incentivize liquidity with their own governance tokens, CRV and FXS, respectively.

Creating Curve/Frax Gauges walks through the process of creating a Curve gauge and a Frax gauge for your RToken’s Curve pool. Note that you should have a Curve pool deployed before embarking on this.