Staking
Reserve Rights (RSR)
Reserve Rights (RSR) is an ERC-20 token that unifies governance, risk management, and value accrual across the Reserve ecosystem. RSR has three main roles:
-
Staking on Yield DTFs: RSR stakers provide governance and first-loss capital (overcollateralization) in exchange for DTF yield.
-
Vote-locking on Index DTFs: RSR is the default governance token for Index DTFs, controlling basket changes, parameters, and upgrades—and sharing in fees when enabled.
-
Deflationary sink: A portion of every Index DTF’s mint and TVL fees is used to market-buy RSR and burn it, steadily reducing the circulating supply.
All the relevant information regarding RSR’s supply, audits, etc. can be found through the links below:
- Source code
- Live contract
- Audit
- Supply dashboard
- Markets: CMC / CoinGecko
Staking
Staking on Yield DTFs
In the Reserve Yield Protocol, staked Reserve Rights (stRSR) provides an overcollateralization mechanism to protect DTF holders in the unlikely event of a collateral token default. In order for RSR holders to provide this overcollateralization, they can decide to stake on any one Yield DTF, or divide their RSR tokens by staking on multiple DTFs. RSR holders can also decide not to stake their RSR at all.
In return for providing this overcollateralization, RSR stakers can expect to receive a portion of the revenue from the specific DTF that they stake on. As a general rule, RSR stakers will receive more revenue as the market cap of the DTF they stake on increases.
When RSR is staked on a DTF, it is deposited into a staking contract specific to that DTF, and the staker receives a corresponding ERC-20 token, representing their staked RSR position on that particular DTF. This token is transferrable and fungible with other staked RSR balances for that DTF, so you can send any portion of the staked position to someone else or trade it, and the new holder can un-stake it if they choose to.
Staked RSR can earn rewards, based on three factors:
- The amount of revenue the DTF generates
- The portion of revenue that governance has directed to RSR stakers
- Your portion of the total RSR staked on that DTF
As a simple example, suppose (these numbers are just made up for simplicity, to make the arithmetic clear):
- A fictional DTF generated $100 in revenue in a period
- 20% of revenue was designated for RSR stakers
- 1000 total RSR was staked
- You had staked 100 of the total 1000 RSR that is staked
In this simple example, you would get $100 * 0.2 * (100/1000) = $2
for that period.
The protocol stores revenue for a particular Yield DTF in different ERC20s (including DTFs). When staking rewards are distributed, it market-buys RSR via auctions with these ERC20s and deposits it into the staking contract to distribute the rewards to RSR stakers. Thus, as rewards are earned, the exchange rate of staked RSR to RSR increases.
When RSR is staked, it is actually at stake. Staked RSR can be seized by the protocol in the event of a collateral token default, in order to cover losses for DTF holders. It is seized pro-rata if this happens.
Un-staking RSR comes with a delay, which is configurable by governance, and predicted to usually be between about 7 and 30 days. This delay is necessary so that in the event of a default, the staked RSR will remain in the staking contract for long enough to allow the Yield DTF to seize any RSR it needs to cover losses.
During the unstaking delay period, the staker does not earn any rewards. This is necessary to prevent stakers from withdrawing and re-depositing over and over in order to subvert the withdrawal delay mechanism. It is possible for users to cancel unstakings at any time to resume staking and earning rewards.
The easiest way to stake your RSR is to use a user interface that interacts with the Reserve Protocol smart contracts, such as the Reserve app. If you're looking for an easy tutorial on how to stake, please refer to this article.
Slashing
In the event a collateral defaults RSR will be seized to cover the loss. As a result, the stRSR exchange rate to RSR will decrease. In most cases this will not impact balances, but it is important to note that in the case of a 100% slashing event (rare) the balances will be zeroed out in order to allow the staking pool to continue operating under new stakers.
Vote-locking
Vote-locking on Index DTFs
With the launch of the Reserve Index Protocol, RSR gained a second governance pathway: vote-locking. By default, Index DTFs use RSR as their governance token, but a creator can designate any ERC-20 instead. Vote-locking commits the chosen token to a specific Index DTF for a minimum period—currently a one-week unlock delay—where it carries voting weight over that DTF’s parameters and upgrades.
When tokens are locked, the entire balance counts 1-for-1 toward governance power. This lets participants steer matters such as basket composition, weighting rules, fee splits, and the cadence of rebalances with influence proportional to their economic stake.
For DTFs that enable revenue sharing, vote-lockers also earn a pro-rata slice of the DTF’s minting and TVL fees, creating a reward stream that is independent of the staking yields available in Yield DTFs. Although any ERC-20 can serve as the locking asset, every Index DTF still contributes to RSR’s value because platform fees are used to market-buy and burn RSR, producing a deflationary sink that scales with DTF adoption.
For an easy tutorial on how to vote-lock, please refer to this article.
Fee burn
Index Protocol fee burn
Every Index DTF levies platform fees on new mints and on the value locked in the contract. Those fees are swept into a protocol-level contract that automatically uses them to market-buy RSR and then sends the purchased tokens to the burn address, permanently removing them from circulation. As Index adoption grows, a larger and steadier flow of fees is converted into burns, introducing a structural deflationary pressure on the RSR supply.
Because the burn mechanism lives at the protocol layer, it applies to every Index DTF—regardless of which governance token the fund chooses for vote-locking—so a diverse ecosystem of indexes all contribute to the same burn stream. The percentage of each fee that feeds the burn contract is itself governed onchain, allowing RSR vote-lockers to dial the burn rate up or down as they weigh deflation against other priorities such as treasury growth or incentive budgets.
Governance
While each DTF can have its own customized governance system, we expect most DTFs to use our default configuration where the amount of RSR tokens a participant stakes or locks serves as the voting weight.
Both Yield DTFs and Index DTFs follow the same transparent, community-driven governance flow:
- Proposal. Any address holding the proposal threshold of voting weight may submit a change.
- Vote. Holders cast votes for, against, or abstain (directly or by delegation) over a fixed voting period.
- Execution. Successful proposals queue in a time-lock, giving stakeholders and markets time to react before the update is applied onchain.
Governance is designed to be community-driven, which means anyone can propose changes to modify or improve a DTF.
For Yield DTFs, Governor Anastasius is the protocol's recommended governor implementation, which is detailed next.
Governor Anastasius
The Reserve team has deployed a recommended governance system for Yield DTFs (Reserve Governor Anastasius) that will be suggested to DTF deployers by default. This governance system is a slightly modified version of OpenZeppelin Governor.
Governor Anastasius allows RSR holders to participate in the decision-making process of the Yield Protocol by proposing, voting on, and executing proposals. It follows a delegation system where RSR holders can delegate their voting power to other addresses. This enables efficient participation in the decision-making process and increases voter turnout.
The following parameters can be configured for the governance process:
Proposal Threshold
: The minimum voting weight required to create a proposal.Quorum
: The minimum total voting weight required to consider a voting valid.Voting snapshot delay
: The time to stake between when the proposal is created and the snapshot of voting weights is taken.Voting period
: The duration of the voting period for each proposal.Execution delay
: The delay before a successful vote is executed. Provides time for DTF holders to make a decision before changes are applied.
By default, the end-to-end process for approving & executing proposals is 8 days:
- Voting snapshot delay: 2 days
- Voting period: 3 days
- Execution delay: 3 days
In addition to the Owner role, each Yield DTF has several additional assignable roles: the Pauser, the Short Freezer, the Long Freezer, and the Guardian—which can be given to any Ethereum addresses by the DTF deployer/owner. Each has the ability to put their DTF’s system into certain states in the case of an attack, exploit, or bug. These states are:
- Paused: when a DTF’s system is paused, all interactions besides redemption, ERC20 functions, staking of RSR, and rewards payout are disabled.
- Frozen: when a DTF’s system is frozen, all interactions besides ERC20 functions and staking of RSR are disabled.
For additional information, please refer to the System States + roles section.
Supply
Reserve Rights (RSR) has a fixed total supply of 100 billion tokens, out of which there are currently 53.5b in circulation. The remaining 46.5b tokens belong to the Slow and Slower Wallets.
The Slow Wallet is a locked wallet controlled by the Reserve project team, used to fund DTF adoption initiatives. It has a hard-coded 4-week delay after initiating each withdrawal transaction on the blockchain.
In January 2024, organizational changes were announced to the Reserve Ecosystem. As part of these changes, Confusion Capital is a new entity who will manage funding for the Reserve Ecosystem, including Best Friend Finance, and ABC Labs (who focuses on core protocol development). The Slower Wallet is a wallet that is administered by Confusion Capital (receiving a portion of funds from the Slow Wallet), which imposes additional withdrawal restrictions.
The Slower Wallet maintains the 4-week withdrawal delay and adds a further limitation that no more than 1% of the total supply of RSR can be withdrawn in any 4-week period. The reason for the change is merely to reduce the degree of trust that anyone needs to place in Confusion Capital. Following is an illustrative example of how this works:
- No withdrawals are made for a while
- Throttle limit (max available): 1,000,000,000 RSR
- Withdrawal initiated for 1 billion RSR
- Throttle limit: 0 RSR
- 2 weeks pass
- Throttle limit: 500,000,000 RSR
- Withdrawal initiated for 250,000,000 RSR
- Throttle limit: 250,000,000 RSR
- 1 week passes
- Throttle limit: 500,000,000 RSR
Future RSR emissions are set on a deterministic schedule which emulates the emissions curve of Bitcoin. For more details on this decision, check out this blog post, or visit CoinMarketCap's Token Unlock page to see the exact RSR unlock timeline.

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 ABC Labs the company that's leading 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.
Non-compatible ERC20 assets
The following types of ERC20s are not supported to be used directly in an RToken system. These tokens should be be wrapped into a compatible ERC20 token to be used within the protocol. A concrete example is the use of Static ATokens for Aave V2.
- Rebasing Tokens that return yields by increasing the balances of users
- Tokens that take a "fee" on transfer
- Tokens that do not expose the decimals() in their interface. Decimals should always be between 1 and 18.
- ERC777 tokens which could allow reentrancy attacks
- Tokens with multiple entry points (multiple addresses)
- Tokens with multiple entry points (multiple addresses)
- Tokens that do not adhere to the ERC20 standard in general
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)
The trading delay defines how many seconds should pass after the basket has been changed before a trade can be opened.
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).