Vote-Escrowed VRH

Participating in VRH DAO governance requires a user to have a balance of vote-escrowed VRH (or veVRH) and is represented in the VotingEscrow contract. 
The veVRH voting power not only helps user to
Gain minted VRH by joining a guild as a member or creating a guild as an owner
Contribute guild weight for the guild user in
Participate in Aragon DAO for voting on different kinds of proposals.
The only way to acquire veVRH is by locking VRH through the create_lock function in the aforementioned contract.
veVRH stands for vote-escrowed VRH and is acquired by locking your VRH for an extended period of time.
The longer you lock your VRH, the more veVRH you will earn. Currently, VRH VotingEscrow smart contract allows users to lock VRH for at least minimum 1yr, maximum 4yrs. However, the users can extend the locking period by a week.
​
1 VRH locked for 4 years = 1 veVRH
1 VRH locked for 3 years = 0.75 veVRH
1 VRH locked for 2 years = 0.5 veVRH
1 VRH locked for 1 year = 0.25 veVRH
veVRH vote weight decreases linearly with time is shown as below.
Where WWW
​ is veVRH vote weight, aaa
​ is locked VRH amount, tlt_ltl​
 is VRH locked time. ​tmaxt_{max}tmax​
 is 4 years.​
Note that veVRH is not ERC-20 compliant, therefore it is not transferrable.
One VRH locked for 4 years is equivalent to a balance of one veVRH and the maximum lock time is 4 years.
After the lock period has expired, the withdraw function may be called to reclaim the original amount of VRH that was locked.
VotingEscrow
Implementation details
The user's vote weight wiw_iwi​
 decreases linearly with time. The total vote weight WWW
will also decrease with time. In order to avoid having constant updates to the user's vote weight unnecessarily, every time a user performs a VRH create_lock, increase_amount, or increase_unlock_time, the checkpoint algorithm  will update the user_point_history mapping to record the decaying vote weight wiw_iwi​
 based on the slope and bias. slope means how much veVRH will decrease by seconds. bias means how much veVRH at that time. Similarly, this will also affect point_history mapping which is recording the decaying total vote weight WWW
.
In addition, when a user's locked VRH has expired, the contract will update slope_changes mapping to record the data that will be changed in the future. Every time when a change is recorded, the value of the epoch variable will be increased by 1.
This way we don’t have to iterate over all users to figure out, how much should W(t)W(t)W(t)
change by, and neither we require users to check in periodically. However, we limit the end of user locks to times rounded off by whole weeks.
Both slopes and biases change when a user locks governance tokens, and when the lock time expires. And all possible expiration times will be rounded to the whole weeks so that the access frequency on the blockchain is dependent on the number of weeks instead of the total number of users (which can potentially be a large number).
Last modified 11mo ago