The proposal, upgrading Polkadot Runtime to **v9080**, is up for vote. Release notes, runtime changes and proposal hash can be found [HERE](https://github.com/paritytech/polkadot/releases/tag/v0.9.8). 

This release introduces a **new host function**: As such, node operators should upgrade before the next runtime upgrade on their chain in order to continue being able to sync the chain. 

Please vote at your earliest convenience!

Runtime v9080 on Polkadot Network

### Summary of Post Content

1. A referendum to open a channel to HydraDX passed.
2. The XCM (Cross-Consensus Message) was executed.
3. The channel was not opened due to insufficient funds in Zeitgeist's sovereign account on Polkadot.
4. The account has now been funded.
5. The XCM can be resent to open the channel.

This is a proposal whose proposer address (15MrYzj6KsJAom1V3eTH4Wgsz86FLVE65dF7SEeNkPYSsSs7) 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.

Init HRMP open channel request to HydraDX

- A proposal is being made to change nominator limits so more people can join.
- Right now, current nominators can't change how much they want to stake.
- The update will let existing nominators not be affected by any new limits.
- The nominator capacity will increase by 2,500, reaching a total of 22,500.
- The amount needed to stake will also change to 40 DOTs.
- These changes will help keep things stable until the next upgrade.
- If too many people join quickly, the stake limit may need to go up again.

The proposal will upgrade the nomination limits such that more people can start nominating. Note that this is a time-sensitive action, because currently existing nominators cannot change their intentions. [This pull request](https://github.com/paritytech/substrate/pull/9193) will change this logic, so that those who are already a nominator will not be affected by any limit, and **will be placed in the next Polkadot  runtime upgrade**.

The new limits increase the nominator capacity by `2500` (making it `22500` in total), and increase the the stake threshold to `40DOTs`. It is intended that these numbers would keep the current count of nominators (all of whom must have 40 or more DOTs) below the new count limit (`22500`) **until the next runtime upgrade**: If an influx of nominators is observed over a very short period of time, the stake limit might need to be increased again proportionally to keep the staking system stable.  

Preimage [HERE](https://drive.google.com/file/d/1Pp8mkUkFCkYiauUAe2RXFBhzk5wgulGV/view?usp=sharing).

Please vote at your convenience!

Upgrade the nomination limits on Polkadot

- The proposal limits the number of validators to 1200.
- Nominators' parameters remain unchanged (20000/20DOTs).
- It started as an external motion, needing Council approval and community referendum.
- Discussions on a minimum DOT stake limit for validators are ongoing.
- These limits aim to ensure network safety and will increase as the network grows.
- The proposal's preimage is available [here](https://drive.google.com/file/d/1W8J1zSPobzNMSAoAWaSeTWvLRI7QdmwH/view?usp=sharing).
- More context and explanations are in the [last runtime upgrade post](https://polkadot.polkassembly.io/motion/88).
- Please vote when you can!

The proposal **sets a limit on the maximum number of validators**, namely `1200`, and leaves the rest of the parameters unchanged (`20000`/`20DOTs`) for nominators. This proposal started as an **external motion**, meaning that if the Council passes this, the community needs to vote in referenda queue to be executed. 

The validator community should be aware that the discussion around minimum DOT stake limit for validators (similar to what was imposed recently on nominators) has already begun [on the Polkadot Direction channel](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io?via=matrix.parity.io&via=matrix.org&via=corepaper.org), and will be proposed **as soon as discussion reaches consensus**. Similar to the nominator limits, **these limits are for the safety of the network and will grow as the network grows.**

The preimage of this proposal can be found [HERE](https://drive.google.com/file/d/1W8J1zSPobzNMSAoAWaSeTWvLRI7QdmwH/view?usp=sharing). 

Context on why this is needed and an explanation of the scaling issues we are seeing on Polkadot Network can be found on the [last runtime upgrade post](https://polkadot.polkassembly.io/motion/88).

Please vote at your convenience!

Limit on the maximum number of validators, based on scaling issues

- Polkadot is proposing an upgrade to its system called v9050.
- This upgrade is important for fixing problems with how staking works on the Polkadot Network.
- It will set a limit on how many nominators can be on the chain, which can be changed by the community.
- There are discussions and details available about this upgrade and its effects.
- Important information about staking elections and solutions is also shared by Wei.
- A blog post explains the changes in staking limitations due to this upgrade.
- Everyone is encouraged to vote on this upgrade soon!

The proposal, upgrading Polkadot Runtime to v9050, is up for vote. Release notes, runtime changes and hash can be found [HERE](https://github.com/paritytech/polkadot/releases/tag/v0.9.5). This release resolves the scaling issues we are seeing on Polkadot Network with staking, introducing hard limits on the number of nominators on chain: which is configurable with governance.

- Previous discussions about the runtime upgrade on the Polkadot Direction channel can be found [HERE](https://matrix.to/#/!OwgojQyBzTlUQGGLhq:matrix.parity.io/$EVsIkHKQaZHNrnOCSrLWwE918yPa3u6srpziFs4usvo?via=matrix.parity.io&via=matrix.org&via=corepaper.org).
- Wei’s post on Polkadot’s staking election situations, problems and discussions about potential solutions can be found [HERE](https://corepaper.org/polkadot/staking/). 
- The blogpost by Polkadot explaining the staking limitations and changes with this runtime upgrade proposal can be found [HERE](https://polkadot.network/polkadot-and-kusama-staking-changes/).

Please vote at your earliest convenience!

Runtime v9050 on Polkadot Network

- Some validator nodes on Polkadot had a problem where they couldn't find enough memory.
- This happened during an important event called the staking election.
- The issue is related to an off-chain worker that uses a special memory setting called WASM.
- Right now, the off-chain worker and the main program share the same memory limits.
- The team thinks increasing the memory pages for the off-chain workers will help solve the problem.
- They plan to do this temporarily while working on a permanent solution.
- The current default memory setting is 1024 pages, and it's checked on-chain.
- A member of the team is focusing on a long-term fix to separate the memory settings.

**UPDATE: Please be so kind to reject this proposal, the team has included the heap pages increase on an upgrade and this seems to be the best way to approach the issue.**

---

We’ve noticed that some validator nodes on polkadot, encounter a “allocator failed to allocate memory” error around the time when the staking election (phragmen) is being computed. Recall that this computation is happening in an **offchain worker thread**. Nonetheless, in the current implementation, the offchain worker thread, which itself is executed in WASM, uses the same WASM environment as the canonical runtime, and therefore has limited memory. To prevent the situation where no validator submits an election solution, the amount of memory accessible to the offchain worker environment should be increased.

Note that ideally, this change should only affect the offchain worker thread, and not the main runtime. But as mentioned, currently they share the same configurations. A long term solution is to separate these configurations and only increase the amount of memory that is accessible to the offchain worker ([PR](https://github.com/paritytech/substrate/pull/8885)). But, since this is not readily possible, we opt to propose increasing the overall WASM runtime memory pages, which affects both block execution and offchain worker. We expect this decision to have **no notable effect** on the main runtime’s progress and execution.

The amount of memory available to WASM is determined in the number of “pages of memory” that can be allocated in the called, aka. “**Heap pages**”. This value lives on-chain, and you can inspect it similar to other [well-known-keys via “:heappages](https://github.com/paritytech/substrate/blob/28107d402cb88cf50119c4ecb16555fcacf3a3e6/primitives/storage/src/lib.rs#L166)”. Currently, no value is set there and a [default of 1024](https://github.com/paritytech/substrate/blob/ef0e22e11535abaa393122209f83ed02a068a464/client/executor/src/native_executor.rs#L48) is used.

More info can be found [HERE](https://docs.google.com/document/d/12CFQlgBxWwBOcpyoJiNhifvAoPQKBDej9f3YRf9Moq8/edit?usp=sharing). This proposal is a temporary solution, Kian from Parity is working on a permanent fix [here](https://github.com/paritytech/substrate/pull/8885).

Preimage for the motion [HERE](https://drive.google.com/file/d/1p1gQKqzYKo2CL-GrsZI2qNonH_kwGZXG/view?usp=sharing).

Increasing the WASM heap pages.

- Jonathan Kleiman is a lawyer in Toronto with 10 years of experience.
- He is a candidate to become a Polkadot ambassador.
- Jonathan can verify identities using two photo IDs and a video call.
- He plans to charge 3 DOT for this verification service and offers it for free to voters of his proposal.
- He aims to make identity confirmations trustworthy, as they will have legal backing.
- Non-English IDs can be verified with help from a local lawyer.
- Additional lawyers can help if there are too many verifications to handle.

Hello. My name is Jonathan Kleiman. I am a Polkadot ambassador candidate, and I have been a lawyer in Toronto for 10 years. I am licensed by the Law Society of Ontario. You can find my website at www.jkleiman.com, and you can peruse my google reviews [here](https://g.page/kleimanlaw?share). 

As a lawyer, I am licensed to verify documents as a notary. My intention is to verify legal name identities on-chain using this same process. Specifically, I will require two pieces of photo ID, and a short video call to confirm that the person seeking identification is indeed the person on the ID's provided. 

The video call (no, a screenshot - see edit) will be recorded for verification records, but will not be shared without requestor's consent or a court order, if for some reason the requestor needs to prove that their identity was properly verified.

As a lawyer, the risk to me of publicly confirming somebody's identity incorrectly is very serious, as the public would be assured of the reliability of such verification and would be able to rely upon it as if it were notarized by me. For this reason, verifications performed by me will be completely trustworthy, without question.

I plan to charge 5 DOT (3 DOT, see edit) for the verification services. Any voters for this proposal when it reaches referendum will receive their verification for free by fee refund once the proposal is approved (unless this is disallowed)

Please feel free to send any questions or suggestions to me at [Jonathan@JKleiman.com](mailto:jonathan@jkleiman.com)

[Proof of License](https://lso.ca/public-resources/finding-a-lawyer-or-paralegal/directory-search/members/lawyer/049/jonathan-louis-kleiman)

EDITS: 

1) I am lowering the price to 3 DOT, given the recent and anticipated price appreciation

2) Pursuant to comments, I suggest that no video be recorded, but that a screenshot of the video be taken and held on offline storage.

3) I will offer to verify email, twitter, and element name as well.

4) Non-english identification can be done, but must involve a lawyer licensed to practice in the jurisdiction that the account holder resides, who can certify the identity for the Registrar.

5) In the event that there are too many for one person to handle, additional lawyers can be involved to verify identities, but the main registrar would still be responsible to ensure the process is secure and reliable. This practice is acceptable to my law society as well - I am allowed to rely on the certification of a person's identity as long as it is done by a lawyer in their jurisdiction, and I am able to confirm the lawyer's identity and their license to practice law, and receive ID of the account holder.

6) Thank you to those who have participated in the discussion, and those who have foregone staking rewards by seconding my proposal.


Lawyer to Verify Legal Names

**Motion 78** upgrading Polkadot Runtime to **v30** is up for vote.   Release notes, runtime changes and hash can be found [HERE](https://github.com/paritytech/polkadot/releases/tag/v0.8.30). 

All council members please vote at your earliest convenience!

Runtime v30 on Polkadot

This is a proposal whose proposer address (16hu63GujrmJPW9ZbGibj6gFnLFe4yW8A7gDgADmRTmpaUkf) 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.

Unlock manager account

- Proposal 10 is a plan that can't be used anymore because it has the wrong address format.
- It doesn't matter how people vote; the proposal is still invalid.
- The person who made the proposal admitted they used the wrong way to submit it.
- They have created a new proposal, number 11, that people can vote on now.
- Everyone is asked to vote to cancel proposal 10.
- The goal is to clean up the list of proposals.

Proposal 10, a `force_transfer` proposal, cannot be executed: since the Address formats changed, it is now invalid: So it does not matter which way the vote goes, it cannot be applied.

Furthermore, the proposer explains they used the wrong method to submit this proposal, replacing no. 10 with [no. 11](https://polkadot.polkassembly.io/proposal/11) (currently up for vote as Referendum 18). 

Please vote to cancel the proposal and clean the queue. 

Preimage: `democracy > cancelProposal(prop_index) 10`: [HERE](https://drive.google.com/file/d/1W9v7a6LPvO6MzpCy0VahxtRTxv7swcZi/view?usp=sharing).

Cancellation of Proposal 10 on Proposals queue

This is a proposal whose proposer address (12tbKWY62Vkh9S2jgXejrxu64B2Hd7KQoU2D6w6f9ZpSTjJP) 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.

Increase active collator set size to 32

**Runtime v29 on Polkadot** 

**Motion 70** upgrading Polkadot Runtime to v29 is up for vote.   Release notes, runtime changes and hash can be found [here](https://github.com/paritytech/polkadot/releases/tag/v0.8.29). 

All council members please vote at your earliest convenience!

Upgrade of Polkadot runtime to v29

Increase active collator set size to 28

- Motion 62 is about upgrading the Polkadot system to version 28.
- Some changes include treasury tip slashes and free participation in Council for newcomers.
- There will be a reorganization of the treasury system.
- Changes will help validators with session keys related to parachains.
- New features will allow checking if accounts exist and a new address format.
- More detailed information can be found in the release notes online.

**Motion 62 upgrading Polkadot Runtime to v28 is up for vote.**

**Some interesting changes:** treasury tip slashes, free participation in Council governance for first-timers, refactor treasury pallet, changes for validators session keys to account for parachains, Introduction of account existence providers reference counting and extensive multiaddress format in all runtimes. 

Release notes, runtime changes and hash can be found [here](https://github.com/paritytech/polkadot/releases/tag/v0.8.28).

Upgrade of Polkadot Runtime to v28

This is a proposal whose proposer address (12jjdP15mZnY3pTNPwa6pyGSAGnz9fyr9dmqbkzB7VhSMy6Y) 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.

Increase active collator set size to 24

- A bug was fixed in the Polkadot v26 runtime that affected some accounts.
- This bug caused unfair slashing of candidacy bonds in the council.
- Motion 43 is a plan to refund those affected accounts.
- It aims to help candidates and runners-up who were hurt by the bug.
- A system called `utility.batch` will handle all refunds together.
- Councillors are asked to vote on this motion.
- If it passes, the community will also vote on the proposal.

As you might remember from past discussions, with the v26 runtime being in Polkadot, [a bug](https://github.com/paritytech/substrate/pull/7384) that caused immature slashing of candidacy bonds in council was fixed, and now's the time to proceed with refunding affected accounts.

Based on our experience in Kusama Network, **Motion 43** aims to reimburse candidates and runners-up who were slashed due to this bug. In order to verify hash, please review this [gist](https://gist.github.com/kianenigma/93c3a86a72823a3f703c442e00929a0a) (generated using [this snippet](https://github.com/paritytech/substrate-debug-kit/blob/b6b818ae1bc6a834f2010e8a58726231034ed8c1/remote-ext-elections-phragmen/js/src/index.ts#L597-L624)). The motion wraps all of the reimbursement calls inside a `utility.batch`, creating a single batch of force transfers from the treasury to the affected accounts. 
All councillors please vote at your convenience! If the motion passes, the proposal will be after voted by the community.

Original post can be found [here](https://polkadot.polkassembly.io/post/165).

Incorrect Slashing on Council Caused by elections-phragmen Pallet Bug

**Motion 56 upgrading Polkadot Runtime to v27 is up for vote**.

 After a successful upgrade on Kusama, [motion 56](https://polkadot.polkassembly.io/motion/56) is submitted on Polkadot, aiming to upgrade the network’s runtime to v27. 

  Upgrade priority: **Low** (upgrade at your convenience).

 Release notes, runtime changes and hash can be found [here](https://github.com/paritytech/polkadot/releases/tag/v0.8.27). Please vote at your earliest convenience!

Upgrade to Polkadot runtime v27

This is a proposal whose proposer address (12jXX8aU8QGRrc9zb2vgVdtSnnTsqKZjf3sKYK8haFcPdpr9) 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.

Increase active collator set size to 20

- Motion 38 is a vote to upgrade to a new version called v26.
- The priority for this upgrade is medium.
- There are some important changes in this upgrade:
  - It fixes how target names with dashes are logged.
  - It stops using old substreams that aren't needed anymore.
  - It makes certain functions unsafe for remote use.
- People can find more details in the release notes.

**Motion 38** is up for vote: the motion upgrades the runtime to v26.   Upgrade priority: Medium due to changes: Fixes logging of target names with dashes ([#7281](https://github.com/paritytech/substrate/pull/7281)), No longer actively open legacy substreams ([#7076](https://github.com/paritytech/substrate/pull/7076)), Make queryStorage and storagePairs unsafe RPC functions ([#7342](https://github.com/paritytech/substrate/pull/7342)))

Hash and release notes can be found [here](https://github.com/paritytech/polkadot/releases/tag/v0.8.26). 

Runtime upgrade to v26

- The proposal aimed to increase the active collator set size to 16.
- It was linked to a runtime upgrade to Zeitgeist v0.3.6 (`spec_version 40`).
- The parachain-staking pallet changed function indices after the upgrade.
- Before the upgrade, the function selector for `setTotalSelected` was `0x6e06`.
- After the upgrade, `setBlocksPerRound` took `0x6e06`, and `setTotalSelected` became `0x6e04`.
- The proposal originally intended to invoke `setTotalSelected`.
- After the upgrade, it mistakenly invoked `setBlocksPerRound`.
- The proposal should be rejected due to this error.

This is a proposal whose proposer address (1hP1j6MT33vmiSUJBzFR5oyrowYZrGcj7kRV9exh7rFYi6A) 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.

Increase active collator set to 16

- A referendum is a way for a community to vote on something important.
- Referendum 7 did not work because it was set to start at zero instead of one.
- The code needed to check if the start time was in the past.
- If it had been set to one, it would have started as soon as the next block happened.
- The writer wants to propose the same idea again to the Council.
- They hope the Council will send it to the voting queue like before.

Referendum 7 (passed by the Council and the community) failed to come into place given the parameter to be executed after was 0 (zero) instead of 1.

```
let when = match when {
			DispatchTime::At(x) => x,
			DispatchTime::After(x) => now.saturating_add(x)
		};

		if when <= now {
			return Err(Error::<T>::TargetBlockNumberInPast.into())
		}
```

0 fails to check, but 1 would happen next block after the referendum is passed. I am proposing the exact same motion to Council and requesting TC to pass to referenda queue in the same way as before.

Proposal to gradually increase the number of validators

This is a motion whose proposer address (13RDY9nrJpyTDBSUdBw12dGwhk19sGwsrVZ2bxkzYHBSagP2) 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.

- Motion 25 wants to add 1 more validator slot every time a new era starts.
- This will happen for 100 eras, which is a lot of blocks.
- The motion will be voted on after the council discusses it.
- The voting process takes about 7 days.
- Councillors need to check a special code called the presage hash.
- Everyone is welcome to share comments or questions. 
- More details can be found in the original proposal link.

**Motion 25** schedules an increase of validators slots by 1 every era (14,400 blocks) with a repetition of 100 eras. 

The motion is to be voted on referenda queue if passed by council for approx. 7 days, after the TC fast-tracks, as explained [here](https://polkadot.polkassembly.io/post/93).   Councillors: **to verify presage hash** you can check [here](https://polkadot.polkassembly.io/post/93#3baa6f49-06c7-4d47-9cb8-44bd19f789d6). Feel free to add any comments or questions. 

Original proposal: https://polkadot.polkassembly.io/post/93

A proposal to gradually increase the number of validators

Motion 20 upgrading Polkadot Runtime to v24 is up for vote.

Upgrade priority: Medium (timely upgrade recommended) To see changes and for release notes and hash, please check [here](https://github.com/paritytech/polkadot/releases/tag/v0.8.24).

All council members please vote at your earliest convenience.

Democracy Referenda