Proposal #20
invalid referendum

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 to vote for the referendum, and the voting deadline is block #3,719,805.

This proposal has also been discussing on community forum:


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.


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.

No current seconds
This proposal has been turned into referendum.
  • Call
  • Metadata
  • Timeline2
There are no comments here