Index DTFs
The Reserve Index Protocol is a permissionless platform that enables the creation of onchain tokenized-asset indexes called DTFs (Decentralized Token Folios).
Core Features
A DTF is a tokenized basket of assets. The number of tokens that compose a DTF basket can range from one to hundreds, with the limiting factor being the compute available to a single transaction. This looks like:
- 100s on Base
- 10s on Mainnet
- 18 on Solana
Basket composition and parameters can be modified by governance. Trading and rebalancing of a DTF basket takes place through onchain Dutch Auctions.
Pricing
The Price of a DTF is based on a NAV calculation.
Given DTF with a basket of n
tokens, each with a spot price p
, we can calculate the price as:
NAV = SUM(token_i * p_i)
Minting & Redeeming
DTFs are always instantly mintable with and redeemable for a pro-rata share of their underlying assets.
In order to make life easier for users, ABC Labs provides use of a Zapper via the Register UI. Users can zap from a single token into a DTF, and vice a versa.
When minting, due to the volatile nature of DEX’s and the way the Zapper routes the input token through DeFi and into the DTF, it is common to receive dust amounts of certain tokens. Generally, the amount of dust is on the order of 1-10bps of the input value.
Roles
A Folio has 4 roles, 3 of which have abilities that affect the operation of the DTF itself:
1. 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 DTFGovernor.sol
and TimelockController.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
2. Auction Approver
The Auction Approver is responsible for configuring auctions for execution.
Expected Actor
The same DAO that acts as the Admin should also take on the role of Auction Approver, and the default deployment configuration in Register is exactly this.
However, having the Auction Approver 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 DTFBuy Token
: the token to be bought by the DTFExpected Volatility
: the amount of price movement that is expected in theSell Token
:Buy Token
pairing. The Auction Approver can select between 3 options: Low, Medium, and High. These options will configure pricing parameters for the auction based on the following calculation:- INSERT CALCULATION HERE
Time To Live
: 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-configuredAuction Delay
if the auction is intended to be permissionlessly available.
3. 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 Auction Approver, 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
4. 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
5. Guardian
The Guardian is responsible for vetoing malicious governance proposals.
Expected Actor
A trusted multisig or EOA that is ready and willing to act quickly to prevent malicious governance proposals from being executed.
Abilities
- Veto governance proposals
Fees & Revenue
Index DTFs generate revenue via two separate fees - a TVL Fee and a Mint Fee. Both fees are collected and distributed in the form of the DTF token itself, to one or multiple recipients, as determined by governance
TVL Fee
The TVL fee (expressed as a % of the DTF’s TVL) is calculated and accounted for on every user interaction.
Mint Fee
The Mint Fee (expressed as a % of the mint amount) is taken every time someone mints the DTF.
Platform Fee
A platform fee is applied to the DTF’s TVL and Mint fees before they gets split up among the recipients. This platform fee is defaulted to 50%, but can be set per-DTF, and is recalculated and manually adjusted on a monthly basis, based on the following progressive fee schedule table.
TVL | Platform Fee |
---|---|
TVL < $100m | 50% |
$100m < TVL < $1b | 40% |
$1b < TVL < $10b | 30% |
$10b < TVL < $100b | 20% |
$100b < TVL < $1T | 10% |
$1T < TVL | 5% |
For example, a DTF with $3.1b in TVL would have a net platform fee of (0.5 * 100e6 + 0.4 * 1e9 + 0.3 * 2e9) / 3.1e9 ~= 33.9% .
The other following parameters apply to all Index DTFs:
- 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%
Governance Revenue
Revenue is directed to governance token stakers by default, but can also be shared to addresses holding other roles and/or any number of arbitrary addresses.
The revenue received by the governance stakers is claimable over time on an exponential decay curve. Unstaking one’s governance tokens initiates a withdrawal period (set by governance) during which no more revenue can be claimed.
Auctions
Any alteration of a DTF’s basket is done via a two-token dutch auction. Each auction is configured with parameters to define which tokens are to be traded, the pricing curve of the auction that will handle 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 Register as the Auction Launcher, the EV presets can again be used to set the final pricing curve and target ratios. Future updates to Register will allow more advanced users to tweak these parameters directly.
Auction Timing
One final parameter that gets set by the Auction Approver is time-to-live (TTL). This parameter defines how long an 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 DTF parameter Auction Delay. The AD 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.
If TTL is set longer than AD then the auction will realize a period during which the auction can be launched permissionlessly, adding to the DTF’s decentralization. If TTL is set at or below AD, 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.
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).