How to calculate per-machine Bitcoin mining profitability

Your pool pays one wallet. Your power bill arrives for a building. Somewhere between the two is the question you actually want answered: what did this machine earn, and what did it cost?

This is how to work it out, whether you do it in a spreadsheet or use something that does it for you.

Step 1: split the payout by work done

A pool payout covers a window of time and the work of every machine running during it. The share each machine earned is its share of the work:

share(machine) = (hashrate × active_hours)
                 ÷ Σ over all machines (hashrate × active_hours)

Worked through, for a payout of 2,400,000 satoshis over 24 hours:

Machine C came online late in the day and earns proportionally. This is the part a naive per-machine average gets wrong: dividing by three would have given C 800,000 satoshis it did not earn, taken from A and B.

Two things that matter more than the formula

Work in whole satoshis. Not BTC as a decimal, and never a floating-point number. Compute each share as an integer, then check the parts sum to exactly the payout. Rounding three shares down leaves a remainder of a satoshi or two; give it to the largest holder rather than letting the total drift.

Value it at the time of receipt. Record the fiat value using the BTC price when the payout arrived, and never revalue it later. If Bitcoin doubles next month, your October revenue did not double — you did not receive it in November. Revaluing history produces a figure that is wrong for tax, wrong for margin, and wrong for any decision it informs.

Step 2: compute what the machine cost to run

kWh  = watts × active_hours ÷ 1000
cost = kWh × rate_per_kWh

For a 3,250 W machine running 744 hours in a month at $0.045/kWh:

kWh  = 3250 × 744 ÷ 1000 = 2,418 kWh
cost = 2,418 × 0.045     = $108.81

Use the same active hours you used for the revenue split. A machine that ran a third of the month should be charged for a third of the month, and using whole-month hours for cost while using partial hours for revenue will make every part-month machine look unprofitable.

Step 3: put it together

The spreadsheet

Here is the whole thing as a working spreadsheet, with the formulas already in it and no email required:

Download the per-machine profitability worksheet (.xlsx)

Three sheets: your inputs, one row per machine with every formula above wired up, and the method written out. It ships with a four-machine example — including one that came online mid-month, because that is the row most hand-built sheets get wrong.

Two things in it are worth looking at even if you never use the sheet:

The share column divides work by work, not machines by machines. Change the active hours on the last row and watch its share fall proportionally. An equal split would have given it a full month of revenue it did not earn, taken from the machines that did.

The unallocated row. Flooring each share leaves a couple of satoshis unassigned — the sheet shows them rather than hiding the discrepancy. In a real system that remainder goes to the largest holder so the parts sum to exactly what the pool paid. A sheet whose columns quietly fail to add up is a sheet you cannot audit.

Doing this by hand works. It takes most operators the better part of a day each month, and it is difficult to check afterwards — which is the problem, not the arithmetic.

Where estimates creep in

If you have no telemetry, you are using nameplate hashrate for the split. That is a reasonable approximation for a fleet of identical machines and a poor one for a mixed fleet — and it can never tell you that one of two identical machines is underperforming, because by construction they are identical in the model.

Whatever you build, label the estimated figures. A number that looks like a measurement and is not is worse than no number.

JouleBook does all of this from your payouts automatically, including the part-month arithmetic and the estimation labelling. Start free — one site and 25 machines, permanently, or read how attribution works first.