0VIX Docs
Search…
Implementation Details
User voting power
$w_i$
is linearly decreasing since the moment of lock. So does the total voting power
$W$
. In order to avoid periodic check-ins, every time the user deposits, or withdraws, or changes the locktime, we record user’s slope and bias for the linear function
$𝑤_i(t)$
in the public mapping user_point_history. We also change slope and bias for the total voting power
$W(t)$
and record it in point_history. In addition, when a user’s lock is scheduled to end, we schedule change of slopes of
$W(t)$
in the future in slope_changes. Every change involves increasing the epoch by 1.
This way we don’t have to iterate over all users to figure out, how much should
$W(t)$
change by, neither we require users to check in periodically. However, we limit the end of user locks to times rounded off by whole weeks.
Slopes and biases change both when a user deposits and locks governance tokens, and when the locktime expires. All the possible expiration times are rounded to whole weeks to make number of reads from blockchain proportional to number of missed weeks at most, not number of users (which is potentially large).
\