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 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.

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 - fee_per_second) ^ seconds_passed - 1

Where:

• fee_per_second is set by the DTF Owner (governance)
• seconds_passed 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 held tokens will gradually decrease relative to the underlying assets, reflecting the accrued fees

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

A platform fee is applied to both the TVL and Mint fees before they are distributed to 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.

Example Calculation

A DTF with $3.1 billion in TVL and a TVL fee of 1% would have its platform fee calculated as:

(0.5 * 0.01 * $100 million + 0.4 * 0.01 * $900 million + 0.3 * 0.01 * $2.1 billion) / (0.01 * $3.1 billion) ≈ 33.5%

This means 33.5% of the collected fees would go to the platform, and the remaining 66.5% would be distributed among fee recipients.

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:

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

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.

Contract addresses

Base Deployments (Chain ID: 8453)

Ethereum Deployments (Chain ID: 1)