Set Engineering Update

Set Engineering Update

Hey all,

The autonomy group is currently working on a comprehensive plan to address everything from leadership and treasury to autonomous engineering and product organizations. We’d like to simultaneously create bottom up awareness around the tasks Set is working on that the product and engineering working groups will need to incorporate to effectively prioritize their roadmaps. We hope this series also provides guidance on activities that the Index Coop will need to take on, hires the Index Coop will need to make, and external relationships required to build and manage product.

Current Ongoing Initiatives

Feature Description Status
Rebalancing Preparation Process upcoming rebalance weights, analyze liquidity profiles for existing tokens, determine whether any new smart contracts need to be written to access liquidity for a new or existing token. Under review by Set and PWG (more below under Rebalancing Preparation)
Aave Leverage Module SC Enables SetToken contracts to create a leverage position via Aave Continuing smart contract auditing process (more below under Auditing Smart Contracts)
Debt Issuance Module Upgrade SC Enables end users to issue and redeem a Set with an Aave Debt Position. Aave borrowing positions are not compatible with the DebtIssuanceModule written for the Compound Leverage Module due to the way Aave processes interest. Under development by Set team. This is a sensitive smart contract that will require external audits.
Methodologist Permissioning SC Upgrade existing Base Manager smart contract with updated specifications based on IIP-64 Pending conversations between the PWG and current Index Coop methodologists.
Polygon Infrastructure Continued Continued bolstering Polygon infrastructure and testing reliability of keeper systems Under development by Set

Rebalancing Preparation
The last week of the month can be a black box that is challenging to plan around. Historically, methodologists have reached out with next month’s rebalance weights. The process is being inherited by the PWG, h/t @overanalyser. This kicks off several requirements:

  • Assessing Liquidity: understanding how liquidity profiles have shifted for each of the tokens in the Sets and determining the rebalance parameters. If liquidity has moved elsewhere, Set needs to write new smart contracts (e.g. UNI moving to Uniswap V3)
  • Token Additions New Contracts: when new token additions are included, Set must assess if the current infrastructure can support them. If not, Set needs to add contracts (e.g. Uniswap with Trade Hopping for Badger)
  • Token Migration New Contracts: when an underlying token has been migrated to a new version, Set needs to add new adapters to account for their unique migration functions (e.g. Axie Infinity, Kyber Network, and Lend)
  • Update External Dependencies: external dependencies such as Chainlink need to be pinged in order to alert them of any new DPI additions. This will be a requirement for any products that the Index Coop wants to get listed on lending protocols depending on the oracles they use.

These requirements will compound as more products are released. The scenario is different each month and there is no process that fits all. The Coop may decide that this current flow of information does not provide its product and engineering group enough time to meet methodology requirements. An example of this was when Set was unable to add Badger to DPI due to a missing adapter and not enough resources and the addition occurred the next month. We will continue working with the PWG and EWG to create awareness around all of the processes and relationships that go into rebalances.

Auditing Smart Contracts
Smart contract audits are great sources of redundancy in maintaining product safety and minimizing unexpected programmatic behaviors, though they can be difficult to obtain due to rising costs and decreasing availability. The process is often summarized succinctly in the form of public facing reports that detail the auditor’s findings, but behind the scenes, an audit requires continuous bi-lateral communication.

The auditors first need to gain an understanding of what we think our code should be doing, then review and test it very thoroughly, before sharing their initial findings. From there, we study their work and clarify their assumptions as necessary until we reach a common understanding on any issues, critical or otherwise, that need to be addressed. Once this is established, we submit the updated code changes as necessary for a re-review. We repeat this until both parties are satisfied.

This process is equally important to both counterparties. Product safety is a core pillar for Set. Meanwhile, auditors must be careful about who they engage with. They are passionate about their work, especially when they have to put their names on it. For Set in particular, audits can range anywhere from 2-6 weeks. This is a function of complexity as Set’s smart contracts do not form a closed system like most other protocols. This requires auditors to also have deep understanding about other protocols that our contracts call such as Uniswap, Aave, and Compound.

An immediate challenge for the Coop will be to begin thinking about budgeting of auditor relationship building, planning, execution time, and costs that go into external audits. Set will make the proper introductions to previous auditors that we have worked with in the past to kick start this process.

Going Forward
As part of the ongoing autonomy effort, Set is continuing thinking about the communication path of technical information and decisions and we will continue to create more awareness for the relevant groups, more on this to come.


Thank you for the sharing the update, @asoong - please keep them coming!

Just wanting to flag here that Titans of Data has seen liquidity migrate and fragment from UNI-V2 to UNI-V3 for many tokens in the DATA index, and that a lot of the current liquidity exists on Balancer V1. For instance, on August 21, ~$5m in liquidity for BAT moved from UNI-V2 to UNI-V3. Based on present conditions, this should not be a major issue for rebalances, which for DATA will be done quarterly, given that the rebalancing process supports UNI-V2, UNI-V3, Sushi, Balancer, etc.

However, I am quite concerned about the ability to onboard capital to DATA through exchange issuance post-launch. I’ve been informed by EWG that exchange issuance only supports UNI-V2 and SUSHI. I’ve estimated that the price impact (inclusive of LP fees) for a $250k mint of DATA will be ~2.4% without support for UNI-V3 and Balancer vs ~0.9% with support for those DEXes.

Not having clarity on which DEXes are supported by exchange issuance and rebalancing also prevents Titans of Data from being able to communicate to our current and potential partners, like Consensys and Filecoin, which DEX(es) they should direct their liquidity to further minimize price impact to ease capital onboarding to DATA.

cc: @ncitron, @Cavalier_Eth, @puniaviision @Kiba @oneski22