Bitcoin Mining Payrates: Compare Pools Fairly

To compare Bitcoin mining payrates fairly, measure what reaches the same wallet from the same accepted hashrate over a representative period. A quoted payrate can use different assumptions for block subsidy, transaction fees, pool luck, fees, rejected shares, payout threshold and Bitcoin price. FPPS, PPS+, PPLNS and TIDES allocate timing and variance differently, so one day's credited balance is not a reliable league table.

Separate revenue rate from profit

Reassess compare Bitcoin mining payrates whenever network conditions, firmware, tariffs or official guidance changes.

A pool payrate is the Bitcoin credited for valid contributed work under the pool’s method. Profit also deducts electricity, cooling, hosting, repairs and finance. Compare pool revenue first, then place the result into the same operating-cost model.

Use accepted hashrate rather than miner nameplate or local dashboard hashrate. Rejected and stale work consumes power but may earn nothing. Record the same algorithm, worker period and units.

Avoid comparing a sterling card at one Bitcoin price with a satoshi rate from another time. Keep the pool analysis in Bitcoin units before applying one consistent exchange rate.

Understand the main reward methods

When reviewing compare Bitcoin mining payrates, separate measured facts from forecasts so the result can be reproduced.

Pay Per Share methods credit qualifying shares according to a formula rather than waiting for the miner’s own share to find a block. Full Pay Per Share commonly estimates both subsidy and transaction-fee revenue. The pool carries short-term block-luck risk but can price modelling and counterparty risk into its fee or rate.

PPLNS rewards shares in a window around blocks actually found. It can converge towards expected value over time but exposes the miner to pool luck and window timing. Leaving and joining can affect which shares remain eligible.

OCEAN’s TIDES uses a transparent ordered share log and rewards recent proof of work when blocks are found, with direct generation-transaction payouts in its stated design. It has variance and threshold considerations and is not simply FPPS under another name.

Build a normalised payrate

No conclusion about compare Bitcoin mining payrates should rely on a single revenue snapshot or an undated specification.

Choose a period long enough to reduce reporting noise, such as 30 days, and record net Bitcoin credited before any unrelated exchange conversion. Divide by accepted petahash-days or terahash-days from the pool.

For example, 0.0030 BTC credited from an average accepted 1 PH/s over 30 days is 0.0001 BTC per accepted PH per day. Subtract pool and payout charges consistently if they were not already deducted.

Repeat for more than one period. A PPLNS or TIDES result over a few blocks can be dominated by luck, while an FPPS result can change when the provider revises its transaction-fee model.

Account for fees and transaction rewards

Record the pool fee that applied to the actual worker, including promotions and later changes. Determine whether the displayed estimate is before or after fee and whether a different fee applies to a firmware or marketplace arrangement.

Bitcoin block reward consists of subsidy plus transaction fees. A pool can distribute, estimate or retain parts differently under its method. Use the provider’s written formula rather than assuming a label such as FPPS always produces the same amount.

Include payout transaction charges, conversion spread and small-balance policy. A high displayed rate can be less useful if the balance takes months to reach a threshold or withdrawal is restricted.

Measure rejects, latency and failover

Connect representative hardware from the intended site. Record accepted, rejected and stale shares, reconnects, Stratum latency, difficulty changes and outages. A theoretically higher rate can lose its advantage through poor routing.

Use regional endpoints recommended by the pool and check DNS and firewall. Configure failover pools deliberately, because time on a backup changes the primary pool’s measured hashrate and some share-window eligibility.

Do not run simultaneous split tests on one miner unless the firmware implements the split predictably. Comparing equivalent miners or time blocks can be clearer.

Check custody, transparency and terms

Identify the pool’s legal entity, jurisdiction, sanctions and verification requirements, ability to suspend accounts, data retention, wallet-change controls and complaint route. A balance in a pool account is counterparty exposure until paid.

Non-custodial or generation-transaction designs can reduce pooled custody but do not remove pool software, block-finding, configuration or threshold risk. Verify the actual implementation and address.

Read how historical shares and unpaid balances are treated when the operator changes terms, the miner leaves or an account is closed. Save the terms and rate formula that applied during the test.

Use pool luck correctly

A pool finds blocks probabilistically. Actual-block methods can run above or below expected revenue for meaningful periods. Larger pool hashrate usually reduces the time variance between blocks but does not make every day equal to expectation.

Do not describe a lucky PPLNS week as a permanent premium or an unlucky week as proof of theft. Compare blocks, share window and published formula over sufficient time.

FPPS can smooth the miner’s credit but transfers variance and model risk to the pool. That creates a different counterparty arrangement, not free certainty.

When a pool switch makes sense

Evidence supports a better net result

Switch when a controlled test shows better net satoshis per accepted unit, reliable routing, acceptable custody and terms, and a practical payout threshold.

Keep a verified backup pool and record the change and payout address.

Reasons to remain

Remain when an apparent difference is within luck, reporting delay or measurement error, or the alternative adds unacceptable jurisdiction, custody or security risk.

Operational reliability can be worth more than a small unproven rate claim.

Common pool comparison mistakes

• Comparing local hashrate instead of accepted hashrate.
• Mixing gross revenue, net credits and profit.
• Using different Bitcoin prices for each pool.
• Ignoring transaction-fee allocation and pool fees.
• Judging an actual-block method from one day.
• Forgetting thresholds, withdrawal fees and small balances.
• Choosing a rate without reviewing custody, security and terms.

Frequently asked questions

What unit should I use to compare mining payrates?

Net BTC or satoshis per accepted PH per day is useful when the period and fee treatment are identical.

Is FPPS always the highest paying method?

No. Results depend on formula, fee, transaction-fee estimate, counterparty and period. The label alone is not a rate.

Why does PPLNS revenue vary?

It distributes actual blocks across a defined share window, so pool luck and when shares enter or leave the window matter.

Does a larger pool always pay more?

It can reduce block timing variance, but fee, method, routing, rejects and terms determine net payrate.

How long should I test a pool?

Use several representative weeks and more than one period. Actual-block methods may need longer to assess luck.

Should I use the pool's displayed hashrate?

Use it for accepted-work comparison and reconcile it with miner and wallet data. Do not rely on one dashboard alone.

Conclusion

To compare Bitcoin mining payrates, standardise the work, time and units before looking at a headline. Calculate net satoshis per accepted hash-day, document the reward formula, fees, transaction-reward treatment, thresholds and custody, and measure rejects from the real site. A good pool is the one that delivers an evidenced net result with acceptable operational and counterparty risk, not the one with the largest unqualified percentage.

Next steps

Use The Mining Shop UK’s pool, profitability and security guidance to create a 30-day comparison sheet for your actual miners, then review the result before moving a whole fleet.