Proposal: Phala Mining Tokenomic Launch
TLDR:
The proposal is aim to seperate the Phala Mining Reward tokenomic from relaychain, it means that PHA token reward to workers will based on TOTAL workers’ ammount from both Phala and Khala, not bonded with either parachain. By merging reward pools, this Gemini Upgrade will help Secure Workers get more rewards on Kusama first, and give free choice to workers to decide if they want to run on Phala or Khala with a same subsidy ratio.
Gemini Update: Merge Khala and Phala
Back in 2021, Khala Network was born as the pre-mainnet of Phala Network to test its tokenomic and the technology. Instead of having two token, the Phala community decided to share the same PHA token on the both sides. It immediately raise a problem: How can the single token power the two blockchains at the same time?
When Khala was launched, to test the mining subsystem and the tokenomic, there’s 1% of the token allocated to Khala dedicated for Secure Worker Mining, while 69% is reserved for Phala mining. From the tokenomic whitepaper (link), we have a different set of parameters for the two chains to define the mining subsidy budget, staking requirements, and reward schedule.
Compared with Phala, Khala has a much smaller subsidy allocation and faster halving schedule, because the basic assumption is that Khala is for testing, and Phala is for production usage. There’s also the understanding in the the community that Khala will only be kept for small scale testing, or can even be shutdown once the test is finished.
In old model:
- Assume 500 workers on Khala, 2k workers on Phala.
- Assume daily reward for Khala is 60k, daily reward for Phala is 720k
- Per Worker daily reward on Khala is 120 PHA, on Phala is 360 PHA
However, Khala may not be just a testbed. We have seen innovative projects built natively on Kusama with prosperity. The real native projects on Kusama may grow to an ecosystem with full of vitality different than Polkadot. Phala Networks, as the Web3 Cloud, should provide the computing resources everywhere with the demand. We definitely don’t want to miss the growing Kusama ecosystem.
If we want to equally treat the Phala parachains on Kusama and Polkadot, now it’s a good time to reconsider the mining tokenomic and the allocation between Khala and Phala. In the reamining part of this post, we are going to propose a way to unify Khala and Phala tokenomic.
Gemini Update 1: Merge Khala & Phala reward pools
The aim of the tokenomic is to properly reward the miners on both Khala and Phala to meet the computation demand on the both sides. So instead of setting the predefined allocation on the both sides, the subsidy pool and the reward schedule should be shared on the both blockchains. The actual reward at a given time can be dynamically adjusted based on the on-chain metrics to reflect the demand on the blockchain.
In this setup, the mining reward on the both blockchains should finally converge to the same level. If one blockchain has more demand than another, the mining reward on this chain should increase to attract miners from another side. As a result, the computing resources between the two chains will be balanced dyanmically.
Gemini Update 2: Unify the staking and value promised parameters
To implement such a system, the two blockchains should share all the parameters (including stake requirement, halving schedule, and the value promised related params) except the subsidy budget. Instead of maintaining two block subsidy separately, there should be an unified subsidy pool shared in the two blockchains. Each chain only get a protion of the full mining subsidy budget, and the sum of that on the two chains should equal to the unified budget, at any point.
Gemini Update 3: Measure the demands
The demand can be measured by different metrics, e.g. the used and the claimed computing resources on the blockchain, which is to be determined later. However, before there’s real application running on the blockchain, we can still use the total available computing resources (or the number of miners) on the blockchain as an estimation of the demand measurement.
After the launch of Fat Contract, we expect workers can get extra rewards by been chosen to run fat contracts. The reward budget on the both sides will be balanced based on the demand (on Polkadot and Kusama). This creates an incentive to drive the miners to move to the chain with more demand by their free choice. Eventually, the reward each miner can receive should converge to a fair level.
Gemini Update 4: Implementation
To maintain the subsidy budget on the two chains, a bridge between the two chains is required. We call the automatic operation to balance the two chains “Balancing Process”. The Balancing Process should happen periodically (e.g. once per day). Once the two blockchains are connected, Phala Network (the parachain on Polkadot) should be responsible to lead the Balance Process, in which it collects the demand metrics from Khala (via the bridge), and determine the split of the subsidy budget, and then assign the new subsidy budget for the next period. The deployment of the new budget can be done by the bridge as well.
Since the only different on the two chains is the subsidy budget, we can reuse most of the tokenomic implementation we have right now. While adjusting the subsidy, the bridge should also be used to move the PHA between the subsidy pools on the two chains to ensure there’s enough token.
Once the Kusama-Polkadot bridge is deployed, we can use XCM to bridge the two parachains more safely.
Gemini Update 5: Parameters and details
Updated subsidy budget
| Total | Geminine | Legacy Khala | Legacy Phala | |
|---|---|---|---|---|
| Relaychain | / | Polkadot & Kusama | Kusama | Polkadot |
| Budget for Mining | 700 mln | 700 mln | ||
| Halving Period | / | 180 days | ||
| Halving Discount | 25% per period | 25% | 25% | 25% |
| Treasure Share | / | 20% | 20% | 20% |
| First Month Reward | / | 21.6 mln |
Besides the mining subsidy, the other tokenomic parameters generally follows Khala’s since it has been running stable for the last a few months:
- Stake multiplier: Re = 1.5
- Minimum stake multiplier factor: k = 50
- Unconditional V increment factor: rho = 1.00020 (hourly)
Beyond the parameters, we propose the following changes to improve the mining experience:
- Allow to increase stake without a full stop: In the past, to change the stake you have to stop the miner, wait 7 days, and restart the miner. The tokenomic requires a delay period exists before the withdrawal of the stake, but it’s not necessary to have it when increasing the stake. So in this change, we can allow stake pool owners to increase the stake for a miner without the miner to stop and wait for 7 days. In this process, V will be reset because it’s equivalent to a stop followed by a restart without the waiting period.
- Calibrate the mining subsidy to match the block time: In the past, the actual block time of the parachains used to be significantly longer than the standard value (12s). It causes the miners get much smaller reward. We should adjust the reward budget to compensate the misalignment.
- (Work in Progress) Revise the other parameters, especially the discount of low confidential level
- Other tokenomic fixes: #680, #638
Examples
The advantage of this proposal is that the subsidy on Phala and Khala is defined by the competition of workers’ ammount on each parachain – there is no longer “mainnet” any more. Even though Phala haven’t launch on Polkadot, all subsidy will send out to online workers.
In new model:
- Assume 5k workers on Khala, 0 workers on Phala when we haven’t launched on Polkadot
- Assume daily reward for the Gemeni pool is 720k
- Then Khala receives 720k PHA daily reward, Phala receives 0 daily reward
- Per Worker daily reward on Khala is 144 PHA
In new model:
- Assume 3k workers on Khala, 5k workers on Phala
- Assume daily reward for the Gemeni pool is 720k
- Then Khala received daily reward as 270k, Phala received daily reward as 450k
- Per Worker daily reward on Khala is 90 PHA
Launch Plan
| Timeline | Action |
|---|---|
| 15th March ~ 20th March | Proposal discussion in community |
| 21th March ~ 28th March | Public Vote for this proposal |
| 29th March ~ 30th March | Tokenomic runtime upgrade (Gemini Upgrade) / Wiki update (If passed) |
| 18th March | Bidding for Polkadot slot auction |
| May | Launch Phala Network on Polkadot (if we win the slot auction) |
