Full Pay Per Share

The machine sends the pool shares: partial computation results that demonstrate work. They usually do not meet the harder requirement for a complete block, but the pool can verify them. Luxor bases FPPS on valid accepted results without waiting for its own block discovery. Braiins also explains their weight: a result at difficulty d counts as d basic units of work. Counting sent messages is therefore insufficient. Results can carry different weights, and rejected work must not automatically be added to accepted work. [2] [3]

A new block can bring newly issued bitcoin, called the block subsidy, and fees paid for its transactions. FPPS values Eva’s expected share of both components. Braiins’ technical expression for an interval with unchanged parameters is R=(S/D)×(C+AF). S means accepted difficulty-weighted work, D network difficulty, C the subsidy and AF average fees determined by the methodology. R is the gross reward before the pool fee. S cannot be a simple count of messages at different difficulties: that would compare unequal amounts of work. S/D expresses how many blocks that amount of work would find on average at the given difficulty. It is neither a count of actual block discoveries nor a promise of finding one. [1] [3]

Eva sees a daily statement, but it is not simply a division of the blocks her pool found that day. Braiins closes its calculation for a day in UTC, the common worldwide time reference, and normalizes network results to the expected 144 blocks. That is a calculation benchmark, not a mandatory daily result for the network or pool. A day with fewer blocks can be ordinary randomness. A calendar period therefore cannot automatically mean the last 144 blocks: that window can begin and end at different times. [1]

Luxor describes another approach: at current height h, the block’s position in the chain, it looks at the last 144 blocks. It excludes fee values at the distribution’s edges, marked ≤p5 and ≥p95, then averages the remainder. This limits the influence of extreme observations. It also uses the subsidy and difficulty at that height. p5 and p95 are thresholds in the values sorted from lowest to highest: roughly 5% lie below the first and 95% below the second. The calculation therefore keeps the middle of the set rather than its extremes. This filtering is neither a Bitcoin rule nor a requirement for every FPPS pool. Luxor may change its methodology, so Eva needs to compare actual rules rather than matching abbreviations on price lists. [2]

Imagine Eva mines both before and after a network difficulty change. The same work now has a different expected value, so Braiins calculates the corresponding parts of the day separately. It handles a halving, the periodic reduction by half of the newly issued block reward, similarly. A halving changes the subsidy, not automatically the method for calculating the average fee component. FPPS therefore reduces dependence on pool luck without fixing the daily amount of bitcoin (BTC). Changes in bitcoin’s price or electricity costs also change Eva’s economic outcome. [1] [2]

The abbreviations describe what earns a payment. PPS means Pay Per Share: payment for accepted shares. PPLNS means Pay Per Last N Shares: when a block is found, the reward is allocated according to work in the latest share window, whose size is set by the pool. Both FPPS and PPS+ may offer a share of transaction fees without calculating it the same way. F2Pool distinguishes FPPS with modeled fees from PPS+. Under PPS+, the subsidy uses PPS, payment for accepted work, while actual fees earned by the pool are distributed through PPLNS according to work in the relevant recent window. The fee component thus remains dependent on the pool’s block discoveries. The statement “we include fees” alone does not tell Eva which part of her reward still waits for real blocks. [4]

When a pool goes a long time without finding a block but keeps crediting rewards, it needs funds to meet its obligations. Meni Rosenfeld discusses this problem for PPS: the operator takes on block-discovery variance and needs reserves. The same reasoning helps explain FPPS risk. His historical model is not an audit of a current pool and does not tell us how much money a particular company has. Eva obtains a claim on a service, not a protocol guarantee that she will receive the money if the operator fails. [5]

Both Braiins and Luxor distinguish crediting a reward from sending it. The payout also depends on the scheduled date, required minimum balance and any transfer fee. An FPPS figure on a dashboard does not prove delivery to Eva’s wallet. To compare services, she therefore looks at the same accepted work and period, the calculation rule used and the net amount actually received. Only then can she ask how much remains after the machine’s operating costs. [1] [2]