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 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 Auction Approver can select between 3 options: Low, Medium, and High.
- 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-configured Auction 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).