Phala Network Docs
IntroductionDevelopersCompute ProvidersPHA Token
Ask or search…
⌃K
Links
Comment on page

Gemini Tokenomics (Worker Rewards)

This document contains the Supply-end Tokenomics for Phala Network, which defines how workers get their rewards by sharing the computing power.
To read about how Demand-end users can stake PHA to use the network, see Stake to Compute.
After the approval of the “Gemini Tokenomics upgrade" democratic referendum on the block height #1,467,069, we have updated the content of the Supply-end Tokenomics as follows:

Design Targets

The overall economic design is built to address these points:
  1. 1.
    Support Phala Network’s trustless cloud computing architecture
    • Consensus-Computation Separation
    • Linearly-scalable computing workers (100k order of magnitude number of workers)
  2. 2.
    Incentivize workers to join the network
    • Ensure payment for power supplied irrespective of demand, especially at network bootstrap
    • Subsidize mining pool with 70% of the initial supply over time
    • Bitcoin-like budget halving schedule
    • Power the Phala and Khala at the same time
  3. 3.
    Application pricing
  4. 4.
    On-chain performance
The following details some key elements of the economic model.

Overall Design

Phala Supply-end Tokenomics applies to any workers running on Phala or Khala.

Value Promise
(V)(V)
​

  • A virtual score for an individual worker representing value earned which is payable in the future, to motivate workers to behave honestly and reliably
  • Equal to the expected value of the revenues earned by the worker for providing power for the platform
  • Changes dynamically based on the worker’s behaviors and the repayment of Rewards
    • Mining honestly:
      VV
       grows gradually over time
    • Harmful conduct: punished by reduction of
      VV
      ​

Initial
VV
​

A Worker will run a Performance Test and stake some tokens to get the initial
VV
:
Ve=f(Re,ConfidenceScore)×(S+C)V^e = f(R^e, \text{ConfidenceScore}) \times (S + C)
  • ​
    Re>1R^e > 1
     is a Stake Multiplier set by the network (Khala or Phala).
  • ​
    SS
     is the worker stake; a Minimum Stake is required to start mining. The stake can’t be increased or decreased while mining, but can be set higher than the Minimum.
  • ​
    CC
     is the estimated cost of the worker rigs, inferred from the Performance Test.
  • ​
    ConfidenceScore\text{ConfidenceScore}
     is based on the worker’s Intel© SGX capabilities.
  • ​
    f(Re,ConfidenceScore)=1+(ConfidenceScore⋅(Re−1))f(R^e, \text{ConfidenceScore}) = 1 + (\text{ConfidenceScore} \cdot (R^e - 1))
    ​
  • ​
    VV
     is always less than or equals to
    VmaxV_{max}
    .
Params used in simulation:
  • ​
    RPhalae=RKhalae=1.5R^e_{\text{Phala}} =R^e_{\text{Khala}} = 1.5
    ​
  • ​
    ConfidenceScore\text{ConfidenceScore}
     for different Confidence Levels
    • ​
      ConfidenceScore1,2,3=1\text{ConfidenceScore}_{1,2,3} = 1
      ​
    • ​
      ConfidenceScore4=0.8\text{ConfidenceScore}_{4} = 0.8
      ​
    • ​
      ConfidenceScore5=0.7\text{ConfidenceScore}_{5} = 0.7
      ​
  • ​
    Vmax=30000V_{max} = 30000
    ​

Performance Test

A performance test measures how much computation can be done in a unit of time:
P=IterationsΔtP = \frac{\text{Iterations}}{\Delta t}
For reference,
Platform
Cores
Score
Approximate Price
Low-End Celeron
4
450
$150
Intel Xeon E Processor
6
1900
$500
Mid-End i5 10-Gen
8
2000
$500
High-End i9 9-Gen
10
2800
$790
The table is based on the version while writing of this documentation and is subject to changes.
The performance test will be performed:
  1. 1.
    Before mining to determine the Minimum Stake
  2. 2.
    During mining to measure the current performance, and to adjust the $V$ increment dynamically

Minimum Stake

Smin=kPS_{min}=k \sqrt{P}
  • ​
    PP
     - Performance Test score
  • ​
    kk
     - adjustable multiplier factor
Proposed parameter:
  • ​
    kPhala=kKhala=50k_{\text{Phala}} =k_{\text{Khala}} = 50
    ​
Locked state $PHA token can also be used for mining staking, e.g., Khala Crowdloan reward

Cost

C=0.3PϕC = \frac{0.3 P}{\phi}
  • ​
    ϕ\phi
     is the current PHA/USD quote, dynamically updated on-chain via Oracles
  • ​
    PP
     is the initial Performance Test score.
  • In the early stages, we are compensating the equipment cost
    CC
     with a higher Value Promise.
  • In the future, we plan to compensate for higher amortization costs (adding equipment amortization cost to the running costs
    cic^i
     and
    cac^a
    ), thus increasing the speed of growth of the Worker’s
    VV
    .

General mining process

Each individual’s
VV
 is updated at every block:
  • Increased by
    ΔVt\Delta V_t
     if the worker keeps mining
  • Decreased by
    w(Vt)w(V_t)
     if the worker got a payout
  • Decreased according to the Slash Rules if the worker misbehaves
When a worker gets a payout
w(Vt)w(V_t)
, they will receive the amount immediately in their Phala wallet. The payout follows Payout Schedule and cannot exceed the Subsidy Budget.
Finally, once the worker decides to stop mining, they will wait for a Cooling Down period $\delta$. They will receive an one-time final payout after the cooldown.
Block number
$t$
$t+1$
$\dots$
$T$
$\dots$
$T+\delta$
Value Promise
$V_t$
$V_{t+1}$
$\dots$
$V_T$
$\dots$
$\dots$
Payment
$w(V_t)$
$w(V_{t+1})$
$\dots$
$w(V_T)$
$0$
$\kappa \min(V_T, V^e)$
​
Block reward
…
…
Block reward
Cooling off for $\delta$ blocks
Final payout
Proposed parameter:
  • ​
    δ=blocks equivalent to 7 days\delta = \text{blocks equivalent to 7 days}
    ​

Update of
VV
​

When there’s no payout or slash event:
ΔVt=kp⋅((ρm−1)Vt+c(st)+γ(Vt)h(Vt))\Delta V_t = k_p \cdot \big((\rho^m - 1) V_t + c(s_t) + \gamma(V_t)h(V_t)\big)
  • ​
    homho^m
     is the unconditional
    VV
     increment factor for worker
  • ​
    c(st)c(s_t)
     is the operational cost to run the worker
  • ​
    γ(Vt)h(Vt)\gamma(V_t)h(V_t)
     represents a factor to compensate for accidental/unintentional slashing (ignored in simulated charts)
  • ​
    kp=min⁡(PtP,120%)k_p = \min(\frac{P_t}{P}, 120\%)
    , where
    PtP_t
     is the instant performance score, and $P$ is the initial score
  • If
    V>VmaxV > V_{max}
     after the update, it will be capped to
    VmaxV_{max}
    ​
Proposed parameters:
  • ​
    hoPhalam=ρKhalam=1.00020ho^m_{\text{Phala}} =\rho^m_{\text{Khala}} = 1.00020
     (hourly)

Payout Event

In order to stay within the subsidy budget, at every block the budget is distributed proportionally based on the current Worker Shares:
w(Vt)=BshareΣsharew(V_t) = B \frac{\text{share}}{\Sigma \text{share}}
where
BB
 is the current network subsidy budget for the given payout period.
Whenever
w(Vt)w(V_t)
 is paid to a worker, his
VV
 will be updated accordingly:
ΔV=−min(w(Vt),Vt−Vlast).\Delta V = -min(w(V_t),V_t-V_\text{last}).
​
VlastV_\text{last}
 is the value promised at the last payout event, or
VeV^e
 if this is the first payout.
The update of V is limited to ensure the payout doesn’t cause
VV
 to drop lower than it was in the last payout event. The limit is necessary to make sure workers are well incentives to always accumulate credits in the network. Otherwise, workers are incentivized to constantly reset their mining session if V decreases over time.
Share represents how much the worker is paid out from
VV
. We expect it will approximate the share baseline, but with minor adjustments to reflect the property of the worker:
shareBaseline=Vt.\text{share}_{\text{Baseline}} = V_t.
​
Σshare\Sigma \text{share}
 contains the share of workers which are running on Phala or Khala with the same subsidy ratio.
Proposed algorithm:
  • ​
    shareKhala=Vt2+(2Pt⋅ConfidenceScore)2\text{share}_{\text{Khala}} = \sqrt{V_t^2 + (2 P_t \cdot \text{ConfidenceScore})^2}
    ​
  • ​
    sharePhala=Vt2+(2Pt⋅ConfidenceScore)2\text{share}_{\text{Phala}} = \sqrt{V_t^2 + (2 P_t \cdot \text{ConfidenceScore})^2}
    ​
  • ​
    PtP_t
     is the instant performance score

Subsidy Budget

Text
Phala / Khala
Relaychain
Polkadot/ Kusama
Budget for Mining
700 mln
Halving Period
180 days
Halving Discount
25%
Treasure Share
20%
First Month Reward
21.6 mln

Heartbeat & Payout Schedule

In any block
tt
, if the Worker’s VRF is smaller than their current Heartbeat Threshold
γ(Vt)\gamma(V_t)
, they must send the Heartbeat transaction to the chain, which will update the on-chain record of their Value Promise and send a Mining Reward
w(Vt)w(V_t)
 to their reward wallet:
ΔVt=−w(Vt).\Delta V_t = - w(V_t).
If they fail to send the Heartbeat transaction to the chain within the challenge window, the update of their value promise will be
ΔVt=−h(Vt).\Delta V_t = - h(V_t).
and their status is changed to unresponsive, and they will get repeatedly punished until they send a heartbeat, or stop mining. The slash amount
hh
 is defined in the Slash section.
The target is to process around 20 heartbeat challenges per block. The heartbeat challenge probability
γ(Vt)\gamma(V_t)
 will be adjusted to target this number of challenges.
Potential parameters:
  • ​
    ChallengeWindow=10\text{ChallengeWindow} = 10
     (blocks)

Slash rules

The slash rules for workers are defined below. No slash rules have been implemented at the moment but will start in the near future.
Severity
Fault
Punishment
Level1
Worker offline
0.1% V per hour (deducted block by block)
Level2
Good faith with bad result
1% from V
Level3
Malicious intent or mass error
10% from V
Level4
Serious security risk to the system
100% from V

Final payout

When a worker chooses to disconnect from the platform, they send an Exit Transaction and receive their Severance Pay after
δ\delta
 blocks.
After the cooling down period, the worker gets their final payout, representing the return of the initial stake. However, if
VTV_T
 goes lower than the initial
VeV^e
, the worker will get less stake returned as a punishment:
w(T+σ)=min⁡(VTVe,100%)⋅Sw(T + \sigma) = \min(\frac{V_T}{V^e}, 100\%) \cdot S
where
SS
 is the initial stake.
Previous
Introduction
Next
Budget balancer
Last modified 5mo ago