SIP-0088 Emergency Revert FeeSharingCollector Changes and Set New Proxy Contract Ownership to Bitocracy

Bitocracy
1

Description

Exchequer has ownership control of the FeeSharingCollectorProxy contract and 2 days ago changed the implementation contract that removes staking fees for stakers and diverts them to exchequer Update FeeSharingCollector to withhold part of fees to the protocol (… · DistributedCollective/Sovryn-smart-contracts@5429b56 · GitHub . This in an emergency SIP that will create a reverted FeeSharingCollectorProxy and FeeSharingCollector implementation contract (from the parent of commit 5429b56^) with ownership assigned to the Bitocracy governance contract address (0x967c84b731679E36A344002b8E3CE50620A7F69f). This is in line with all sovryn protocol and zero contracts.

Once this is done, there will be a followup SIP to change the implementation address to a new version to include diverting a percentage of fees to the GovernorVault contract 0x51C754330c6cD04B810014E769Dab0343E31409E. From the GovernorVault Bitocracy can vote to release funds to exchequer based on a proposed budget request. Details of this update will come in a new SIP for further discussion and exchange of ideas on that forum post. The majority of these code changes are already finished and ready to be implemented. Let’s avoid discussing this until that forum post is made, and keep this discussion only to reverting the FeeSharingCollector changes.

Proposed change

Revert FeeSharingCollector to the parent 0557646 commit before the latest update to the FeeSharingCollector contracts and set the owner and proxy owner addresses to governance 0x967c84b731679E36A344002b8E3CE50620A7F69f not exchequer.

Whitelisted Converters has been set to:

Final list: [
  '0x60CC333072f16d5F4CB2bC36d6Aa1F00381E22C2',
  '0x88A67a0e79e311fe93C6e2101d55d6d2Ae3a7E94',
  '0xD8397c1944862b6a9674c85A5496c208Dc9417BB',
  '0x150Bc1f9f1020255d44385865928AAdc6b7AD9F3',
  '0x34163BB263AC77E9d6315676a2B9624CFC5ff861',
  '0x832769CC15dBDd6814819988c7A875EC2cB943e8',
  '0xf6377deC9ce79b5bC0576618A5cd3e95f49f9ace',
  '0x25B8D024B39174824424f032423E03dd7dcCF044',
  '0xe76Ea314b32fCf641C6c57f14110c5Baa1e45ff4',
  '0xe321442DC4793c17F41Fe3fB192a856A4864cEAF',
  '0xa57Ec11497f45fe86ECA50F4f1c9E75C8016A1aF',
  '0x1684B871ec5F93dE142E79a670B541D75BE07Ead',
  '0xA9c3D9681215eF7623dc28eA6b75bF87fDf285D9',
  '0xDEB0894196863Dbb2F2D4C683f6D33a2197056B5',
  '0x65528e06371635a338CA804cd65958a11cB11009',
  '0x3a18e61D9C9f1546DeA013478DD653c793098f17',
  '0xE81373285Eb8CdEE2e0108E98C5Aa022948DA9d2',
  '0x4531DD0f24D204c08b251084E12ce3D3e70Dd03e',
  '0xF1DeE3175593f4e13a2b9e09a5FaafC513c9A27F'
]

New Proxy contract exists here: Rootstock address details for 0xd16457c2495406783deca731f90f6284d09eafb1 | Blockscout

With it’s implementation here: Rootstock address details for 0x5d539131c0eb5237753beb7a4d60a3bb6ecdd96f | Blockscout

Owner and Proxy Owner have both been transferred to Bitocracy TimelockOwner contract: 0x967c84b731679E36A344002b8E3CE50620A7F69f

Actions (targets + function calls):

TimelockOwner (0x967c84b731679E36A344002b8E3CE50620A7F69f)

  • SovrynProtocol (0x5A0D867e0D70Fcc6Ade25C3F1B89d618b5B4Eaa7) → setFeesController(address) = 0x000000000000000000000000d16457c2495406783deca731f90f6284d09eafb1
  • Staking (0x5684A06CaB22Db16D901FEe2a5c081b4C91eA40e) → setFeeSharing(address) = 0x000000000000000000000000d16457c2495406783deca731f90f6284d09eafb1
  • FeeDistributor (0x1261d5872d56e2Ab61B3C68451D015b752105027) → setAddresses(address,address,address,address,address,address,address) = 0x000000000000000000000000d16457c2495406783deca731f90f6284d09eafb10000000000000000000000005369941b2a08db3fec31c4a6cd3b902f7b1468a30000000000000000000000005b9db4b8bdef3e57323187a9ac2639c5dee5fd3900000000000000000000000082b09695ee4f214f3a0803683c4aaec332e4e0a3000000000000000000000000542fda317318ebf1d3deaf76e0b632741a7e677d000000000000000000000000db107fa69e33f05180a4c2ce9c2e7cb481645c2d000000000000000000000000f294ea272d6f8fedc08acf8e93ff50fe99e1f7e8

TimelockAdmin (0x6c94c8aa97C08fC31fb06fbFDa90e1E09529FB13)

  • SwapSettings (0x3aB00BEFDd7Bfc0667DE6483D2D3b2F9A74AF2da) → setFeesController(address) = 0x000000000000000000000000d16457c2495406783deca731f90f6284d09eafb1

Thank you all for your time, support, and efforts! I really hope we can make positive changes in the right direction to instill confidence in sovryn users and stakers.

Background

October 15th 2021 transactions 0xdb6f399d2ecb08c04ac6e69b55d559f5093f9b9c386d9abfece37df905dc1d26 and 0xd095df4d1db537d53e3cf916c19f98bcbf6e0aedde3b8b762c050977bc4c3312 assigned the exchequer multisig address (0x924f5Ad34698fD20C90fe5d5a8A0ABD3b42dC711) as proxy owner and owner of FeeSharingController contract (0x115CAF168c51Ed15Ec535727f64684d33B7B08D1).

On October 24th 2023 SIP-0046 executed through Bitocracy with 100% of the vote in favor. The first two sentences in the Proposed Change subsection of SIP-0046 state:

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.

FeeSharingCollector as far as I’m aware seems to be the only Sovryn contract still in control of exchequer, suggesting exchequer either overlooked this contract or intentionally obfuscated their ownership.

Updates

As requested by French and Tyrone a pull request of code changes (reverting code back to pre-5429b56 version) has been submitted to the Sovryn-smart-contracts repository: Pr/feesharingcollector v2 SIP-0088 by bribri-wci · Pull Request #574 · DistributedCollective/Sovryn-smart-contracts · GitHub

It should be noted this code reverts the commit Tyrone authored and executed without the consent of Bitocracy violating sip-0046 Update FeeSharingCollector to withhold part of fees to the protocol (… · DistributedCollective/Sovryn-smart-contracts@5429b56 · GitHub

NEW UPDATE - Vote Date

A proclamation passed with the most VP of any SIP all the way back to 2022 with every single vote for the proclamation. The proclamation directs exchequer to transfer FeeSharingContoller back to Bitocracy TimelockOwner. Yago has stated they will not follow this proclamation. This would have been the easiest solution for everyone including the developers.

Since exchequer refuses to follow the proclamation and Sovryn marketing also refuses to announce to the community anything relating to SIP-0088 on their X account or other socials (even though this was listed as a requirement for SIP-0088 to be valid) we are going to commence the vote for SIP-0088 on Friday March 20, 2026. Please everyone come out and make this a historic vote once again.

5 Likes
2

I do support the idea that some of the collected fees go to exchequer. It would be great if Sovryn can sustain it’s devs and it’s cost with the generated revenue.

However, it must not be possible to change the feesharing without a SIP. This was a big mistake and must be corrected. All contracts have to be owned by Bitocracy.

So far, stakers had an incentive to use the rootstock Sovryn dapp because despite the high cost of using it, it generated revenue for Sovryn stakers. Now that stakers (i.e. Users) dont get anything from using the rootstock dapp, volume is likely to drop further and revenue is going to drop further. This must be fixed.

4 Likes
3

I haven’t been participating in forum discussions - simply because I don’t have the time. I focus on building and working. Sovryn has been helping me pay my bills, so I care deeply about its stability. What I’m seeing now is frustrating and disappointing, even though I understand where some of the concerns are coming from.

TL;DR
I understand the frustration. Transparency must improve.
But both this SIP-X and SIP-00XY, as written, introduce serious operational risk without presenting a credible continuity plan. Removing leadership and reverting ownership “on urgency” is not the same as responsible governance.

I want to start by saying clearly: I understand the concerns around transparency and treasury activity. I share some of them. Things need clarification. Reporting should improve. Governance should mature.

But the way this is being approached feels reactive and rushed — and not grounded in what it actually takes to run a production DeFi protocol as a real business.

1) Infrastructure cost assumptions are not realistic

The 20k/year server estimate is simply not credible.

For a protocol of this size running:

  • RSK nodes
  • subgraphs / indexers
  • backend services
  • frontend infra
  • monitoring and alerting
  • redundancy and security tooling

20k/year is off by a large margin. I work with this type of infrastructure. A realistic range is closer to 200k/year, possibly more depending on redundancy and security posture.

If the baseline cost assumptions are wrong, then the “mismanagement” narrative and emergency framing built on top of them need to be re-examined carefully.

2) SIP-X: Emergency revert + ownership transfer

Reverting FeeSharingCollector changes and transferring proxy ownership to Bitocracy in an emergency vote is not a minor adjustment — it is a control shift.

Before doing that, we need to answer:

  • Who operationally executes decisions the next day?
  • Who carries responsibility for treasury flows?
  • Who responds to production incidents?
  • What safeguards prevent governance capture?

Two addresses already represent ~23% VP in this vote. That is not broad legitimacy — that is concentrated influence. Emergency structural changes with low participation are dangerous precedent.

Governance reform cannot mean operational destabilization.

3) SIP-00XY: Leadership removal without a continuity plan

Removing Yago, Armando, and FrenchVictory within 48 hours before a fully defined interim structure exists creates a governance vacuum at the highest-risk moment.

“Top 5 by vote” to form an Interim Stewardship Council does not guarantee:

  • Verified competence
  • Relevant experience
  • Availability
  • Accountability

Sovryn is not a forum experiment. It runs production infrastructure. It pays contributors. It secures user funds.

For smaller players like me, this is not theoretical. This protocol’s stability directly affects sustainability and income. Replacing operators without a concrete operational handover plan and secured runway is not reform — it is destabilization.

4) The runway question

Yago stated the treasury refill is an emergency temporary measure. You may disagree with how it was executed. Fine.

But what is the day-after plan if it’s cut off?

  • Do payrolls stop?
  • Do key contributors leave?
  • Who maintains infra?
  • Who approves expenses?
  • What is the guaranteed runway?

If the answer is “we’ll figure it out,” that is not governance. That is risk.

5) What a responsible path would look like

If the goal is real reform, then propose it properly:

  • Clear definition of Bitocracy’s operational scope and limits
  • Realistic, itemized cost breakdown
  • Secured 12–24 month runway model
  • Defined transition plan with no operational gap
  • Named, verified candidates with relevant experience
  • Explicit acceptance of responsibility

Anything less is turbulence during an already fragile moment.

I’m not against reform. I’m against hasty structural moves that introduce existential risk.

Yes — improve transparency. Strengthen governance. Increase accountability.
But do it in a way that protects continuity and sustainability, not in a way that risks collapsing operations in the name of urgency.

And one more thing: please abstain from discussing my position or this post. I will ignore such attempts. What matters now is not debating me — it’s what you are prepared to do. Governance means responsibility.

3 Likes
4

Hi Mike! Thank you for your well thought out comments!

  1. I have a similar project on Rootstock running right now with full rsk nodes with load balancing redundancy all for just over $10k/year on GCP. I was being liberal with the suggestion of $20k/year. You would have to actually put some numbers in place for me to understand how you could possibly come up with a number even larger than $30k a year? I’ve designed telecom networks for over a decade and set up full cabinet direct exchange connects in Equinox for example with CME In Chicago and EBS in New Jersey. None of these networks have cost anything close to $200k/y and all of them have had significantly more processing, latency, and bandwidth requirements. I’m sure there are many IT professionals reading this so it would be helpful for them to chime in their experience with similar project costs. I just want to add this doesn’t really stay on topic with the sip, but I thought important to respond. We’re not voting on how to fund operations with this sip. That’s for a follow-up sip that could in effect do exactly the same as what exchequer did by securing 100% of the system revenue in the GovernorVault, which then could be dispersed to exchequer. So this could all end up exactly how exchequer wants, but the goal here is to do it the right way with community oversight.
  2. It’s actually not a control shift. All of these contracts were switched to bitocracy ownership years ago. SIP 46 submitted by light had many phases of switching all the contracts from exchequer owner to governance timelock owner/admin SIPS/SIP-0046_part-1.md at SIP-0087 · DistributedCollective/SIPS · GitHub. How FeeSharingCollector ended up back in control of exchequer is concerning and I’ve been trying to find the transaction where this occurred. It seems to be the only contract that isn’t in control by bitocracy. I’m pretty sure most sovryn users were shocked no sip was needed to highjack the Feesharing contract.
  3. Let’s try to keep this on topic for this sip. This sip has nothing to do with the other one SIP-00XY. I personally had nothing to do with it and I find it reactionary to the emotional response of the team to highjack the Feesharing contract from the fall of Bitcoin. Let’s just concentrate on making sound decisions going forward and do our best to fix the mistakes made that we can. Progress is important not tearing everything down.
  4. The day after plan is exactly how everything has been going. The only difference is if exchequer wants to secure the funds to help with operations from the Treasury it must submit a sip and secure a community vote. That’s it. Likely for people to vote in favor we’ll want to see some sort of budget that explains simple category line items of expenses. Just like any company would submit to their board. This shouldn’t be breaking anything. It should be improving transparency and driving efficiency. I’ve been a board president for a $mm org and a good friend of mine was the executive director. We still required them to submit a budget every year and we voted on it to secure the operational funds for the next year. No matter how much I trusted him and all the department heads it was still best practice to see the budget and revise it over the months of October and November for the final vote in December. This is for everyone’s benefit including the team! If there is no money available because we’re spending ourselves into a hole changes have to be made. The only way this can happen is if we actually know what the expenses are. I hope this helps!
  5. All great points! I completely agree with all of them! Thank you. I would just say that this sip isn’t intended to address leadership roles or anything like that I worry it’s being conflated with sip-00xy that’s unrelated topic. So yes if we could do our best to focus on this sip and move to secure this one contract that somehow was changed back into exchequer control that would be amazing!

Thank you again for all your thoughtful responses. These are so important to this discussion. I appreciate your help!

4 Likes
5

I agree completely! Thank you for your input Sacro! :pink_heart:

For everyone: I just want to reiterate this sip is just to secure the FeeSharingCollector contract to it’s previous state and set the owner and proxy owner to Bitocracy TimelockOwner - just like every other Sovryn contract. The steps after will take followup sips to decide how we can best move forward to support operations with system revenue (which I as well am all for).

4 Likes
6

Brianna, I’m sorry, but saying this is “just” about reverting the FeeSharingCollector ignores the broader context.

From what was communicated, the recent changes were described as a temporary measure to refill the treasury and navigate a critical situation. Whether you agree with that decision or not, that context matters. Treating this as a simple technical revert detached from the operational reality isn’t accurate.

You’re focusing on restoring contract state, but I’m asking about continuity:

If this is reverted immediately:

  • how is treasury stability handled?
  • how is runway secured?
  • how is the team expected to continue operating?

That’s the part that’s missing.

I appreciate the initiative to step in and try to address concerns. Truly. But right now this feels reactive — addressing a control surface without presenting a concrete plan for sustaining operations.

If there’s a structured plan that ensures continuity, runway, and team stability, I’m open to reviewing it. Until then, reverting things in isolation feels like pulling one lever without considering the system-level impact.

I’m waiting to see a more comprehensive and sustainable proposal.

7

Hi again Mike! The biggest parts we’re missing is we actually have no idea how much money the exchequer has to cover operations and we don’t know what the operational costs are. All we’ve been told is they don’t have enough and need to take all the fees. This is a problem, because we only really know a few things:

1. The treasury had over $4mm controlled by exchequer just over a year ago.

  1. We can see from rootstock transactions around $800k was converted to BTC in December-January and then transferred out of Rootstock.
  2. As of right now we can only see exchequer has just under $200k in tokens left in the multisig address: Rootstock address details for 0x924f5ad34698Fd20c90Fe5D5A8A0abd3b42dc711 | Blockscout
  3. If you look back even further in exchequer transactions you can seem millions of dollars worth of rBTC transferred out of rootstock at 30BTC at a time over the last few years never to be seen again in exchequer’s wallet.

These are all we know and no matter how much we ask for transparency we’ve been denied. I’m not sure how new you are to Sovryn, but the contracts always were intended to be under complete control of Bitocracy. Fees generated by the system were always intended to go to stakers, so much so it’s even written in the first comments of the code I’m currently reviewing for the FeeSharingCollector contract:

/**
 * @title The FeeSharingCollector contract.
 * @notice This contract withdraws fees to be paid to SOV Stakers from the protocol.
 * Stakers call withdraw() to get their share of the fees.
 *
 * @notice Staking is not only granting voting rights, but also access to fee
 * sharing according to the own voting power in relation to the total. Whenever
 * somebody decides to collect the fees from the protocol, they get transferred
 * to a proxy contract which invests the funds in the lending pool and keeps
 * the pool tokens.

As I’ve stated multiple times, I personally am not against using some percent or all (in an emergency period) of the protocol fees to support the treasury, however I am completely against the executive team on a whim with zero support or attempt at garnering support from governance essentially stealing promised revenue for users who voluntarily purchasing and staking sov under the agreement that they are already supporting the development of sovryn via purchasing the tokens the sovryn team sold. Think about the importance of what they have done to the token’s value and trust.

If you hold sov and have staked it, I would think you would understand the importance of securing contract trust with the users of sovryn.

As for your other questions:

  • Treasury stability is currently handled by exchequer - nothing changes via this SIP.
  • I’m not sure what you mean by a runway secured?
  • The team as we currently understand has at least more than $500k at their disposal this moment. That is not the concern of this SIP. As I mentioned I’m planning on introducing a followup sip to discuss diverting a percentage of fees to the GovernorVault contract that already exists for the purpose of further funding exchequer if necessary. But that is for the discussion on that sip. I hope you can understand these are very different topics and can be voted on seperately.
4 Likes
8

with all mentioned infra elements:

What is the complexity of what You’ve build on RSK?

I am afraid that You underestimate the size of Sovryn, multiple components and subprotocols are working together. The closest comparation on RSK would be MoC - but still less complex IMO.

It is hard to compare telecom and blockchains.

That is why I think that financial report is needed prior to the SIP.

1 Like
9

Hey Hyde! First, thank you for looking at this SIP! Now into the response lol:

None of what you mentioned besides the rsk nodes are high bandwidth intensive or compute intensive and especially not latency sensitive. The networks I described processed millions of calls a day and millions of packets per second of market data. Think about the seer volume of voice data and market data that for instance the CME produces via multicast on all their contracts and options contracts (CME uses FIX/FAST which is a compressed version of FIX that also needs to be decompressed before the applications can read it - lots of compute overhead) and don’t get me started in the compute resources needed in telecom for voice codec transcoding and signal processing!

Sovryn is absolutely a large project I don’t disagree. But most of it is contracts on rootstock that is handled by the rsk network. rootstock on average has about 10 transaction per minute. That’s not a network that requires serious compute. While I don’t doubt there’s resources needed, it’s no where near the level of 100k/year and would be hard to argue over 30k/year. A high compute VM with 1TB SSD (which rsk dosen’t even need 250GB right now) can easily run an rsk node for less than $200/month. Try to explain how you get to $100k/year even if you for whatever reason had 10 of those (I don’t know why as two or three are plenty for redundancy). And then we’ll assume you’re not securing a lesser price by agreeing committed use discounts. I’ve been as liberal as possible in these estimates.

If Sovryn is actually spending what’s being suggested on network infrastructure then I would seriously look into embezzlement.

As for my rsk project, yes it has all those services except for subgraphs. I wrote a custom service that indexes all the rsk contract events for streaming back to clients via websocket.

But again all these topics are really not at all related to this SIP! :slight_smile:

6 Likes
10

so happy we have Brianna coming in to the rescue as most of the others are completely exhausted, and looking into these transactions finding critical evidence that is being overslooked

we are in a situation where exchequer/ Armando is moving funds without the knowledge of rest of the “company shareholders” and this is potentially in the millions of dollars

at the same time they branched off BOS (YES, because community calls stated in 2023-2024 we at Sovryn were developing this)

and suddenly they was funded privately by “early bitcoiners using their own money” quoting YAGO. So a lot of money has been funneled into this BOS project at the exact same time financial reports are absent & we clearly see a connection between bigger marketing push for BOS, new team hires, etc

then the obvious failure of BOS price at the exact same time Armano/ Exchequer in a rush sells all available DLLR 800k, as if, their plans met market turbulence and they want to buy more time for themselfs

6 Likes
11

so all of this compiled is not hard to understand (unless your a completely ignorant and morally corrupt individual)

-BOS was funded by funds from SOVRYN, potentially these 4 million dollar Brianna is referencing

(potentially MORE considering the exit liquidity of ~12m dollars BOB-pools made possible)

-BOS saw significant promotional efforts & hiring meanwhile SOV became completely stagnant

- BOS fails in November-Decembers market turbulence & DLLR gets moved out of Exchequer

(Yago believed bull market was around the corner, according to himself on multiple podcasts)

7 Likes
12

Aww thank you, I appreciate the support! I don’t blame people for feeling exhausted. I’ve felt that as well. I think now is finally the time for action and to start writing code to improve sovryn and bring progress in a positive direction. Hopefully most of us agree.

5 Likes
13

I don’t mean to be nitpicky here but the way I see things, Sovryn decisions were always controlled by very few addresses, which almost always belonged to the core team. Bitcocracy being “community controlled” was always a pipe dream. Yago himself said once not being able to quote him verbatim that bitocracy has nothing to do with democracy and in bitocracy the ones with the most skin in the game get to have more weight in deciding than those with less. I never liked statements like that especially coming from core team or so called leadership figures as we all know it is easy to say such things when you haven’t paid the tokens from your own pocket. Anyway seeing bitocracy turn out in favor of the community with a watertight plan, which is above my head anyway would be a thing I’d love to see. I do share your concerns that something could be broken in the process will it be another fork that is really controlled by bitocracy or will it be the current version where some dev might have built a backdoor to pull the plug at will? We will see.

3 Likes
14

Fortunately those two addresses are not the team. Economic incentives are powerful and people with the most to lose have the incentive to not destroy their investment - no one more so than those who bought their SOV.

It’s very possible when passing sips things will get broken. That’s anything that gets upgraded. Fortunately they can all be fixed as these contracts are all upgradable proxies. This current sip is simple as it reverts to verified code that was working (and it’s been cross compiled by the explorers to verify the code is 100% the same). The biggest risk we have is that I missed updating the address in a contract somewhere in sovryn that needs the FeeSharingCollectorProxy address. I’m pretty sure I’ve accounted for all of them, but I’m hoping others with their knowledge of Sovryn like Hyde, CEK or Luka can double check and make sure that if this sip passes that we targeted them all. If I missed one, it means some of the fees will still simply go to the old contract that exchequer highjacked, so you weren’t going to see those fees anyway. Essentially the risks with this sip are limited. And if we find we missed something we can run a new sip to patch that address where ever it is.

Exchequer essentially exploited bitocracy somehow in the past and managed to get their address assigned as owner and proxyowner on one of the most important contracts in the system. This sip is essentially patching an exploited contract. The risks here are small.

4 Likes
15

Hi Chris!

Unfortunately I have not received a substantive response to any of the material concerns I raised. That suggests the initiator and supporters either do not fully understand the implications of what they are proposing, or they are choosing to disregard them — possibly both.

My position remains unchanged: the current “revolutionary” approach is irresponsible and potentially harmful. It introduces unnecessary risk without adequately addressing the technical, operational, and governance consequences.

The FeeSharingCollector itself is not the issue. The stated goal of “returning ownership to Bitocracy” may sound principled, but the downstream implications have not been adequately examined. The risks have not been properly acknowledged, nor has a concrete mitigation framework been presented. Without a rigorous assessment of second-order effects, such a transition is not decentralization — it is uncertainty.

My suggestion is to extend the timeline to allow for broader and more substantive discussion, require the current leadership to provide clear and concrete responses to the outstanding questions, and publish a transparent financial report. With that information in hand, we can establish a solid factual baseline, develop a structured and data-driven plan, and move forward through properly aligned and coherent SIPs rather than fragmented emotional initiatives.

1 Like
16

Mike again, I don’t know just how new you are, but getting leadership to be transparent has been a problem for years and is extremely unlikely to happen in a matter of days let alone weeks. They have stopped producing financial reports for over a year and have just taken over the system revenue until “operational costs are met” yet they can’t even disclose what those operational costs are! How are they to determine when operational costs have been met? At this point no one is trusting them to be financially responsible anymore. Especially since there is no reason we should have to trust them. This is a DAO the entire point of securing everything via smart contracts is so we don’t need to trust anyone! We have the contracts in place so that trust is unnecessary.

I don’t think you understand that post sip 46 exchequer was never supposed to have ownership of any of the contracts let alone the fee contract where all the fees are sent to! If they weren’t the “team” we would be dealing with an exploited contract that seems to have somewhere in history slipped in a SIP that, unknowingly to stakers voting, assigned their address as proxy owner.

Please understand, every single contract in sovryn is owned by bitocracy TimelockOwner or TImelockAdmin. Do you not find it odd that one contract, specifically the one that collects all the system revenue ended up being owned recently by the eqchequer multisig? It was pretty shocking to most of us that a sip wasn’t needed to change the implementation contract. That’s because EVERY contract in sovryn is owned by bitocracy timelock. This was implemented years ago via sip 46.

So I’ll ask you to think deeply, what is more harmful to a trust-less decentralized system? Is it a DAO fixing an exploited contract and returning control of future revenue to it’s users?

Nothing is going to change if we don’t fix this and get the contract back in our control. The team is not going to give us the financial reports we asked for. They’re not going to disclose their operational expenses. They haven’t had to do any of that for years and therefore they haven’t. Fixing this exploit and regaining control of the system revenue is our only hope at forcing their hands to disclose operational costs and what the financial status of exchequer is.

FeeSharingCollector is exactly the issue. It’s the power of the purse and if you don’t understand that it’s going to be really hard to continue having this conversation with you. Imagine you own a business and the management you hired took over your bank account.

Here’s more for you to read:

System contracts, parameters, and their owners

With the approval of SIP-0046, all ownable contracts holding user funds are currently owned by Bitocracy.

3 Likes
17

Brianna, I appreciate your efforts and engagement. However, I have been involved with Sovryn since 2022. I am familiar with SIP-0046 and I understand the broader context and history.

What concerns me is that you seem to underestimate how fragile the current situation is. The margin for error is extremely thin. Governance experiments of this magnitude are not occurring in a vacuum — they are happening during a prolonged bear market, with limited runway and high execution risk.

I would refer you to Timechainman’s comment here:
https://forum.sovryn.com/t/sip-00xy-vote-of-no-confidence-and-leadership-transition/3532/4

Rather than framing this as a leadership issue, it may be more constructive to focus on the broader context: if Sovryn fails, we all lose our investments. If Sovryn successfully navigates this bear market, launches Sov Layer, and gains traction on a stronger chain, we all stand to benefit.

That framing is critical. This is not about personalities; it is about survivability and execution capacity under constrained conditions.

My question to you is straightforward: with all the requirements and concerns you’ve raised — many of which are fair in isolation — are you comfortable pushing through SIPs that materially increase the probability of operational disruption at this stage? Because if these proposals destabilize execution, the downside is not abstract. It is existential.

18

I can’t ask you enough, but: please stop referring to that forum post. It has nothing to do with this. This sip is not calling for a change or removal of leadership. I’m not sure why you can’t disconnect the two completely different sips?

This sip is not destroying anything or tearing apart anything. It has nothing to do with changing leadership or removing team members. That was a completely different person’s post responding out of desperation to a rash and destabalizing action taken by exchequer.

This sip is fixing a contract that was exploited and creating positive steps towards motivating exchequer to reveal it’s financial situation to bitocracy so we can properly vote on the measures needed to fund operations. That’s so normal for any business I don’t understand how this is even a discussion at this point. Imagine the board of any company or shareholders having zero knowledge of a companies financial obligations or oversight of any kind. It’s unheard of.

Regarding your direct question: Yes absolutely I am comfortable. This SIP is extremely simple, it reverts a single sovryn contract back to the state it was less than 5 days ago. Now if the team has another rash reaction, we’ll deal with it like adults and talk about the steps we can all take to help them resolve their concerns as well as the community’s. I don’t believe most users are interested in destabilizing things or causing chaos. Why would we want to destroy something we have worked hard to fund and build? Most people are not calling for leadership to resign etc. That’s not the point of this. My personal goal is to work together and make positive changes so that users and the team can feel comfortable in sovryn’s future.

But please I can’t ask you enough to stop conflating this sip with that other sip that was written by someone completely different who was clearly unable to come up with any positive solutions other than replacing everyone who led us to this point. I should add: I don’t blame that sip author for feeling desperate. Things felt quite desperate for me as well until I confirmed all of the contracts besides this one are still in the control of bitocracy.

5 Likes
19

Brianna, let me explain again why I see this differently.

I don’t believe anyone’s intention is destruction. My concern is different: I believe you may be underestimating how easily unintended consequences can lead to it.

Have you looked closely at the numbers — at the current fee generation flowing to the protocol? Do you believe such an unpopular decision would have been made for this modest revenue unless it was considered absolutely necessary? It appears to be a move taken under financial pressure to stabilize the protocol’s treasury during a difficult period to keep Sovryn operational, and that’s how it was communicated to us.

At the same time, we do not have full visibility into runway, liabilities, burn rate, or forward projections. That is precisely the level of financial transparency we should require before advancing structural changes. Without that context, we are making high-impact governance decisions based on incomplete information.

My strong position remains that we should prioritize continued discussion, transparency, and coordinated problem-solving — not escalate with reactive SIPs that can just increase instability. The proposals concerning the FeeSharingCollector are technically defensible in isolation, but strategy is not only about technical correctness. In the current environment, sequencing and systemic stability matter far more than symbolic positioning.

20

Perhaps you could just state what you think will happen plainly? I think if you say it out loud you might realize whatever this overarching fear is, might not be rational.

1 Like