Simple & Leverage Index Engineering Capacity Expanded

1

Two months ago we shared some realities regarding the engineering constraints for new product launches at the Index Coop.

After a couple months and focused effort by Set Labs engineers, we are no longer engineering constrained in launching simple & leverage indices.

As a refresher, Simple Indices (like DPI, MVI, BED) generally:

  • Rebalance using DEXs (Uniswap V2/V3, Sushiswap, Kyber, Balancer)
  • Do not include rebasing tokens
  • Do not include wrapping or staking functionality
  • Do not include mint/redeem fees

And Leverage Indices (like ETH2x-FLI, BTC2x-FLI):

  • Rebalance using DEXs (Uniswap V2/V3, Sushiswap)
  • Post & draw collateral available on Compound protocol

What does this mean for the Coop?

  • We can now safely launch and operate new simple index & leverage index products, as well as improve existing ones
  • We have successfully improved the safety of our existing product base, namely the FLI suite

TLDR; on what was built

Scaling Product Safety & Product Maintenance

Set Labs have put together a Technical Operations dashboard to simplify & increase the safety of the rebalance parameterization process for Simple Index products. Historically, Set have been responsible for parameterizing & monitoring product rebalances. This is because the manual rebalance parameterization process is sensitive & must be done with zero user errors. The Technical Operations dashboard reduces the sensitivity of the process by including various safety/correctness checks & allows Set’s day-to-day involvement in product rebalances to be greatly reduced.

1600Ă—953 154 KB

Screenshot of Technical Operations UI for DPI Rebalancing

Set has also made many improvements to the Leverage Index smart contracts & related keeper systems to greatly increase the reliability of the deleveraging system during periods of high volatility. Previously, managing multiple leverage products during periods of massive market volatility was untenable. We now have much higher confidence that our smart contracts & keepers will be robust should we experience another sharp market downturn.

New releases in these product lines will require relatively little new smart contract work, and operational overhead for their maintenance has been reduced. The rule of thumb is if a new product’s maintenance looks very similar to an existing Index Coop product, engineering can likely launch it at relatively low cost.

Technical Operations Hand Off

Much of the Simple Index product rebalancing system has been abstracted, and made safer via the Technical Operations dashboard. Maintenance & control of the Technical Operations dashboard will be the responsibility of the Coop, and the hand off to EWG is being prepared.

The keeper system that Set Labs operates to monitor ETH2x-FLI & BTC2x-FLI leverage ratios will eventually need to be handed off to the Index Coop as well. Currently the Index Coop EWG does not have the bandwidth & expertise to pick these up.

Engineering Autonomy

Engineering autonomy has been established as a major long-term goal for the Index Coop & specifically the mandate for the EWG. However, getting to complete engineering autonomy where the Index Coop can design, implement, test & deploy its own novel financial products end-to-end will be a gradual process.

We are still in the very early days of this at the Coop but progress is being made and we’re getting the right pieces in place to build a proper foundation for engineering:

In the meantime, Set Labs involvement will continue to be required to launch new Index Coop products, & some coupling with Set Labs’ roadmap is to be expected.

One known area for improvement here is for the Set Engineering team to more proactively communicate what is being worked on as it relates to Index Coop products. You can expect more here soon as we work to improve our own internal operations in order to make this happen.

12 Likes
2

Hey @dylan - this is amazing news! @Kiba and I are so excited to launch DATA so it’s a relief to hear that Engineering is no longer a constraint for simple indices in such a short period of time. Thank you @dylan , Set Labs, and EWG for your great work and for sharing an update in this forum post. :pray:

Now, a question!

After conversations with you, @oneski22 , and @Kiba and reading through this past forum post and subsequent comments here, here, and here , Titans of Data did some research and believes that changing the fee structure from standard 95 bps to 50 bps (streaming), 10 bps (mint) and 20 bps (redeem) will increase revenue for DATA by ~50% without sacrificing TVL or growth. See our analysis.

There was some confusion in the Work Team Analysis Discord channel for DATA about the difficulty of implementing these changes for simple index products.

image
image1033Ă—219 29.5 KB

Could you provide context on feasibility?

Tagging @puniaviision as he had thought discussing engineering requirements for DATA before the methodologist compensation negotiations took place was premature, but I think those will take longer than we had initially anticipated after receiving community feedback.

1 Like
3

For context, the balance we are trying to figure in the PWG is how much engineering resources we actually want to devote to speccing out products prior to the community actually approving the product to be launched by the Coop via a DG2 vote.

@overanalyser and @catjam are working on drafting clear guidelines, but as of now we will be keeping deep engineering involvement as minimal as possible pre-DG2. It would be a waste to spend scarce engineering resources on a product the community has not yet approved.

Given that, the high-level feedback we have gotten from the engineering team on mint and redeem fees is that they require significant changes up and down the stack for simple indices and will result in 2 additional weeks of product and engineering work to fit them for DATA

I don’t have context on what does specific changes up and down the stack are, and I don’t want to bring in engineering resources to provide that context at this point.

Given the product passes DG2, we can engage in deeper negotiations between the PWG and Titans of Data on how we want to think about feature scope vs. timeline vs. resources.

4 Likes
4

@puniaviision This is great feedback and completely reasonable. Something that’s been confusing to me during the Product Onboarding Process is that the Work Team Analysis Prioritization Process happens before DG2, but gives significant consideration to Technical and Financial Costs which may influence the MVP product proposed by a Methodologist.

This is the primary reason the DATA team has requested multiple Work Team Analyses. It’s not because we want to spin PWG or EWG wheels and waste time or resources, it’s so that we can bring DG1 and DG2 proposals that reflect costs to the Index Coop. In my view, this is especially important because those considerations influence whether a governance vote will pass or not.

When I worked at a FinTech startup, as a Data Science Manager I would be interacting closely with Product Management and Data Engineering, making trade-offs with leads from various teams, while building an MVP. In our case, I think the Methodologist is the Product Designer/Manager, but they are (unintentionally) excluded from internal Coop considerations that influence how they may design a product and create a go-to-market / launch plan.

@dylan @puniaviision @Kiba The change to the streaming fee from the standard 95 bps to 50 bps (streaming), 10 bps (mint) and 20 bps (redeem) is something Titans of Data would like included for launch and 2 weeks is a reasonable amount of time to delay, especially given that the other work before launch can be done in parallel with the Engineering work. Yes, it requires engineering work (an extremely scarce resource!), but it will benefit all simple index products after DATA that want a different fee model, so it’s not like it will only benefit DATA.

3 Likes
5

This is good data. Forwarding it to Meg and OA who are currently restructuring the process. Maybe you’re right and we do need more strict engineering resources devoted to DG1 → DG2 move.

2 Likes
6

Just confirming (in the interest of over communication and continual improvement!) that @puniaviision forwarded, we’re thinking through it… great feedback!

To your point about how things worked differently at your FinTech startup, we could benefit from more clearly defining roles/expectations for methodologists & product throughout this process, in addition to the “process stuff” (when to bring eng in, etc.)

4 Likes