Mining Profitability Model Walkthrough: From Inputs to Decision

The Spreadsheet Said Buy

We had a purchase order half-filled out for ten more units. The spreadsheet said a 14-month payback, comfortable margin, green numbers all the way down. Then someone asked what happens if difficulty keeps climbing at the pace it has for the last two quarters and uptime dips to 92% instead of the 99% we'd typed in. The 14 months turned into 23. That's the whole argument for building a real profitability model instead of trusting a single optimistic number: the base case always looks fine, because you built it to look fine.

Where These Models Usually Break

Most profitability sheets fail for the same reason — they use the electricity rate off the contract, not the all-in cost once you count cooling overhead, curtailment during peak hours, and the transformer losses nobody puts in a slide deck. They also assume a hashrate and efficiency number pulled straight from a spec sheet rather than what the machine actually does at 35°C ambient with a few thousand hours on it. Both errors push in the same direction: they make the miner look better than it will perform.

The Inputs Worth Getting Right

Five numbers do most of the work in any model that matters:

• All-in energy cost per kWh — not the headline rate, the number after cooling and any demand charges.
• Realistic hashrate and J/TH at your actual operating temperature, not the datasheet figure measured in a lab.
• Pool fee structure and payout method, since that changes effective revenue more than people expect.
• Uptime, including planned maintenance and the unplanned downtime you always assume won't happen.
• A range for difficulty growth and BTC price, not a single point estimate.

Get the energy cost and the uptime number honest and the rest of the model mostly takes care of itself.

Pool fees deserve more attention than they usually get, too. A percentage fee, a PPS model, and a solo payout structure all move the effective revenue line in different ways, and the difference compounds over a year of blocks won or missed. If you're solo mining, factor in that payouts are lumpy by design — the model needs to survive a long dry stretch between blocks, not just the average outcome.

Base, Downside, Stress: Run All Three

The workflow we use before any purchase decision:

1. Build the base case with conservative, not optimistic, assumptions.
2. Build a downside case: higher difficulty growth, lower uptime, same price.
3. Build a stress case combining every adverse assumption at once — worst plausible difficulty, worst plausible uptime, lower price.
4. Only commit to the purchase if the stress case is still tolerable, not just survivable on paper.

If the stress case shows you underwater for eight months straight, that's information worth having before the wire transfer, not after.

Keeping the Model Honest Over Time

Use the same template every procurement cycle instead of rebuilding it fresh each time. It's tempting to build a new, more optimistic sheet when you're excited about a machine, and that's exactly when discipline slips. Update the difficulty trend and current price inputs, keep the structure the same.

Honest caveat: no model predicts BTC price, and anyone telling you otherwise is selling something. The point of this exercise isn't a precise forecast — it's knowing your downside before you're in it, so a bad quarter is an inconvenience instead of a surprise.

The base case tells you if a deal looks good. The stress case tells you if you can survive being wrong.

Related Reading

Run your own numbers with the profitability calculator to model break-even and downside scenarios against current network conditions.