A 1% Fee Against a 4% Fee: Why Ranking Pools on One Number Breaks, and How to Score Four Factors Instead

TL;DR

The advertised fee is one input out of four, and rarely the decisive one. Next to it sit operator risk, the confidence you can have in the numbers a pool publishes about itself, and payout liquidity: how many days until the coins reach your wallet and how much evaporates on the way. What follows is a scoring method that folds those four into one figure, plus an honest account of where that figure lies to you.

POOL BTC is an independent pool comparison site, not a mining pool. Everything below scores other people's services, and the method is published precisely so it can be argued with.

Multi-factor scoring is not our invention. Minerstat published a breakdown of its opportunity score in September 2026, built from four components (profit, risk, data confidence, liquidity), and that post is what pushed us to write our own approach down. We are not copying their formula and not claiming their coefficients. Only the choice of components overlaps, because those components are obvious to anyone who has ever computed pool revenue by hand.

Why does comparing pools on the fee alone give the wrong answer?

Because the fee describes neither what gets split nor whether the money arrives. A pool charging 2% on PPLNS and one charging 4% on FPPS are paying for different things: the second includes block transaction fees in the base. Payout thresholds, network withdrawal costs and the chance the operator rewrites the rules are not in that percentage at all.

Take verified numbers. F2Pool officially runs three Bitcoin schemes side by side: FPPS at 4%, PPS+ at 2.5% and PPLNS at 2% (F2Pool help centre, checked 2026-08-29). Picking the cheapest line and stopping there fails, because PPLNS pays you the actual transaction fees of blocks the pool finds, while FPPS averages them over the previous day and pays regardless of the pool's luck. Which is better depends on your time horizon and on what transaction fees are worth right now.

And what they are worth swings between almost nothing and more than the subsidy:

In the calm fee market of September 2026, the gap between "fees are shared" and "fees are not shared" is a fraction of a percent of revenue, and against that background the advertised fee genuinely is the main factor. On 20 April 2024 the same gap was worth three quarters of the day's revenue. A method resting entirely on one number breaks on exactly those days.

The second thing invisible in a percentage: the cost of getting money out. Luxor's payout threshold is 0.001 BTC plus a 0.000075 BTC network fee, so you need more than 0.001075 BTC on the balance, and the network fee comes out of the user's side (Luxor documentation). NiceHash charges 2% on accrual, and withdrawing from its wallet is a separate operation with a 0.0005 BTC minimum and a fee starting at 0.0001 BTC on top (NiceHash official pages, accessed 2026-09-02). Which of those hurts more depends on your hashrate, not on the storefront percentage.

The full breakdown of everything deducted beyond the advertised percentage lives in a separate piece on what pools really take. The point here is different: even a perfectly computed effective fee is still one component out of four.

What components make up a fair pool score?

Four, and they answer four separate questions. Profitability answers "how much BTC per day". Operator risk answers "what is the chance that BTC never reaches me". Data confidence answers "how much can I trust the first two estimates at all". Liquidity answers "when exactly do I see the money, and what do I lose withdrawing it".

The order matters. Profitability comes first because nothing else means anything without it, and data confidence sits third but works as a gate ahead of everything: if the pool's fee is not published, you did not calculate profitability, you guessed it.

Our ranking methodology page currently documents only the first component, the net BTC/day calculation. The other three shaped our selection but were never written down, and this article closes that gap.

How do you compute the profitability component, and why net BTC/day rather than the advertised percentage?

Because a fee percentage is a coefficient inside a formula, not a result. What a miner needs is the net output after the pool's cut and after electricity, expressed in BTC per day at their own hashrate. The same pool can be the best choice for a farm on three-cent power and the worst for a home miner on an expensive tariff.

The formula POOL BTC uses:

```

net BTC/day = (your hashrate / network hashrate) x 144 x (subsidy + average block fees) x (1 - pool fee) - electricity in BTC

```

What matters in each term:

1. Network hashrate comes from a public API and moves daily. On the 2026-08-29 snapshot it stood at 896.89 EH/s with difficulty 125,807,076,547,197.5; by 2026-09-09 it was 943.73 EH/s with difficulty 127,450,789,715,843.1 (mempool.space). The network grew 5.2% in eleven days, and any profitability table without a capture date is useless.
2. The subsidy is 3.125 BTC per block after the 2024 halving. It is the only genuinely stable input in the formula.
3. Average block fees count only for schemes that share them. FPPS and PPS+ do, classic PPS pays from the subsidy alone. That is where the gap between advertised and effective fee comes from.
4. Electricity converts to BTC at the current rate. It is the only input that only you know, and it decides the comparison more often than anything else.

Then comes the unpleasant part. The formula asks for "pool fee", and for roughly half the large pools there is nowhere to get it, which is the third component intruding on the first. How the payout scheme changes both variance and the final number is covered in the FPPS and PPLNS breakdown.

None of this needs doing by hand. That is what the payout calculator is for: it pulls current network parameters and takes your price per kilowatt hour.

What is operator risk, and how do you judge it from the outside?

Operator risk is the probability that the revenue you calculated never arrives: the pool closes, rewrites payout rules, stalls for a week, or writes off your balance on a technicality. It cannot be measured precisely from outside, but it has observable markers, and almost all of them sit in public documents nobody reads.

What you can actually check without inside knowledge:

• Terms of service on balances and unpaid remainders. F2Pool spells it out: with no payout address set for more than 90 days, rewards "may be treated as a donation", and under its terms of service, failure to supply a valid wallet address within six months of written notice forfeits the accrued amount. This is not a scandal, it is a normal contract clause, and it deserves reading before rather than after.
• Custody. A pool holding your balance until the threshold is your debtor for that whole period. A pool paying straight to your wallet at a low threshold keeps you a creditor for less time.
• The payout scheme as a risk transfer. PPS-style schemes move variance onto the operator, which is comfortable exactly as long as the operator stays solvent. PPLNS leaves variance with you and leaves the pool owing you less.
• Hashrate concentration. A large share of the network means predictable payouts and a systemic risk to Bitcoin at the same time. Both effects are real, and collapsing them into one score without a caveat is dishonest.
• Incident history and how the pool talked during incidents. A public outage log carries more weight than a pretty uptime figure with no measurement method behind it.
• Jurisdiction and verification requirements. Both change, and they change retroactively for coins already mined.

How network hashrate is distributed across pools

Nobody measures a pool's hashrate directly, so the industry counts blocks instead: an explorer attributes each block to a pool by its coinbase tag and divides by the total blocks in the window. Below is mempool.space data as of 2026-09-09 across two averaging windows, one week and one month. These shares move constantly, and a table like this is only usable together with its capture date.

Source for both windows: mempool.space Mining Pools API, accessed 2026-09-09.

Two things in that table are worth a reader's time. The top three hold roughly 58% of the network on either window, which is the case where payout predictability at a big pool and systemic risk to Bitcoin grow together. And the gap between windows shows how noisy the figure is: SECPOOL's weekly share runs about a third above its monthly one, while NiceHash sits at 1.33% weekly and drops out of the monthly top twelve entirely. Comparing pools on shares captured on different days with different windows tells you nothing.

Which pools publish a status page

Almost none. We checked nine pools on 2026-09-09, and exactly one keeps a proper status page.

That matters more than it looks. Advertised uptime is essentially unverifiable from outside: eight of nine pools publish neither an incident history nor a measurable availability figure, so a marketing claim of 99.9% is an assertion with no way to disprove it. The only checkable quantity here is not a percentage but whether the page exists at all.

A note on uptime as a metric. None of the pools in our dataset publishes a measurable availability figure with a stated method: a published number becomes an obligation, and measuring it honestly has to happen from outside. So uptime enters the risk score as an observable marker (is there a status page, are there multiple entry points), never as a percentage.

How do you judge the confidence you can place in a pool's own published numbers?

By one test: has the pool put its fee and threshold on its own site, without a login, with a date. If the fee is known only through aggregators, you are not comparing a pool, you are comparing somebody's retelling of it. This component is fully verifiable from outside, which makes it the only one that does not require taking the operator at their word.

Here is what that looks like in practice. During the 2026-08-29 review we opened the disputed pages manually in a browser:

One conclusion from that table matters more than any ranking: for four pools on the list, the fee number in any comparison, ours included, is not a fact but a dated rumour. And when two pools differ by half a percentage point while one of them publishes no fee at all, that half point means nothing.

The scale we use:

1. Published on an official page, opens without a login, carries the date of our manual check.
2. Published but incomplete: some parameters public, others only in support tickets or chat.
3. Behind a login or available only through aggregators, no official confirmation.
4. Sources contradict each other and the contradiction is unresolved.

Level four shows up more often than anyone would like. EMCD has given us two conflicting thresholds since August, and the right response is not "pick whichever looks plausible" but "mark it unresolved and build no comparison on it".

What is payout liquidity, and why do the minimum threshold and payout frequency matter more than they look?

Liquidity is how fast mined coins turn into money in your own wallet. The arithmetic is trivial: divide the payout threshold by your net BTC/day. For a farm that is hours. For a single home ASIC it can be months, and for all those months the balance sits with the operator whose rules can change.

Verified thresholds and deductions across several services:

Three things break liquidity math more often than anything else.

An accrual threshold and a withdrawal threshold are not the same number. NiceHash credits your balance from 0.00001 BTC, but you cannot withdraw less than 0.0005 BTC, fifty times more. Comparing the first figure with an ordinary pool's threshold is meaningless.

A flat withdrawal fee is a percentage in disguise, and the percentage depends on the amount. A 0.00003 BTC fee on a 0.00025 BTC withdrawal is 12% of the sum; on 0.01 BTC it is 0.3%. The same tariff line means two different things to a home miner and to a farm.

The remainder when you leave. The rule "a balance below the threshold accumulates and is not burned" is officially confirmed for F2Pool, ViaBTC and Luxor. For the other pools we found no direct official wording, which means that when you switch pools, the leftover on the old balance is an open question rather than a guarantee.

How long it takes to reach a payout threshold

This is expected value, with no scheme-specific variance in it:

```

miner share = miner hashrate / network hashrate

BTC per day = miner share x 144 x effective_reward

days to payout = threshold / BTC per day

```

Effective reward is the subsidy plus average block fees. On the 2026-09-09 snapshot the network stood at 943.73 EH/s and transaction fees made up 0.669% of the reward over the last 4,320 blocks, so effective_reward = 3.125 x 1.00669 = 3.1459 BTC (mempool.space, accessed 2026-09-09). Against 896.89 EH/s on 2026-08-29 the network grew 5.2%, and waiting times grew by the same 5.2% for everyone who did not change hardware.

This is our own calculation from the formula above, not pool-reported data. Real variance under PPLNS or TIDES is not modelled here, and on those schemes the spread around the expected date is noticeable. The practical reading is simple: a 100 TH/s home ASIC waits about three weeks for a 0.001 BTC threshold, and the operator holds the money for all three weeks. At a 0.01 BTC threshold the wait passes half a year. Plug in your own hashrate and tariff in the payout calculator.

How do you combine the components into one score, and with what weights?

As a weighted sum of four normalised scores, with data confidence doubling as an admission filter. The weights below are our choice and our responsibility, not an industry standard: anyone who disagrees is free to set their own and get a different ordering. That is exactly why they are published instead of buried in code.

The procedure:

1. Compute net BTC/day for every pool at the same hashrate and the same electricity price. Different inputs for different pools is the single most common comparison error.
2. Normalise profitability to a 0 to 100 scale within the compared set: best pool in the set takes 100, worst takes 0. The score is relative, and that has to be remembered when reading it.
3. Score operator risk from the observable markers above. The scale is coarse on purpose: 0, 25, 50, 75, 100. Precision here would be fake, and pretending risk is measured to the percentage point helps nobody.
4. Score data confidence on the four-level scale and convert: level 1 is 100, level 2 is 66, level 3 is 33, level 4 is 0.
5. Score liquidity as threshold divided by your daily revenue, normalised like profitability: faster is higher.
6. Apply the weights and sum.

Proposed weights:

One hard rule sits above the sum: a pool at data confidence level 3 or 4 is not ranked at all. It appears in the list flagged "data unconfirmed" and without a total. Otherwise you get the absurd outcome where a pool scores well on an attractive fee that nobody could confirm.

What it looks like on a single pool:

```

Profitability 82 x 0.50 = 41.0

Risk 75 x 0.20 = 15.0

Data confidence 100 x 0.20 = 20.0

Liquidity 60 x 0.10 = 6.0

Total 82.0

```

Why we publish no table of final scores per pool

Because no such table works for every reader, and publishing one would manufacture an impression of objectivity that the numbers cannot support. The reasons are concrete.

First, three of the four components depend on inputs that differ per reader. Profitability runs on your hashrate and your price per kilowatt hour; liquidity runs on how long the threshold takes you to reach. A 100 TH/s home ASIC waits about three weeks for a 0.001 BTC threshold, a 1 PH/s farm about two days. The same threshold yields different scores for different readers, and there is no meaningful average to collapse them into.

Second, half the pools we compare do not clear the admission filter. AntPool, Binance Pool, Foundry USA and Luxor do not publish a fee rate officially, so by our own rule they get no total at all. A table with four empty rows out of ten is not a ranking.

Third, weights are a choice rather than a measurable quantity. Our 50/20/20/10 encodes a view of what matters, and any other arrangement produces a different ordering. A composite pool score is always an author's decision, never a property of the pool.

How to set weights for yourself. If you run one or two machines and the threshold takes weeks, raise the weight on liquidity and lower it on profitability: half a percent of fee at that volume is worth less than a month of waiting. If a meaningful sum sits on the balance at all times, raise operator risk. If you are simply unwilling to act on unconfirmed numbers, treat data confidence as a hard filter rather than a weight, and drop level 3 and 4 pools out of the comparison entirely.

When does a composite score lie, and what has to be checked by hand?

It lies in three typical situations: when averaging hides a failure in one component, when the set of compared pools is assembled so that normalisation distorts the picture, and when the numbers inside the components come from different dates. A composite score is a convenient compression, not a verdict, and the decision comes after checking the raw inputs.

Where it breaks:

• Averaging hides a zero. A pool can post a respectable total on zero data confidence if its paper profitability leads the set. That is what the admission rule in the previous section exists for.
• Normalisation depends on the set. The same pool scores 100 on profitability among five expensive pools and 60 among fifteen. Scores are comparable within one snapshot and not comparable across snapshots.
• Dates drift apart. The fee was checked in August, network parameters were captured in September, the BTC price is yesterday's. The total looks like one coherent number while resting on three different days.
• Weights are taste. Our 50/20/20/10 encodes our view of what matters. Yours may differ, the ordering will change, and the arithmetic will not be at fault.
• Switching cost is not in the score. ViaBTC describes its PPLNS window as the past 5 difficulty rounds, and Ocean runs TIDES with a window of 8 times network difficulty. Leaving such a pool wipes out the position accumulated in the window, and a one point difference does not pay for that.
• A pool changes terms inside the scoring window. Fees and thresholds are current values, not constants. Checking monthly means spending a month acting on a stale number.

What to check by hand before you point hashrate anywhere:

1. Open the chosen pool's official fee page yourself and confirm you see the same number as the comparison.
2. Find the payout threshold and the rule on balances below it. If no rule is public, assume the remainder is lost when you leave.
3. Read the terms of service section on unpaid rewards and deadlines.
4. Confirm the payout scheme on your account matches the one in the comparison. Several pools let you pick a scheme in settings, and the default is not the cheapest one.
5. Recompute revenue on your own electricity price, not on a market average.

How do you use this method when actually picking a pool?

As a filter rather than a leaderboard. First drop the pools whose data is unconfirmed, then compute profitability on your own inputs, then look at liquidity against your hashrate, and only then compare totals across the two or three survivors. The whole thing takes an evening and saves months on the wrong pool.

The sequence:

1. Build the candidate list. A current snapshot of fees, schemes and thresholds sits in the pool cards, which also shows which figures are officially confirmed and which are not.
2. Drop everyone at data confidence level 3 or 4. This does not mean the pool is bad, it means there is nothing to compare it on.
3. Compute net BTC/day in the calculator at your hashrate and your price per kilowatt hour. Not an average, not "typical for the region".
4. Divide each candidate's payout threshold by that daily figure. That is your days to first payout. If it exceeds a month, liquidity is your dominant factor, not the fee.
5. Read the remainder and unpaid-reward clauses for the two finalists.
6. Set the weights for your own situation. If two pools land within 5 points of each other, the gap sits inside the error bars of the input data, and the tiebreaker should be what never got quantified: support language, response speed, whether a status page exists.
7. Record the date of the check and revisit it in a quarter. Fees and thresholds move, and a decision made on last year's data is no better than a decision made on rumour.

One case where the method does not apply: if you are seriously weighing solo mining, the components are the same but the weights are not, because variance stops being a parameter and becomes the entire story. That is covered in the solo against pool comparison.

In short

Comparing on fee alone works only in a quiet transaction fee market and only for a miner indifferent to payout timing. As soon as undisclosed tariffs, 0.001 BTC thresholds and unpaid-remainder clauses enter the frame, one number stops describing reality.

Four components instead of one do not make the score accurate. They make it honest: you can see what went into it, what weight each part carried, and where the data simply does not exist. A pool with an unpublished fee does not deserve a low score, it deserves no score, and admitting that beats plugging an aggregator's number into the formula.