I believe system chains are absolutely essential for the ecosystem. That said, I would like to raise a few concerns regarding this proposal.

The three curators receive $1,067.48 per month each, across both bounties. If we take the $85/hour rate referenced by the coordinator, are we really expected to believe that each curator dedicates 12 hours per month to these tasks? It is difficult to justify a monthly payment of $1,067.48 per curator for work that appears to require little more than a few clicks.

This concern is further amplified by the fact that the proposals include the amortization of an $8,500 tool, with the cost split between Polkadot and Kusama. The stated purpose of this tool presumably reducing the amount of manual work required from curators. If that is the case, the current level of compensation becomes even harder to understand also for the coordinator.

Additionally, it has been demonstrated that some members receiving payments from this bounty have engaged in commission flipping multiple times within the same day, abusing nominators and, in some cases, operating under multiple identities. These behaviors clearly violate good faith and run counter to the principles promoted by the W3F.

In my view, curators and coordinator compensation should be adjusted to reflect the actual time and effort invested, and bad actors should be removed from the bounty altogether.

Thanks for the detailed feedback. I see two themes here: (1) curator/coordinator compensation and the purpose of the tooling, and (2) validator commission behaviour.

1) Curator + coordinator compensation (and why it isn’t “a few clicks”)

The monthly payout process is not just pressing a button. Curators are accountable for producing a correct, reproducible distribution and for responding when results are challenged. In practice the work includes: extracting block-author data across multiple chains and periods, reconciling results across independent runs, preparing and validating payout batches/child-bounty actions, checking for discrepancies, publishing an audit trail, and then handling follow-up questions or disputes. Where the chain/bounty structure changes, curators also maintain the administrative mappings (e.g., aligning child-bounty IDs and keeping tracking consistent).

The coordinator role is separate and operational. The coordinator acts as the technical liaison between collators and curators, which includes coordinating operational readiness for network or system-chain events (new chain rollouts, runtime upgrades, startup/config changes), collecting and relaying diagnostics/logs when issues occur, maintaining a shared coordination channel, and helping explain/triage deviations (including flagging chain events that plausibly explain irregularities). The coordinator also independently runs the tooling as an additional sanity check and assists with troubleshooting when the pipeline or scripts need fixes. Proposal upkeep and community responses are also part of this operational workload.

On the question of “hours”: both the curators and the coordinator believe that, in practice, the time spent on these activities often exceeds the ~12 hours/month estimate on average once you include end-to-end processing, reconciliation, exception handling, and ongoing communications.

We are open to moving to a time-based arrangement (or a hybrid model). In reality, that could mean some months exceed 12 hours (e.g., upgrades, chain events, disputes, tooling issues), while quieter months could be lower. However, time-based billing also introduces overhead: hours would need to be tracked, evidenced, and reported, which itself is additional effort and process. Because this would be a meaningful operational change, we’d prefer to do it in response to broader sentiment from multiple engaged stakeholders, rather than a single anonymous account raising the concern.

2) Tooling cost vs curator work

The purpose of the new tool is not to eliminate curator work; it is to make the work more reliable, reproducible, and less operationally risky (fewer failure modes, less manual intervention, faster verification across multiple chains). It is already partially developed and being prototyped, and the request covers capped hours to complete it. The goal is better automation and stronger auditability—not “replace humans entirely.”

3) Validator commission flipping (high-level)

I agree that commission gaming is unacceptable and runs counter to the spirit expected of operators supporting critical infrastructure. At the same time, I view this primarily as a UI/UX and transparency problem rather than a protocol-level exploit—users often rely on the commission shown in tooling, and the system does not yet provide strong, user-friendly protections against sudden changes.

Today, the system collator bounty does not have a clearly documented policy that would justify punitive action beyond warnings for this specific behavior; we can consider adding clearer tenets/expectations in a future proposal if the community wants that. I’m also not directly responsible for the election of invulnerables: I can suggest composition, but removal/replacement is ultimately an OpenGov decision. If the community believes removal is the appropriate remedy, the cleanest path is for OpenGov to act; and if engaged, I can help suggest alternative candidates within the existing framework. In the meantime, I’m open to approaches that improve transparency and set clear expectations without creating perverse incentives or encouraging rebranding/identity churn.

Edit: Also noting, the respective collators who were commission flipping have issued apologies and vowed to not repeat such actions. Should we seek to punish when there's room for reform?