Curve DAO

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.