We use cookie to improve your experience on our site. By using our site you consent cookies.
Accept
Over the last month Bitocracy have passed two proposals - SIP-0042 and SIP-0043 - in order to resolve vulnerabilities in the Staking Contract, detected by our Immunefi Bug Bounty.
SIP-0044 looks to finalize these fixes by resolving the root-cause that enabled the vulnerabilities to occur.
The Staking contract has been paused to prevent malicious use of the information disclosed by this SIP.
If approved, this proposal will upgrade the Staking contract to an implementation that prevents a critical vulnerability.
The chosen mitigation strategy restricts the ability for an attacker to creatively combine calls in a single block or create loops which could potentially be harmful, while not hindering the normal usage and composability of the contract.
We have noticed that a handful of design decisions of the staking contract create a vulnerability when combined in a given way. Individually most of them make sense, or made sense when the contract was first deployed, but when taken in today's context and combined in the same block with specific prior context, they open the door to a voting power manipulation exploit.
Fixing the underlying causes is a large undertaking, requiring a partial rewrite of the contract and possibly a split, because the contract is already as large as allowed by the EVM (contract size must be below 24kB). This is not something we want to do in a rush, nor do we want to keep the staking contract paused longer than strictly necessary.
In order to close the vulnerability and its various variants, we have opted for a mitigation strategy that thwarts them by forbidding a number of scenarios which we think have no real practical use for the users, while being necessary to enable the exploit. Namely, if this SIP is approved, it will forbid a number of actions from happening in the same block as a call to the stake(...) function, for the same lockDate timestamp:
Existing Staking Logic contract: 0x4769c04F2537C3b951Efa8a330A15716B5913Af6
New Staking Logic contract: 0x81570497e763809900A8e91c8DaF3020085e43aB
Proposed changes: DistributedCollective/Sovryn-smart-contracts#429
Like SIP-0042 and SIP-0043, 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.
Therefore, if this SIP were to pass, the Staking contract fix may be implemented no earlier than Friday April 15 2022, after which the contract would then be un-paused and return to normal operation. I encourage all SOV Stakers to 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
Leave A Reply