Many Bitcoin miners choose a primary pool through a “bake-off”: divide the fleet across several candidates, run for a week or a month, compare the total payouts, and point full hashrate capacity to the winner.

The instinct is sound, but the measurement is not. A pool ‘bake-off’ scored on raw payouts alone tends to be won by the pool with the widest distribution, and that distribution has nothing to do with what the pool actually pays over time. For FPPS pools, it may also motivate to overpay as bait for committing hashrate.

TLDR

• PPLNS usually wins bake-offs, but not because they pay more. Pit one PPLNS pool against several FPPS pools that all pay the same over time, and the PPLNS pool will top a short-term test far more often than its fair share — often by a wide margin. It will also finish last unusually often. That is the illusion: PPLNS’s higher variance makes it more likely to stand out as either the clear winner or the clear loser, even though it does not pay more on average.
• Bake-offs can invite overpayment. An announced start and end date is an easy window for a FPPS pool to pay above its published methodology, win the fleet, then revert. Miners should verify what each pool owed based on its stated methodology, not just what it sent. 

Pitfall 1: PPLNS Usually Wins, But Not Because It Pays More

Let’s start with a simple demonstration. Eight pools, one coin flip, and one payout. Seven of them pay 0.5 BTC no matter how the coin lands (i.e., FPPS). The eighth pays 1.0 BTC on heads and 0 BTC on tails (i.e., PPLNS). Every pool has an expected value of 0.5 BTC; not one of them pays a satoshi more than any other over time.

Run this bake-off many (millions of) times and you’ll see that the eighth pool (PPLNS) wins half of them. Fair share in an eight-pool test is 12.5% (⅛ = 0.125), but a high-variance entrant takes 50% (4.0x its fair share), purely by being the only entrant capable of producing an outlier payout above the average.

Pool bake-offs look like this coin-flip model. The pool payout method decides who carries block-finding luck risk: under FPPS the pool operator absorbs it and pays the expected value of every share regardless of block discovery outcome, while under PPLNS the miner carries it and gets paid only when the pool actually finds blocks. Both methods target the same long-run expected value, but what differs is the spread around it. Since a typical bake-off compares several FPPS pools to one or two PPLNS pools, the FPPS entrants land in a tight cluster near their true value (because they were engineered to), whereas the PPLNS entrant(s) are the only pools that can produce an outlier payout.

This is the statistical fallacy behind the circulating claim that a high-variance PPLNS pool “pays more.” It wins these contests at several times its fair rate without paying a single satoshi above its stated methodology.

From a Coin Flip to SHA-256 Hashing

Now let’s apply current Bitcoin network conditions into the model. As of early August 2026, Bitcoin’s 7-day average hashrate stood at ~930 EH/s, and difficulty sits at ~126T. Take a 25 EH/s PPLNS pool — 2.69% of the network, 3-4 blocks per day. Over a seven-day bake-off the PPLNS pool expects to find ~27 blocks, which carries a standard deviation of ~19% on its own revenue (weekly swing = 1 ÷ √(blocks per week)). Against seven FPPS rivals paying identical true value, across millions of Monte-Carlo simulated bake-offs, the PPLNS pool finishes first 46.9% of the time. It also finishes last 53.1% of the time.

That is the entire illusion. The PPLNS pool appears to win far more often than its fair share—and when it does, it usually wins by a wide margin—but not because it pays more.

A Longer Window Shrinks the Error, Not the Bias

The usual response is to run the test longer. That helps, but not the way most operators assume. Extending a bake-off from 7 days to 90 days barely moves the probability that the PPLNS pool finishes first, from 46.9% to 49.6%. What shrinks is the margin of victory. 

The fix is not duration, it is luck-adjustment: score revenue per PH against expected blocks, not actual blocks.

Pitfall 2: A Bake-Off Is an Invitation to Overpay

The first pitfall is nobody’s fault. The second can be deliberate. A bake-off is an announced test with a known start and end — a convenient window to pay above methodology, win the fleet, and revert back to methodology once the hashrate is committed. A high payout during the test means nothing on its own; it is meaningful only if it matches what the pool’s own published methodology says you earned.

So reconstruct the obligation instead of only ranking payouts: for FPPS, your valid shares times the full pay-per-share value over the window, net of stated fee; for PPLNS, the blocks the pool actually found and your share of the last-N window when each landed. Both are verifiable against on-chain data and each pool’s own published rules. The real question is not “who paid the most?”, but rather “did each pool pay what it owed?”

Getting paid more than you are owed is pleasant, but it may be bait. Luxor Pool’s payouts match our published methodology during a bake-off and long after it, and we will help you verify that claim against us.

Tips to Run a Bake-Off That Answers the Real Question

• Score luck-adjusted revenue per PH, never raw totals. Normalize each PPLNS entrant by the blocks it found against the blocks its hashrate expected. 
• Reconstruct what you were owed, pool by pool. Rebuild each payout from on-chain blocks, fees, and the pool’s stated method, then compare it to the payout you received.
• Run every pool at once, not one after another. Splitting one fleet across all candidates simultaneously holds difficulty, hashprice, uptime, and firmware constant. LuxOS can split a single miner’s hashrate across multiple pools by quota, and Commander enables easy fleet-wide configuration.
• Value the low variance itself. Predictable revenue is what makes forecasting, treasury planning, and cheaper financing possible, and it belongs in the comparison as a benefit.

Luxor can help you access the on-chain and pool data needed to independently reconstruct what each pool owed you, so the decision rests on auditable results rather than a single statistical punchline. 

If you’d like to learn more about Luxor’s mining pool, please reach out to [email protected] or visit luxor.tech/mining.

About Luxor Technology Corporation

Luxor delivers hardware, software, and financial services that power the global compute and energy industry. Its product suite spans Bitcoin Mining Pools, ASIC Firmware, Hardware trading, Hashrate Derivatives, Energy services, a Miner Management software, Commander, and a bitcoin mining data platform, Hashrate Index.

Disclaimer

This content is for informational purposes only; you should not construe any such information or other material as legal, investment, financial, or other advice. Nothing contained in our content constitutes a solicitation, recommendation, endorsement, or offer by Luxor or any of Luxor’s employees to buy or sell any derivatives or other financial instruments in this or in any other jurisdiction in which such solicitation or offer would be unlawful under the derivatives laws of such jurisdiction.

There are risks associated with trading derivatives. Trading in derivatives involves risk of loss; loss of principal is possible.