Skip to content
BitcoinToolkit

Reserve Rights (RSR): Minting and Redemption Follow the Current Basket

Reserve Rights is an ERC-20 protocol token used across Reserve decentralized token funds. Depending on the DTF, RSR can supply governance, vote locking or staked first-loss overcollateralization. This page focuses on minting and Redemption Follow the Current Basket and the checks users need before using the protocol or evaluating the token role.

Use or stake RSR while understanding that rights and first-loss exposure are specific to each Reserve DTF.

Subject:
Reserve Rights
Market mode:
Snapshot Only
Fee asset:
ETH / varies
Timezone:
UTC

This page does not rate a DTF, verify reserves, calculate a redemption, recommend RSR staking or guarantee that overcollateralization covers every loss.

Content ownership: BitcoinToolkit Editorial Team Technical references: Official protocol and developer documentation. Review approach: Technical explanations are checked against primary sources and updated when the network or asset changes. Last content review: Data integration last tested:

Minting and Redemption Follow the Current Basket

A portfolio token depends on the actual collateral plugins and basket state.

Issuance, redemption and rebalancing

A user mints a DTF by supplying the required basket quantities and redeems it for the current redemption basket. Governance can update backup collateral, parameters and basket composition under timelock and role rules. Collateral defaults can trigger trading and rebalancing rather than a fixed one-dollar redemption promise for every product.

Inspect basket composition, collateral status, issuance price, redemption output, slippage and gas before signing. Verify whether an asset is directly held, wrapped or represented through another protocol. A DTF market price can diverge from net asset value when liquidity is thin or redemptions are constrained by auctions, pauses, frozen collateral or host-chain congestion.

RSR Is Not the Asset Basket Inside a DTF

The protocol token and each issued portfolio token represent different claims.

Protocol token versus portfolio token

Reserve protocols let deployers create DTFs, also described as RTokens in parts of the system. A DTF token represents its configured basket and issuance or redemption rules. RSR is separate: it can be staked against a selected yield DTF or vote-locked for an index DTF according to that product configuration.

Holding RSR does not give a pro-rata claim on every collateral basket, and holding a DTF does not automatically create RSR voting power. Before interacting, verify the network, DTF contract, collateral registry, mandate, governance and RSR staking contract. The same Reserve interface can list products with materially different assets and risk policies.

Staked RSR Can Be First-Loss Capital

Revenue sharing compensates a position that can be seized and sold after a collateral shortfall.

Overcollateralization and governance

For supported yield DTFs, stRSR can provide overcollateralization. When collateral defaults and the basket cannot fully recover, the protocol can seize and sell staked RSR for the affected DTF. Stakers can receive a configured share of DTF revenue and participate in governance, but the protection is limited by available RSR value and auction conditions.

Evaluate each staking pool separately: basket quality, stRSR ratio, withdrawal delay, governance, revenue and concentration all matter. Do not call the position insured or assume staking one DTF protects another. A severe or correlated collateral loss can exceed the available backstop, and falling RSR market value can weaken effective coverage during stress.

Reserve Rights Risks Before Completion

Start with the exact DTF rather than the RSR ticker.

What Reserve Rights users should verify and why this design differs

DTF holders should inspect the basket and governance. Minters and redeemers should compare contract output, slippage and gas. RSR stakers should model first-loss exposure and exit delay. Voters should review the target DTF, proposal, execution delay and privileged roles. Keep the host-chain native asset available for every action.

Do not reuse a source or contract from a different DTF, treat a revenue percentage as guaranteed yield or assume an official interface removes issuer and smart-contract risk from collateral tokens. Preserve transaction hashes and governance proposal IDs, then use wallet and security tools for the actual contracts and approvals.

Reserve Rights Network use FAQ

Does holding RSR make every Reserve Rights application transaction-ready?

No. RSR is the protocol asset shown in the market snapshot. The wallet still needs the correct network, fee asset, contract or program, and any application-specific token or permission.

Known Limitations

Market Data Methodology

The page uses a CoinGecko aggregated RSR/USD snapshot. No exchange chart is rendered for this entity.

Market Snapshot Source
CoinGecko aggregated market data (RSR/USD)
Cache
Snapshot cache is approximately 60 seconds.
Failure Handling
Verified cached data is labeled Cached or Delayed. Missing values remain unavailable.
Snapshot Status
Delayed
Report Issue
Report a market-data problem →

Technical Sources

Selected primary sources support the operational explanations. Market-provider attribution remains separate.

Editorial Information

Verified technical content, reviewed sources and update history.

Published
Last Review
Data Verification
Sources
Official documentation