- This is a plan for the first parachain auctions on Polkadot.
- The auctions will happen every 3-6 months.
- The first set will have five auctions starting on November 11.
- Each auction will last for seven days.
- The second set will have six auctions starting on December 23.
- The number of parachain slots on Polkadot will be limited to 75% of those on Kusama for safety.
- The auctions help with the growth and stability of the network.

proposalHash

votingPeriod

delay

Proposal for First Parachain Auctions on Polkadot

This is a proposal to schedule the first set of parachain auctions on Polkadot as well as get
Council buy-in to a recommended strategy for scheduling auctions on a 3-6 month basis.

Based on the performance of parachains on Kusama and the state of audits, the Parity engineering
team believes that the code for parachains, auctions, and crowdloans is ready for an initial
production release.

This motion proposes two batches of auctions:

- The first: five auctions, starting 11 Nov, seven days each, beginning every _seven_ days, for
  lease periods 6-13 (LP6 is slated to begin 15 Dec)
- The second: six auctions, starting 23 Dec, seven days each, beginning every _14_ days, for
  lease periods 7-14 (LP7 is slated to begin 09 Mar 2022)

As auctions can take place prior to a lease period starting, this motion schedules auctions to
begin around mid-day (UTC) of 11 November.

In order to ensure stability guarantees, I suggest along with this proposal that the Council and
network governance limit the number of parachain slots on Polkadot to 75% of that on Kusama. This
initial schedule will last until early March; as the network grows the Council can suggest an
updated auction cadence to stay within a reasonable factor of safety relative to the number of
parachains on Kusama.


Proposal for First Parachain Auctions on Polkadot

- A proposal for upgrading Kusama’s system to a new version, v9110, is up for voting.
- The first attempt used a file that was too big, so a smaller version is needed now.
- The new proposal uses a compressed hash to fit in the network.
- You can find more details about the upgrade by checking the links provided.
- People can use a tool called `srtool` to see the proposal hash.
- Voting is important, and everyone is encouraged to participate!

When submitting the image for the Kusama proposal upgrading the runtime to v9110, we realised the hash used was compact, not compressed. The compact wasm file is too big to be added to the network, therefore a compressed hash needs to be used: [**Motion 117**](https://polkadot.polkassembly.io/motion/117) is now up for vote!  **This motion executes the same upgrade to v9110, this time with compressed hash**. 

The motion proposes an upgrade of the Polkadot Runtime to **v9110** - Release notes, runtime changes and proposal hash can be found [HERE](https://github.com/paritytech/polkadot/releases/tag/v0.9.11). Please feel free to use `srtool` yourself to check the proposal hash. If passed by the Council.

Hash: `0x791e698f3690481e0eb16d35017cf3bb27ec095ec6f27dafd3a230b76dc42f86`

Make sure to vote at your convenience!

Runtime v9110 on Polkadot Network

- There is a new proposal to upgrade Polkadot to version v9110.
- People can find details about the release, changes, and proposal hash online.
- The proposal hash is a special code: 0xe874dd4219efa603acc0ab24a592d6f1b8553b7aedb196d1ef65fdd7fc3b8fe5.
- It is important to upgrade because past changes in version v9100 can't be skipped.
- Voting for this upgrade is encouraged when it's convenient for everyone.
- The upgrade will happen after the previous version v9100 on the network and v9110 on Kusama.

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

Hash: `0xe874dd4219efa603acc0ab24a592d6f1b8553b7aedb196d1ef65fdd7fc3b8fe5`.

Please feel free to use `srtool` yourself to check the proposal hash. Migrations and other important changes in v9100 make it impossible to skip this release - hence why the new vote. If fast-tracked, TC should ensure this is enacted after v9100 in the network and after v9110 on Kusama.

Make sure to vote at your convenience! 

- A new proposal is for upgrading Polkadot Runtime to version v9100.
- People can vote on this proposal.
- More information can be found in the release notes.
- The proposal hash is 0x8160fd4a5aa5d58491cc8d4f0919780da25feb9ada92c2126b3f1d859800dd81.
- You can check the proposal hash using a tool called srtool.
- The upgrade will happen after another upgrade on a different network called Kusama.
- Remember to vote when you get a chance!

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

Hash: `0x8160fd4a5aa5d58491cc8d4f0919780da25feb9ada92c2126b3f1d859800dd81`.

Please feel free to use `srtool` yourself to check the proposal hash. The proposal uses a non compressed version of the runtime. We should aim for the TC to fast-track for enactment only after Kusama's runtime upgrade has been executed. 

Make sure to vote at your convenience! 

Runtime v9100 on Polkadot Network

- The staking team wants to change some rules to let more people help keep the network safe.
- Right now, there are 22,500 nominators, but no new ones can join because of current rules.
- They want to increase the minimum bond, which is the amount of money needed to join.
- The suggested new bond is 120 DOTs instead of 80 DOTs.
- This change is meant to last for at least a month before needing another update.
- They will release monthly reports to keep everyone informed about how things are going.
- This is a temporary change to make sure the network stays stable and secure.
- Comments and feedback about the proposal are welcomed.

The staking team requested a new proposal to increase the minimum bond and allow new nominators above the threshold to participate in the network’s security mechanism. As mentioned by the Staking team on [this message](https://matrix.to/#/!FdCojkeGzZLSEoiecf:web3.foundation/$YNsqfhHKXoRbW_QKvtG5EKn8HodUGFts6abJJdSAoVA?via=matrix.parity.io&via=matrix.org&via=corepaper.org), Polkadot currently has 22500 nominators and the configuration of the staking system prevents further nominators to join.

The team suggests to update the staking parameters: The proposal has the goal to increase the minimum bond to allow new nominators above the threshold to participate in the network’s security mechanism, and for less staked nominators to be chilled. **Note that after the latest runtime upgrade (9090), existing nominators can always update their preference at all conditions.**

The proposal the team suggested aims to change the staking parameters to allow more nominators with higher backing stake be able to join the staking system. The existing parameters as follows:

- Minimum validator bond: None
- Maximum validator count: `1200`
- Minimum nominator bond: `80` DOT
- Maximum nominator count: `22500`
- Chill threshold: 90%

The new proposed parameters aim to update one value:

- New minimum nominator bond: `120` DOTs

The team aims to increase the limit enough so that we won't need to do another tweak for at least a month. **Multiple tracks of optimization are ongoing by the development team**, and you can read more about them on this [issue](https://github.com/paritytech/substrate/issues/9511). Furthermore, a monthly progress report will be released [here](https://gist.github.com/kianenigma/aa835946455b9a3f167821b9d05ba376) to communicate the technical details. Please note that increasing the value of the parameter to **120 DOTs** will hopefully give the team another more time until the new threshold is reached and we have made progress on a more permanent solution. Please leave your comments and feedback on the proposal. Keep in mind these measure is **temporary**, and the overall goal is the stability and security of the network.

- Preimage [HERE](https://drive.google.com/file/d/10FRH_Hzs8kqwI_lfMZhC6bu6Dt0bQdCf/view?usp=sharing) - submitted.
- Hash: `0xb862a50c4e8541c013637e9766f3059af75218f0f9630dc8b6c85dc8f633a971`

Please vote at your convenience!

Increasing nominators’ min bond on Polkadot

- A proposal to upgrade Polkadot to version v9090 is being voted on.
- You can find details like release notes and changes online.
- Developers should be aware that there is a breaking change in this version.
- This proposal uses a special type of runtime called NON COMPRESSED.
- There is a specific hash number related to the proposal.
- Everyone is encouraged to vote when they can.

The proposal, upgrading Polkadot Runtime to **v9090**, is up for vote. Release notes, runtime changes and proposal hash can be found [HERE](https://github.com/paritytech/polkadot/releases/tag/v0.9.9). If you develop & maintain applications for Polkadot, please note there is [a breaking change](https://github.com/paritytech/substrate/pull/9462) on this runtime.

Hash: `0x6f7f0451388d9053db17c61c67678fdd0d775f9c74dc46ebea565ad0cd52bd6e`.

This proposal uses the NON COMPRESSED runtime.

Please feel free to use `srtool` yourself to check the proposal hash. Make sure to vote at your convenience!

Runtime v9090 on Polkadot Network

- Polkadot has 22,500 nominators, but can't add more right now.
- The staking team wants to change rules to allow new nominators to join.
- They plan to increase the minimum amount needed to join from 40 DOTs to 80 DOTs.
- This change will help fill 4,500 available spots for new nominators.
- A new rule called "chill-threshold" will be set at 90%.
- The goal is to make the network stable and secure.
- These changes are temporary until better solutions are found.

As mentioned by the Staking team on [this message](https://matrix.to/#/!FdCojkeGzZLSEoiecf:web3.foundation/$YNsqfhHKXoRbW_QKvtG5EKn8HodUGFts6abJJdSAoVA?via=matrix.parity.io&via=matrix.org&via=corepaper.org), Polkadot currently has 22500 nominators and the configuration of the staking system prevents further nominators to join. 

The team suggests to update the staking parameters as soon as the next runtime upgrade happens today. The proposal has the goal to increase the minimum bond to allow new nominators above the threshold to participate in the network’s security mechanism, and for less staked nominators to be chilled. Note that after 9080, the existing nominators can always update their preference at all conditions. 

The proposal the team suggested will change the staking parameters to allow more nominators with higher backing stake be able to join the staking system. The existing parameters as as follows:

* minimum validator bond: None
* maximum validator count: `1200`
* minimum nominator bond: `40` DOTs
* maximum nominator count: `22500`

**The new proposed parameters will update one value:**
* new minimum nominator bond: `80` DOTs

 and set a new parameter that did not existed before:
* chill-threshold: 90%

The reasoning behind the new minimum nominator bond: Polkadot onboards ~150 nominators per day. That means if the network has 4500 empty slots, they will be filled in 30 days. The team aims to increase the limit enough so that we won't need to do another tweak for at least a month. Changing this parameter to `80` will almost expose 4500 nominators. 

The new chill-threshold will ensure that the permissionless `chill_other` can only be used when more than 90% of "maximum nominator count" is used.
note that to ensure polkadot's stability until the parachains launch, this motion does not yet include an increase in the total count of nominators. Multiple tracks of optimization are ongoing by the development team, and you can read more about them in this [issue](https://github.com/paritytech/substrate/issues/9511).

Please note that doubling the value of the parameter to `80` DOTs will hopefully give the team more time until the new threshold is reached and we have made progress on a more permanent solution. Please leave your comments and feedback on the proposal. Keep in mind these measures are temporary, and the overall goal is the stability and security of the overall network. 


- Preimage can be found [HERE](https://drive.google.com/file/d/1ZdXO1y6_UUlsjaPZgNla6elaMUQgtOxS/view?usp=sharing).

- Hash: `0xc8ca426c26fc637ab82f56e69e91469c6c7205b01609e7970c0ed11cc0c7981f`
- Encoded call data: `0x07170040b743ba00000000000000000000000000000000000000000000000000000001e457000001b0040000015a`

Increasing nominators’ minimum bond on Polkadot

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

- 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.

**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

**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

- 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

- 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

- A new idea is suggested for increasing the number of validators in the network.
- The plan is to add 1 new validator each day for 100 days.
- The goal is to have 100 more validators by the end of this period.
- This gradual increase helps the community check and review the network's performance.
- If needed, the process can be stopped, and the community can look at the data.
- This method is suggested to avoid sudden big changes in the number of validators.
- The parachains team also supports this idea.

Following up on [this idea](https://polkadot.polkassembly.io/post/283), I am proposing an external motion to be voted by the Council and by the community after. **The motion aims to schedule a gradual increase in the number of validators: 1 slot per day (14,400 blocks) for 100 days. **

We aim for and increase of 100 validators to be able to review metrics after completion. This mechanism can also be canceled, and at that moment the community will be able review network metrics. The proposal aims to avoid an abrupt increase in the number of validators in the network and follows the recommendation of the parachains team as noted [**here**](https://polkadot.polkassembly.io/post/263). 

You can verify preimage [here](https://drive.google.com/file/d/1idocvPtKKMQA36lzG4Upxcb4OXGMUeBW/view?usp=sharing).

Gradual increase in the number of validators

**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

- 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 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

- 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

### 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.

Init HRMP open channel request to HydraDX

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 External Proposals