What hashprice includes, what it hides, and how to use it when you are deciding between hosting offers rather than trading a position.
Hashprice gets quoted the way a stock price gets quoted: one figure, updated constantly, treated as though it speaks for itself. For a trader watching a position, that treatment is roughly fair. For a fleet owner comparing hosting offers, it is not, because the number is a snapshot of several moving parts compressed into one, and a decision about where to place hardware for years needs to know what is inside that snapshot, not just what it currently reads.
What the number is made of
Hashprice is a measure of expected revenue per unit of hashrate over a fixed period, usually expressed per terahash per day. It is built from three components that move independently of each other: the block subsidy and transaction fees a miner can expect to earn for a given amount of work, the network difficulty that determines how much work is required to earn that reward, and the market price of the coin, which converts the reward into a currency figure. Change any one of the three and the headline number moves, even if the other two hold still. A hashprice figure with no note on which of these moved, and by how much, tells you that revenue per unit changed without telling you why, and the why is what determines whether the change is temporary or structural.
Why difficulty, fees and the averaging period move it
Difficulty adjusts on a fixed schedule based on how much hashrate is competing on the network, and it moves up or down at each adjustment as capacity joins or leaves the network. That means a hashprice figure calculated today is already implicitly assuming today's difficulty, and it will read differently the moment the next adjustment lands, independent of anything the coin price does. Transaction fees add a second layer of noise on top of the block subsidy, and fees can vary considerably from one period to the next depending on network activity, in a way that has nothing to do with hashrate or price at all. Neither of these components is something a hosting decision can control, but both of them are baked into any single hashprice figure you are handed, which is exactly why one number from one day is a weak thing to plan a multi-year placement around.
The period over which the number is averaged adds a third distortion on top of the other two. A hashprice series is volatile by construction, since it inherits volatility from the coin price on top of the steadier drift from difficulty. An average taken over a long window smooths that volatility away and can understate how often the actual daily figure sits well below the average, the same way an annual availability average can understate a genuinely bad month, a pattern our piece on uptime and availability looks at in more detail. A single day's reading has the opposite problem: it captures a real number but tells you nothing about where in the range that day sits. Neither a long average nor a single snapshot is wrong on its own. The mistake is using either one as though it were the whole picture, rather than asking where the current figure sits against its own recent range before treating it as representative.
Reading it against your hosting cost, not against the market
Hashprice is a revenue figure. It only becomes decision-useful once it is set against a cost figure measured in the same unit, which for a hosted fleet is the hosting rate expressed per terahash. A machine's efficiency, in joules per terahash, converts your per-kilowatt-hour hosting rate into a cost per terahash you can put directly against the hashprice figure: cost per terahash per day = rate per kWh × efficiency in J/TH × 24 ÷ 1,000. When hashprice per terahash per day sits comfortably above that cost, the machine is covering its hosting bill with margin left over. When the two figures sit close together, small movements in any of hashprice's three components can flip the comparison, and you want to know that before it happens rather than after.
Setting a shutdown threshold without pretending to forecast
The useful exercise is not predicting where hashprice goes next. It is knowing, in advance, at what hashprice figure your specific hardware, at your specific hosting rate, stops covering its own power cost. That threshold is arithmetic, not forecasting: it is the hashprice level at which revenue per terahash equals the cost per terahash the formula above gives you. Once that number exists, checking a hashprice reading against it is a fast, mechanical comparison rather than a judgement call made under pressure during a bad week. What is your hosting rate per kilowatt hour today? What is your machine's efficiency in joules per terahash? What cost per terahash per day do those two give you? Those three questions, answered once and kept current as your hosting rate changes, do more for a placement decision than watching the daily figure move.
What to work out before you compare offers
Before treating hashprice as the basis for comparing two hosting offers, work out your own shutdown threshold using the arithmetic above, and convert each host's rate per kilowatt hour into a cost per terahash yourself, with the same efficiency figure for every offer. Ask whether that figure is fixed or indexed, since a threshold calculated against a rate that can move is only good until the next reset. And ask what happens operationally at your site if the comparison turns unfavourable: is curtailment or shutdown something you control, or something the host manages on your behalf?
This requires no guess about where the coin price or the network difficulty is headed. It requires knowing your own numbers well enough that a hashprice reading is something you can check against a threshold rather than a headline you have to react to. Our hosting rate page explains how a rate per kilowatt hour is built and what sits inside the base rate, which is the figure your machine's efficiency converts into a cost per terahash, and the terms used here are defined in our glossary.
