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

Invalid proposal

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

Dear Phala Community Members,

As the computation eco system leader of Phala team and the owner of the biggest Vault on Khala network, it is with utmost excitement and dedication that I announce my Proposal for the nominating myself as a Registrar on the Khala. 

In close collaboration with the community, I have a natural advantage in reaching more community users and providing them with effective help. Among these, more efficient on-chain certification is essential. Moreover, I am also dedicated to promoting a greater number of vaults to encourage users to obtain more reliable staking rewards.

There is no doubt that Phala is positioned for outstanding growth and success in the coming years, and I am both proud and humbled to be a part of this journey. With your support, I aim to become a Registrar, empowering individuals, organizations, and developers alike.

Together, let's build a brighter future for Phala. Thank you for considering my candidacy, and I am earnestly looking forward to working with all of you in shaping a new frontier of blockchain technology.

Best regards,

Doyle

Proposal for nominating Doyle as a Khala Registrar

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

Hello everybody !
I am a Phala network user for a long time,
I accidentally transferred 8849 Phala from the phala app dashboard to a KSM address.
The system has created a statemine address linked to this KSM address, my 8849 Phala are blocked on this Khala address which does not belong to anyone!
So I propose a force transfer of my 8849 Phala so as not to lose them forever and that no one will ever recover!
i sends you all the transaction links.
Thank you very much Phamily!
My transaction first :
https://khala.subscan.io/extrinsic/3630637-15
The system link the KSM adress and a new Khala Adress :
https://khala.subscan.io/tools/format_transform?input=G4bsXhKHQ4v1o5TRdqRfB2Crvau8qSWAoNcfgKKgDYhs7St&type=Khala
So the new Khala adress with my 8849 phala lock :
https://khala.subscan.io/account/44757Jrc3YZGPSQSnYU6EQU6xWb8fy55T8tHtpKkeACMjxAU


Untitled - public proposal #21

[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

**To speed up the process of the proposal entering the referendum stage, we used a motion for pre-acceleration, so the referendum generated by this proposal is invalid. 
Please all go [here](https://khala.subsquare.io/democracy/referendum/89) to vote for the referendum, and the voting deadline is block #3,719,805.**

This proposal has also been discussing on community forum: https://forum.phala.network/t/proposal-launch-gemini-tokenomics-on-phala-and-enable-support-for-phat-contract/3860

## TLDR
This proposal seeks to establish and implement Gemini Tokenomics on the Phala network. Through this implementation, the Phat Contract will have access to the computing power of the Phala network. This upgrade will align the Phala network’s functional modules with those of the Khala network, enabling the community to deploy workers on Phala and earn computing power rewards comparable to those on the Khala network. Additionally, delegators can participate in staking on Phala. Overall, this upgrade will activate the Phala network and encourage more usage, providing ecosystem support for the growth of Phat Contract.

## Features details
### Update 1: A fully functional Phala network
Following this upgrade, all the features that have already been implemented on the Khala network will now be available on the Phala network. This includes the staking mechanism, worker deployment via solo scripts or PRB, Delegation NFT, and compounding mechanisms in StakePool and Vault. Additionally, the Phala app will be updated in accordance with these changes.

### Update 2: Independent components for computing provider
We plan to offer unique computing power supply tools for the Phala network, designed specifically to meet its distinct needs (support Phat Contract). These tools will feature a range of updates and improvements, such as introducing a new pRuntime V2 component, an updated version of PRB, and a collaborative community contribution in the form of the “Phala solo script”. These new Phala components won’t be available on the Khala network, and we’re confident it will greatly enhance the performance and capabilities of the computing power on the Phala network.

### Update 3: Budget Balancer to makes Gemini tokenomics work (execute in Phat Contract)
To ensure the integrity of the Gemini Tokenomics and to guarantee the equitable distribution of rewards across both the Khala and Phala networks, we have developed a budget balancer functionality through Phat Contract.

This functionality serves to dynamically adjust budget parameters on both chains in real-time by factoring in the total computing power and block speed on each chain. By doing so, the balancer ensures that the computing power reward budget is balanced, thereby achieving consistency in the distribution of rewards across both chains.

### Update 4: Phat Contract launches on Phala
Phat Contract mainnet is scheduled to launch on Phala shortly after integrating with Gemini Tokenomics, a unique feature that is only available on Phala Network. The new pRuntimeV2 facilitated the occurrence of this function.
Our team plans to launch the first cluster in April.

## Key points to this upgrade
### 1. Why we launch Phat Contract on Phala Network?
Phala is an ideal choice for the growth of Phat Contract due to several reasons.

Firstly, launching Phat Contract can help us get massive adaption for use-cases. Phala is a parachain of Polkadot, which means that it has the potential to leverage the benefits of being part of a larger ecosystem, and developers can more easily access Phat Contract on the Phala network. So that Phala has a more robust and well-developed ecosystem, providing more opportunities for Phat Contract’s growth and innovation than Khala.

Secondly, Phala team should ensure the successful deployment of Phat Contract in the main network with limited human resources first.

Therefore, we have decided to focus on developing Phat Contract on the Phala network.

### 2. Why should we provide computation power on Phala instead of just Khala?
First of all, it takes fewer Hardware costs on Phala. The block number on both Polkadot and Phala is much less than Kusama and Khala, and the historical data is almost nonexistent, which means that less hard disk space and synchronization speed are required when providing computing power on Phala. This is very friendly to newcomers and computing power providers with limited device resources.

At the same time, the fast synchronization function exclusive to pRuntimeV2 will further reduce the time required to finish synchronization.

Finally, only workers on the Phala network will have the opportunity to provide computing power for Phat Contract this year, which will be the most important point.

### 3. Workers with the same status on both Khala and Phala will receive the same reward within a day.
To further elaborate, the budget balancer feature ensures that workers on both Khala and Phala networks receive equal rewards for maintaining consistent states(depending on its “V” value). This essentially means that the computing power reward offered by each network becomes irrelevant when deciding where to provide computing power, as it will not have any impact on the expected earnings of the worker. Therefore, computing providers can make their decision solely based on other factors, such as availability and requirement, without having to worry about the potential impact of the chain’s computing power reward on their earnings.

### 4. No need to do any upgrade operations on the workers on Khala.
If your worker is currently operating without difficulty on the Khala network, there is no need for you to take any action for this upgrade. The purpose of this upgrade is actually on the Phala network. It should have no impact on the maintenance and operation of workers on the Khala network except for the budget balancer. However, there is some positive news to be shared as part of this upgrade: the node client will also be upgraded, which will benefit both the Phala and Khala networks. This upgrade has been designed to fix all previously known node bugs, including the “block body not found” error.

If your worker is currently operating without difficulty on the Khala network, there is no need for you to take any action for this upgrade. Essentially, this is an upgrade for the Phala network. The only impact on the Khala network will be the budget balancer, which is unrelated to worker operation and maintenance.

However, there is positive news to be shared as part of this upgrade: we will also be upgrading the node client during this upgrade, which will benefit both Phala and Khala networks. This node upgrade has been designed to fix all previously known node bugs, including the “block body not found” error. You have the option to manually upgrade the image version of the node to implement this upgrade.

### 5. After this upgrade, Phat Contract is still not supported by computing power from the community.
In addition to deploying workers, there are multiple necessary steps for workers to provide computing power for Phat Contract, which are not covered in this upgrade. As a result, we can only support workers being deployed to the Phala network and starting to earn awards; we are currently unable to assist community workers in supporting Phat Contract.

Thus, the Phala team will supply the computing power for workers on the Phat mainnet. As the “Pay for Cloud Service” aspect of the tokenomics has not been initiated, the computing power we furnish will be free of charge.

In Q2, we will continue to develop the necessary components to enable community workers to provide support to Phat Contract on the Phala network.

## Timeline
Due to the extensive nature of the content that needs to be upgraded to Phala this time, we cannot currently provide an exact timeline.
However, all upgrades will be voted on and implemented through on-chain motions to ensure transparency and decentralization. The specific schedule for these motions is as follows:

- **Motion 1** Upgrade Phala & Khala to 0.9.39 (in process)
- **Motion 2** Upgrade Phala & Khala to 0.9.40
launch all pallets to Phala but disable them first
upgrade the node version
launch the function of budget flexible adjustment
- **Motion 3** On-chain configuration for the pallets
    - Create wPHA on Phala
    - pRuntime v2 registry
    - Genesis hash registry
    - Tokenomics parameters
- **Motion 4** Move the balance of computing rewards from the Ethereum mining subsidy account to the Phala subsidy pool by SubBridge
- **Motion 5** GK registry
- **Motion 6** Enable all pallets
- **Motion 7** Cluster configuration
- **Motion 8** Gemini balancer registry and start its work

Our team will take a cautious approach to implementing this huge upgrade. To streamline the process, we will set a tiny computing rewards budget parameter within the Phala network to serve as testing grounds for deployment and reward distribution functions. After successfully conducting these tests, we will construct the budget balancer between the Khala and Phala networks to ensure that the upgrade has minimal impact on the Khala network.

Democracy Referenda