CRV methodology
Reviewed token theory and authored supporting material.
Origins of value
- [3]Governance
Represents governance value that originates from influencing CRV emission distribution and general Curve DAO proposals
The governance value originates from the ability of veCRV voters to influence the distribution of CRV emissions weekly (although the weights are updated daily). This distribution is used to reward gauges, and through them, users who stake the associated liquidity provider tokens. Additionally, veCRV Governance covers voting on proposals and community fund usage.
[3] = ƒ([81], user_vote_allocation, user_strategy_representation)
- [7]Transferability Restriction
represents the necessity to lock CRV in vote-escrow contract in order to activate its utility
Represents the requirement to lock CRV for a specified time period [1 week - 4 years] in order to activate the token utility, which only exists in a nontrivial way in the form of veCRV. The voting power gained per token locked linearly depends on the remaining locking time.
[7] = ƒ(lock_time, price_at_lock, locked_quantity)
- [2-1]Cashflow
represents the additional cashflow for the LP who owns a veCRV position and has staked their LP tokens in a Gauge that is eligible for a CRV boost.
This represents the additional CRV reward, or Boosted Reward, that a user receives for staking LP in Gauge from an address with a veCRV position.
[21] = ƒ([7], [82], user_vote_allocations, emission_distribution, user_voting_strategy)
- [2-2]Cashflow
represents the protocol fees received by veCRV stakers
Represents protocol fees distributed to the veCRV holders pro rata on a weekly basis.
[22] = ƒ([82], admin_fee_volume, user_weight_shares)
- [8-1]Conditional Action
represents the necessity of participation in voting to acquire governance value
The conditional action represents the necessity of participating in the governance process (i.e., voting, primarily for allocation of CRV emissions) in order to acquire veCRV governance value.
[81] = Binary
- [8-2]Conditional Action
represents the mandatory condition action (LP tokens staking in Gauge) to activate boosted CRV rewards
Conditional Action: to receive boosted CRV rewards, veCRV staker must have a liquidity position in Curve and stake these LP tokens in Gauge.
[82] = Binary
vcip
Deployments are observable here. Cross-chain governance deployments are observable here.
1. METHOD OF LOCKING AND ACCOUNTING OF THE CRV TOKEN
Locking of tokens is realised by invoking the VotingEscrow.create_lock method of the veCRV contract; thereafter, locks can be manually maintained at a desired level by invoking the VotingEscrow.increase_unlock_time method of the veCRV contract. Locking of additional funds separately is not required, as funds can be added to an extant lock by invoking the VotingEscrow.increase_amount method of the veCRV contract. This is commonly used to maintain perpetual lock of CRV in case of, e.g. Convex.
Once the lock expires, the funds can be withdrawn by invoking the VotingEscrow.withdraw method of the veCRV contract (should the user have more than one expired lock, this method would withdraw all of them). These are all the methods for maintaining one’s locks.
The voting power thereby conferred is computed with a coefficient of $$ \frac{\textit{lockTimeRemaining}}{4\ \textit{years}} $$. It should be observed that veCRV resides only on Ethereum, and therefore side-chain implementations of boosting and voting are distinct.
2. GOVERNANCE IMPLEMENTATION
Participation in governance is then assured on the Ethereum chain by interacting with a custom fork of the Aragon voting app. veCRV is weighted, as stated before, by the remaining lock time, but also within each (weeklong) voting period: past the halfway point, the veCRV decays linearly to zero at the voting period endpoint; in this way, it becomes infeasible to sway the outcome of the vote with a last-minute vote injection (likewise, changing the vote is forbidden for the same reason).
There exist two voting contracts, of which one is used for parameter adjustment, and the other - for major changes like the change in the DAO voting address. They possess different quora and support thresholds (30/51 and 15/60 for the Ownership Voting and Parameter Voting, resp.). Proposal generation is only permitted for users who have at least 2500 veCRV. Vote creation is done via the voting contracts.
Cross-chain governance still relies on voting on the Ethereum mainnet on account of the exclusive presence of CRV/veCRV there. Therefore, cross-chain governance necessitates communication of the results to the target chains. This is done with the help of a Broadcaster contract on Ethereum that can be called by an Agent in order to broadcast to a target chain and a relayer which automatically routes the calldata to the appropriate Agent on the target chain (the Agent structure mirrors that on Ethereum) for execution. The Agents on the sidechains are concerned solely with execution for the aforementioned reasons of voting being confined to Ethereum.
3. YIELD BOOSTING IMPLEMENTATION
The boost is obtained by the very action of locking the CRV tokens and automatically updated at any token transfer, deposit, or withdrawal by the user. Since the system theoretically allows gaming it by avoiding the updates, such users can be forcibly updated with the LiquidityGaugeV6.kick method. Crosschain boosts are present in the same way crosschain voting is: namely, by conveying the veCRV information to the sidechains via an oracle. The boosted liquidity formula is:
$${\text{effective liquidity}} = \min!\left( L_{user},\ 0.4L_{user} + 0.6L_{total} \cdot \frac{veCRV_{user}}{veCRV_{total}} \right)$$
Finally, the fees are distributed simply pro rata among all holders of veCRV. They, like the other epochal CRV events, are computed weekly. Claiming is done by invoking the FeeDistributor.claim method.