[Closed] AYF-001 Whitelisting of Delphi smart contracts for the gauge weight lock on Curve.fi to enable increased CRV rewards for everyone (boost)

Title of Feature: Whitelisting of Delphi smart contracts for the gauge weight lock on Curve.fi to enable increased CRV rewards for everyone (boost)

Author(s) Names: The Liquidator

TLDR Summary:

  • The idea is to whitelist the Delphi smart contracts for the gauge weight lock on Curve.fi (https://dao.curve.fi/gaugeweight).
  • This would basically be similar to what yearn has already done (corresponding on-chain vote on curve: https://dao.curve.fi/vote/ownership/2).
  • This would enable the ability to lock a part of the rewarded CRV and Boost the CRV rewards for all people who are in the curve delphi pools (so would be in the interest of many people I guess).
  • It would also provide the Delphi community with voting rights within the curve DAO, we could potentially take part in the weekly gauge weight votes (https://dao.curve.fi/gaugeweight) to increase the CRV distribution to the pools where Delphi funds are allocated
  • There are two options to implement this (see technical discussion)

Technical discussion:

There are basically two options to implement this, one is easier to implement, the other offers higher rewards for everyone:

Option 1)

Currently, each Delphi curve pool has its own smart contract (please correct if there is a mistake):
a. BUSD (0x91d7b9a8d2314110D4018C88dBFDCF5E2ba4772E)
b. yPool (0x7967adA2A32A633d5C055e2e075A83023B632B4e)
c. sUSD (0x91d7b9a8d2314110D4018C88dBFDCF5E2ba4772E)
d. renBTC? (0x020439688aA784Baa55DfEDB4732E8229aC8Fb1b)

These would count as individual “wallets” within the curve system, so each of them would need to lock their own CRV tokens, to receive voting power on curve.fi and a boost of up to 2.5x for the CRV rewards.

One thing to keep in mind though, if you vote-lock your CRV in Curve (https://dao.curve.fi/locker) you will receive an equivalent number of voting-escrowed CRV (veCRV), which you can use to vote in the Curve DAO. This veCRV also applies a boost to all Curve pools (up to a maximum of 2.5x CRV rewards), though the boost number is dependent on the actual liquidity you provide and the overall pool liquidity (e.g. curve ypool is much larger, so it is easier to achieve the full 2.5x boost reward with less locked veCRV).

Each of the Delphi contracts (BUSD, yPool, sUSD, renBTC) would need to lock their own Curve to receive veCRV and each others veCRV would not count towards the “CRV boost” of the other smart contracts.

Benefit of option 1: easier to implement (Delphi contracts don’t need to be adjusted as much as with option 2.

Disadvantages of option 1: locked CRV would only count towards the individual pool where it came from (no combined boosting of all other Delphi pools = less overall boosting power = less yield).

Option 2)

If we were to change the overall structure of the Delphi Curve pools in a way that in the end all funds (yPool, sUSD, BUSD, renBTC) would be held and put into curve via a single smart contract, then the Boost and voting power of each individual pool would count towards all the other pools.

In other words, the Delphi ypool would be able to lock some of the rewarded CRV and boost all other Delphi pools (sUSD, BUSD, renBTC) and vice versa.

Benefit of option 2: locked CRV would count towards all Delphi pools (combined boosting of all Delphi pools = higher overall boosting power = higher yield). This would increase the power of each locked CRV by the number of all Delphi pools (4x at the moment).

Disadvantages of option 2: more difficult to implement, since a new smart contract would need to be created which is the “owner” of all delphi pool funds (yPool, sUSD, BUSD, renBTC), which might add complexity to the system.

Summary

In the long run, the benefits of option 2 in regard of yield and “cross-boosting across all delphi pools” will outweigh the initial effort of adding a higher complexity. I have some locked CRV so I could create the vote on dao.curve.fi as well.

It’s important to understand that once we decide for either option, a portion of the CRV tokens will be locked for a longer duration (up to 4 years) and this vote-lock (including boost) is then bound to that specific contract address. So if we decide to boost each pool individually, we would lose the benefits of the locked CRV (of the individual contracts) if we decide for option 2 in the future.

Thank you for considering :grinning:

9 Likes

I’m not an expert on the current smart contract design of Delphi, so the question would be if Option 2 would be technically feasible or too much work at the moment.

If we can get an answer to that question, we would be able to create a vote at dao.curve.fi in order to whitelist the contracts/new contract.

2 Likes

This is the new contract from yearn to enable CRV boosting for their yBUSD vault (for technical reference, might be interesting for us):

1 Like

What time frames are we looking at with the implementation of each option? Are both options viable? Could we implement option 1 (the quickest and easiest) and then could we focus on options 2, taking our time and ensuring that it is implemented without any bugs or issues?

I dont understand the technicalities of the underlying contract issues and human resources that might be required but could both be implemented at an efficient cost ratio?

1 Like