Mining 2026-06-25

Most sites are more optimized than their owners think. The problem isn't effort. It's where the effort is pointed.

TL;DR

TL;DR: Energy contract negotiations, pool fee reviews, and software audits feel productive because they produce visible results. But overcurtailment, underperforming ASICs, and unmonitored auxiliary loads are often larger leaks. The fix isn't to stop negotiating contracts. It's to know your actual numbers before deciding which conversation deserves your time.

The Real Math on Energy Contracts

Let's get this out of the way first, because anyone who runs the numbers will call it out.

Saving $0.004 per kWh on a 50 MW site is worth roughly $1.75 million per year. That's not a rounding error. That's a meaningful improvement to your margin structure that protects you when hashprice drops, regardless of uptime.

The problem isn't that operators negotiate contracts. The problem is that some operators stop there, treating the contract as the primary lever and treating everything else as secondary overhead.

A site losing 5% of potential hashtime to avoidable overcurtailment, running several hundred ASICs with undiagnosed performance issues, and that site has a larger optimization gap than most contract negotiations will close. And if you don't know those numbers, you can't make that comparison honestly.

The argument here isn't that contracts don't matter. It's that operational visibility is what tells you whether the contract is your biggest lever or your second biggest one.

What Overcurtailment Actually Is (and Isn't)

Curtailment on ERCOT is part of the deal. If you're participating in grid programs, you have obligations to your QSE, and you curtail when the grid needs you to. That's expected, it's compensated, and experienced operators manage it well.

Overcurtailment is different. It's the hashtime you lose beyond what the program requires.

It shows up in a few ways. Trigger thresholds set too conservatively during price-responsive events, so the site goes down earlier or more often than necessary. Ramp-ups that take 30 to 45 minutes when the grid condition cleared in 10 minutes. Curtailment logic that doesn't distinguish between a 5-minute spike and a sustained 2-hour event.

Operators who have audited this typically find it accounts for 2 to 4% of potential hashtime. On a 50 MW site at current economics, that's a real number.

One important caveat: constantly power cycling your miners during the summer heat can accelerate PSU failures, hashboard delamination, and thermal paste degradation, and scale this to a 50MW site, this is a significant repair cost.

The goal isn't to ramp up and down quickly, or to curtail unnecessarily, but instead to find a balanced method that allows you to curtail only when necessary, staying on a while longer while analyzing market conditions, and power cycling systematically to minimize damage to the equipment.

Fleet Averages Are Hiding Your Worst Machines

If your dashboard says your site is running at 96% of rated performance, you might feel reasonably confident.

You shouldn't.

That 96% is an average. It can easily include 40 machines running at 78%, 80 machines running at 91%, and a handful at 99% pulling the number up. The 78% machines are your actual problem, and fleet averages won't surface them.

The causes are usually recoverable: firmware drift, dynamic power scaling bugs, clogged intake filters, degraded thermal paste, dead hash boards. None of these require replacing the machine. All of them require knowing the machine has the problem.

Here's where the data conversation gets real, though. A 50 MW site runs 14,000 to 16,000 ASICs. Unit-level telemetry on a fleet that size doesn't give you a cleaner picture, it gives you an overwhelming one, unless the system is built to prioritize and act, not just report.

The difference between useful telemetry and alert fatigue is whether the platform surfaces the 40 machines that actually need attention today versus generating 400 low-priority notifications about minor efficiency variance across the fleet. Granular data is only an asset when it's organized around what your team can actually do something about.

Most operators find underperforming machines by spending hours and hours looking at multiple spreadsheets, during a maintenance cycle or when a rack gets swapped. The goal of good telemetry isn't to replace that process with more screens. It's to make the problem findable before it has compounded for three months.

The Energy Budget You're Probably Not Tracking

Most mining operations have reasonable visibility into their ASICs. Hashrate, power draw, uptime. These numbers are tracked.

What often isn't tracked is everything else.

Cooling systems, variable frequency drives, ventilation, PDUs, and auxiliary electrical loads can represent 20 to 40% of total site power. When those systems aren't instrumented, they run as fixed overhead. Fans at constant speed regardless of ambient temperature. Cooling units cycling on schedules set at commissioning.

One thing worth being direct about: instrumenting these systems in an industrial mining environment is not a simple retrofit. Bitcoin mines are high-EMI environments. Wireless sensors fail or drop packets regularly in these conditions. Doing this properly typically requires hardened industrial infrastructure, wired integrations, and real engineering work. It's not plug-and-play, and any vendor who tells you it is isn't being straight with you.

What it is, is worth doing. The operators who have built out this visibility run their auxiliary loads as a managed cost instead of a fixed one. That's a structural advantage that compounds over time, especially as energy prices become more volatile.

How to Figure Out Where Your Leaks Actually Are

Before the next vendor negotiation, run a quick audit of your real numbers.

Start with curtailment recovery time. Pull your ERCOT event logs from the last 90 days and measure the average time between a trigger condition clearing and your site reaching full output. If that number is consistently above 20 to 25 minutes, you have an overcurtailment gap worth quantifying in hashtime.

Then pull your fleet performance distribution. Not the average. The distribution. How many machines are running below 90% of rated performance? Below 95%? If you don't have that breakdown available without digging, that's your first data gap.

Then look at your auxiliary energy consumption. What percentage of your total site power goes to non-compute loads? If you don't know, you can't optimize against it.

Run those three estimates. Compare the result against what you'd recover from renegotiating your pool fee or squeezing a software contract. That comparison tells you where to spend your time.

What Changes When You Have the Data

Operators who have instrumented their sites at this level describe a consistent shift. They stop reacting and start operating.

Curtailment events get handled by defined logic instead of whoever picks up the phone first. Fleet degradation gets caught when a machine drifts, not during the next maintenance window.

None of that replaces the operator. Telemetry doesn't fix a machine. Automation doesn't negotiate your PPA.

What changes is the quality of information that the manager is working with, and how much of their time goes to decisions that actually require their judgment versus issues that should be handled automatically before they even hear about it.

The best-run operations don't treat contract negotiation and operational telemetry as competing priorities. They use their data to know which one matters more right now, and they execute on both.

LōD gives data center operators real-time energy intelligence, fleet-level telemetry, and automated curtailment response built on real-time grid data. If you want to see what your operation is actually leaking, request a site assessment.