[PIP-005] Add Convex PRISMA-cvxPrisma Pool so it can receive PRISMA rewards

DAO Proposals
1

Summary

This proposal is straightforward and simply proposes to add support PRISMA/cvxPrisma as a receivers so that lockers may vote to direct emissions to it.
A Curve only version of this pool still needs approved as well

Motivation

As Convex have been excellent ecosystem partners and that a significant amount of Prisma rewards are claimed as cvxPrisma, it makes sense for vePRISMA holders to be able to direct PRISMA emissions to it.

Specification

Implementation address: 0xc629a01eC23AB04E1050500A3717A2a5c0701497
LP token address: 0x3b21c2868b6028cfb38ff86127ef22e68d16d53b

Target Contract: 0x3da992f4694d1a1624c32cafb5e57fe75b4bc867
Command: deployNewInstance(258)

Target Contract: 0x06bDF212C290473dCACea9793890C5024c7Eb02c
Command: registerReceiver(0x63da809eC4C2bBCD0dB1Ae72bEEfEAe4eFe72805, 1)

[(‘0x3dA992F4694d1a1624c32CAFb5E57fE75B4Bc867’, ‘0x9fa53d230000000000000000000000000000000000000000000000000000000000000102’), (‘0x06bDF212C290473dCACea9793890C5024c7Eb02c’, ‘0x33dee36000000000000000000000000063da809eC4C2bBCD0dB1Ae72bEEfEAe4eFe728050000000000000000000000000000000000000000000000000000000000000001’)]

Next steps

This will be a three day snapshot temperature check where vlCVX voters are able to vote on Convex

Vote:

Snapshot

2 Likes
2

Can support this (as well as yPRISMA when it comes) but would like to see some commitment to limiting the weight that will be sent towards the emission receiver (much like Yearn).

1 Like
3

Supported.
Also, very nice design by whoever built the Convex factory to use CREATE2 for deterministic addresses, instead of normal CREATE. This way address can safely be included in the calldata in the proposal. No need to worry about a subsequent proposal for convex factory managing to get queued ahead this one. :ok_hand:

2 Likes
4

Yes, definitely supported, a more liquid cvxPrisma benefits everyone.

1 Like
5

Based on discussions with Convex and Yearn, we’ve come up with a solution to programatically limit a receiver’s emission percentage in any given week. Changes to the deposit token code can be viewed here:

How it works:

  1. The receiver has a maxWeeklyEmissionPct that decides the maximum % of the weekly emissions it is allowed to receive. By default it is set to 100%. The value can be modified by the DAO at any time and the change takes effect in the following week.

  2. At the start of a new week, if the receiver’s allocated emissions exceed the max allowable, the receiver takes one of two actions:

    • If emission claims are locked, the excess amount is recorded as storedExcessEmissions.
    • If emission claims are unlocked, the receiver claims the excess amount (plus any previously stored amount) and then returns it to the unallocated supply.

I propose that within the payload for PIP-005, we include 3 additional actions:

  1. Set the new implementation contract for the Curve receiver.
  2. Set the new implementation contract for the Convex receiver.
  3. Set maxWeeklyEmissionPct on the newly deployed cvxPRISMA/PRISMA receiver at 10% (1000).
4 Likes