Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more
System Collator Bounty Topup - 6 mths
This proposal requests a 6-month top-up to continue supporting Kusama System Parachain collators (AssetHub, BridgeHub, CoreTime, People, and Encointer). The goal is to sustain a reliable, decentralized collator set for critical system infrastructure by funding performance-based incentives for eligible collators (invulnerable + permissionless; developer slots are excluded). Payouts are distributed proportionally to blocks authored during each assessment period.
The proposal also includes a small monthly allocation for staking rewards (yield on 50 KSM per collator), ongoing infrastructure costs for local archive RPC access used for verification and dispute resolution (with retrospective queries limited to 3 months), and amortized development to complete a new block-author scraping tool (already partially developed and being prototyped) to reduce operational overhead and improve reliability of monthly accounting.
Ask (6 months):
- 17,456.59 KSM total (estimated), based on $7.3985 per KSM
- Equivalent to $129,152.59 USD total
Monthly estimate:
- 2,909.43 KSM/month (estimated)
- Equivalent to $21,525.43 USD/month
The proposal document can be found here -> https://gist.github.com/paradox-tt/a30a2661935a8343c39b47ae127cc5aa
Regards,
Will | Paradox
Comments (3)
Requested
Proposal Failed
Hey will - do you think it would be useful to make public a cost / revenue model that people could contribute to given existing usage and parameters (e.g. no of validators). You've started something similar here.
Dumb question here, but is there an evolution of this 'performance' model for collators where there is usage based income, rather than just producing empty blocks?
Is this another case of paying for uptime, but not necessarily for demand?
Curious as to your views...
Hey Rich,
The baseline we’re using comes from the approved RFC-0007 (System Collator Selection), which was informed by broader stakeholder feedback and includes input from SR Labs auditors. (paritytech.github.io)
RFC-0007 suggests a rule-of-thumb target of ~20 collators per system chain (often described as a split of ~15 invulnerables + ~5 bond-elected/permissionless slots) to balance liveness, censorship resistance, and operational scalability. (paritytech.github.io)
In practice, we have been operating below these thresholds across the system chains. However, given the increased operational importance of AssetHub, we have moved to tighten the gap by increasing its collator set to 18 total (invulnerable + permissionless), while still remaining under the RFC baseline. (paritytech.github.io)
The question of the “ideal” number of collators comes up regularly, and it can quickly become subjective. For system chains, the safest anchor is the research and previously approved direction that prioritizes liveness and censorship resistance as non-negotiable requirements. I’m open to adjusting collator counts downward, but any proposal to reduce them should be backed by clear, testable evidence that these guarantees are preserved at lower numbers—along with a concrete operational plan showing how the network would detect, respond to, and recover from degraded performance or coordinated disruption.
Best,
Will