If we want to connect a parachain to Rococo's 'rococo-local' relay chain we follow this Cumulus tutorial using polkadot-launch. Part of the pre-launch steps mentioned here is to minimize your runtime size by pruning the functionality, and to then do incremental upgrades using the generated /target/release/wbuild/parachain-template-runtime.compact.wasm file when the parachain is live to include the missing pallets again.

However, Rococo's relay chain currently has a maxCodeSize of only ~3.15 MB, and if you build the substrate-parachain-template using branch 'polkadot_v0.9.17' with cargo build --release it generates that file parachain-template-runtime.compact.wasm that is ~2.9 MB. If you add the Sudo pallet to it so you can do the incremental upgrades then building it generates an even larger file of ~3.0 MB, which may not allow enough space for you to do the incremental upgrades to include the missing pallets again during your launch simulation on the Rococo production testnet before launching on Kusama's production mainnet.

If you add more pallets than just Sudo and the Scheduler pallet by following Substrate's Forkless Upgrades tutorial then you might exceed the maxCodeSize and Polkadot.js Apps may generate an error Bytes:: Maximum call stack size exceeded or Invalid Transaction: Transaction would exhaust the block limits that prevents the runtime upgrade.

Meanwhile, Kusama's relay chain currently has a larger maxCodeSize of ~10.5 MB, which may be sufficient to include all your pallets. There would be a requirement for an initial 3.0 MB for the genesis build of substrate-parachain-template branch 'polkadot_v0.9.17' (plus Sudo pallet to allow you to perform runtime upgrades), then a further 1.5 MB for the 1st runtime upgrade to add ~15 pallets like preimage, scheduler, democracy, referenda, conviction voting, council collective, technical collective, elections phragmen, tips, treasury, bounties, child bounties, assets, multisig, identity, proxy, and recovery, and then a further 1.5 MB for a 2nd runtime upgrade to add ~25 of our own custom pallets to increase it a total code size of the parachain-template-runtime.compact.wasm file to ~6 MB, which would still be less than Kusama's maxCodeSize.

Note that Chachacha relay chain is alternative production testnet for parachains. But that does not provide an alternative, as it also has the same maxCodeSize of as Rococo of ~3.15 MB when you query it here with Polkadot.js Apps by choosing "Developer > Chain state > Storage > configuration (for "selected state query") > activeConfig()" and then clicking the (+) icon.

Question: If Rococo's maxCodeSize only allows you to make some small runtime upgrades, but isn't large enough for you to add all your missing pallets when your parachain is live on it as incremental upgrades after pruning them all to minimize the runtime size for genesis, should you just assume that the remaining runtime upgrades will work on Kusama and proceed to doing it on Kusama instead?

  • 1
    Can you provide a link to the files you are using at genesis and for the upgrade to so a Minimal, Reproducible Example can be tested?
    – Nuke
    Mar 17, 2022 at 17:37
  • 1
    Perhaps the maxCodeSize could be increased, the best way to do this would be a PR referencing this question and let the core team deliberate and work with you to get it in production 🤞
    – Nuke
    Mar 17, 2022 at 17:39
  • 1
    In general too, you should ideally keep posts to one succinct question, so the community can provide one (succinct) answer. 🙏
    – Nuke
    Mar 17, 2022 at 17:41
  • the files we are using at genesis on Rococo on parachain id 2007 will be included in this PR github.com/DataHighway-DHX/DataHighway-Parachain/pull/30. we haven't prepared the runtime upgrade files yet, but they will be generated by restoring the pallets that were pruned in this PR to reduce the x_runtime.compact.wasm file to less than 3.1MB github.com/DataHighway-DHX/DataHighway-Parachain/pull/24 Mar 18, 2022 at 10:25

1 Answer 1


Generally, you should use the x_runtime.compact.compressed.wasm which is about a factor of 3 smaller than the compact wasm. This runtime is compressed with zlib and the node knows to decompress it before execution. Using the compressed Wasm saves space on-chain and over the network.

As for Rococo configuration, that's something that'd be up to the Parity team in charge of the testnet.

  • 1
    so should the Forkless Upgrades tutorial here be updated to say to select the compressed x_runtime.compact.compressed.wasm Wasm binary for an upgraded runtime rather than just the x_runtime.compact.wasm in production? Mar 18, 2022 at 10:19
  • 1
    yes, I think the tutorial should be updated to include a note that compact.compressed.wasm should be used in the parachain environment.
    – rob
    Mar 21, 2022 at 2:40
  • Thanks I have created an issue requesting for that change to me made github.com/substrate-developer-hub/substrate-docs/issues/913 Mar 24, 2022 at 8:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.