candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

root

We're writing to inform you about the decision to deregister Parachain ID 2118 from the Kusama network. Para ID 2118 is currently locked, we've decided to deregister it from the Kusama network.

Preparing

Deregister 2118

TimedOut

![image](https://i.ibb.co/7rnjqZp/12694-44ee48ef6d9f4d589b1866b93-1697934927514.png)

Read the full proposal here - you'll need a Substrate address to comment and critique. 

https://rfc.decent.partners/t/burn-the-kusama-treasury-by-setting-balance-to-0/43



Burn the Kusama treasury and turn the canary into the phoenix.

[Root] Referendum #279: NIS Target

Acala Foundation have registered para id 2233 and won a parachain slot auction by bidding with the intention to use the new lease to renew Karura para lease.

However, due to historical reasons and missing migrations, para id 2233 is locked and in a bad state that can only be managed by root track.

In order to fix the bad state and improve the parachain lock mechanism to ensure this cannot happen in future, I have proposed [RFC-14](https://github.com/polkadot-fellows/RFCs/pull/14). A draft implementation is also implemented: https://github.com/paritytech/polkadot/pull/7560.

But Polkadot Fellowship is still on the process of taking over the ownership of Polkadot runtime, which slows everything down. We do not know if the RFC-14 can be accepted, implemented, and enacted before lease 32 ends.

As a result, I would like to perform a lease swap between Karura (Para ID 2000) and Para ID 2233 with root track. 

Once RFC-14 is enacted, we would be able to self-service the lease swap in future and other parachain teams will be less likely require root track governance intervene for least swap or state update.

- Acala Foundation won an auction to renew a lease for Karura para lease.
- Para ID 2233 is locked and needs to be fixed before the lease can be renewed.
- A proposal called RFC-14 has been made to fix the issue and improve the parachain lock mechanism.
- The Polkadot Fellowship is still taking ownership of Polkadot runtime, which may slow down the process.
- A lease swap between Karura and Para ID 2233 is being considered to address the issue.

Executed

Perform lease swap for Karura

Greetings everyone!

After discussing these changes with many people in the ecosystem, I have finally prepared a referendum that will reconfigure Kusama's runtime accordingly. This referendum will change the following parameters in the spending tracks:

| Track | Spend Limit| Max Deciding | Min Approval | Preparation Period | Confirmation Period | Decision Period |
|-------|--------------|----------------|-----------------|---------------------|------------------------|------------------|
|Small Tipper|No Change|200 -> 6|No Change|1 mins -> 3 hrs|No Change|No Change|
|Big Tipper|No Change|100 -> 3|No Change|10 mins -> 6 hrs|No Change|No Change|
|Small Spender|333 KSM -> 100 KSM|50 -> 7|No Change|4 hrs -> 24 hrs|No Change|No Change|
|Medium Spender|3,333 KSM -> 1,250 KSM|50 -> 2|No Change|4 hrs -> 24 hrs|No Change|No Change|
|Big Spender|33,333 KSM -> 2,500 KSM|50 -> 1|50% -> 66%|4 hrs -> 24 hrs|48 hrs -> 24 hrs|No Change|
|Treasurer|No Change|No Change|50% -> 66%|2 hrs -> 48 hrs|3 hrs -> 48 hrs|14 days -> 28 days|

For now, the preimage is unnoted. However you can verify the hash by using srtool v0.11.0. The call is:

```
utility.withWeight(
  system.setCode(
    <adam-spending-reconfig wasm blob>
    ),
  1000000000000,
  10000000
)
```

You can find the summary of changes [**on Github here**](https://github.com/paritytech/polkadot/compare/release-v0.9.43...adamsteeber:polkadot:adam-spending-reconfig).

Treasury reconfiguration discussions [**here**](https://forum.polkadot.network/t/kusama-treasury-analysis-reconfiguration/2484) and [**here**](https://forum.polkadot.network/t/kusama-treasury-follow-up-analysis-continued-budgeting-incompetence/3143).

I made a video going through the whole process of this referendum but [**it got removed from Youtube**](https://www.youtube.com/watch?v=HlxjSstvsmM) due to copyright strikes on the music in the background. [**I uploaded it to Twitter**](https://twitter.com/AdamSteeber1/status/1679661676486852610) though so hopefully it will stay up there.

srtool output:

```
✨ Your Substrate WASM Runtime is ready! ✨
Summary generated with srtool v0.11.0 using the docker image paritytech/srtool:1.70.0:
 Package     : kusama-runtime v0.9.43
 GIT commit  : 700acb8e1fc20d53c71f7fdfea44dbe09d171c59
 GIT tag     : v0.9.43
 GIT branch  : adam-spending-reconfig
 Rustc       : rustc 1.70.0 (90c541806 2023-05-31)
 Time        : 2023-07-12T03:09:55Z

== Compact
 Version          : kusama-9431 (parity-kusama-0.tx23.au2)
 Metadata         : V14
 Size             : 6.76 MB (7087543 bytes)
 setCode          : 0xb33c31bd19d662efa286825b762e12f4b5c5f3efe52adb9364f0536b85c23411
 authorizeUpgrade : 0x39d7596c5ff88184df84e1c8b97c990c770d3b504e1a14184f7cc1a7dc11554f
 IPFS             : QmTM2YunEtFS16M7U82tBVDXZoSqj6Ygj4BFvPoEzbD9Nq
 BLAKE2_256       : 0x6931efb33b54eb6415b0bc5872623049eb5c5d130dc8fff31597c2c4791b81a7
 Wasm             : runtime/kusama/target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.wasm

== Compressed
 Version          : kusama-9431 (parity-kusama-0.tx23.au2)
 Metadata         : V14
 Size             : 1.41 MB (1482916 bytes)
 Compression      : 79.08%
 setCode          : 0x47c4c4406c953aa037361422b6633ad3238f324b065999e55f50ea30fc11f08d
 authorizeUpgrade : 0x5643d874b0e71ad9a5dd2341e29e06e28ca2b19db770298785adc1db527f7afc
 IPFS             : QmNt3L38axQ9q4ibhx3FaNKLF4CwX7WkWpPU6CAycbVtGw
 BLAKE2_256       : 0x6320cbe21cd6ddf5fdc371a6d2da568d4b179dc5648eb2559e2e801370375b99
 Wasm             : runtime/kusama/target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.compressed.wasm
```

Respectfully,

Adam

For a second-grade student:

- Adam has made a plan to change how Kusama's spending works.
- He has made a list of changes for different types of spenders.
- He has created a way to check if the plan is real using a tool called srtool.
- Adam made a video explaining the plan, but it was removed from Youtube.
- You can find more information about the plan on Github and a forum called Polkadot.

Rejected

Spending Tracks Reconfiguration - runtime v9431

Submitted to Wrong track, my apologies, Please ignore

Submitted to Wrong track, our apologies, Please ignore

EDIT - *No-one has objected, so I'm going to go ahead with this.*

EDIT AGAIN - Passed and executed correctly.  Thank you to everyone who supported it!

I'm interested in the communities views on whether the following is technically feasible and whether they would likely support it, please.

We're coming to the end of the Kabocha parachain lease (paraid 2113), and we've secured another lease on another paraid (2268).  Unfortunately, I hadn't realised that the parathread would instantly upgrade to a parachain and lock lease swaps, so we're going to need to use a root referendum to resolve it.

However, there are a few other longer term issue that we'd like to resolve at the same time, if possible.  The current paraid is on a regular single owner account.  We'd like to move it to another account - probably a pure proxy so we can update control of the account as key people move in and out of the project.  I believe there isn't currently a way to update the manager of a paraid?

With that in mind, and noting that Kabocha will revert to a parathread in a few days, I'd like to set up a root track referendum that does the following in a batch (in order):

1. registrar.deregister(2113) - release the paraid from the current holder and free the reserved balance.

<wait 2 epoch for offboarding>

2. registrar.forceRegister() - with the pure proxy account, standard 280.3KSM deposit (see below), paraid 2113, and the head hash and validation_code at the point where Kabocha stops making blocks (not yet known).

<wait 2 epoch for onboarding - might not be strictly necessary>

3. registrar.swap(2113,2268)
4. registrar.swap(2268,2113)

My assumption is that this will move the paraid to the new account, offboard 2268 and onboard 2113 as parachains, and Kabocha should start making blocks again.  Is there anything fundamentally wrong with this assumption?  Or, indeed, is it too complex for the community to allow, perhaps?

Validation wise, we can set remarks from the accounts involved (the current manager accounts for the two paraids and the new pure proxy), to confirm intent.  Is this sufficient?

[About Kabocha, for anyone not familiar](https://forum.polkadot.network/t/introducing-kabocha-an-experimental-kusama-parachain-incubated-by-the-edgeware-community/327)


EDIT to add **validation on-chain remarks**

[Paraid 2268 manager account](https://kusama.subscan.io/extrinsic/18149800-2)

[New paraid 2113 manager account, via proxy](https://kusama.subscan.io/extrinsic/18149835-2)

[Old paraid 2113 manager account](https://kusama.subscan.io/extrinsic/18154737-2)


EDIT to add **notes on deposit for forceRegister()**

The fee for setting the parachain PVF and head is just under 280.3KSM (this is more than the fee when Kabocha was first registered).  I will use the current fee in the forceRegister() extrinsic.

![image](https://i.ibb.co/RpQRz5S/4031-jelliedowl-1685570490210.png)

EDIT: In case it's useful for anyone in future - this is the preimage I used:
![image](https://i.ibb.co/jLtPpdB/4031-jelliedowl-1687038852464.png)

1. A lease for a Kabocha parachain is ending and they have secured another lease on another paraid.
2. The parathread will instantly upgrade to a parachain and lock lease swaps, so they need to use a root referendum to resolve it.
3. They want to move the current paraid to another account, probably a pure proxy, so they can update control of the account as key people move in and out of the project.
4. They plan to set up a root track referendum that will release the paraid from the current holder, move it to the new account, offboard 2268 and onboard 2113 as parachains, and Kabocha should start making blocks again.
5. They will set remarks from the accounts involved to confirm intent and use the current fee in the forceRegister() extrinsic.

Moving a paraid to a new manager address - Kabocha

Ignore this proposal please, was submitted in wrong track.

Ignore

## Background
[Bifrost](https://kusama.subscan.io/parachain/2001) is a Kusama parachain that recently completed a lease renewal. We registered two paraids to bid for the lease renewal and then swapped to Bifrost paraid 2001 once the bidding was successful. 

## Request
We now have two parachains that require community assistance to execute the `remove_lock` function in order to withdraw the previous 700 KSM locking.

The address we used to register `paraid 2259` & `paraid 2262`: **J3dfxSNbUHwBbmB4My7DCgrNniQ227uTUNqqf4KB1DhyZkR**

Transactions:
- 2259 registration: [https://kusama.subscan.io/extrinsic/0x90433dd2c428e38104709393a35d41e051c353fb175eeb93d2240fa1aef7f13c](https://kusama.subscan.io/extrinsic/0x90433dd2c428e38104709393a35d41e051c353fb175eeb93d2240fa1aef7f13c)

- 2262 registration: [https://kusama.subscan.io/extrinsic/0x0e2ad064d107abe9dca42f6be2f37ec27fa2b2858d847c62af8b87af38ad3975](https://kusama.subscan.io/extrinsic/0x0e2ad064d107abe9dca42f6be2f37ec27fa2b2858d847c62af8b87af38ad3975)

The signature below is used to prove the registration address (J3dfxSNbUHwBbmB4My7DCgrNniQ227uTUNqqf4KB1DhyZkR) is ours:

Content:
`Paraid 2259 & 2262 belong to Bifrost, and Bifrost Kusama slot renewal is successful, we are submitting referendum to unlock paraid 2259 & 2262`

Signature:
`0xa0e872b0d115e75cf82787693f5b4cce913c1c6666abb4cd5d4a279489d0ae795fc905d36b6d3af11cb65b1ecf66a8294726c52805f374e7ae4fb1ffa30b698e`

- Bifrost is a Kusama parachain that renewed its lease recently.
- Two parachains, `paraid 2259` and `paraid 2262`, require community assistance to withdraw 700 KSM locking.
- The registration address used for both parachains is `J3dfxSNbUHwBbmB4My7DCgrNniQ227uTUNqqf4KB1DhyZkR`.
- A referendum is being submitted to unlock both parachains.
- The signature `0xa0e872b0d115e75cf82787693f5b4cce913c1c6666abb4cd5d4a279489d0ae795fc905d36b6d3af11cb65b1ecf66a8294726c52805f374e7ae4fb1ffa30b698e` is used to prove the registration address is theirs.

Remove lock for Bifrost swapped parachain id (2259 & 2262)

- Bifrost is a Kusama parachain that recently renewed its lease.
- Two parachains, paraid 2259 and paraid 2262, require community assistance to withdraw 700 KSM locking.
- The address used to register paraid 2259 and paraid 2262 is J3dfxSNbUHwBbmB4My7DCgrNniQ227uTUNqqf4KB1DhyZkR.
- A signature is provided to prove that the registration address belongs to the author.
- A referendum is being submitted to unlock paraid 2259 and paraid 2262.

MISTAKE - Wrong track, my apologies

Kusama Treasury Staking Configuration

Using a `batch` call, this Referendum aims to cancel proposals that have been approved by the community but have failed to enact on time due to UI misconfiguration.

Namely, as we started to navigate OpenGov, it was brought to our attention that a misinterpretation of the parameter `after`, which is NOT an absolute block number but a delay expressed in blocks, implied that after approval, these referenda would take years to enact.

Among others, Referenda: [4](https://kusama.subsquare.io/referenda/referendum/4), [5](https://kusama.subsquare.io/referenda/referendum/5), [6](https://kusama.subsquare.io/referenda/referendum/6), [7](https://kusama.subsquare.io/referenda/referendum/7), [9](https://kusama.subsquare.io/referenda/referendum/9), [10](https://kusama.subsquare.io/referenda/referendum/10), [11](https://kusama.subsquare.io/referenda/referendum/11), currently sitting in the scheduler, are expected to be approved from 1025-1100 days from now.

However, as the teams have already resubmitted their proposals with the updated parameters (see [referenda history](https://kusama.subsquare.io/referenda) of various tracks), I am bringing forward the following call to cancel the proposals and avoid any complications in the future.

- There is a Referendum that wants to cancel proposals that were approved by the community but didn't happen on time because of a mistake.
- The mistake was that they thought a certain number of blocks meant a certain amount of time, but it didn't.
- There are many proposals that are affected, and they won't happen for a long time if they don't cancel them.
- The teams have fixed the mistake and resubmitted their proposals.
- They want to cancel the old proposals to avoid problems in the future.

Cancellation of the proposals that are wrongly scheduled

Kusama auctions are scheduled using the Scheduler Pallet and its recurring feature. This pallet offers two options: the frequency of execution (in blocks) and the number of times it should be executed. Unfortunately, as the scheduled auctions queued on Scheduler by [Referendum 72](https://kusama.subsquare.io/referenda/referendum/72) and [Referendum 81](https://kusama.subsquare.io/referenda/referendum/81) have been misconfigured and subsequently cancelled, it has become necessary to propose this Referendum with the right parameters to ensure that all auctions are properly scheduled throughout the year and the Kusama community can continue including new parachains and allowing those already up and running to renew their slots in 2023.

Please note that from the original schedule, originally approved by the community, two auctions have been submitted via the Auction admin track

- [ https://kusama.polkassembly.io/referenda/91](https://kusama.polkassembly.io/referenda/91)
- [https://kusama.polkassembly.io/referenda/96](https://kusama.polkassembly.io/referenda/96)

And a third one will also be submitted via the same track. After this one, if approved, the 2023 schedule will continue as stated [here](https://docs.google.com/spreadsheets/d/1KyNq6IGrzrfx0ZiMuRY0gMZSqv6la1fNjWF3rOD1zkU/edit?usp=sharing).

The preimage submission can be seen [here](https://kusama.subscan.io/extrinsic/16647098-2).

The image can be found [here](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x1804201d0281edbd9bec51fc9d78be1dc45e65c7c97ff25d8fb0df5e190e559181831249fb4c6e010101508b010004000000004800e2a50100701d022e1895be3594bbbd39f330a843f221425b680653652b26fc1320533d8eecbf7b00ac0701018051010007000000004800f1d2741d023f695d577cd80ceab19696358d0965bd903a4a4622380a564dc6b9783b756a0e80e61001018051010007000000004800f1d2781d02f8a869528ddc7c0d40aeceda15497713ebb931c931424043f9a4df89af4a1ac900211a01018051010007000000004800f1d27c1d020b80ba0c51368b431d999fc5bab0cea73c5f8cb2520e4eb41c7c309b68d2cdf5805b2301018051010007000000004800f1d2801d02630ed60985a63f89b71e168f8cbcec645b27e37f1840f4e81d96c7fa248e63ee00962c01018051010007000000004800f1d2841d027e65636788051a7e026b57a4fa11c8854e181e5dcfd688dbe25bb449b0555c2680d03501018051010007000000004800f1d2881d022e7dae2f2fd127478f7d20a0da689b7f8abbb0b5f2f2a65ed18d31c9815f8404000b3f01018051010007000000004800f1d28c)

Please make sure to review and cast your votes!

- Kusama auctions are scheduled using a feature called Scheduler Pallet.
- Two scheduled auctions were cancelled due to misconfiguration, so a new Referendum has been proposed with the right parameters to ensure all auctions are properly scheduled throughout the year.
- Three auctions have been submitted via the Auction admin track, and if approved, the 2023 schedule will continue as planned.
- The preimage submission and image can be found on specific links.
- People are encouraged to review and cast their votes on the Referendum.

Kusama Auctions for 2023

Auctions on Kusama are scheduled using the Scheduler Pallet. [Referendum 72](https://kusama.polkassembly.io/referenda/72) was proposed on Kusama through root Track given that the Scheduler Pallet can’t be called by the Auctions Admin (this PR will change that). Due to voting turnout, Referendum 72 will not be executed before the first scheduled call, set to happen at block height #16_367_188. This means that the first batch of auctions for LP27 will not be executed, as the scheduler pallet does not allow the execution of an action in a past block (the other batches will be scheduled).

In order to alleviate the demand of auctions (teams that need to renovate their slot during LP27 to keep uptime of their parachains will not be able to do so, therefore having to interrupt their service to the community) we have proposed the following two referenda, up for vote now and scheduling 3 auctions from next week:

This referendum aims to schedule the following 2 auctions (after [the 1st one scheduled by [this proposal](https://kusama.polkassembly.io/referenda/80)) using the scheduler pallet via **Root Caller**. The new Scheduler call will need to execute before block #16_568_788. If submitted today (27/Jan), then it should work for every case scenario, based on the current support percentages. 

Call

- Scheduler: Root Admin

- Auction Parameters: `auctions.newAuction(duration: 14400, leasePeriodIndex: 27)`

- Encoded call Data: [0x1804041d0251a37492c47ff0c069dad8080818b5303493eb91feb718cc4cee7e3ebe39978ed4d1fc000102000000c089010000480001e16c](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x1804041d0251a37492c47ff0c069dad8080818b5303493eb91feb718cc4cee7e3ebe39978ed4d1fc000102000000c089010000480001e16c)

- Kusama is a platform where auctions are held using the Scheduler Pallet.
- Referendum 72 was proposed but it won't be executed before the first scheduled call.
- The first batch of auctions for LP27 won't be executed due to the Scheduler Pallet not allowing the execution of an action in a past block.
- To help with the demand of auctions, two referenda have been proposed and are up for vote now.
- The referenda aim to schedule 3 auctions from next week using the Scheduler Pallet via Root Caller.

Cancelled

2 Auctions using scheduled after (Root): scheduling 2 more auction to replace the three missed auctions meant to be scheduled by referendum 72

At Fellowship request, we have submitted the new batch of auctions for 2023, from LP27 to LP35, this time on root track. The Fellowship members are working on [a PR](https://github.com/paritytech/polkadot/pull/6573/files) to include the use of Scheduler in Auctions Admin track: for now, root track is the only track that will execute this call successfully. 

Contextual information below: 

After the successful enactment of [motion 438](https://kusama.polkassembly.io/motion/438), scheduling 32 auctions in 2022 from LP21 to LP26, the Kusama community aims to continue including new parachains and allowing those already up and running to renew their slots in 2023. This proposals aims to schedule a new batch of auctions: 

- from LP27 to LP35
- For a total of 57 auctions until January 2024
- For LP27: 3 auctions on LP26
- For LP28: 5 auctions on LP27 and 28
- For LP29: 7 auctions on LP28 and 29
- For LP30: 7 auctions on LP29 and 30
- For LP31: 7 auctions on LP30 and 31
- For LP32: 7 auctions on LP31 and 32
- For LP33: 7 auctions on LP32 and 33
- For LP34: 7 auctions on LP33 and 34
- For LP35: 7 auctions on LP34 and 35

The complete schedule for this year can be found [HERE](https://docs.google.com/spreadsheets/d/1KyNq6IGrzrfx0ZiMuRY0gMZSqv6la1fNjWF3rOD1zkU/edit#gid=1973973152) from line 17 on: please note the first two auctions for LP27 already happened. 

Call data for this proposal: 

```
0x1804241d0251a37492c47ff0c069dad8080818b5303493eb91feb718cc4cee7e3ebe39978e54bef9000103000000508b0100004800e2a501006c1d028557b8b9b1177d169c1e675aebde9685c2c141f0e32dadf13c9ca8d70b16dc06fce2ff000105000000508b0100004800e2a50100701d02227b91c3edcc0775442d0b24d507766ecb73d3f4c5f91ae16a78fa027685cfc100ac0701010700000080510100004800f1d2741d029ca55d18392de86b9c464ab3224bea70ceccc54f25feab22ed6c38fa8fabaff180e61001010700000080510100004800f1d2781d02f9c1800fd16e1bb758f29193e2db9555c386499ea0fa479a9f667ef930a05e3100211a01010700000080510100004800f1d27c1d0212f0110cec745116c8801f9c1f44770e3f82976793db821cee4364d4e256aaa6805b2301010700000080510100004800f1d2801d024fb5addef23974b6a5c78cf2bac108aefc41603a04e8e8447fe6e4c6cd511b9500962c01010700000080510100004800f1d2841d02e4739bb1095c94cc172c4f320aebfc71c69f2d1102f4592bed81a687f86cdbc880d03501010700000080510100004800f1d2881d020e4d6cfd138a715673efe7d70d7f2680b3531a04b1bc3052bb34f6c39234cf74000b3f01010700000080510100004800f1d28c
```

Make sure to review and vote at your convenience!


- The Kusama community is planning to hold more auctions for parachains in 2023.
- The auctions will be for LP27 to LP35, and there will be a total of 57 auctions until January 2024.
- The schedule for the auctions can be found in a Google spreadsheet.
- The first two auctions for LP27 have already happened.
- The community is working on a new feature called Scheduler to help with the auctions.

New Batch of Auctions for 2023: from LP27 to LP35 (Replacing Referendum 71)

This is a referendum whose proposer address (Eovc1HjhjVDi4xwrJUgCjhHgqS78s4kDoFgSAxoaw7VkXeA) 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.

I submitted wrong track. Please VOTE AGAINST IT!

We have accidentally submitted the incorrect Genesis WASM for the Bittensor parathread on Kusama (current genesis wasm is using para id 2096), hence we are looking to update it to para id 2242. 

We appreciate all the help, as this is our first referendum request please let us know if we missed anything.

[0] Origin: Root