What changes for the fleet owner and what changes for the host, and why the two do not feel the same event at the same time.
A halving is a scheduled, known-in-advance change to the block subsidy, and still it produces the same round of questions every time it approaches: what happens to my revenue, what happens to my hosting rate, and why does the answer seem to depend on who at the site you ask. The mechanism is simple enough to state in one line. What it does to a fleet owner's numbers and what it does to a host's numbers is not the same event, arriving on the same day, and treating it that way is where most of the confusion starts.
What changes on the day
A halving reduces the block subsidy paid to miners for each block found, which is one of the components that make up a miner's reward per unit of work. It does not touch transaction fees, and it does not touch the market price of the coin, both of which continue moving independently on their own schedules. The mechanical effect, holding fees and price constant, is a drop in expected revenue per terahash, because the same amount of work now earns a smaller subsidy for producing it. The size of that drop follows from the mix: at constant price and difficulty, revenue per terahash falls by half the subsidy's share of the reward. Our piece on hashprice explained goes through the components that make up that figure in more detail, and a halving is a clean, one-time change to exactly one of them, which is why it can be reasoned about on its own rather than folded into the general noise a hashprice reading carries day to day.
How difficulty responds, and on what schedule
Revenue per terahash falling does not mean every miner keeps running at the same pace regardless. Difficulty adjusts on its own fixed schedule based on how much hashrate is competing on the network, and the least efficient hardware on the network (the machines whose revenue per terahash was already closest to their operating cost) is the first to become unprofitable once the subsidy drops. As that hardware powers down, network hashrate falls, and difficulty adjusts down at its next scheduled interval to reflect the reduced competition. That adjustment does not happen instantly, and it does not happen continuously. It happens on the network's own schedule, which means there is a window between the subsidy drop and the difficulty response where revenue per terahash sits at its lowest relative point, before easing back somewhat as the least efficient hashrate exits and difficulty catches up.
Working out your own shutdown threshold in advance
The exercise to do before a halving arrives, not after, is the same threshold arithmetic that applies to any hashprice reading: at what revenue per terahash does your specific hardware, at your specific hosting rate, stop covering its own power cost? Because a halving is a known, scheduled change to the subsidy component, you can model its mechanical effect on that threshold ahead of time without forecasting the coin price or difficulty at all, simply by asking how a lower subsidy, on its own, moves your revenue per terahash relative to the cost side of the comparison. Doing that calculation before the event means you walk in knowing whether your fleet sits comfortably above the threshold, close to it, or already below it once the subsidy halves, rather than finding out from a week of thin margins after the fact.
Why the host feels it on a different clock than you do
A fleet owner's revenue moves the moment the subsidy changes, because that is what a miner is paid for the work already being done. A host's position is different, for reasons that are easy to overlook. A host with a fixed-rate hosting agreement is paid the same rate regardless of what a fleet owner's hardware is earning that week, so the halving does not move the host's revenue directly at all. What it moves, with a lag, is occupancy: if enough fleet owners on site find their hardware unprofitable at the new subsidy level and power down or leave, the host's utilised capacity falls even though its rate did not change. That is a slower-moving effect, tied to how many customers cross their own shutdown threshold and how quickly, not a same-day repricing. A host paid through a revenue share, or a rate indexed to hashprice, feels the event closer to how a fleet owner does, which is exactly why which structure you are on matters here as much as it does anywhere else in the agreement.
What to raise with your host, and what to have ready
A few things belong on the list before the event rather than during it. Ask what your hosting rate is measured against and whether it moves in response to network-level revenue changes at all, since a fixed rate and an indexed rate behave differently here and the difference is contractual, not a metering question. Check the notice period and minimum term attached to your agreement, so you know how much room you have to adjust or exit if your own threshold calculation shows the fleet moving towards unprofitable territory. Ask whether the agreement has any built-in adjustment clause for exactly this kind of scheduled, known event, rather than only for unscheduled price moves, since a halving is predictable enough that some agreements address it directly and others leave it to fall under general rate-review language. And bring your own threshold numbers to that conversation rather than opening with the headline figure, since a specific calculation of where your fleet sits relative to its cutoff gives the host something concrete to respond to instead of a general concern about the market.
None of this requires predicting where the coin price goes after the event, and the mechanical part (what the subsidy change does to revenue per terahash on its own) is knowable well before the date arrives. What you need ready is your own threshold, your agreement's notice and adjustment terms, and a clear question for your host about which of those terms applies once the subsidy drops. Our hosting rate page explains how a rate per kilowatt hour is built and what sits inside the base rate, which is the cost side of that threshold calculation.
