Deployment walkthrough
The Reserve Yield Protocol allows anyone to permissionlessly create Yield DTFs backed 1:1 by collateral assets of their choosing. The options for governance design and operational parameters available to deployers are essentially limitless.
This guide walks through the main steps to deploying a Yield DTF using the Reserve app.
Getting Started
Step 1: Getting Started
- Navigate to the Yield DTF deployer UI
- Connect your wallet using the Connect button in the top right
Define your DTF
Step 2: Define your DTF
A DTF'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 DTF's native blockchain
- Token Name - The DTF's full name
- Ticker - The DTF's abbreviated symbol (Staking token names and tickers are auto-generated)
- Mandate - Description of the goals the DTF's governors should try to achieve. By briefly explaining the DTF’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 Basket
Step 3: Configure Basket
Now it’s time to define what collateral assets back your DTF, 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 DTF 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
- It’s generally recommended to configure Emergency Collateral in a backup basket. These are defined separately for each target unit.
- The ‘Diversity factor’ of your backups dictates the number of backup assets the DTF 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. For more information on each parameter, see Advanced Parameters.
Note that the Reserve 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
Parameter | Default | Purpose | Common adjustments |
---|---|---|---|
Trading delay | 0 s | Delay before trading after basket change; avoids thin‑liquidity losses | Longer for illiquid tokens |
Warm‑up period | 15 min | Delay after SOUND status before mint/trade opens | Rarely changed |
Batch‑auction length | 15 min | Duration of Gnosis EasyAuction batch auctions | Extend in low‑volume markets |
Dutch‑auction length | 30 min (mainnet) 15 min (L2s) | Duration of preferred Dutch auctions | Extend in illiquid markets |
Backing buffer | 0.1% | Extra collateral held before forwarding to Revenue Trader | Increase for illiquid assets |
Max trade slippage | 0.5% | Max deviation from oracle price per trade | Increase for illiquid assets |
Issuance throttle rate | 10% per hour | Cap on new mints (% of supply) | Relax (increase) after launch |
Issuance throttle amount | 2M per hour | Absolute mint cap (larger of rate vs amount) | Adjust for TVL |
Redemption throttle rate | 12.5% per hour | Cap on redemptions (% of supply) | Relax (increase) if basket very liquid |
Redemption throttle amount | 2.5M per hour | Absolute redemption cap | Adjust for TVL |
Other Parameters
Parameter | Default | Purpose |
---|---|---|
Short‑freeze duration | 3 days | One‑shot short freeze window |
Long‑freeze duration | 1 week | Long freeze window (6 charges) |
Withdrawal leak | 5% | Max RSR that can exit StRSR before status refresh |
Unstaking delay | 2 weeks | Wait after unstake before RSR can be withdrawn |
Reward ratio | 7‑day half‑life | Exponential drip rate of accrued rewards |
Minimum trade volume | $1000 USD | Prevents micro‑auctions on dust balances during rebalancing (not during revenue processing auctions) |
RToken max trade volume | $1M USD | Upper limit for trades involving the DTF token |
Deploy
Step 6: Deploy
Once you’re satisfied with your DTF’s name, basket composition, and other parameters, you can click “Deploy” button which will prompt you to sign a transaction (“Tx1”).

Congratulations! You have successfully deployed your Yield DTF. However, no governance system has yet been configured. Continue reading to learn how to set up decentralized governance on your DTF 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
- If you wish to use Governor Anastasius (default; recommended by Reserve), ensure the following toggle is active
- Carefully select addresses for Guardian, Pauser, and Freezer roles. See here for more details on system roles.
Addresses for each role are separate from each other and from the Guardian. However, often, the Guardian address is also included in the other three roles.
Next, configure the ‘Governance parameters’
Note that the Reserve app provides sensible defaults and unless you’re an advanced user, you can deploy Governance using the defaults and skip this section
Governance parameters
Parameter | Default | Purpose |
---|---|---|
Snapshot delay | 2 days | Time between proposal submission and vote‑power snapshot/voting |
Voting period | 3 days | Time from vote start to vote end |
Proposal execution delay | 3 days | Time between vote success and execution |
Proposal threshold | .01 % of stRSR | Minimum stake needed to submit a proposal |
Quorum | 10% of stRSR | Minimum “for + abstain” participation to pass |
Select whether your DTF will be left in a paused state or whether it will be functional after configuring governance (In other words, the deployer decides whether the DTF 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 DTF is live onchain with the live state parameters you chose above.

Closing

All of the DTF’s relevant contracts can be viewed under the “Related Contracts” section of the UI. The DTF is now ready to accept collateral assets and be used throughout the ecosystem.
The deployment process is complete! That said, your new DTF’s journey has just begun — ongoing attention and marketing are required for DTFs to distinguish themselves in a crowded marketplace and truly flourish. Check out the post‑launch playbook for helpful tips.
Join the Reserve Discord server to share knowledge with and learn from other DTF 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.
Non-compatible ERC-20 assets
The following types of ERC-20s are not supported to be used directly in a Yield DTF system:
- 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 that do not adhere to the ERC-20 standard in general
These tokens should be wrapped into a compatible ERC-20 token to be used within the protocol. A concrete example is the use of Static ATokens for Aave V2.
Yield DTF deployer video tutorial
How to deploy in about 5 minutes
This video demonstrates how to deploy a Yield DTF on the Reserve Protocol using app.reserve.org. The process involves defining the DTF name, ticker, primary and emergency collateral baskets, revenue distribution, and governance parameters, followed by deploying the RToken and governance smart contracts.
06:46Anyone 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).