Origin able to dispatch a whitelisted call.

whitelisted_caller

in preparation for the crowdloan unlock on October 24th, as discussed in <a href="https://forum.polkadot.network/t/adjusting-polkadots-ideal-staking-rate-calculation/3897">this forum post</a>, it was concluded to propose slightly increasing the ideal staking rate in Polkadot, such that the network can accommodate the new DOT that is being unlocked into the staking system, without reducing staking rewards.&nbsp;
In short, what this proposal does is:&nbsp;
For the current situation, the ideal staking rate would then be calculated as: 0.75 - min(45,60)/300 = 0.6, i.e., 60%.
You can find the full steps to reproduce the proposal in <a href="https://hackmd.io/ykunWzXYR-Kaz_cM2KNIlg">https://hackmd.io/ykunWzXYR-Kaz_cM2KNIlg</a>. It is merely a 1 liner change to the former Polkadot runtime that was version 9430.&nbsp;
The enactment time is set to <a href="https://polkadot.subscan.io/block/17840000">this</a> block, which is roughly 2 days before the funds unlock from crowdloans.&nbsp;
The corresponding fellowship referendum to whitelist the call is <a href="https://collectives.polkassembly.io/member-referenda/24">https://collectives.polkassembly.io/member-referenda/24</a>.&nbsp;

Deciding

Tweak Polkadot's Ideal Staking Rate

PVF execution currently has a memory limit of 128MB, which is the same as Cumulus uses for its block import pipeline. While collators execute state transitions by reading parachain data from disk locally, parachain validators must load state proofs into memory. Therefore, they should have a higher memory limit than collators. Otherwise, a parachain block that made full use of memory when executed by the collator could fail to be executed by validators. To fix this, we propose increasing the memory limit for PVF execution to 512MB.

Please note that a similar proposal has already been successfully executed in [Kusama](https://kusama.subsquare.io/referenda/233). As this proposal was submitted on the Whitelisted Caller track, Fellowship will be voting on a proposal to whitelist this hash.

```
set_config_with_executor_params {}: set_executor_params(RawOrigin::Root, 
ExecutorParams::from(&[ExecutorParam::MaxMemoryPages(8192)][..]))
```

- Call data: 0x332e040100200000
- Call hash: 0x1c356149b664ec3f7d89eeb56a3469bd5f468ae7fafa2b13f2423618db6c922e

Executed

Increase MaxMemoryPages to 512MB

<a href="56">Referendum 56</a> (voted and approved in Auction Track) scheduled a new set of auctions, after some issues with the existing auctions were found (the execution resulted in the failure of the auction due to BadOrigin) . The new auctions schedule executed by Ref56 is the same as the one decided before by the community: replacing the BadOrigin calls.
Referendum 56 also aimed to cancel the auctions resulting in BadOrigin, to clean the scheduler. However, since the proposal was up for vote and approved in auction admin track and the cancellation of these auctions needed Root origin, the cancellation was not successful. In order to complete Ref56&rsquo;s plan, this proposal aims to clean scheduler from future failed auctions, leaving only the new schedule on scheduler.
<ul>
<li>
Issue on GitHub: <a href="https://github.com/paritytech/polkadot/issues/7541">here</a>
</li>
<li>
Preimage for the public referendum: <a href="https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x0a00250117031a040801039a6e9257349bba17f88788016821455b1e3fffbd0947dcbad6e8a938b5063bac010321fc0d6cfaa46fd7ac946c6152fb989bc2ab9cbee53f389e2be0d8b68dac7765">here</a>
</li>
<li>
Public referendum to dispatch the call: <a href="https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x1500160d02856f80bb4c18888ef355e717322ffbf4004fa80912d880ba1fd40d60835e235949000000010a000000">here</a>
</li>
<li>
Call hash: 0x6a8ce6c3c5cee277c21ae28aa2fcff8067d611bf009f050176a3cd8cee835477
</li>
</ul>
Please note this proposal was submitted on Whitelisted Caller track: the Fellowship is also voting on a proposal to whitelist the hash for this call to execute successfully.
Make sure to vote!

Cancel Old Auctions Schedule - Replaced by New Schedule After OpenGov Inclusion

Enacting this proposal will register the asset { parents: 2, interior: GlobalConsensus(Kusama) } on the Polkadot Asset Hub. KSM will be a sufficient asset with a minimum balance of 0.01 KSM.

The "owner" of the asset is the account ID conversion of the path (expressed as a Multilocation) to the Kusama Relay Chain, i.e. the governance location of Kusama.

This registration by governance is part of the initialization of a Polkadot <> Kusama bridge. Future assets that are sent over the bridge will not need governance motions from the system Root origin. There is a [similar referendum](https://kusama.subsquare.io/referenda/referendum/258) to register DOT on Kusama.

A note about metadata: I discovered while testing that `force_set_metadata` is not included in the `SafeCallFilter`, so it cannot be executed over XCM. This will be fixed in [this PR](https://github.com/paritytech/cumulus/pull/3044). A follow up referendum can set the metadata (name: Kusama, symbol: KSM), however this is not necessary for functionality (and the asset identifier itself is expressive of the asset meaning).

[Whitelisted Caller] Referendum #122: Register KSM on Asset Hub

This referendum updates the parachain validation configuration in two ways:

1. It changes the no-show slots from 2 to 3. This change was already done [on Kusama](https://kusama.subsquare.io/referenda/referendum/232), and after review by Parity's Parachains Core team can be applied to Polkadot.
2. Removes the limit on the maximum number of parachain validators. For Polkadot, this means that all 297 validators will participate in parachain consensus.

Requires [whitelist](https://collectives.subsquare.io/fellowship/referendum/17) from the Fellowship.

[Whitelisted Caller] Referendum #110: Update Parachain Validation Config

Following the success of raising parachain validators to 300 on Kusama, this referendum will increase parachain validators to the more conservative 250 on Polkadot. It also updates the `relay_vrf_modulo_samples`.

Whitelist via https://collectives.subsquare.io/fellowship/referendum/4

[Whitelisted Caller] Referendum #58: Increase Parachain Validators to 250

NOTE: This was originally [#39](https://polkadot.polkassembly.io/referenda/39)

Nomination pool usage is increasing, and nomination pool commission has now rolled out on Polkadot. This referendum changes the following nomination pool settings to account for this:

- `maxPools` from 256 -> 512 (currently at 131 pools)
- `maxMembers` from 16,384 -> 49,152 (currently at >12,000 members)
- `globalMaxCommission` from 0% -> 10%, enabling pool commission on Polkadot.

Further reading:
- Polkadot Forum: https://forum.polkadot.network/t/next-revision-of-increasing-nomination-pool-limits/2498/5
- GitHub tracking issue: https://github.com/paritytech/substrate/issues/14321

[TAKE TWO] Next revision of increasing nomination pool limits & commission

This referendum opens HRMP channels between system parachains, namely three bi-directional channels:

- Asset Hub <> Collectives, e.g. for Fellowship salaries;
- Asset Hub <> Bridge Hub, e.g. for representing bridged assets; and
- Collectives <> Bridge Hub, e.g. for the Fellowship acting on Kusama.

Note that the first transfers to the sovereign accounts of parachains 1,001 (Collectives) and 1,002 (Bridge Hub) are slightly greater than the 20 DOT channel deposit. This is because the accounts do not exist yet and must retain at least 1 DOT (existential deposit) in free balance to succeed.

Depends on the Fellowship passing https://collectives.subsquare.io/fellowship/referendum/2

[Whitelisted Caller] Referendum #51: Open HRMP Channels Between System Parachains

**IMPORTANT: This proposal was not correctly set up for whitelist and will not successfully pass. Reopened at [#55](https://polkadot.polkassembly.io/referenda/55)**

Nomination pool usage is increasing, and nomination pool commission has now rolled out on Polkadot. This referendum changes the following nomination pool settings to account for this:

- `maxPools` from 256 -> 512 (currently at 129 pools)
- `maxPoolMembers` from 16,384 -> 49,152 (currently at >12,000 members)
- `globalMaxCommission` from 0% -> 10%, enabling pool commission on Polkadot.

Further reading:
- Polkadot Forum: https://forum.polkadot.network/t/next-revision-of-increasing-nomination-pool-limits/2498/5
- GitHub tracking issue: https://github.com/paritytech/substrate/issues/14321

TimedOut

Next revision of increasing nomination pool limits & commission

This is a referendum to upgrade the Polkadot network to v9430. Release notes are available for the [Relay Chain](https://github.com/paritytech/polkadot/releases/tag/v0.9.43) and the [System Parachains](https://github.com/paritytech/cumulus/releases/tag/parachains-v9430).

Enactment is scheduled for block [16,450,000](https://polkadot.subscan.io/block/16450000), which should be mid-morning European time on Tuesday, 18 July.

Whitelist proposal: https://collectives.subsquare.io/fellowship/referendum/1

[Whitelisted Caller] Referendum #18 Polkadot v9430

Sibling Fellowship Referendum: https://collectives.subsquare.io/fellowship/referendum/0

As explained in the Fellowship referendum description, the v9420 runtime upgrade did not enact successfully on the Bridge Hub because the Relay Chain's XCM version was too old. This proposal corrects the error from [Gov1 Ref 121](https://polkadot.subsquare.io/democracy/referendum/121) did for the Bridge Hub. All other calls within 121 worked as planned, only the Bridge Hub was affected.

[1] Origin: WhitelistedCaller