Compare Bitcoin mining payrates fairly across FPPS, PPS+, PPLNS and TIDES using fees, transaction rewards, variance, rejects, thresholds, latency and custody.
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.
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 miner wants to understand compare Bitcoin mining payrates. Choose a period long enough to reduce reporting noise, such as 30 days, and record net Bitcoin credited before any unrelated exchange conversion.
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.
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.
| Method | Payment basis | Main review point |
|---|---|---|
| PPS | Fixed expected subsidy value per valid share | Fee and counterparty reserve |
| FPPS | Expected subsidy and transaction fees | Transaction-fee estimate and rate method |
| PPS+ | PPS subsidy plus separate fee allocation | How transaction fees and luck are shared |
| PPLNS | Actual blocks across a share window | Window, pool luck and switching effect |
| TIDES | Actual blocks and weighted ordered share log | Variance, direct payout and threshold |
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. At the same time, an FPPS result can change when the provider revises its transaction-fee model.
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.
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.
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.
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 enough 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.
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.
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.
To compare Bitcoin mining payrates, standardise the work, time and units before looking at a headline.
A pool payrate is the Bitcoin credited for valid contributed work under the pool's method.
Pay Per Share methods credit qualifying shares according to a formula rather than waiting for the miner's own share to find a block.
Choose a period long enough to reduce reporting noise, such as 30 days, and record net Bitcoin credited before any unrelated exchange conversion.
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.
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.
Normalise every quote to net satoshis per accepted PH per day or an equivalent unit, using the same time window and excluding electricity when comparing pools alone. Read the reward formula, fee, transaction-fee treatment, share window, threshold, payout charge, custody, jurisdiction and change policy before connecting a fleet.
Build a five-year ASIC replacement calendar from efficiency gap, tariff, failure rate, parts, firmware, resale, network scenarios and capital gates.
Build ASIC profit forecast ranges using base, downside and severe cases for accepted hashrate, energy, uptime, difficulty, reward, fees, price and repairs.
Compare European ASIC mining energy costs using the correct tariff band, taxes, grid connection, curtailment, cooling, contracts and location risks.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.