DOCS

Index Protocol operations

The Reserve Index Protocol automates the entire life-cycle of Index DTFs with fully onchain, autonomous smart contracts. The sections below break down how the protocol handles minting, fees, and auctions.

Issuance & redemption

Index 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 Reserve app. Users can zap from a single token into a DTF, and vice versa.

See the Minting & Redeeming chapter for step-by-step instructions using the zapper, manual minting, or smart contract calls.

Fees & revenue

Index DTFs generate revenue through two primary fee mechanisms:

Fee type Basis Range Accrual method
TVL (management) Basket NAV < 10% APY Mint new DTF shares block-by-block
Mint Incoming issuance < 5% Mint additional shares on each mint

Both fees are collected and distributed in the form of the DTF token itself to one or multiple recipients, as determined by governance. Fee rates and recipients can always be adjusted through governance.

A platform fee is applied to both fees before they are distributed to recipients. The platform enforces a minimum fee of 15 bps, ensuring a baseline revenue stream. Currently, the platform fee is used to buy and burn RSR.

TVL fee

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

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

After the raw tvlFee and mintFee are collected, the platform fee determines how those shares are split between the platform and the DTF’s designated fee-recipients.

  • Progressive share – The platform keeps the percentages shown in the table below and forwards the remainder to recipients. The table rates apply slice-by-slice (tax-bracket style) to each TVL tranche.
  • Floor override – If the platform fee is less than 15 bps of TVL (tvlFee) or minted tokens (mintFee) in absolute terms, the contracts override the table and grant the 15 bps minimum instead.
TVL tranche Platform keeps Recipient share
< $100 m 50 % 50 %
$100 m – $1 b 40 % 60 %
$1 b – $10 b 30 % 70 %
$10 b – $100 b 20 % 80 %
$100 b – $1 T 10 % 90 %
> $1 T 5 % 95 %

Example calculations

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.

As a proportion of total TVL, the platform's portion of the TVL fee would be 33.5% * 1% = 33.5 bps, above the minimum fee floor.

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.

Practical implications for users

For governance stakers

  • Fee distribution to governance token holders follows an exponential distribution model over time to maintain vote-locking incentives at all times
  • 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
  • Ensure your integration accounts for both fees when estimating transaction outcomes

Rebalancing

Rebalancing assets is a core functionality of the protocol. This section summarizes the parameters, roles, and functions involved in each stage of the rebalancing process:

  1. Kick-off — A REBALANCE_MANAGER proposes new basket targets, per-asset buy/sell limits, and conservative low/high price brackets for each asset.
  2. Auction window — For every token pair that needs adjustment, an AUCTION_LAUNCHER (or any account after a 120 s grace period) calls openAuction, minting a sell lot sized so the basket always stays within those limits.
  3. Price curve — Each auction follows an exponential decay from startPrice to endPrice (both derived from the submitted brackets or tightened by the launcher). Curve length is governance-configurable.
  4. Settlement — Bidders supply the buy-asset and receive the sell-asset. When the lot clears or its time-to-live expires, the auction closes. The entire rebalance ends automatically at TTL or when the manager kicks off the next cycle.

This design lets an Index DTF migrate toward its target weights gracefully, using market pricing rather than oracle pushes, while preserving fully onchain execution.

Auction pricing

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.

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. Future app updates 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.