Hashrate is Not What You Think It Is

Hashrate is the most cited number in Bitcoin, but strictly speaking, it's not a number that we can measure. There's no global gauge that tells us what the current hashrate of Bitcoin is. Rather, it's something that we estimate backwards. We infer it from blocks against difficulty over a rolling window. So a figure on a dashboard is an inference about work that must have been performed in order to produce the chain that we observe. In a steady state, that distinction doesn't matter. But under stress, it becomes the entire problem. Hashrate measures effort. Security is what happens when that effort breaks.

​

The standard model says that more hashrate is more security. In a one-period attack model, that's directionally correct. You have a larger honest network, so you have a higher work threshold for an attack. But that holds one variable constant: time. It assumes stable power costs, a stable machine fleet, that miners remain solvent, and that the capacity on paper is capacity that can respond. It assumes that operators that look independent fail independently.

​

In May of 2021, half of the global hashrate went offline within weeks. The protocol survived. The difficulty adjustment did exactly what it was designed to do. But the recovery of capital, the reallocation of fleets, the reconfiguration of power markets and supply chains took six months to two years, depending on how you measure it. Hashrate is the stock, but security is the flow, and the standard model only shows the stock.

​

Hashrate is a snapshot, but security is a trajectory. Those are different mathematical objects. You can have two networks with identical hashrate and completely different trajectories under stress. One can have miners that are lightly leveraged, run flexible power contracts, hold idled machines as reserve capacity, and operate firmware that they control. The second can have the same firmware, the same hashrate, concentrated in dense sites with short-duration ASIC-backed debt, locked into take-or-pay power, with similar firmware and exposed to the same power grid.

​

Those look the same on the dashboard, but they have very different security trajectories. The question for the attacker is not, how much hash power is there? It's how much credible hash power remains available over time. Machines that can't get power are not credible security. Sites are not credible security if the transformers have an 18-month replacement window. Operations are not credible security if the next margin shock breaches a covenant. What matters is not H, it's H of T. It's hashrate over time, and more specifically under stress.

​

The power grid, policy, firmware, and credit environments are all variable mechanisms that affect security aside from hashrate. So let's say we had a 30% hashrate shock overnight. The immediate effect is that the 10-minute block time gets divided by 0.7. You have 14.3-minute blocks. That means the time for a difficulty adjustment goes from 2016 blocks being two weeks to about 20 days. That's a 43% increase in real time right off the bat.

​

The first change that I want to make explicit is that the protocol adjustment clock itself slows, so the non-equilibrium state lasts longer. Now consider miner economics during that gap. The intuition is that with 30% gone, the remaining terahashes earn more revenue per terahash. That's partially true, but before adjustment, the original difficulty remains and the revenue per hash doesn't change on a per-wall-clock-time basis. Per unit of wall clock time, the revenue per terahash doesn't change. The difficulty adjustment is where the repricing actually occurs, but that's 20 days out.

​

Twenty days is a really long time in capital markets. That's time for operators with thin margins, operating on fixed power obligations with ASIC-backed debt, to breach their debt service coverage ratios and trigger forced curtailment, or to push collateral underwater on a mark-to-market basis. Miners do not adjust to this uniformly. Some miners survive the repricing and they benefit when the difficulty drops, but the others are gone. So the 30% shock is not just a number. It's a sorting mechanism, and it separates the capacity that's installed from the capacity that's resilient.

​

This is where security is determined. In the shock, three things happen. One, there's lower work to compete. An attacker needs 30% less work to compete with the network. Fine. Two, the network has yesterday's view of the world. The difficulty hasn't adjusted. And third, and this is the one that's often not taken into account, nobody knows the true state of the system in real time.

​

As we said earlier, hashrate is inferred. Under a real shock, nobody knows just by looking at the block times whether there's a real shock or whether it's just block time variance. Block arrival is on a Poisson process, so operations dashboards always smooth the difficulty over a rolling window. They do this because the raw signal is too noisy. Nobody can infer clean information from that stochastic signal.

​

But this induces decision lag. Exchanges, lenders, market makers, miners, insurers, and power counterparties are all trying to determine: is the miner unlucky, is the network impaired, is it entering a cascade? These entities update at different speeds and they update based on different data. This is the vulnerability window. It's not just a cryptographic window. It's an information window, a coordination window, and a liquidity window.

​

The attacker's problem changes. The required capital to compete is down. That's the cost effect. But there's also a time effect. A 60-minute confirmation time for settlement on an exchange becomes 85 minutes, 43% up. This makes coordination between adversaries easier. It makes a defender response harder. Risk policies adjust unevenly across counterparties and the defender's reaction surface fragments.

​

The resilient parties close quickly. They have flexible load. They are liquid operators. They have capacity that can return without new transformers, interconnects, new credit contracts, or new firmware deployments. But the fragile miners leave that window open, not because the protocol failed, but because the physical and financial layers couldn't respond fast enough.

​

What matters isn't the starting hashrate at the time that there's a shock. What matters is the recovery curve. Attackers don't need permanent control. They need an attack window. Security is not the depth of the curve. It's the area under the curve. And the danger moment is not low hashrate. It's unstable hashrate.

​

We have a 15-minute talk, so I'll skip over the math.

​

There are three things that are not obvious from the hashrate. One is capital. Industrial mining is financed. They have equipment loans that are collateralized by ASICs. They have project finance tied to specific sites. They have rate-linked loans, and they all have covenants. Debt service coverage ratios and collateral maintenance triggers are covenants tied to the hash price, and the revenue per hash per day determines whether those covenants are breached.

​

When the rate drops temporarily, that's not volatility. Those are triggers. The operations have to curtail or liquidate. It's not the system that failed. It's the balance sheet. Temporary protocol conditions lead to permanent loss of capacity.

​

Second is energy. What matters isn't the energy contracted. It's how flexible that energy is. Take-or-pay contracts behave like fixed cost floors during shocks. Interruptible loads can curtail when prices spike, monetize demand responsibly, and re-energize when conditions improve. It's not the largest megawatt. It's the fastest megawatt.

​

Also, as we said before, there's coupling. Networks lock onto common shared dependencies. ASIC supplies concentrate in three vendors. Even those three vendors buy capacity from the same foundries, and they have shared firmware stacks. Large transformers take 18 to 24 months for replacement lead windows. Physical destruction is uninsurable in real time under those conditions, and geographic dispersion can still mean shared exposure to one grid operator, jurisdiction, or weather conditions. From an underwriting perspective, the correlation risk looks diverse until it's stressed, and then it looks like a single position.

​

Hashrate doesn't wait for difficulty. When hashrate drops, collateral obligations trigger, credit is tightened, power contract obligations kick in, and curtailments are triggered, which cause further hashrate drops. That's the cascade. The difficulty adjustment is in protocol time, about 20 days. These things aren't waiting 20 days. They are responding continuously. Capital markets and power markets respond continuously. Credit markets respond brutally, and insurance responds when claims arrive.

​

These clocks are not aligned. The protocol is the slowest clock. There's a mismatch between the continuous response of the markets and the response of the protocol, and they can be moving in opposite directions. The protocol's observed hashrate and the market's observed risk are not correlated in that time. During that gap, when they're moving in opposite directions, a 30% shock can become a 40% problem before the protocol catches up.

​

If I compress everything I said to three points, it's recovery speed: how fast can capacity return when the window opens? Capital half-life: how long can stressed operators survive before they're forced offline? And correlation failure: how much does the system share underlying exposure?

​

These are not abstract quantities. They're specific, observable, and often priced quantities: hashrate over break-even, insurance premium changes, ASIC collateral haircuts, power optionality value, pool concentration, and supply lead times. These are measures that forecast the post-shock security. Notice that aggregate hashrate is not in that list. When the aggregate hashrate moves, the other factors have already moved.

​

Lastly, hashrate is just one layer. Hashrate measures effort, but security is how the system recovers. Bitcoin solved trust in software. It didn't solve physics: power, transformers, semiconductors, and cooling. It didn't solve capital: debt structures, covenants, and liquidity. And it didn't solve coordination: the willingness and ability of independent operators to remain online during times of stress.

​

Those don't run on Bitcoin's clock. They fail independently and recover at different speeds. The network security question is not, how much hash power is there right now? It's what happens under stress, and how quickly does it close the window. Hashrate is the last signal to know. Thank you.