Dear Simon, and the wider community,

I understand a call has been made to remove me as an invulnerable collator. I want to provide context.

I’m currently migrating services from one data centre to another, and I recently switched off the remaining infrastructure at the old facility. We hit an unexpected issue during the migration, and this outage is one of the consequences.

I sincerely apologise to the community. I’m actively working to bring the node back online as quickly as possible, and I’ll share an update as soon as service is fully restored.

I hope my long-standing record as a collator — with very few missed blocks, operating from an independent data centre, and having retained the majority of my rewards — speaks in my favour.

Kind regards,
Will

[@ParaNodes.io](XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw-astar) 
Thanks for the update, Will, and for providing additional context.

I can see that the collator now appears to be operational again after roughly two days of inactivity, and I appreciate the effort to restore the service.

That said, the core concern behind this proposal/ref is not related to a single incident or to your historical performance as a collator, which is acknowledged. The focus is instead on the operational standards expected from collators. 
From a network-health and governance perspective, extended downtime — even when caused by maintenance, migrations, or infrastructure changes — highlights the importance of having robust backup and failover systems in place. An invulnerable collator is expected to continue producing blocks without multi-day interruptions, regardless of internal infrastructure work.

The intent of this proposal is to ensure that the active collator set consistently meets the highest availability standards, and that prolonged inactivity is surfaced and handled transparently through governance when it occurs.

Kind regards,
Simon

[@ParaNodes.io](XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw-astar) 

As Simon mentioned, it is unfortunately inevitable that high operational standards are required.
Because of that, even if this migration work was planned, the risks involved should have been addressed in advance.
With proper preparation for potential failures, I would expect that recovery could have been completed within a day.

Regrettably, it seems likely that you will be removed from the invulnerable set.
I hope you will rebuild your environment and continue contributing to decentralization again in the future.

I do not understand what makes you believe you should be treated differently from [other invulnerable validators who have also been removed](https://astar.subsquare.io/democracy/referenda/46) for failing to produce blocks for an entire day.

A datacenter migration, by itself, is not a sufficient reason for such prolonged inactivity. Validators are entrusted with critical responsibilities, and prolonged inactivity directly impacts network performance and nominator rewards. As such, higher operational standards should be expected and upheld.

[@Ym9j...tLpS](Ym9jqyzr5QHbNHxw746TmYN7Ea5Yppi8CkH1XhXXLRXtLpS-astar) In your example, the collator did not produce blocks for more than two weeks and did not even restore the service, but here the service was restored. Each case should be treated differently, as each case is unique. That is why we have separate proposals.

I’m truly disappointed by the tone of some of the replies here. Personally, I feel like a community that I admired has turned against me.  It’s also hard to see a few days of issues weighed more heavily than years of consistent service and contribution. That said, I understand that there's a position that reliability is non-negotiable for a collator set.  I do however think that the network (by design) has the capacity to function reasonably without a single collator and the "punishment" proposed is too much.  

If the community’s decision is to remove me as an invulnerable collator, I’ll respect that and step aside. I’m proud of what I’ve contributed over the years, and I genuinely want Astar to succeed.

I’m hopeful the project’s roadmap, its ties in Japan, and the Sony collaboration translate into real, sustained adoption. Wishing the network and community the best going forward.

[@ParaNodes.io](XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw-astar) 
I saw that you have been participating as a collator since the very beginning of the Astar Network, since 2021. Sometimes server management becomes hard and unpredictable, and even big companies sometimes have downtime in their services. With your long expertise in the Astar Network, after one issue it would not be fair to remove you as a collator.

What I want to say is that you are the same part of the community as others, and you have the right to vote with your tokens against this proposal, especially since it requires SuperMajority approval. You have a chance to change the decision.

[@ParaNodes.io](XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw-astar) 

Of course, I appreciate all the contributions you have made up to this point.
However, unlike collators who bond their own funds, invulnerable collators do not have automatic slashing or strong economic constraints.
Because of this, they are expected to maintain a higher level of operational discipline, responsiveness, preparedness, and infrastructure reliability.

From my perspective, this is an essential standard that should be shared across the entire ecosystem.

Thank you once again for all the contributions you have made.


[@ParaNodes.io](XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw-astar) 
First of all, thank you for your contribution over the years. Your long-standing service as a collator is recognised and appreciated.

This situation is not about turning against anyone, nor about disregarding past performance. It is about defining and upholding operational standards for the active collator set moving forward.

You are right that the network can technically continue functioning even if a single collator goes offline. However, governance decisions are not only about what the network can tolerate, but about the reliability standards we choose to maintain — especially for invulnerable collators.

In the permissionless collator set, prolonged inactivity is handled automatically by the protocol. A collator that remains offline for a short period (e.g. a couple of hours) would be automatically slashed and removed from the active set. That mechanism enforces availability without requiring any governance intervention.

Invulnerable collators, on the other hand, are not required to lock a 3.2M ASTR bond and are not subject to automatic slashing. Because there is no automatic removal mechanism in that case, governance becomes the only accountability layer when extended downtime occurs.

For that reason, this discussion is not personal and not intended as a punishment. It is about ensuring that the invulnerable set reflects the highest level of operational readiness and redundancy at all times.

Your past contributions remain part of Astar’s growth, and that is not erased by this situation.

Whatever the outcome of the vote, I appreciate your professionalism in respecting the community’s decision and wish you the best going forward.

Kind regards,
Simon

voted NAY as as a collator sometimes it just hits you

[@SimonB](WXX4zsN3LPwUbVAouQUE9EqUSVycUTaoW65FyM5UeS5xeWZ-astar) [@tksarah](aZkj2EgiZkUbnKk6XMp9pf9f9SALXSAaTgz17ZEYUaq2UZy-astar) 

It seems to me that ParaNodes is resorting to close friends ([see onchain transfers between them](https://astar.subscan.io/transfer?address=XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw&token_category=native&token_category=asset&token_category=treasury&page=1&time_dimension=date&match_mode=fuzzy&value_dimension=usd&value_start=20)) to make the Astar Council’s proposal fail. Instead of accepting the rules of the game, he thinks he’s smarter than everyone else and has more right than others. Kick this smart-aleck out!

Thanks to everyone who supported my retention. [@pathrocknetwork](ZUJewBJpQMCS8MeNbKoQk8ddTC5SyEzJN312XVx4zujjjHj-astar) — your words were few but genuinely motivating. And [@0x6933...297e](0x69338964156466F3e1C83C0Ae4C79fd32Db5297e-astar), I appreciate you adding perspective from the previous referendum.

Regarding the outcome: myself and others voted fully within the rules and the on-chain governance process. Disagreeing with a proposal (and voting accordingly) isn’t “gaming” anything; it’s how governance is intended to work.

I hope we can all, including [@Ym9j...tLpS](Ym9jqyzr5QHbNHxw746TmYN7Ea5Yppi8CkH1XhXXLRXtLpS-astar), respect the result and move forward constructively. I’ll continue supporting Astar in the best way I can, and I encourage everyone to do the same.


This referendum proposes removing the collator XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw from the invulnerable set due to zero blocks produced over one day (permissionless collators are slashed after only 2 hours of inactivity or 2 sessions).

Action: RemoveInvulnerable(XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw).

This is a governance-only change; no client upgrade is required.

---

## 🔧 Technical Details

### Purpose & Context
- Zero blocks produced in the last day (last block produced: `12157032`) risks liveness and reliability of the invulnerable set.
- Removing this collator from the invulnerable set preserves network availability and expected performance.

Collator address: XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw

### Key Technical Change
Execute extrinsic:
- RemoveInvulnerable(XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw)

---

## 📊 Impact Analysis

### Risks & Considerations
⚠️ No client change; operational monitoring recommended post-removal

---

## 📚 Additional Resources
- Subscan collator page: https://astar.subscan.io/collator/XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw

Update Collator Invulnerables List – Remove XAL7gbTCFBNCmYBwdQzcFvkSSbfMTSXEMqigEpkzyNLyYrw due to inactivity

🔧 Technical Details

Purpose & Context

Key Technical Change

📊 Impact Analysis

Risks & Considerations

📚 Additional Resources