Here,

• I(B,S) = B + S(B)
• S(B) = 0.2 • min(Sc,5) • B, where
• Sc is the count of valid Security Circle connections.
• E(I) = Ec • I(B,S) • 0.25, where
• Ec is the count of active Referral Team members who mine concurrently.

The mining formula can also be written as a multiple of B: 

• M = I(B,S) + E(I)
• M = + , or
• M = + , or
• M = B • , or
• M = B •

Pre-Mainnet Systemwide Base Mining Rate

Every active Pioneer received at least the systemwide base mining rate (B). That is, if Sc = 0 and Ec = 0 in the mining formula above, then M = B. In any case, the total Pioneer mining rate was a multiple of the systemwide base mining rate. The value of B was pre-determined before the Mainnet, and as shown in the table above, it changed only five times. The max supply was undetermined due to the dynamic progress of the pre-Mainnet mining mechanism, e.g. how large the network is and how fast the network reaches the next halving event. It would only be determined when B dropped to 0. However, as explained in the next section, the value of B at Mainnet is calculated in real time, dynamically adjusting based on the total annual Pi supply and the total mining coefficient across all the Pioneers. The supply of Pi is finite at Mainnet.

Security Circle Reward

Pi’s consensus algorithm relies on a global trust graph, which is aggregated from the millions of intertwining Security Circles of individual Pioneers. Thus, a Pioneer was rewarded with additional Pi per hour for each new valid Security Circle connection, up to 5 such connections. The Security Circles are so central to the security of the Pi blockchain that the Security Circle reward raised the total Pioneer mining rate in two ways: 

• by directly adding to the individual Pioneer base mining rate (I), and 
• by boosting the Referral Team reward, if any. 

In fact, a full Security Circle—that is, having at least five valid connections—doubled both the individual Pioneer base mining rate and the Referral Team reward. 

Referral Team Reward

Pioneers can also invite others to join Pi Network and form their Referral Team. The inviter and invitee share an equal split of the Referral Team bonus rewards, that is a 25% boost to their respective individual Pioneer base mining rates, whenever both are mining concurrently. Pioneers mined more Pi per hour with each concurrently mining Referral Team member. This Referral Team reward recognized the Pioneers’ contribution to the growth of the network and the distribution of the Pi token.

Mainnet Mining Formula

The goals of the Mainnet phase are to make further progress in decentralization and utilities, ensure stability and longevity, and retain growth and security. The new formula, as written below, incentivizes more diverse contributions of Pioneers to support these Mainnet goals while retaining the incentives to secure and grow the network. As before, it is meritocratic and expressed as the rate at which Pioneers mine Pi per hour. 

M = I(B,L,S) + E(I) + N(I) + A(I) + X(B), where

• M is the total Pioneer mining rate, 
• I is the individual Pioneer base mining rate, 
• B is the systemwide base mining rate (adjusted based on the available pool of Pi to distribute for a given time period), 
• L is the lockup reward, which is a new component of the individual Pioneer base mining rate,
• S is the the Security Circle reward, which is a component of the individual Pioneer base mining rate from valid Security Circle connections the same way as in the pre-Mainnet mining formula, 
• E is the Referral Team reward from active Referral Team members the same way as in the pre-Mainnet mining formula, 
• N is the Node reward, 
• A is the Pi apps usage reward, and
• X are new types of contributions necessary for the network ecosystem in the future, which will be determined later, but will also be designed as a multiple of B. 

In short, S and E remain the same as in the pre-Mainnet mining formula, while new rewards such as L, N and A  have been added to the current formula. L is added as part of I; N and A are added as additional rewards calculated based on I. In other words, the network still rewards growth through E and security through S, while incentivizing Pioneers’ contributions to running nodes for decentralization through N, using apps for utilities creation through A, and locking up for stability especially during the initial years through L. Further, new types of rewards to Pioneers through X in the future may be added for building a fully functioning ecosystem, such as rewards for Pioneer developers creating successful Pi apps. B continues to exist over a long period of time while having a yearly cap to ensure longevity of network growth bywhile maintaining long-term network incentives. In fact, all the rewards can be expressed in B as follows. 

Here, 

I(B,L,S) = B + S(B) + L(B)

S(B) = 0.2 • min(Sc,5) • B, where

• Sc is the count of valid Security Circle connections.

E(I) = Ec • 0.25 • I(B,L,S), where

• Ec is the count of active Referral Team members.

L(B) = Lt • Lp • log(N) • B, where

• Lt is a multiplier corresponding to the duration of a lockup, 
• Lp is the proportion of Pioneer’s mined Pi on the Mainnet that is locked up with the maximum being 200%, and 
• N is the total number of Pioneer’s mining sessions preceding the current mining session.

N(I) = node_factor • tuning_factor • I, where

• Node_factor = Percent_uptime_last_1_days • (Uptime_factor + Port_open_factor + CPU_factor), where
• Uptime_factor = (Percent_uptime_last_90_days + 1.5*Percent_uptime_last_360_days(360-90) + 2* Percent_uptime_last_2_years + 3*Percent_uptime_last_10_years),
• Port_open_factor = 1 + percent_ports_open_last_90_days + 1.5*percent_ports_open_last_360_days + 2* percent_ports_open_last_2_years + 3*percent_ports_open_last_10_years,
• CPU_factor = (1 + avg_CPU_count_last_90_days + 1.5*avg_CPU_count_last_360_days + 2* avg_CPU_count_last_2_years + 3*avg_CPU_count_last_10_years)/4. 

and

• Percent_uptime_last_*_days/years is the percentage of the last * time period when the individual Node was live and accessible by the network. 
• percent_ports_open_last_*_days/years is the percentage of the last * time period when the ports of the individual Node were open for connectivity to the network.
• avg_CPU_count_last_*_days/years is the average CPU that the individual Node provided to the network during the last * time period. 
• tuning_factor is a statistical factor that normalizes the node_factor to a number between 0 and 10.  

• time_spent_per_app_yesterday_in_seconds is, for each Pi app, the total amount of time in seconds that the Pioneer spends using the app on the prior day.
• Σ_across_apps sums up the logarithmic value of the Pioneer’s time_spent_per_app_yesterday_in_seconds across all the Pi apps. 
• avg_daily_time_spent_across_apps_last_*_days/years is the average daily time in seconds the Pioneer spends across all the Pi apps in the aggregate during the last * time period. 

* Note that when any of the logarithmic functions returns an undefined value or a value below 0 (that is, when, the input to the logarithmic function is below 1), the formula resets the value of the logarithmic function to be 0 in order to avoid negative mining rewards or an error in the function. 

X(B) is to be determined in the future based on the new types of contributions, but will be a multiple of B and kept within the yearly supply limit along with other rewards. 

As shown above, the expressions of S and E remain the same as in the pre-Mainnet mining formula, and will not be explained further here. Next, we will focus on explaining the changes to B, changes to I through L, and the additions of N and A.

Systemwide Base Mining Rate

Like in Pre-Mainnet mining, all of the terms in the Mainnet mining formula above can be expressed in Pi per hour and are designed to be a multiple of B. Hence, the equation can also be re-written as below. Every Pioneer can mine at least the Systemwide Base Mining Rate everyday, and will be able to mine at a higher rate if they also have other types of contributions that are calculated as multiples of B.

M = B • (1 + S + L) • (1 + N + E + A + X)

Unlike in the pre-Mainnet mining, B in Mainnet mining as in the formula above is no longer a constant across all Pioneers at a given point in time, but is calculated in real time and dynamically adjusted based on a yearly supply cap. 

Given a yearly supply limit, it is impossible to keep a constant B like in the pre-Mainnet period because it’s unpredictable how much each Pioneer mines and how many Pioneers are actively mining during a period of time. The pre-Mainnet model was designed to incentivize growth during the beginning years to bootstrap the network. As the network achieves a certain scale, it also needs to ensure the overall health of the ecosystem. Therefore, an exponential issuance of the tokens through exponential network growth and a constant mining rate does not make sense any longer. The shift of B from being a constant to being dynamically adjusted for a certain period of time throughout the year results from the need to incentivize Pioneers’ contributions meritocratically but also to keep the total rewards within a limit. 

The time period for adjusting B could be yearly, monthly, daily, hourly, or even more granular. Pi Network will iterate on this time period over time based on careful monitoring and review.

The first version of the Rewards Issuance Formula was announced March 1st 2022—the declining exponential function described below—whereby in combination with mining activities, the systemwide base mining rate (B) is adjusted based on a monthly supply limit determined by the formula. 

Please note that the declining exponential formula below is the first version of the Rewards Issuance Formula, as it is impossible to precisely predict the future data on Mainnet and from new mining. This first version was designed based on past data, simulations and best assumptions, such as the 35 billion remaining supply for future mining rewards, Pioneer lockups and overall ecosystem factors. For example, the 35 billion remaining Pi is estimated based on the currently available data about real Pioneers’ mobile balances. A more accurate figure will be determined by the speed of network KYC and how much Pi is migrated to the Mainnet in the future. Further data and continual simulations will help assess such underlying assumptions in the rewards issuance formula, and thus may lead to the formula’s adjustment in line with the network’s objectives.

supply_limits (expressed in Pi/day)  = exp (–last_day_total_mining_rewards / 1220) • 35,000,000,000, where 

• supply_limits are the output of this formula that allocates a specific amount of Pi to each day for the indefinite time while making sure the total future issuance will not exceed the remaining available supply,
• last_day_total_mining_rewards is equal to the total Pi mining rewards issued on the previous day,
• 1220 is a tuning factor to be further tuned over the coming months, and
• 35 billion is the estimated number of Pi available for Pioneers to mine going forward. 

This monthly B means that that B will stay constant for a month and will be adjusted based on the rewards issuance formula and the network’s mining activities at the end of each month. Starting with a B that stays constant for a month helps Pioneers understand the implications of 1) new supply limits, 2) the new mining mechanism with new rewards, and 3) a more dynamic nature of B (potentially in the future) one at a time, given that these concepts are complex and all have an effect on Pioneers’ mining rewards. At the same time, a monthly period is short enough to correct any potential over- or under-issuance of Pi deviating from the rewards issuance formula while B is stable long enough for Pioneers to follow along and adjust their contributions to the network to mine for rewards. 

Each month’s B is calculated based on the supply limit for the month based on this formula and the sum of all reward coefficients of all active Pioneers from the last day of the previous month. This B updates again on the first day of every month. 

More specifically, the value of B for a given month is calculated by:

• Summing up the daily supply_limits for the month from the above rewards issuance formula
• Dividing it by the number of days in the month for even daily allocation within the month 
• Dividing it again by the sum of coefficients (sum_of_B_multiples) of mining rewards of all active Pioneers of the last day of the previous month—including their multiples of Referral Team, Security Circle, Pi Lockup, App usage, and Node Operation rewards 

Similar iterations occur each month.

When B stays constant in a month, the total number of Pi actually mined every month varies with the total number of actively mining Pioneers and the contributions they make in that month. At the end of the month, the total number of Pi actually mined will be compared with the number initially projected by the formula. Any deviation between the two numbers each month will lead to a further adjustment on the remaining Pi supply, across the remaining indefinite mining period, along with any other types of adjustments explained above, e.g. the assumed 35 billion remaining mining rewards supply. 

As such, the monthly B can potentially cause an overissuance of Pi when there is an unexpected increase in the number of Pioneers and their mining rates, leading to a deviation from the rewards issuance formula. If such deviation on a monthly basis is constantly large, the network can move to a more dynamic version of the B model where the monthly issuance of Pi remains constant but B gets adjusted on a more granular time epoch basis. The shorter the time period for adjusting B to follow the formula, the less is the potential for over- or under-issuance against the targeted supply limits, and the less is the chance for deviation from the formula over that period. More data on Mainnet and the new mining mechanism will help examine the efficacy of the current monthly dynamic B and determine if a more dynamic version B is necessary. 

For example, if the B is calculated daily, instead of the current monthly version, for a given day of the year, 

B = day_supply / (sum_of_B_multiples • 24h)

• Divide the remaining total Pi supply of the year by the number of days left in the year to get day_supply based on the remaining yearly supply,
• Add the multiples of B from all Pioneers actively mining within the last 24 hours, which represents a diverse set of Pioneers’ contributions, in the Mainnet mining formula above to get the sum_of_B_multiples of the whole network for that 24-hour window, and 
• Further divide day_supply by sum_of_B_multiples and 24 hours to get B of that specific mining session.

Under this potential framework with a day as the unit of time for adjustment, B on different days of the year will be different depending on how many Pioneers mined in the last 24 hours as well as what and how much contributions they made to receive the extra multiples of B by running nodes, using utilities apps or lockups, etc. Each Pioneer’s B of their day stays constant through their mining session, that is, over the next 24 hours from the moment they start their mining session. 

This model, whether it is monthly, daily or by more granular time periods, also addresses any uncertainty with having X(B)—future types of contribution rewards for Pioneers—in the formula. Regardless of how much X is going to be, it will be kept within the same yearly supply limit without increasing the total supply and will only affect the division of rewards among different types of contributions. This dynamic mechanism allows Pioneers themselves, in a decentralized way, to make sure that (1) the rewards do not exceed the yearly supply limit, (2) the distribution of the yearly supply does not end early in the year, and (3) the rewards are divided meritocratically.  

For purposes of illustration, let’s suppose there are only two Pioneers on a given day and B is the daily mining rate (expressed in Pi/day for this illustration)—a constant during a specific Pioneer mining session, but dynamically adjusted across different days:

• Pioneer 1 has no app engagement (A=0), is not operating a Node (N=0), has no security connections (S=0), and has no active Referral Team members (E=0). They are in their 11th mining session (N=10) and are locking up 100% of their mined Pi (Lp=1) for 3 years (Lt=2). Pioneer 1’s mining rate on this day is: 

                 M1 = I(B,L,S) + 0 + 0 + 0, or

                  M1 = B + {2 • 1 • log(10)} • B + 0, or

                  M1 = 3B

• Pioneer 2 has no app engagement (A=0), is not operating a Node (N=0), has no lockup (L=0), and has no active Referral Team members (E=0). They have a full Security Circle. Pioneer 2’s mining rate on this day is: 

                  M2 = I(B,L,S) + 0 + 0 + 0, or

                  M2 = B + 0 + {0.2 • min(Sc,5) • B}, or

                  M2 = B + {0.2 • 5 • B}, or

                  M2 = 2B

• Here, Total Pi to be mined in the whole network on this day = M1 + M2 = 5B
  Let’s assume there are 500 Pi and 50 days left in the year.
  Therefore, Total Pi available to be mined for this day = 500 Pi / 50 days = 10 Pi/day
• Solving B based on the two equations above, 

                  5B=10 Pi ⇒ B = 2 Pi/day (or 0.083 Pi/hour)

• Accordingly, Pioneers 1 and 2 will have their actual mining rates as follows:

                  M1 = 3 • 2 Pi/day = 6 Pi/day (or 0.25 Pi/hour)

                  M2 = 2 • 2 Pi/day = 4 Pi/day (or 0.17 Pi/hour)

Pioneer Base Mining rate

By comparison, the individual Pioneer base mining rate in the pre-Mainnet mining formula includes only system-wide base mining rate and Security Circle rewards. At Mainnet, a new component, lockup reward, is added to individual Pioneer base mining rate I. Lockup rewards L, along with the system-wide base mining rate B and Security Circle reward S, constitute the individual Pioneer base mining rate I. Since I is used as an input to calculate all the other rewards,  as a result, the Security Circle and lockup rewards enhance the total Pioneer mining rate by: (1) by directly adding to the individual Pioneer base mining rate and (2) by boosting the any Referral Team reward E, nodes reward N, and app usage reward A.

Lockup Reward

At Mainnet, the lockup reward is meant to support a healthy and smooth ecosystem and incentivize long-term engagement with the network, while the network is bootstrapping and creating utilities. It is an important decentralized macroeconomic mechanism to moderate circulating supply in the market, especially in the early years of the open market when utilities are being created. One important goal of the Pi Network is to create a utility-based ecosystem of apps. Transactions for real goods and services in the ecosystem, rather than just speculative trading, are intended to determine the utility of Pi. As we launch the Enclosed Network phase of the Mainnet, one of the main areas of focus will be to support and grow the Pi app developer community and nurture more Pi apps to grow. In the meantime, Pioneers can choose to lock up their Pi to help create a stable market environment for the ecosystem to mature and for more Pi apps to emerge and provide compelling use cases for spending Pi – to ultimately create organic demands through utilities.

The lockup reward formula is reprinted here:

• L(B) = Lt • Lp • log(N) • B, where 

                  Lt is the Lockup Time period multiplier of B.

                           0              → Lt = 0

                          2 weeks   → Lt = 0.1 

                           6 months → Lt = 0.5  

                           1 year      → Lt = 1    

                           3 years    → Lt = 2 

• Lp is the Lockup Percentage multiplier of B, where
  • the Lockup Percentage is the lockup amount over the Mainnet Balance transferred from one’s previous mining rewards (Lb), and the Lockup Percentage multiplier is as follows.

         0% → Lp = 0

         25% → Lp = 0.25 

         50% → Lp = 0.5

         90% → Lp = 0.9

         100% → Lp = 1.0

         150% → Lp = 1.5

         200% → Lp = 2

• log(N) is the logarithmic value of the total number of previous mining sessions (N).

Pioneers will have the opportunity to voluntarily lock up their Pi to earn the right to mine at a higher rate. First of all, the prerequisite of the lockup reward is that the Pioneer must be actively mining. Without mining in the first place, there will be no lockup rewards for any inactive mining sessions, even if Pi is locked up. As expressed in the formula above, all that the lockup does is to provide multipliers to B, so there will be no lockup rewards if B is 0 (which means the Pioneers is not mining). 

Secondly, the lockup reward is positively associated with the contribution to the lockup, i.e. the duration of the lockup time period (Lt) and the amount locked up. However the lockup amount is accounted for by the percentage of a Pioneer’s total Pi mined (Lp). The maximum Pi that a Pioneer can lock up is twice as much as their Mainnet Balance that got transferred from their prior mining in the mobile app (Lb), i.e. 200% Lb. The reasons for having a 2X maximum lockup amount of one’s transferred Mainnet Balance (Lb) are to 1) prevent exploitation of the lockup reward and 2) further encourage other contributions to the Pi ecosystem, such as further boosting their mining, running nodes and using apps. This, in a sense, favors Pioneers who mine and make other types of contributions to the network. 

Thirdly, Log(N) offers a higher lockup incentive to Pioneers who have a long mining history and presumably a large transferable balance to lock up. While the lockup reward formula generally favors equality by accounting for not the absolute amount but the percentage of their transferred balance (Lp) — which allows smaller accounts with a short mining history to lock up small amounts and yet receive the same lockup reward multiplier as big accounts — we need to add a Log(N) factor that accounts for miners with a long mining history, to counterbalance the bias in favor of Pioneers with small balances and provide enough incentive for long-history Pioneers with bigger balances. However, the effect of mining history on lockup rewards also needs to be capped. Thus, the formula applies a logarithm to the number of previous mining sessions N. For example, if a Pioneer mined almost everyday for the last 3 years, their total previous mining sessions (N) will be about 1,000. In this scenario, Log(1,000) equals 3, adding another multiplier to B in their lockup rewards. Keep in mind that to achieve meaningful lockup rewards for long-mining-history Pioneers, the amount of Pi they have to lock up is much more than smaller accounts. Fourthly, one Pioneer can voluntarily have multiple lockups at different times with different amounts and durations. The calculation of the total lockup rewards for this Pioneer with i number of different lockups is to find the total lockcup reward multiplier of B, as expressed in the formula below. The formula below is the equivalent to the lockup reward formula above, with the only difference being that it accounts for multiple lockups of the same Pioneer to calculate their total lockup rewards, e.g. different durations (Lti) and different amounts (Lci) of each lockup at different time:

The purpose of this formula is to calculate the total lockup rewards based proportionally on each lockup’s amount (Lc) over the total Mainnet Balance from previous mining (Lb) as a weight, multiplied by their respective lockup time period (Lt) and Log(N). So that, even though there are multiple lockups of the same Pioneer, more lockups with different settings will proportionally add to their total lockup rewards. The values of Lt, Lc, and log(N) are calculated and multiplied for each lockup i and then summed across various i’s, which is then divided by the value of Lb at a given mining session, to arrive at the value of L(B) for that mining session. This formula ensures that regardless of the Lb, as long as the Pioneer maintains the same percentage of their lockup amount over their Lb, the total lockup rewards multiplier will remain the same. 

Lastly, when can a Pioneer lock up Pi? Pioneers can decide their lockup duration and lockup percentage of their transferable balance anytime they want as an overall account setting in the Pi app. They can even preselect these settings before they’re KYC’ed or ready to migrate to the Mainnet. As they and their Referral Team/Security Circle pass KYC, more of their Mobile Balance will become transferable. At the moment of the migration of their Transferable Balance to Mainnet, their preselected setting of lockup duration and percentage will automatically apply to the amount of balance transferred, resulting in two types of balances on the Mainnet: lockup balance and free balance, both of which will be recorded on the Mainnet blockchain and reside in the Pioneer’s non-custodial Pi wallet. Thus, lockups cannot be reversed once confirmed and must remain locked up for the entirety of the chosen duration due to the nature of blockchain. Any changes to this Pioneer’s lockup setting will take effect in their next balance transfer to the Mainnet. 

This account-wide lockup setting allows Pioneers to lock up a maximum of 100% of their transferable balance from mobile to Mainnet. After Mainnet launches and Pioneers transfer their balances, Pioneers can also lock up more Pi directly on the Mainnet through a slightly different lockup interface later on. At that time, Pioneers can lock up as much as 200% of their already-transferred Mainnet balance acquired from their previous mining. The additional lockup allowance for more Pi than individually mined by the Pioneer can come from utility-based Pi apps transactions, i.e., making Pi from selling goods and services.

App Usage Reward

An overarching goal of Pi Network is to build an inclusive peer-to-peer ecosystem and online experience fueled by the Pi cryptocurrency through our app ecosystem. Therefore, Pioneers will have additional mining rewards for using Pi apps on the Pi apps platform through the Pi Browser, including ecosystem apps and third-party apps in the Pi Directory. The app usage reward for Pioneers helps the ecosystem in two ways. 

First, it will give Pi app developers market access and increased impressions of their apps. Pi app developers will gain usage and product iteration opportunities from Pioneers, which has been one of the biggest barriers to creating viable decentralized applications in the blockchain industry. Decentralized application (dApp) developers do not yet have a plentiful, stable, and utility-seeking consumer market environment to test and hone their consumer products to create consumer utilities. Pi Network’s apps platform and the app usage reward are meant to provide that environment for dApp developers.  

Second, the increased impressions and usage will potentially lead to increased spending of Pi by Pioneers in the Pi apps. Even though the impressions are incentivized through the app usage reward, the spending of Pi is not. This means that the Pi app usage reward to Pioneers helps the Pi app developers to the extent that Pioneers are at their door. Now what determines whether Pioneers will actually stay and spend Pi in their apps is how useful and engaging their products and apps are. This framework ensures that these apps are able to compete on the basis of product quality and utility, ultimately allowing the best apps to emerge and stay in the ecosystem. 

Through the above two mechanisms, the app usage reward aims to achieve the gradual transition from extrinsic incentives to intrinsic motivations among Pioneers visiting Pi apps, and thus the transition from incentivized to organic usage of Pi apps in order to ultimately bootstrap a utility-based ecosystem of apps using Pi.

The app usage reward formula is reprinted here:

• time_spent_per_app_yesterday_in_seconds is, for each Pi app, the total amount of time in seconds that the Pioneer spends using the app on the prior day.
• Σ_across_apps sums up the logarithmic value of the Pioneer’s time_spent_per_app_yesterday_in_seconds across all the Pi apps. 
• avg_daily_time_spent_across_apps_last_*_days/years is the average daily time in seconds the Pioneer spends across all the Pi apps in the aggregate during the last * time period. 

* Note that when any of the logarithmic functions returns an undefined value or a value below 0 (that is, when, the input to the logarithmic function is below 1), the formula resets the value of the logarithmic function to be 0 in order to avoid negative mining rewards or an error in the function. 

Generally, the app usage reward formula takes into account two factors: time spent in apps and the number of apps used while crediting the history of app usage in the long term and capping the rewards to avoid exploitation. There are two main parts to the formula. The first part aggregates a Pioneer’s time spent across each app in the last mining session (i.e., in the previous day). The logarithmic function provides a positive function with diminishing rewards, meaning that an increase in time spent on any one app will generally increase the rewards, but the positive effect of time spent on rewards decreases as more time is spent. This setup encourages Pioneers to generally spend more time on multiple diverse apps, helping the network to bootstrap the creation of diverse utilities. At the same time, it caps the rewards to prevent users from exploiting this reward by artificially keeping the apps open all day, which would not meaningfully contribute to utilities creation. 

The second part of the app usage reward formula looks at a Pioneer’s rolling average of daily time spent across all apps in various time periods. The further back the time period goes, the less it is weighted. In other words, a Pioneer mines more Pi the longer they have been using the Pi apps, but their recent time spent on the apps counts more toward mining than their previous time spent further back in the past. In addition, as a matter of fact, the app usage history takes effect on the current mining reward only if the Pioneer also used Pi apps during their last mining session. This means that there is no passive reward for only the past usage. Once again, the use of logarithmic functions helps moderate the mining boost from app usage to avoid exploitation of the app usage reward. A noteworthy implication here is that Pi chat moderators who have been helping to guide Pioneers and monitor undesirable activities on Pi chats over the last two years will mine the app usage reward at a higher rate when the Mainnet launches.

Node Reward

Like on any blockchain, Nodes are at the heart of the decentralization of Pi. In Pi, instead of relying on centralized institutional nodes, we decided to open up the Nodes to any Pioneer with a computer connected to the internet. Aided by the global trust graph aggregated from individual Pioneer’s Security Circles from the mobile app, these Nodes will run the consensus algorithm to validate transactions and process blocks. Because the Nodes are critical to the decentralization, security, and longevity of the Pi blockchain, Node-operating Pioneers will receive additional mining rewards. 

The node reward formula is reprinted here:

N(I) = node_factor • tuning_factor • I, where

• Node_factor = Percent_uptime_last_1_days • (Uptime_factor + Port_open_factor + CPU_factor), where
  • Uptime_factor = (Percent_uptime_last_90_days + 1.5*Percent_uptime_last_360_days(360-90) + 2* Percent_uptime_last_2_years + 3*Percent_uptime_last_10_years),
  • Port_open_factor = 1 + percent_ports_open_last_90_days + 1.5*percent_ports_open_last_360_days + 2* percent_ports_open_last_2_years + 3*percent_ports_open_last_10_years,
  • CPU_factor = (1 + avg_CPU_count_last_90_days + 1.5*avg_CPU_count_last_360_days + 2* avg_CPU_count_last_2_years + 3*avg_CPU_count_last_10_years)/4. 

                  and

• • Percent_uptime_last_*_days/years is the percentage of the last * time period when the individual Node was live and accessible by the network. 
  • percent_ports_open_last_*_days/years is the percentage of the last * time period when the ports of the individual Node were open for connectivity to the network.
  • avg_CPU_count_last_*_days/years is the average CPU that the individual Node provided to the network during the last * time period. 
  • tuning_factor is a statistical factor that normalizes the node_factor to a number between 0 and 10. 

The node reward depends on the uptime factor, port open factor, CPU factor, and the tuning factor. The uptime factor of a Node for a given period of time is the proportion of time the Node is active during that period. For example, a 25% uptime factor yesterday means that the Node was live and accessible for a total of 6 out of 24 hours yesterday. The Pi Node software tracks the time a particular Node is active. Starting in the Open Network phase, only a Node running functionally at a given point in time is considered active. This is a proxy for the reliability of the Node. However, for the historical data relevant to the mining reward, a Node is considered active if the Node app is open and connected to the internet even if it is not running functionally. This exemption for the past performance recognizes that the Community Node operators running the Testnet provided the network with important data and infrastructure to enable multiple iterations of the Node software and Testnet, and that it was not always the fault of the Node operator that their Nodes were inoperative. 

The port open factor of a Node for a given period of time is the proportion of time the Node’s specific ports are detected to be accessible from the Internet during that period. Pi Nodes use ports 31400 through 31409, enabling other nodes to reach them through these ports and the network IP address. An open-port Node is able to respond to communications initiated by other Nodes, while closed-port Nodes are not able to receive such communications from other Nodes and can only initiate communications. Pi’s consensus protocol relies on Nodes sending a series of messages among each other. Therefore, open-port Nodes are critical to the operation of the Pi blockchain, and thus, worthy of a mining reward boost. In fact, the network aims to have at least 1/8th of the Nodes with open ports, and having an open port is one of the prerequisites for being a Super Node. 

The CPU factor of a Node for a given period of time is the average number of CPU cores/threads available on the computer during that period. A higher CPU factor prepares the blockchain for future scalability, for example, the ability to process more transactions per block or more transactions per second. The Pi blockchain is not an energy and resource-intensive blockchain. The network is initially set to operate at one new block of up to 1,000 transactions (T) about every 5 seconds. Thus the network is effectively capable of processing up to about 200 transactions per second (TPS) or ~17M T/day. Should the blockchain get congested in the future, this limit can be increased to 2,000 TPS (~170M T/day) by increasing the block size from 1000 to 10,000 transactions per block. The higher the CPU contributed by Pi Nodes, the more room the network will have to grow and scale further in the future. Furthermore, higher collective CPU from Pi Nodes will allow novel peer-to-peer node-based applications to be built on Pi Network, such as decentralized CPU sharing applications that let computing power-intensive applications run or provide distributed cloud services. Such services will be further rewarding contributing nodes with additional Pi paid by the clients of those services.

Finally, a tuning factor normalizes the Node reward to a number between 0 and 10. This is meant to make Node rewards comparable to other types of mining rewards that recognize other contributions to Pi Network. During the Enclosed Mainnet phase (as explained in the Roadmap section), the Node reward formula is expected to iterate. For example, the use of logarithmic or root functions may potentially obviate the need for a tuning factor. 

Having reliable Nodes running predictably over a long stretch of time is critical to the health of the blockchain. It is not a one and done contribution. Therefore, the uptime factor, port open factor, and the CPU factor are all calculated over varying time periods, where the value from more recent time periods are more heavily weighted than the time periods of equal lengths from a more distant past. Note, however, that the Node reward is a multiple of the uptime factor of the previous mining session. Hence, a Pioneer will not receive any Node reward in a given mining session if their Node was inactive for the entirety of the immediately preceding calendar day. Similar to the app usage reward, there is no passive reward for only the past contribution as a Node operator. This also means that a low uptime factor in the previous calendar day (even if the Node is active for a part of the day) will substantially reduce the Node reward in a given day despite high past Node contributions. 

The Effect of KYC on Mainnet rewards

There will be a rolling grace period of six calendar months for a Pioneer to complete KYC. Thereafter, the Pi mined outside of the rolling 6-month window will not be transferable to the Mainnet, and will instead be reallocated to Pioneer mining rewards, as discussed below. The retention of the mined Pi in the 6-month window continues indefinitely until they pass KYC or the KYC policy changes. Note that this KYC-window mining framework will only begin when the KYC solution is generally available to all eligible Pioneers in the future, and will be announced to the community beforehand. The six-month restriction will not be immediately in place yet when we launch the Mainnet. 

Because of the importance of true humanness in our social network-based mining, only the Pioneers who pass KYC will be able to transfer their Phone balance to the blockchain. Our objective is to have as many true Pioneers as possible pass KYC. As explained further below, the rolling six-month window serves the following important purposes: 

• strike a balance between giving Pioneers adequate time to pass KYC and creating enough urgency to pass KYC,
• prevent unverified Pi beyond the rolling six-month KYC grace period from migrating to the Mainnet, instead freeing it up for mining by other KYC’ed Pioneers within the allocated Pi overall supply limit for Pioneer mining, and
• limit KYC spam and abuse (see 30-day delay in KYCing new members below)

If Pioneers do not pass KYC in time, it delays the Mainnet transfer of their balances and the balances of other Pioneers who have them on their Security Circles and Referral Teams. Without balances on the Mainnet, Pioneers are not able to use payments in Pi apps, thereby undermining the growth of our utility-based ecosystem. A six-month window creates a sense of urgency for Pioneers while giving them adequate time to retrieve their mined Pi. The KYC verification process will generally take into account Pioneers’ likelihood of being real human beings based on Pi’s machine-automated prediction mechanisms run over the last three years. Newly created accounts will not be able to immediately apply for KYC verification, until after 30 days. This helps the network limit the ability of bots and fake accounts to spam and abuse our KYC process and prioritize KYC validation resources for real human Pioneers. 

Finally, the Pi of the Pioneers who delay KYC verification beyond six months will not be transferred to the Mainnet and will not be accounted for in the calculation of the systemwide base mining rate (B) beyond the rolling six-month KYC grace period. Pioneers will, therefore, need to claim their Pi in time, or their Pi will be reallocated to B for mining in the same year by other verified Pioneers who can make full contributions to the network.