Hey @LemonadeAlpha - totally appreciate your points and value your opinion greatly, but want to clarify a few points you made that I think are unfair or incorrect.
We launched DATA on Sushiswap because they were offering incentives via Onsen and Index Coop and Uniswap were not. We did not know what the incentives were until AFTER the product launched (we were never told by Sushi team pre-launch despite requesting this information multiple times). We had to make a judgement call and I thought having incentives was better than no incentives with greater capital efficiency (UNI-V3.), especially given that were putting our own capital at risk of impermanent loss, and given that IC provided no seed liquidity for DATA either.
To be clear - We are not in favor of launching an LM program for DATA on vanilla Sushi or UNI V2. If we were to do a program like this, we would want it to do it on something like Visor + UNI-V3 or Gelato + Sushi Trident.
This was true of both DPI and MVI before incentives were started.
Some of my response here will sound spicy, but I promise this is not my intention!
Firstly, I donât think AUM is the right metric. DATA is generating ~2.5x daily revenue of BED for Index Coop.
Secondly, for fairness sake, if we are doing these kind of analysis, we should be doing cohort analysis. BED has been around twice as long as DATA (launched 2 months before DATA on 7/21) and at the bottom of the bear market when BTC closed at $32k and ETH at ~$1.9k, so BED is getting a 2x in TVL vs DATA just off capital gains growth alone. DATA top holdings would have all benefited from similar gains if it had launched on same day (7/21); LINK was ~$15 (now $25), GRT was $0.56 (now $0.92), and FIL was $46.5 vs $53.5 now. BAT did a 3x over that time period and LPT a ~4.5x. Just from that very biased launched day, DATAâs TVL would likely be ~2x greater due to appreciation alone.
No disagreement here! Per this post, users can purchase $30k of BED vs. just $8k of DATA at 1% slippage. Would be more than happy to discuss moving DATA to a Visor + UNI V3 style liquidity solution for improved capital efficiency!
I will say I was pretty surprised the day of launch to see we werenât doing so on v3. I think a quick look at MVI vs BED liquidity profiles prior to launch would have shown you that v3 is at least 4-5x as capital efficient as the v2 architectures.
Fair point on the LM options presented, think those are definitely solid options but I will maintain that the choice at launch was a misstep which could have given you a better liquidity profile to start (ofc assuming the v3 pool could attract suitable liquidity)
This was true of both DPI and MVI before incentives were started.
This is true but there is no counterfactual while DATAâs is clear - Iâll take that back a bit, I will grant DPI before incentives is at least somewhat similar to DATA, but ICâs recent / current reach is a great improvement on that moment in time.
Youâre right that BED has appreciated more in price, but we have a measure called $NSF (net dollar flows) to account for inflows, BED is outperforming DATA on that metric at the same time in its lifecycle (contingent on verification of my belief $DATAâs has a bug on Dune).
RE: revenue, I think youâre absolutely right, but letâs not forget that BED had its fee beaten down by the madness of crowds, with many claiming outright disgust that we would charge a reasonable fee by all customer accounts. In addition, BED has much lower costs to maintain than other products.
In spite of that, BED is a vault for DPI which accrues revenue to IC, so I think its fair to say some of that revenue can be attributable.
It was not a decision taken lightly. We knew about 4-5x capital efficiency of UNI-V3 after research from @overanalyser , @jdcook , @verto0912 , and others when we made the decision.
Would we have decided to launch on UNI V3 if we had known how relatively small the Onsen incentives would be? Maybe. Still, given that all liquidity until the week of launch when Wintermute stepped in was being provided by Titans of Data and Index Coop community members, we did not want to put retail investors/supporters of DATA in the harms way of UNI-V3 impermanent loss (you really should not be doing this unless you are a professional market maker or a automated solution like Visor). Impermanent loss on UNI-V3 is a FAR greater risk for a product like MVI/DPI/DATA than BED (this was the best research we had at the time).
I still maintain no misstep was taken given the knowledge we had at the time. Obviously, we know more and can do more now. We worked within the constaints we had and in hindsight might do things a bit differently given the knowledge we have now.
Worth noting a Uniswap V2 / Sushiswap transaction has done increased 25x from October 2020 to ~$150 now. Small buys of DPI were very feasible then; small buys of DATA not until we launched on Polygon several days ago.
Yes, there is definitely a bug in Dune for the DATA $NSF charts and your counterpoint is definitely correct. BED definitely outperformed DATA in both users and $NSF in a cohort analysis of first 2 months - no doubt about it.
Iâm fine with saying another product outperformed DATA in various dimensions - I just want to make sure weâre making reasonable analyses in our comparisons, and I donât think comparing a 4 month old product on UNI-V3 to a 2 month old product on Sushi is an accurate representation of much of anything.
I guess my point would be that the growth of BED organically has been solid and a counterpoint to the idea that incentives are necessary to achieve a critical mass of users post launch
I also just think its worth noting that BED is the only composite index that hasnât received nor requested incentives.
A bit unrelated but I am also wondering why DATA is being considered for something like this while BED is not and I suspect will not be - revenue would be a pretty good answer, I concede
I would support moving DATA to a PCL pool on v3 - and your points are fair around user safety - and trialing some kind of small incentive program (would be happy to share why Iâm hyped about single-sided staking!), but I do think there is something lost by separating the incentive program and the launch hype.
I donât think itâs necessary. I do think it helps achieve this:
Of course it comes at a significant financial cost. Iâm not totally convinced that itâs worth the cost vs. just âslowâ organic growth over time (is 60% MoM address growth slow?!) and I donât think @DocHabanero is either which is why he wants to run an experiment?
Not true - Titans of Data has never requested LM incentives from Index Coop for DATA. They were offered/suggested in this post without us asking for them. This post was my first time hearing about possibility of INDEX LM incentives since post-launch.
Thatâs a good question. I honestly have no idea. @DocHabanero?
Agree - wish we could go back in time and change this. That being said, we (Titans of Data), are planning a â2nd launchâ (stay tuned!) with a video that we could strategically time simultaneously.
I had no part in this decision. Based on our analyses, we believe index products that have a 10 bps mint/ 20 bps redeem fee with a 50 bps streaming fee (this could be even lower for BED) would generate ~50% more revenue and allow us to further lower streaming fees for users by generating revenue from arbitrageurs. DATA passed DG2 with this condition, but launched with standard 95 bps streaming fee due to engineering constaints. Weâre still waiting to hear when this can/will be prioritized by IC.
If I recall correctly, the idea to do 10 bps mint / 20 bps redeem may have originally been your idea or you at least inspired me.
To your point about about product-market fit. This needs to be a better exercise in the product onboarding process. We should feel confident that all of our products at least of a chance at good product market fit. I think this program helps identify that early. As an example, if we expect most products to reach XAUM/X# of wallets/etc in a certain time frame, but a specific product doesnât reach that, then we remove incentives and think about removing the product.
We really just didnât want to go too far back, and BED has had relatively good traction. If you feel BED should be included we can include the forth product but that ultimately has to be decided by the community.