Unbrick Zeitgeist Parachain

### Bittensor Project Proposal Summary

- **Issue**: Bittensor used the wrong para ID (2096) in its genesis WASM during Auction #36.
- **Problem**: The chain cannot produce blocks with the incorrect para ID.
- **Solution**: Propose to update the genesis head from 2096 to 2097 using `forceSetCurrentHead`.
- **Proposal Hash**: 0x457da305f86a09bad84a8c557bb89628b9b39707819df0b12458d84a255d6354
- **Status**: Preimage submitted.

Update genesis state WASM to 2097 

- The parachains v9370 release includes updates for the Relay Chain.
- The main change is the addition of OpenGov origins to Statemine.
- There are also upgrades for Statemint and Collectives.
- Links are provided to see more information and proposals related to these updates.
- The release has specific proposal hashes for tracking changes.

The parachains [v9370 release](https://github.com/paritytech/cumulus/releases/tag/parachains-v9370) contains updates that correspond to the v9370 runtimes of the respective Relay Chain. The main update in this release is addition of OpenGov origins to Statemine. See the release notes for more details.

[Statemint Authorize Upgrade](0x01029985e134020e8a1e2e211afcd5ac9ec6a2fd21dfb5e1c39b3b670f4415e90406)

[Collectives Authorize Upgrade](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-collectives-rpc.polkadot.io#/extrinsics/decode/0x0102dcc6cda49b51efbe0fd184b974074d1258ca9f15b9fccfedc35b7dee6e1ab9e9) 

[Send from Polkadot](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x1a0008630001000100a10f0204060202286bee8801029985e134020e8a1e2e211afcd5ac9ec6a2fd21dfb5e1c39b3b670f4415e90406630001000100a50f0204060202286bee880102dcc6cda49b51efbe0fd184b974074d1258ca9f15b9fccfedc35b7dee6e1ab9e9) 

Proposal Hash: 0x75df893fe3cd4e5960179865bef1291225df793082a46e721a786b3ce463471a


Upgrade System Parachains to v9370

- The Zeitgeist team made a proposal to fix a problem with their parachain on Polkadot.
- There was an issue with the ParaId number that made it hard for the parachain to work correctly.
- They had a similar problem on Kusama, and the community approved a fix there.
- The proposed fix involves updating the parachain's chainspec to use the correct ParaId and a newer runtime.
- The team asked the Technical Committee to quickly approve the fix to start the chain.
- A signed statement from the ParaId manager confirms the proposal's authenticity.
- If this proposal is approved, the community will have the final say through a referendum.

Based on the conversations the Zeitgeist team had with TC in the last days, and taking into account the same issue appeared for the team on Kusama and the fix was approved by the community (see [HERE](https://kusama.polkassembly.io/referendum/251)), this proposal is now submitted as external motion for consideration of the Council, before making it to referenda queue for the final decision. 

You can find the contextual information on this proposal by the Zeitgeist team [HERE](https://hackmd.io/PXotv7zMTSOphZFg4f99iQ) or below:

### What Happened

The runtime that is now deployed on Polkadot was prepared before the ParaId was obtained. During local testing rococo-local was used as the relay chain. The parachain was onboarded using another ParaId than the one within the runtime and the parachain was capable of producing blocks and functioning as expected. Assuming that everything is fine, the same runtime was used to bid in the parachain auction using a different ParaId than the one noted in the prepared runtime. As it turns out, the parachain is uncapable of producing blocks on Polkadot due to a ParaId mismatch.

About the same time Zeitgeist also bid for a slot on Kusama to execute a slot lease swap. The testing procedure was the same and also resulted in success, however the chain was also uncapable of producing blocks. If those two events were temporaly further apart, the human error would only have happened once. Unfortunately we are forced into the highly aggrevating situation to ask the governance body twice to fix our Parachain, once for Kusama (proposal) and once for Polkadot.

### Remedy

To fix the bricked chain, the chainspec used for Zeitgeist’s parachain on Polkadot must use 2092 within ParachainInfo::ParaId. To inform Polkadot about the new state root that results from the updated chainspec, paras.forceSetCurrentHead(2092, genesisHead) has to be invoked by the Root origin, whereas genesisHead is set to the resulting genesis state head that is derived from the new chainspec.

We also want to supply a new runtime. It is much more recent (polkadot-v0.9.29 instead of polkadot-v0.9.19).

### Council Proposal

We are aware of the recent discussion around the technical council circumventing due process on governance here: [https://forum.polkadot.network/t/how-to-recover-a-parachain/673/23](https://forum.polkadot.network/t/how-to-recover-a-parachain/673/23) and withdrawing from fixing broken parachains. However there is currently not a best practice solution other then avoiding mistakes.

Our humble request to the Technical Committee is to fast-rack this proposal, this is purely a technical hotfix to get the chain started the first time. 

### Proof of Authenticity

To proof that this request is authentic, the manager of ParaId 2092 does provide a signed statement of approval.

Manager (`registrar.paras(2092)`): `15Q7heNtPy5vaZ79c3eUt7M42Ao3okf7PKKdRDULBz3Z4UyF`

Statement: [1675099734007] I hereby approve the deployment of the genesis state `0x000000000000000000000000000000000000000000000000000000000000000000c2e17f26b505c2be4dcefd0ebfd3abe4536fcc86ded7329af33ddd0a9496db9a03170a2e7597b7b7e3d84c05391d139a62b157e78786d8c082f29dcf4c11131400` and the genesis wasm with the blake2-256 hash `0xa4fe96b65d8f78a7f92d1b7eb917ca501518b6910bee573565d16a911fb91a14` for ParaId 2092 on Polkadot

Signature: `0x6a87523b11d4dd17411c3d9ebed91175dafed6b570014b164074b54b3b2c2b147574a9a5e3f2a25dfcd15340617c4df0730302f51016d5264257e7e8b0c39880`

### 

**PLEASE NOTE THIS PROPOSAL IS SUBMITTED AS AN EXTERNAL MOTION: MEANING IF/AFTER COUNCIL APPROVAL, THE COMMUNITY WILL HAVE THE FINAL DECISION ON THE PROPOSAL IN REFERENDA QUEUE. ALSO NOTE [REFERENDUM 103](https://polkadot.polkassembly.io/referendum/103), SUBMITTED BY THE ZEITGEIST TEAM, AIMS TO EXECUTE THE SAME PROPOSAL: HOWEVER THE TEAM HAS PUBLICLY DISCUSSED 56 DAYS FOR ENACTMENT IS A LONG TIME TO WAIT FOR A FIX. IF THIS PROPOSAL PASSES, THEN REFERENDUM 103 WILL NEED TO BE CANCELED OR DOWNVOTED.**

### 

Make sure to review and vote at you convenience!

- There was a problem with a previous motion in Polkadot, so it has been replaced by Motion 333.
- This new motion wants to upgrade Polkadot to a new version (v0.9.36).
- The proposal includes important details you can find in the release notes.
- Some updates in the upgrade are about improving how things work on the system, like handling bond amounts and log targets.
- This proposal needs approval from the Polkadot Council first.
- After that, the community will vote on it for the final decision.

**NOTE**: Due to an issue with the length of the call when submitting an external motion 333 on Polkadot.js Apps (already fixed by this [PR](https://github.com/polkadot-js/apps/pull/8899))the previous motion won't execute successfully. Motion 333 is replaced by this one.


This proposal aims upgrade Polkadot to [v9360](https://github.com/paritytech/polkadot/releases/tag/v0.9.36): the specific details on this upgrade please check the release notes. 

System.setCode hash: `0x5f48aacbbd94a881a3ce5a496e1d852f21cffe33d1f7592023f2140254683d20`

Hash wrapped on Utility > withWeight call: `0x1daf74e45c1db64e50a5fa01b20ec2e8101e589bed278841b2946d4c4d258f78`

![](https://i.ibb.co/10xqxjy/Screenshot-2023-01-27-at-10-40-07.png)

**Runtime**

- [S] ✅ trivial [#12889](https://github.com/paritytech/substrate/pull/12889) Low - Staking: store last min-active-bond on-chain

- [S] ✅ audited [#12582](https://github.com/paritytech/substrate/pull/12582) Low - Automatic withdraw_unbonded upon unbond

- [S] ✅ trivial [#12894](https://github.com/paritytech/substrate/pull/12894) Low - Warn on missing pallet::call_index

**Misc**

- [S] ✅ trivial [#12875](https://github.com/paritytech/substrate/pull/12875) Low - Use log_target in consensus related crates

- [S] ✅ trivial [#12889](https://github.com/paritytech/substrate/pull/12889) Low - Staking: store last min-active-bond on-chain

- [S] ⏳ pending non-critical audit [#12537](https://github.com/paritytech/substrate/pull/12537) Low - Try-runtime revamp and facelift

- [S] ✅ audited [#12582](https://github.com/paritytech/substrate/pull/12582) Low - Automatic withdraw_unbonded upon unbond

- [P] ✅ trivial [#6440](https://github.com/paritytech/polkadot/pull/6440) ‼️ HIGH - Fix wrong rate limit + add a few logs.

- [S] ✅ trivial [#12894](https://github.com/paritytech/substrate/pull/12894) Low - Warn on missing pallet::call_index

- [P] ✅ trivial [#6450](https://github.com/paritytech/polkadot/pull/6450) Low - Update weights (0.9.36)


Please note this proposal is submitted as an external motion: meaning if/after the Polkadot Council approves, the proposal will be up for vote by the community in democracy module for the final decision.

Make sure to vote at your convenience!

Runtime Release v9360 for Polkadot (replacing motion 333 due to length issues)

- The proposal is about checking new software updates for parachains before they happen.
- This means validators will test the updates to make sure they work properly.
- If the updates are good, they can be added; if not, they won't be accepted.
- This process helps prevent mistakes when parachains try to create new blocks.
- It has been tested successfully on different platforms like Versi, Rococo, and Westend.
- Changes to prevent unfair punishments, called slashing, also need this method.
- Parachains have had the tool to support this for over a year.
- People are encouraged to review and vote on this proposal.

This proposal aims to enable pre-checking for runtime upgrade on parachains: With pre-checking enabled a parachain is only allowed to upgrade their runtime **after validators have tried compiling it and they agree it is good**, as opposed to just accepting it blindly and then fail when the parachain tries to produce blocks with the new runtime. This is just generally a good idea, exists for a while already and has been successfully tested on Versi, Rococo and Westend. It is also required for rolling out slashing as it helps reducing the risk of unjustified slashes.

Parachains need to support the `go_ahead_signal,` but that should be a non issue as this has been introduced over a year ago.

 - Call to be enacted: [HERE](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.dotters.network%2Fpolkadot#/extrinsics/decode/0x332901).

Preimage is submitted. Make sure to review and vote at your convenience!

Setting pvfCheckingEnabled In The Configuration To TRUE

- The parachains v9360 release has important updates for its system.
- Statemint, a part of the release, has changes in the Assets section that affect how transactions work.
- Wallets need to be updated to match these changes.
- The Collectives Parachain now has a new role called "Fellow."
- The new "Fellow" role combines the old Founder and Fellow roles and takes away veto power.
- Fellows can also choose to step back to a role called Ally.
- More details can be found in the release notes.

The parachains [v9360 release](https://github.com/paritytech/cumulus/releases/tag/parachains-v9360) contains updates that correspond to the v9360 runtimes of the respective Relay Chain. For Statemint, this contains updates to the Assets pallet that breaks transaction version; wallets should update accordingly. For the Collectives Parachain, this merges the Founder/Fellow roles into one “Fellow” role, removes veto power, and allows Fellows to step down to Ally. See the release notes for more details.

[Statemint Authorize Upgrade](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fstatemint-rpc.polkadot.io#/extrinsics/decode/0x010239127c43fb7051d78dd91eb724b087607cb09bc046824b0d52e0a48981943e68)

[Collectives Authorize Upgrade](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-collectives-rpc.polkadot.io#/extrinsics/decode/0x0102de7616501046da7138c35e0b4699bf403a09523533f30e0e5180dbb5fb8fec4d) 

[Send from Polkadot](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x1a0008630001000100a10f0204060202286bee88010239127c43fb7051d78dd91eb724b087607cb09bc046824b0d52e0a48981943e68630001000100a50f0204060202286bee880102de7616501046da7138c35e0b4699bf403a09523533f30e0e5180dbb5fb8fec4d) 

Proposal Hash: `0xa730cdb8c4b933b9e9ced277e63e79f0f52c0159f78bf60037f6ba312324051f`


Upgrade Polkadot System Parachains v9360

- The Bitgreen team upgraded their parachain code to a new version at block 191202.
- The upgrade went well, and the parachain continued working without any problems.
- A new feature called "pallet-parachain-staking" was added during the upgrade.
- This new feature helps assign new validators for the parachain's sessions.
- After the upgrade, there was an issue with setting initial values, leaving the authorities empty.
- The team talked with Parity developers and created a plan to fix this issue.
- They are asking for the proposal to be approved quickly so they can start distributing token rewards.
- Similar proposals have been approved quickly before, and they hope for the same support.

Contextual information from the Bitgreen team, below:

For a detailed description please refer to this: [https://hackmd.io/@t9B1coeOQ1GlARb2EZRx3g/Hy0mnACdo](https://hackmd.io/@t9B1coeOQ1GlARb2EZRx3g/Hy0mnACdo)

The bitgreen parachain was upgraded from a shell runtime to our latest runtime code at block 191202.

The upgrade executed without issues and the parachain continued to produce blocks. The upgraded parachain runtime introduced a couple of new pallets, the pallet-parachain-staking among them. This new pallet was responsible to assign new validators to session pallet and by extension the aura pallet. After the runtime upgrade, when a new session was triggered, it set the new authorities to an empty set since the pallet-parachain-staking was not set with any initial values.

We have explored all other solutions and after discussion and advice from Parity devs have created this proposal. Our humble request to the TC is to fastrack this proposal, this is purely a technical rollback since our chain has no user transactions or funds yet. We would like to distribute token rewards as soon as possible. Similar parachain resetshave been fastracked by the TC in the past and we request that our proposal be fastracked aswell.

Proposal hash: `0xfc0c33d0c0ae08d940fddadb11e239710da69b8660eaae7f77ea102a331e4ebe`

Preimage is submitted. 



Unbrick Bitgreen Parachain

- A proposal is made to upgrade Polkadot to a new version called v9340.
- This upgrade is only about the software used and does not include a new client.
- The new version will replace older versions, v9320 and v9330.
- The Polkadot Council will decide if the proposal can be voted on by the community.
- If the council agrees, the vote will happen on January 14.
- Some important changes will happen after the upgrade, like stopping certain unfinished tasks.
- Any votes that have passed but not started will not go ahead until after the update.

This proposal aims upgrade Polkadot to [v9340](https://github.com/paritytech/polkadot/releases/tag/v0.9.34): the specific details on this upgrade please check the release notes. 

- This is a runtime-only release. 
- No node client is released, also this Polkadot runtime replaces runtime v9320 and v9330.

Proposal hash: `0xace5dccb8eecfab754154a27c370a513d79d4fcda40f5837be1c0f129cdf4726`

Please note this proposal is submitted as an external motion: meaning if/after the Polkadot Council approves, the proposal will be up for vote by the community in democracy module. 

Make sure to vote at your convenience!

### IMPORTANT NOTE ON THIS UPGRADE:

Assuming Referendum 96 passes, Polkadot will upgrade to runtime v9340 on Saturday 14 Jan. This will have several effects: **please read below!**

First, any outstanding multisig calls (ones where one signatory has signed, but not the threshold) will not be able to execute. Please either finish your multisig calls before this upgrade, or wait until after it is completed. [https://github.com/paritytech/substrate/pull/12072](https://github.com/paritytech/substrate/pull/12072).

All preimages and the dispatch queue will be cleared. Any Referenda already passed but not enacted will thus not execute. If the Referendum is ongoing, the preimage can be re-uploaded after the upgrade. [https://github.com/paritytech/substrate/pull/11649](https://github.com/paritytech/substrate/pull/11649).

Runtime Release v9340 for Polkadot

- The Polkadot Alliance was created by seven important projects to set rules and protect open-source development.
- The founding members are Acala, Astar, Interlay, Kilt, Moonbeam, Phala, and Subscan.
- The Alliance has two main ranks: "Fellow" and "Ally."
- Their goals include making rules, managing members, and keeping a list of bad actors.
- Membership shows a group's commitment to quality contributions within the Polkadot community.
- Members must follow rules like respecting each other's work and working together against scams.
- If members break the rules, they can be removed by a vote.

The Seeding of the Polkadot Alliance: Fighting for an open source culture and open collaboration that benefits the Polkadot ecosystem

This is a proposal whose proposer address (14DXNLsWfpf1RZ3eZSemHaitFh7WM6ZwswJUVLxqQhRvc2ui) is shown in on-chain info below. Only this user can edit this description and the title. If you own this account, login and tell us more about your proposal.

On chain council motion

- The Kapex Parachain is part of Polkadot and has been making blocks but can't upgrade due to a problem.
- A security check found bad code in the system that prevents fixing a fee recording issue.
- The problem was discovered after winning a special spot on Polkadot.
- Efforts to fix the issue without official approval failed, so new solutions were needed.
- They successfully tested a fix using special code on different networks.
- The Kapex team is now preparing for production and needs community support to fix the funding problem.
- They have taken steps for updates and proposals to resolve the issue.

### The Kapex Parachain has been producing blocks since winning and parachain slot on Polkadot, but cannot be upgraded due to an error.

> [SRLabs](https://www.srlabs.de/) conducted a security audit on the Totem Kapex pallets and identified an issue with some illegal code that impacted the Transaction Payment pallet adapted by the team. Unfortunately the team won a slot on Polkadot before the audit could have been conducted and so the issue was not discovered until the audit completed. 

## Background
The standard Transaction Payment Pallet had been forked and adapted to record transaction fees into the accounting engine of the KAPEX Parachain. the original version of this code was changed by a new team developer to use a function reserved for off-chain workers instead of the original code but as the code compiled it was not spotted until the audit. It was thought that an upgrade would fix the issue.

## Upgrade failure
As the Transaction Payment Pallet is called during an upgrade to reserve funds (even though the actual upgrade is free of charge), the illegal code was unfortunately also called to record this reservation of fees causing an error, preventing the upgrade from taking place and therefore not allowing the parachain to be fixed.

**_In addition this also meant that the XCM security vulnerability discovered in late September also cannot be fixed either at this point._**

All attempts were made to try to fix this issue without having to go to the Council and Referendum process, with help provided with gratitude from the Kilt.io team and Parity team Bastian, Alejandro and Santiago.

The new [Manual Parachain Lock](https://github.com/paritytech/polkadot/pull/5451) cannot fix our chain because [the unlocking mechanism does not allow for centrally controlled chains to unlock the parachain from the relaychain side](https://github.com/paritytech/polkadot/issues/6196). 

The fix that worked was to apply a validation code substitution using `paras.forceSetCurrentCode()` executed on the relaychain once the parachain `chain spec` had been updated accordingly and applied to the collators in our test networks. This is the subject of this proposal.

## Testing the fix

- [X] Tested the fix (`paras.forceSetCurrentCode()`) on our [Relaychain development network](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frelaychain.totem.live#/parachains) connected to the Lego development parachain.

- [X] Upgraded the Lego Parachain to version [`v1.2.0`](https://github.com/totem-tech/totem-parachains/tree/kapex-v1.2.0-audit-fix) 

- [X] Upgrade Lego to [`v1.3.0`](https://github.com/totem-tech/totem-parachains/tree/kapex-v1.3.0-polkadot-v0.9.28-alignment)

- [X] Tested the fix on the [Rococo chain](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/accounts) connected to our [Stagex](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fs-ui.kapex.network#/explorer) production staging parachain with the help of Parity devs.

- [X] Upgraded the Stagex Parachain to version `v1.2.0`

- [X] Then upgrade Stagex to `v1.3.0`

- [X] Upgraded [docker Stagex nodes](https://hub.docker.com/layers/totemlive/totem-parachain-collator/staging/images/sha256-bc6fe0e61a347e2f64150aa2fd739bb5e0b12b0702c1b8a4f7da262b39328897?context=explore) to run version `v1.3.0`

## Production preparation
- [X] Decide the block number for the transition in Kapex [chainspec](https://github.com/totem-tech/totem-parachains/blob/main/res/kapex/kapex-parachain-raw.json) - Block number `400000`

- [X] Apply the [new production validation code](https://github.com/totem-tech/totem-parachains/blob/main/res/parachain-code-substitution-wasm.wasm) to Kapex `chainspec`

- [X] Tag the code repo from the main branch in the repo as [`kapex-v1.1.0-codeSub`](https://github.com/totem-tech/totem-parachains/releases/tag/kapex-v1.1.0-codeSub)

- [X] Build a new [docker image](https://hub.docker.com/layers/totemlive/totem-parachain-collator/production/images/sha256-21857f3efd8496a57bd41646d728086173b622ac085f5204f48a015dd9e02310?context=explore) with the new Kapex `chainspec`.

- [X] Restart the Kapex Collators with the new `chainspec`.

- [X] Transfer funds to request code Substitution on Polkadot

- [X] Create Preimage hash on Polkadot `0x1ca2532cbb04d421f1b216f354354524feffd8540e7ca74b0938e58d2cdfc923` 

- [X] Create a proposal

- [X] Create Preimage on Polkadot

We are unfortunately unable to distribute our funds from the Crowdloan until this issue is fixed, so we look forward to the community supporting this proposal through the referendum as soon as possible. Thanks in advance.

The Totem Kapex Team

Kapex Parachain - Validation Code Substitution to fix broken upgrade mechanism and permit XCM Security Vulnerability upgrade.

- There is a proposal to change the number of nomination pools in Polkadot.
- Right now, there are a maximum of 64 nomination pools allowed.
- The proposal wants to increase this limit to 128 nomination pools.
- This change is suggested because everything is working well so far.
- If the Council agrees, the community will have a chance to vote on it later.
- The proposal is measured by a special code called a hash.

![](https://i.ibb.co/ZM5JWMB/Screenshot-2022-12-06-at-10-07-36.png)

Proposal hash: `0x98b3a8aa425c1e1ca5cd96d1b8f3491233b0745575e648a8c5497e83cec76f16`

The proposal aims to **lift the limits imposed on the nomination pools**, which limited the number of nomination pools to **64** in Polkadot, preventing any potential risk if there had been any bugs or issues with the launch. Given that everything works as expected, the new limits are to be increased to **128** total pools. Please note that as this is an external motion, if the Council approves, the community will vote after in the referenda queue for the final decision.

Increasing Max Number of Nomination Pools

- A new proposal is for a project called **Snowbridge** that connects Polkadot/Kusama and Ethereum.
- The project is developed by the Snowfork team and aims to be trustless and permissionless.
- It will be launched on a special parachain called the Bridge Hub.
- The proposal requests funding for 28 months to support the Snowbridge team's work.
- This includes 16 months of past work and 12 months for future work.
- If the proposal is approved, both Polkadot and Kusama communities will vote on it.
- More details about the project are available in the full proposal linked in the document.

Original Proposal: [HERE](https://polkadot.polkassembly.io/treasury/192).

The proposal is now up for vote! aiming to cover the development of **Snowbridge** by the Snowfork team: a fully trustless, permissionless and general purpose bridge between Polkadot/Kusama and Ethereum. The bridge will launch on the Bridge Hub, a common-good parachain that is being developed by Parity for Kusama and Polkadot. This proposal is a funding request for 28 months worth of long term runway for all operations for the Snowbridge team (16 months retroactive, 12 months in future), with the goal to launch as a common-good bridge on the Bridge hub on both Polkadot and Kusama.

The full proposal can be reviewed on [the post](https://polkadot.polkassembly.io/treasury/192) and includes extensive additional details related to further motivation for supporting and promoting Snowbridge, a long term roadmap, governance and economic plans as well as long term economic incentives for successful execution, launch and running of the project. Please note that both networks are voting on the project: the Kusama proposal (up for vote by the community on OpenGov) can be found [here](https://kusama.polkassembly.io/referenda/1). 

If approved by Council, this proposal will be up for vote after by the community in referenda queue. @Councillors: please review and vote at your convenience!

Proposal hash: 0xcb7a0584b5d85d6065d2e492d476aa1c1b92b9a0e492aa668b33036671500ddb

Treasury Proposal: Snowbridge Funding Proposal

This is a motion to upgrade Statemint to v9330. The release notes can be found in the [Cumulus release page](https://github.com/paritytech/cumulus/releases/tag/parachains-v9330). Like the Statemine upgrade, this adds the new asset destruction interface. It also brings in the ability to pay XCM fees using sufficient assets ([PR 1910](https://github.com/paritytech/cumulus/pull/1910)).

Upgrade Statemint to v9330

- A proposal wants to stop the upgrade of Polkadot to version 9320.
- This is because of changes in the FRAME code that affect how schedules work.
- There is a new check in the code to prevent exceeding weight limits for blocks.
- Most functions will work fine, but the `set_code` function will not pass this check.
- This is due to `set_code` using the maximum block weight, which always fails the check.
- A new proposal will be made with the correct call soon.
- The Council must approve this motion before the community votes on it.

This proposal aims to cancel the upgrade of Polkadot Runtime to v9320, due to a change on FRAME code explained below:

As the dev team works on transforming all FRAME pallets and code to work properly with WeightsV2, they have added the following check to the scheduler pallet: 

[https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/scheduler/src/lib.rs#L1105-L1107](https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/scheduler/src/lib.rs#L1105-L1107)

This piece of code should ensure that we don't execute a scheduled call that would use more weight than we have left for the block. For most calls this isn't any problem as they should be fit easily into a block. However, for `set_code` the dev team currently has annotated it with using the max block weight: 

[https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/system/src/lib.rs#L404-L405 ](https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/system/src/lib.rs#L404-L405 )

So, when trying to execute `set_code` with the scheduler it will always fail this check. There will be already some consumed weight when trying to dispatch the call and `some_weight + max_block_weight` will always be bigger than `max_block_weight`. A new proposal will be submitted with the correct call soon.


 - Proposal hash: `0x88998cf7535c1f22d62849be8464fdc38fe46c0a46dc943ec56c91ef6592ec65`

 - Preimage is submitted. 

- Note this motion is an external one: meaning if/after Council approves, the community will vote on this proposal with the final decision.

Cancel the upgrade of Polkadot Runtime to v9320

- A new proposal has been made to cancel an earlier one that is expected to fail.
- The failure is due to recent changes in the code that will not allow the scheduled call to execute properly.
- Developers are working to update the code so that everything functions correctly.
- A new proposal will be submitted soon that should work better.
- The proposal aims to upgrade Polkadot to a new version called v0.9.32.
- There are several minor changes and fixes included in this upgrade.
- After the Council votes on the proposal, the community will also need to vote on it.

This proposal will fail in enactment, so [external motion 306](https://polkadot.polkassembly.io/motion/306) is now opened to cancel this. A change on FRAME code explained below is the reason this will fail: as the dev team works on transforming all FRAME pallets and code to work properly with WeightsV2, they have added the following check to the scheduler pallet: 

[https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/scheduler/src/lib.rs#L1105-L1107](https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/scheduler/src/lib.rs#L1105-L1107)

This piece of code should ensure that we don't execute a scheduled call that would use more weight than we have left for the block. For most calls this isn't any problem as they should be fit easily into a block. However, for `set_code` the dev team currently has annotated it with using the max block weight: 

[https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/system/src/lib.rs#L404-L405 ](https://github.com/paritytech/substrate/blob/b1396f708b2001593d5589dd1bd3f832821fb208/frame/system/src/lib.rs#L404-L405 )

So, when trying to execute `set_code` with the scheduler it will always fail this check. There will be already some consumed weight when trying to dispatch the call and `some_weight + max_block_weight` will always be bigger than `max_block_weight`. A new proposal will be submitted with the correct call soon.

Please note this proposal should be rejected.

______________________
_______________________
_______________________

The proposal aims to upgrade Polkadot’s runtime to [v9320](https://github.com/paritytech/polkadot/releases/tag/v0.9.32): more information can be found on the release notes.


**Runtime**

- [S] ✅ trivial [#12358](https://github.com/paritytech/substrate/pull/12358) Low - Remove contracts rpcs
- [S] ✅ trivial [#12421](https://github.com/paritytech/substrate/pull/12421) Low - Adapt `pallet-contracts` to weightv2
- [S] ✅ audited [#11649](https://github.com/paritytech/substrate/pull/11649) Low - Bound uses of `call`
- [S] ✅ trivial [#12429](https://github.com/paritytech/substrate/pull/12429) Low - Contracts: adapt dry-run runtime apis to weightv2
- [S] ⏳ pending non-critical audit [#12282](https://github.com/paritytech/substrate/pull/12282) Low - Maximum value for `multiplierupdate`
- [P] ✅ trivial [#6021](https://github.com/paritytech/polkadot/pull/6021) Low - Maximum value for multiplierupdate
- [S] ✅ trivial [#12334](https://github.com/paritytech/substrate/pull/12334) Low - Macro stubs for all pallet:: macros to improve documentation visibility and discovery + revamp of pallet macro documentation
- [S] ✅ audited [#12109](https://github.com/paritytech/substrate/pull/12109) Low - Vesting pallet - make `withdrawreasons` configurable
- [P] ✅ audited [#5451](https://github.com/paritytech/polkadot/pull/5451) Low - Manual para lock
- [P] ✅ trivial [#6155](https://github.com/paritytech/polkadot/pull/6155) Low - Add `force_open_hrmp_channel` call
- [P] ✅ trivial [#6171](https://github.com/paritytech/polkadot/pull/6171) Low - Bump transaction_version (0.9.31)
- [S] ✅ trivial [#12558](https://github.com/paritytech/substrate/pull/12558) Low - Update `pallet-multisig` benches
- [P] ✅ trivial [#6189](https://github.com/paritytech/polkadot/pull/6189) Low - Update weights, attempt two (0.9.31)

This release also contains the changes **from v0.9.31 to v0.9.32**: 
- [Substrate#12630](https://github.com/paritytech/substrate/pull/12630): Make `--database` cli argument case insensitive again.
- [Substrate#12632:](https://github.com/paritytech/substrate/pull/12632): Fixes a bug with the transaction pool after doing a warp sync.
- [Substrate#12633](https://github.com/paritytech/substrate/pull/12633): Fixes the `payment_queryInfo` RPC to be compatible with the latest runtime changes.


Proposal hash: `0xbd78d3542767047aba0babb8c8825a5799e3ef54a21193ffe24b98eb4f895162`

You can review the hash and changes in the release notes and use SRTool to verify proposal hash - make sure to vote at your convenience! This proposal is submitted as an **external motion**: meaning after Council vote, the community will need to vote on the proposal in referenda queue.

[PLEASE REJECT] Runtime v9320 Upgrade On Polkadot

- Tether has registered a new token called USDT on Polkadot's Statemint platform.
- They want Polkadot governance to make USDT able to pay transaction fees without needing DOT tokens.
- There are two types of assets on Statemint: Sufficient (which can be used freely) and Non-Sufficient (which need DOT to exist).
- If USDT is approved as Sufficient, users won't have to hold DOT to create accounts.
- This change would help USDT users have more flexibility on Polkadot Network.
- The stablecoin can support various transactions and boost the ecosystem, especially for decentralized finance (DeFi).
- Tether and Polkadot both announced this proposal through their official channels.

[Tether](https://tether.to/en/) registered USDT on Statemint (asset ID `1984` - it can be verified here). The team is requesting Polkadot governance to make it sufficient such that it can pay transaction fees and exist on accounts without DOT. Tether's announcement can be found [HERE](https://tether.to/en/tether-tokens-usdt-live-on-polkadot/). Polkadot's announcement can be found [HERE](https://twitter.com/Polkadot/status/1573299786266050561).

On Statemint, assets can be Sufficient or Non-Sufficient. To hold a Non-Sufficient asset, the Statemint account needs to exist on-chain. This is different from Ethereum where a non-existent account can hold ERC-20 tokens, as users need to ensure that the receiver account has at least 0.1 DOT which is the Existential Deposit for a Statemint account. However, if an asset is Sufficient, the Existential Deposit in DOT on the receiver account is not needed to create the account; the asset itself is sufficient. The team is requesting this property to be voted by governance.

This proposal would allow much more flexibility for holders on Polkadot Network and the stablecoin will power transactions on Polkadot’s Statemint needed for asset deployment and balance-keeping of fungible and non-fungible tokens flowing across the web of blockchains. Many in the community believe as well that a stablecoin like USDT can boost the ecosystem and support an increase of transactions, specifically on DeFi-focused chains.

**Call on Statemint**

- Encoded call: `0x3212011f00d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d200d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d200d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d200d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d282b92a000100`

- Call hash: `0x842d8a934c2aa86a909e0232f730d2f974bfc01e307703a07eefbad6efdb9e1d`

![](https://i.ibb.co/smBWXHt/Screenshot-2022-09-26-at-09-23-00.png)

**Call on Relay Chain**

- Call hash: `0x5eea32679cdac9fc69d2d1ff7740104ec2bb6d412cb121505dbece9d34a239fd`

- Call data: `0x630001000100a10f0204060202286bee39023212011f00d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d200d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d200d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d200d8e5d105e214d8c57e5819fb6d820883f44a617a78a7a6237cb9627ec73a26d282b92a000100`

![](https://i.ibb.co/XLwTgc6/Screenshot-2022-09-26-at-09-24-29.png)



Proposal for USDT Token Sufficiency on Statemint

- There are almost 50,000 nominators involved in a project.
- A new motion is being proposed to improve nomination rules.
- This motion wants to set higher minimum bond limits for nominations.
- There's already a vote for a different proposal called Referendum 86.
- If the new motion is approved, it could replace Referendum 86.
- The goal is to make changes quickly and keep nominations easy.
- More information about why the new limits are important is available online.

As we are almost at 50k nominators and we need to avoid a scenario of no one being able to change or set nominations, this external motion aims to outstrip [Referendum 86](https://polkadot.polkassembly.io/referendum/86) aiming to define slightly higher nomination min bond limits, which is currently up for community vote for next 11 days and with a new motion suggest shorter voting and enactment periods. If approved and later fast-tracked by the TC, making [Referendum 86](https://polkadot.polkassembly.io/referendum/86) redundant; Hence, this proposal, along with updating several staking configurations, would also cancel the [Referendum 86](https://polkadot.polkassembly.io/referendum/86). 

Further information about the importance of the higher nomination min bond limits can be found in the initial discussion post [here](https://polkadot.polkassembly.io/post/1224). 

 ![](https://i.postimg.cc/cJJQF6CT/Screenshot-2022-12-02-at-09-24-23.png)

Redefining Slightly Nomination Minimum Bond Limits and Removing Max Number of Nominators (replacing Referendum 86)

Polkadot is introducing nomination pools to simplify staking for DOT-holders. Currently, nominators can stake a minimum of 10 DOTs and up to 50,000 nominators can participate. The top 22,500 are chosen for each era's election process and may receive staking rewards. Nomination pools aim to make staking easier and are designed to address two main concerns:

1. Encourage waiting nominators to join pools, which is mainly a task for Wallet/UI development.
2. Prevent too many waiting nominators from being created, as most may prefer joining pools instead.

To achieve these goals, the minimum nomination limit could be increased to 100 DOTs, based on the current requirement of around 200 DOTs to be an active nominator. This change would help prevent nominators from being created if they are likely to end up in the waiting queue. However, keeping a buffer of waiting nominators is important for Polkadot's economic security, so the 50,000 nominator limit should remain. With nomination pools, anyone with less than 50 DOTs should be directed to join pools instead, and their nominate transaction should be rejected.

Including contextual information form the staking team below - original discussion post [HERE](../post/1224). 

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Nomination pools are just around the corner for Polkadot, and this suggests some changes to be applied to the staking system.

First, let’s recap on the current status quo: Currently, nominators can freely set their intention to nominate in Polkadot, as long as they meet two limits: a minimum of 10 DOTs is staked, and a maximum of 50\_000 nominators is not filled. This creates a nomination market, where in every era, the top 22\_500 nominators from this open market are chosen to participate in the election process, and possibly receive staking rewards (if other conditions like over-subscription are not met).

This is a complicated and involved process. Nomination pools are exactly here to combat this and provide a simpler experience for DOT-holders to participate in staking.

Based on this, let’s cluster Polkadot nominators into two groups: **active** (in the top 22500), and **waiting**. The main concern at this point is to

-   Encourage all existing waiting nominators to join pools. This is mainly a task for the Wallet/UI development ecosystem, and is beyond the scope of this discussion.
-   Prevent too many waiting nominators to be created. The reason being that I speculate that most of these nominators have **erroneously** in the waiting queue, and prefer joining pools instead.

To achieve the second goal, we can set the nomination limits (10 DOTs, 50\_000) such that the system is not so _inviting_ to waiting nominators. In other words, the system should try and prevent nominators from being created, if they are certainly going to end up being in the waiting queue.

For example, we empirically know that the actual amount of DOTs needed to be an active nominator is around 200 DOTs as of this writing. Therefore, we can set the minimum nomination limit to a higher value such as 100.

Note that keeping a buffer of waiting nominators is a positive factor for Polkadot's economic security. It allows for buffer of waiting nominators to be ready, should a (malicious) cluster of nominators decide to chill all at once, preventing nothing at stake issues. Therefore, I am not suggesting lowering 50\_000 as well, and find that a reasonable bound. But, with nomination pools, I do think we should immediately forward anyone with less than e.g. 50 DOTs to join pools instead, and the way to do that is to immediately reject their nominate transaction.

-   [https://polkadot.polkassembly.io/post/1224](../post/1224)

Proposal: Slightly higher nomination limits

- The proposal is about funding a project called Gossamer.
- Gossamer helps build and run nodes for different blockchains using a programming language called Go.
- It is designed for the Polkadot ecosystem, which is a system of interconnected blockchains.
- The project will take 12 months to complete after getting support from the Web3 Foundation Grants Program.
- The goal is to make the Polkadot ecosystem have different types of clients.
- The proposal needs to be approved and then voted on by the community.
- More details about the budget and plans are available in the post.

The proposal aims to cover the costs for further development of **Gossamer**: a Polkadot host written in Go - a framework to build and run nodes for different blockchain protocols compatible with the Polkadot ecosystem. The timeline of the proposal is 12 months, after the successful collaboration with the Web3 Foundation Grants Program on the initial steps of this development. 

The overall goal is for Gossamer is **to provide the functionality needed to bring true client diversity to the Polkadot ecosystem** Budget, milestones and overall roadmap can be found on [the post](https://polkadot.polkassembly.io/motion/267). Please note that this is up for vote as an external motion: after/if the Council approves, this will be up for vote by the community. Make sure to review and vote at your convenience!

Original Treasury post: [https://polkadot.polkassembly.io/treasury/168](https://polkadot.polkassembly.io/treasury/168)

Original discussion post: [https://polkadot.polkassembly.io/post/1260](https://polkadot.polkassembly.io/post/1260)

External Motion: #168 Gossamer Ongoing Development Grant

- There is a new update for parachains called "v9320."
- The update includes some small changes and bug fixes.
- The word "Anonymous" has been changed to "Pure" in the proxies.
- Two links are given for authorizing upgrades and sending from Polkadot.
- A proposal hash is provided for reference.
- The proposal needs to be approved by the Polkadot Council first.
- After approval, the community will vote on the proposal.

The parachains [v9320 release](https://github.com/paritytech/cumulus/releases/tag/parachains-v9320) contains updates that correspond to the v9320 runtimes of the respective Relay Chain. Changes to Assets and Uniques are minimal, but the release includes the change of “Anonymous” to “Pure” proxy and minor bug fixes.

\- [Authorize Upgrade](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fstatemint-rpc.polkadot.io#/extrinsics/decode/0x0102f02ab4af6b1b58da2805d186f87ca03e808dc0d93d3581b4dbdab4785bea95cb)

\- [Send from Polkadot](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x630001000100a10f0204060202286bee880102f02ab4af6b1b58da2805d186f87ca03e808dc0d93d3581b4dbdab4785bea95cb\))

\- Proposal Hash: 0x1c3e581368a6762a6ecc26903a1fd18345bc212df09e8a66222778def7fcf49d

This proposal is submitted as an external motion: meaning that if/after the Polkadot Council approves, the community will vote on the proposal in referenda queue for the final decision. 

Make sure to review and vote at your convenience!

Statemint Runtime Upgrade to v9320

- A new proposal wants to add a special group called a "common good parachain" to Polkadot, which will help collectives.
- The first group will probably be called the Polkadot Alliance.
- This parachain will help other groups in the Polkadot network too.
- There won't be a similar group for Kusama, but Kusama may join some collectives.
- There will be votes to approve the creation and use of the parachain.
- The first steps include registering the parachain and allowing it to start working.
- More details will come when the official plans are released.

As outlined in a [recent blog post](https://polkadot.network/blog/proposal-for-common-good-parachains/), this discussion is about a proposal to add a new common good parachain to Polkadot focused on collectives. The first collective to form will likely be the [Polkadot Alliance](https://docs.google.com/document/d/1aXlVDDQj6v8kOTvbMXBmenBZ3Sfn5zZf0ipQbYvdipo/edit#), but this parachain will also support other collectives that are in service of the Polkadot network.

There are no plans for a Kusama counterpart to the Polkadot Collectives parachain. In fact, the Kusama network itself may join several collectives to exercise its voice within the Polkadot ecosystem. For example, the Kusama network could join the Polkadot Alliance to set the standards for Polkadot brand use.

Other collectives do not warrant two distinct groups, like the [Technical Fellowship](https://forum.polkadot.network/t/calling-polkadot-core-developers/506). This group of technical experts who have made core protocol contributions to the network, would have nearly identical member sets, as the developers most intimatly familiar with Polkadot's inner workings deploy most of their code on Kusama as a step toward Polkadot.

I intend to submit this proposal to the Council to register and onboard the Collectives parachain with a four-year lease, and posting here first to open discussion.

The full launch will include a series of referenda on Polkadot for approval by the entire stakeholder body. These will be roughly as follows:

1. This proposal, to register the parachain and set the lease period. Once on board, it should start producing blocks. However, since it is not a trusted teleporter from the Relay Chain's point of view, nobody will be able to transact on it as there won't be any DOT with which to pay fees.
1. Runtime upgrade to the Relay Chain to include Collectives as a trusted teleporter.

Finally, I would expect a referendum to initiate the Alliance, which could come before or after the Relay Chain's recognition of the parachain as a teleporter. However, this is outside the scope of this discussion; I expect the Alliance founders to propose how they would like to launch.

The call details will be finalized when Parity publishes the [Collectives genesis release](https://github.com/paritytech/cumulus/releases/tag/parachains-collectives-v9290) and the Technical Committee indicates a rough enactment timeframe, which is needed to set the first period of the lease. The call will be a batch with `registrar.force_register` and `slots.force_lease` and the appropriate parameters.

--------

EDIT: Including call info.

Call hash: `0x9ef867bcaaee9750487738c6e6537eb52a3047c7bb2f06eb30dc05073dae90d5`

For some reason Polkassembly won't allow me to add the entire Polkadot JS link for the call (guessing it is too large), but it is as follows:

![](https://i.imgur.com/DDU8FPX.png)

Polkadot Collectives Common Good Parachain Proposal

- A proposal to upgrade Polkadot's system called "runtime" to version v0.9.30 has been made.
- The new proposal replaces an earlier one because there can be only one idea discussed at a time.
- The last proposal was about changing rules for special groups called nomination pools.
- There are several small tasks being worked on, like improving safety and making changes to how things are named.
- Some tasks have finished reviews, while others are still being checked.
- After the council votes, everyone in the community will also get to vote on this proposal.

The proposal aims to upgrade Polkadot’s runtime to [v9300](https://github.com/paritytech/polkadot/releases/tag/v0.9.30). More information about the release can be found on the link in this post. As the external queue can only hold one proposal at a time, yesterday's [motion 286](https://polkadot.polkassembly.io/motion/286), removing the limits on members in nomination pools, deleted previously approved [motion 285](https://polkadot.polkassembly.io/motion/285) aiming to upgrade Polkadot's runtime. This new proposal replaces motion 285.

**Runtime**

* [S] ✅ audited [#12170](https://github.com/paritytech/substrate/pull/12170) Low - Pallet-identity: be more paranoid ;)
* [S] ⏳ pending non-critical audit [#12222](https://github.com/paritytech/substrate/pull/12222) Low - Add constfeemultiplier to the transaction payment pallet
* [S] ⏳ pending non-critical audit [#11981](https://github.com/paritytech/substrate/pull/11981) Low - Breaking: rename call & event
* [S] ✅ trivial [#11738](https://github.com/paritytech/substrate/pull/11738) Low - Add inspect trait for asset roles
* [S] ⏳ pending non-critical audit [#11806](https://github.com/paritytech/substrate/pull/11806) Low - Improve base weights consistency and make sure they're never zero
* [S] ✅ trivial [#12205](https://github.com/paritytech/substrate/pull/12205) Low - Add special tag to exclude runtime storage items from benchmarking
* [S] ⏳ pending non-critical audit [#12034](https://github.com/paritytech/substrate/pull/12034) Low - [feature] part 1: add targetlist for validator ranking
* [S] ✅ trivial [#12186](https://github.com/paritytech/substrate/pull/12186) Low - Contracts: use weakboundedvec for instrumented code
* [P] [#5535](https://github.com/paritytech/polkadot/pull/5535) Low - Runtime/disputes: slashing
* [S] ✅ trivial [#12258](https://github.com/paritytech/substrate/pull/12258) Low - Breaking: rename origin
* [S] [#12230](https://github.com/paritytech/substrate/pull/12230) Low - Bound staking storage items
* [S] ✅ trivial [#12083](https://github.com/paritytech/substrate/pull/12083) Low - Make automatic storage deposits resistant against changing deposit prices
* [S] ✅ trivial [#12283](https://github.com/paritytech/substrate/pull/12283) Low - Rename anonymous to pure proxy
* [P] ✅ trivial [#6037](https://github.com/paritytech/polkadot/pull/6037) Low - Increase blockhashcount parameter
* [S] ⏳ pending non-critical audit [#12329](https://github.com/paritytech/substrate/pull/12329) Low - Add base-weight to system::extrinsic* events
* [P] ✅ trivial [#6032](https://github.com/paritytech/polkadot/pull/6032) Low - Paras: unblock offboarding when pvf-check concludes
* [S] ⏳ pending non-critical audit [#12366](https://github.com/paritytech/substrate/pull/12366) Low - [feature] add deposit to fast-unstake
* [P] [#6050](https://github.com/paritytech/polkadot/pull/6050) Low - Add fast-unstsake pallet to all runtimes
* [S] ⏳ pending non-critical audit [#12277](https://github.com/paritytech/substrate/pull/12277) Low - Add storage size component to weights

Proposal hash: `0xf1eeaa09f9a85633cf7f1fa588bf3247a58acf9f4cb3e8e12350833c595bc7d3`

You can review the hash and changes in the release notes and use SRTool to verify proposal hash - make sure to vote at your convenience! This proposal is submitted as an **external motion**: meaning after Council vote, the community will need to vote on the proposal in referenda queue. 

Runtime v9300 Upgrade On Polkadot

- This content is about a new plan to fix a previous issue with a project called Referendum 74.
- The first plan didn't work, so they made changes to improve it.
- Instead of combining actions into one, they separated them into individual actions.
- It adds a new connection for something called Bifrost (ParaId 2030).
- They will transfer 22 DOT (a type of money) for these actions.
- They want to make this happen quickly since a similar plan was already approved.

**Note: Supersedes 282**

This is a fix of [Referendum 74](https://polkadot.polkassembly.io/referendum/74), which [failed to execute properly](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io/$WokrZ22XOgT8nAIUmx18WYRUsF3a-F6xcezGReQZ58A?via=matrix.parity.io&via=corepaper.org&via=matrix.org). Instead of using a Transact instruction containing a batch call, this uses a batch of Transact instructions, each with one call in it. This should work on the current version of Polkadot.

In addition to the original 5 channel requests, this also adds a sixth pair with ParaId 2030 (Bifrost).

The force_transfer is for 22 DOT: 20 for the sixth parachain (the 100 DOT from Ref 74 did get transferred) and 2 DOT for the XCM execution fees (the remainder of which will be transferred back to the Treasury).

Since the referendum already passed, requesting TC to fast track this one, presuming it passes Council.

Democracy Referenda