FPPS vs PPS+ vs PPLNS for ASIC Miners: Fees, Variance, and Cash Flow

Published: 2026-08-28 Updated: 2026-08-28 Evidence checked: 2026-08-28

For most home and small-farm miners, FPPS is the simplest cash-flow choice because the pool absorbs block-luck variance and credits both subsidy and transaction-fee components on an expected-value basis. PPS+ usually stabilizes the subsidy while transaction fees can vary, and PPLNS passes more short-term luck variance to the miner. Compare fees, share-window rules, payout thresholds, and counterparty terms before switching.

The real choice is who carries short-term variance

An ASIC sends shares to a pool. The reward method decides how those valid shares become account credits; the payout rule decides when credited funds actually leave the account. These are separate decisions. A pool can offer steady FPPS credits but still hold a small operator below a withdrawal threshold, charge for a small on-chain payout, or process withdrawals only at set times.

The acronyms also describe a family of implementations, not one universal contract. Each pool can define its accounting day, fee schedule, accepted-share rules, transaction-fee calculation, confirmation delay, payout threshold, and treatment of interrupted mining differently. Read the current rules for the exact coin and account instead of choosing from the acronym alone.

Start with the two reward components

A Bitcoin block pays a block subsidy plus transaction fees. Pool methods decide whether each component is credited from an expected value or from blocks the pool actually finds.

• PPS (Pay Per Share) pays an expected subsidy value for valid shares. The pool carries the difference between expected and actual block discovery.
• FPPS (Full Pay Per Share) extends expected-value accounting to both the subsidy and a transaction-fee component. The exact fee estimate and accounting period remain pool-specific.
• PPS+ normally applies PPS to the subsidy and an actual-block or PPLNS-style method to transaction fees. It is steadier than pure PPLNS for the subsidy, but the fee component can still move with pool results.
• PPLNS (Pay Per Last N Shares) divides actual block proceeds among shares inside a defined recent window. The miner carries more short-term pool-luck variance and must understand how the pool defines N.

The Braiins FPPS specification illustrates the two-component approach: it calculates a subsidy cut and an average transaction-fee cut from submitted shares and network difficulty, then deducts the pool fee. This explains the mechanism, not a guaranteed future reward rate. Network difficulty, transaction fees, accepted shares, and pool terms can all change.

FPPS, PPS+, and PPLNS comparison

Decision field	FPPS	PPS+	PPLNS
Subsidy basis	Expected value per valid share	Expected value per valid share	Actual blocks allocated across the defined share window
Transaction-fee basis	Expected or averaged value under the pool's formula	Usually actual fees allocated with a PPLNS-style rule	Actual block fees allocated with the block reward
Who carries block-luck variance?	Mostly the pool	Pool for subsidy; miner retains some fee variance	Miner
Short-period account credits	Usually smoother	Usually smooth subsidy plus a variable fee component	Can be uneven
Pool fee tendency	Often higher because the pool prices variance risk	Often between FPPS and PPLNS, but rules vary	Often lower, but a low fee does not remove variance
Window or ramp effect	Usually limited to accepted-share accounting	Can affect the transaction-fee component	Important; joining, leaving, or switching can affect which shares remain eligible
Best fit to investigate	Tight operating cash flow and low variance tolerance	Operators wanting stable subsidy credits with some actual-fee exposure	Operators able to absorb uneven credits and evaluate the window rules

No column is automatically the most profitable. A higher-fee method can produce steadier credits while a lower-fee method exposes the operator to more timing variance. Over a sufficiently long period, actual results still depend on accepted shares, network conditions, pool performance, implementation rules, and whether the operator stayed inside the qualifying window.

Read fee tables component by component

One percentage can hide two calculations. ViaBTC's current calculation page, checked on August 28, 2026, documents a 4% fee for the PPS+ subsidy component and 2% for its transaction-fee component, while its PPLNS method lists 2%. It also states that its PPLNS window uses the last five difficulty rounds when a block reaches six confirmations. Those numbers and rules are a dated ViaBTC example, not an industry standard; verify them again before changing a worker.

Use separate rows for each component:

Net credited reward = eligible subsidy component x (1 - subsidy fee) + eligible transaction-fee component x (1 - transaction-fee fee)

Then separate credited rewards from cash received:

Cash received = cleared account balance - payout or network charge, after the trigger and minimum threshold are satisfied

These formulas do not forecast earnings. They organize the contract so you can compare like with like. The gross eligible components still depend on submitted and accepted work, network difficulty, transaction fees, block discovery, and the pool's accounting method.

Complete this payout-method worksheet

Record the page date and take a copy of the terms when you compare pools. Do not leave a field blank because the headline fee looks attractive.

Field to record	Pool A	Pool B	Why it matters
Coin and reward method	___	___	Rules can differ by coin and account
Subsidy calculation	___	___	Identifies expected-value or actual-block exposure
Transaction-fee calculation	___	___	Distinguishes FPPS from PPS+ and PPLNS details
Fee on subsidy	___%	___%	May differ from the fee component
Fee on transaction fees	___%	___%	Must be compared separately
Definition of valid share	___	___	Rejected or stale work may not qualify
PPLNS window or accounting day	___	___	Controls ramp and timing exposure
Confirmation or maturity delay	___	___	Delays when a credit becomes available
Minimum payout	___	___	Small miners may wait longer for cash
Payout schedule or trigger	___	___	Daily credit does not guarantee daily withdrawal
Payout network and charge	___	___	On-chain and Lightning terms may differ
Address lock and account security	___	___	Reduces payout-address takeover risk
Term-change and suspension clauses	___	___	Defines counterparty discretion
Exportable share and reward history	___	___	Needed for reconciliation and disputes

The Braiins rewards and payouts page says its pool currently uses FPPS and calculates rewards daily. Its separate payout documentation, checked the same day, lists a 2.5% pool fee, daily payout evaluation at 09:00 UTC, and different minimums and charges for on-chain and Lightning withdrawals. This is a useful reminder that a reward can be calculated before it is eligible to leave the account.

Match the method to your operating constraint

FPPS when predictability matters more than the lowest headline fee

FPPS is usually the first method to examine when electricity, hosting, or debt payments follow a fixed schedule and a short run of poor pool luck would strain cash reserves. The pool prices and carries more variance risk. Your diligence shifts toward the pool's formula, solvency, fee, rejected-share policy, payout security, and right to modify terms.

Steady credits are not a return guarantee. A miner can still earn less because difficulty rises, transaction fees fall, hashrate drops, shares are rejected, or the machine is offline. Use the break-even analysis to keep those operating variables separate from the reward method.

PPS+ when you want a stable subsidy with actual-fee exposure

PPS+ can suit an operator who wants expected-value subsidy credits but accepts some movement in the transaction-fee component. The label is not enough: find out whether actual fees are allocated by a PPLNS window, how long the window is, when blocks mature, and whether separate fee rates apply.

ViaBTC's payment-method comparison describes its PPS+ option as steadier and its PPLNS option as luck-sensitive. Treat that as documentation of ViaBTC's implementation, not proof that every pool uses the same calculation.

PPLNS when you can absorb uneven credits and understand the window

PPLNS can be reasonable for an operator with enough time and reserves to tolerate block-luck variance, especially when the fee is lower and the window is transparent. The tradeoff becomes harder for a small miner who may need predictable weekly cash or who frequently moves hashrate between pools.

Before choosing PPLNS, write down the exact N window, ramp-in behavior, what happens after disconnecting, block confirmation rule, orphan treatment, and whether late shares remain eligible. A method that looks inexpensive can be costly to operate incorrectly if a worker switches repeatedly or leaves just before its recent shares are rewarded.

Switch without confusing configuration with economics

Do not change every variable at once. First use the ASIC miner pool settings guide to confirm the official endpoint, account format, worker name, and failover rows. Then run a controlled comparison:

1. Export the old pool's share, reward, fee, and payout records.
2. Record the old method's final share-window and unpaid-balance rules.
3. Confirm the new pool's reward method, fees, threshold, payout destination, and address lock.
4. Move one identifiable worker or a documented hashrate slice first.
5. Compare accepted hashrate and rejected-share rate over the same measurement window.
6. Reconcile gross credits, component fees, maturity delays, and cash payouts separately.
7. Keep electricity cost outside the pool statement and calculate it with the ASIC electricity cost guide.

Do not judge a PPLNS method from one lucky or unlucky day, and do not judge FPPS only from the size of one cash transfer. Use the accounting window published by the pool and enough time to identify missing shares, unexpected fees, or payout friction.

Open discussion: auditable reward designs change the comparison

The familiar FPPS-versus-PPLNS choice assumes that the main tradeoff is steady credits versus direct exposure to pool luck. Newer designs add questions about custody, auditability, block-template control, and whether miners can independently check the reward split.

OCEAN's TIDES technical documentation describes a recent-share log designed to reduce variance while making reward allocation auditable and capable of non-custodial implementation. That does not make TIDES automatically better for a home miner. The operator still needs to examine window behavior, payout delivery, fees, minimums, software compatibility, and the practical ability to verify records.

Future pool comparisons should therefore show more than an acronym and percentage. A useful disclosure would publish the reward formula, transaction-fee treatment, window definition, orphan policy, maturity delay, payout custody, threshold, address-security controls, and a machine-readable history. Until that becomes standard, the worksheet above is the safest way to expose hidden differences.

Frequently asked questions

Which payout method is best for one ASIC miner?

FPPS is often the easiest method to evaluate for one machine because smoother account credits reduce the effect of pool luck on short-term cash flow. It is not automatically the highest-return choice. Compare the full fee, accepted-share policy, minimum payout, withdrawal charge, and pool terms. PPLNS may fit an operator with more time and variance tolerance, while PPS+ sits between them by stabilizing the subsidy but not always the transaction-fee component.

Does FPPS always pay more than PPLNS?

No. FPPS changes the timing and allocation of rewards; it does not guarantee a larger long-term result. The pool normally charges for carrying block-luck variance, while PPLNS often has a lower headline fee but uneven short-term credits. Results also depend on accepted shares, network difficulty, transaction fees, pool performance, and the exact implementation. Compare net component fees over the pool's stated accounting window instead of using one day or one payout as proof.

What happens when I leave a PPLNS pool?

Your result depends on how that pool defines the last-N-share window. Recent valid shares may remain eligible until they fall out of the window, but credits can also ramp down as newer work replaces them. Other implementations use different rounds, confirmation rules, or payout timing. Export your records and read the current exit treatment before moving hashrate. Do not repeatedly switch pools without understanding whether each move restarts a ramp or strands eligible work.

Are pool fees directly comparable across FPPS, PPS+, and PPLNS?

Not from one percentage alone. A pool may charge one rate on the expected subsidy, another on transaction fees, and a separate charge for small or on-chain payouts. It may also calculate fees before or after another adjustment. Record each component, the share definition, and the payout charge in separate rows. Then compare net credited rewards and cash received over the same period, with the same accepted hashrate and no assumption that two pools use identical formulas.

Why is my pool balance larger than the amount I received?

The balance can contain immature rewards, funds below the withdrawal threshold, or credits waiting for the next scheduled payout. The pool may also deduct an on-chain or small-payout charge when it sends funds. Reward calculation and payout delivery are separate stages. Check the maturity rule, trigger, minimum, network, fee, and failed-payment policy. Lock the payout address when the pool supports it, and verify changes through the official account interface without sharing private wallet credentials.

Should I split hashrate across two payout methods?

Splitting hashrate can create a useful controlled comparison or reduce dependence on one operator, but it also adds small balances, more thresholds, more records, and possible PPLNS ramp effects. Give each worker a clear name, fix the allocation ratio, and compare accepted hashrate over the same window. Reconcile subsidy, transaction fees, pool fees, maturity, and withdrawals separately. For a single small ASIC, operational simplicity may be more valuable than a split that delays both payouts.

References

• Braiins Academy: Rewards and payouts
• Braiins Academy: Rewards and payout FAQ
• ViaBTC: How mining rewards are calculated
• ViaBTC: Choosing PPS+ or PPLNS
• OCEAN: TIDES technical documentation