Kusama Parachain Auctions: Second Batch

By Robert Habermeier, Polkadot Founder

The first batch of 5 parachain slot auctions on Kusama were completed successfully over the course of June and July. Those parachains, along with the common-good parachain Statemine, have been running on Kusama since that time. Here are our recommendations for rolling out the next batch of Parachain Auctions after the interim period of monitoring for liveness and stability.

This Summer, Kusama made history with a permissionless launch of 5 independent parachains, made possible by the technology developed for Polkadot. This was a watershed moment for the entire ecosystem, with a fair and secure auction mechanism allocating parachain slots to the community’s favored projects.

The 5 winning projects, in order, were Karura↗, Moonriver↗, Shiden↗, Khala↗, and Bifrost↗ and each, in turn, are working through their relative launch phases. By gradually expanding their feature-set, Kusama’s first parachains are already taking advantage of the built-in and forkless upgradability provided by Substrate and have brought more value to the ecosystem.

Furthermore, the seeds of a multi-chain future that were planted long ago are now bearing fruit. While all five parachains are working on cross-chain collaborations, Shiden↗ and Karura↗ have already used the XCM protocol to enact value-bearing cross-chain transfers, and Khala has built a public, one-way bridge utilizing Substrate pallets↗.

The goal of Kusama is to be a chaotic proving ground for the technology that powers Polkadot. In the spirit of chaos, features typically land on Kusama before launching on Polkadot. After cleanroom testing, code and incentives must be satisfactorily proven in a real-world and value-bearing environment before landing on Polkadot.

While our recommendations for the parachain launch on Kusama are cautious due to the uncertainty of the new environment, this experience paves the way for a swift and fluid scaling of Polkadot to the same level of sharding because the technology is proven. The more that Kusama is stress-tested, the faster and easier it will be for a smooth Polkadot rollout.

The software for minimum viable product (MVP) parachains is feature-complete and comprises protocols for parachain block inclusion, data availability, and security. Two of the four protocols have been audited and audits will continue for the remaining two. Our recommendation is that the launch of parachains on Polkadot should begin at the point when the audits are complete, all discovered issues are addressed, and there are no incidents relating to parachain consensus on Kusama.

We’ve observed the performance and stability of the six parachains currently on Kusama with the report published here. Parachain block production, approvals, and finality are generally stable with occasional incidents relating to temporary stalls of block finalization. These incidents are being investigated and we will propose a solution to fix the root cause after the next five auctions on Kusama, and before auctions on Polkadot.

It is not the opinion of the core development team at Parity Technologies that the next five parachains on Kusama will meaningfully exacerbate this issue - Kusama is chaotic, and being exposed to more real-world data means a smoother launch on Polkadot in the future. Therefore, it is Parity’s recommendation to the Kusama Council that the next parachain auctions commence with the following schedule:

• The sixth parachain slot auction to begin on September 1st, noon GMT, in order to allow the members of the Kusama community enough time to unstake KSM for their auction bids and to participate in crowdloans
• Auctions commence back to back with a two day period of initial bidding followed by a five day ending period (in the same manner as to the first five auctions)
• Five auctions happen over five weeks with a pause for evaluation of overall network performance before a third batch of five auctions begins in a similar schedule

The following is the case assuming that no significant and unexpected issues are found with the relay-chain logic (in such a case all options should remain on the table for network governance including pausing or postponing any scheduled or on-going auctions.)

If these recommendations are observed then the schedule will look as follows: