So far, Integritee has used identical runtimes on all its networks. With the imminent bridging of our Kusama and Polkadot parachains, we will in the future want to deploy not only different versions of our runtime, but also different specializations, i.e. for harmonization of onchain governance across our parachains.
The Integritee team proposes this runtime upgrade which simply splits runtimes by `spec_name` (`integritee-kusama`/ `integritee-polkadot`) from now onwards.&nbsp; No changes in functionality are included.
runtime release:&nbsp;
<a href="https://github.com/integritee-network/parachain/releases/tag/1.13.3-dev4">https://github.com/integritee-network/parachain/releases/tag/1.13.3-dev4</a>

Schedule a majority-carries referendum to be tabled next once it is legal to schedule
an external referendum.

The dispatch of this call must be `ExternalMajorityOrigin`.

- `proposal_hash`: The preimage hash of the proposal.

Unlike `external_propose`, blacklisting has no effect on this and it may replace a
pre-scheduled `external_propose` call.

Weight: `O(1)`

Authorize an upgrade to a given `code_hash` for the runtime. The runtime can be supplied
later.

The `check_version` parameter sets a boolean flag for whether or not the runtime's spec
version and name should be verified on upgrade. Since the authorization only has a hash,
it cannot actually perform the verification.

This call requires Root origin.

- **Problem Statement:** Integritee needs to deploy different runtimes for its Kusama and Polkadot parachains to harmonize onchain governance.
- **Significance:** Bridging Kusama and Polkadot parachains requires specialized runtimes for governance.
- **Proposed Solution:** Upgrade runtime to split by `spec_name` (`integritee-kusama`/ `integritee-polkadot`) without changing functionality.
- **Expected Outcomes:** Improved onchain governance across Integritee's parachains.

#58 runtime upgrade v551

No Active Proposals