IIP-73: FLI Economic Model Upgrade - Past Gas Costs

status: Proposed
author: Matthew Graham (@Matthew_Graham)
created: 2021-08-12

Simple Summary

To date gas costs for maintaining the FLI product have been borne by Index Coop and it’s service providers. This IIP proposes reimbursing gas costs incurred up until the time when future gas costs borne by FLI product holders be reimbursed with COMP tokens from each respective product’s TokenSet vault.


To date, Index Coop and its service providers have spent $146K in gas on ETH2x-FLI and for BTC2x-FLI is not shown on Dune analytics. Having already proposed in a separate discussion transferring future gas costs from Index Coop to FLI holders, in line with all industry standards, this proposal seeks to reimburse Index Coop for gas costs incurred up until when future gas costs borne by FLI product holders.

To date, the FLI products have generated around $500K in COMP tokens, which are now sitting unused in the bothe ETH2x-FLI & BTC2x-FLI contracts. I proposed Index Coop’s gas costs up until the time when future gas costs borne by FLI product holders be reimbursed with COMP tokens from each respective product’s TokenSet vault.

This $500K was generated over the same period as the $146K gas fees were paid, which should give the Coop ample runway to reimburse those gas costs, until the full feature is built out.


The on-chain maintenance costs of the FLI products should have always been borne by the FLI product holder. To date Index Coop has borne these costs and now, we have an opportunity to recover past costs by transferring COMP tokens that have been accumulating within the FLI product to Index Coop.

Upon implementing the upgrade as detailed in IIP-XY: FLI Economic Model Upgrade - Future Gas Costs, all past gas costs amounting to around $146K at time of writing are to be reimbursed with COMP tokens.

All future COMP token allocations and liquidity rewards which are expected to continue being accrued for the next 3 years are to be discussed in a separate forum post as this will form part of a broader fee split discussion. This separate and future conversation will address the developer lift for improving the FLI product technically since launch. There exists the potential to use the COMP rewards to pay for this upgrade should Set Protocol not have the bandwidth to provide the engineering resources.


Index Coop’s gas costs up until the time when future gas costs borne by FLI product holders are reimbursed with COMP tokens from each respective product’s TokenSet vault, ETH2x-FLI & BTC2x-FLI. The COMP tokens are to be transferred to the Index Coop Treasury.



Upon upgrading the FLI contracts, past gas costs incurred by Index Coop are to be reimbursed by transferring the equivalent USD value in COMP tokens from ETH2x-FLI & BTC2x-FLI to the Index Coop treasury.


DO NOT perform any upgrade to the FLI contracts.


Copyright and related rights waived via CC0.


Hey @Matthew_Graham - I appreciate the creative thinking here! I think this is an obvious opportunity for us as a community to upgrade the FLI products and improve their performance and profitability.

The original design for COMP rewards was to use them to offset the negative effects of volatility decay for token holders. This would be accomplished by swapping COMP for ETH (or wBTC) and depositing those new tokens to the product’s collateral balance, thus increasing total AUM and chipping away at the inevitable, harmful effects of vol decay. However, this capability has yet to be fully developed so both ETH2x-FLI and BTC2x-FLI have idle COMP balances as you’ve noted, and I do think that the community should decide on how we handle these protocol rewards.

We’re working with the AWG currently to try and measure the $ impact of volatility decay for both ETH2x-FLI and BTC2x-FLI so that we can determine how effective current COMP balances would be at offsetting vol decay. Once we have this data, I think we can make more informed decisions about whether or not this is a viable strategy!

I personally like the idea of liquidating COMP rewards to offset vol decay and then sending any remaining COMP to the community treasury to offset rebalancing costs, but we’ll need more data to know if this is an effective alternative or not.

Thank you for getting this conversation started!


Hi @allan.g,

This is a fantastic idea. :slight_smile:

Cycling COMP into the product is forward looking right. I’ve left the door open for future rewards.

What we do know is we have no efficient way to distribute COMP rewards retrospectively to compensate past users who have since sold there FLI tokens.

We therefore can look at the accumulate COMP rewards differently to future COMP rewards.

The FLI product offering has a heavy lift during the early stages of its life. The LM rewards on COMP are for 3 years. That’s a run way to cover the front loading burden of the product range. This means we can recover costs via the LM rewards whilst we improve the product.

Do we roughly know the % of vol decay?
What this will tell us is how much of the future LM rewards we can extract to support on going developer costs.

Most of Index Coops contributor rewards are for DPI, not FLI products. So FLI’s contributor costs are less than simple Index products. When we start doing contributor rewards per product offered, we will have data to confirm my suspicions. This excludes developer costs of course. There a completely different kettle of fish.


@Matthew_Graham Fully in favor of retroactive reimbursement of gas costs to Index Coop and Set Labs using idle COMP rewards.

@allan.g Offsetting the negative effects of volatility decay for tokenholders is a great idea for future changes to the product. Would be keen to see a detailed proposal and IIP. Regardless of the merit of the idea, I don’t think that should prevent us from acting quickly to retroactively reimburse past gas costs from FLI products to Index Coop and Set Labs.

Thank you @Matthew_Graham for your creativity and bias for action!

1 Like

Fair point - seems like my comment belongs within the Future Gas Costs proposal!

We don’t have an exact % yet for vol decay but we are trying to get there. Will include updated intel in the Future Gas Costs post.


Hi @gregdocter, @Pepperoni_Joe

May I please have an IIP Number assigned, a discord discussion channel created and a Snapshot vote scheduled for Monday 16th August 2021.

Thank you in advance.

Totally makes sense!

1 Like

Hi @Matthew_Graham - before this progresses to IIP I would like to get input from the Product and Engineering teams cc @puniaviision, @overanalyser, @afromac and @dylan.

1 Like

Will discuss with team and reply asap.

1 Like

Thanks for this post @Matthew_Graham. This is definitely a step in the right direction for the Coop.

I’d like to provide some clarity on the engineering work required to implement this feature. I will only be describing the work required to claim the accrued COMP and distribute 100% of it to the community treasury. Splitting it between DFP, the treasury, and FLI holders is a much more complicated task and a discussion for the future.

This feature requires writing one new extension contract for the FLI manager contracts. Fortunately Set has built two modules that can help out, ClaimModule and AirdropModule. The ClaimModule would be used to call the claim function on Compound’s Comptroller and send the proceeds to the FLI token. AirdropModule's original intent was to be used to add an airdropped token to become a valid component of a set token but introduces an optional manager fee which we can set to 100% which will allow us to sweep all of the COMP to our treasury.

The above may sound a bit complicated, but it’s actually not that bad. I am fully confident that we can build this feature mostly in-house.

EDIT: looks like anyone can call claimComp for any address so we don’t even need to use the ClaimModule. This makes it a bit easier.


@ncitron thank you for providing the technical insight here. It is very welcomed and appreciated.

To clarify - can we recover a portion of the COMP rewards or does it need to be 100% ?
Kind of sounds like 100% needs to be distributed and can only be distributed to a single entity, ie:Treasury in this instance.

100% would be easiest, but the design space is actually pretty open here. For example, we can have the fee recipient be a splitter contract which then splits the revenue between any number of entities. Additionally, we can have it only charge a X% fee to the treasury and then reinvest the remaining COMP back into the FLI product.


Nice :slight_smile: I seen this functionality in the way it was written but wanted to clarify.

@afromac - what are your thoughts on claiming a % of the COMP rewards? I think we can proceed to vote to recover a % of the COMP rewards recovering sunk gas costs. Let me know a number and I’ll amend the post. :slight_smile:

Hi @Pepperoni_Joe,
May we progress to snapshot starting Monday 23rd August ?

Hi Matt

We have been considering this proposal for several days now so thanks for your patience. The suggestion from the PWG is to put a hold on this idea for now and revisit it at a later date.

Currently, there are a number of important ongoing discussions relating to both these products and wider strategy within the Coop. All of these conversations are both time sensitive and extremely high stakes. In this context, we see this proposal as neither time sensitive nor high stakes. Moreso, it is unclear if this is even the best use of these rewards. Further investigation and discussion of this idea is merited - at the very least.

We would be happy to return to this discussion later, when the community has had adequate time to consider the more options, and when greater consensus has been reached on this and a number of other issues.


Great idea. Thank you for the feedback and sharing it on the forum.

1 Like

Hi @afromac,

A month has past since this IIP was placed on hold. Any chance you can share the results of the further investigation mentioned in the previous comment?

1 Like

Hi @sixtykeys and @mel.eth,

Can we please move IIP-73 to snapshot with voting starting later today 27th September.

Thanks in advance.

Hey @Matthew_Graham, this proposal is still in the ‘draft’ stage, and can only go live 48 hours after the status has been changed to ‘proposed’ as per IIP-26.

1 Like

@Matthew_Graham noting that I’ve changed the status to ‘Proposed’ per your recent request that this go to vote; the soonest this can go to snapshot would be September 29, but I would recommend that it be queued for Monday October 4 so that it runs during weekdays. Please reply with your preference. Flagging @overanalyser, @afromac, @dylan, and @puniaviision per @Pepperoni_Joe’s request above for PWG and EWG input. cc: @sixtykeys