Overview
Yield DTFs: Overview
The Reserve Yield Protocol allows anyone to create diversified baskets backed by yield-bearing ERC-20 tokens on Ethereum, Base, and Arbitrum. The protocol enables permissionless launch, onchain governance, and autonomous operations for yield-bearing Decentralized Token Folios (DTFs):
-
Permissionless creation & NAV-based issuance. Anyone can deploy a Yield DTF and let users mint or redeem at real-time asset value, with no reliance on offchain custodians.
-
Built-in yield capture & routing. Collateral earns staking, lending, or other rewards; smart contracts harvest and distribute them automatically based on governance-defined routing.
-
RSR-backed overcollateralization. Staked Reserve Rights (RSR) can create a first-loss safety buffer, insulating the basket from collateral shortfalls and aligning incentives through shared fees.
-
Transparent, token-holder governance. Parameters like fee rates, collateral mixes, and risk limits are managed onchain, keeping control in the community’s hands.
Together, these capabilities enable anyone to launch a fully collateralised, yield-accruing basket with robust decentralized infrastructure.
Once a Yield DTF configuration has been deployed, the DTF's tokens can be minted by depositing the entire basket of collateral backing tokens, and redeemed for the entire basket as well. Thus, a DTFs will tend to trade at the market value of the entire basket that backs it, as any lower or higher price could be arbitraged.
Overcollateralization
Yield DTFs can be overcollateralized, which means that if any of their collateral tokens defaults, there's a pool of value available to make up for the loss. Overcollateralization is provided by RSR holders, who may choose to stake their RSR on any Yield DTF. Staked RSR can be seized in the case of a collateral default, in a process that is entirely mechanistic based on onchain price-feeds, and does not depend on any governance votes or human choices.
Yield DTFs can generate revenue, and this revenue is the incentive for RSR holders to stake. Revenue can come from yield from lending collateral tokens onchain, revenue shares with collateral token issuers, or any other source of onchain yield. Governance can direct any portion of revenue to RSR stakers, to incentivize RSR holders to stake and provide overcollateralization. If a Yield DTF generates no revenue, or if none of it is directed to RSR stakers, there is no incentive to stake RSR on it, so it is unlikely to be protected by overcollateralization.
For the kinds of DTFs the core team is imagining, default will be an extremely rare "black-swan" situation, not something that occurs regularly. But still, it could happen, and the purpose of the overcollateralization mechanism is to preserve Yield DTF holders’ value if it does.
Revenue handling
Yield‑bearing collateral—such as interest‑bearing tokens or LP positions—accrues value over time. The protocol’s Backing Manager periodically harvests this surplus and converts it into liquid assets.
Governance determines how the harvested revenue is divided among three outlets: DTF holders, RSR stakers, and any additional addresses specified by governance. Once the accumulated surplus crosses a configurable threshold, the Backing Manager initiates an onchain auction to exchange the excess collateral for more shares of the DTF and/or RSR.
Newly acquired DTF shares are burned, increasing the token’s redeemable value. Proceeds routed to stakers are swapped for RSR and deposited into the stRSR contract, raising the stRSR/RSR exchange rate. Because the entire cycle is autonomous, revenue compounds transparently without manual intervention.
Governance
Each Yield DTF is governed separately, and each can have an entirely different governance system. Initial Yield DTFs will likely have relatively simple governance systems, which will probably evolve over time. That evolution is up to those that hold power in the initial governance systems.
Governance defines not just the basket to back a Yield DTF, but also an ordered list of emergency collateral. So there's a current basket, and a series of assets that can be deployed to the basket in the case of a default. A collateral token is considered to have defaulted if it's gone down in value more than a defined amount for a long enough time, relative to its reference or target unit (described in the Monetary Units section).
Governance can update the basket configuration regularly. When the current basket is updated, or in the case of a default, the protocol makes onchain trades to reach the new basket composition. This trading is modularized so that it can happen in different ways over time as onchain liquidity evolves. Currently, trading plugins support Gnosis Auctions (batch auctions) and Dutch Auctions, but in the future additional methods can be incorporated.
As with any smart contract application, the actual behavior may vary from the intended behavior, and it's safest to wait for an application to be in use for a long period of time before trusting it to behave as expected. This overview and subsequent documentation describes the intended behavior.
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).
