RSR (Reserve Rights)
RSR is the token that allows anyone to own a share in the value of everything. It enables participation in DTF governance and by returning a portion of protocol fees to RSR holders through token burns.
Below is a detailed overview of RSR and how it functions within the Reserve ecosystem.
Technical overview
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:
Yield DTFs
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. RSR holders can stake on any one Yield DTF, or split their tokens across multiple DTFs, or choose not to stake.
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 DTF. This token is transferable 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 unstake 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
Example calculation (illustrative values):
DTF revenue: $100
Revenue designated for RSR stakers: 20%
Total RSR staked: 1,000
Your stake: 100
Reward: $100 * 0.2 * (100/1000) = $2
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, configurable by governance and typically between about 7 and 30 days. This delay ensures staked RSR remains available long enough to cover potential defaults. During the unstaking delay period, the staker does not earn any rewards. Users can 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. For a tutorial, see this article.
Slashing
If a collateral defaults, RSR will be seized to cover the loss, causing the stRSR exchange rate to RSR to decrease. In most cases this will not impact balances, but in the rare event of a 100% slashing, balances can be zeroed to allow the staking pool to continue operating under new stakers.
Vote-locking
Vote-locking on Index DTFs
With the Reserve Index Protocol, RSR gained vote-locking. By default, Index DTFs use RSR as their governance token (a creator may 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 allows participants to influence basket composition, weighting rules, fee splits, and rebalance cadence proportionally to their economic stake.
For DTFs that enable revenue sharing, vote-lockers earn a pro-rata slice of the DTF’s minting and TVL fees—creating a reward stream independent of staking yields in Yield DTFs. Although any ERC-20 can be the locking asset, Index DTF fees are used to market-buy and burn RSR, contributing to a deflationary sink as adoption grows.
For a tutorial on vote-locking, see 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. 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 governed onchain.
Governance
While each DTF can have its own governance system, most DTFs are expected to use the default configuration where the amount of RSR a participant stakes or locks serves as voting weight.
Both Yield DTFs and Index DTFs follow the same 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.
Anyone can propose changes to modify or improve a DTF.
Governor Anastasius
The Reserve team recommends Governor Anastasius for Yield DTFs (a slightly modified version of OpenZeppelin Governor). It allows RSR holders to propose, vote on, and execute proposals using delegation.
Configurable governance parameters include:
Proposal Threshold
Quorum
Voting snapshot delay
Voting period
Execution delay
Default end-to-end timing (8 days total):
Voting snapshot delay: 2 days
Voting period: 3 days
Execution delay: 3 days
In addition to the Owner role, each Yield DTF has assignable roles: Pauser, Short Freezer, Long Freezer, and Guardian. These can be granted by the DTF deployer/owner and put the DTF into protected states in case of an attack, exploit, or bug:
Paused: All interactions besides redemption, ERC20 functions, staking of RSR, and rewards payout are disabled.
Frozen: All interactions besides ERC20 functions and staking of RSR are disabled.
For more details, see System States + roles.
Supply
Reserve Rights (RSR) has a fixed total supply of 100 billion tokens, of which currently 53.5b are in circulation. The remaining 46.5b 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 onchain.
In January 2024, organizational changes named Confusion Capital as the entity to manage funding for the Reserve Ecosystem (including Best Friend Finance and ABC Labs). The Slower Wallet is administered by Confusion Capital and receives a portion of funds from the Slow Wallet. It maintains the 4-week withdrawal delay and adds a throttle: no more than 1% of the total supply of RSR can be withdrawn in any 4-week period. The change reduces the trust required in Confusion Capital.
Illustrative example of the throttle behavior:
Future RSR emissions follow a deterministic schedule that emulates Bitcoin's emissions curve. For more details see Reducing RSR emissions or view the unlock timeline on CoinMarketCap's Token Unlock page.
Anyone can create an RToken
Anyone can permissionlessly create a new Reserve stablecoin (RToken) by interacting with Reserve Protocol’s factory smart contracts. Creation can be done directly via smart contracts or through user interfaces built on top of them. ABC Labs will release a user interface supporting RToken creation, exploration, minting & redeeming, and RSR staking.
See the protocol docs for more on factory contracts: https://reserve.org/protocol/reserve_rights_rsr/#
Non-compatible ERC20 assets
The following ERC20 types are not supported directly in an RToken system and must be wrapped into compatible tokens first:
Rebasing tokens (that increase user balances to return yield)
Tokens that take a "fee" on transfer
Tokens that do not expose decimals() in their interface (decimals must be between 1 and 18)
ERC777 tokens (could allow reentrancy attacks)
Tokens with multiple entry points (multiple addresses)
Tokens that do not adhere to the ERC20 standard in general
A concrete example is using Static ATokens for Aave V2—these should be wrapped into compatible ERC20s.
Advanced RToken parameters
When deploying an RToken, the deployer can configure many advanced parameters. These parameters interact with the Protocol Operations and deployers should read that section for full context.
Trading delay(s)
The trading delay defines how many seconds must pass after the basket has been changed before a trade can be opened.
A collateral asset can instantly default if an invariant of the underlying DeFi protocol breaks. Without a trading delay, the protocol would react instantly by opening an auction, giving only auctionLength seconds for bids and increasing risk of slippage and loss. The trading delay may be needed mainly in early days before a robust market of MEV searchers is established; it can potentially be set to zero later when such a market exists.
Additional resources
Reserve protocol introduction
Yield DTFs documentation
Last updated