Sovryn is a smart contract system built on RSK. The Sovryn smart contracts have many parameters that can be modified, and the smart contracts themselves can also be modified. This raises the issue of governance: what the parameters and smart contracts of the Sovryn smart contract system are that can be governed, what the processes are for modifying these parameters and smart contracts, and how to modify the governance process itself.
Note: This page intends to describe how Sovryn governance currently works at a medium level of detail. This page is currently a WORK IN PROGRESS; while it may not have all of the information about Sovryn governance, we have strived to ensure that the information that is here is 100% accurate. We welcome feedback with any additions or corrections to this content.
For the canonical description of Sovryn governance, you will have the find and read the source code of the relevant smart contracts in their current state on the RSK blockchain.
All ownable contracts are currently owned by the Exchequer multisig.
Sovryn smart contracts directory:
SOV holders must stake their SOV to gain voting weight in Bitocracy. Voting weight is determined using a quadratic formula based on the amount and duration of SOV staked.
Staking periods are divided into bi-weekly intervals, beginning at the time of the SOV token generation event and repeating every two weeks from then on. Users will acquire voting weight from their stake and begin their staking duration when the staking period after they started staking begins. Once their staking duration begins, users can withdraw their staked SOV early if they are willing to take a slashing penalty. Users can also delegate their voting power to other addresses.
In addition to earning voting power, SOV holders who stake their SOV become eligible for protocol fee-sharing, receiving a proportional share (as measured by voting power) of all tokens that have been collected in the fee-sharing pool. Tokens collected in the fee-sharing pool come from protocol fees plus all slashed SOV from users who withdraw their staked SOV early.
The stake weighting function is based on a quadratic formula, using the amount and duration of SOV staked.
Let m be the maximum staking period (
1092 days) , be the number of days passed since the beginning of the period, and be the maximum voting weight (currently
9). The voting weight at a given time can be described as:
is added in the end to shift the weights to lie in instead of .
Users will usually not stake the maximum duration, so has to be computed based on the remaining days until unstaking:
The user’s voting power at a given time is the product of their stake and their voting weight:
The total voting power equals the sum of the voting power of all users. However, since we can’t iterate over an array with unlimited size, we need to compute it differently. Instead of summing up the user voting powers, we introduce a mapping, which stores the total amount of SOV to be unstaked on a given day, and call it
Whenever a user stakes SOV, not only is their staking balance updated, but also
stakedUntil[unstakingDay]. Whenever a user increases their staking balance, the mapping also needs to be increased. Whenever a user increases their staking time, their stake is subtracted from
stakedUntil[previousUnstakingDay] and added to
Now, we can compute the voting power of all SOV staked until a given point in time in a single operation. The daily voting power DVP is given by:
where is the content of
The total voting power can then be computed by summing up the daily voting powers of the next days:
This process requires iterations. With a maximum staking duration of 3 years, this would cost approximately 1,000,000 gas. In order to save gas costs, we decided to stake in bi-weekly periods instead. As a consequence, voting weights are only adjusted every 2 weeks and we need a maximum of 78 iterations (instead of 1095).
stakedUntil mapping needs to be checkpointed to allow the computation of the total voting power for a point of time in the past. The same is true for the user stakes.
Once their SOV is staked, users are able to delegate their voting power to another address. Users may want to do this if, for example, they are unable to be actively involved in governance and want a more active or qualified individual/group to vote on their behalf, or if they prefer to maintain transfer authority for their SOV on one address but voting authority on a different address.
Given the possibility of delegation, a user can have a potentially large number of addresses delegating voting power to their address, with each of these other addresses staking for different durations. The voting power of a delegatee is computed the same way the total voting power is computed: as a sum of the voting powers per unstaking day.
Users who unstake before the end of their staking duration are subject to a token slashing penalty of up to 30%. This incentivizes users who stake to maintain their commitment to the protocol. Slashing penalties are deducted from the staking balance and sent to the fee-sharing pool and redistributed to all other staked SOV holders.
The penalty chart for early unstaking is as follows:
|Weeks remaining||Early unstaking penalty|