Deploying a Yield DTF
Anyone can create a DTF—permissionless & production‑ready in under 10 minutes.
This guide walks deployers through the launch process: strategic design, parameter configuration, deployment, and post‑launch best practices.
Overview
The Reserve Yield Protocol provides a system of factory smart contracts that allows anyone to deploy their own Yield DTF instance onchain.
Creating a Yield DTF can be done either by interacting directly with the Reserve Yield Protocol’s smart contracts or any user interface built on top of them. The Reserve app provides a convenient interface to the Yield DTF factory, but any front‑end can access the same permissionless contracts.
Learn more
Getting started → Designing a successful Yield DTF
Deployment walkthrough → Using the Reserve app UI
Reference parameters → Advanced parameters
Post‑launch playbook → Tips for DTF success & adoption
Anyone can create an RToken
In the same way anyone can create a new trading pair on a DEX, anyone can permissionlessly create a new Reserve stablecoin (RToken) by interacting with Reserve Protocol’s smart contracts. The protocol uses a system of factory smart contracts to deploy new instances.
Creating an RToken can be done directly via the Reserve Protocol smart contracts or through UIs built on top of them. The first such UI will be released by ABC Labs, the company leading protocol development. That UI will support RToken creation, exploration, minting & redeeming, and RSR staking.
Non-compatible ERC20 assets
The following ERC20 types are not supported directly in an RToken system. These tokens should be wrapped into a compatible ERC20 before use (a concrete example: Static ATokens for Aave V2).
Rebasing tokens that return yield by increasing user balances
Tokens that take a "fee" on transfer
Tokens that do not expose the decimals() in their interface (decimals should 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
Advanced RToken parameters
When deploying an RToken, deployers can configure many advanced parameters. The documentation details what each parameter does and considerations for setting them.
Many parameters relate to Protocol Operations, so we recommend reading that section first to get the necessary context.
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 an underlying DeFi protocol breaks. Without a trading delay, the protocol could react instantly by opening an auction and allow only auctionLength seconds for bids, increasing the risk of losing value due to slippage.
This parameter may only be needed early on—before a robust market of MEV searchers exists. The expectation is it can be set to zero later once such a market is established.
Related pages
Smart Contracts