This motion will trigger the runtime upgrade for Khala Network Runtime v1252 with the following major updates:

* Fix the sygma problem

For details, please check [the release page](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.25-2)


Khala Runtime Upgrade v1252 - motion #239

Due to the some big amount cross-chain transfer,  we have almost run out of liquidity on Khala network. To make the bridge work properly, we create this proposal to move 4M PHA from ChainBridge reserve account on both Khala & Phala, and Ethereum network at the same time.

`436H4jat7TobTbNX4RCH5p7qgErHbGTo1MyZhLVaSX4FkKyz` to SygmaBridge reserve account `436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3` on both Khala and Phala network

The proposal will trigger the extrinsic on blockchain which will force transfer 4M PHA from the source account to dest account

[4th round] Move 4M PHA from ChainBridge to SygmaBridge - motion #233

This motion will trigger the runtime upgrade for Khala Network Runtime v1251 with the following major updates:

* Fix SubBridge XCM forwarding

For details, please check [the release page](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.25-1)


Khala Runtime Upgrade v1251 - motion #231

Due to the some big amount transfers send from Ethereum to Khala,  we are almost run out of liquidity on Khala network. To make the bridge work properly, we create this proposal to move 2M PHA from ChainBridge reserve account on both Khala, Phala, and Ethereum network at the same time.

`436H4jat7TobTbNX4RCH5p7qgErHbGTo1MyZhLVaSX4FkKyz` to SygmaBridge reserve account `436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3` on both Phala & Khala network. The proposal will trigger the following extrinsic on blockchain which will force transfer 2M PHA from the source account to dest account

[3rd round] Move 2M PHA from ChainBridge to SygmaBridge - motion #228

Due to the high bridge liquidity utilization from Ethereum to Khala, we have almost run out of liquidity on Khala network. To make the bridge work properly, we create this proposal to move 500K PHA from ChainBridge reserve account `436H4jat7TobTbNX4RCH5p7qgErHbGTo1MyZhLVaSX4FkKyz` to SygmaBridge reserve account `436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3` on both Phala and Khala network.

The proposal will trigger the following extrinsic on blockchain which will force transfer 500K PHA from the source account to dest account:

```js
{
  args: {
    source: { Id: '436H4jat7TobTbNX4RCH5p7qgErHbGTo1MyZhLVaSX4FkKyz' },
    dest: { Id: '436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3' },
    value: '500,000,000,000,000,000'
  },
  method: 'forceTransfer',
  section: 'balances'
}
```

[Second round] Move 500K PHA from ChainBridge to SygmaBridge - motion #226

With the latest runtime upgrade happened on Khala and Phala, SygmaBridge pallets have been enabled on those two networks. SygmaBridge will be part of the SubBridge, provide the functionality of transferring asset between parachain and EVM chains.

We have finished all tests, now we create this proposal to move 500K PHA from ChainBridge reserve account `436H4jat7TobTbNX4RCH5p7qgErHbGTo1MyZhLVaSX4FkKyz` to SygmaBridge reserve account `436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3` on both Khala and Phala network. The proposal will trigger the following extrinsic on blockchain which will force transfer 500K PHA from the source account to dest account:

```js
{
  args: {
    source: { Id: '436H4jat7TobTbNX4RCH5p7qgErHbGTo1MyZhLVaSX4FkKyz' },
    dest: { Id: '436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3' },
    value: '500,000,000,000,000,000'
  },
  method: 'forceTransfer',
  section: 'balances'
}
```

Move 500K PHA from ChainBridge to Sygma Bridge - motion #221

This motion will trigger the runtime upgrade for Khala Network Runtime v1250 with the following major updates:

- Enable Sygma bridge pallets for configuration
- Upstream update to Substrate v0.9.42 and node client stability improvements

For details, please check [the release page](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.25)


Khala Runtime Upgrade v1250 - motion #220

This motion will trigger a Transact message on Kusama to accept the HRMP request sent from Picasso.

The transact will be performed on Kusama/Polkadot with the call:

```
0x3c0127080000
```

which can be decoded as:

```
hrmp.hrmpAcceptOpenChannel(
    sender: 2,087
)
```

Khala's sovereign account has already got enough deposit to open the channels.

Accept HRMP channel from Picasso - motion #217

This motion is a retry of:

- [Motion 212](https://khala.subsquare.io/council/motion/212): incorrect `proposedMaxCapacity` (should be 1000, but given 10,000)
- [Motion 209](https://khala.subsquare.io/council/motion/209): didn't have enough PHA to create assets
- [Motion 207](https://khala.subsquare.io/council/motion/207): didn't receive enough votes.

## Original Proposal

This motion will first trigger a Transact message on Kusama to open a HRMP request to Picasso Network then register PICA on Khala.

The transact will be performed on Kusama with the following call:

```
0x3c0027080000e803000000900100
```

which can be decoded as:

```
hrmp.hrmpInitOpenChannel(
  recipient: 2,087
  proposedMaxCapacity: 1,000
  proposedMaxMessageSize: 102,400
)
```

Phala's sovereign account has already got the enough deposit to open the channels.

PICA registry info is:

```
Picasso PICA: id=15, path=”../Parachain(2087), sym=PICA,dec=12, exePrice=default
```


Open Khala -> Picasso Network HRMP & Register PICA on Khala (4) - motion #215

This motion will trigger the runtime upgrade for Khala Network Runtime v1247 with the following major updates:

- Fix the min balance problem which causes GK stuck at Phala Network

For details, please check [here](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.24-3-runtimes-1247)

Khala Runtime Upgrade v1247 - motion #213

This motion is a retry of:

- [Motion 209](https://khala.subsquare.io/council/motion/209): didn't have enough PHA to create assets
- [Motion 207](https://khala.subsquare.io/council/motion/207): didn't receive enough votes.

## Original Proposal

This motion will first trigger a Transact message on Kusama to open a HRMP request to Picasso Network then register PICA on Khala.

The transact will be performed on Kusama with the following call:

```
0x3c00270800001027000000900100
```

which can be decoded as:

```
hrmp.hrmpInitOpenChannel(
  recipient: 2,087
  proposedMaxCapacity: 1,000
  proposedMaxMessageSize: 102,400
)
```

Phala's sovereign account has already got the enough deposit to open the channels.

PICA registry info is:

```
Picasso PICA: id=15, path=”../Parachain(2087), sym=PICA,dec=12, exePrice=default
```


Open Khala -> Picasso Network HRMP & Register PICA on Khala (3) - motion #212

This motion will trigger the runtime upgrade for Khala Network Runtime v1246 with the following major updates:

- Fix Khala new worker cannot be registered problem
- Fix Phala message queue txpool sequence checker

For details, please check [here](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.24-3-runtimes-1246)

Khala Runtime Upgrade v1246 - motion #210

This motion is a retry of [Motion 207](https://khala.subsquare.io/council/motion/207) which didn't receive enough votes.

## Original Proposal

This motion will first trigger a Transact message on Kusama to open a HRMP request to Picasso Network then register PICA on Khala.

The transact will be performed on Kusama with the following call:

```
0x3c00270800001027000000900100
```

which can be decoded as:

```
hrmp.hrmpInitOpenChannel(
  recipient: 2,087
  proposedMaxCapacity: 1,000
  proposedMaxMessageSize: 102,400
)
```

Phala's sovereign account has already got the enough deposit to open the channels.

PICA registry info is:

```
Picasso PICA: id=15, path=”../Parachain(2087), sym=PICA,dec=12, exePrice=default
```


Open Khala -> Picasso Network HRMP & Register PICA on Khala (2) - motion #209

This motion will trigger the runtime upgrade for Khala Network Runtime v1245 with the following major updates:

- Better dust processing in Vault. Fixed a bug preventing the withdraw from some vults.
- Node client stability improvements

For details, please check [here](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.24-3-runtimes-1245)

Khala Runtime Upgrade v1245 - motion #208

This motion intends to enable the HRMP channel to InvArch Tinkernet. The proposal was brought to the council and as external referendum for a few times but all the tries were failed, due to either the technical problems and mistakes, or not reaching the voting threshold. In the past voting, there's no strong signal against this proposal.

In the last motion (205) where the proposal didn't pass as a referendum. However the opposition party has never given out a clear reason in public spaces (SubSquare, Discord, and Twitter). Therefore, I proposed this motion to bring it back to the democracy again, hoping it can attract more votes to the referendum to unblock the HRMP integration.

# Original Proposal

This motion will trigger two Transact message on Kusama to accept&send the HRMP request sent from InvArch Tinkernet.

The first transact will be performed on Kusama with the following call:

```
0x3c014d080000
```

which can be decoded as:

```
hrmp.hrmpAcceptOpenChannel(
  sender: 2,125,
)
```

The second transact will be performed on Kusama with the call:

```
0x3c004d080000e803000000900100
```

which can be decoded as:

```
hrmp.hrmpInitOpenChannel(
  recipient: 2,125,
  proposedMaxCapacity: 1,000
  proposedMaxMessageSize: 102,400
)
```


Khala's sovereign account has already got enough deposit to open the channels.

Accept & Open HRMP channel with InvArch Tinkernet (4) - motion #206

[Motion #194](https://khala.subsquare.io/council/motion/194) and [#204](https://khala.subsquare.io/council/motion/204) were not executed successfully due to the preimage / scheduler migration misconfiguration. This motion will try to re-execute Motion 194. Hopefully it can be executed correctly.

Please vote NAY to [#204](https://khala.subsquare.io/council/motion/204) because it sets a wrong preimage length. Vote on this proposal instead.

# Original Proposal

This motion will trigger two Transact message on Kusama to accept&send the HRMP request sent from InvArch Tinkernet.

The first transact will be performed on Kusama with the following call:

```
0x3c014d080000
```

which can be decoded as:

```
hrmp.hrmpAcceptOpenChannel(
  sender: 2,125,
)
```

The second transact will be performed on Kusama with the call:

```
0x3c004d080000e803000000900100
```

which can be decoded as:

```
hrmp.hrmpInitOpenChannel(
  recipient: 2,125,
  proposedMaxCapacity: 1,000
  proposedMaxMessageSize: 102,400
)
```


Khala's sovereign account has already got enough deposit to open the channels.

Accept & Open HRMP channel with InvArch Tinkernet (3) - motion #205

This motion will mint 308.2M PHA and deposit it to SubBridge PHA reservation to enable PHA transfer. Once the motion is finished, the Phala team will bridge 308.2M PHA to the Phala compute reward pool.

[Gemini was launched on 8/4/2022](https://medium.com/phala-network/khala-gemini-upgrade-mining-reward-transaction-will-happen-around-2-00-a-m-utc-on-april-8th-97847474d7f0). Since then, Phala’s team had moved 381.8M PHA rewards from the locked compute reward subsidy reservation on Ethereum to the Khala subsidy pool in two separate transactions (Not including the 10M tokens transferred to Khala before Gemini started). 

There are still 127M tokens left in the Khala subsidy pool and 308.2M tokens locked in the Ethereum subsidy pool. 

This motion proposes that all the locked tokens in the Ethereum subsidy pool (308.2M PHA) are moved to the Phala subsidy pool to pay for the compute rewards to the workers on the Phala chain. 

In the future, we will periodically transfer funds between the Phala and Khala subsidy pools based on their balances to ensure that both chains have sufficient tokens to pay computation rewards. The rules for distributing rewards will be implemented by a dedicated budget balancer introduced in the referendum. More details can be found [here](https://khala.subsquare.io/democracy/referendum/89).

## Detailed Background

You can find both the Ethereum compute reward subsidy account and the Phala/Khala subsidy pool accounts here:

1. Ethereum (the biggest token holder on Etherscan) -[0x4731bc41b3cca4c2883b8ebb68cb546d5b3b4dd6](https://etherscan.io/token/0x6c5bA91642F10282b576d91922Ae6448C9d52f4E?a=0x4731bc41b3cca4c2883b8ebb68cb546d5b3b4dd6)
2. Phala — [modlphala/pp](https://phala.subscan.io/account/436H4jat7TobTbNYLdSJ3cmNy9K4frmE4Yuc4R2nNnaf56DL)
3. Khala — [modlphala/pp](https://khala.subscan.io/account/436H4jat7TobTbNYLdSJ3cmNy9K4frmE4Yuc4R2nNnaf56DL).

Since the genesis launch of Khala, 1% of the total PHA supply was moved from the Ethereum compute reward subsidy reservation to the Khala subsidy pool, according to Phala tokenomics. As 70% token is reserved for computing rewards, 69% was left in the Ethereum subsidy reservation.

After the Gemini Update, Khala and Phala will share the same compute reward schedule and subsidy pool. Therefore Phala team must move more funds to the Khala subsidy pool.

The first move after the Gemini Update happened on April 8th, 2022. The transaction amount is 226,800,000 PHA. And the second move happened on Feb 21st, 2023, with the amount of 155,000,000 PHA.

Adjust bridge reservation for the 308.2M PHA compute reward unlock - motion #197

This motion will trigger the runtime upgrade for Khala Network Runtime v1241. It is a bug fix for the WrappedBalances pallet.

For details, please check [here](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.24-khala-runtime-1241)

Khala Runtime Upgrade v1241 - motion #196

This motion will trigger two Transact message on Kusama to accept&send the HRMP request sent from InvArch Tinkernet.

The first transact will be performed on Kusama with the following call:

```
0x3c014d080000
```

which can be decoded as:

```
hrmp.hrmpAcceptOpenChannel(
  sender: 2,125,
)
```

The second transact will be performed on Kusama with the call:

```
0x3c004d080000e803000000900100
```

which can be decoded as:

```
hrmp.hrmpInitOpenChannel(
  recipient: 2,125,
  proposedMaxCapacity: 1,000
  proposedMaxMessageSize: 102,400
)
```


Khala's sovereign account has already got enough deposit to open the channels.

Accept & Open HRMP channel with InvArch Tinkernet - motion #194

This motion will trigger the runtime upgrade for Khala Network Runtime v1230. It is a new Khala runtime and client release with the following features:

- Add inDEX pallet
- Prepare for Phala Compute & Phat Contract launch
- Upgrade upstream substrate (Polkadot v0.9.40) with database stability improvements

For details, please check [here](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.23)

Khala Runtime Upgrade v1230 - motion #195

This motion will retry [motion #189](https://khala.subsquare.io/council/motion/189). The last motion was executed, but got overrode by motion #190 because Substrate only has one external proposal slot, and the newer one always overrides the earlier one.

## Original Proposal

This motion will [Proposal #20](https://khala.subsquare.io/democracy/proposal/20) to the external queue to accelerate the voting process. Once it's passed, the technical committee will fast track it (but still keep 7 days voting period).

Accelerate proposal #20: launch gemeni tokenomic on Phala (2nd try) - motion #191

This is a retry of the [motion #188](https://khala.subsquare.io/council/motion/188).

The original motion was not executed successfully because the permission was set incorrectly. It requires root permission to execute. So in this motion, we are going to execute the same steps but in a referenum.

## Original proposal

This motion is a batch call to fix the ChainBridge migration issue on ZLK after we upgrade to XCM v3.
With the new XCM version, `GeneralKey` definition was changed, which influence our resource id
and reserve account calculation on ChainBridge. The batch contains 6 calls:

1. Call-1 set ZLK to a temporary location `(1, X2(Parachain(2001), GeneralIndex(0))`
2. Call-2 set ZLK back to its real location `(1, X2(Parachain(2001), GeneralKey(2, 0x0207..00))`
The above two call will trigger ZLK resource id updated to proper value automatically
3. Call-3 force burn `196247848001219224432700` units ZLK from old reserve account(pub key): `0xde50ca45c8f7323ea372fd5d7929b9f37946690b0b668985beebe60431badcea`
4. Call-4 force mint `196247848001219224432700` units ZLK to new reserve account(pub key): `0x95f793efdd6b1f7894f6c4d9bcb3de87d4e58385c56ebf1bfef91f9ab2144b91`
5. Call-5 force burn `2026420000000000000000` units ZLK from temporary account: `427Xv1Y1bNNQ5XU6pCCVGbqTgEe41t6s4GAYCCCDwASWsXpa`
5. Call-6 force mint `2026420000000000000000` units LK to external account: `43L9xU7zKU2ByNKvsgb4QLnhBU4pVvfbphh52TeH8byRtPuj`

There are 5 transaction that have their ZLK locked in the temporary account: 
<https://khala.subscan.io/event?address=427Xv1Y1bNNQ5XU6pCCVGbqTgEe41t6s4GAYCCCDwASWsXpa&module=assets&event=issued&startDate=&endDate=&startBlock=&endBlock=&timeType=date&version=1220>

And the external account will bridge ZLK to user account on Moonriver



Fix ChainBridge migration for ZLK (2nd try) - motion #190

This motion will trigger the runtime upgrade for Khala Network Runtime v1210. It is a new Khala runtime release with the following features:

- Bug fixes in Stake Pool v2 and Vault
- Bug fixes in RMRK Marketplace
- Upgrade upstream substrate (Polkadot v0.9.39) with database stability improvements

For details, please check [here](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.21)

Khala Runtime Upgrade v1210 - motion #187

The Phala team has successfully secured the Kusama parachain 2264 to extend the leasing period of Khala Network. In this motion, it will trigger a Transact message on Kusama to pair the swap request sent from 2264.

The transact will be performed on Kusama with the following call:

```
0x4603d4070000d8080000
```

which can be decoded as:

```
registrar.swap(
  id: 2,004,
    other: 2264,
)
```

Khala's sovereign account has already got enough deposit to do swap.

Swap Khala parachain slot with parachain 2264 - motion #186

This motion will try to re-execute:

- [Motion 178](https://khala.subsquare.io/council/motion/178), which was succeeded and fast-tracked but the external proposal was not voted in time.
- [Motion 177](https://khala.subsquare.io/council/motion/176), which was succeeded but the transact weight limit is too low.
- [Motion 176](https://khala.subsquare.io/council/motion/176), which was succeeded but the external proposal was overwritten.
- [Motion 174](https://khala.subsquare.io/council/motion/174), which was failed because it should be a external referendum instead of a simple motion.

## Original proposal

This motion will trigger a Transact message on Kusama to accept&send the HRMP request sent from Litmus Network.

The transact will be performed on Polkadot with the following call:

```
0x1802083c013a0800003c003a080000e803000000900100
```

which can be decoded as:

```
hrmp.hrmpAcceptOpenChannel(
  sender: 2,106,
)
hrmp.hrmpInitOpenChannel(
  recipient: 2,106,
  proposedMaxCapacity: 1,000
  proposedMaxMessageSize: 102,400
)
```

Khala's sovereign account has already got enough deposit to open the channels

Tech. Comm. Proposals