Leadership doesn’t answer to shit. I asked a question about a weird part of the “Most important SIP” a month ago, and “leadership” can’t seem to muster the energy to type a fuckin paragraph.
Either they don’t give a fuck, or they’re too lazy to ape slap some keyboard keys. Either way, I doubt they will be providing anything.
They had this beautiful project, and fucked it up because of greed and overconfidence.
Requesting an SIP for the removal of staking rewards is hardly something that needs any serious debate. Literally all they had to do was put an sip up. Why didn’t “leadership” just do a proclamation SIP instead of strong arming Stakers? After just a month or 2 ago ADVERTISING SOV as a yield product. You can’t be serious that “leadership” can have an honest conversation about anything anymore.
So we just wait another some years for a few numbers on a spreadsheet and let team continue to operate without any acountability.. so Mike doesnt have to worry about next paychecks. Bit exaggerated, but thats exactly how this convo comes across.
The fact that this contract was basically hijacked some days ago isn’t noteworthy at all? At least not for the people who proclaim security and stability and what not as their mantra. Yago doesnt’t even care to reply at all to his own SIP topic.. why? Because he eventually found out that instead of talking with the stupids he can just take over the contract and be done with it?
I can understand team doesn’t like the fact that Brianna found out all this.. but still team should be happy and even thank and grant Brianna for all the work done. “Protocol is open to anyone who wants to participate” .. yeah, until someone does.
I thought this was implicit, but let’s walk through the scenario carefully.
Assume the SIP passes and disrupts the fee flow that was intended — at least as communicated — to help refill the treasury. If that materially impacts runway, leadership could issue notice that they are winding down operations due to lack of community support.
What happens next?
Are you or Bitocracy prepared to rebuild and operate the entire infrastructure stack from scratch — backend services, indexers, monitoring, security, deployments, support — all of it, or will just be happy with the smart contracts ownership? The real operational costs alone will not be anywhere near $20K per year once you account for infrastructure, maintenance, and reliability requirements — and that’s before even considering team compensation.
And even more importantly: if leadership exits, who assumes full responsibility? Not symbolic ownership — actual operational, legal, financial, and technical responsibility. Is there a named team? A transition plan? A development roadmap? Funding commitments?
Or are we again relying on “we will figure it out”?
These are execution questions. Without credible answers, this is not a controlled transition — it is a high-risk disruption.
Was it an exploit? SIP-0046 had a limited, specific list of contracts that were given under control of Bitocracy. FeeSharingProxy was mentioned as exception in this SIP. Ergo: labeling it as exploit is misleading and deeply incorrect. We need to stick to the facts.
Mynt, Zero, Staking, and FeeSharingProxy were already owned by Bitocracy. Zero for instance, since it was created later June 15 2022 (while bitocracy was already established) was transferred to Bitocracy ownership immediately after the contracts were deployed and configured by the deployment EOA - exchequer never had control of those contracts. Obviously theres was a big reason FeeSharingProxy and Staking, were already owned by Bitocracy.
Even if for whatever reason you are right and FeeSharingCollector was in control of exchequer at that point, SIP 46 also declared Exchequer was to transfer all ownership of contracts that did not require 2 way acceptance of Bitocracy for the transfer to complete. Which they apparently did follow through with as every contract that doesn’t require accepting ownership is currently owned by TimelockAdmin or TimelockOwner.
To mitigate risks to Exchequer Multisig keyholders and to the Sovryn protocol and its users, we propose transferring ownership and administration of all Sovryn contracts currently owned by the Exchequer Multisig to either the TimelockOwner or TimelockAdmin contract, as specified in the tables in the Description section above. This will put the contracts under the control of SOV stakers, increasing the decentralization and censorship resistance of these contracts.
SIP 46 only defined bitocracy parameters for contracts that required a 2 way handshake for accepting transfer of ownership. All other contracts exchequer could, and did, simply transfer to the Timelock addresses. But even the contracts, which required bitocracy parameters, exchequer had to initiate the transfer. FeeSharingCollector was not one of them because it was already owned by Bitocracy. Up to this point I have not run across any other core contracts owned by exchequer.
I can only say you’re sort of spiraling into “what ifs.” Let’s take a look at how the treasury once upon a time operated:
Exchequer provided a budget and Bitocracy voted to approve the funds from the treasury and transfer them to exchequer. No one died. The team didn’t abandon their roles or responsibilities. No one needed to take over setting up servers. Leadership didn’t wind “down operations due to lack of community support.”
In a worst case scenario you describe, which is not a reasonable risk, yes I am prepared to run the backend servers needed to run sovryn. I really think you must not have IT experience as literally no components in the sovryn backend are expensive besides the rsk nodes - which I already have 3 mainnet running for around $1k/month for another project. Try running an ethereum node if you want expensive (one of mine with the compute and ssd space required is like $500/month) I’m sure bitocracy would vote, in this extremely rare scenario you describe, to help fund the likely less than $20k per year IT expenses needed to run sovryn dapp. Literally you’re talking about a web server serving a website, rsk rpc nodes, and subgraph database. Sovryn doesn’t even have a custom service handling rpc calls. They are all just interfacing with the rsk nodes directly. I really think you are out of your element if you think that costs $200k/year lol.
The beauty and major selling point of sovryn is that everything is open source and anyone can run the dapp. Anyone can interact with the contracts on the rsk blockchain. Whoever’s been selling you this idea of immense IT overhead is really selling you a bridge somewhere.
Brianna, I think we’re going in circles at this point.
If my cost estimates seem unrealistic to you, that’s fine — we clearly have very different views on the operational scope involved. From my perspective, the figures being mentioned materially underestimate what it takes to run this properly in a production environment. Referring to “3 nodes” as sufficient ignores the reality that even that represents just a minimal cluster. That’s not a resilient, production-grade setup — it’s a starting point at best.
I’ve spent considerable time outlining my concerns around financial constraints, infrastructure complexity, and execution risk. Repeating the same arguments likely won’t move this discussion forward.
Let’s leave it here and allow the broader community to read through the thread and form their own conclusions. Ultimately, the decision — and the responsibility that comes with it — will rest with the voters.
Lol ok I think it’s important that you understand: local exchange carriers who handle all phone calls for entire cities run class 5 switches with ONE backup side. These are switches designed to have 99.999% uptime. That means literally millions of phone calls per minute depending on services as important as actual life or death phone calls to emergency services depend on the reliability of 5 9’s uptime “99.999%”. All of this hinges on long term designs of a master device and a slave device.
So claiming 3 rsk nodes is not enough for high availability of rsk transactions is really showing you’re out of your element. Have you ever heard of high availability designs of airplanes? lol
I shared with Hyde the exact costs for running an rsk node.
If you want to be really really super safe and you have 10 of these running - because you’re just crazy and love burning electricity doing nothing useful. That’s $24k/year! Please help me understand by providing any actual numbers for how you’re getting to $200k/year!
I think it’s obvious you have no experience running an rsk node. They are not high compute or high bandwidth intensive. rsk handles on average 10 transactions a minute! That’s the entirety of the Rootstock blockchain generates just 10 transactions on average in a single minute. How much cpu overhead or disk space do you imagine that generates? Then please consider that means Sovryn, specifically sovryn users, all of it’s contracts and webservers, and rsk nodes are handling LESS than 10 transactions in any given minute from all the users of sovryn. Think about how little traffic and compute resources are needed if sovryn servers at most need to handle on average 10 requests (to do any interaction with the sovryn contracts) in an entire 60 seconds. That’s 6 seconds all of the compute power on sovryn needs to handle any single user transaction updating staking information, or converting tokens through the AMM or opening a loan on Zero. What world are you living in when 1 transaction per every 6 seconds costs $200k dollars in computing resources!?
To provide even more information for you here’s the load on just one of my rsk high compute servers with 4 cores handling all 10 transactions per minute lol:
If you’re not familiar with load average that means this server uses around 5% of it’s compute power. You wouldn’t be shocked to know GCP constantly reminds me I can save money on these servers by scaling them down lol.
I would encourage you to provide any cost numbers you can to explain your assertions. Pick AWS or GCP and build out your most demanding cluster of rsk nodes that you want, and we can ignore committed use discounts. It would be really interesting to share what kind of insanely over powered network you’d come up with that would cost $200k/year .
Aww gawsh, your kind words really mean a lot!! I do have a lot of experience in those two areas, but yes I would absolutely need help in sooo many other areas. I’m really hopeful that if we can make some traction in setting sovryn back on a proper course, that others who have those skills in other areas or even technical (gosh it would be soo cool to have some more programmers jump in) can also step up to help build the sovryn we all want.
Step one is just getting full control of the contracts and securing Bitocracy. If we have actual control of bitocracy including the treasury then I see so many positive changes we can start making from there.
If you do not know how to delegate. Go to your stake app, click on adjust next to your VP and there you will see a delegate button, costs about 2 to 4 dollars…
The Sovryn team has completed the technical review of PR#574. Following this review, the PR requires changes before it can be approved. The main considerations are outlined below.
Brief for Non-Technical Stakeholders
This proposal aims to upgrade the FeeSharingCollector, the component responsible for collecting and distributing user fees. However, the current implementation introduces a design inconsistency that would require additional coordination and changes before it could be safely adopted.
What the proposal currently does
Instead of performing a clean upgrade, the change unintentionally results in two different FeeSharingCollector contracts:
The current contract
This is the contract currently used by the Sovryn app and existing scripts.
Users’ accumulated fees are stored here.
A newly deployed contract
This contract is intended to be used by the protocol going forward.
However, the Sovryn app and existing automation are not currently configured to interact with it.
Why this creates challenges
If both contracts exist simultaneously:
User fees would remain in the existing contract while the protocol intends to transition to a new one.
The Sovryn frontend and scripts would still reference the existing contract.
Users might need separate withdrawal processes to access all their fees.
In some cases, withdrawing smaller balances from the existing contract could become economically inefficient due to gas costs.
Operational considerations
Supporting this approach safely would require:
Coordinated updates to the Sovryn frontend and scheduled scripts
Additional migration logic and testing
A clear mechanism for users to claim fees from both contracts
Without these measures, the user experience could become confusing and some users might have difficulty accessing their fees.
Conclusion
In its current form, the proposal introduces additional complexity and creates inconsistencies between the deployed contracts and the protocol’s deployment metadata.
For these reasons, the Sovryn team recommends modifying the proposed approach to ensure a single consistent FeeSharingCollector contract and seamless integration with the Sovryn application.
The team will be happy to continue the review once the requested changes are implemented.
This post serves as the official Sovryn team technical review of the proposed solution and the SIP and is intended as an announcement rather than a discussion thread.
.
I do have a lot of experience in those two areas, but yes I would absolutely need help in sooo many other areas. I’m really hopeful that if we can make some traction in setting sovryn back on a proper course, that others who have those skills in other areas or even technical (gosh it would be soo cool to have some more programmers jump in) can also step up to help build the sovryn we all want.