Origin able to dispatch a whitelisted call.

whitelisted_caller

### Proposal Summary

- **Objective**: Increase the backing timeout for validators from 2 seconds to 2.5 seconds and the approval-voting timeout from 12 seconds to 15 seconds.
- **Reason**: This change aims to provide a smoother experience for async backing parachains by allowing them to fully utilize the 2 seconds of execution time per block.
- **Rationale**: Detailed in [GitHub issue #3565](https://github.com/paritytech/polkadot-sdk/issues/3565).
- **Implementation**: The changes are implemented in the call found [here](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc-kusama.luckyfriday.io#/extrinsics/decode/0x332e0c01002000000600c4090000000000000601983a000000000000).
- **Additional Change**: The `MaxMemoryPage` parameter is reset to its previous value as the call overrides all parameters of `ExecutorParams`.
- **Testing**: The proposal has been tested locally using zombienet and on the Rococo network.

Executed

WHO: The proposal is made by an anonymous entity.

WHAT: The proposal aims to increase the backing timeout on validators from 2s to 2.5s and approval-voting timeout from 12s to 15s.

PRICE/TIMEFRAME/RESOURCES: Not specified.

Bump parachain validation timeouts

[Revision] Nomination Pool: Remove max pool and max member limits

Set BEEFY genesis (thus starting BEEFY consensus on Polkadot)

### Summary of Proposal

- The proposal sets a minimum fee of 0.025 DOT for each block order in the on-demand system.
- The goal is to prevent spam while allowing for cost-effective experimentation.
- If the fee is too high after the system starts, another proposal can be made to lower it.
- The proposal is part of the Whitelisted Caller track.
- The Fellowship is also voting on Referendum 89 to whitelist the hash.

WHO: The proposal is submitted on the Whitelisted Caller track.

WHAT: Establishes the minimum fee for a single block order via the on-demand system at 0.025 DOT.

PRICE/TIMEFRAME/RESOURCES: Not mentioned.

Setting onDemandBaseFee to 0.025 DOT

The P<>K bridge is a system that connects different blockchains and charges user fees. It pays rewards to people who help it work, called "relayer rewards." These rewards are a big part of the bridge's costs. To start, the bridge needs some money to begin working. They suggest giving 10100 DOT and 2030 KSM to the bridge's accounts. This money will help the bridge get started. As the bridge works, it will make enough money from user fees to pay for the rewards. Any extra money will go back to the treasury. You can find more details about the bridge's accounts and money here: https://github.com/polkadot-fellows/runtimes/issues/238. The bridge has already been approved by a group called https://collectives.subsquare.io/fellowship/referenda/88.

The P<>K bridge charges user fees on originating Asset Hub, but it pays relayer rewards from AssetHubs' sovereign accounts on sibling BridgeHub parachains. These relayer rewards are a large part of the bridge's "operating costs". For initial deployment, AssetHub's sovereign accounts on BridgeHubs should be pre-funded by treasury. An initial 10100 DOT and 2030 KSM is proposed to be split among the relevant system chain sovereign accounts to provide initial bootstrap runway to the bridge. This will only be an initial seed. As the bridge operates, it should cover operation costs (relayer fees) from the user fees paid on Asset Hub, and any unspent user fees ("bridge profits") are going to the treasury anyway, so in the longer term these funds are practically paid back (plus profits). Exact system chain addresses being funded and amounts for each can be found here: https://github.com/polkadot-fellows/runtimes/issues/238 Already whitelisted by https://collectives.subsquare.io/fellowship/referenda/88

WHO: P<>K Bridge

WHAT: Proposes an initial funding of 10100 DOT and 2030 KSM to be split among system chain sovereign accounts for initial deployment. 

PRICE/TIMEFRAME/RESOURCES: The funding will be pre-funded by the treasury and will only be an initial seed. The bridge will cover operation costs from user fees paid on Asset Hub.

Fund system chains sovereign accounts on Polkadot BridgeHub for Polkadot<>Kusama bridge

Polkadot Runtime Upgrade v1.1.3

TimedOut

Duplicate of #545 - please ignore

- The call helps connect Polkadot and Kusama through a bridge.
- It sets the rules for communication between different parts of Polkadot and Kusama using XCMv3.
- It connects Polkadot AH to Polkadot BH and both to Kusama.
- It starts the Kusama light-client on Polkadot Bridge Hub.
- It follows a list of approved actions from a website.

WHO: Polkadot

WHAT: Initialize the Polkadot side of the Polkadot<>Kusama bridge by calling `forceXcmVersion` on system parachains and `bridgePolkadotGrandpa::initialize()`

PRICE/TIMEFRAME/RESOURCES: Not specified.

Initialize Kusama GRANDPA light-client running on Polkadot BridgeHub

WHO: Polkadot System Parachains. 
WHAT: Updating the `safeXcmVersion` to value 3 to support new V3 destinations/connections by default. 
PRICE/TIMEFRAME/RESOURCES: Not specified. 
Note: Requires whitelisting by Polkadot community.

Set `safeXcmVersion` to 3 for AssetHub, Collectives and BridgeHub

- The approach on Polkadot is like Kusama.
- They are changing a setting called `setOnDemandMaxQueueSize` to 500.
- This change is based on observations from a test called Rococo.
- During tests, handling too many orders at once slowed down the system.
- Limiting the number of orders is a temporary fix.
- They plan to look for a better solution later.

WHO: The proposal does not mention a specific organization or individual.
WHAT: Adjusting the `setOnDemandMaxQueueSize` to 500 on Polkadot to limit the total number of orders.
PRICE/TIMEFRAME/RESOURCES: No specific information provided.

Setting setOnDemandQueueMaxSize to 500

Polkadot recently updated to version 0.8.28. In this update, there was a change in the "apply" function. The second part of the function, called "CandidacyBond," was supposed to be 100 DOT, but it was changed to 1 DOT by mistake. This caused some accounts to only have 1 DOT unreserved instead of 100 DOT. To fix this, a proposal was made to use "Balances::force_unreserve" to correct the amounts for the two affected accounts. More information can be found in the linked issue.

Paraphrasing Basti from [this comment](https://github.com/paritytech/polkadot-sdk/issues/2507#issuecomment-1828227653):

> The runtime upgrade to Polkadot `0.8.28` had the following migration: [https://github.com/paritytech/polkadot/blob/371681c298eb96b74ad04a09ca8097f19c777e68/runtime/polkadot/src/lib.rs#L968](https://github.com/paritytech/polkadot/blob/371681c298eb96b74ad04a09ca8097f19c777e68/runtime/polkadot/src/lib.rs#L968)
> 
> The second parameter to the `apply` function was the old `CandidacyBond`. It was passed as `1 DOT` while it was actually in the release before: [`100 DOT`](https://github.com/paritytech/polkadot/blob/2f84569930a4ae86a3ecd60fff3488753ab79aa6/runtime/polkadot/src/lib.rs#L489).
> 
> The result is now that some accounts only got 1 DOT unreserved, while it should have been 100 DOT.

This referenda calls `Balances::force_unreserve` for the two accounts which had incorrect amounts unreserved.

See [this issue](https://github.com/paritytech/polkadot-sdk/issues/2507) for more information.

WHO: Polkadot network

WHAT: Call a referenda to force unreserve incorrect amounts of DOT for two accounts

PRICE/TIMEFRAME/RESOURCES: Not specified.

Compensate for insufficient `phragmenElection.renounce` unreserve amount

Upgrade System to v1.1.2

- A problem was found in the Kusama system with version 1.1.0, so it's suggested to cancel a vote related to it.
- A new update for Polkadot Asset Hub with version 1.1.1 is being proposed to fix this issue.
- The new version will lower the minimum amount of DOT needed to 0.01.
- It includes changes from another referendum that needs to be rejected.
- The vote for the new upgrade will happen 24 hours after the 1.1.0 upgrade on February 13.
- There is a decision period of 28 days to make the vote.
- The new balances will take effect shortly after the Asset Hub upgrade.
- Timely submissions are important, but there shouldn't be any major issues.

Cancelled

WHO: Polkadot Asset Hub

WHAT: Update to patch release v1.1.1, reducing existential deposit to 0.01 DOT and updating minimum balances of sufficient assets to maintain their ratio with the DOT existential deposit.

PRICE/TIMEFRAME/RESOURCES: N/A (not specified)

Update Polkadot Asset Hub v1,001,001 and Sufficient Asset Minimum Balances

As a result of the removal of the \`SudoBalances\` proxy type from the runtime, a proxy was rendered undecodable before it was able to be migrated. This proposal cleans up the related storage entry, with more information about this issue avaliable [here](https://github.com/polkadot-fellows/runtimes/issues/145).

A seperate referendum is already up for voting by the Fellowship to [whitelist this proposal's hash](https://collectives.subsquare.io/fellowship/referenda/68).

WHO: Not specified
WHAT: Clean up related storage entry due to removal of `SudoBalances` proxy type from the runtime
PRICE/TIMEFRAME/RESOURCES: Not specified

Clean up undecodable storage entry

- A proposal is suggested to change the deposit amount needed for using digital assets called Asset Hubs.
- It is recommended to reject this proposal and create a new one with improvements.
- The plan involves reducing the minimum balance required for certain assets like USDT and USDC by ten times.
- If the DOT deposit decreases, it will cause fees to be higher for those assets.
- There is also a plan to fix an issue with KSM assets that didn't work correctly before.

The proposal suggests reducing the minimum balance requirement for USDT, USDC, and KSM by a factor of 10 to reduce the existential deposit on Asset Hubs. This will increase fees in sufficient assets by a factor of 10. The proposal also includes updating metadata for bridged KSM.

Update Sufficient Asset Minimum Balances

- There is a referendum to upgrade Polkadot to a new version called Fellowship v1.1.0.
- A problem was found with this new version on Kusama, which could cause issues.
- Because of this problem, it is suggested to cancel the referendum.
- They want to wait for a fix before proceeding.
- The upgrade was supposed to happen on February 12 in the morning.
- A new version with a fix needs to be released first.

Proposal: Upgrade Polkadot to Fellowship v1.1.0 release. Enact in block 19452000. Price/timeframe/resources not specified. However, the proposal has been recommended to be cancelled/rejected due to an issue discovered on Kusama with the v1.1.0 release.

Upgrade Polkadot v1,001,000

### Summary of Proposal

- **Issue**: XCM `SetTopic` instruction conflicts with default version 2 destinations, causing failed transactions.
- **Resolution on Kusama**: [Referendum 305](https://kusama.subsquare.io/referenda/305) fixed this issue on Kusama.
- **Proposal for Polkadot**: Suggest aligning `safeXcmVersion` to v3 on Polkadot's relay chain.
- **Purpose**: Ensures the relay chain sends XCMs in v3 format by default, resolving version mismatches.
- **Impact**: Prevents issues between the relay chain and parachains due to XCM version conflicts.
- **Submission Track**: Proposal submitted on the Whitelisted Caller track.
- **Fellowship Vote**: Fellowship is voting on a related proposal ([56](https://collectives.subsquare.io/fellowship/referenda/56)) to whitelist the submission hash.

WHO: The proposal advocates for a change in Polkadot's relay chain. 

WHAT: The proposal suggests setting the relay chain's safeXcmVersion to v3 to ensure it sends XCMs in the v3 format by default. 

PRICE/TIMEFRAME/RESOURCES: Not specified.

Setting the relay chain's safeXcmVersion to v3

[Whitelisted Caller] Referendum #268: Polkadot v1,000,0001

**WHO:** OnFinality

**WHAT:** Requesting KSM 2,534.3895 (USD $62,110.28) for ongoing costs to run high performance, scalable, and reliable public infrastructure for Kusama and Statemine.

**TIMEFRAME:** Q2 2023

**RESOURCES:** See full proposal for breakdown of costings and more information.

[Whitelisted Caller] Referendum #211: Upgrade Polkadot v1,000,000

Polkadot is preparing for a crowdloan unlock on October 24th. To accommodate the new DOT being unlocked into the staking system without reducing staking rewards, it has been proposed to slightly increase the ideal staking rate. The new ideal staking rate would be 60%. The change is a small adjustment to the previous Polkadot runtime version 9430. The enactment time is set for two days before the funds unlock from crowdloans. There is a fellowship referendum to whitelist the call.

in preparation for the crowdloan unlock on October 24th, as discussed in [this forum post](https://forum.polkadot.network/t/adjusting-polkadots-ideal-staking-rate-calculation/3897), 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. 

In short, what this proposal does is: 

_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 [https://hackmd.io/ykunWzXYR-Kaz\_cM2KNIlg](https://hackmd.io/ykunWzXYR-Kaz_cM2KNIlg). It is merely a 1 liner change to the former Polkadot runtime that was version 9430. 

The enactment time is set to [this](https://polkadot.subscan.io/block/17840000) block, which is roughly 2 days before the funds unlock from crowdloans. 

The corresponding fellowship referendum to whitelist the call is [https://collectives.polkassembly.io/member-referenda/24](https://collectives.polkassembly.io/member-referenda/24).

Polkadot proposes to increase the ideal staking rate to 60% to accommodate the new DOT being unlocked into the staking system. The enactment time is set to two days before the funds unlock from crowdloans. The proposal is a 1 liner change to the former Polkadot runtime.

Tweak Polkadot's Ideal Staking Rate

### Summary of PVF Execution Memory Limit Proposal

- **Current Limit**: PVF execution has a memory limit of 128MB, same as Cumulus.
- **Issue**: Parachain validators need more memory than collators to load state proofs.
- **Proposed Solution**: Increase the memory limit to 512MB.
- **Previous Success**: A similar proposal was successfully executed on Kusama.
- **Fellowship Vote**: Fellowship will vote to whitelist this proposal.
- **Call Data**: 0x332e040100200000
- **Call Hash**: 0x1c356149b664ec3f7d89eeb56a3469bd5f468ae7fafa2b13f2423618db6c922e

WHO: The proposal does not mention a specific organization or individual.
WHAT: Increase the memory limit for PVF execution to 512MB.
PRICE/TIMEFRAME/RESOURCES: Not specified.

Increase MaxMemoryPages to 512MB

Referendum 56 was a vote to fix issues with auctions in Auction Track. The goal was to replace the BadOrigin calls and cancel auctions that failed due to BadOrigin. However, the cancellation was not successful because it needed Root origin. This new proposal aims to clean the scheduler from future failed auctions, leaving only the new schedule. The proposal was submitted on the Whitelisted Caller track, and the Fellowship is voting to whitelist the hash for this call to execute successfully.

[Referendum 56](56) (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’s plan, this proposal **aims to clean scheduler from future failed auctions, leaving only the new schedule on scheduler**.

-   Issue on GitHub: [here](https://github.com/paritytech/polkadot/issues/7541)
    
-   Preimage for the public referendum: [here](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x0a00250117031a040801039a6e9257349bba17f88788016821455b1e3fffbd0947dcbad6e8a938b5063bac010321fc0d6cfaa46fd7ac946c6152fb989bc2ab9cbee53f389e2be0d8b68dac7765)
    
-   Public referendum to dispatch the call: [here](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x1500160d02856f80bb4c18888ef355e717322ffbf4004fa80912d880ba1fd40d60835e235949000000010a000000)
    
-   Call hash: 0x6a8ce6c3c5cee277c21ae28aa2fcff8067d611bf009f050176a3cd8cee835477
    

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!

Referendum 56 aimed to cancel failed auctions due to BadOrigin, but it required Root origin which was not successful. This proposal aims to clean the scheduler from future failed auctions, leaving only the new schedule on the scheduler. No price/timeframe/resources mentioned.

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

- This proposal registers an asset on the Polkadot Asset Hub, linking it to Kusama.
- The asset requires a minimum balance of 0.01 KSM.
- The "owner" is set to the governance location of Kusama.
- This registration is part of setting up a bridge between Polkadot and Kusama.
- Future asset transfers won't need governance approval.
- There's a similar proposal to register DOT on Kusama.
- Metadata issues were discovered but will be fixed in a future update.

WHO: Governance of Kusama
WHAT: Register the asset { parents: 2, interior: GlobalConsensus(Kusama) } on the Polkadot Asset Hub as part of the initialization of a Polkadot <> Kusama bridge.
PRICE/TIMEFRAME/RESOURCES: Minimum balance of 0.01 KSM. No further information provided.

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

### Referendum Summary

- Changes no-show slots from 2 to 3.
- This change was already implemented on Kusama.
- Removes the limit on the number of parachain validators.
- All 297 validators will now participate in parachain consensus.
- Requires approval from the Fellowship.

WHO: Polkadot community

WHAT: Update the parachain validation configuration by changing the no-show slots from 2 to 3 and removing the limit on the maximum number of parachain validators.

PRICE/TIMEFRAME/RESOURCES: Not specified. Requires whitelist from the Fellowship.

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

root

wish_for_change

staking_admin

treasurer

lease_admin

fellowship_admin

general_admin

auction_admin

referendum_canceller

referendum_killer

small_tipper

big_tipper

small_spender

medium_spender

big_spender

Referenda Whitelisted Caller

Origin for signaling that the network wishes for some change

Origin able to cancel slashes and manage minimum commission.

Origin for spending up to 10,000,000 DOT from the treasury as well as generally administering it.

Origin for managing the composition of the fellowship.

Origin able to spend around 250 DOT from the treasury at once.

Origin able to spend around 1,000 DOT from the treasury at once.

Origin able to spend around 10,000 DOT from the treasury at once.

Origin able to spend around 100,000 DOT from the treasury at once.

Origin able to spend up to 1,000,000 DOT from the treasury at once.

[1] Origin: WhitelistedCaller