Overview
Index DTFs: 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 Folios (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:
-
Measure the live basket. Current token proportions are calculated onchain.
-
Open auctions. Any surplus token is offered along a declining-price curve in exchange for a deficit token.
-
Clear via open markets. Solvers such as CoW Swap and direct DEX takers compete to fill orders, minimising slippage and MEV.
-
Settle and update weights. When auctions finish or time out, fills are processed and the basket’s composition is updated atomically.
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 | < 10% APY | Mint new DTF shares block-by-block |
| Mint | Incoming issuance | < 5% | 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.
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
- Proposals are created, voted on, and executed entirely onchain, with timelocks to ensure time to react.
- Basket changes can execute after a short delay, while other changes respect a longer review window.
- Every proposal, vote, and execution is permanently recorded on-chain, giving users, auditors, and regulators a transparent change history.
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.
As with any smart contract application, the actual behavior may vary from the intended behavior, and it's safest to wait for an application to be in use for a long period of time before trusting it to behave as expected. This overview and subsequent documentation describes the intended behavior.
Anyone can create an RToken
In a similar way as how anyone can create a new trading pair on Uniswap, anyone can permissionlessly create a new Reserve stablecoin (RToken) by interacting with Reserve Protocol’s smart contracts. The protocol applies a system of factory smart contracts that allows anyone to deploy their own smart contract instance.
Creating an RToken can be done either by interacting directly with the Reserve Protocol’s smart contracts or any user interface that gets built on top of it. The first user interface for these smart contracts will be released by ABC Labs the company that's leading protocol development. Besides the creation of RTokens, this user interface will also support exploring usage and stats related to RTokens, RToken minting & redeeming, and RSR staking.
Non-compatible ERC20 assets
The following types of ERC20s are not supported to be used directly in an RToken system. These tokens should be be wrapped into a compatible ERC20 token to be used within the protocol. A concrete example is the use of Static ATokens for Aave V2.
- Rebasing Tokens that return yields by increasing the balances of users
- Tokens that take a "fee" on transfer
- Tokens that do not expose the decimals() in their interface. Decimals should always be between 1 and 18.
- ERC777 tokens which could allow reentrancy attacks
- Tokens with multiple entry points (multiple addresses)
- Tokens with multiple entry points (multiple addresses)
- Tokens that do not adhere to the ERC20 standard in general
Advanced RToken parameters
When deploying an RToken, the deployer has the ability to configure many different advanced parameters. The following list goes into detail about what these parameters do and some of the factors the deployer should keep in mind to set them.
As many of these parameters concern the Protocol Operations, we advise reading through that section of the documentation first—as it will give the deployer the necessary context to fully understand all parameters.
Trading delay(s)
The trading delay defines how many seconds should pass after the basket has been changed before a trade can be opened.
A collateral asset can instantly default if one of the invariants of the underlying DeFi protocol breaks. If that would happen, and we would not apply a trading delay, the protocol would react instantly by opening an auction. This would give only auctionLength seconds for people to bid on the auction, making it very possible for the protocol to lose value due to slippage.
The trading delay parameter may only be needed in the early days - before we get to a point where there is a robust market of MEV searchers. We expect that this parameter can be set to zero later on (once a robust market of MEV searchers is established).
