Curve DAO token (CRV) is an Ethereum token that is powered by Curve finance. Which can be stated as the decentralised exchange and an automated market maker protocol. Curve DAO consists of multiple smart contracts connected to Aragon. And generally Aragoon 1 token = 1 vote however this voting method is replaced with the weighted voting method that will be discussed in this paper.
Curve uses escrow for time weighted vote. Escrow is a legal concept describing a financial instrument and it is used as a third party that holds assets before it is transferred from one account to another. Users who commit to own a token for a longer period of time have more stake on investment and hence it can be expected that such users can give more responsible governance decisions.
Curve have introduced a new way of voting instead of voting with the amount of token a now user can lock their tokens for a selected locktime tl which are treated as the vote. Where these votes can be locked for the maximum time period of 4 years. Moreover the selected time period should be less then the maximum time tl
From the above equation we can say the weighted vote depends on both amount and time.
However a time locked token can not be a smart contract. As it can not be traded in during the locked time until and unless the token lies in a multi-signature wallet.
VotingEscrows resembles Aragon’s Minime token. Where balanceOf()/balanceOfAt() and totalSupply()/ totalSupplyAt() return back all the weight respectively using following formula.
Where locks can be created using create_lock() and increment in time can be done using increase_unlock_time or increase in token amount and withdrawal can be done using increase_amount(),and withdraw() commands respectively.
As soon as the users lock the token their voting power starts to decrease linearly. So does the total voting power W. In order to avoid the periodic changes, every time the users check-in the changes are recorded in the form of slopes and bias for the linear wi and W(t). In addition when the lock schedule time is ended, there is a change in slope of W(t) and every time the slope of W(t) changes there is an increase in epoch by 1.
In short the slope and bias changes when the user deposits and locks governance tokens, and when the lock time expires.
An ERC20CRV is an ERC token which studies inflation on a linear piecewise model. Whenever inflation is decreased by 21/4 every year. And everytime the inflation is dropped the epoch is changed. As shown in the graph below.
As we can see from the above graph as the time is increasing there is an increase in the supply of CRV tokens. If we look closer at the graph we can see the initial supply of the CRV token is 1.273 billion and as the time passes supply of token is approximately 3.03 billion. Where inflation has a 22.3% impact on the supply. All the inflation impact is distributed among the users according to their contribution calculated by the gauges.
Inflation has an impact on only those users that provide liquidity within the protocol. To measure this usage we use “Liquidity Gauges” contracts. Where each pool has its own liquidity gauges. And to maintain the number of liquidity gauges and weight of each liquidity gauge contract we have a “Gauge Controller”.
To measure liquidity over time users have to deposit their LP token in the Liquidity gauge. The coin rate decides which gauge will depend on current inflation rate, gauge weight and gauge type weights. Each user receives a share of minted CRV according to the amount of their LP token locked. Additional reward might be boosted by up to a factor of 2.5 if the token is locked by the user under Curve governance in the Voting Escrow contract.
Suppose we have our inflation rate stated as r which changes with every change in epoch, gauge weight wg and gauge type wt. so we calculate the rate of change of inflation with the following formula:
Which changes every time when there is a change in wg , wt or mining epoch time.
Now to calculate a user’s share we integrate the following integral
Where bu(t) = balance supplied by user ( LP Token amount)
S(t) = total liquidity supplied by user
Iu= amount of token that has to be minted by user to them
Where bu(t) changes every time the user u deposits or withdraw the token, S changes when any user from the pool withdraw or deposit the token. And lastly Iu is recorded as per user in public integrated fraction mapping.
In order to avoid that all users to checkpoint periodically, we keep recording values using following integral function named as integrate_inv_supply
The value of Iis is recorded when any user from the pool makes deposits or withdrawals, furthermore, everytime r' is changed.
Whenever a change is made by the user in the pool we can calculate Iu as the current value of Iis and multiply it by the users balance and sum it along the users balance following is the formula.
The per-user integral is is possible to change with sum of bu(t) since it keep changing between tk and tk-1.
Up till now we have seen how liquidity gauges are working but the main concern is how to incentivize the users to participate in governance, and create liquidity. The following explains the how the balances are boosted
A user’s balance is counted in the liquidity gauge and gets boosted whenever the CRV token is locked in a voting escrow expressed in the following formula
Where the value wi is taken when the user performs any action and applied until next action is implemented.
Moreover if none of the use locks the CRV then impact of inflation is distributed according to bu. Furthermore, if a user stakes a sufficient amount of CRV tokens then they can boost the CRV stream by 2.5
From the above implementation work we can say that since the voting power starts to decrease with time it is the most favourable condition for the user to apply the boost and do not do any further action until the time lock opens.
Here users can allocate their veCRV token towards one or more liquidity gauges. It receives a fraction of a newly minted CRV token that is proportional to how much veCRV the gauge is allocated.
We all know the gauge controller records liquidity gauge but in order to implement the weight voting. The gauge controller includes the parameters that are linear.
GaugeController records points (bias+slope) per gauge in vote points and scheduled changes in biases and slope for those points in vote bias changes and vote slope changes. Where the new changes are implemented at the start of a new epoch every week.
Per-user, per-gauge slopes are stored in vote-user slopes along with power that is used by the user and the time of their vote-lock.
The totals of the slopes and biases for vote weight per gauge are scheduled for the next week as well as the points of voting power becomes 0 the locks expire for some users.
Moreover, when there's a change made by the user in gauge weight vote, the change is implemented till next week. This decreases the number of block-chain reads which needs to be performed by every user: that will be directly proportional to the number weeks since the last change is made instead of the interaction among the users
Since GaugeController is one of the most important pieces of the system therefore it is governed by DAO itself.
Curve DAO shows that users are not willing to stick with a project after receiving a short term gain. Hence only a handful of people are left to govern the project which creates an environment for hostile power grabs. Moreover the CRV holders bear an opportunity cost when they lock-up their tokens because tokens are tardable. And if the price moves up or down, the token is stuck in the protocol and can not be sold until and unless the user pays a hefty amount of gas to unlock the token. Besides, high inflation will negatively affect CRV price in the upcoming years.
You can read about our latest research on Zero Knowledge Proof: A General Understanding.