Astar Collator System Update: Transitioning to Governance-Approved Collator Selection

[Juminstock]

Hello, Astar Community!

We’re excited to share an important evolution in how Astar Network manages its collator infrastructure. As part of the Runtime-1900 upgrade, Astar has transitioned from a permissionless collator registration system to a governance-approved collator selection process.

This change represents a significant milestone in Astar’s journey toward a governance-led ecosystem, placing collator management directly under the oversight of our governance system. By requiring governance approval for all new collators, we ensure that only vetted, committed, and qualified node operators participate in block production, strengthening network security and operational standards across the ecosystem.

I. Understanding Collators in the Astar Ecosystem

Before diving into the new system, let’s understand what collators do and why they matter.

What Is a Collator?

A collator is responsible for producing blocks and confirming transactions on Astar Network. Think of collators as the network’s block producers: they collect transactions from users, package them into blocks, and produce state transition proofs for Polkadot’s Relay Chain validators to verify.

Why Quality Matters

The primary focus for Astar’s collator infrastructure is ensuring high operational standards and accountability. The main risk collators pose is transaction censorship, but this is mitigated by ensuring a diverse set of honest collators. Theoretically, even a single honest collator prevents complete censorship. This is why Astar focuses on vetting collators for quality, commitment, and operational standards, ensuring that each collator meets the network’s requirements for security and performance.

Learn More About Collators in Our Documentation

II. Why the Change to Governance-Approved Selection?

The previous permissionless system allowed anyone meeting the bond requirement to register as a collator candidate. While this approach maximized openness, it lacked mechanisms to ensure operational quality and accountability.

The new governance-approved system addresses these limitations by introducing community oversight at every stage. Prospective collators must now demonstrate their commitment and receive explicit approval from Astar Governance before joining the active collator set. This ensures:

• Enhanced Network Security: Only vetted operators with proven track records can participate in block production
• Higher Operational Standards: Governance can verify technical capabilities and infrastructure quality before approval
• Community Empowerment: ASTR holders and governance bodies have direct say in who secures the network
• Improved Performance Monitoring: Governance retains authority to remove underperforming collators
• Quality Control: Focus on maintaining a professional, accountable collator set

What Remains Unchanged

It’s important to note that all collator-related parameters remain the same: bond amounts, slashing percentages, reward structures, and the collator set size are unaffected by this upgrade. The change is purely about how collators join and leave the network.

III. The New Collator Application Process

Under the updated system, becoming an Astar collator follows a structured two-step process designed to ensure transparency and community oversight.

Step 1: Submit Your Application

Forum Post Requirement: Prospective collators must first submit a public application post on Astar Forum. Your application should include:

• Introduction and background of your organization or individual operation
• Technical infrastructure details (hardware specifications, data center country, redundancy measures)
• Operational experience (previous blockchain node operation, uptime records)
• Commitment statement explaining your motivation to support Astar Network
• Your node’s public address and contact information

The forum post must remain open for a minimum of 7 days, during which the community will evaluate your request and initiate a collective dialogue with the proposer.

Step 2: Governance Approval

Once your forum application is submitted and you have received positive feedback from the community, you proceed to the governance review process:

• Bond Reservation: After gathering community feedback on your forum post and confirming interest in proceeding, you must call the apply_for_candidacy extrinsic onchain, reserving the required 3.2M ASTR bond. This bond demonstrates your financial commitment and remains locked throughout your tenure as a collator.

• Approval Paths: Your application can be approved through two mechanisms:
  • Public Referendum: Allowing all ASTR holders to participate in the decision. This is the primary path for collator approval, ensuring maximum community involvement in determining who secures the network.
  • Main Council Approval: Alternatively, your application can be approved by a two-thirds majority vote from the Main Council. Council members review your application, assess your qualifications, and vote on whether to add you to the collator candidates pool.

Upon Approval: Once governance approves your application via the approve_application extrinsic, your node is officially added to the collator candidates pool and can begin participating in block production.

Review Here How to Submit a Public Referendum

Withdrawing Your Application

Changed your mind? The close_application extrinsic allows applicants to withdraw pending applications and unreserve their bond before governance approval. This flexibility ensures applicants aren’t locked into commitments if circumstances change.

IV. Governance Actions: Oversight and Enforcement

The new system empowers Astar Governance with formal mechanisms to maintain network health and enforce operational standards.

Governance Origins

The collator selection pallet utilizes two distinct configurable origins:

• GovernanceOrigin: Responsible for approving and closing candidacy applications. On Astar, this requires either a two-thirds majority vote from the Main Council or approval through a public referendum.
• ForceRemovalOrigin: Handles the forcible removal and slashing of candidates. The configuration mirrors GovernanceOrigin, requiring either three-fourth Main Council approval or referendum passage.

Removing Underperforming Collators

Governance has multiple mechanisms to remove collators depending on the situation and severity:

• Immediate Removal with Slashing (kick_candidate): For active collator candidates requiring immediate action due to poor performance or malicious behavior, governance can remove them instantly and slash 1% of their bond. This call can only be executed by the ForceRemovalOrigin.
• Removal Without Slashing (leave_intent via dispatch_as): In situations where governance wishes to remove a collator without financial penalty (e.g., voluntary departure assistance, special circumstances), this can be achieved by wrapping the leave_intent call with the utility pallet’s dispatch_as function through a referendum. The removal takes effect in the next session.
• Removing Invulnerables (remove_invulnerable): For invulnerable collators, removal requires a public referendum. This ensures maximum community oversight for changes to the network’s core infrastructure operators.

V. Important Notice for Existing Collators

If you’re already operating as an Astar collator, here’s what you need to know:

• Existing collators remain active: Current collators are not affected by this upgrade. Your position in the collator set is maintained, and no additional action is required to continue operations.
• Deprecated Extrinsic: The previous register_as_candidate extrinsic has been deprecated and will return a Permission error if called. All new collator candidacy submissions must utilize the apply_for_candidacy extrinsic followed by governance approval.
• Governance Oversight Applies: While existing collators don’t need to reapply, you are now subject to governance oversight. The Main Council and community have formal authority to remove collators who fail to meet standards through the mechanisms described above.

VI. Technical Reference

Full Technical Requirements in Our Documentation

For developers and technical operators, here’s a summary of the new extrinsic calls:

Extrinsic	Purpose	Origin
apply_for_candidacy	Submit application, reserve bond	Any account with 3.2M ASTR
close_application	Withdraw pending application, unreserve bond	Applicant
approve_application	Approve candidacy, add to collator pool	GovernanceOrigin (Main Council 2/3 majority or Public Referendum)
kick_candidate	Remove active collator candidate from the set and slash 1% of bond	ForceRemovalOrigin (Main Council 3/4 majority or Public Referendum)
remove_invulnerable	Remove an invulnerable collator from the set	Public Referendum

GitHub PR with Full Technical Details

VII. Closing Thoughts

The transition to governance-approved collator selection represents Astar’s continued commitment to community oversight and operational excellence. By placing collator management under governance control, we ensure that the network’s block producers are accountable to the community they serve and meet the high standards required to secure Astar Network.

Thank you for your continued support in building the Astar Collective. Together, we are shaping a future where governance, contribution, and ownership are inseparable.

[Matt]

This is a great step forward for Astar’s governance maturity. Moving collator selection under explicit community and council oversight brings much stronger accountability and aligns perfectly with the long-term goal of strengthening security while keeping decentralization meaningful.

A couple of thoughts and questions that may help shape future iterations of this process:

• Transparency Dashboard:
Would it be possible to create a public dashboard showing all pending collator applications, their current status (e.g., “forum discussion,” “bond reserved,” “awaiting referendum”), and any relevant metrics? This would help the community track progress more easily and stay engaged throughout the review process.

• Performance Standards Framework:
While governance can remove underperforming collators, is there a plan to publish a minimum performance guideline (uptime thresholds, hardware expectations, response windows, etc.) so applicants understand expectations clearly before applying?

• Regional Diversity:
As more communities explore running nodes (such as Turkey recently showing interest), could governance encourage geographic diversification to strengthen neutrality and resilience?

Overall, this upgrade is a major milestone. Looking forward to seeing how the first round of new, governance-approved collators goes through the pipeline. Great work to everyone involved!

[tksarah]

Thank you for providing clear new guidance on Astar Collators.
Some of my questions may overlap slightly with Matt’s, but I would also like to raise a few points.

In particular, my questions concern the technical infrastructure details of the application process.

• Hardware specifications: These are documented, and I understand that meeting them is the minimum requirement. Please let me know if there are any different elements or changes to be aware of.
• Data center location: I believe it is not wise to disclose detailed information about this. While I understand the likelihood is very low, there is still a possibility that such a location could be targeted. If disclosure is required, I think it should be limited to specifying only the country in which the node is operated.
• Redundancy: I am a fairly experienced IT infrastructure and cloud engineer. Redundancy essentially serves as insurance to maintain an always-running node. The mechanisms and costs to increase uptime are, in principle, limitless. What I think would be useful to set is a target uptime rate (such as five nines or six nines). Unlike conventional mission-critical IT systems, blockchains are inherently decentralized systems, so I do not believe the requirements need to be stricter than that. Considering updates and maintenance, a maximum of around 99.99% uptime may be reasonable. This is my opinion.
• Importance of monitoring: I also place strong emphasis on monitoring, though I recognize there are many different solutions. Simply put, as long as node monitoring in the operator’s environment ensures the uptime target mentioned above, I believe that is sufficient. For example, in some regions, stable power supply is not guaranteed, and frequent outages occur. In such cases, introducing UPS systems would be necessary. By contrast, building mechanisms to secure power supply in Japan tends to be somewhat simpler.

Currently, I am operating as a Shiden Collator, taking into account system configuration and monitoring. I am also considering the possibility of operating as an Astar Collator, so I want to ensure I have sufficient understanding and preparation in advance.

[you425]

Moving collator management on-chain is a great step forward!

However, I feel it’s very difficult for regular participants to properly evaluate whether collators are functioning as they should.
For that reason, as Matt mentioned, having a dashboard or similar tooling would definitely make things easier to understand.

Right now, there’s no clear way for users to see which collators have what kind of performance or track record, and without that visibility, governance-based management may not function properly.

[DrCAO]

Thank you for this detailed and forward-looking proposal.
This governance-approved collator selection model is an important step toward strengthening operational quality and network security on Astar, and overall I support this proposal, and I do have a few follow-up questions to better understand how the new system will work in practice, especially regarding technical standards and evaluation procedures: First, what is the minimum requirements for becoming a collator? hardware like CPU, RAM or bandwidth? Probably a guidelines would be helpful. Also, how will node quality be validated and monitored? anyone would be there to monitor it? Any dashboard to show the status so the community could check it easily? Again, thank you so much for this important initiative!

[Juminstock]

Hi @Matt! Thank you for your significant contributions to the conversation. Allow me to answer your questions:

@Matt

• Transparency Dashboard:
Would it be possible to create a public dashboard showing all pending collator applications, their current status (e.g., “forum discussion,” “bond reserved,” “awaiting referendum”), and any relevant metrics? This would help the community track progress more easily and stay engaged throughout the review process.

It’s totally possible, but you should keep in mind that this would consume resources from our engineering team, which not only is responsible for maintaining this area, but must also fulfill other activities related to the functioning of Astar Network. Additionally, the information that such a dashboard would reflect is already public here on the forum, on Subsquare, on Subscan, etc. The dashboard would only unify everything on an all-in-one platform. Although it sounds cool, I don’t see it as a priority.

However, it would be a great community project.

@Matt

• Performance Standards Framework:
While governance can remove underperforming collators, is there a plan to publish a minimum performance guideline (uptime thresholds, hardware expectations, response windows, etc.) so applicants understand expectations clearly before applying?

At the moment, the only performance standard by which governance will be guided is the inactivity time of an Astar Collator. You can read more about this in our documentation: Learn about Collators | Welcome to Astar

@Matt

• Regional Diversity:
As more communities explore running nodes (such as Turkey recently showing interest), could governance encourage geographic diversification to strengthen neutrality and resilience?

Absolutely. Applications are open and eager to receive new applicants.

[Juminstock]

Valuable points you raise, @tksarah

@tksarah

Hardware specifications: These are documented, and I understand that meeting them is the minimum requirement. Please let me know if there are any different elements or changes to be aware of.

No, there have been no changes regarding this.

@tksarah

Data center location: I believe it is not wise to disclose detailed information about this. While I understand the likelihood is very low, there is still a possibility that such a location could be targeted. If disclosure is required, I think it should be limited to specifying only the country in which the node is operated.

Thank you for this feedback, I’ve specified it in my post.

@tksarah

Redundancy: I am a fairly experienced IT infrastructure and cloud engineer. Redundancy essentially serves as insurance to maintain an always-running node. The mechanisms and costs to increase uptime are, in principle, limitless. What I think would be useful to set is a target uptime rate (such as five nines or six nines). Unlike conventional mission-critical IT systems, blockchains are inherently decentralized systems, so I do not believe the requirements need to be stricter than that. Considering updates and maintenance, a maximum of around 99.99% uptime may be reasonable. This is my opinion.

I didn’t exactly understand what you’re getting at with this. Are you referring to us being more specific or changing the parameters?

@tksarah

Importance of monitoring: I also place strong emphasis on monitoring, though I recognize there are many different solutions. Simply put, as long as node monitoring in the operator’s environment ensures the uptime target mentioned above, I believe that is sufficient. For example, in some regions, stable power supply is not guaranteed, and frequent outages occur. In such cases, introducing UPS systems would be necessary. By contrast, building mechanisms to secure power supply in Japan tends to be somewhat simpler.

Valuable, I think it’s something we can take into consideration. cc @bLd759

[Juminstock]

I appreciate your participation in the conversation, @you425 and @DrCAO!

@you425

However, I feel it’s very difficult for regular participants to properly evaluate whether collators are functioning as they should.
For that reason, as Matt mentioned, having a dashboard or similar tooling would definitely make things easier to understand.

I agree with you. That’s why the variety of profiles in a community is valuable. It’s not realistic to expect all users to participate in all topics, the same happens here.

@you425

Right now, there’s no clear way for users to see which collators have what kind of performance or track record, and without that visibility, governance-based management may not function properly.

Currently, we can see some information using Subscan: Subscan | Aggregate Substrate ecological network high-precision Web3 explorer. But I understand that this may not be enough to get the full context of all collators.

@DrCAO

First, what is the minimum requirements for becoming a collator? hardware like CPU, RAM or bandwidth? Probably a guidelines would be helpful.

Regarding this, we actually already have this information specified in our documentation: https://docs.astar.network/docs/build/nodes/collator/requirements.

@DrCAO If you still feel it’s not totally clear, I invite you to create content to help users better understand this .

[you425]

Thank you.
I see — at the very least, Subscan provides enough visibility to identify basic issues.
For example, among the current collators, it’s easy to spot that one of them hasn’t produced a block for nearly a month, so it’s reasonable to propose removing that account.

In fact, a proposal to remove this collator is already being voted on through on-chain governance:

Update Collator Invulnerables List – Remove...

@Juminstock

I agree with you. That’s why the variety of profiles in a community is valuable. It’s not realistic to expect all users to participate in all topics, the same happens here.

As you said, even if a dashboard existed, the majority of users would probably not participate in evaluating collators.
In many cases, having a few proactive leaders raise issues is enough.
Unlike dApp Staking, there isn’t a clearly defined group like the ACC to lead collator-related matters, but since the urgency is low and decisions are unlikely to be blocked, it may be fine to continue as things are for now.

[Juminstock]

@you425

As you said, even if a dashboard existed, the majority of users would probably not participate in evaluating collators.
In many cases, having a few proactive leaders raise issues is enough.

Exactly! This is where we invite any community member to be that proactive leader on topics like this, collator evaluation.

@you425

Unlike dApp Staking, there isn’t a clearly defined group like the ACC to lead collator-related matters, but since the urgency is low and decisions are unlikely to be blocked, it may be fine to continue as things are for now.

Although, once again, I would love to see a community-led project to develop this.

[tksarah]

@Juminstock

I didn’t exactly understand what you’re getting at with this. Are you referring to us being more specific or changing the parameters?

This comment refers to the point labeled as “redundancy measures.” It is not about parameters.

Implementing redundancy measures essentially means ensuring availability so that the node does not stop. In systems, availability levels are typically evaluated in terms of “uptime.” For example, in mission-critical systems, an uptime of 99.999% or higher is commonly cited. This corresponds to roughly five minutes of downtime per year.

To increase this uptime (availability), it is necessary to implement measures—both software and hardware—that keep the system running as continuously as possible. Redundancy is one method of improving uptime. Therefore, the key question is what level of uptime is required for blockchain nodes. Since blockchain as a whole maintains high availability through decentralization, with multiple nodes performing the same tasks and preserving data, it is not necessary for each individual node to maintain extreme uptime. That said, some degree of continuous operation is required. Based on my research, an uptime rate of around 95% to 99% is desirable.

For instance, with 99% uptime, the annual downtime would be about three and a half days. In other words, node operators must ensure software and hardware robustness, as well as supporting monitoring, alerting, and maintenance systems, so that the node can run continuously for more than 362(365-3) days a year.

[Vangardem]

The fact that collators are chained together is a giant step forward. However, I am concerned about how they will be monitored to prevent abuse of their functions. I think I have the same concern as most people here.

Perhaps their performance could be evaluated based on the number of outages they have caused. I think penalties could be created for operational outages. Collators must always be online because our network depends on it.