# What is the Reserve project? The Reserve project is guided by the belief that **everyone should be able to own their share of the world’s wealth**. Its platform lets anyone hold and transfer an entire portfolio of tokenized assets as a single unit, so as more of the world’s wealth moves onchain, anyone can own their share of it. This lays the groundwork for *asset-backed currency*: money backed by real assets rather than inflationary fiat that loses purchasing power over time. When people earn more than they spend while holding value this way, they steadily build ownership of a share of the world’s wealth. Reserve is not just a platform. It’s a coordinated universe of protocols, products, and partners working to make this belief real in practice. The sections that follow outline the project’s long-term goal, how it works, and how to participate. # Long-term goal Reserve is a long-term project. To make asset-backed currency possible, we first needed a platform for bundling assets together onchain, a system where entire portfolios can be created, held, transferred, and governed as a single unit. That same platform can support many kinds of diversified investment products. While the long-term goal is asset-backed currency, the underlying infrastructure is useful today. So Reserve makes this core platform available now, while continuing to prepare the remaining pieces required for asset-backed currency. That is why the first product line is crypto index products, starting with the assets that already exist and are widely used: native crypto tokens. For example, the CMC20 DTF tracks CoinMarketCap’s top 20 cryptocurrencies by market capitalization, similar to how the S\&P 500 tracks the largest public companies, but for crypto. These products are called DTFs, Decentralized Token Funds. DTFs are onchain portfolios governed by transparent, predefined rules. Today, DTFs hold crypto assets. As more assets become tokenized, DTFs can expand to include stocks, bonds, commodities, and real estate. Over time, a single DTF could represent broad exposure to global assets, including equities, fixed income, crypto, and hard assets, all held and transferred as one unit. These products lay the groundwork for asset-backed currency. As assets become tokenized and can be exchanged programmatically, value does not need to sit in fiat between transactions. Instead, value can be held in diversified portfolios and converted at the moment of payment. If someone earns more than they spend while holding value this way, their exposure to underlying assets increases over time, and they steadily build ownership of a share of the world’s wealth. {% embed url="" %} CEO Nevin Freeman highlights the two primary long-term challenges that must be addressed for asset-backed currencies to thrive {% endembed %} # How it works The Reserve project consists of a set of protocols, products, contributors, and initiatives, all built around a single belief: that everyone should be able to own and earn their share of the value of everything. ## Core components ### Reserve’s protocols The Reserve Index Protocol and Reserve Yield Protocol are the foundation that gives access to the value of everything. They define how assets are bundled, backed, redeemed, and transferred onchain. Assets governed by the protocols follow shared, transparent sets of rules, making it possible to hold diversified value directly. Everything in the Reserve ecosystem builds on this foundation. ### DTFs (Decentralized Token Funds) DTFs let anyone own and earn on everything. They are portfolios of onchain assets, managed by smart contracts. Some are designed to hold value steadily, while others are designed to generate yield. Together, they make it possible to hold diversified value as a single token. Today, DTFs are built from crypto assets. Over time, as more assets are tokenized, they can include stocks, bonds, commodities, and real estate. As tokenization expands, DTFs make it possible to hold increasingly broad representations of the world’s value. * **Index DTFs** let you own a share of everything * **Yield DTFs** let you earn on everything ### 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 returns a portion of protocol fees to RSR holders through token burns. *** ## Core contributors The Reserve project is supported by a set of core contributors, each focused on advancing the shared belief that everyone should be able to own and earn their share of the value of everything. ### Best Friend Finance (BFF) Best Friend Finance is the distribution arm of the Reserve project. It designs, builds, and distributes everyday financial products, including UGLYCASH, all powered by Reserve’s financial center and backed by the Reserve Protocol. Its role is to make asset-backed money understandable and usable through consumer-facing products. ### Confusion Capital (CC) CC supports the broader Reserve ecosystem. It funds public goods, backs ecosystem development, and supports initiatives that expand access, participation, and understanding across the network. ### ABC Labs ABC advances the technology underlying the Reserve Protocol. It builds and maintains the products, tooling, and safeguards that strengthen the protocol and make it reliable for long-term use. Together, these contributors support the protocol, products, and ecosystem required to make ownership of the value of everything practical at scale. *** ## Core initiatives Reserve project initiatives focus on education and alignment around asset-backed currency and long-term monetary infrastructure. * [**Monetarium**](https://reserve.org/monetarium/) convenes builders, economists, and policymakers to examine how asset-backed money could function in practice and at scale. * [**The Digital Securities Initiative**](https://www.digitalsecuritiesinitiative.xyz/) (DSI) works on regulatory and institutional alignment to support the adoption of asset-backed currency over time. * [**UGLYCASH**](https://ugly.cash/) is a Reserve project initiative for earning a share in the value of everything. It provides a consumer-facing way to earn, save, and hold value through asset-backed currency, extending the Reserve ecosystem into everyday financial use. These initiatives address the non-technical requirements of the project, recognizing that enabling people to own and earn their share of the value of everything depends on education, coordination, and institutional readiness as much as technology. # How to participate ### Users Hold, earn, and transact in asset-backed value through DTFs and consumer products built on the Reserve ecosystem, including UGLYCASH. ### Investors Gain diversified exposure to tokenized assets through Index DTFs, and earn yield through Yield DTFs as the ecosystem grows. ### RSR holders Own a share in the value of everything by participating in governance, staking, and value accrual mechanisms tied to DTF adoption. ### Builders Create new DTFs, financial products, and applications on top of Reserve using open, permissionless infrastructure. ### Partners Distribute Reserve-powered products, integrate asset-backed value into existing platforms, or extend access through new channels. ### Contributors Support protocol development, ecosystem growth, education, and alignment through core contributor organizations and initiatives. # 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 returns 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: * [Source code](https://github.com/reserve-protocol/rsr-mainnet) * [Live contract](https://etherscan.io/address/0x320623b8e4ff03373931769a31fc52a4e78b5d70#code) * [Audit](https://github.com/reserve-protocol/rsr-mainnet/blob/master/audits/solidified/Audit%20Report%20-%20Reserve%20Token%20%5B3%20Jan%202022%5D-2.pdf) * [Supply dashboard](https://coinmarketcap.com/currencies/reserve-rights/#token_unlocks) * Markets: [CMC](https://coinmarketcap.com/currencies/reserve-rights/markets/) / [CoinGecko](https://www.coingecko.com/en/coins/reserve-rights#markets) ### 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. ![](/files/5c460c5b11c55b951e3f85bb9a7dc2bea185af61) Staked RSR can earn rewards, based on three factors: 1. The amount of revenue the DTF generates 2. The portion of revenue that governance has directed to RSR stakers 3. 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 ERC-20s (including DTFs). When staking rewards are distributed, it market-buys RSR via auctions with these ERC-20s 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. Unstaking 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](https://app.reserve.org/). For a tutorial, see [this article](https://blog.reserve.org/how-to-stake-reserve-rights-rsr-f5393fe24573). **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](https://blog.reserve.org/vote-locking-on-reserve-19e19201d78e). ### 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 indexes across a diverse ecosystem 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: 1. Proposal: Any address holding the proposal threshold of voting weight may submit a change. 2. Vote: Holders cast votes for, against, or abstain (directly or by delegation) over a fixed voting period. 3. Execution: Successful proposals queue in a timelock, 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](https://docs.openzeppelin.com/contracts/4.x/api/governance)). 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, ERC-20 functions, staking of RSR, and rewards payout are disabled. * Frozen: All interactions besides ERC-20 functions and staking of RSR are disabled. For more details, see [System States + roles](https://github.com/reserve-protocol/protocol/blob/master/docs/pause-freeze-states.md). ### 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](https://etherscan.io/address/0x4903dc97816f99410e8dfff51149fa4c3cdad1b8#tokentxns) 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*](https://etherscan.io/address/0x0774dF07205a5E9261771b19afa62B6e757f7eF8#tokentxns) 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: {% stepper %} {% step %} ### Initial state No withdrawals are made for a while. {% endstep %} {% step %} ### Throttle limit calculation Throttle limit (max available): 1,000,000,000 RSR {% endstep %} {% step %} ### Withdrawal initiated Withdrawal initiated for 1,000,000,000 RSR → Throttle limit becomes 0 RSR {% endstep %} {% step %} ### Time passes 2 weeks pass → Throttle limit: 500,000,000 RSR {% endstep %} {% step %} ### Second withdrawal Withdrawal initiated for 250,000,000 RSR → Throttle limit: 250,000,000 RSR {% endstep %} {% step %} ### More time 1 week passes → Throttle limit: 500,000,000 RSR {% endstep %} {% endstepper %} Future RSR emissions follow a deterministic schedule that emulates Bitcoin's emissions curve. For more details see [Reducing RSR emissions](https://blog.reserve.org/reducing-rsr-emissions-6da7f35917ba) or view the unlock timeline on [CoinMarketCap's Token Unlock page](https://coinmarketcap.com/currencies/reserve-rights/#token_unlocks). ![](/files/de18813339fdf733d88cc02ec1d446707109b8ab) # Index DTFs Index DTFs let you own a share of everything. They do this by holding diversified baskets of tokenized assets within a single onchain product. Below is a detailed overview of how Index DTFs function within the Reserve ecosystem. *** ## TL;DR **Index DTFs are like ETFs, but decentralized: they’re permissionless, composable, and live 24/7 onchain.** Index DTFs package up to 100+ onchain assets into single ERC‑20 tokens, bringing index investing onchain with a new degree of openness, accessibility, and efficiency. ## Key features Index DTFs deliver broad exposure, transparent execution, and flexible governance through a lightweight, fully onchain architecture. * **Diversified exposure**: Package 10+ assets on Ethereum and 100+ on Base * **Broad asset support**: Use virtually any ERC-20; no oracles or plugins needed * **Permissionless access**: Anyone can mint, redeem, or deploy * **Flexible onchain governance**: Use any token for custom decentralized governance * **Automatic liquidity engine**: Tap deep onchain liquidity for smooth rebalancing and low tracking error # Overview The Reserve Index Protocol provides a lightweight framework for wrapping handfuls to hundreds of ERC-20 tokens into single fungible assets. The protocol enables permissionless access, efficient rebalancing, and customizable onchain governance for Index Decentralized Token Funds (DTFs): * **Permissionless NAV-based issuance.** Anyone can mint or redeem directly at real-time asset value—no authorized participants or intermediaries required. * **Light footprint & broad asset universe.** No price oracles or collateral plugins, so virtually any ERC-20 (including LSTs, LP tokens, and bridged assets) can be indexed. * **Dutch-auction rebalancing & onchain price discovery.** Dutch auctions minimize MEV and slippage by sourcing deep onchain liquidity from DEXs and solver networks (e.g., CoW Swap) for rebalancing. * **Continuous fees & protocol revenue.** Block-by-block TVL (management) and Mint fees accrue transparently in DTF shares, routed according to governance specification. * **Custom onchain governance.** Flexibly-structured onchain governance can be governed by any token. This document surveys the core mechanics that keep an Index DTF reliable and decentralized, from efficient rebalancing to fee flows and onchain governance. ## Rebalancing & tracking Index DTFs are periodically rebalanced to target weights through onchain Dutch auctions. Rebalance timing is set by governance. Auctions are executed onchain through an autonomous process: {% stepper %} {% step %} ### Measure the live basket Current token proportions are calculated onchain. {% endstep %} {% step %} ### Open auctions Any surplus token is offered along a declining-price curve in exchange for a deficit token. {% endstep %} {% step %} ### Clear via open markets Solvers such as CoW Swap and direct DEX takers compete to fill orders, minimizing slippage and MEV. {% endstep %} {% step %} ### Settle and update weights Whenever an auction fills a bid the basket’s composition is updated atomically. {% endstep %} {% endstepper %} Because every step is deterministic and transparent, arbitrageurs quickly remove price discrepancies, keeping the market price close to NAV and limiting tracking error. Auction cadence & duration are adjustable by governance, enabling different index strategies without touching core code. ## Fees & revenue Unlike Yield DTFs, Index DTFs do not rely on yield-bearing collateral for revenue. Instead, two fee streams compensate governance, RSR holders, and governance-chosen addresses. | Fee type | Basis | Range | Accrual method | | -------------------- | ----------------- | -------- | ---------------------------------- | | **TVL (management)** | Basket NAV | < 5% APY | Mint new DTF shares block-by-block | | **Mint** | Incoming issuance | < 1% | Fee deducted from each mint | All newly minted shares flow first to the platform take-rate, with the remainder split between addresses set by governance. Currently, the platform fee is used to automatically buy and burn RSR. ## Governance Each Index DTF acts like its own miniature protocol with governance rules chosen at deployment. The deployer selects any ERC-20 token—RSR by default—for vote-locking, and holders of that locked token steer the DTF’s evolution via onchain proposals. The Reserve Optimistic Governor provides a dual-path model: a **standard path** for high-impact decisions that require full community voting, and an **optimistic path** for routine operations that execute quickly unless vetoed by token holders. ### What governance decides | Area | Typical settings | | --------------------------- | ----------------------------------------------------------------------------------------------- | | **Assets & target weights** | Add, remove, or re-weight assets to reflect the desired index methodology | | **Fee schedule** | TVL (management) and Mint fees, plus the split between the platform and DTF-specific recipients | | **Rebalancing parameters** | Auction cadence & duration | | **Revenue routing** | Addresses and allocations for fee revenue | ### How it works in practice * **Standard proposals** are created, voted on, and executed entirely onchain, with timelocks to ensure time to react. This path is used for high-impact changes such as fees, basket composition, and role assignments. * **Optimistic proposals** skip affirmative voting and execute automatically after a short veto window, unless enough token holders vote Against. This path is used for routine operations like launching rebalance auctions. * Every proposal, vote, and execution is permanently recorded onchain, giving users, auditors, and regulators a transparent change history. Read more about how **Reserve Optimistic Governance** works [here](/core-components/index-dtfs/optimistic-governance). Because governance is modular and token-agnostic, one Index DTF might run a simple one-token DAO, while another could delegate voting power across multiple stakeholders or adopt more sophisticated vote-lock mechanics over time. {% hint style="warning" %} 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 describe the intended behavior. {% endhint %} {% hint style="info" %} The Reserve Register does not yet support permissionless creation of Index DTFs. {% endhint %} ## Non-compatible ERC20 assets The following types of ERC20s are not supported to be used directly in an Index DTF. These tokens should be wrapped into a compatible ERC20 token to be used within the protocol. * Tokens that take a "fee" on transfer * Tokens that do not expose the decimals() function in their interface. Decimals should always be between 1 and 27. * ERC777 tokens which could allow reentrancy attacks * Tokens with multiple entry points (multiple addresses) * Tokens that do not adhere to the ERC20 standard in general # Pricing ### NAV The price of a DTF is based on a NAV (Net Asset Value) calculation. Given a DTF with a basket of `n` tokens, each with a spot price `p`, we can calculate the DTF's price as:
### Onchain pricing The `toAssets()` function is used to convert a DTF share to its underlying assets. It will return the one-to-many exchange rate of the DTF. ``` function toAssets(uint256 shares, Math.Rounding rounding) returns (address[] memory _assets, uint256[] memory _amounts); ``` Solidity Code: [Folio.toAssets()](https://github.com/reserve-protocol/reserve-index-dtf/blob/main/contracts/Folio.sol#L311) #### Inputs * `shares` Number of DTF shares to quote * `rounding` Rounding method for output values (enum). One of: * \[0] Floor (Toward negative infinity) * \[1] Ceil (Toward positive infinity) * \[2] Trunc (Toward zero) * \[3] Expand (Away from zero) #### Outputs * `_assets` Array of addresses for each asset in the quote * `_amounts` Array of amounts of each asset in the quote # Minting & redeeming Minting/redeeming directly converts between Index DTFs and their underlying tokens—no authorized participants required. Anyone can mint or redeem permissionlessly. ![](/files/0e8ec43ddc36c4d17c1826a37ffd4af9198ebb04) For convenience, Register offers zapper helpers that let users enter or exit using other ERC‑20 and chain-native tokens in one transaction. Manual redemptions and direct contract calls enable more flexibility and provide an escape hatch if other methods are down, ensuring users are not reliant on offchain tools to exit positions. ## Protocol level vs. app level Market makers and integrators often ask what a mint or redeem actually does under the hood. The mechanics differ depending on whether you interact with the contracts directly or go through the app’s zapper—but in every case, the operation is atomic. ### At the protocol level Onchain, minting and redeeming are atomic operations in a single transaction: the user exchanges exact amounts of each basket token for an exact number of DTF tokens (or vice versa for a redeem). The exchange ratios are defined by—and readable from—the Folio.sol contracts, so the precise basket amounts for any mint or redeem can be computed in advance. ### In the app (via the zapper) When using the zapper, the user only specifies the input/output token and how much they want to spend. The zapper abstracts the rest: it trades the input token into the required basket tokens and executes the `mint` action—or executes the `redeem` action and then trades the basket tokens into the desired output token. The zapper transaction is **also** atomic, just with the added trading step packaged in series with the `mint`/`redeem` step. ### DTFs with offchain liquidity (RFQ / intents) {% hint style="info" %} Some DTFs utilize tokens whose main source of liquidity is offchain (e.g., Ondo or Universal assets). For these, the in‑app zapper might not function as well, because there is not sufficient liquidity onchain to route the trading step. Instead, we rely on RFQ / intent systems: approved minters source the underlying basket tokens as needed—effectively acting as the trading layer of the zapper—and execute the mint/redeem functionality to provide the end user with a seamless result. {% endhint %} ## How to mint or redeem There are three main ways to mint or redeem. The [Reserve app](https://app.reserve.org/) provides a convenient interface, but any front‑end can access the same permissionless contracts. {% stepper %} {% step %} ### Zapper (one‑step) *When to use:* You want to use a single ERC‑20 or ETH and let the app handle the swaps * Click the **Buy** or **Sell** button on any Index DTF page * In the **You use** or **You receive** field, pick any supported token (ETH, USDC, wBTC, etc.) * Enter an amount and review the quote Due to the volatile nature of DEXs (decentralized exchanges) and the way the zapper routes tokens, it is common to receive dust amounts of certain tokens. Generally, the amount of dust is on the order of 1–10 bps of the input value. {% endstep %} {% step %} ### Manual mint / redeem *When to use:* You hold/want the exact collateral tokens or need precise slippage control * Click **Switch to manual mode** on the DTF’s Mint/Redeem page * Review per‑token amounts to deposit/receive * Approve any necessary tokens and submit {% endstep %} {% step %} ### Direct contract call *When to use:* Integrations, scripts, advanced use cases Call `mint` or `redeem` on the DTF proxy. Basket ratios are calculated and enforced onchain. See the [smart contracts](/core-components/index-dtfs/smart-contracts) section for contract details and addresses. {% endstep %} {% endstepper %} # Roles The [readme](https://github.com/reserve-protocol/reserve-index-dtf/blob/main/README.md) document in the Reserve Index Protocol GitHub [repository](https://github.com/reserve-protocol/reserve-index-dtf) provides an overview of the protocol's smart contract architecture and implementation details. The material below provides a technical tour of the protocol's contracts, bridging the high-level system design with onchain implementations. The [Protocol Operations](/core-components/index-dtfs/overview) chapter explains how these contracts work together to provide the core functionality of the protocol. ## System architecture The table below groups the protocol's contracts into functional layers and highlights the role each set of contracts plays within the system. | Layer | Core contracts | Purpose | | -------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **DAO infrastructure** | `FolioDAOFeeRegistry`, `FolioVersionRegistry` | Collect protocol-wide fees and whitelist Folio implementations / deployers | | **Index (“Folio”) layer** | `Folio` (ERC-20), `FolioProxy` | Represents the basket and embeds the rebalance-auction engine; proxy pattern allows controlled upgrades | | **Governance layer** |

FolioGovernor

ReserveOptimisticGovernor

| Dual-path governance (standard & optimistic) that executes proposals and manages rebalances. The selector registry whitelists which actions can use the optimistic fast path | | **Staking / voting layer** | `StakingVault` | Escrows vote-locked governance tokens and streams rewards while providing voting weight for both standard and optimistic proposals | ## Governance roles Index DTFs employ a modular governance structure composed of scope-constrained onchain roles. Governance can be flexibly customized by assigning different actors or contracts (e.g., DAOs, multi-sigs, EOAs) to each role. Each role is deliberately sandboxed to the smallest set of function calls and parameter ranges needed for its mandate, and every high-impact action must pass through a timelock or hard-coded ceiling. These guardrails guarantee that no single key can abuse the system—another role (or broader governance) always has time and authority to intervene. {% stepper %} {% step %} ### Admin The Admin is the primary admin of the DTF. There should really only ever be 1 Admin. #### Expected actor A DAO that operates via the supplied `FolioGovernor.sol` / `TimelockController.sol` or `ReserveOptimisticGovernor.sol` / `TimelockControllerOptimistic.sol` contracts. DAO power should be sourced from the `StakingVault.sol` contract. The main reason for this is that the `StakingVault` has the ability to collect multiple different reward tokens and distribute them to stakers pro-rata over time in an MEV-resistant manner. Any ERC20 can be configured as the deposit token for the `StakingVault` at deployment. #### Abilities * Add / remove assets to / from the basket * Set fees & fee recipients * Set auction length * Set the auction delay (delay between when an auction is approved and when it can be permissionlessly launched) * Assign all roles * Manage the Optimistic Selector Registry (add or remove allowed optimistic actions) #### Limitations All actions are gated by a timelock (default 48 h). Cannot bypass hard-coded parameter ceilings (e.g., max 10% annual TVL fee) and cannot seize collateral directly. Changes to governance infrastructure (the Governor, Timelock, Selector Registry, and Staking Vault) must always go through the standard governance path. {% endstep %} {% step %} ### Rebalance Manager The Rebalance Manager is responsible for configuring auctions for execution. #### Expected actor The same DAO that acts as the Admin should also take on the role of Rebalance Manager, and the default deployment configuration in Register is exactly this. However, having the Rebalance Manager as a separate role gives the Admin the optionality to permission a smaller set of trusted actors to approve auctions. This would allow the DTF to move faster on basket changes, but comes with the added risk of the DTF being considered a security (due to the nature of the asset selection being managed by a small group of permissioned actors) and mint access being geo-blocked on Register. #### Abilities * Configure an auction for execution. Each auction definition has the following parameters at approval: * `Sell Token`: the token to be sold by the DTF * `Buy Token`: the token to be bought by the DTF * `Expected Volatility`: the amount of price movement that is expected in the `Sell Token`:`Buy Token` pairing. The Rebalance Manager can select between 3 options: Low, Medium, and High. * `Time To Live (TTL)`: How long (in seconds) an auction can exist in an APPROVED state until it can no longer be opened. This value must be longer than the DTF-configured `Auction Delay` if the auction is intended to be permissionlessly available. #### Limitations May only define auctions within pre-set volatility and TTL ranges. Cannot alter fees, basket weights, or governance itself. {% endstep %} {% step %} ### Auction Launcher The Auction Launcher is responsible for launching an approved auction and providing more accurate pricing information for it. A DTF is NOT required to have any Auction Launchers, as auctions can be launched permissionlessly (as long as the DTF and auctions are configured correctly). #### Expected actor Because this role takes on a more ministerial job, it can be held by a trusted multisig or EOA. While any Auction Launcher should be trusted, they can only modify the pricing information within the bounds set by the Rebalance Manager, thus limiting the amount of damage from mistakes or a rogue actor. #### Abilities * Launch auctions * Kill auctions * When opening an auction, optionally alter parameters of the auction within the approved ranges #### Limitations Can tweak start/end prices but only inside the bands approved by the Approver. Cannot extend an auction’s TTL or change the sell/buy tokens. {% endstep %} {% step %} ### Optimistic Proposer The Optimistic Proposer is responsible for creating fast-path optimistic proposals for routine, pre-approved operations. #### Expected actor A trusted multisig or EOA that handles day-to-day operational proposals such as launching rebalance auctions or updating a DTF's display name. #### Abilities * Create optimistic proposals that skip affirmative voting and execute automatically after the veto period unless vetoed * Only actions whitelisted in the Optimistic Selector Registry can be proposed optimistically #### Limitations Subject to a *proposal throttle* limiting the number of optimistic proposals per account within a 24-hour window. Can only propose whitelisted (proposer, target, selector) combinations. Cannot propose changes to governance infrastructure (Governor, Timelock, Selector Registry, or Staking Vault). The role can be revoked at any time by a Guardian without a governance vote. {% endstep %} {% step %} ### Brand Manager The Brand Manager is responsible for updating the Register UI with the correct social media links and token media (logo, banner). #### Expected actor A trusted multisig or EOA that is responsible for the branding and marketing of the DTF. #### Abilities * Update the DTF website, Twitter, Farcaster, and Telegram links that get displayed on Register * Update the DTF logo and banner that get displayed on Register #### Limitations Limited to UI metadata (links, logos). Has zero permissions over assets, fees, or auctions. {% endstep %} {% step %} ### Guardian The Guardian is responsible for vetoing malicious governance proposals and providing emergency safeguards against compromised optimistic proposers. #### Expected actor A trusted multisig or EOA that is ready and willing to act quickly to prevent malicious governance proposals from being executed or to revoke compromised optimistic proposers. #### Abilities * Veto governance proposals (both standard and optimistic) * Revoke the Optimistic Proposer role from any address at any time without a governance vote #### Limitations Single-purpose veto (cancel) on queued governance proposals; cannot propose or execute anything itself. Power sunsets automatically if a quorum of stakers votes to revoke the role. {% endstep %} {% endstepper %} # Fees ### Fees & revenue Index DTFs generate revenue through two primary fee mechanisms: 1. **TVL Fee**: A fee based on the Total Value Locked in the protocol 2. **Mint Fee**: A fee applied when users mint new DTF tokens Both fees are collected and distributed in the form of the DTF token itself to one or multiple recipients, as determined by governance. A platform fee is applied to both the TVL and Mint fees before they are distributed to recipients. # TVL fee ### TVL fee explained The TVL fee is expressed as a percentage of the DTF's Total Value Locked and is applied continuously through a compound interest calculation. #### Technical implementation The TVL fee is implemented using a compound interest formula: ``` fee = (1 / (1 - feePerSecond))^secondsPassed - 1 ``` Where: * `feePerSecond` is set by the DTF Owner (governance) * `secondsPassed` represents the time since the last fee calculation This mechanism ensures that: * The fee is calculated and accounted for on every user interaction * Any view functions account for the TVL fee since the last contract update * The fee accumulates continuously rather than at discrete intervals #### Practical implications For users and integrators, this means: * The TVL fee effectively acts as a continuous management fee * The longer assets remain in the DTF, the more fees accrue * The displayed value of Index DTF tokens will gradually decrease relative to the underlying assets, reflecting the accrued fees # Mint fee ### Mint fee explained The mint fee is a straightforward percentage fee applied whenever a user mints new DTF tokens. #### Technical implementation The calculation is a simple percentage of the mint amount: ``` fee_amount = mint_amount * mint_fee_percentage user_receives = mint_amount - fee_amount ``` #### Example * User mints 100 $COIN50 * Mint fee = 1% * User receives 99 $COIN50 * 1 $COIN50 is set aside for fee recipients # Platform fee ### Platform fee A platform fee is applied to both the TVL and Mint fees before they are distributed to recipients. This platform fee is defaulted to 33%, but can be set per-DTF. #### Technical implementation The platform fee is supplied to DTFs via a Platform Fee Registry contract, which is controlled by the platform owner multisig. This registry also provides DTFs with the current platform fee recipient address. ### Fee parameters and constraints The following parameters apply to all Index DTFs: | Parameter | Value | | ----------------------------- | ----- | | Net platform TVL fee minimum | 0.15% | | Net platform mint fee minimum | 0.15% | | Max admin-defined TVL fee | 10% | | Max admin-defined mint fee | 5% | # Fee distribution ### Fee distribution After platform fees are deducted, the remaining fees are distributed among the fee recipients according to their Admin-defined weights. ### Practical implications for users #### For governance stakers * Fee distribution to governance token holders follows an exponential distribution model over time to mitigate MEV (Miner Extractable Value) attacks * Governance token holders can claim their pro-rata share of fees based on their staked tokens #### For traders and holders * When holding DTF tokens, be aware that the TVL fee continuously accrues, effectively acting as a management fee * When minting new DTF tokens, account for the one-time mint fee in your calculations #### For integrators * Implement accurate fee calculations in your interfaces to provide users with precise token valuations * Account for the continuous nature of the TVL fee when displaying token values * Ensure your integration accounts for both fees when estimating transaction outcomes ### Governance implications Fee parameters can be adjusted through governance, allowing the protocol to adapt to changing market conditions. This includes: * TVL fee rate adjustments * Mint fee rate adjustments * Fee recipient configurations # Rebalancing ### Rebalancing DTF baskets Any alteration of a DTF’s basket is done via a Dutch auction. Each auction is configured with parameters to define which tokens are to be traded, the pricing curve of the auction, and the target end ratios of the tokens in the basket. ### Auction pricing When configuring an auction for approval by governance, the **Expected Volatility (EV)** presets can be used to set the pricing curve and target token ratios. Choosing **Low EV** will configure a smaller pricing curve with more compact target ratio ranges, while choosing **High EV** will configure a much wider pricing curve with wider target ratio ranges. When launching an auction via the Reserve app as the **Auction Launcher**, the **EV** presets can again be used to set the final pricing curve and target ratios. When launching an auction via the Reserve app as any other actor, the **EV** presets are not available, as permissionless auction launches are not able to modify the pricing curve. ### Auction timing The **time-to-live (TTL)** parameter gets set when a rebalance auction is approved. This parameter defines how long a rebalance auction can exist in the Approved state before it is considered invalid and can no longer be launched. The **TTL** matters significantly, especially with respect to the Admin-defined **Auction Delay** parameter. The **Auction Delay** defines how much time an auction can exist in the Approved state before it can be launched by anyone. Before the delay ends, the only actor that can launch the auction is the **Auction Launcher.** Setting the **TTL** longer than the **Auction Delay** creates a period when the auction can be launched permissionlessly, adding to the DTF’s decentralization. If **TTL** is set at or below **Auction Delay**, then the **Auction Launcher** will be the only actor that is ever able to launch the auction. This gives more control to the **Auction Launcher** and entrusts them with more responsibility, so any **Auction Approver** should be sure about the TTL that they set. ### Basket-wide rebalancing auctions ![Rebalancing Example](/files/SKTN5riOXQBCye7R3mKB) Index DTFs are rebalanced by approving a target basket, and then opening auctions that allow market participants to bid on *any* surplus:deficit token pair until the tokens in the basket reach their respective target ratios. ![4.0.0 Auctions](/files/iI0ijkzITg4xPDeEf9Fy) ### CoW Swap participation Since release 4.0.0, Index DTFs are able to utilize the new **Trusted Fillers** integration. The first Trusted Filler that has been integrated for Reserve Index DTFs is **CoW Swap**. Adopting **CoW Swap** as a Trusted Filler means that whenever the DTF has a rebalance auction, potential bids can be sent to the **CoW Swap** solver network, allowing solvers to bid directly in the auctions. This has 2 major benefits: 1. It ensures the DTF will always have competitive bidders participating in its rebalance auctions. 2. It connects rebalance auctions with the deep liquidity and best-price guarantees of the **CoW Swap** DEX. # Technical details ## Rebalance lifecycle In order to rebalance a DTF, the `REBALANCE_MANAGER` must first start a rebalance. This will set the new basket, per-token limit ranges, and price ranges. The `REBALANCE_MANAGER` will also set the restricted window during which only the `AUCTION_LAUNCHER` can open auctions, and the total time-to-live for the rebalance. Once a rebalance auction is opened by the `AUCTION_LAUNCHER`, every surplus token in the auction will be sold down to its target basket ratio, and every deficit token will be bought up to its target basket ratio. An auction can include every surplus and deficit token in the basket, or a subset of them. Bidders can bid on any surplus:deficit pair in the auction until they reach their respective target ratios. 1. **Rebalance Initiation**: The `REBALANCE_MANAGER` starts a new rebalance, specifying new basket tokens, target ratios (limits), and price ranges for each asset. 2. **Auction Launcher Window**: For a restricted period, only the `AUCTION_LAUNCHER` can open auctions, with the ability to fine-tune parameters within governance-set bounds. The `AUCTION_LAUNCHER` can: * select a sell limit within the approved sell limit range * select a buy limit within the approved buy limit range * raise starting price by up to 100x * raise ending price arbitrarily (can cause auction not to clear, same end result as closing auction) 3. **Permissionless Auctions**: After the restricted window, anyone can open auctions using the pre-approved parameters. 4. **Bidding**: Anyone can bid in open auctions, exchanging tokens at a price determined by an exponential decay curve. Every successful bid will move the DTF closer to the target basket ratio. 5. **Auction Close**: Auctions end when their time elapses or their limits are reached. The rebalance technically ends when the rebalance period expires. ### Key concepts and structs * **BasketRange**: `{ spot, low, high }` — Target, minimum, and maximum ratios of a token to DTF (Folio) shares (D27 precision). * **Prices**: `{ low, high }` — Price range for each asset (D27 precision). * **RebalanceDetails**: `{ inRebalance, limits, prices }` — Per-token rebalance state. * **Auction**: `{ rebalanceNonce, sellToken, buyToken, sellLimit, buyLimit, startPrice, endPrice, startTime, endTime }` — State of a single auction. ### Auction pricing For each token supplied to the rebalance, the `REBALANCE_MANAGER` provides a `low` and `high` price estimate. These should be set such that in the vast majority (99.9%+) of scenarios, the asset's price on secondary markets lies within the provided range. The maximum allowable price range for a token is 1e2: `high / low` must be <= 1e2. If the price of an asset rises above its `high` price, this can result in a loss of value for Folio holders due to the auction price curve on a token pair starting at too low a price. When an auction is started, the `low` and `high` prices for both assets are used to calculate a `startPrice` and `endPrice` for the auction. There are 2 ways to price assets, depending on the risk tolerance of the `REBALANCE_MANAGER`: 1. **Priced** * The `REBALANCE_MANAGER` provides a list of NONZERO prices for each token. No token price can be 0. * The `AUCTION_LAUNCHER` can always choose to raise the starting price up to 100x from the natural starting price, or raise the ending price arbitrarily (up to the starting price). They cannot lower either price. 2. **Unpriced** * The `REBALANCE_MANAGER` provides ALL 0 prices for each token. This allows the `AUCTION_LAUNCHER` to set prices freely and prevents auctions from being opened permissionlessly. Overall the price range for any Dutch auction (`startPrice / endPrice`) must be less than `1e6` to prevent precision issues. #### Price curve Note: The first block may not have a price of exactly `startPrice` if it does not occur on the `start` timestamp. Similarly, the price may not be exactly `endPrice` in the final block if it does not occur on the `end` timestamp. All auctions use an exponential decay price curve from `startPrice` to `endPrice` over the auction duration. The price at any time `t` is: ``` P(t) = startPrice * exp(-k * t) ``` Where `k` is calculated so that `P(auction.endTime) = endPrice`. #### Lot sizing Auctions are sized by the difference between current balances and the basket ratios provided by the `limits`. The auction `sellAmount` represents the single largest quantity of sell token that can be transacted without violating the `limits` of either token in the pair. In general, it is possible for the `sellAmount` to either increase or decrease over time, depending on whether the surplus of the sell token or deficit of the buy token is the limiting factor. 1. If the surplus of the sell token is the limiting factor, the `sellAmount` will increase over time. 2. If the deficit of the buy token is the limiting factor, the `sellAmount` will decrease over time. #### Auction participation Anyone can bid in any auction up to and including the `sellAmount` size, as long as the `price` exchange rate is met. ``` /// @return sellAmount {sellTok} The amount of sell token on sale in the auction at a given timestamp /// @return bidAmount {buyTok} The amount of buy tokens required to bid for the full sell amount /// @return price D27{buyTok/sellTok} The price at the given timestamp as a 27-decimal fixed point function getBid( uint256 auctionId, uint256 timestamp, uint256 maxSellAmount ) external view returns (uint256 sellAmount, uint256 bidAmount, uint256 price); ``` # Security & permissions ## Permissions * **Only** the `ADMIN` can set the auction length. * **Only** the `ADMIN` can allow/disallow permissionless bidding. * **Only** the `ADMIN` can configure the Trusted Fillers registry. * **Only** the `ADMIN` can add a token to the basket directly (not via rebalance). * **Only** the `REBALANCE_MANAGER` can start a rebalance. * **Only** the `AUCTION_LAUNCHER` can open auctions during the restricted window. * After the window, anyone can open auctions (if in priced mode). * **Anyone** can bid in open auctions. * **Any** of the `REBALANCE_MANAGER`, `AUCTION_LAUNCHER`, or `ADMIN` roles can close an auction. * **Any** of the `REBALANCE_MANAGER`, `AUCTION_LAUNCHER`, or `ADMIN` roles can end a rebalance. # Security Reserve aims to establish a robust and stable DTF platform. However, this necessitates the implementation of an additional layer of smart contracts, introducing an extra level of smart contract risk. The Reserve team is aware of these tradeoffs and has prioritized security by undergoing multiple audits conducted by the world's leading security firms. ## Smart contract security audits | Auditor | Date | Scope | Report | | -------------- | -------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Trust Security | Dec 2024 | Protocol | [Report](https://github.com/reserve-protocol/reserve-index-dtf/blob/main/audits/trust-security/v1-audit-dec-2024.pdf) | | Cantina | Jan 2025 | Protocol | [Report](https://github.com/reserve-protocol/reserve-index-dtf/blob/main/audits/cantina/report-competition-reserve-jan2025.pdf) | | Trail of Bits | Apr 2025 | Protocol | [Report](https://github.com/reserve-protocol/reserve-index-dtf/blob/main/audits/trail-of-bits/2025-04-reserve-folio-solidity-securityreview.pdf) | | Pashov | Jun 2025 | Protocol | [Report](https://github.com/reserve-protocol/reserve-index-dtf/blob/main/audits/pashov/reserve-security-review_2025-06-02.pdf) | In addition to performing an initial full audit on the Index DTF protocol, Trust Security is the main security partner for ABC Labs, and reviews every piece of Solidity code before it is deployed onchain to be used in production. Their depth of knowledge of the Index and Yield protocols is matched only by that of the core developers. ## Bug bounty In addition to undergoing numerous audits, the Reserve team would like to motivate the community to undertake their own audits and will reward individuals who responsibly disclose any vulnerabilities they find. **Bug bounty of $10,000,000** Reserve has partnered with Cantina for its bug bounty program. See additional details of the program, or report any findings here: ## Risks For a detailed overview of potential risks and risk-mitigation strategies, see the [Risks page](/risks). # Deployment guide {% hint style="warning" %} 🚧 Coming soon {% endhint %} # Smart contracts ## Contract addresses ### Ethereum deployments (Chain ID: 1) | **Contract** | **Address** | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | RsrToken | [0x320623b8E4fF03373931769A31Fc52A4E78B5d70](https://etherscan.io/address/0x320623b8E4fF03373931769A31Fc52A4E78B5d70) | | FolioFeeRegistry | [0x0262E3e15cCFD2221b35D05909222f1f5FCdcd80](https://etherscan.io/address/0x0262E3e15cCFD2221b35D05909222f1f5FCdcd80) | | FolioVersionRegistry | [0xA665b273997F70b647B66fa7Ed021287544849dB](https://etherscan.io/address/0xA665b273997F70b647B66fa7Ed021287544849dB) | | TrustedFillerRegistry | [0x279ccf56441fc74f1aac39e7fac165dec5a88b3a](https://etherscan.io/address/0x279ccf56441fc74f1aac39e7fac165dec5a88b3a#code) | | GovernanceDeployer | [0xE926577a152fFD5f5036f88BF7E8E8D3652B558C](https://etherscan.io/address/0xE926577a152fFD5f5036f88BF7E8E8D3652B558C) | | FolioDeployer \[4.0.0] | [0xBE3B47587cEeff7D48008A0114f51cD571beC63A](https://etherscan.io/address/0xbe3b47587ceeff7d48008a0114f51cd571bec63a) | | FolioDeployer \[5.0.0] | [0x4d201a6e5bf975e2cee9e5cbdfc803c0ff122073](https://etherscan.io/address/0x4d201a6e5bf975e2cee9e5cbdfc803c0ff122073) | | Folio (Implementation) \[4.0.0] | [0xBA9642b0690E083fc11def8Eac49FC05aAA5d725](https://etherscan.io/address/0xBA9642b0690E083fc11def8Eac49FC05aAA5d725) | | Folio (Implementation) \[5.0.0] | [0xb6b35b2c7032E00BAa2535Ba480d461321B7E0A6](https://etherscan.io/address/0xb6b35b2c7032E00BAa2535Ba480d461321B7E0A6) | ### Base deployments (Chain ID: 8453) | **Contract** | **Address** | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | RsrToken | [0xaB36452DbAC151bE02b16Ca17d8919826072f64a](https://basescan.org/address/0xaB36452DbAC151bE02b16Ca17d8919826072f64a) | | FolioFeeRegistry | [0x0262E3e15cCFD2221b35D05909222f1f5FCdcd80](https://basescan.org/address/0x0262E3e15cCFD2221b35D05909222f1f5FCdcd80) | | FolioVersionRegistry | [0xA665b273997F70b647B66fa7Ed021287544849dB](https://basescan.org/address/0xA665b273997F70b647B66fa7Ed021287544849dB) | | TrustedFillerRegistry | [0x72db5f49d0599c314e2f2fedf6fe33e1ba6c7a18](https://basescan.org/address/0x72db5f49d0599c314e2f2fedf6fe33e1ba6c7a18#code) | | GovernanceDeployer | [0x6a66E6E209C7120819cC033d9397E5022C22C872](https://basescan.org/address/0x6a66E6E209C7120819cC033d9397E5022C22C872) | | FolioDeployer \[4.0.0] | [0xA203AA351723cf943f91684e9F5eFcA7175Ae7EA](https://basescan.org/address/0xa203aa351723cf943f91684e9f5efca7175ae7ea) | | FolioDeployer \[5.0.0] | [0x3451fD177E9a8bB4Eb8271E627A804BD22A816F9](https://basescan.org/address/0x3451fd177e9a8bb4eb8271e627a804bd22a816f9) | | Folio (Implementation) \[4.0.0] | [0x03D27E00e98d107a9d2523144C2AdEC7cf214DFb](https://basescan.org/address/0x03D27E00e98d107a9d2523144C2AdEC7cf214DFb) | | Folio (Implementation) \[5.0.0] | [0x6368E66a38BAB5a03c4f1be64b9d890305959A10](https://basescan.org/address/0x6368E66a38BAB5a03c4f1be64b9d890305959A10) | ### BSC deployments (Chain ID: 56) | **Contract** | **Address** | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | RsrToken | [0x23f72a3Db61D6CB8aBE5d9AF1Ac4B6c99327bFee](https://bscscan.com/address/0x23f72a3db61d6cb8abe5d9af1ac4b6c99327bfee) | | FolioFeeRegistry | [0x135437333990f799293F6AD19fE45032Ba68285e](https://bscscan.com/address/0x135437333990f799293F6AD19fE45032Ba68285e) | | FolioVersionRegistry | [0x79A4E963378AE34fC6c796a24c764322fC6c9390](https://bscscan.com/address/0x79A4E963378AE34fC6c796a24c764322fC6c9390) | | TrustedFillerRegistry | [0x08424d7c52bf9edd4070701591ea3fe6dca6449b](https://bscscan.com/address/0x08424d7c52bf9edd4070701591ea3fe6dca6449b#code) | | GovernanceDeployer | [0x270d928b9Ee38BAD93601D197256390b3c3C13Ec](https://bscscan.com/address/0x270d928b9Ee38BAD93601D197256390b3c3C13Ec) | | FolioDeployer \[4.0.1] | [0x5Bed18AcA50E6057E6658Fe8498004092EedCDcF](https://bscscan.com/address/0x5Bed18AcA50E6057E6658Fe8498004092EedCDcF) | | Folio (Implementation) \[4.0.1] | [0xd58B270159BD0d51cef1Cb2A950c7f71804D45E7](https://bscscan.com/address/0xd58B270159BD0d51cef1Cb2A950c7f71804D45E7) | | FolioDeployer \[5.0.0] | [0x72f87239981159ed23673012EE3806Ca6114AB2A](https://bscscan.com/address/0x72f87239981159ed23673012EE3806Ca6114AB2A) | | Folio (Implementation) \[5.0.0] | [0x6f2C6343F997dC9C8C4d96a51cDDe9b8283e9A07](https://bscscan.com/address/0x6f2C6343F997dC9C8C4d96a51cDDe9b8283e9A07) | # Optimistic Governance Reserve's optimistic governance lets pre-approved, routine actions on a DTF execute quickly — without holding a full multi-day vote — while giving token holders a direct way to block anything they disagree with. If enough holders object during a short veto window, the action does not just get cancelled. It automatically escalates into a regular community vote. ### Two paths through one system A DTF using optimistic governance has two ways for proposals to move forward: | Path | What it's for | What holders do | | --------------------- | ---------------------------------------------------------------- | -------------------------------------------------------- | | **Fast (optimistic)** | Routine, pre-approved actions | Watch for proposals; vote against any they disagree with | | **Slow (standard)** | Anything else — including changes to how governance itself works | Vote For, Against, or Abstain through a normal proposal | Both paths share the same token, the same delays, and the same execution pipeline. The only difference is whether the action was pre-approved as routine enough to run on the fast path. {% hint style="info" %} Anything that changes the governance system itself — the rules of what's allowed on the fast path, the contracts that run governance, or the token — can only happen through the slow path. Fast governance can never modify itself. {% endhint %} ### Why have a fast path at all? Most governance actions on a live DTF are small and predictable: adjusting a single parameter, rotating an oracle, scheduling a rebalance window. Running each of these through a full multi-day vote with quorum adds friction without adding meaningful security — the action is already pre-scoped and the operators are already known. The fast path removes that friction for routine work, and the veto window keeps holders in control. If something unexpected ever appears on the fast path, holders can stop it. ### How the fast path works {% stepper %} {% step %} #### A proposer submits a fast proposal Only addresses with permission to use the fast path can submit. Each submission is checked against an allowlist of pre-approved actions — if the proposal tries to do anything not on that list, it's rejected immediately. {% endstep %} {% step %} #### A short delay, then the veto window opens After a brief delay, the proposal enters its veto window. This is the time during which token holders can object. {% endstep %} {% step %} #### Holders can vote against During the veto window, any holder can vote against the proposal. There are no For votes on the fast path — holders only weigh in if they want to stop the action. Silence is consent. {% endstep %} {% step %} #### One of two things happens: **If the veto window closes an too few Against votes came in**, the proposal passes and can be executed right away. **If Against votes cross the veto threshold at any point during the veto window**, the proposal is blocked and a full community vote is automatically opened in its place. {% endstep %} {% step %} #### Escalation: the confirmation vote The escalated vote runs as a normal slow proposal: For, Against, or Abstain. Votes from the veto window do not carry over — voting starts fresh. If the community vote passes, the action still happens, just with full approval and the normal timelock delay. If it fails, the action is permanently blocked. {% endstep %} {% endstepper %} ### What holders need to do #### Stake to gain voting power Voting power on both paths comes from staking the DTF's governance token. Staked tokens are subject to an unstaking delay when you withdraw — this prevents flash-loaning votes in or out around a proposal. #### Delegate (twice, if you want) Staked tokens carry two separate delegations: * **Standard delegation** chooses who votes your weight on slow proposals. * **Veto delegation** chooses who can use your weight to veto fast proposals. You can point these at the same address or at two different ones. A common pattern: delegate standard governance to a long-term steward, and delegate veto authority to someone focused on monitoring fast proposals as they happen. If you stake and never delegate, your tokens don't vote on either path. Most users delegate to themselves when they stake. #### Watch the veto window When a fast proposal is active, the only thing you (or your veto delegate) needs to decide is whether to vote against it. There is no quorum to hit and no For vote to cast — your only job is to flag anything that looks wrong. If something does look wrong, voting against it costs nothing and contributes to the veto threshold. If enough holders feel the same way, the proposal escalates to a full vote. #### Participate in slow proposals normally Slow proposals — including any confirmation vote that comes out of a vetoed fast proposal — work like standard governance. You vote For, Against, or Abstain, and the proposal needs both quorum and majority support to pass. ### What protects the fast path The fast path is fast because it's narrow. Five independent safeguards keep it that way: **A pre-approved action list.** Fast proposals can only call actions that have been explicitly added to an allowlist by slow governance. New actions cannot be added through the fast path itself. **Untouchable targets.** The governance contracts themselves — the token, the timelock, the governor, the allowlist — can never be called by a fast proposal, even if someone tries to add them. Any change to the system has to go through slow governance. **A rate limit on proposers.** Each fast-path proposer can only submit a limited number of proposals per 12 hour period. This caps the rate at which a compromised proposer key could flood the system, giving holders time to respond and giving the broader community time to revoke the key. **A shared guardian.** A guardian role can cancel any non-final fast proposal mid-flight. This is typically held by a monitoring service that watches for clearly malicious or broken proposals, so holders don't have to be the first line of defense in an emergency. **The veto itself.** Even if every other safeguard fails, the veto window is the final backstop. The threshold scales with the total supply of staked tokens, so it cannot be diluted by issuing more tokens. ### Possible outcomes for a fast proposal | What happens | Result | | --------------------------------- | ------------------------------------------------------------ | | Veto threshold never reached | Proposal executes right after the veto window | | Veto threshold reached | Proposal is blocked; a confirmation vote opens automatically | | Confirmation vote passes | Action executes through the normal slow path | | Confirmation vote fails | Action is permanently blocked | | Cancelled by proposer or guardian | Proposal is dropped before completing | ### Tracking what kind of proposal you're looking at Every proposal — fast or slow — has a unique ID. Whether a given proposal is on the fast or slow path is fixed and does not change. When a fast proposal is vetoed and escalates, the resulting confirmation vote is a **new** proposal with its own ID. The original fast proposal stays on record as defeated; the confirmation vote runs as a standard slow proposal from that point on. ### When does the fast path actually get used? The fast path is intended for actions that are routine, reversible, or time-sensitive — for example: * Routine parameter tuning * Scheduling or pausing a rebalance window * Rotating an oracle to a vetted alternative It is **not** intended for, and cannot be used for, structural changes: * Changing what's on the pre-approved action list * Upgrading the governance contracts * Changing the token or the timelock * Adding or removing voting power directly Anything in the second category requires a full community vote. # Yield DTFs **Yield DTFs package diverse baskets of yield‑bearing assets into single ERC‑20 tokens.** All Yield DTFs are fully backed by diversified collateral and can be protected against default by [Reserve Rights (RSR) staking](/core-components/rsr-reserve-rights#staking). Stakers earn a portion of DTF yield in exchange for governance and security. ## Key features Yield DTFs are fully onchain financial primitives that deliver yield, security, and accessibility—no intermediaries required. * Full 1:1 backing & emergency overcollateralization * Permissionless onchain minting, redemption, & deployment * Autonomous revenue auctions executed by dedicated contracts * Customizable onchain decentralized governance ## Learn more * 🌐 [Overview](/core-components/yield-dtfs/overview)\ A big picture overview of Yield DTF functionality and governance. * 🔁 [Minting & redeeming](/core-components/yield-dtfs/minting-and-redeeming)\ Mint or redeem using a one-step zap, exact collateral, or direct contract calls. * 🛠 [Deployment guide](/core-components/yield-dtfs/deployment-guide)\ How to launch a new Yield DTF—including collateral selection, configuration, and governance. * ⚙️ [Protocol operations](/core-components/yield-dtfs/protocol-operations)\ Details of minting/redeeming, collateral management, yield capture, and revenue distribution. * 📜 [Smart contracts](https://github.com/reserve-protocol/protocol/tree/master/docs)\ A walkthrough of the contracts that govern collateral, issuance, revenue, and governance. * 🔐 [Security & audits](/core-components/yield-dtfs/security)\ Audit reports, bug‑bounty details, and risk‑mitigation practices that keep DTFs secure and reliable. # 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 Funds (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 collateralized, yield-accruing basket with robust decentralized infrastructure. ![](/files/9c10861b49e63bc2a088d89c741e3beccb832d27) 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 DTF 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 of the [collateral documentation](https://github.com/reserve-protocol/protocol/blob/master/docs/collateral.md)). 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. {% hint style="info" %} 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 describe the intended behavior. {% endhint %} # Minting & redeeming Minting/redeeming directly converts between Yield DTFs and their underlying collateral—no custodians or order books required. Anyone can mint or redeem permissionlessly. ![issuance and redemption](/files/0e8ec43ddc36c4d17c1826a37ffd4af9198ebb04) For convenience, the protocol offers zapper helpers that let users enter or exit using almost any ERC‑20 token or native ETH in one transaction. ## How to mint or redeem There are three main ways to mint or redeem. The [Reserve app](https://app.reserve.org/) provides a convenient interface, but any front‑end can access the same permissionless contracts. {% stepper %} {% step %} ### Zapper (one‑step) When to use: You want to use a single ERC‑20 or ETH and let the app handle the swaps. * Click the **Mint** button on any DTF page → choose **Mint** or **Redeem** * In the **You use** or **You receive** field, pick any supported token (ETH, USDC, wBTC, etc.) * Enter an amount and review the quote {% endstep %} {% step %} ### Manual mint / redeem When to use: You hold/want the exact collateral tokens or need precise slippage control. * Click **Switch to manual mode** on the DTF’s Mint/Redeem page * Review per‑token amounts to deposit/receive * Approve any necessary tokens and submit {% endstep %} {% step %} ### Direct contract call When to use: Integrations, scripts, advanced use cases. * Call `issue(amount)` or `redeem(amount)` on the DTF proxy. Basket ratios are calculated and enforced onchain. See the [smart contracts](https://github.com/reserve-protocol/protocol/tree/master/docs) section for contract details and addresses. {% endstep %} {% endstepper %} # Protocol operations The Reserve Yield Protocol automates the entire life-cycle of Yield DTFs with fully onchain, autonomous smart contracts. The sections below break down how the protocol handles minting, collateral management, yield capture, and revenue distribution. ## Issuance & redemption Anyone can bring the protocol X amount worth of collateral baskets and receive X DTF tokens in exchange for it. Anyone can also bring the protocol Y DTF tokens and receive Y worth of collateral baskets in return. ![](/files/0e8ec43ddc36c4d17c1826a37ffd4af9198ebb04) ## Issuance throttle As a way to limit the extractable value in the case of an attack or exploit of a Yield DTF, the protocol allows the DTF deployer (and governance) to set a limit on the rate of issuance. The throttling mechanism works as a battery: after a large issuance, the issuance limit recharges linearly to the defined maximum at a defined speed of recharge. The idea is to ensure net issuance for a Yield DTF never exceeds some bounds per unit time (hour). Limits can be set as a fixed amount of DTF tokens (e.g. 2,000,000 tokens) and/or as a percentage of token supply (e.g. 10% as default). ## Redemption throttle Similar to the issuance throttle, each Yield DTF can have a redemption throttle to limit the amount of extractable value in the case of an attack or exploit. The throttling mechanism works as a battery: after a large redemption, the redemption limit recharges linearly to the defined maximum at a defined speed of recharge. The idea is to ensure net redemption for a DTF never exceeds some bounds per unit time (hour). Limits can be set as a fixed amount of DTF tokens (e.g. 2,500,000 tokens) and/or as a percentage of token supply (e.g. 12.5% as default). Note: It is recommended that the redemption throttle is greater than the issuance throttle, to avoid consuming all the redemption throttle with an issue‑redeem operation. ## Staking and unstaking Reserve Rights (RSR) holders can stake their RSR tokens on Yield DTFs to make DTF holders whole in the unlikely event of a collateral token default, and receive a portion of the revenue the DTF makes in return. Right after staking RSR tokens on a Yield DTF, the staker receives an stRSR (staked Reserve Rights) token at a particular exchange rate to RSR. This exchange rate starts at 1.00 and will change over time—either by revenue being shared with the RSR stakers, or through overcollateralization slashing. To participate and vote in Governance proposals, stakers need to delegate their stakes to themselves to activate their voting weight. ![](/files/bf51c48bd877b47d09a322094986703022d14191) If an RSR staker decides to unstake their RSR tokens, they’ll have to wait the unstaking delay (by default set to 2 weeks) before receiving their RSR tokens back. While in the delay period, the stRSR to RSR exchange rate is locked (the staker is no longer accumulating revenue from the DTF). However, the RSR is still liable to be slashed in the case of a collateral default. The reason for an stRSR position needing to be slashable, but not earning revenue, during the unstaking delay period is because the alternative would allow for gaming of the system. If revenue was still being accumulated during the delay period, one could immediately unstake after staking their RSR (and repeat this process) to circumvent the delay period—ultimately resulting in a less consistent overcollateralization pool. Unstaking an stRSR position requires two transactions: one to initiate the unstaking process and one at the end of the delay period to receive the RSR tokens back. In between these two transactions the stRSR position is not transferable (as stRSR gets burned upon the first transaction). ## Asset management ERC-20 assets that need to be used as part of a Yield DTF system (either as collateral or as revenue assets) need to be registered in the Asset Registry contract for that particular DTF. Governance is in charge of registering, unregistering, and swapping assets. * `register`: Adds the asset to the Asset Registry, including all the required details the protocol needs to handle that asset. * `swapRegistered`: Allows modifying/updating details and functionality of a previously registered asset. * `unregister`: Removes the asset from the Asset Registry. It will no longer be used by the Yield DTF system. The intended use of this function is for governance to remove bad collateral contracts. Proposals that perform unregistration of assets should include at the end a call to refresh the basket (`refreshBasket()`). A detailed list of non-compatible ERC-20 assets is included in the [deployment walkthrough appendix](/core-components/yield-dtfs/deployment-guide/yield-dtf-deployment-walkthrough#appendix). ## Revenue handling ### Source of revenue The revenue that Yield DTFs accrue comes from their collateral baskets, including tokenized outputs from DeFi protocols such as cUSDC (Compound USDC), aDAI (Aave DAI), or various AMM LP tokens. These tokens are designed to increase monotonically (ever-increasing) against their base tokens, as they are pegged to the value of the base token + any borrowing/trading fees paid in the relevant pool. The protocol can track the appreciation of a Yield DTF’s collateral tokens in USD terms, and decrement the redeemability for that DTF accordingly. ![](/files/bef80e5cdc6a1ac04aa6acf968ce17d926943fd0) ## Revenue distribution There are several components essential to understanding how Yield DTF revenue is distributed to DTF holders or RSR stakers. Below they are introduced and then consolidated into the full picture. #### Revenue distribution to Yield DTF holders All collateral tokens provided to the protocol are stored in the Backing Manager (BM). The BM is responsible for holding them, minting more DTF tokens out of them, or trading them for DTF tokens or RSR (to later pay out rewards to DTF holders or RSR stakers). If a Yield DTF X has revenue going entirely to DTF holders, the BM will periodically mint as many token X as it can from the growing collateral. Any remaining grown collateral that cannot be evenly minted into DTF X will be sent to the DTF Trader, where it will be traded directly for more token X through auctions. ![](/files/77daa94b8cc92aabed4a3aa0eb8ce0a3db54ac24) After trading, both the newly minted token X and the newly traded token X will be consolidated in the Furnace. The Furnace is responsible for melting (= slowly burning) these new tokens, which incrementally increases the exchange rate between the DTF and its collateral basket. ![](/files/5b4d735bb767bbb045c339716b658026ab0066bf) To summarize: the protocol holds all collateral tokens in the Backing Manager. Whenever it can, it will mint new DTF tokens or trade excess collateral to DTF tokens via the DTF Trader. After minting/trading, the DTF tokens get melted via the Furnace—resulting in the DTF becoming more valuable (redeemable for more collateral tokens). The revenue distribution to Yield DTF holders can be visualized as follows: ![](/files/c44e8afebabcf45d6f2856329fb1bca8fbbcb136) #### Revenue distribution to RSR stakers If a Yield DTF Y has revenue going entirely to RSR stakers, the BM will periodically mint as many token Y as it can from the growing collateral. After minting, the newly minted tokens and all remaining grown collateral that could not be evenly minted into DTF Y will be sent to the RSR Trader, where it will be traded directly for RSR tokens through auctions. After trading, the protocol sends all the newly acquired RSR to the stRSR pool, where it is slowly dripped out as rewards for the RSR stakers by increasing the stRSR/RSR exchange rate. ![](/files/30710b7be7acc4468f20daee7bda54d925d9ff32) To summarize: the protocol holds collateral in the Backing Manager. Whenever it can, it trades excess collateral to RSR via the RSR Trader. After trading, the RSR gets slowly handed out via the stRSR pool—resulting in stRSR becoming more valuable (redeemable for more RSR tokens). The revenue distribution to RSR stakers can be visualized as follows: ![](/files/d0d452ff32d06b61503317e4607d693ede9e7599) #### Summary of revenue distribution When deploying a Yield DTF, the deployer defines what portion of the revenue goes to DTF holders versus RSR stakers. For example, if a Yield DTF Z sends 40% of revenue to DTF holders and 60% to RSR stakers, the protocol will periodically: * Take 40% of the accrued revenue in the Backing Manager, mint as many token Z as possible, send any remainder to the DTF Trader to trade for token Z, then consolidate newly minted/traded token Z in the Furnace to be melted—thereby increasing the exchange rate of DTF token Z to its collateral. * Take 60% of the accrued revenue in the Backing Manager, mint as many token Z as possible, send the newly minted tokens and any remainder to the RSR Trader to trade for RSR, then send the newly acquired RSR to the stRSR pool to be dripped out to stRSR holders—thereby increasing the stRSR/RSR exchange rate. ![](/files/bdf1f8284747ede9ff4c5a867e0bbd5c5f030234) The Reserve Yield Protocol can be configured to send (part of the) Yield DTF revenue to any arbitrary Ethereum address (e.g. to compensate the DTF deployer, to build a DTF treasury, etc.). The deployer can decide whether to pay the third-party address in DTF tokens or RSR. In either case, the part of the revenue designated to the third-party address can be sent directly from the DTF Trader or the RSR Trader—it does not have to go through the Furnace or stRSR pool first. ## Recapitalization ### Fully collateralized vs. fully funded When we talk about recapitalization, we distinguish between two states for a Yield DTF: * Fully collateralized: the protocol holds the right balances of the right tokens to offer 100% redeemability. * Fully funded: the protocol holds the right amount of value, but not necessarily the right amounts of collateral to offer 100% redeemability. The Reserve Protocol aims to be fully collateralized at all times, but may not always be. For example, right after governance decides to change the collateral basket, the protocol may be fully funded but not yet fully collateralized. Similarly, in the case of a collateral default, the protocol might be fully funded through excess collateral or RSR overcollateralization, but not fully collateralized to offer full redeemability. When the protocol is not fully collateralized, it will sell off any assets it holds that are not part of the proper collateral basket until either (a) the protocol is fully collateralized again or (b) RSR from the stRSR contract needs to be sold to recapitalize the protocol. #### Recapitalization through Reserve Rights If any of a Yield DTF's collateral tokens default, the default flag would be raised by the protocol through the default checking mechanisms explained in the [Monetary Units section](https://github.com/reserve-protocol/protocol/blob/master/docs/collateral.md). At that point, the protocol will sell as much of the faulty collateral as it can through auctions and use the proceeds, as well as any excess collateral still in the system, to purchase the predefined emergency collateral (see the [Deployment Guide](/core-components/yield-dtfs/deployment-guide)). If auction proceeds and excess collateral are insufficient to fully collateralize the DTF with the emergency collateral, the protocol will attempt to recapitalize using RSR tokens staked in the stRSR contract. The required amount of RSR tokens will be seized from the stRSR contract and sold for the required amount of emergency collateral through auctions—resulting in an even “haircut” for all RSR stakers. ![](/files/ac254f0f845b52f2c32a46e53fd954536b832bcd) ## Auctions Auctions are employed whenever an asset within the DTF system is traded for another asset. Possible scenarios include (1) processing DTF revenue and (2) recollateralization following a basket change or a collateral default. The Reserve Yield Protocol supports multiple trading systems; currently it provides support for two auction implementations: * Dutch auctions * Batch auctions It is anticipated that Dutch auctions will be the preferred trading method, with a fallback to batch auctions available when manipulation is suspected or a more manual trading process is warranted. ### Dutch auctions A Dutch auction is a type of auction where the item starts at a high price, and the price lowers until a buyer accepts the current price. The Reserve Protocol's implementation of Dutch auctions utilizes a 4-phase price reduction mechanism which safeguards against potential price manipulations and accommodates natural price fluctuations during the auction. {% stepper %} {% step %} ### Phase 1 The auctioned asset declines from 1000x of its expected price down to 1.5x. Bids are not expected during this period; this serves as a safeguard against price manipulation. {% endstep %} {% step %} ### Phase 2 The asset falls from 1.5x its expected price down to 1x the expected price. This stage acknowledges the potential for natural price movements during the auction. {% endstep %} {% step %} ### Phase 3 The asset declines from its expected price to its worst possible price, accounting for oracle errors and the max trade slippage parameter. This is where most bids are expected to occur. {% endstep %} {% step %} ### Phase 4 The price remains static at the worst price, providing an opportunity for manual human bidding in the absence of bots. {% endstep %} {% endstepper %} A Dutch auction completes when a user places a full-lot bid or when the auction time runs out and a user chooses to close the auction with no bids. At that point either a new Dutch auction or a batch auction can be run for the same assets. ### Batch auctions Reserve relies on Gnosis' Easy Auction () for its implementation of batch auctions. Batch auctions match limit orders of buyers and sellers at one fair clearing price by fulfilling the batch of bids above an acceptable minimum price that satisfies the supply being sold. Example: if 10 tokens X are sold and bids are: * A buys 5 at $10/token * B buys 4 at $9/token * C buys 4 at $5/token Then A and B receive 5 and 4 tokens respectively, C receives 1 token, and all bids clear at $5/token. # Security ### Security & audits Reserve aims to establish a robust and stable asset-backed currency platform. However, this necessitates the implementation of an additional layer of smart contracts, introducing an extra level of smart contract risk. The Reserve team is aware of these tradeoffs and has prioritized security by undergoing multiple audits conducted by the world's leading security firms. #### Smart contract security audits | Auditor | Date | Scope | Report Link | | -------------- | -------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Trail of Bits | Aug 2022 | Protocol | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/trail-of-bits-2022-08-reserve-protocol-securityreview.pdf), [Fix Review](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/trail-of-bits-2022-08-reserve-protocol-fixreview.pdf) | | Solidified | Oct 2022 | Protocol | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Solidified%20-%20Audit%20Report%20-%20Reserve%20Protocol.pdf) | | Ackee | Oct 2022 | Protocol | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Ackee%20-%20abch-reserve-protocol-report-1.1.pdf) | | Halborn | Nov 2022 | Protocol | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Halborn%20-%20Reserve_Protocol_Smart_Contract_Security_Audit_Report_Halborn_Final.pdf) | | Code4rena | Mar 2023 | Protocol v 2.1.0 | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Code4rena%20Reserve%20Audit%20Report%20-%20Release%202.1.0.md) | | Code4rena | Jun 2023 | Protocol v 3.0.0 (core) | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Code4rena%20-%20Reserve%20Audit%20Report%20-%20Release%203.0.0%20\(core\).md) | | Code4rena | Jul 2023 | Protocol v 3.0.0 (collaterals) | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Code4rena%20-%20Reserve%20Audit%20Report%20-%20Release%203.0.0%20\(collaterals\).md) | | Trust Security | Jan 2024 | Protocol v 3.1.0 | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Trust%20Security%20-%20Reserve%20Audit%20Report%203_1_0.pdf) | | Trust Security | Feb 2024 | Protocol v 3.2.0 | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Trust%20Security%20-%20Reserve%20Audit%20Report%203_2_0.pdf) | | Solidified | Apr 2024 | Protocol v 3.3.0 | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Solidified%20-%20Audit%20Report%20-%20Reserve%20Protocol%20-%20April%2025%202024.pdf) | | Trust Security | May 2024 | Collateral plugins | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/individual-plugins/Reserve_MetaMorpho_plugins_v2.pdf) | | Trust Security | May 2024 | Upgrade Spell v 3.4.0 | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Trust%20Security%20-%20Reserve%20Audit%203.4.0%20Spell.pdf) | | Solidified | Jun 2024 | Protocol v 3.4.0 | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/Solidified%20-%20Audit%20Report%20-%20Reserve%20Protocol%203.4.0.pdf) | | Trust Security | Jul 2024 | Collateral plugins | [Report](https://github.com/reserve-protocol/protocol/blob/master/audits/Reserve_June_Plugins_v1.pdf) | | Trust Security | Jul 2024 | Collateral plugins | [Report](https://github.com/reserve-protocol/protocol/blob/73362259c5a14c9c7bf3db0bd64fd9d1d370568a/audits/individual-plugins/Reserve_ETH_Plus_LP_v1.pdf) | ### Bug bounty In addition to undergoing numerous audits, the Reserve team would like to motivate the community to undertake their own audits and will reward individuals who responsibly disclose any vulnerabilities they find. Bug bounty of $10,000,000 Reserve has partnered with Immunefi for establishing a bug bounty program. See additional details of the program, or report any findings here: ### Risks For a detailed overview of potential risks and risk-mitigation strategies, see the [Risks page](/risks). # Deployment guide Anyone can create a Yield 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](https://research.csiro.au/blockchainpatterns/general-patterns/contract-structural-patterns/factory-contract/) that allows anyone to deploy their own Yield DTF instance onchain. ![](/files/82ee58e6a429d29cefbf458ffd08f0a5f62a40d1) Creating a Yield DTF can be done either by interacting directly with the [Reserve Yield Protocol’s smart contracts](https://github.com/reserve-protocol/protocol) or any user interface built on top of them. The Reserve app provides a convenient [interface to the Yield DTF factory](https://app.reserve.org/deploy/yield-dtf), but any front‑end can access the same permissionless contracts. ## Learn more * **Getting started** → [Designing a successful Yield DTF](/core-components/yield-dtfs/deployment-guide/designing-your-yield-dtf) * **Deployment walkthrough** → [Using the Reserve app UI](/core-components/yield-dtfs/deployment-guide/yield-dtf-deployment-walkthrough) * **Reference parameters** → [Advanced parameters](/core-components/yield-dtfs/deployment-guide/advanced-parameters) * **Post‑launch playbook** → [Tips for DTF success & adoption](/core-components/yield-dtfs/deployment-guide/post-launch-playbook) # Designing your Yield DTF Before deploying, it’s important to consider what goes into creating a successful Yield DTF. Each DTF will have its own ecosystem use cases, community, and unique go-to-market strategies. Just because anyone can deploy and/or mint a DTF does not mean adoption is guaranteed. Consider the following points to help ensure success. ## Key questions {% stepper %} {% step %} ### Collateral mix Is the basket diverse and attractive? * See our [basket design guide](https://blog.reserve.org/rtoken-basket-design-1d20ae03bf89) for key considerations * Find collateral plugins in the [deployer UI](https://app.reserve.org/deploy/yield-dtf) or [write your own](/core-components/yield-dtfs/deployment-guide/yield-dtf-deployment-walkthrough#appendix) * Specify emergency backup assets in case of default {% endstep %} {% step %} ### Target yield What are the yield targets (if any) for your DTF? * Consider risk/reward trade-offs and the DTF's target market * Check out [DefiLlama](https://defillama.com/yields) for inspiration and market rates * Fork [this spreadsheet](https://docs.google.com/spreadsheets/d/1nipH_G0lKQeaXItatDeAGju-4smkYeaIpUl3Pxnz3iU/edit) to model blended APY and revenue share {% endstep %} {% step %} ### Revenue split What share goes to holders, RSR stakers, and other addresses? * **DTF holders**: incentivize minting and holding as a savings vehicle * **RSR stakers**: incentivize decentralized governance and overcollateralization * **Other addresses**: fund marketing, liquidity, research, DAO management, etc. {% endstep %} {% step %} ### Branding What is the name, ticker, and one-line marketing hook for your DTF? * Use unique & memorable branding to convey the DTF's unique features * Keep the ticker short & avoid overlap with other major assets {% endstep %} {% step %} ### Mandate What will the DTF's mandate be? * The mandate is a 256‑character compass for governance * Specify the DTF's goals, constraints, and priorities {% endstep %} {% endstepper %} If you’re unsure how to answer any or all of these questions, the Reserve community is welcoming and willing to help! [Jump in the Reserve Telegram channel here.](https://t.me/reservecurrency) ## Pre-launch checklist Before deployment, make sure each of the following has been specified: * ✅ Deployment network (Ethereum / Base / Arbitrum) * ✅ Primary & backup collateral baskets * ✅ Revenue split (DTF holders / RSR stakers / others) * ✅ Name, ticker, & mandate * ✅ DTF parameters (use presets or tweak [advanced parameters](/core-components/yield-dtfs/deployment-guide/advanced-parameters)) Once each has been chosen, the Yield DTF is ready for launch. # Advanced parameters When deploying a Yield DTF, 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](/core-components/yield-dtfs/protocol-operations), we advise reading through that section of the documentation first — it will give the deployer the necessary context to fully understand all parameters. ## Backing Manager 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. It can be useful to have some buffer time before rebalancing in order to ensure sufficient auction participation. However, in the modern MEV day it's a bit unnecessary. Some new RTokens may still find it useful to set a nonzero value, but in general it can be safely set to 0 for most Yield DTFs. Default value: `0` = 0s ### Warmup period The warmup period defines how many seconds should pass after a collateral asset resumes being SOUND before issuance or trading can resume. This parameter is useful to defend against short-term oracle manipulation attacks and in cases where asset prices may be experiencing larger fluctuations. Default value: `900` = 15 minutes ### Batch auction length (s) The length of a Gnosis EasyAuction, one of two trading methods supported by the Reserve Protocol. Considerations when determining this value: * If set too low, back-to-back batch auctions may not give arbitrageurs enough time to complete arbitrage loops that involve centralized exchanges. We don’t want capital-constrained traders to have to sit out every-other auction. * If set too high, fewer auctions will fill in general due to organic price movement, and the protocol will be much slower to rebalance. This is because the price can swing more than maximum trade slippage in the unfavorable direction. Default value: `900` = 15 minutes ### Dutch auction length (s) The length of the custom Dutch Auction, one of two trading methods supported by the Reserve Protocol. Considerations: * If set too low, more slippage will be encountered due to precision loss. * If set too high, the protocol will be slow to rebalance. Default value (mainnet): `1800` = 30 minutes\ Default value (Base/Arbitrum): `900` = 15 minutes ### Backing buffer (%) The backing buffer is a percentage value that describes how much extra collateral to hold as backing in the Backing Manager. It is important for preventing RSR seizure during normal rebalancing. * Too low a backing buffer can result in RSR seizure during normal rebalancing. While unpleasant, the stronger reason to avoid this is to prevent situations where RSR stakers are incentivized to unstake before rebalancing proposals in order to avoid paying their fair share. The backing buffer should be set high enough to prevent this outcome. * Too high a backing buffer can cause RToken and RSR staker yields to drop during large supply increases as new issuance creates additional debt burdens that must be filled in with new appreciation. In general the amount of time this takes is short, but when an RToken grows fast enough, backing-buffer shortfall growth can outpace yield accrual and result in no revenue being recognized for a while. Note: It is not important to consider the backing buffer for *default* scenarios, only governance-led rebalances. There is no one-size-fits-all — each RToken should customize its backing buffer parametrization based on: {% stepper %} {% step %} ### How many days of yield it will take to fill the backing buffer Consider expected revenue cadence and how long it takes to refill the buffer with normal yield. {% endstep %} {% step %} ### Expected loss due to slippage if the least-liquid backing collateral is removed Assess the liquidity and potential slippage cost when removing least-liquid assets. {% endstep %} {% step %} ### Sensitivity of DTF holders to variance in their yield Consider how much yield volatility holders will tolerate. {% endstep %} {% endstepper %} Default value: `1e15` = 0.1% ### Max trade slippage (%) The maximum trade slippage is a percentage value that describes the maximum deviation from oracle prices that any trade that the protocol performs can clear at. Oracle prices have ranges of their own; the maximum trade slippage permits additional price movement beyond the worst-case oracle price. Setting this percentage too high could cause the protocol to take high losses if auctions are illiquid. Default value: `0.005e18` = 0.5% ## Supply throttles To restrict the system to organic patterns of behavior, Yield DTFs maintain two supply throttles, one for net issuance and one for net redemption. When a supply change occurs, a check is performed to ensure this does not move the supply more than an acceptable range over a period; a period is fixed to be an hour. The throttling mechanism works as a battery: after a large issuance/redemption, the limit recharges linearly to the defined maximum at a defined speed of recharge. Limits can be defined (for issuance and redemption) in DTF token amounts and/or as a percentage of the DTF token supply. Important: The redemption throttle must always exceed the issuance throttle. ### Issuance throttle rate (%) A fraction of the RToken supply that indicates how much net issuance to allow per hour. Can be set to 0 to solely rely on the issuance throttle amount. Default value: `1e17` = 10% per hour ### Issuance throttle amount A quantity of DTF token that serves as a lower-bound for how much net issuance to allow per hour. Defined in DTF token amounts. Must be at least 1 whole DTF token. Can be set to 0 to solely rely on the issuance throttle rate. Default value: `2e24` = 2,000,000 tokens ### Redemption throttle rate (%) A fraction of the RToken supply that indicates how much net redemption to allow per hour. Can be 0 to solely rely on the redemption throttle amount. Default value: `12.5e16` = 12.5% per hour ### Redemption throttle amount A quantity of RToken that serves as a lower-bound for how much net redemption to allow per hour. Defined in RToken amounts. Must be at least 1 whole RToken. Can be set to 0 to solely rely on the redemption throttle rate. Default value: `2.5e24` = 2,500,000 RToken ## Other parameters ### Short freeze duration (s) The number of seconds a short freeze lasts. Governance can freeze forever. Default value: `259200` = 3 days ### Long freeze duration (s) The number of seconds a long freeze lasts. Long freezes can be disabled by removing all addresses associated with the role. Default value: `604800` = 1 week ### Withdrawal leak (%) Most RSR withdrawals will not trigger a refresh of asset prices (which can determine whether collateral has defaulted), allowing for cheaper withdrawals. The tradeoff of not refreshing prices with every withdrawal is that the system runs the risk of prices becoming stale, and the system not being able to react sufficiently swiftly to market conditions. This parameter attempts to balance these tradeoffs, by setting a fraction of RSR stake that should be permitted to withdraw without a refresh of asset prices. When cumulative withdrawals (or a single large withdrawal) exceed this fraction, gas must be spent to refresh all assets. Setting this number larger allows unstakers to save more on gas at the cost of allowing more RSR to exit improperly in the event of a default. Default value (mainnet): `5e16` = 5%\ Default value (Base/Arbitrum): `1e16` = 1% ### Unstaking delay (s) The unstaking delay is the number of seconds that all RSR unstakings must be delayed in order to account for stakers trying to frontrun defaults. Whenever an RSR staker chooses to withdraw their RSR, they must submit a transaction, wait X amount of time, and then submit another transaction to complete the withdrawal. During the waiting period, their RSR continues to be subject to forfeiture in the case of a collateral token default, but stops earning its pro-rata share of the RToken’s revenue. The goal of this delay is to make it so that at any point in time, staked RSR that has not had a withdrawal transaction initiated is at least X time away from being withdrawn. Default value: `1209600` = 2 weeks ### Reward ratio (decimals) The reward ratio is the percentage of the current reward amount that should be handed out per second. It applies to both the Furnace (RToken melting) and stRSR (RSR rewards). Default value: `1146076687500` = a half-life of 7 days. Mainnet reasonable range: `1e11` to `1e14` ### Minimum trade volume ($) The minimum trade volume represents the smallest amount of value that is worth executing a trade for. * Setting this too high will result in auctions happening infrequently or the RToken taking a haircut when it cannot be sure it has enough staked RSR to succeed in rebalancing at par. * Setting this too low may result in more slippage or allow griefers to delay important auctions. The variable should be set such that donations of size minTradeVolume would be worth delaying trading auctionLength seconds. We expect auction bidders to pass through any gas fees they pay during trading to the protocol. They are under competition, so those that do not will find themselves with less capital over time relative to those that do. Warning: Every collateral in the basket should be a large enough portion of the basket that it is worth trading at the configured minTradeVolume at typical supply levels. Default value: `1e21` = $1k ### DTF max trade volume ($) This represents the maximum sized trade for any trade involving RToken, in terms of value. Note: Each collateral plugin will also have its own max trade volume defined. Any trade will be sized to be less than or equal to the minimum of both plugins' max trade volumes. Default value: `1e24` = $1m # Yield DTF 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: {% stepper %} {% step %} ### Getting started * Navigate to the Yield DTF deployer UI: * Connect your wallet using the Connect button in the top right. ![](/files/e12df8bc8cf6a5942b5942f112b1b8767453e637) {% endstep %} {% step %} ### 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. ![](/files/57e0933f7b99be9348182d7436c0cd09b3e9bcbc) * 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. {% endstep %} {% step %} ### 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 — see the [appendix](#appendix) below. * 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. ![](/files/fab3fd767166a458ee8d775d2c43fbea065a93eb) 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. ![](/files/6f45f3b47e014a60fdab1657df4654931deff445) {% endstep %} {% step %} ### 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). ![](/files/5f7903d56f9d110424fa0c474c4e3122e7fae6a9) {% endstep %} {% step %} ### Configure parameters This section discusses what each configuration parameter does, and why it’s important. For more information on each parameter, see [Advanced parameters](/core-components/yield-dtfs/deployment-guide/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 | Additional details on 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 happened, and we did 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 — once a robust market of MEV searchers is established this can likely be set to zero. {% endstep %} {% step %} ### Deploy Once you’re satisfied with your DTF’s name, basket composition, and other parameters, click the “Deploy” button which will prompt you to sign a transaction (“Tx1”). ![](/files/e4ef9a5c094e99a0e9e8a7123e574788cf3d0433) 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](/core-components/rsr-reserve-rights#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. {% endstep %} {% step %} ### Set up governance * If you wish to use Governor Anastasius (default; recommended by Reserve), ensure the corresponding toggle is active. ![](/files/dbeaa55f72c1b927eb81175053fe4b46237fb6d0) * Carefully select addresses for Guardian, Pauser, and Freezer roles. See the [roles documentation](https://github.com/reserve-protocol/protocol/blob/master/docs/system-design.md). 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 | 0.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 functional after configuring governance (i.e., whether the DTF should be active immediately post-deployment, or whether governors should decide to start in a paused state). ![](/files/a58454fbcd449bca7d8d7d37b6b68a1d7ef429a8) 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. ![](/files/c33e6460ac21cd02b6904c38a21e3e8ec9fe92c8) {% endstep %} {% endstepper %} ## Closing ![](/files/33f9ea35abcd9d6abcc75341ead2d80b74bde5f8) 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. Ongoing attention and marketing are required for DTFs to distinguish themselves in a crowded marketplace and truly flourish. Check out the [post‑launch playbook](/core-components/yield-dtfs/deployment-guide/post-launch-playbook). Join the [Reserve Telegram channel](https://t.me/reservecurrency) to share knowledge with and learn from other DTF deployers. *** ## 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. ![](/files/1b8cfe6c1859bf608e1e8fc237e9ec1f29c142a1) Helpful resources: * Collateral Plugin Overview: * Writing Collateral Plugins: * Reserve’s Solidity Style: Troubleshooting questions and feedback are always welcome in the [Reserve Telegram channel](https://t.me/reservecurrency). ### Non-compatible ERC-20 assets The following types of ERC-20 tokens are not supported to be used directly in a Yield DTF system. These tokens should be wrapped into a compatible ERC-20 token to be used within the protocol. * 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()` function in their interface (decimals should 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 A concrete example: Static ATokens for Aave V2 — see: ### Yield DTF deployer video tutorial (expandable)
How to deploy in about 5 minutes — video tutorial 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. Watch tutorial ![](/files/633732bc730a871cd5263459c389c94b91b88fca) ![](/files/4591a37c30b82e2e72bb1ac115ad67d2301d7e28) Duration: 06:46
*** ## Additional notes * Anyone can create an RToken by interacting directly with Reserve Protocol’s smart contracts or via user interfaces built on top of them. The primary UI is provided by ABC Labs: * For detailed protocol operations, governance, contracts, and further documentation, consult the Yield DTFs documentation on reserve.org. # Post-launch playbook Once a new DTF is live, several key actions can help to encourage adoption. This guide outlines some suggested activities to maximize visibility, utility, and transparency after launch. ## Marketing & awareness Ensure the wider community hears about the new Yield DTF and understands its value proposition. * Publish a launch thread on popular social media channels (e.g., X/Twitter, Discord, and Telegram) * Create a simple explainer graphic (e.g., basket composition & headline yield) for social sharing * Reach out to newsletters or podcasts for a “new-product” segment or guest appearance * Announce any liquidity-mining, minting rewards, or other incentives with clear timelines ## Onchain integrations Listing the DTF where users already trade and borrow maximizes utility and stickiness. * Seed a primary liquidity pool on a leading AMM (e.g., Curve, Uniswap, Aerodrome) * Submit listing proposals to at least one onchain money market (e.g., Morpho, Aave, Compound) * Co-incentivize early liquidity with integration platforms and partners * Monitor pool depth and spreads; consider strategies to remedy liquidity issues ## Data & analytics Reliable, transparent data builds trust and helps investors track performance. * Apply for listings on CoinGecko and CoinMarketCap—prepare ticker, logo, & a short description * If applicable, publish data to Dune Analytics, The Graph, and/or DefiLlama * Set up automated alerts (e.g., on Discord or X/Twitter) for governance proposals or status changes # Project milestones Coming soon # Project updates Coming soon # Risks This section explains the risks of using the Reserve platform. If you interact with the platform, you do so at your own risk. The following is provided for informational purposes only and is intended to describe certain risks associated with accessing, using, or otherwise interacting with the Reserve platform, including its smart contracts, related interfaces, and any DTFs. Nothing here or anywhere else on reserve.org or app.reserve.org (the “App”) is a recommendation to purchase, hold, redeem, mint, stake, trade, or otherwise use any DTF, protocol, or service. We believe clearly describing the following risks helps users make informed decisions. If you are unsure about any risk, you can ask questions in [Telegram](https://t.me/reservecurrency). These risks are not, and should not be construed as, exhaustive. They do not identify all risks, whether known or unknown, existing now or arising in the future. Users should conduct their own independent review and diligence before interacting with the Reserve platform and any DTF and should remain informed of any changes to the protocol, its dependencies, governance arrangements, or related infrastructure. If you do not fully understand the applicable risks, you should not use the Reserve platform. ## Reserve platform risks: smart contracts The Reserve platform relies on smart contracts to operate. Smart contracts may contain coding errors, design defects, security vulnerabilities, or other faults, whether known or unknown, that may result in exploits, unauthorized transactions, malfunction, interruption, inaccurate operation, or total or partial loss of user assets. Although smart contracts associated with the Reserve platform may be reviewed, tested, or audited by third parties, no audit, review, or testing process can eliminate all vulnerabilities or guarantee that the smart contracts are secure, functional, or free from defects. ## Oracle risks DTFs rely on third-party and other external pricing inputs, including oracle services, to obtain real-time or near-real-time asset price information. If any oracle fails, becomes unavailable, is manipulated, publishes inaccurate, stale, incomplete, or delayed data, or is integrated or used improperly, the Reserve platform may operate incorrectly. Such failures may affect accounting, collateral management, default determinations, recollateralization actions, redemptions, trading behavior, or other core protocol functions. By way of example only, an inaccurate price report for USDC could cause a Yield DTF to incorrectly treat a collateral asset as defaulted and attempt to exchange that asset for emergency collateral, potentially at a loss. ## MEV, slippage, and transaction execution risks Transactions submitted to public blockchains may be subject to miner or maximal extractable value practices, including sandwich attacks, front-running, back-running, and other forms of transaction reordering or opportunistic extraction. Users interacting with automated market makers or similar trading venues in connection with the Reserve platform, including for DTF trading, may incur losses as a result of adverse price movement, slippage, failed execution, partial execution, or value extraction by third parties. Users are solely responsible for evaluating transaction settings, including slippage tolerances, and for determining whether to use any available transaction protection tools or alternative transaction-routing methods. ## Governance risks The Reserve team has deployed a suggested governance system for DTFs that enables fully onchain governance. Because governance powers are broad, governance attacks are possible. For example, an attacker who acquires enough voting power could approve a malicious upgrade that enables theft of funds. Some of this risk is mitigated by special roles within the governance system. That said, these protections only work if the people holding those roles exercise them competently and in good faith. Before using a DTF, users should review who holds these roles on the Details + Roles page and the Governance page in the App. ## Issuer and custodian risk Digital assets may depend on issuers, custodians, or other centralized or third-party actors. Such parties may impose transfer restrictions, freezes, blacklists, redemption limits, or other controls that could impair the collateral assets underlying DTFs. These powers may be exercised for regulatory, compliance, commercial, discretionary, or other reasons, including reasons unrelated to any particular user conduct. In addition, the value and stability of certain collateral assets may depend on the adequacy, existence, management, and accessibility of offchain reserves or other supporting assets. Those arrangements may fail, be mismanaged, be misrepresented, become illiquid, or otherwise prove insufficient. ## Price and market risk The value of a DTF generally reflects the weighted value of its underlying collateral assets. If one or more underlying assets declines in value, depegs, becomes impaired, or experiences volatility, dislocation, or market stress, the value of the DTF may decline correspondingly. DTFs backed by volatile or partially volatile assets may experience substantial price fluctuations, and users should not assume price stability unless expressly stated and continuously maintained, which cannot be guaranteed. In addition, where Yield DTFs rely on RSR or similar overcollateralization mechanisms, such protection may be insufficient in practice. In stressed market conditions, the market value, liquidity, or realizable sale proceeds of RSR may decline materially, which may reduce or eliminate the effectiveness of any overcollateralization and impair the protocol’s ability to recollateralize after a default or collateral event. ## Underlying protocol risk The Reserve platform and DTFs may rely on assets, services, or integrations from third-party protocols, applications, bridges, liquidity venues, or infrastructure providers, including lending protocols and other decentralized finance systems. Use of the Reserve platform therefore exposes users to the risks associated with those third-party systems, including smart contract failure, governance failure, insolvency, exploit, oracle error, liquidity failure, bridge failure, upgrade risk, dependency failure, or other operational or legal issues. Failures in any such underlying protocol or integration may directly or indirectly cause loss, delay, impairment, or inaccessibility of collateral assets of DTFs or DTFs themselves. ## Interface and frontend risks Users may access the Reserve platform through direct smart contract interaction or through one or more web interfaces, applications, or other frontends operated by third parties. Any such interface may contain bugs, security vulnerabilities, malicious code, inaccurate transaction prompts, display errors, integration failures, or other defects. A frontend may also be compromised, spoofed, censored, unavailable, or operated in a malicious or negligent manner. As a result, users may be induced to sign incorrect transactions, approve unintended permissions, send assets to unintended destinations, or otherwise suffer losses. The existence of a publicly available interface does not constitute any representation that the interface is secure, audited, error-free, or appropriate for any particular use. ## No representation; assumption of risk By using the Reserve platform, you acknowledge that blockchain-based systems are inherently experimental and involve technological, legal, regulatory, and economic uncertainties. You further acknowledge that neither the identification of certain risks nor the implementation of any safeguards, audits, monitoring, governance mechanisms, or emergency procedures eliminates the possibility of loss. You assume all risks associated with use of the Reserve platform and DTFs, including risks arising from smart contracts, governance, oracle dependencies, collateral assets, third-party protocols, user interfaces, market conditions, and user error. # FAQ ## Overview
What is Reserve’s mission? The Reserve project’s mission is to make it possible for anyone to own and earn their share of the world’s wealth. It does this by enabling people to hold and transfer diversified portfolios of tokenized assets as a single unit, laying the foundation for asset-backed currency backed by real assets rather than inflationary fiat. Over time, earning and holding value this way allows people to build direct ownership of a share of the world’s wealth.
What are Decentralized Token Funds (DTFs)? DTFs allow anyone to own a share of everything. They are fully asset‑backed ERC‑20 tokens created with Reserve’s open‑source contracts. A DTF can represent anything from an automatically rebalanced yield basket to a broad crypto market index. Anyone can launch, mint, redeem, and govern a DTF permissionlessly onchain.
What’s the difference between Yield DTFs and Index DTFs? [Yield DTFs](/core-components/yield-dtfs) diversify across yield-generating strategies — like lending or staking — that employ a particular asset, such as a particular stablecoin or liquid staking token. Yield DTFs can be protected against default by Reserve Rights (RSR) stakers, who earn a portion of DTF yield in exchange for governance and overcollateralization. [Index DTFs](/core-components/index-dtfs) focus on efficiently managing diversified portfolios of tens to hundreds of tokens. Their lightweight design eliminates the need for complex collateral management, enabling the creation of large, transparent indexes with broad exposure. Instead of yield-based revenue, index DTFs charge minting and TVL (management) fees.
What are RTokens? RTokens are the technical name for all tokens launched on Reserve — whether they’re Yield DTFs or Index DTFs. While these docs use “DTF” for clarity & consistency, you’ll still see “RToken” in the app, videos, and community. Both terms are valid and refer to the same underlying contract standards. Yield DTFs and Index DTFs launched on Reserve can also be called "Yield RTokens" and "Index RTokens."
*** ## Reserve Rights (RSR)
What is the RSR token? [Reserve Rights (RSR)](/core-components/rsr-reserve-rights) is the token that allows anyone to own a share in the value of everything. It 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.
Where can I stake or vote‑lock RSR? You can stake or vote-lock RSR by accessing the [Reserve app](https://app.reserve.org/) and selecting a DTF. For Yield DTFs, RSR staking is necessary in order to participate in governance and earn rewards. Stakers also provide first-loss capital in the event a collateral asset fails in the DTF or a black swan event occurs — such as what happened during USDC’s depeg. [Learn more about staking](https://blog.reserve.org/how-to-stake-reserve-rights-rsr-f5393fe24573). For Index DTFs, creators can choose any governance token, although RSR is the default. Vote-lockers govern basket changes, parameters, and upgrades—and share in fees when enabled. [Learn more about vote-locking](https://blog.reserve.org/vote-locking-on-reserve-19e19201d78e).
What are the tokenomics of RSR? RSR has a fixed max supply of **100 billion** tokens, of which around **60%** are currently in circulation. All remaining RSR emissions follow a deterministic schedule which emulates the emissions curve of Bitcoin. See [CoinMarketCap's Token Unlock page](https://coinmarketcap.com/currencies/reserve-rights/#token_unlocks) for precise values and timeline, or [this blog post](https://blog.reserve.org/reducing-rsr-emissions-6da7f35917ba) for an overview of the emissions curve and its design motivations.
How can I estimate my RSR staking or vote‑lock returns? Current staking APYs (Yield DTFs) and governance reward shares (Index DTFs, if configured) are displayed in the Reserve app next to each DTF's Stake/Lock buttons. These values are estimated based on recent performance and may not be predictive of future performance. Once you have already staked or locked, you will notice rewards accrual in the app's wallet UI.
I have old RSR that I can no longer transfer from my wallet. How can I exchange these for the new RSR tokens? Good news: your new RSR is already in your wallet. The bad news is that some wallets do not auto-discover the new RSR, so you have to take a few extra steps. Read [How to Upgrade to the New Reserve Rights (RSR) Contract](https://blog.reserve.org/how-to-upgrade-to-the-new-rsr-contract-7eb338e4261a) for a comprehensive breakdown of your options.
*** ## Reserve app
What is the Reserve app? The [Reserve app](https://app.reserve.org/) (sometimes called "Reserve Register") is a decentralized app (“dapp”) frontend enabling easy access to the Reserve platform. The app allows anyone to create, mint, or redeem DTFs in a permissionless manner. The Reserve app also allows RSR (or other governance token) holders to stake or vote-lock their tokens onto their preferred DTFs to participate in governance, earn yield, and provide first-loss capital in the event of a depeg event.
How do I bridge DTFs or RSR between Ethereum, Base, and Arbitrum? In the Reserve app UI, click **More** and use the built‑in **Bridge** flow. Select the chain, token, and deposit or withdraw. The same interface supports DTFs, RSR, and other common tokens.
Where can I find Reserve ecosystem contract addresses? The contract addresses for all DTFs are available in the Reserve app. Navigate to the DTF page you want, then find the contract address(es) featured in the header alongside the DTF’s name. For more details, see the Smart Contracts sections of the [Yield DTF](https://github.com/reserve-protocol/protocol/tree/master/docs) and [Index DTF](/core-components/index-dtfs/smart-contracts) docs.
Who can create a DTF? Because the Reserve platform is permissionless and no coding experience is needed, anyone can create a DTF. DeFi developers, entrepreneurs, crypto protocols, apps, hedge funds, TradFi, and even rewards programs and video game/metaverse developers are all potential DTF deployers.
Which DTFs are available to mint/redeem? How? All DTFs can be minted and redeemed permissionlessly. DTFs are available to explore, mint, stake and govern via the [Reserve app](https://app.reserve.org/). For detailed walkthroughs, see the minting and redemption docs for [Yield DTFs](/core-components/yield-dtfs/minting-and-redeeming) and [Index DTFs](/core-components/index-dtfs/minting-and-redeeming).
I want to deploy my own DTF. Where do I start? **Yield DTFs:** Start by reviewing the [Official Documentation](/core-components/yield-dtfs), the [Deployment Guide](/core-components/yield-dtfs/deployment-guide), and the [YouTube Tutorial](https://www.youtube.com/watch?v=sf0PuYpVWRU\&ab_channel=Reserve), where you can find everything related to the process of deploying your DTF. Then you can visit the [Reserve app](https://app.reserve.org/deploy/yield-dtf) to deploy. **Index DTFs:** The Index DTF deployment UI is still under construction. If you want to be first in line to create an Index DTF, put down your contact information [here](https://app.reserve.org/deploy/index-dtf).
How do I list a DTF in the Reserve app UI? For your Yield DTF to be listed in the Reserve app, you can create a pull request in this [GitHub repository](https://github.com/reserve-protocol/rtokens). Index DTF listing coming soon.
*** ## Reserve platform operations
What blockchains does Reserve support? The Reserve Yield Protocol is currently deployed on Ethereum, Base, and Arbitrum. The Reserve Index Protocol is currently deployed on Ethereum and Base. DTFs (and RSR) can be bridged to many popular blockchains.
Has the protocol been audited? Yes. All audits can be viewed on the [Yield DTF](/core-components/yield-dtfs/security) and [Index DTF](/core-components/index-dtfs/security) Security & Audits pages.
Are Reserve's smart contracts decentralized? Yes. The core contracts are only upgradable via governance proposals that get approved by onchain governance. These proposals can either change a single parameter or upgrade a contract.
How are DTFs decentralized? Collateral baskets are tokenized onchain, with the smart contract risk diversified over multiple protocols and assets. Each DTF is governed separately by stakers or vote-lockers and each can have an entirely different governance system.
What are the risks of using the Reserve platform and DTFs? Smart contracts, depegs, counterparty and governance risks are all applicable to the Reserve platform. Read our [Risks documentation](/risks) or [Comprehensive Risk Mitigation at Reserve Protocol](https://blog.reserve.org/comprehensive-risk-mitigation-at-reserve-protocol-68a724e9989e) to dive deeper.
What are collateral plugins and why are they important? In the Reserve Yield Protocol, collateral plugins wrap ERC-20 tokens into assets that can back Yield DTFs. Without them, native ERC-20 tokens cannot be used to collateralize Yield DTFs. [Learn more about collateral plugins](https://github.com/reserve-protocol/protocol/blob/master/docs/collateral.md). The Reserve Index Protocol does not require collateral plugins, and natively supports most ERC-20s.
What assets can be used as collateral in DTFs? For **Yield DTFs**, any asset with a suitable collateral plugin can be used as a collateral asset within a Yield DTF. Collateral plugins help to price underlying assets and surface properties required for the DTF to ascertain its status. [Learn more about developing collateral plugins](https://github.com/reserve-protocol/protocol/blob/master/docs/collateral.md). Discover the [currently available collateral options](https://app.reserve.org/explorer/collaterals) in the Reserve app. New collateral assets are constantly being integrated into the protocol, and ambitious deployers can even [create custom collateral plugins](/core-components/yield-dtfs/deployment-guide/yield-dtf-deployment-walkthrough#appendix). For **Index DTFs**, nearly any ERC-20 token can be used, no collateral plugin required.
Are DTFs algorithmically backed? No, DTFs are not algorithmically backed. DTFs are fully asset-backed 1:1 with exogenous collateral (i.e., external, unrelated assets) that, via smart contracts, are able to be redeemed at any time for the underlying assets.
How can a DTF deployer earn revenue? Revenue distribution for DTFs is entirely flexible. From the revenue that is being accrued, any portion can be sent to any number of arbitrary Ethereum addresses, including the DTF deployer. Revenue share percentages are set when deploying the DTF and can only be changed by community governance.
Where does DTF revenue come from? **Yield DTFs:** Deposits in DeFi protocols such as Aave, Compound, Uniswap and Convex provide the depositor a receipt token that accrues yield. When these receipt tokens are used in collateral baskets for Yield DTFs, the protocol’s onchain operations harvest this yield to distribute to DTF stakeholders. This is performed 100% onchain. Learn more about [Yield DTF revenue handling](/core-components/yield-dtfs/protocol-operations#revenue-handling). **Index DTFs:** Two fee streams generate revenue for Index DTFs. A TVL fee, akin to a management fee, is assessed block-by-block as a percentage (max. 10% annualized) of the token's TVL. A mint fee (max. 5%) is assessed each time a DTF is minted. This is performed 100% onchain. Learn more about [Index DTF fees](/core-components/index-dtfs/fees).
How do Yield DTFs harvest and reflect yield in price? As underlying assets appreciate or rewards are earned, more DTF tokens can either be minted or obtained through revenue auctions. These tokens are subsequently sent to the [Furnace](/core-components/yield-dtfs/protocol-operations#revenue-distribution-to-yield-dtf-holders) and melted. As a result, Yield DTFs become redeemable for more of their base currency unit. DTFs that accrue revenue to their holders do not rebase, which means that yield-bearing dollar-denominated DTFs (for example) often resemble [flatcoins](https://decrypt.co/155775/flatcoins-new-thing-on-the-horizon-coinbase-ceo-brian-armstrong), rather than stablecoins. That is, their price will continue to increase over time ($1.00 → $1.10 → $1.20, and so on). Learn more about [RToken revenue handling](/core-components/yield-dtfs/protocol-operations#revenue-handling).
How is revenue distributed to DTF holders, RSR stakers, & vote-lockers? For both Yield and Index DTFs, governance determines how protocol revenue is routed—whether to RSR stakers, vote-lockers, DTF holders, or elsewhere. **Yield DTFs**: Once a threshold value has been met, “revenue auctions” sell accrued rewards to buy RSR, which is subsequently distributed to RSR stakers. This process increases the redemption ratio of the staked RSR token (e.g. eusdRSR) relative to plain RSR. Learn more about [Yield DTF revenue handling](/core-components/yield-dtfs/protocol-operations#revenue-handling). **Index DTFs**: Mint fees are charged at issuance and TVL fees accrue continuously. Both are collected in the DTF token itself and routed to governance-selected recipients after a platform fee is applied.
How are DTF pegs maintained and what anti-bank run mechanisms are built in? DTF pegs are maintained through permissionless onchain minting and redemption, allowing anyone to arbitrage price discrepancies between the DTF token and its underlying collateral’s net asset value. Anti-bank run mechanisms include verifiable reserves, predictable recovery, overcollateralization, and proportional funds distribution, all of which are 100% onchain. **DTFs are not algorithmic (no recursive endogenous collateral)** DTFs do not have the recursive, negative feedback loops found in certain algorithmic stablecoins because DTFs are not minted from self-referential endogenous collateral. DTFs are 1:1 backed with exogenous assets with verifiable reserves onchain. **RSR overcollateralization for Yield DTFs** Yield DTFs can also employ RSR overcollateralization to promote peg protection. In the event that one of the exogenous assets in a Yield DTF basket drops by 10%, 20% or even 100%, the protocol would slash RSR stakers and sell the failing collateral to buy the pre-programmed emergency collateral basket. Briefly the DTF would be below peg, yet the 100% redemption outcome would be predictable and verifiable given the onchain overcollateralization. This mechanism was battle-tested during the Silicon Valley Bank run that played a role in the March 9, 2023 depeg of USDC — learn more about Yield DTFs’ autonomous self-healing. **Proportional distributions in catastrophic defaults** Should there be a case where Yield DTF collateral defaults and the RSR overcollateralization pool is spent with net collateral at < 100% of target price, the affected holders receive proportional distributions rather than first-come-first-served exits, eliminating bad debt without causing a hyperinflationary event.
How does DTF governance work? The governance process follows a transparent and democratic approach. Stakers and vote-lockers can propose, discuss, and vote on changes to the DTF(s) they're staked or vote-locked on. For Yield DTFs, Governor Anastasius is the protocol's recommended governor implementation. For Index DTFs, the Reserve Optimistic Governor provides a dual-path governance model. Standard proposals follow the traditional flow — proposal, voting delay, active voting, timelock queue, and execution — and are used for high-impact decisions like modifying fees or basket composition. Optimistic proposals skip affirmative voting entirely; once proposed, they enter a short veto window and execute automatically unless enough token holders vote Against to meet the veto threshold. If vetoed, the proposal automatically transitions into a standard proposal for full community deliberation. Only whitelisted actions can be proposed optimistically, and governance infrastructure changes are permanently blocked from the fast path. To participate in the governance of a specific DTF, go to the Reserve app. Select the DTF you wish to govern and select the Governance section. You will be able to view all the governance proposals that have been submitted for the DTF. If there is any active proposal, you can select it and vote for or against it.