SIP-0042: Staking Security Update

SIP-0042: Staking Security Update

Good morning, afternoon and evening fellow Sovryns. With this post, I introduce SIP-0042: Staking Security Update. This SIP does what it says on the tin, it improves the security of the Staking contract. You can read the SIP on the main Sovryn GitHub, or read the full text in this post below.

I would like to welcome every Sovryn Individual, especially SOV Stakers, to review this proposal and give feedback (for, against, or otherwise) in this forum thread. Given the nature of this proposal and its security-focused outcome, I would encourage this go to vote sooner rather than later, but not until there is a strong consensus toward that action. So please, read and provide any and all feedback below!

SIP Description

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 set the contract on pause or freeze in case of emergency.

Motivation

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.

Proposed change

9 Likes

Now for my personal view:

I for one am in support of this SIP. It makes sense for the exchequer to have a pausing ability for avoiding and fixing potentially unsavoury events - this is the same for all other important contracts.

Bitocracy retaining control of the pauser address is important, I’m glad that’s in there.

Separate pausing and freezing abilities are also important, to enable stakers to unstake if they need to, and to only freeze the movement of SOV in case of an unstaking exploit, which is highly unlikely. This should avoid locking of any user funds unless absolutely necessary (and then I will be happy my stake is locked and out of potentially malicious hands).

Not much else to add, seems a logical safeguard to have

8 Likes

I support this since security comes first.

1 Like

Security first! allways!

I fully support this SIP and since it is about security it should be done ASAP.

Firstly, thank you for looking out for the security of stakers. I remember 5months (maybe 6) ago someone in the telegram group asking if there is an insurance fund in place in case of a hack to the staking contract. And this just solves the issue.

Secondly, please does the security improvement also cover the process of a user account being unknowingly hacked then the hacker unstakes a user’s SOV?

This SIP outcome would not cover this use case. I don’t think it would be efficient or a good idea to pause the whole staking contract every time someone gives their seed phrase away :sweat_smile:

A security measure who’s time has finally come. I’m all for it!

1 Like

Security is very important, so I support this.

1 Like

Full support of this, safety and security are paramount

How I see it: Safety is important, but not at the expense decentralization. So stakers are going to vote and give centralized powers to few addresses for their safety?

Would like to see many more people expressing their thoughts on this one before I decide on what to vote.

5 Likes

its already implemented on most other contracts, its just missing from the staking contract so far

1 Like

why now?
until when?
can this be used to target specific addresses?

1 Like

the other day I got a Cex account flagged for no fucking reason and got frozen for almost 2 weeks, just to receive a “sorry” at the end, and I thought to my self: “this is why defi will win”.
guess not.

1 Like

i’m joking yes I want my stake safe.
but…

1 Like

why now? because it is way overdue and leaves the protocol unarmed against many attacks that it could otherwise mitigate efficiently.

until when? until another vote decides we should remove it, unless you mean how long would a pause last, in which case I’d answer “for the shortest possible time, i.e. until a bugfix is tested and deployed”, and in the unlikely case of hostile/malicious use of the pause or freeze function, until 3 days max, which is the time it would take for Sovryn governance to vote a new owner or pauser for the contract and unpause it.

can this be used to target specific addresses? no
pause blocks all user-facing staking functions, excluding withdraw (unstake) for everyone.
freeze blocks all functions of the contract, including withdraw and all admin functions as well. So no rug pull nor third party contract drain can happen through a freeze.

2 Likes

Lol, while I agree safety is important, I agree with SOV_HOOLIGAN. It seems like mostly team members are commenting on this SIP, would love to see more people using the forum. Posting these types of SIPs, I’m going to include the last one, it’s funny how they get thrown on the forum and voted on within 3 days. SIPs like this particular one are kind of useless, just do it… They only seem to be SIPs that get put up for vote are the ones the team either fully supports or comes up with. I’ve seen many ideas shared here, but if the team doesn’t care it’s ignored. There were quite a few ‘No’ votes in the last SIP. One wallet I know had quite a few people who delegate votes to it. The vote was 50/40% then the one big wallet voted instant 96/4%, lol, so glad my vote counted. In the long run I’m not really sure how DAOs or decentralized protocols are going to make a big difference to the “normal person trying to get ahead”. It’s still the ones with the most money and ability to buy everything out from the little people that will control the future. I know you might say I’m only saying that because the price of SOV is so low right now etc etc. Not the case, been here since 2020, still buying. I believe in the project so someday I’ll either be rich or broker. I’ve seen SIPs here trying to deal with tokenomics, burning ideas, locking away ideas, all seem to fall on deaf ears.

2 Likes

With this SIP:

  1. Will it ever be possible to stop me from unstaking?

  2. Will it ever be possible to change my voting power?

  3. How many people have control over this function, and how many people are needed to execute a pause or a freeze?

  4. Will it ever be possible to stop certain addresses from participating in staking with the use of the pause/freeze features?

  1. Will it ever be possible to stop me from unstaking?
    During a freeze you cannot unstake until the end of the freeze. Under “normal” circumstances that is done to protect your funds, and everyone is in the same boat as you. Governance can force an unfreeze at any time if it deems the freeze unnecessary, or if the pauser multisig was abused, but it will take 3 days. In the meantime, no funds are at risk.

  2. Will it ever be possible to change my voting power?
    Nothing in this SIP has any connection with voting power. It simply introduces a couple of “power switches” to allow the team to better protect the protocol against exploits.

  3. How many people have control over this function, and how many people are needed to execute a pause or a freeze?
    The initial setup this SIP proposes is to give pauser rights to the Exchequer multisig. Governance can change this at any time for any other address, another multisig, or maybe even in the future to a decentralised threat detection monitoring system.

  4. Will it ever be possible to stop certain addresses from participating in staking with the use of the pause/freeze features?
    Not with the code that this SIP is proposing. This is a global feature that will affect all users equally. There is no way to make this feature address-specific.

3 Likes

I tend to agree with your sentiment on voting powers, and it leads me to a side note: would we consider quadratic voting for Bitocracy?