SIP-0042 Goes To Vote - Staking Security Update

Greetings fellow Sovryns. SIP-0042: Staking Security Update was introduced to the Forum on Monday. In short, this SIP improves the security of the Staking contract by adding the exchequer multisig as a pauser to the contract, meaning the Staking contract can be paused if needed to mitigate a potential bug or event that would lead to a loss of Staker funds.

Many Sovryns have reviewed this SIP and provided feedback in the Forum thread. Given the security-focused nature of this proposal and interest on the forum, it is now up for vote in Bitocracy, where SOV Stakers will ultimately decide whether the proposal should be implemented or not. You can read the SIP on the Sovryn GitHub here, on the forum here, or read the full text below.

If approved, this proposal will:

1. Replace the current Staking contract with a new Staking contract, with the only changes being targeted fixes of the issues described below.
2. Add the Exchequer Multisig as a pauser to the Staking contract, with the ability to pause or freeze the contract in case of emergency.

Improve security of the Staking contract

While going through our smart contracts to verify all their owners and their privileges, we noticed something missing from our most important contract Staking.sol. It is the heart and soul of our governance part of the protocol and we currently have no means to pause it in case of an emergency or unlikely breach. It means that we may find ourselves in a position where we notice a hack or maybe even could prevent that hack but we would not have the means to stop the exploits.

This is why we are introducing a Pause functionality.

It might seem counterintuitive at first, since we want Staking to be unstoppable, obviously, but there is a distinction to make between long term and short term safety, and a tradeoff to make between security and immutability.

By adding a pause function controlled by a multisig, we will have a way to mitigate circumstances that may cause a loss to the protocol or its Stakers, whether they are caused by a bug in our protocol or by a new ecosystem element (think about when flashloans first appeared in DeFi).

Bitocracy governance will retain full control of the pauser address to ensure that even if the multisig owners collude for or are coerced into abusing their power to pause the Staking contract, governance can override it by switching the pauser rights to another address. The same safeguard applies in the case the multisig is unable to unpause the contract, which could theoretically happen, excluding voluntary collusion, such as too many signers being kept away from their keys, e.g. by being taken into custody, or hospitalized in a pandemic or war scenario.

The proposed solution includes logical steps to make these rare events of pausing less restrictive and less inconvenient to our users. In many cases, we can still allow users to unstake during the pause, while we lock the rest of the contract until we prepare and deploy a fix. This is how the Pause functionality is designed, so that we do not lock users’ funds into the system for the duration of the pause.

To cover the cases where the detected bug could be exploited through unstaking, we also included a Freeze functionality in the implementation for this SIP, which locks the contract up completely, including unstaking.

• Existing Staking Logic contract: 0x4BaBb34189a9CDa8213D24DD3984058Fb8A955D2
• The new Staking Logic contract: 0xe31A938F5cf1C41747B5F20f9dD5d509B2ACd49c
• Proposed changes: DistributedCollective/Sovryn-smart-contracts#423

Given this SIP involves a change to the Owner Governor contract logic, there are certain requirements that need to be met for the SIP to pass. You can find the full technical details of different voting requirements on the Wiki here.

• Firstly, the voting quorum must be greater than 20%, meaning at least 20% of current voting power must participate in this vote for the SIP result to be valid.

• Secondly, the SIP must achieve over 70% support, meaning at least 70% of the voting power participating in the vote must be attributed to a FOR vote.
  
  
• The vote duration is 2880 blocks (~1 day). Given that the vote began at March 23 2022 16:26 UTC, the voting period will end at approximately March 24 2022 16:26 UTC.

• If the SIP is passed, there will be an execution delay (time lock) of 48 hours, meaning the result of the vote may not be acted upon until the end of this time lock period.

‍

We encourage all SOV stakers to once again put their voting power to work and exercise their right to vote for the future of the Sovryn Protocol. If you want to learn more about governance in Sovryn or are considering participating in the future, check out the Wiki article here. Thank you for your time and for maintaining Sovryn through decentralized governance!

Cast your vote here!

‍

Stay Sovryn