I’d like to share a few updates coming to the governance system.
Please note that nothing is set in stone, and we can adjust parameters if needed.
Goal
Current governance model allows anyone to propose a root-privilege action via a public referendum. We also have several councils which can execute some privileged actions like making external proposals & fast-tracking those proposals into referendums.
This is all great, but what we lack is the ability to react quickly in case of an emergency. This was evident with the Neemo situation where Astar team was informed about an ongoing theft with less than 2 hours to spare.
We could have fast-tracked referendum but with only two technical committee signatures available at that time, the minimum voting duration would be 2 hours, which wouldn’t really help us. An unpopular decision was made to use sudo to prevent this by putting dApp staking into maintenance mode.
The following proposed changes aim to allow additional security measures to be executed by the Main Council and Technical Committee.
Changes
1. dApp staking Maintenance Mode
not a new functionality, but we’re going to optimize how we can use it
either technical committee or the main council can now enable & disable it, without the need for referendum (or worse, sudo)
1/2 of the tech committee (2 out of 3) or 2/3 of the main council (4 out of 6) is needed for this action
2. tx-pause functionality
new functionality which allows pausing of certain extrinsic calls
useful to disable some functionality partially
e.g. instead of putting entire dApp staking into maintenance, we could have just blocked claimUnlocked call instead
1/2 of the tech committee (2 out of 3) or 2/3 of the main council (4 out of 6) is needed for this action
3. safe mode
this is to be used in times of critical vulnerabilities or errors, to prevent the chain from “dying”
used to block almost all extrinsics (transactions) submitted to the chain
e.g. dApp staking, balance transfers, ethereum transactions, proxy calls, etc.
only most basic system calls are allowed
once entered, the safe mode is active for 12 hours (configurable), and can be extended by additional 2 hours as many times as needed
1/2 of the tech committee (2 out of 3) or 2/3 of the main council (4 out of 6) is needed for this action
4. sudo
sudo key will be removed completely (soon, TBA)
Important note: None of these actions can impact a certain user’s account directly. E.g. even if we know who the hacker/thief is, this doesn’t allow the council to manipulate their account. Such actions are still only possible via a referendum.
While this change could be seen as strengthening the authority of the Technical Committee and Main Council, more importantly, it serves as an effective measure to enhance both security and agility after the removal of sudo.
This is a great and much-needed proposal — especially after what happened with Neemo. It’s good to see a move toward faster emergency response without relying on sudo.
Love the idea of giving the Technical Committee and Main Council powers to act quickly in crises. Safe Mode and tx-pause sound like smart additions to avoid full shutdowns when only partial action is needed. Removing sudo is a solid step toward more decentralized governance.
A couple friendly thoughts:
Maybe add a simple post-action report so the community stays in the loop after these tools are used.
For Safe Mode, consider setting a soft limit on extensions to avoid overuse.
Overall, really supportive of this direction — it balances speed, safety, and decentralization well!
I support the proposed changes as they address an important gap in our governance—enabling rapid reaction to emergencies. To ensure these new powers are used appropriately without undermining agility, I recommend the following clarifications and controls:
Clear trigger criteria: Define explicit conditions or examples when maintenance mode, tx-pause, or safe mode can be activated, with mandatory on-chain logging of the justification for transparency.
Time-limited emergency states: Implement maximum durations for all emergency modes (e.g., safe mode active for no more than 12–24 hours unless re-approved), with automatic reversion to normal operation if not extended.
Transparency and reporting: Require public notifications immediately upon activation via on-chain events and external channels, plus a detailed post-mortem report explaining the cause, actions taken, and resolution within a defined timeframe.
Communication protocol: Mandate timely and multi-channel communication to all stakeholders—developers, users, validators—to ensure awareness and reduce uncertainty during emergencies.
Appeal and review process: Establish an independent or expanded governance panel to review emergency actions and enable rapid reversal or correction if misuse or errors are detected.
Scope limitations on tx-pause: Define a whitelist of extrinsics eligible for pausing to prevent blocking critical system functions like governance or validator operations.
Maintain approval thresholds with quorum and timing safeguards: Keep the proposed approval thresholds but require quorum presence and reasonable minimum decision time to avoid rushed or minority-driven emergency actions.
These measures will help maintain the necessary agility to respond quickly while providing sufficient guardrails to protect against overreach, preserve trust, and ensure accountability.
Thanks all for the replies so far.
Let me address some suggestions/questions.
Maybe add a simple post-action report so the community stays in the loop after these tools are used.
I believe @Gaius_sama or someone else from the team always handles such things, and this will continue to be the trend. E.g. for the Neemo situation, everything was transparently shared.
For Safe Mode, consider setting a soft limit on extensions to avoid overuse.
&
Time-limited emergency states
This is something we don’t want to do because if something like this happens, we want to keep it in safe mode for as long as it’s needed. Right now it can stay active for 12 hours, but every subsequent extension requires an agreement from the councils. So it’s quite hard to abuse.
Clear trigger criteria
Of course. It will be the same as it was (or is) for dApp staking maintenance mode - if the protocol is at risk. So in case there’s a critical vulnerability or some action (like Neemo hack) that could potentially cause tremendous damage to Astar, then these tools can be used.
This is of course, up to the council members to make their own minds about depending on the specifics of the situation.
Scope limitations on tx-pause
Same as for safe mode, we don’t permit transactions which aren’t critical for the functioning of the system.
Thank you all for raising valid questions and concerns, happy to see others are thinking about this too!
I fully support this proposal.
In my opinion, it’s essential to have this kind of mechanism to be able to react quickly when needed. I’m a supporter of decentralization, but we also need to find a good compromise between governance and responsiveness, especially if it’s to protect users’ funds.
Great to see these adjustments being shared with the community and positive feedback already coming in. Emergency actions must be available in case of incidents to ensure we can act quickly and preserve both the network’s integrity and the value of Astar.
As a Main Council member, I’ll also ensure that such permissions are not used lightly, and the community will always be informed transparently whenever these actions are taken.
For anyone curious about what the Main Council can do, or has done in the past, you can follow all motions in the Council section on Subsquare:
Love the idea of giving the Technical Committee and Main Council powers to act quickly in crises.
Safe Mode and tx-pause sound like smart additions to avoid full shutdowns when only partial action is needed.
Removing sudo is a solid step toward more decentralized governance.
