Skip to content

Instantly share code, notes, and snippets.

@paradox-tt

paradox-tt/SPC_Topup-012026-Kusama.md

Last active January 22, 2026 12:37
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save paradox-tt/a30a2661935a8343c39b47ae127cc5aa to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save paradox-tt/a30a2661935a8343c39b47ae127cc5aa to your computer and use it in GitHub Desktop.
Download ZIP
System Parachain Collator Bounty - Topup Request January 2026
Raw
SPC_Topup-012026-Kusama.md

Proposal to Fund System Parachain Collators (Kusama)

Table of Contents

1.0 Introduction

Kusama’s system parachains provide shared infrastructure that other applications and users implicitly rely on. To keep these chains healthy, the network depends on collators that are sufficiently decentralized, consistently available, and properly resourced—because poor collation performance directly translates into slower block times and degraded UX. However, system collators still face a structural incentive gap: fee revenue is limited, and the current environment can unintentionally encourage cost-cutting rather than resilience.

This proposal seeks a funding top-up to maintain the operational status of the existing bounty and ensure ongoing, performance-based support for collators as a practical medium-term measure—aligned with the broader trajectory for system collator selection and incentives described in RFC-0007.

2.0 Previous Referenda

Initiatives supporting Kusama system chain collators have been ongoing since early 2023 and have been essential to maintaining the network’s stability, security, and decentralization.

3.0 Budget

Conversion rate used: $7.3985 per 1 KSM
Request duration: 6 months

Over the six-month period, the proposal funds:

  1. performance-based collator incentives for 62 eligible collators,
  2. staking rewards on a 50 KSM stake per collator (estimated at ~39.24 KSM/month at 15.19% annual),
  3. infrastructure for archive RPC and curator operations, and
  4. amortized completion of the updated scraping/payout tool.

The curator fee is applied last at 7.5% of the full monthly subtotal (covering all items), bringing the estimated total to $21,525.43 per month, or ~2,909.43 KSM/month at $7.3985/KSM (total ~17,456.59 KSM over 6 months).

Table 1: Budget Summary

Budget item Basis USD / month KSM / month
Collator incentives 62 x $300 18,600.00 2,514.02
Staking rewards (estimated) 62 x (50 KSM x 15.19/12/100) = 39.24 KSM 290.32 39.24
Infrastructure (VMs) 5 para VMs + 1 relay VM + 1/2 curator VM 425.00 57.44
Tool development (amortized) $4,250 one-time / 6 months 708.33 95.74
Subtotal (before curator fee) 20,023.66 2,706.45
Curator fee (7.5%, calculated last) 7.5% x subtotal 1,501.77 202.98
Total per month 21,525.43 2,909.43
Total for 6 months 129,152.59 17,456.59

3.1 System Parachain Collators

Table 2 (below) shows how many collators each Kusama system chain currently has, split into invulnerables, permissionless, and developer slots. For this proposal, only the invulnerable + permissionless collators are eligible for payments (developer slots are excluded). Based on the table, that’s 62 funded collators total across the five system chains.

Each eligible collator is budgeted at $300/month, and payouts are performance-based: collators are paid according to the share of blocks they author during the assessment period (rather than a flat, equal payout).

Table 2: Number of collators by type (exclusive)

Chain Invulnerables Permissionless Developer
AssetHub 9 6 2
BridgeHub 6 6 2
CoreTime 6 6 2
People 8 6 2
Encointer 4 5 2

Total monthly disbursement to collators = 62 x $300.00 = $18,600.00

3.2 Staking Rewards

Collators would receive staking rewards on a 50 KSM stake per collator, with rewards capped at the yield earned on that 50 KSM each month. Using the current staking rate of 15.19% per year, we estimate monthly rewards using a simple annual-to-monthly conversion:

  • Monthly rate = 15.19 / 12 / 100 = 0.01265833
  • Monthly reward per collator = 50 * 0.01265833 = 0.63291667 KSM
  • Total for 62 collators = 62 * 0.63291667 = 39.24083354 KSM per month (~39.24 KSM)

Total monthly allocation for staking rewards = ~39.24 KSM

3.3 Block Author Scraping Tool

The curators calculate proportional payouts by scanning each chain’s blocks over the assessment period, tallying blocks authored per collator, and distributing rewards based on each collator’s share of block production.

To ensure accuracy, the bounty operates under a 3-person, 2-of-3 multisig: each month, two curators independently run the process, compare results, and publish the final accounting before executing payouts.

The existing payout tool (built in early 2023 in Typescript using Polkadot.js API) has become operationally heavy: scraping can be slow and requires close attention due to API/throughput and memory constraints (even with local RPC), and it also involves manual upkeep such as adjusting legacy child-bounty IDs. The framework anticipated the need for reliable automation/tooling to support efficient and accurate payout processing, which is why we are moving to a replacement.

A newer tool is already partially developed and currently being prototyped, using Rust for chain data extraction and Typescript for constructing on-chain extrinsics. We are requesting funding for up to 100 capped hours of development at $85/hour (split between Polkadot and Kusama). Like its predecessor, the tool will be open-sourced for community review and independent verification.

Total one-time cost for development = (100 x $85.00) / 2 = $4,250.00

3.4 Local Virtual Machines

We host local archive RPC instances in virtual machines on the same network as the curator’s scraping VM to ensure fast, reliable access to historical chain data. This is especially important for the relay-chain archive node, which has significantly larger storage requirements than individual parachain nodes.

The monthly VM costs cover not only compute and storage, but also ongoing maintenance activities including software upgrades, maintaining backups and ensuring the nodes remain available and fully synced. Archive access is also required for governance and auditability: curators may need to query historical state to validate or respond to claims based on past data. Under this proposal, retrospective queries are limited to 3 months back.

Monthly cost (Kusama portion):

  • Parachain archive VMs: 5 * $50 = $250.00/month
  • Relay-chain archive VM: 1 * $150 = $150.00/month
  • Curator VM (50% share): $50 * 0.5 = $25.00/month

Total monthly infrastructure cost = $250 + $150 + $25 = $425.00

3.5 Administrative

Curators are compensated via a fee proportional to the total amount disbursed each month. The curator fee is 7.5% of monthly payouts, and is split evenly across the three curators (2.5% each). In return, curators are responsible for producing the monthly payout report, reviewing results for discrepancies, communicating updates to the collation team, and handling incoming queries and follow-ups as they arise.

4.0 Future Initiatives

4.1 Standardize Numbers of Collators per Chain

Collator set sizes currently vary across Kusama system chains, and Encointer is an independent case operated by a separate development team. In this proposal, we aim to keep support standardized and consistent across system chains wherever practical, while recognizing that some chains have different operational needs.

At the same time, we are deliberately not increasing collator counts beyond what is necessary. Larger sets can improve resilience, but they also directly increase ongoing incentive costs. Our approach is to maintain a sensible baseline that preserves security and availability, without expanding the funded set so much that it creates an unnecessary and avoidable burden on the treasury.

4.2 Drive a new system for Invulnerable assignments

The gist proposes an on-chain way to make system-chain collator “invulnerable” protection more flexible, without introducing off-chain voting. It starts from one core need: system chains require a reliable tier of collators that can’t be permissionlessly displaced by bad actors (today’s invulnerables), while stakeholders also want that tier to be more fluid, to reward good performers, to encourage longer-term bonding, and to reduce gaming (e.g., entering with a high bond to win a slot, then re-entering later with less).

To achieve that, it suggests adding a third tier called “serviced” collators, sitting between permissionless and invulnerable. Permissionless entry stays the same, but permissionless collators accrue a block-production counter. High-performing permissionless collators can be promoted into serviced slots that come with a guaranteed tenure (example: ~4 months).

Once a serviced collator’s tenure ends, rotation happens automatically: eligible permissionless candidates with sufficient production can replace the lowest-bonded serviced collator whose service period has elapsed, preventing targeted removals and keeping churn rule-based and transparent. Invulnerables remain largely unchanged: few in number, permissioned, not bond-based, and intended to preserve chain liveliness.

Reference:

4.3 Logging of System Collator Data

Today, when incidents occur, developers often need to request logs from collator operators. In practice, some operators run with lower log verbosity to reduce on-host storage and maintenance overhead, which can limit the detail available during investigations.

We propose an optional, opt-in logging approach where operator logs are shipped to an external storage service that is directly accessible to developers, while operators keep only a shorter rolling window on the collator host itself.

Under this model, each operator would retain full visibility of their own logs, with external retention for up to six months, enabling deeper historical context without increasing storage pressure on production machines. This should materially reduce turnaround time when diagnosing issues, help identify root causes faster, and speed up the rollout and validation of fixes. Participation would be voluntary for each operator, allowing teams to opt in based on their operational preferences and privacy considerations.

4.4 Incentive and Penalty Model Exploration

We propose a conceptual review of the current reward structure to explore whether additional incentives and penalties could reduce negative behaviours such as Sybil operation (e.g., one party running multiple collators). As part of this, we’d like to consider ways to incentivize voluntary log sharing, since improved observability can speed up incident diagnosis and resolution.

Importantly, the goal is not to increase overall payouts above the current level. Instead, we may examine a model with a lower base payment plus earned incentives that can build back up to today’s effective reward when operators meet desired standards (e.g., transparency and good operational practices). This is an early-stage concept and would require further research and stakeholder input before any concrete proposal is made.

5.0 References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment