CR
Curve DAO
Mechanism map
- Vote-escrowed (Curve original)
This token function represents the value received in the form of a cashflow by all veCRV holders. This value is delivered to all stakers of CRV in the form of the fees generated by Curve and crvUSD administration fees. This cashflow in contingent only on locking the CRV token to obtain veCRV.
The exact portion of fees paid to locked token positions is defined by the governable parameters of the protocol, such as the FeeSplitter parameter governing the split of the crvUSD fees.
Value drivers
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)
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)
Deployments are observable here. Cross-chain governance deployments are observable here.
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 . It should be observed that veCRV resides only on Ethereum, and therefore side-chain implementations of boosting and voting are distinct.
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.
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:
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.
This token function represents tangible and intangible value derived from controlling the decision-making regarding resources, parameters, or updates on the protocol level. The requirement for obtaining governance power is locking the CRV token in the vote-escrow contract.
The governance power and related value can be obtained only after locking CRV (action which corresponds to the Risk Exposure) and casting a vote (the Conditional Action).
The governance of the protocol controls a number of protocol parameters, the distributions of several income streams, and a countable number of improvement proposals, current and future (more details in the VCIP section).
Value drivers
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)
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
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)
CRV possesses a single large VCM composed of three sub-VCMs. One is exactly equivalent to a regular Yield-Bearing Staking Token, encapsulating the unconditional distribution of fees to all veCRV holders. Another is the classical Governance Token. The third encompasses the acquisition of liquidity boost by the liquidity providers that also possess veCRV.
This token function represents the ability to generate additional yield for a liquidity provider with veCRV locked position.
This value is delivered to veCRV stakers who provide liquidity and received in the form of a boost, which is applied based on the relative weight of the liquidity provider's veCRV position within a given pool.
The boost multiplies the LP reward when distributing the epochal gauge allocations within the pool.
Value drivers
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)
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
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)