Governance Adjustment - 2025Q3

[Dino]

Hi everyone,

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.

[you425]

Thank you for the proposal!

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.

I support this proposal.

[Matt]

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!

[Mouthmouth68]

Hi @Dino

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.

[Dino]

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!

[GuiGou]

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.

[Gaius_sama]

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:

Subsquare | Astar Council Motions

---

Gaius_sama
Astar Foundation

[Juminstock]

Astar Runtime 1700 Upgrade: Enhanced Emergency Response & Infrastructure Improvements

Introduction

Greetings, Astar Community!

We are excited to share a significant runtime upgrade coming to Astar Network that introduces critical governance and security enhancements designed to strengthen our emergency response capabilities while maintaining the decentralized principles that define our ecosystem. Runtime 1700 represents a crucial evolution in our network infrastructure, providing our Technical Committee and Main Council with sophisticated tools to respond swiftly to security incidents without compromising democratic governance.

This upgrade addresses lessons learned from recent ecosystem events, particularly the need for rapid response mechanisms during critical security situations. The new emergency response tools will enable precise, targeted interventions while preserving user rights and maintaining transparency. Additionally, this release includes important infrastructure improvements that prepare Astar for upcoming Polkadot ecosystem developments.

Emergency Response Enhancements

1. dApp Staking Maintenance Mode – Governance Trigger

Building upon the existing maintenance mode functionality, this enhancement significantly improves how we can activate emergency protocols during dApp staking security incidents. Previously, maintenance mode activation required lengthy referendum processes that could prove insufficient during time-critical situations.

Key References:

• Technical implementation details available in the Astar documentation
• Runtime 1700 GitHub release notes

Key Updates:

Enhanced Activation Authority: Maintenance mode can now be triggered by either two-thirds of the Main Council (4 out of 6 members) or one-half of the Technical Committee (2 out of 3 members), eliminating the need for referendum processes during emergencies.

Immediate Protocol Protection: When activated, maintenance mode instantly halts all dApp staking interactions, preventing new staking operations, unstaking requests, and reward claims while simultaneously pausing era advancement to prevent further storage modifications.

Rapid Response Capability: This enhancement addresses scenarios where protocol compromise is detected and immediate action is required to protect user funds and network integrity, as demonstrated during the Neemo Finance incident where rapid response was critical.

2. TxPause Functionality

This represents entirely new functionality that provides surgical precision in emergency responses, allowing governance to selectively pause individual extrinsics without disrupting the entire network operation. TxPause functionality offers unprecedented flexibility in addressing security vulnerabilities.

Key References:

• Implementation specifications in the Astar documentation

Key Updates:

Granular Control Mechanisms: TxPause enables targeting specific pallets and functions rather than broad system shutdowns. For example, governance can pause only the claimUnlocked function within dApp staking while maintaining all other staking operations, or disable specific balance transfer types while preserving essential network functions.

Flexible Activation Thresholds: Similar to maintenance mode, TxPause can be activated by either two-thirds of the Main Council or one-half of the Technical Committee, ensuring rapid deployment when security threats are identified.

Minimal Network Disruption: This functionality allows for precise interventions that address specific vulnerabilities while keeping the majority of network operations running normally, reducing impact on users and developers during security incidents.

3. Safe Mode Implementation

Safe Mode represents the most comprehensive emergency measure available to Astar governance, designed for use during critical vulnerabilities or chain-threatening errors. This functionality provides the strongest possible response to existential network threats while maintaining essential system operations.

Key References:

• Safe Mode configuration parameters in the Runtime specifications
• Emergency procedures docs in the Astar documentation

Key Updates:

Comprehensive Transaction Blocking: When activated, Safe Mode blocks nearly all user-submitted transactions including dApp staking operations, balance transfers, Ethereum transactions, proxy calls, and most user interactions while allowing only essential system operations such as governance actions, parachain lifecycle functions, and timestamping.

Configurable Duration Controls: Safe Mode initializes with a 12-hour active period that can be extended in 2-hour increments as needed, providing flexibility to address extended security situations while preventing indefinite emergency states.

Chain-Critical Response: This functionality is specifically designed for use during active exploit windows or when critical vulnerabilities threaten the entire network, providing governance with the tools necessary to prevent catastrophic damage while solutions are implemented.

Infrastructure & Runtime Improvements

4. Asset Hub Integration in Token Reserve Filter

This upgrade introduces Asset Hub as a recognized relay chain reserve location, positioning Astar Network for seamless integration with upcoming Polkadot and Kusama Asset Hub migrations. This enhancement ensures Astar remains compatible with evolving Polkadot ecosystem infrastructure.

Key References:

• Asset Hub integration PR #1497

Key Updates:

Future-Proof Integration: Asset Hub recognition prepares Astar for upcoming ecosystem changes while maintaining backward compatibility with existing asset management systems.

Enhanced Interoperability: This integration strengthens Astar’s position within the broader Polkadot ecosystem by ensuring seamless asset transfers and cross-chain functionality as the network evolves.

5. Collator Selection Improvements

Runtime 1700 introduces enhanced collator management capabilities that provide more granular control over network validation while improving overall performance tracking and benchmarking accuracy.

Key References:

• Collator selection enhancements PR #1502
• Updated weight calculations PR #1508

Key Updates:

Granular Collator Management: New extrinsics enable adding and removing individual invulnerable collators, providing more precise control over network validation infrastructure.

Performance Optimization: Updated weight calculations improve performance tracking and benchmarking accuracy, contributing to more efficient network operations and better resource allocation.

Community Participation & Next Steps

The governance referendum for Runtime 1700 deployment is now available for community voting. We encourage all stakeholders to participate in this important decision that significantly enhances Astar’s security posture and emergency response capabilities.

Cast Your Vote Now! - End in August 14th

Thank you for your continued participation in shaping Astar’s future and building a more resilient network for our entire community.

[you425]

Thank you for the detailed update!

As I mentioned previously, this upgrade is a crucial step toward improving the security of the Astar network. While it may introduce a partial shift toward centralization, it’s not a complete one — and more importantly, users are prioritizing security above all else.

Naturally, I support this proposal and have already voted in ”Aye”.