Product (DG) Template
This is the template for new Product (DG) IIPs. Note that an IIP number will be assigned by a GovRep.
IIP: [to be assigned] Status: [Discussion -> Proposed] Author(s): [a list of author(s) names, usernames] Discussions-to: [Create a new thread on https://gov.indexcoop.com/ and drop the link here] Created: [date created on MM-DD-YYYY] Quorum: [10% of Votable Supply]
Provide a brief (2-3 paragraph) description of the proposed product. The first 1-2 sentences should be a simple summary for a lay reader. Specify if the proposal is seeking approval for one product or a suite.
List the target customer segments in descending priority, for example, defi-native, tradfi-convert, DAO treasuries. Give a user story for each segment, eg, ‘As a defi-native investor, product ABC gives me …’
Describe the market survey results or any other hard evidence of market demand. For market survey results, give the method, date, sample size, margin of error, comparison to other products in the survey, and any potential sources of bias. References to general market trends are not sufficient market validation.
Give the predicted AUM, for example, at 6, 12, and 24 months post-launch. This can be based on the past performance of similar product launches. Also describe any limits to growth such as low underlying liquidity.
The purpose of this section is to give an approximate forecast of what the product AUM will be and not to give the total addressable market. Accordingly, do not use top-down market assessments. For example, do not say the derivatives market is $100B and we plan to capture 1% of that market for a $1B AUM.
Describe how this product is different from other products on the market and/or under development at Index Coop.
Describe the role that branding partners or distribution channels will play.
Describe the most likely reasons the product will fail to live up to its potential, for example, the concept is too early for the market, strong competition, insufficient liquidity mining incentives, etc.
Give the streaming fee, mint/redeem fee and any other revenue sources. List any commitments to provide transparency on product costs and asset decay.
List any agreed or potential fee splits, eg, to branding partners. All fee splits will be post gas costs.
Describe the expected monthly revenue, monthly costs (eg from rebalancing), profit margin, and any assumptions. All products should have >70% gross profit margin (excluding liquidity mining incentives) at launch.
Give at least a 2-year financial forecast for the profit margin and cash flow. Naturally this will involve many assumptions, which is okay if they are reasonable. The purpose of the forecast is to confirm that the product team has fully thought through the product profitability rather than to provide a fully accurate forecast.
Describe how the product will be built.
Give a brief summary of the engineering lift required and any novel adaptors or integrations required. Specify the lift and new requirements for both pre-launch and post-launch.
Describe on which chain/s the token will be natively deployed and bridged to. For example, ‘deployed natively on mainnet and bridged to Polygon and Arbitrum.’
Token inclusion / exclusion criteria, for example, minimum market cap and liquidity.
Formula for calculating the index weights, for example, market cap and liquidity weighted. Specify any allocation caps. Note that using multiple allocation caps can be very expensive on mainnet.
For products on mainnet, we recommend no rebalancing. If rebalancing is essential for the product strategy describe the rebalancing approach including frequency. Note that rebalancing is very gas expensive on mainnet and decays the underlying assets.
Criteria for adding and removing tokens from the index. Note that recomposition is very gas expensive on mainnet and decays the underlying assets through slippage. We aim for <5% asset decay/year maximum.
Describe intrinsic productivity, if any
Describe governance model, if any.
Give a table of the underlying composition including the weights, market cap, underlying liquidity, dex’s and overallocation factor for each component (if applicable). The liquidity should be defined as the trading depth at 100 bps including the LP fee. The overallocation factor is the ratio between the component allocation for a $1M AUM and the trading depth at 100 bps.
- For general indices, this will consider:
- The price impact on each underlying token for a $1 M exchange issuance / arb trade.
- Number of trades (with price impact < 50 bp / 0.005%) to add / remove the token from the fund at $10,000,000.
- Trades should be on a single pool on L1 using Uniswap v2, Uniswap v3, Sushiswap or Balancer.
- For leveraged indices, this will consider:
- Size of a trade (dollar and asset value) that will incur a 1% transaction cost on each available DEX. Transaction cost includes fees and price impact.
- Size of available liquidity on pairs used for rebalance transactions & number of hops required to rebalance if using more than one pair
- Highlight the smallest amount of liquidity of any pair used for rebalancing. This is the weakest point in the rebalance process and can be used to stress test the product.
Give backtest results, preferably covering a market upcycle and downcycle. Compare to ETH or the most relevant comparator.
Specify whether the product will be launching on a dex or exchange issuance and why.
For a dex launch, specify the LP pair (XXX:ETH) and dex (SushiSwap, Uiniswap v3 etc) for the initial liquidity. Discuss whether the liquidity is expected to be self-sustaining (e.g. highly traded FLI products) or need ongoing liquidity mining incentives.
List the authors and their roles.