This proposal is a repeated proposal of StakePoolV2, and the parameters in it are wrong. 
Please vote against it, thank you!

Invalid proposal

This proposal has also been discussing on community forum: https://forum.phala.network/t/proposal-stakepool-v2-and-vault-launch/3784

## TLDR

This proposal aims to upgrade the 'Delegate to Earn' mechanism on the Khala network. After the upgrade, a Delegation NFT is assigned as a certificate for users' delegations which solves the withdrawal issue caused by lock-up time. Furthermore, automatically compounding delegator rewards will replace having to claim rewards manually which will improve delegation efficiency. In addition, we are introducing a major new feature called Vault, which allows users to pass the management of delegation to the Vault operator. Vault operators will manage delegations to individual StakePools on behalf of their delegators which will further enhance delegation efficiency. This will also lower the barrier to entry significantly. 

## Features details

### Update 1: An NFT representing each delegation share

Your delegation positions in each pool are now represented as NFTs in StakePool V2. Like any other NFT, they will be transferable and tradable in the PhalaWorld NFT marketplace. As a result, using NFT technology to represent pool shares, the liquidity of your delegation is dramatically increased. Instead of having the sole option of waiting upto 7-14 days to withdraw, you can now trade your StakePool delegation on a secondary marketplace for potentially immediate liqudity.  

![](https://i.imgur.com/DXmexPz.jpg)

### Update 2: Automatically compounding delegator rewards

Delegator rewards can be automatically reinvested in the same StakePool or Vault. As a result, there is no longer a need to manually claim rewards periodically.

### Update 3: Vault - Lowering risk and barrier to entry

Inspired by many DeFi protocols, we present a Vault feature that allows third party operators to manage the delegation of your funds across multiple StakePools in a non custodial fashion. Vaults are pools of funds which can be delegated across any number of StakePools by the Vault operator on behalf of their delegators. The choice of strategy a Vault operator pursues can lead to maximum returns and minimal worker downtime risk to enable premium efficiency for the Vault delegators. Vault operators are incentivised to pursue the best possible strategy for their delegators by receiving a percentage of the rewards.

For many delegators, they will not necessarily have the time or experience to manage individual StakePool delegations in an optimal fashion. Even if they attempt to manually manage their delegations, choosing the wrong pools can be an expensive mistake. These mistakes not only affect their delegation rewards but also effect the stability of the whole network. Our new Vault feature solves all of these issues in one go. A small group of Vault operators, for a fee, effectively can manage the StakePool choices for a large chunk of the user base. This allows them to obtain optimal rewards while incentivising the best run and most stable StakePools, improving the quality of the network for everyone. 

As with delegating to StakePools, when a user delegates to a Vault, they will receive a Delegation NFT. The delegations in the Vault also compound interest.

![](https://i.imgur.com/SAYAfaT.png)


### Update 4: New WrappedBalances pallet and Governance Voting

In StakePool V1, delegation could still be used for governance voting. However those tokens were "locked". This meant the tokens could not be transferred or traded.

In StakePool V2 with an NFT now representing a delegation and being tradable, we need to introduce a mechanism to transfer governance voting rights of the original stake when the NFT is traded. To do this, we need to introduce the concept of WrappedBalances and Wrapped-PHA (W-PHA). 

In StakePool v2 you need W-PHA in order to be able to delegate to a StakePool or Vault. You can always exchange PHA to W-PHA in a one to one fashion. A new pallet called WrappedBalances handles this exchange via smart contract automatically. When a user withdraws they can then convert their W-PHA back to PHA in a reversal of the original exchange. W-PHA and PHA are always 1:1. 

The WrappedBalances pallet enables the tracking of W-PHA. When the user delegates W-PHA to a pool they receive a Delegation NFT which acts a certificate of proof of the share in the pool. This allows the W-PHA to be held by the StakePool or Vault, but be associated with the address of the account that holds the Delegation NFT. 

WrappedBalances uses a proxy voting mechanism. When you exchange PHA to W-PHA, the voting rights of the PHA transfer along to the W-PHA. Delegators can vote for a proposal through the WrappedBalances pallet; it will temporarily lock part of or all of their W-PHA assets to represent the fact these tokens are being used for a governance vote. These locked W-PHA cannot be transferred, or exchanged back to PHA, until your vote has finished. 

So far, WrappedBalances does not support council elections. This feature will be developed within two months after this upgrade. However, because the current total Delegation on the network is close to 190 million PHA, to avoid this impacting council elections, we will freeze the election function until we support this feature.

## Upgrade process impact

### Computing & Delegate related on-chain functions must be stopped during the upgrade

Due to the fact this upgrade involves the entire delegation mechanism, this upgrade will have to be split across multiple blocks, which has never happened in Phala or even in other parachains.

Therefore the time required to complete this upgrade will be non trivial. This means that we need to stop all functions related to StakePools, Workers, Delegation, and Computing Rewards on the chain. This may take upto five days.

### Breaking upgrade on pRuntime & PRB

During the on-chain upgrade computing providers are highly encourage to upgrade their own stack. Changes to the chain will break any existing version of PRB, and so the PRB update is a critical one. pRuntime compatability with the new chain will only support the most recent versions and so an upgrade of this is strongly recommended too. We will provide an exact version number on the PRB monitor page to ensure that compute providerscan determine whether their PRB upgrade is successful.

### Computing Rewards will be delayed for 8 Days

Due to the pausing of all chain functions related to Workers they will all go unresponsive as soon as this upgrade starts and will remain in that state at least as long as the upgrade is ongoing. Therefore we have developed a new function that can suspend the distribution of computing rewards within a certain period. Once this reward pause period finishes, at the first heartbeat event, each worker will be paid the full reward for the entire pause period. But, of course, it requires the worker to have been active before the reward pause period starts and be active after it stops. We feel this is the fairest solution for the community. 

Before the upgrade, we will determine the specific time period required to suspend rewards in advance, including the start block and end block and announce it to the community.

### Phala App 2.0

We will substantially update the Phala App to deal with this on-chain upgrade. This includes the following: 

* Being compatible with the functional changes of StakePool V2, including 
  * an NFT representing a share of a StakePool or Vault 
  * Automatically compounding delegator rewards
* Providing Vault usage and management pages 
* Automated exchange between PHA and W-PHA

The app has been redesigned from the ground up, both under the hood and the user interface. This version strives to be mobile compatible from day one as well.

### Council lists frozen, elections suspended

As mentioned above, starting from this upgrade, we will temporarily freeze the Council list and suspend council elections.

To ensure the Council election's fairness and the Council list's reliability, we will take a snapshot of the Council member list based on the last block before the upgrade and maintain the list until the election function is restored. We of course welcome and encourage the community to fully participate in council elections before they are paused.

## Timeline

### Before the upgrade

* **30th Nov ~  7th Dec** Proposal discussion in the community
* **1st Dec  ~  7th Dec**	Internal Test
* **8th Dec  ~ 14th Dec**	Public Vote for this proposal
* **8th Dec  ~ 14th Dec**	Public Test
* **15th Dec (Estimated)** New versions of pRuntime and PRB released
* **15th Dec ~ 23th Dec (Estimated)**  If the proposal passes, the 'upgrade' starts

The exact upgrade time (block height) will be announced in advance and voted on the motion by Council members.

### During the upgrade

The length of the upgrade is not known ahead of time. The entire upgrade may take upto 5 days, though it may be much shorter, and if critical bugs are encountered it may also take longer aswell. 

* **15th Dec** Suspend the distribution of computing rewards
* **16th Dec** On-chain upgrade starts, the Computing & Delegation related functions stop
* **16th Dec** The Delegate and Mining pages of the Phala App pause and the Phala App upgrade starts. Compute providers can  start to update their pRuntime and PRB.
* **21th Dec** On-chain upgrade finishes. Computing & Delegation related functions start on chain. StakePool V2 and Vault on-chain functions officially launch
* **21th Dec - 23th Dec** On-chain upgrade test period; Compute providers can register and start workers on chain or create pools during this period.
* **22th Dec** Phala App 2.0 launches
* **23th Dec** Resume distribution of Computing Rewards. The whole upgrade ends

Proposal: StakePool V2 and Vault Launch

# Proposal Overview

This proposal below is initiated for the community referendum. The proposal itself does not contain any specific `runtime_update`.

* Open Khala Transfer
* Launch Khala-Ethereum bridge for $PHA transfer

If the community’s opinion is `“AYE“`, then the proposal will be successfully passed. Khala Council will implement two ` fast_track` proposal separately:
- Motion A : on this proposal take effect `Day 0`, use `runtime_update` to open Khala transfer
- Motion B:  on this proposal take effect `Day +5` , use `runtime_update` to launch Khala-Ethererum bridge

# On-chain Info

The proposal `0xd1229f749b7633ba995b70f26886be0bdc9c6563e21a2ce2002991c9bae9830a ` is now available on the Polkadot.js app:

> **Vote here**:[ https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkhala-api.phala.network%2Fws#/democracy ](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkhala-api.phala.network%2Fws#/democracy)

There will be a **7-day** `Voting Period` and **3-hour** `Enactment Period` before execution. To learn more about how to participate in our democratic structures please read:[ https://wiki.phala.network/en-us/docs/governance/1-participate-in-democracy/ ](https://wiki.phala.network/en-us/docs/governance/1-participate-in-democracy/)

* ***Preimage***: `0xd1229f749b7633ba995b70f26886be0bdc9c6563e21a2ce2002991c9bae9830a `
* ***Proposal Hash***: `0xd1229f749b7633ba995b70f26886be0bdc9c6563e21a2ce2002991c9bae9830a `

Motion #6: Open Khala Transfer and Bridge to Ethereum 

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

Accept & Open HRMP channel with Litmus (5th try, sadly) - motion #180

This motion will trigger the v1210 runtime upgrade with the following features:

- Fix a dead-loop problem in Stake Pool withdraw
- Enable PhalaWorld marketplace
- Upgrade upstream Substrate to v0.9.37

For more details, please refer to: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.21>

Khala Runtime Upgrade v1210 - motion #181

This motion will try to re-execute:

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

Accept & Open HRMP channel with Litmus (4th try) - motion #178

This motion will try to re-execute:

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

Accept & Open HRMP channel with Litmus (3rd try) - motion #177

The compute reward subsidy pool has only 7M left (around 1 month of the reward). This motion is a part of the effort to unlock 155M PHA (around 1 year budget) and move it as the Khala reward. Since the unlock is 155M PHA. The SubBridge reservation accounts on both Khala and Phala should add 155M to the locked account. Then the locked balance on Ethereum can be moved to Khala via bridge transfer.

This motion will mint 155M PHA on a temporary account on **Khala**, and transfer it to the bridge reservation account via a batchAll call. The temporary account is `43RZEPV1f652dRS9d6xxpnEfo74ndNAcZ2qk4yU9qbegCTmZ`, which is randomly generated.


Mint 155M PHA for the unlocking compute reward - motion #175

This motion will trigger the v1208 runtime upgrade for bug fixes:

- Storage performance fix for StakePool v2 upgrade
- Loosen condition check for confidence level 2 to reflect the Intel definition more accurately

For more details, please refer to: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.20-khala-runtime-1208>

Khala Runtime Upgrade v1208 - motion #172

This motion will trigger the v1207 runtime upgrade for bug fixes:

- Fix the dust problem preventing contribute & withdraw in pools

For more details, please refer to: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.20-khala-runtime-1207>

Khala Runtime Upgrade v1207 - motion #165

This motion will trigger the v1206 runtime upgrade for bug fixes:

- StakePool claimable reward migration backfill
- RMRK storage leakage mitigation & backfill

For more details, please refer to: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.20-khala-runtime-1206>

Khala Runtime Upgrade v1206 - motion #163

This motion will trigger the v1205 runtime upgrade for bug fixes:

- Fix Vault amount overflow problem & backfill methods
- PhalaWorld fixes & migration

For more details, please refer to: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.20-khala-runtime-1205>

Khala Runtime Upgrade v1205 - motion #161

This motion will trigger the v1204 runtime upgrade for bug fixes. For more details, please refer to: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.20-khala-runtime-1204>

Khala Runtime Upgrade v1204 - motion #160

This motion will trigger an external referendum to runtime to v1202 to facilitate the runtime migration. 

For more details about Runtime v1202, please refer to the [Github release page](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.20-khala-runtime-1202).

Runtime 1202 & Prepare for StakePool v2 launch (7) - motion #156

This motion will trigger an external referendum to runtime to v1201 to facilitate the runtime migration. Major changes:

- Enable StakePool v2 and Vault basic filter
- Remove migrations

For more details about Runtime v1200, please refer to the [Github release page](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.19-9-runtime-1200).

Runtime 1201 & Prepare for StakePool v2 launch (4) - motion #153

This motion will trigger an external referendum to runtime to v1200 to facilitate the runtime migration. 

For more details about Runtime v1200, please refer to the [Github release page](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.19-9-runtime-1200).

Runtime 1200 & Prepare for StakePool v2 launch (3) - motion #152

This motion will trigger an external referendum to runtime to v1199. Once the upgrade is triggered, the StakePool v2 multi-block migration will start.

Runtime v1199 is a major runtime release with the following changes:

- Stake Pool v2 & Vault: completely redesigned Phala Compute
- Multi-block migrations
- Follow the upstream substrate v0.9.33

For more details about Runtime v1199, please refer to the [Github release page](https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.19-9).

----

This motion is a part of the StakePool v2 launch plan, which passed the vote on [Referenda #67](https://khala.subsquare.io/democracy/referendum/67)

Runtime 1199 & Prepare for StakePool v2 launch (2) - motion #151

This motion will trigger an external referendum to do the following things:

1. Pause heartbeat. It's required to pause the tokenomic and mining mechanism before the StakePool v2 upgrade.
2. Set the Wrapped PHA token metadata (Symbol: wPHA, ID: 10000)

This motion is a part of the StakePool v2 launch plan, which passed the vote on [Referenda #67](https://khala.subsquare.io/democracy/referendum/67)

Prepare for StakePool v2 launch (1) - motion #148

This motion will register W-PHA (Wrapped PHA) on Khala for StakePool v2 preparation. It will also trigger the registering of pruntime v0.2.5 on Khala again, because the last launch motion missed one vote (5 vote at least, given it's "greater than half of the council or root").

---

Origin proposal of Motion #143:

This motion will whitelist pruntime v0.2.5 on Khala. This version introduces a fix on the Grandpa justification validation problem described [here](https://forum.phala.network/t/topic/3701).

Related PR: <https://github.com/Phala-Network/phala-blockchain/pull/1034>

Register WPHA assets and launch pruntime v0.2.5 again - motion #146

This motion is a batch call to (1) register the following assets and set each execution price to 80_000_000_000_000_000_000, and (2) trigger a Transact message on Kusama to open a HRMP request to Pioneer Network.

Registering:

1. Pioneer NEER: id=13, path="../Parachain(2096)/GeneralKey(0x000000000000000000)", sym=NEER, dec=18
2. Pioneer BIT: id=14, path="../Parachain(2096)/GeneralKey(0x020000000000000000)", sym=BIT, dec=18

Transact:

**0x3c0030080000e803000000900100**

which can be decoded as:

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

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

Register XCM assets & Open Khala -> Pioneer Network HRMP - motion #144

v1192 is a release with the following changes:

- Introduce PhalaWorld incubation logic

For more details, please check: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.19-2.1>

Khala Network Runtime 1192 - motion #142

v1191 is a release with the following changes:

- Prepare for StakePool v2 migration: forbid remove_worker before reclaiming

For more details, please check: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.19-1.1>

Khala Network Runtime 1191 - motion #140

v1190 is a release with the following changes:

* PhalaWorld feature updates
* Update to Polkadot 0.9.30

For more details, please check: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.19>

Khala Network Runtime 1190 - motion #138

This is a retry of Motion #135. The old motion should have 6/8 votes but it only has 5 votes. So it didn't meet the super majority (>75%).

## Original motion

v1183 is a runtime-only release with the following changes:

- Add events for StakePool indexing

For more details, please check: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.18-3>

Khala Runtime Upgrade v1183 (2nd try) - motion #136

v1181 introduced a bug which caused the `utility.batch` family call to fail in a motion. As a result, Motion 130 and 131 are failed. This runtime upgrade will introduce the fix. An additional change is to add some arguments to the mining events for data indexing.

For more details, please check: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.18-2>

Khala Runtime Upgrade v1182 - motion #133

This motion will trigger a Transact message on Kusama to accept a HRMP request from Shiden Network.

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

```
0x3c01d7070000
```

which can be decoded as:

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

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

Accept Shiden -> Khala Network HRMP - motion #128

According to the suggestion in Substrate community, it's good to have a patched runtime release. Therefore we have created the runtime v1181. It has the exact runtime features as v1180 but with newer version dependencies.

Original v1181 changelogs:

- Add up to 8 council seats
- Allow StakePoolManager proxy to call PhalaStakePool.restart_mining
- Follow the upstream RMRK pallets
- Follow the upstream Polkadot v0.9.27, which is supposed to fix the state cache mismatch problem

For more details, please check: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.18-1>

Khala Runtime Upgrade v1181 - motion #127

v1170 is a release with the following major changes:

- Add up to 8 council seats
- Allow StakePoolManager proxy to call PhalaStakePool.restart_mining
- Follow the upstream RMRK pallets
- Follow the upstream Polkadot v0.9.27, which is supposed to fix the state cache mismatch problem

For more details, please check: <https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.18>

Khala Runtime Upgrade v1180 - motion #126

This motion will trigger a Transact message on Kusama to open a HRMP request to Shiden Network.

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

```
0x3c00d7070000e803000000900100
```

which can be decoded as:

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

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

Open Khala -> Shiden Network HRMP - motion #125

# Adding up Khala/Phala council seats into 8

This proposal aims to increase the Council members' seats to 8 in Q4. Both presented for Phala Network and Khala Network. 

At the moment, the Khala Council has five members. I think reaching eight members can help the Phala community grow into more democratic status.

Eight will not be the final result. The council will propose new seats supply based on how the network grows in the future. 


## What kind of council member is most wanted?

Anyone can apply for the council seat!

I, as an independent individual in the Phala community, will personally hope to see the candidate fit with the following traits:

1. Understanding the Phala council election algorithm and the delegation process.
2. Contributed to the community before; the more credit you get from the community, the greater your chance of winning an election. I suggest each candidate make a running statement in the Phala forum to introduce themselves to the community!
3. Commitment your time to the Phala community. It frequently requires participants in council discussion, 2-3 motions per week need brief discussion and decesions. Every council member must join the debate on time, on-call weekly.

For example, it's welcome for council candidates to make a statement on Phala [forum](https://forum.phala.network/c/51-category/51) as a running statement:
- Who you are
- Why you choose to run as a council member is Phala/Khala
- What have you contributed to Phala before
- Which party do you want to speak for in the community? (ambassadors/ miners / developers /PHA holders)
- How much can you contribute as a council member?

## How can I apply to be a council member?

Phala Network will follow the council members from Khala Network so that all running events will be applied from Khala Network: 
https://wiki.phala.network/en-us/maintain/governance/2-join-the-council/


## What can I get as a council member?

- Phala / Khala council members won't get paid. It's a volunteer job
- Execute the right to participate in Phala / Khala on-chain governance, present your people's interests
- Supervise the treasury usage
- Chances to be a Curator of Treasury Bounties!


### About Bounty Spending:

The following introduction is from [Polkadot Wiki](https://wiki.polkadot.network/docs/learn-treasury#closing-a-bounty). Phala/Khala Network follows the same rules.

There are practical limits to Council Members' curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to properly assess the activities described in all submissions. Even if individual Councillors have that expertise, it is improbable that a majority of members are capable of such diverse topics.

Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with the agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem.

A proposer can submit a bounty proposal for the council to pass, with a curator to be defined later, whose background and expertise are such that they are capable of determining when the task is complete. Curators are selected by the council after the bounty proposal passes and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward.

When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator's fee can be defined as the result of subtracting the value paid to the bounty rewards from the total value of the bounty.

In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches and show project management skills or experience. These recommendations ensure the effective use of the mechanism. A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of goals is completed is delegated to the curator.

After the council has activated a bounty, it delegates the work that requires expertise to the curator, who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the council to act if any issues arise.

To minimize storage on the chain in the same way as any proposal, bounties don't contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). This template can help as a checklist of all needed information for the council to make an informed decision.

The bounty has a predetermined duration of 90 days, with the possibility of being extended by the curator. Aiming to maintain flexibility in the tasks' curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism.


Adding up Khala/Phala council seats into 8 - public proposal #17

This motion will trigger a Transact message on Kusama to accept Crust's HRMP request, and open a HRMP channel to Turing.

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

```
0x1800083c01dc0700003c00dc070000e803000000900100
```

which can be decoded as:

```
utility.batch(calls: [
    hrmp.hrmpAcceptOpenChannel(sender: 2,012),
    hrmp.hrmpInitOpenChannel(
        recipient: 2,012
        proposedMaxCapacity: 1,000
        proposedMaxMessageSize: 102,400
    )
])
```


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



Establish Khala<->Crust HRMP - motion #114

Untitled - public proposal #16

The runtime 1170 contains the following updates:

1. Phala World Updates
2. Add RMRK RPC & Scripts for Phala World Updates
3. Change desclen to 4400

For more details, please refer to:

https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.17

Khala Runtime Upgrade v1170 - motion #122

This proposal will mint 44M PHA token to the SubBridge reservation account.

SubBridge connects Khala and Ethereum and allows to transfer PHA between. It maintains the reservation on the both side to ensure there's enough liquidity to allow PHA to move freely between the chains. Theoretically Khala should have 1B PHA supply, where part of the supply is in circulation, and others are locked in the bridge reservation account. However practically, there are still 463.2 M PHA locked for mining subsidy and 38M locked for crowdloan
crowdloan reward. So the final equation should be:

```
[PHA in Khala supply] + [PHA locked on Ethereum] = 1B
```

Therefore Khala's total supply (bridge reservation + other tokens in circulation) is supposed to be (1B - 463.2 M - 38M) = 498.8M PHA. Once we have unlocked the crowdloan reward, we should add 38M to the reservation to make sure the equation still holds, which means it has sufficient liquidity accept all the cross-chain transfer.

However, the situation is more complex. It turns out in the past, Khala was always imbalanced. The sum of PHA supply on Khala and locked PHA on Ethereum adds up to 994M. There's still 6M missing. It turns out an imbalance in the supply was due to the miscalculation in the initial bridge launch. It's supposed to have 27M PHA for StakeDrop event, but we only used 21M. Another 6M was used for crowdloan reward instead. It made the total crowdloan budget increased from 63M to 69M.

Another part is the 38M crowdloan reward. In the Polkadot crowdloan event, Phala is going to reward the participants with ~20M PHA. With Phala launched, it's easiest to unlock the full 38M and keep the remaining PHA locked on Phala.

So in this proposal, we are going to fix the 6M PHA imbalance add the 38M crowdloan funds to the reservation.

Mint reserved funds for Phala crowdloan unlock - motion #119

This motion will redo the overrode [motion #113](https://khala.subsquare.io/council/motion/117).

---

Here's the original content of motion #113:

This motion will trigger a Transact message on Kusama to accept a HRMP request from Crab Network.

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

```
0x3c0139080000
```

which can be decoded as:

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

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

Redo: Accept Crab -> Khala HRMP - motion #117

This motion will trigger a Transact message on Kusama to open a HRMP request to Crab Network.

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

```
0x3c0039080000e803000000900100
```

which can be decoded as:

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

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

Open Khala -> Crab Network HRMP - motion #110

This motion will trigger a Transact message on Kusama to accept HRMP requests from Basilisk and Calamari.

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

```
0x1800083c01240800003c012a080000
```

which can be decoded as:

```
utility.batch([
  hrmp.hrmpAcceptOpenChannel(sender: 2,084)
  hrmp.hrmpAcceptOpenChannel(sender: 2,090)
])
```

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



Accept HRMP channel from Basilisk & Calamari - motion #104

The runtime 1160 contains the following updates:

1. SubBridge minor improvements
2. Misc improvements in StakePool (add events for indexer)
3. Update the storage deposit of uniques pallet
4. Update the upstream Substrate version to v0.9.24

For more details, please refer to:

https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.16

Khala Runtime Upgrade v1160 - motion #95

This motion will trigger a Transact message on Kusama to open a HRMP request to Basilisk.

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

```
0x3c002a080000e803000000900100
```

which can be decoded as:

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


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



Open Khala->Basilisk HRMP - motion #94

This motion will trigger a Transact message on Kusama to open a HRMP request to Calamari.

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

```
0x3c0024080000e803000000900100
```

which can be decoded as:

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


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



Open Khala->Calamari HRMP - motion #91

Untitled - public proposal #13

This motion will trigger a Transact message on Kusama to accept Turing's HRMP request, and open a HRMP channel to Turing.

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

```
0x1800083c01420800003c0042080000e803000000900100
```

which can be decoded as:

```
utility.batch(calls: [
  hrmp.hrmpAcceptOpenChannel(sender: 2,114),
  hrmp.hrmpInitOpenChannel(
    recipient: 2,114
    proposedMaxCapacity: 1,000
    proposedMaxMessageSize: 102,400
  )
])
```


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



Accept and open Khala<->Turing HRMP  - motion #88

The runtime 1150 contains the following major updates:

1. Introduce NFTs: integrate pallet-uniques and Phala World pallets
2. Misc improvements in StakePool (separated reward claiming, and more events)
3. Update the upstream Substrate version to v0.9.23

Please check the release page for details: https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.15-rc2

Khala Runtime Upgrade v1150 - motion #89

Unfortunately, I've messed up the hash. Pardon my foolishness, for I ask for forgiveness. I shall ask for another proposal soon.

The dawning realization my hash is incorrect #14

Release some locked XCM PHA transfer from Karura (2) - motion #86

**Dear Phamily**

Allow me to introduce myself. Hi! I'm Thibaut, a French software developer with a background in Java and Ethereum security. I've got over 7 years of development under my wing and today, I come to you to present my registrar application. (view https://github.com/terminalsin for my OS projects)
 
I first heard about Phala at the Paris Blockchain Summit, in which I met several Ambassadors and the legend Marvin himself. Since then, I have become a stake pool provider (#2028). 

The reasons backing my decision to apply as a registrar are quite simple:
- I firmly believe in Phala's potential to expand, and such cannot be due without contribution to the community. Henceforth, I wish to do my part and assist the team in any way I physically can.
- I advocate for privacy over security. I firmly believe Registrars should be authenticated in a fashion which is sensitive to data, albeit without compromising the privacy wish of one.
- I'm trilingual (French, English, Spanish), based in Europe and hopefully quadrilingual in the years to come (currently learning Mandarin). France is a striving country for the crypto-sphere, and the absolute lack of knowledge regarding Polkadot has strongly marked me. I wish to be a leading actor in solving this problem.

If there are any rising concerns or wishes to communicate to me, here are my socials to get in touch:
- Telegram: @terminalsin
- Discord: Ghast#0001
- Matrix: @terminalsin:matrix.org
- Email: mastermind@artemis.ac

I look forward to the Council's response to this proposal,
Sincerely,
- Thibaut Gautier

Temporary document highlighting the methodology for how I will execute my judgements: [https://docs.google.com/document/d/1LuLX2f4d6yGkWUJtL2YpiPAQGCK_p_HmDHaGIGlwgRU/edit?usp=sharing](https://docs.google.com/document/d/1LuLX2f4d6yGkWUJtL2YpiPAQGCK_p_HmDHaGIGlwgRU/edit?usp=sharing)


Thibaut Gautier / Registrar Application - public proposal #15

This motion will bring an external proposal to release some stuck XCM transfer from Karura to Khala.

Recently there's a problem introduced in Karura's frontend app, resulting two users' XCM transfer stuck. Specifically, the frontend app composed an incorrect XCM execution weight in a XCM crosschain transfer transaction. The XCMs were executed on Karura, but were not executed successfully on Khala because of the out-of-weight problem. The assets are burnt on Karura, but on the Khala side, they are not distributed to the actual user. The assets are remaining in the SubBridge reservation account.

So in this motion, we are going to transfer the locked funds directly from the reservation account to the destination user by "balances.forceTransfer"

Detailed user list: https://hackmd.io/2n0M3ujZQIikoanHk_O3Qg

Release some locked XCM PHA transfer from Karura - motion #84

This motion will create bring an external proposal to send a XCM to call "registar.swap(2004, 2111)" on behalf of the Khala sovereign account on Kusama.

Accept 2004 and 2111 swap on Kusama - motion #83

This motion will bring an external proposal to adjust the tokenomic parameter to match the 15s block time. Specifically, the block_subsidy will be reduced from 183.3 to 125 (100 PHA * 15s / 12s). This is because after the Kusama v0.9.20 upgrade, the parachain block time has been greatly reduced from around 24s to 15s.

Update tokenomic parameter to match 15s block time - motion #78

The runtime 1140 contains the following major updates:

1. Upgrade SubBridge to allow easy integration to 3rd party bridges and add BSX (Basilisk native token)
2. Update the upstream Substrate version to v0.9.20
3. Phala Pallets v6 migration: remove dirty data (SubAccountAssignments)

For more details, please refer to:

https://github.com/Phala-Network/khala-parachain/releases/tag/v0.1.14-rc2