What your effective pool fee actually is

Your pool advertises a rate. What you paid is a different number, and the gap is usually small enough to ignore and occasionally large enough to move pools over.

Measuring it is straightforward. Measuring it correctly has one trap that makes most attempts wrong in an obvious direction.

The method

Compute what the network paid out for the work your fleet did, compare it to what your pool credited, and the difference is your effective fee:

expected_sats = (your_hashrate ÷ network_hashrate)
                × 144 blocks/day
                × block_reward
                × days

effective_fee = 1 − (actual_paid ÷ expected_sats)

Network hashrate comes from difficulty:

network H/s = difficulty × 2³² ÷ 600

The trap: which block reward

This is where most calculations go wrong.

An FPPS pool pays the subsidy and the transaction fees. So do PPS+ and PPLNS. If you compute expected from the subsidy alone — 3.125 BTC — while your pool is paying subsidy plus fees, then actual will exceed expected and your effective fee comes out negative. The arithmetic says your pool is paying you a bonus.

It is not. You used the wrong baseline.

Transaction fees have recently run around 0.8–0.9% of the block reward, with individual blocks well over 2%. An honest 2% pool measured against a subsidy-only baseline looks like it charges about 1.2%. The error is comparable in size to the thing you are trying to measure.

So: match the baseline to your pool's scheme. Full block reward for FPPS, PPS+ and PPLNS. Subsidy alone for plain PPS.

The second trap: matching windows

Both sides of the comparison have to describe the same stretch of time.

If you have difficulty data for two days and payouts for twenty, and you divide one by the other, you will get a large negative number that has nothing to do with your pool. The expected side must cover exactly the days the actual side does — and if you only have partial network history, the honest answer is that you cannot state a fee yet, not a confident wrong one.

The third trap: payout cadence

If you slice the comparison into windows shorter than your payout interval, the window containing a payout looks like a windfall and the windows between look like a 100% fee. Whatever period you measure over should contain several payouts.

What is a normal answer

A well-run FPPS pool measured correctly comes out within a few tenths of a percent of its advertised rate. Published examples put Foundry around 0.31% effective against a 0% advertised headline, which is the sort of small positive gap that reflects rounding and timing rather than anything untoward.

An effective fee that comes out at −248%, or 87%, is not a fee. It is a broken expectation — almost always a mismatched window or machines earning into the pool that are not in your calculation.

Solo is different

For a solo pool, none of this applies. Solo pays the whole block or nothing, so dividing what you were paid by what you "should" have earned reports a 100% fee for every month without a block. That is variance, not a fee, and the right figure to look at instead is expected time to a block.

JouleBook computes this automatically, follows your pool's declared scheme, and declines to state a fee when it cannot do so honestly rather than printing a number. Start free, or read how attribution works.