SIP-0042: Staking Security Update

I support this for our Beta Phase. I would like to see a clear commitment from the core team to review this e.g. in 12 months to assess whether it’s then still in the best interest or time to decentralise and run forever.

2 Likes

I’m on board.

Just one more question, is there a reason to think the staking smart contract isnt secure, and we should trust multisig key holders (exchequer), more than the smart contract, or is this a like a double security measure type thing?

1 Like

Me as well many others , support this SIP because it´s about SECURITY and has to be implemented right away.
I don´t want to think how SOVRYN would be seen in the DeFi ecosystem if a hack would happen beside bieng all affected.

1 Like

Great questions already asked, would like to have those answered first. Sure, security is important and therefore I’d like to say do what’s best for safety. However I’m not sure if security should compromise decentralisation on any way. Therefore I’d like to learn a little more about the pause and freeze idea of this SIP.

Also what some already mentioned, it kinda worries me that like one wallet basically, can easily determine the outcome of any SIP. That makes it less decentralised imo and might need a little tweak for that matter.

Last I’d like to say, here since the beginning in ‘20 and still accumulating more SOV with Yield Farm. I believe in this project and that’s why I don’t check price often. Since the start Sovryn has been a long term mission/project, so I am cool with that.
Now I make a nuance. Price went now under Origins. That worries me a little. It shows that long term investors have lost faith. In this stage Sovryn needs the community to grow not to shrink :slight_smile:

I understood that audits are being done at the moment. I really hope (and I bet the team as well) to see Sovryn soon in a place where it’s ready to promote it to the world. Wouls love to see Sovryn in Beta being simple and easy to use, the rest will follow. Of course you’d want to time and polish it but pls show community the fruit of all hard work! From perspective of price they are screaming for it now.

Looking forward to read other comments on the SIP :point_right:t4:

1 Like

My keys, my coins. I don’t consent to any third party having control over my coins, even if it is “temporary”. I will no longer stake SOV. What other Sovryn contracts allow such actions to be taken on my coins without my consent?

I agree this is the kind of feature that should be reevaluated periodically. I would like to insist though, this is not a loss of decentralisation. Bitocracy is still the ultimate rights owner on the contract and can revoke pauser rights at any time. The protocol is still totally unstoppable in the long term. We just want to add an emergency brake that could help save our funds agains many kinds of exploits.

1 Like

Trust the smart contract.
But in the same way as you trust the Exchequer and the teams it funds to achieve our development and adoption goals, you should also trust that same team to wield a powerful tool that allows to protect our funds more efficiently. We are designing the pause/freeze feature to make it as fair and trustless as possible, not impacting the decentralized nature of our governance, yet allowing quick reaction to extreme circumstances.

[EDIT] I realize I did not answer your main question: this is more than a double security measure. There are already several layers of security measures to protect the protocol from malicious events, this is an extra layer of security that many of our contracts already have. The trend analysis of latest onchain hacks shows that without this tool (pause) on the very juicy Staking contract, we run the risk of seeing an exploit drain the contract, with the team having a bugfix ready for it, but being stuck waiting 3 days for its deployment, watching our funds be drained and washed in the meantime. The Pause feature fixes that.

1 Like

Im generally against stuff like centralization too, but the exchequer already has so much control over other funds, this doesn’t really seem like it makes a huge difference.

Im not trying to talk you in to anything, and I respect your opinion deeply. I’m just trying to explain why im being passive about it.

Our LoanToken is also Pausable. Making contracts pausable is often as much of a security requirement as protecting them from reentrancy, and sure enough, the LoanToken also has a reentrancyGuard on all functions that could be vulnerable to an exploit. The real question is who can pause the contract, with which speed, and when/how it will be unpaused. I agree there is room for abuse with such feature, so we welcome constructive criticism on how to make this feature as fair as possible.

We have tried to make even that concern much less pressing by designing a system where it’s impossible to prevent the owner from unpausing, and as long as the owner of the contract is Bitocracy, the contract is ultimately unstoppable, and the funds it contains can never be misappropriated nor selectively frozen by the pauser (nor by the owner).

I respect your opinion as well and I also consider safety important for any protocol. But this has to do with my stakes, and to trust some people that they will do the right thing (which I am sure all of them have best intentions for Sovryn - just to avoid any misunderstandings). Obviously people will say that more safety is better for my stake. True, but I am not a person that will trade one value for the other.

I am of the opinion that if there are SIP proposals that affect stakers there should be an option to unstake without penalties for those who wish so. The reason is stakers, especially those who staked early months, staked their tokens having several information and conditions in place. In previous months for example, there were big changes, including the reduced power of SOV with subprotocols (MYNT,ZERO,Origins) and countless discussions about how subprotocols are good for Sovryn. All the votes were in favour of course to pass those SIP’s but there were also people who voted No towards them to be independent mechanisms of the platform. Wouldn’t it be fair those who didnt want to give away their SOV power to have the option to unstake without penalties? Yes, 2 of them are going to be controlled by stakers now, but do you remember the whole discussions behind it? People have different values, different opinions, they think differently, they react differently. Asking everyone to agree for the greater good will always find people against this logic. And i dont disagree for the sake of disagreeing. I just dont feel comfortable with having anyone safeguarding my money.

I have no doubt that this SIP will pass when it comes to voting with 95%+ so those who are in favour have nothing to worry about.

2 Likes

Thanks for the reply. I may come off as hash and I know I’m a noob, but am open to learning, and I do have significant funds in Sovryn and I want Sovryn to succeed, but I also want to know my funds are safe. A single voter, 0x78a0DE7a48cCE1a8759f353987731394d5c0ffa7, passed SIP0041 all by themself with 82% of the vote. A single voter passing a proposal does not give me confidence this is a “decentralized” organization. I might as well open a Canadian bank account if a single entity can freeze my funds.

Blockquote
we welcome constructive criticism on how to make this feature as fair as possible.

Hard cap the freezing/pausing process to something like 7 days. Giving “bitocracy” the power to freeze stakes indefinitely is not “fair”.

1 Like

I exactly have this point of view. Okay governance can “unpause” if they feel the multisig parties are abusing their power. The only one good reason this SIP exists is we are in alpha and didn’t have any sufficient stress test. If devs say it’s necessary now why not …

So I will vote again because for me decentralization is as important as security.

I’m in support as long as Bitocracy retains Veto over the pausing actions of the Exchequer

2 Likes

I like the idea behind your suggestion, although it is not doable exactly as you describe it technically (it can be done so, but it would be gameable). There may be another way to achieve the same goal though, I will look into it.
But just to be clear, Bitocracy is us. Bitocracy rules the whole protocol at the moment and forever, unless we vote otherwise.

@arne - This does not allow any actions to be taken with your coins. Exactly the opposite, it stops actions being taken with your coins. This is a safety feature. This type of functionality is common across the crypto/DeFi/Bitcoin.

For example, Casa and other multisig Bitcoin providers offer this type of freeze function to secure against theft.

Sovryn, as is made extremely clear, is in Alpha. Taking appropriate precautions, especially during this phase is the prudent approach.

Security is the priority. By allowing Bitocracy to undo any pause, we maintain both security and decentralized governance.

3 Likes

Maybe a little bit off topic but when can we finally expect Sovryn going into beta?
The way I interpret your message is that because the project is in alpha, there need to be securety implementations… Which i can agree with. But if it will only be implemented starting in the near future, this signals that beta phase is not here yet for quite some time… The way this project is going gives me little faith lately. Community isn’t growing, nobody talks about Sovryn, no involvement whatsoever from the Pomp syndicate (maybe there is but it isn’t visible),…

Concerning this topic. If there is an ability to freeze stakes (=coins) this means that people do not have fully control over their funds and we will have to trust a third party. I understand the security reasons but it doesn’t give me a good feeling.

What are the actual risks that could happen if the staking contract isn’t able to be paused? I’m not familiar with the contract.

What kinds of assets and how much of them does it hold at any given time? I’m assuming it holds all the staked sov, does it hold fees or sov rewards or anything else?

If an exploit happens and someone steals all the staked sov, how could pausing or freezing after the fact help?

Thanks!

What are the actual risks that could happen if the staking contract isn’t able to be paused?

We would be left defenseless against several kinds of exploits that could otherwise be thwarted, partially or even entirely.

What kinds of assets and how much of them does it hold at any given time?

I’m assuming it holds all the staked sov, does it hold fees or sov rewards or anything else?

It is a key piece of our protocol, here is a slightly oversimplified view. It holds staked SOV, has access to the rewards (because it distributes them to SOV stakers), and it is the basis of our governance: your voting power is determined by how much you have staked compared to others and the total, in other words, our voting power is stored inside the staking contract.

If an exploit happens and someone steals all the staked sov, how could pausing or freezing after the fact help?

It cannot help in that case. But it is far from being the only scenario, nor the most likely to occur. Some exploits work over time, and if they get noticed quickly, the drain can be stopped, IF there is a pause function, mitigating the attack by up to 90% in some cases.
Also, there are great strides being made in techniques for watching the mempool and detecting hacks before they get mined. Being able to add such a tool as a pauser will turn out very useful in the future to further enhance our resilience.
There are many other maintenance and live test scenarios, frequent during alpha stage, that also would be much simpler and safer if the contract was pausable.

This being said, at some point our protocol’s core contracts will be provably unbreakable and we will be able to set them in stone, deploy them adminless and forget about pause features and failsafes. Today we are in alpha, we push the envelope very fast week after week, we need to keep some flexibility to maintain that pace while never letting security take second place. This pause function is being proposed to protect our funds and our voting rights during this wild journey through DeFi and towards self-sovereignty.

4 Likes

Another interesting scenario I forgot to mention is if one of the protocols we forked is the victim of an attack, or if we recognize a code pattern we have in our code, that has been exploited in another protocol recently.

It might take a while for the hacker or the army of copycats who monitor blockchains to realize we are another potential victim. On the other hand the dev team watches closely all hacks in the various evm ecosystems as soon as they are disclosed.
If such a scenario happens, and we notice before the hacker, having a freeze function is a surefire way to protect our funds while we develop, test, set up to vote and finally deploy our fix.

Without it we are but sitting ducks.

5 Likes