SIP-0043 is live: Critical Governance Bug Fix

Last Sunday we held an emergency dev meeting in reaction to an alarming bug report. The vulnerability was quickly confirmed as valid. There is a minute error in the code of the Staking contract, which went unnoticed through countless internal reviews and several external audits. It allows a potential attacker to illegitimately obtain arbitrarily high voting power. To the best of our knowledge and after thorough investigation, this vulnerability has thus far gone undiscovered and unused by any malicious actors.

A handful of team members are subscribed to the Immunefi bug bounty feed and they are the only people who knew about this until now. It is our internal policy - and best practice - to treat all reported bugs confidentially, until their impact can be fully assessed and their status allows public disclosure, which usually happens after the fix is deployed. We know how to fix this bug, it is a very simple change, a single character really. But the problem is in the solution. To apply the fix we need a vote from Bitocracy to replace the implementation of the staking contract with the patched version. But when a SIP is set to be voted, it must include the complete transaction to be executed in case it passes, which means the new contract byte code is revealed, disclosing the bug and leaving a 72 hour window of opportunity for any attacker to exploit it before the patch can actually be deployed.

We could not ask you to vote on a proposal blindly without showing the source code nor being transparent about how it works in detail. It would set a dangerous precedent and was likely to fail or at minimum become an extremely polarizing subject, with good reason in both cases. Also, if the bug was already known by an attacker, this would force them into action to utilize it before the fix is implemented. 

Until now we did not have any tool to mitigate this attack. If someone decided to use it offensively, our best option would be a voting power war where the whole community would be taught how to wield the vulnerability - a distributed weaponized version - to collectively crush the attackers and pass a SIP that would end the war. We could then pick up the pieces and rebuild our staking contract, restoring its state from a previous snapshot. This would not have been an easy task, and we all would prefer to be spending time on building new features and better UX instead.

We considered many options, including trying to sneak this tiny change into a larger update. But it is unwise to underestimate the ability of black-hats spotting upcoming bug fixes. It is also not Sovryn to include a change into a SIP without clear disclosure, even if it is for the greater good. We had to find a better solution, and possibly one that could help us out of these situations in the future as well.

Now that the contract is paused, we can disclose everything and answer all of your questions with transparency. Most importantly, we can publicly expose the bug and propose a fix, with a guarantee that it cannot be exploited due to the contract being paused.

I now present SIP-0043 as an emergency critical bug fix. This Proposal, if executed, will replace the Staking.sol implementation with a safer patched version and immediately un-pause the contract afterward.

Since the bug does not impact the withdraw function, there is no need for Exchequer to use the Freeze function on the staking contract. This means that if anyone wants to unstake, they are free to do so throughout the pause. Please note though that it is absolutely unnecessary to unstake any SOV from a security standpoint; we have taken extreme measures to protect the protocol's assets and they are now safer than ever. Creating new stakes and extending existing stakes will be available again ~72 hours after the vote starts, should SIP-0043 pass.

Find the full text for SIP-0043 here.
Discuss SIP-0043 on our Forum here or in the #Bitocracy channel in our Discord here.
Like SIP-0042, this SIP involves a change to the Owner Governor contract logic, therefore 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.
‍‍

• 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 March 27 2022 18:58 UTC, the voting period will end approximately March 28 2022 18:58 UTC.
• If the SIP passes, there will be an execution delay of 48 hours, meaning the result of the vote may not be acted upon until the end of this time lock period.

Therefore, if this SIP were to pass, the Staking contract may be patched no earlier than Wednesday March 30 2022, after which the contract would then be un-paused and return to normal operation.

I encourage all SOV Stakers to once again put their voting power to work and exercise their right to decide the future of the Sovryn Protocol. If you want to learn more about governance in Sovryn or are considering participating, check out this Wiki article here. Thank you for your time and for maintaining Sovryn through decentralized governance! Cast your vote here!
‍
Events like these highlight why we believe it is crucial to maintain a leading bug bounty program. Internal audits are a good standard practice. External audits, even better. But open bug bounties welcoming talented white hats from every background imaginable remains one of the best lines of defense we sustain at Sovryn. The ongoing program with Immunefi rewards a maximum bounty of US$1,000,000 for critical finds and is available here.

‍

Stay Sovryn