Redirect YB emissions to a distributor contract for gauge vote incentives

Proposals
1

Summary:

Hello. Tommy from Votium here. In collaboration with Votemarket, we have developed some helper contracts to automate allocating YB for gauge voting incentives.

There are three contracts:

DepositPlatformDivider - 0x0997f89c451124eadf00f87de77924d77a38419a
DepositHelperVotium - 0x5005DE019301aB6b744B6EFbB942E9A8999EEeC7
DepositHelperVoteMarket - 0xfD97b14E1d91B82936e35aE7b20dA4FD16C855B1

  • starting split is set to 65% Votium, 35% Votemarket, this split follows the efficiency data that Resupply uses which actually shows Votium should be even higher. This weighting can always be updated. It can potentially even be calculated on chain for a subsequent update to auto calculate the split.
  • starting gauges will be for the usdc, usdt, and frxusd pegkeeper pools. There will probably be a lot of discussion on which pools are best and we can continue those discussions. For now we urge a short minimal list to get things started.
    Gauges can be found at the following addresses:
    crvusd/usdc gauge: 0x95f00391cB5EebCd190EB58728B4CE23DbFa6ac1
    crvusd/usdt gauge: 0x4e6bB6B7447B7B2Aa268C16AB87F4Bb48BF57939
    crvusd/frxusd gauge: 0x22804B0F6bE741a9Fa1BbaEcDD6c8D4116E96944
  • Initial weights are set evenly between the three gauges, and can be changed with a DAO vote.

Abstract:

Set YB emission receiver to platform divider contract that splits YB emissions between Votemarket and Votium platforms.

claim() can be called by public every 2 weeks to automate deposits

There are two roles: Manager, and Owner. Both roles will be transferred to the DAO. Owner role has the ability to add/remove deposit helpers, add/remove gauges, and change weights of platforms and gauges on each platform.

Manager role only has the ability to change weights, as this can possibly be further automated and optimized in the future.

Specification:

to: 0x36e36D5D588D480A15A40C7668Be52D36eb206A8

data: set_recipient(0x0997f89c451124eadf00f87de77924d77a38419a)

3 Likes
2

Much thanks for the proposal, looks good to me!

I just want to start a discussion on whether we really want to spend 100% of the YB vested to Curve as vote incentives. I’m fully in favor of spending almost all of it to incentivize the crvUSD pool to grow liquidity, as that’s essential for further cap increases and to ensure crvUSD volatility doesn’t go crazy when BTC pumps/dumps and affect interest rates on mint markets.
That said, it might make sense to take a small cut (maybe 5–10%) of the vested YB and lock it to keep some upside from YieldBasis’s overall success. If locked, the subsequent revenue earned can be used for incentives aswell.

3 Likes
3

Agreed there should be a discussion about locking some of the YB.

Since the DepositPlatformDivider is able to take on additional “helpers”, it should be fairly simple to create a locking contract that would be plug-and-play with this proposal.

The specification would be to call addDepositHelper(address), along with setWeights(address[], uint16[]), on DepositPlatformDivider
Then, when claim() is called each round, it would create vote incentive deposits as well as locking whatever % is voted on by DAO.

There’s probably some things to decide about how to best handle how Curve’s veYB would vote, what to do with rewards, etc., in that scenario. If there is demand to set aside an amount before getting all of the contract development side sorted for a locking contract, could even create an extremely simple helper that just sends some % of YB to DAO controller at each claim.

1 Like
4

There should be some long term DAO investment thesis that locked YB could in theory through its yields make seed investments in Curve ecosystem protocols.

Part of the requirements of these investments would be some recursive locking of YB by the protocols in their tokenomics and incentives.

I see no downside to fostering long term incentives throughout the ecosysten.

Further, locking more of the supply (and its yield) does reduce the sell pressure.

I’ve locked (Small at this stage) ~10K+ up as veYB for perpetual contract. Will put more of my money where my mouth is by steering this type of governance in WKH investments which participate in Curve eco.

5

gm, interested in reading more detail on the resupply efficiency data computing, and how would you calculate it on-chain, to acknowledge the split calculations.

6

Resupply’s efficiency for the two platforms was provided by Resupply team, based on how many RSUP tokens they deposit vs how many votes received from each platform.

The current helper contracts have view functions to see what previous epoch YB amounts were given to each gauge, so a similar calculation can take place onchain, comparing previous YB amounts on each platform to votes received from Convex voter vs. others (viewable from gauge controller)

I have a work-in-progress contract for this, but need at least one round of incentives to properly test.

1 Like