This page details the various RToken governance parameters and sensible defaults we recommend for deployers. This information can also found on Register’s Deployment Wizard.
| Param | Default (mainnet) | Base | eUSD (for reference) | Notes | Type (relative importance) |
|---|---|---|---|---|---|
| Trading Delay (s) | 7200 | 7200 | 7200 | How many seconds should pass after the basket has been changed, before a rebalancing trade is opened. Why does this matter? To avoid losses due to poor liquidity. | routine |
| Dutch Auction Length (s) | 1800 | 1800 | 1800 | Defines how many seconds long falling-price dutch auctions should be. A longer period will generally result in less slippage due to better price granularity, and a shorter period will result in more slippage. | routine |
| Batch Auction Length (s) | 900 | 900 | 900 | 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. | routine |
| Warmup period (s) | 900 | 900 | 900 | The warmup period is how many seconds should pass after the basket regained the SOUND status before an RToken can be issued and/or a trade can be opened. | routine |
| Backing Buffer | .1% | .1% | .01% | The % 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. Why this matters? It 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. For more info on the BackingManager and Trader types see our docs on https://reserve.org/protocol/protocol_operations/#revenue-distribution. | routine |
| Max Trade Slippage | 0.5% | 0.5% | 1% | Maximum deviation from oracle prices that any trade can clear at. Why this matters? Acts as a form of slippage protection. | routine |
| Min Trade volume | 1,000 | 100 | 1,000 | Minimum sized trade that can be performed, in terms of the unit of account eg. USD. | routine |
| RToken Max Trade Volume | 1,000,000 | 1,000,000 | 1,000,000 | Maximum sized trade for any trade involving RToken, in terms of the unit of account eg. USD. | routine |
| Issuance Throttle Rate | 5% | 5% | 5% | 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 reduce the amount of RTokens that can be issued. | routine |
| Issuance Throttle Amount | 250,000 | 250,000 | 250,000 | Allows the issuer to limit the amount of RTokens issued per hour. 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 reduce the amount of RTokens that can be issued. |
In RToken amounts (not dollars), so should be reconsidered for non-USD RTokens. | routine | | Redemption Throttle Rate | 7.5% | 7.5% | 7.5% | 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 reduce the amount of RTokens that can be redeemed. | routine | | Redemption Throttle Amount | 500,000 | 500,000 | 500,000 | Allows the issuer to limit the amount of RTokens redeemed per hour. 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 reduce the amount of RTokens that can be redeemed.
In RToken amounts (not dollars), so should be reconsidered for non-USD RTokens. | routine | | Short Freeze duration (s) | 259200 (3 days) | 259200 (3 days) | 259200 | 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. | routine | | Long Freeze duration (s) | 604800 (1 week) | 604800 (1 week) | 604800 (1 week) | 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. | routine | | Unstaking delay (s) | 1209600 (2 weeks) | 1209600 (2 weeks) | 1209600 | Number of seconds that all RSR unstaking must be delayed in order to account for stakers trying to frontrun defaults and needs to be longer than "governance" for proper incentives for basket changes. | routine | | Withdrawal leak (%) | 5 | 5 | 5 | The fraction of RSR stake that should be permitted to withdraw without a refresh. When cumulative withdrawals (or a single withdrawal) exceed this fraction, gas must be paid to refresh all assets. | routine | | Reward ratio (decimals) | 0.0000064180294 for 15 day half-life | 0.0000064180294 for 15 day half-life | 0.0000032090147 for 30 day half-life | Relates to the Furnace + Drip. Large amount of RToken comes in to be melted… how much should be handed out every block?
use http://calculator.net/half-life-calculator.html and put in your half life of payouts to get the decay constant. | routine | | Snapshot delay (blocks) | 14,400 blocks (2 days) | 86400 blocks (2 days) | 14,400 blocks | 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 for users to buy tokens, or delegate their votes. | structural | | Voting period (blocks) | default: 3 days (21,600 blocks) | default: 3 days (129,600 blocks) | default: 3 days (21,600 blocks) | Delay (in number of blocks) since the proposal starts until voting ends. | structural | | Proposal execution delay (s) | 3 days (259,200 seconds) | 3 days (259,200 seconds) | 3 days (259,200 seconds) | The minimum amount of time after a proposal passes before it can be executed. | structural | | ProposalThreshold (%) | 0.01% | 0.01% | 0.01% | The minimum percentage of stRSR ownership on an RToken to be able to create a proposal. | structural | | Quorum (%) | 10% | 10% | 15% | The minimum percentage of stRSR voter participation (either For or Abstain) on a proposal before it can be passed. | structural |