Participating in VRH DAO governance requires a user to have a balance of vote-escrowed VRH (or veVRH) and is represented in the
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_lockfunction 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.
is veVRH vote weight,
is locked VRH amount,
is VRH locked time.
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
withdrawfunction may be called to reclaim the original amount of VRH that was locked.
The user's vote weight
decreases linearly with time. The total vote weight
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
checkpoint algorithmwill update the
user_point_historymapping to record the decaying vote weight
based on the
slopemeans how much veVRH will decrease by seconds.
biasmeans how much veVRH at that time. Similarly, this will also affect
point_historymapping which is recording the decaying total vote weight
In addition, when a user's locked VRH has expired, the contract will update
slope_changesmapping to record the data that will be changed in the future. Every time when a change is recorded, the value of the
epochvariable will be increased by 1.
This way we don’t have to iterate over all users to figure out, how much should
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).