What the halving does to a fleet, and how to be ready

Bitcoin pays miners in two parts: a block subsidy created by the protocol, and the transaction fees users attach to their payments. Roughly every four years, after 210,000 blocks, the subsidy halves. It is not a market event or a surprise, it is arithmetic written into the software, and the date can be estimated a year ahead.

What makes it hard is that it lands in a single block. There is no ramp. On one side of that block your fleet earns a number, and on the other side it earns meaningfully less for exactly the same work and the same power bill.

What actually happens to your revenue

The subsidy portion halves. The fee portion does not. So the drop in your total revenue depends on what share fees make up at the time, and that share has varied a great deal. In a quiet period, halving the subsidy takes most of your income with it. In a period of heavy network use, fees cushion the fall. Planning on a heavy fee period is planning on a hope.

In the language of hashprice, a halving is a step change downward. Everything on your site that was marginal before is unprofitable after, immediately.

The second effect, which is slower and helps

When revenue per unit of hashrate falls, the least efficient machines on the network stop paying for themselves and get switched off. Network hashrate falls, difficulty adjusts downward, and the remaining miners earn more per unit. That recovery is real but it is not instant, and it has never fully restored the figure from before the halving on its own. Historically the coin price has done more of the recovering than difficulty has, which is a market bet, not a plan.

Working out where your fleet sits

The exercise is simple and worth doing a year early. Take every model on your site, work out its breakeven power price at today's hashprice, then again at roughly half. Sort the fleet by the second number. You now have three groups: machines that still work after, machines that only work if the coin price rises, and machines that are finished.

That third group is not a disaster, it is a decision with a deadline. Those machines have resale value now and much less afterwards, because everyone else is running the same calculation on the same models at the same time. The used market for older generations softens noticeably before a halving, not after.

What operators actually do

• Rotate early. Sell the oldest generation while it still has a buyer and put the proceeds into efficiency. This is the argument in phasing a buildout, and a halving is the deadline that makes it concrete.
• Underclock the middle group. Machines that fail at default settings sometimes survive underclocked, because efficiency improves faster than hashrate falls. See tuning a fleet.
• Renegotiate power before, not after. Your leverage with a supplier is highest while your site is clearly viable.
• Build cash. The months after a halving are when hardware is cheapest and operators with liquidity buy well. Being the forced seller instead is the expensive side of that trade.
• Do not buy the oldest machine on the market because it looks cheap. It is cheap because of the date on the calendar.

Buying across a halving

If you are purchasing in the year before one, run your payback model on revenue after the halving, not today's. A machine that pays back in two years at current hashprice may not pay back at all if half of that period sits on the other side of the step. Our note on payback covers the model; the halving is simply the largest single input you can actually predict.