September 2026 incident report: Rootstock governance attack defeated, SIP-0095 open for voting

September 2026 incident report: Rootstock governance attack defeated, SIP-0095 open for voting

The attempted takeover of Sovryn’s governance on Rootstock has been defeated. On 20 September, Bitocracy rejected the attacker’s proposal, preventing it from proceeding to execution. We contained the attacker’s staked SOV by pausing and freezing staking. SIP-0095 is now open for voting in Bitocracy. It proposes confiscating approximately 5,000,510.4995 SOV held in the two identified attacker staking positions and recovering it to the Exchequer for compensation of those harmed by the exploit.

The malicious proposal never executed. The recovery is the next step and remains subject to governance approval and execution. The published SIP-0095 sets out the proposed mechanism.

We opened the recovery vote before publishing this report, with staking restrictions in place. Voting power for the proposal is determined by the snapshot at its start block: additional stake created afterward cannot increase a voter’s weight in this vote. The freeze also prevents the attacker from adding stake or withdrawing the tokens targeted for recovery. The attacker retains the voting power recorded at the snapshot and can vote against the proposal.

This report focuses on the attack against Sovryn on Rootstock and our response. The incident began with an exploit of the Sovryn DEX on BOB. The full technical account of that exploit, including its root cause, affected pools, losses and remediation, will be published separately.

The attacker moved SOV from BOB through Ethereum to Rootstock, receiving approximately 1.7304 million SOV, and acquired a further 3.2701 million SOV through the Rootstock RBTC/SOV pool. Together, these receipts account for the approximately 5.0005 million SOV subsequently placed in the two identified staking positions. The cross-chain transfers and Rootstock purchase connect the BOB activity directly to the governance attack. Bridge receipt; Rootstock purchase.

On 19 September at 16:56:51 UTC, the main attacker address staked 4,960,441.0623 SOV for the maximum lock period, giving it approximately 49.6044 million voting power. Just two minutes and 39 seconds later, it created proposal 56 on GovernorOwner, followed by a supporting vote. The remaining 40,069.4372 SOV was transferred to a second address and staked later that evening. That second address also attempted to support proposal 56, but its vote carried zero weight because its stake was created after the proposal’s snapshot. Main stake; proposal creation; secondary vote.

Although the attacker labelled the proposal “testnet governance-capture PoC,” it targeted Rootstock mainnet. Its nine actions sought to replace protocol implementations, change administration and install malicious code. Analysis of that code identified functions capable of transferring SOV, WRBTC and native RBTC out of contracts through which it was installed. The staking action sought to expose the SOV held by the staking contract, including other users’ stakes. These were attempted changes: proposal 56 was defeated before execution. Proposal and actions; attacker implementation.

Our response combined on-chain investigation, containment and a governance defence. We traced the funding and staking positions, examined the proposed contract changes, and checked the attacker’s subsequent activity. On 19 September at 21:58:51 UTC, the Contracts Guardians paused and froze staking on Rootstock. The main attacker address subsequently made three unsuccessful attempts to withdraw its entire stake. None released SOV; the final attempt explicitly reverted with “paused”. Containment transaction; failed withdrawal.

The staking freeze preserved the tokens available for recovery. Defeating the proposal required a separate vote. Opposition reached approximately 37.9710 million voting power, against 49.6044 million in support. That left support at 56.64%, below GovernorOwner’s requirement of strictly more than 70%. Proposal 56 became Defeated at 17:10:13 UTC on 20 September. It was never queued or executed, and that defeated proposal cannot now proceed to execution. Final proposal record; first block recording defeat.

On BOB, the DEX’s emergency halt was activated at 13:30:41 UTC on 20 September, disabling its direct swap path and enabling safe mode. Halting the exchange was a containment measure; the underlying exploit and any restart require their own remediation work. SIP-0095 does not restart the BOB DEX. Emergency-halt transaction.

Defeating proposal 56 did not remove the attacker’s stake or the voting power associated with it. To support the recovery vote, 10 million existing SOV were placed in a temporary defensive stake through the Contracts Guardians on 23 September at 12:45:52 UTC. This was completed in one transaction that lifted the staking restrictions, placed the stake and restored the restrictions before the transaction ended. It did not leave staking open between transactions. The recovery proposal includes returning this defensive stake to the Exchequer; it must be accounted for separately from the SOV recovered from the attacker. Defensive staking transaction.

SIP-0095 proposes four actions, all executed in one atomic transaction:

1. Install a temporary recovery module on the Staking contract.

2. Transfer the SOV in both identified attacker staking positions to the Exchequer.

3. Return the temporary defensive stake to the Exchequer.

4. Remove the recovery module.

If any action fails, the entire transaction reverts. The module fixes the relevant accounts and the Exchequer destination in its code, and its recovery functions can be called only by the staking owner timelock. It targets those accounts’ own staking positions; it does not confiscate tokens owned by other stakers who may have delegated voting power to them. No early-withdrawal penalty is applied, so the full recovered attacker stake goes to the Exchequer. The module adds no new storage fields and updates the existing staking and voting checkpoints when removing the positions. The proposed transaction leaves no recovery module installed afterward. Implementation and proposal code; verified recovery module.

Staking restrictions must remain in place until recovery executes. Opening the vote does not itself confiscate the tokens or release the freeze. Reopening ordinary withdrawals beforehand would allow the attacker to attempt to exit with the balance remaining after the early-withdrawal penalty. That would jeopardize the recovery; a penalty paid into fee sharing would not itself fund the proposed compensation process. We recognize that the freeze also prevents legitimate stakers from withdrawing. This is a real cost to users, and completing the recovery is the necessary step toward lifting these restrictions. SIP-0095’s four actions do not themselves unpause or unfreeze staking.

The recovered attacker SOV would be held by the Exchequer multisig for compensation of those harmed by the BOB DEX exploit. SIP-0095 does not determine allocations or a distribution mechanism. Those decisions will return to Bitocracy in a separate proposal once the loss accounting is complete. Recovering this SOV does not establish that all exploit losses have been recovered or that users have already been compensated.

The incident also exposed the need for more precise emergency controls, including the ability to restrict withdrawals while preserving other staking functions. That work will be reviewed separately. The immediate proposal is limited to recovering the identified stakes and returning the temporary defensive stake.

This incident highlights the importance of Sovryn’s Perimeter, which we have been building to strengthen protocol security. Its planned monitoring and intervention capabilities focus on the point where assets leave the protocol, with the aim of identifying suspicious withdrawals and intervening before funds are lost. The ability to contain an attack and preserve assets for recovery matters alongside preventing vulnerabilities in the first place. This experience reinforces the urgency of completing and rigorously reviewing that work. Perimeter programme described in SIP-0094.

We thank the stakers, delegates and contributors who helped defeat the malicious proposal and contain the incident. We ask the community to review SIP-0095: Staking Recovery — Sweep of the Attacker’s Staked SOV and vote in favour of recovery in Bitocracy: SIP-0095.