4CP Defense Without an Operator in the Loop

In ERCOT, a consumer's transmission charges for the following calendar year are set by their demand during just four 15-minute intervals — the single highest system-wide demand interval of each summer month, June through September. These four intervals are known as the 4CP (4 Coincident Peaks). The mechanism is unforgiving: if your site is consuming power during a 4CP interval, you anchor a full year of transmission costs to that load. If you are off, your fixed cost basis is anchored to zero.

For a large mining customer, the difference between curtailing on the right interval and missing it can be six or seven figures per year. The frustrating part is that you only learn which 15-minute window became a 4CP interval after the fact — at the time of the event, you have to make a decision with incomplete information, and you have to make it within the interval itself, before ERCOT closes the books.

This is a real-time decision problem with high asymmetric cost: false positives (curtailing when you didn't need to) cost some forgone revenue; false negatives (not curtailing during a real 4CP) cost a year of transmission charges. A defensive bias is rational, but only up to a point — curtailing too often becomes its own cost in ramp wear, operational churn, and lost runtime.

What if you didn't have to watch the grid yourself? What if a single integrated system could decide when to curtail, and dispatch that decision directly to your mining fleet — automatically, every interval, throughout the entire 4CP season?

That is exactly what we built. Together with our Intelligent Miner (our fleet-control product), the decision engine described in this post forms a hands-off 4CP defense system: your fleet curtails and recovers, without an operator in the loop.

What makes real-time CP detection hard

Stripped of context, the 4CP problem is a sequential decision under delayed feedback: across the four summer months, ERCOT publishes roughly twelve thousand 15-minute intervals (about three thousand per month), and exactly four of them — one per month — set a year of transmission charges. At each interval, the call must be made on incomplete information, with no way to revise. The naive approach of "watch the grid demand and curtail when it crosses some line" is defeated by three structural features of the problem.

1. The ground truth arrives too late. The 4CP is a property of the 15-minute interval after it closes — only knowable in retrospect, once ERCOT settles the books. But to defend against it, the site has to be physically off-grid during the interval, and powering a mining fleet down is not instantaneous — the curtailment command has to land early enough that the equipment has finished ramping by the time the peak materialises. The gap between when the answer is observable and when the action is required forces every firing decision to be made on incomplete information about an event that has not yet finished.
2. Load oscillates near the line. When system load is oscillating near the firing threshold, a naive design produces short ON→OFF→ON dispatch cycles. Each cycle has a real cost: ramp-down, ramp-up, ramp-down, ramp-up, with thermal cycling on equipment and revenue interruptions on each leg. Across a 4CP event the cumulative cost can exceed the value of the curtailment itself, and operators lose trust in the system. Any workable solution has to absorb these oscillations without delaying real fires.
3. The target keeps moving. The 4CP is the highest interval of the month, so the target a defense system is trying to anticipate is itself a running maximum — it only moves in one direction (upward) and never settles until the month closes. Every new high resets the level that matters for the rest of the month, making the decision problem path-dependent: the same load reading can be a fire-worthy candidate one day and a non-event the next, depending on what the running peak has done in between.

Formally, the problem is binary classification in a sequential, partially observed setting, under the highly asymmetric loss introduced earlier. Combined with the three structural obstacles above — observability lag, boundary noise, and a moving target — these features define the shape of the decision problem the rest of this post addresses.

An intelligent decision engine

This is where the system we built lives. The decision engine is the runtime that converts the abstract problem above into a concrete, every-5-minute decision: it pulls in the relevant ERCOT data, evaluates a firing rule against them, and dispatches CURTAIL alerts to the site's load infrastructure when the rule says fire. The rest of this section walks through its three pieces — estimating the coincident peak, deciding whether to fire, and dispatching the signal.

Estimating the coincident peak

Every five minutes, the decision engine asks itself one question: how close are we to a new monthly peak right now? The number that answers it is what we call the estimated CP load. It is "estimated" because the actual value is only known at interval close — too late to act on; it is "CP load" because it strips out components of the raw ERCOT system load that are not counted against mining consumers under the 4CP rule.

The estimated CP load is recomputed every 5 minutes, not every 15. The 4CP itself is a 15-minute interval, but waiting until the close of each 15-minute window costs you five minutes of latency — a third of the 4CP interval itself. Sampling at 5-minute granularity gives the decision engine three independent opportunities to fire within each 4CP interval, which is the difference between a curtailment that lands in time and one that lands too late.

Each 5-minute value is built from three quantities:

• Actual system-wide load — the most recent observed demand on the grid.
• Forecast system load — ERCOT's own projection for the upcoming interval. Pulling in a forward-looking signal alongside the observed actual is what allows the decision engine to fire in time during a steeply ramping peak, rather than reacting after the interval has already closed and the 4CP has already been set.
• Wholesale Storage Load (WSL) — aggregated battery charging on the grid. WSL shows up as system load but is not counted against mining consumers in the 4CP calculation, so the decision engine accounts for it on the consumer's behalf rather than penalising the site for grid-level charging activity.

Fire or not to fire?

Imagine watching grid demand climb toward what could become a new monthly peak. There are two options. The first is to wait until load actually crosses the existing peak and then curtail. This is mathematically optimal but operationally impossible: by the time the actual load tips over the existing peak, the 15-minute interval is already most of the way through, and the physical curtailment lag — the time it takes for site equipment to actually power down — means you cannot react fast enough. The 4CP peak is set before your dispatch lands.

The second option, the one the decision engine implements, is to curtail before the crossing — accepting that some of those curtailments will turn out to have been unnecessary, in exchange for the lead time required to physically be off the grid when a real peak hits. We encode that lead time as a margin below the running monthly peak, and call it the buffer.

That settles when the decision engine must fire (preemptively), but not which intervals deserve a preemptive fire. The decision engine signals CURTAIL only when a 4CP peak is genuinely plausible — not on every interval where load happens to be high. The asymmetric loss introduced earlier shapes the architecture of the rule: the cost of a false negative dwarfs the cost of a false positive, so the decision engine biases toward firing — but it also refuses to fire in regimes where, by construction, no 4CP can occur. Burning a curtailment on an interval that is mathematically incapable of setting a monthly peak accumulates operational cost without buying any insurance. The decision rule is therefore a conjunction of necessary conditions: the decision engine fires only when all of them hold simultaneously, and a single failure suppresses the alert.

Formally, fire(t) ⇔ C₁ ∧ C₂ ∧ C₃, where each Cᵢ is one of the conditions below (evaluated at the same t):

• C₁ — Minimum grid-wide demand. When ERCOT-wide load is too low to mathematically threaten the monthly peak, the interval is skipped regardless of any site-level signal. This lower bound is a necessary condition for 4CP plausibility: no interval below it has ever set, or could realistically set, a monthly peak in the historical record.
• C₂ — Distance from peak. L(t) ≥ peak(t) − b, where L(t) is the estimated CP load, peak(t) is the running monthly peak, and b is the buffer (introduced above). No alert fires while L(t) < peak(t) − b.
• C₃ — Noise tolerance. Brief oscillations of grid load around the firing threshold are absorbed by a one-sided hysteresis: the decision engine fires the moment load crosses the firing threshold, but waits for the signal to fall cleanly below it before clearing. The asymmetry is deliberate — entry is fast and exit is slow, because spurious re-entries cost ramp wear and re-dispatch latency that compound across a 4CP event.

The conjunctive structure is itself a consequence of the asymmetric-loss framing. Condition C₁ is a suppressor: when it fails, the conditional probability of being inside a 4CP is essentially zero, so the cost of suppression is also essentially zero. Conditions C₂ and C₃ are operational: they govern how the decision engine behaves once a peak becomes plausible. The split mirrors the loss structure — cheap to suppress when 4CP is implausible, fast to fire when it is.

Among the three conditions, only one has a tunable parameter: the buffer b in C₂. C₁ (the load floor) and C₃ (the hysteresis) are fixed by the structure of the problem; the buffer is the design knob. Rather than leaving customers to pick an arbitrary number, we offer three calibrated tiers.

These tiers are calibrated against historical 4CP seasons; in the offered range, every historical 4CP would have been anticipated by all three, so the wider tiers are insurance against future seasons being more extreme rather than in-sample optimality.

Dispatching the signal

When the decision engine signals CURTAIL, the alert is handed off to Intelligent Miner, the fleet-control half of the integrated solution. Intelligent Miner translates the curtailment decision into miner-level dispatch on the ground: it picks which units to power down (and in what order) according to the site's operational constraints, ramp-down timing, and recovery profile — then brings the fleet back online once the alert clears. The decision engine decides whether to curtail and when; Intelligent Miner decides how. The split keeps each half focused on the problem it solves best: detection and timing on one side, physical orchestration on the other.

How much downtime should I actually expect in a month?

A natural follow-up question is: for a given buffer tier, how much curtailment time should a site expect per month?

The honest answer is that it varies — and the dominant factor is not the buffer choice alone, but when during the month the peak materialises.

Here is why. The firing threshold is the running monthly peak minus the buffer, and the running monthly peak only moves in one direction: it ratchets upward as new highs are observed, and never backward. When the peak for a given month is set early — say, in the first week of June — the threshold for the remaining three weeks sits relatively high, and few subsequent intervals come close enough to the running peak to trigger another curtailment. When the peak is set late — for instance, in the final week of the month — the threshold spends most of the month at a lower running value, which means many more intervals during those weeks fall within buffer-distance and the decision engine fires more often.

This can be stated formally. Let t* denote the day of the month on which the running peak was first set, and let D denote the total curtailment hours accumulated over the entire month. Because peak(t) is non-decreasing in t, the firing threshold peak(t) − b is also non-decreasing, which means the threshold sat at a lower value during the days before t*. The later t* is, the more days the threshold spent at that lower value — and therefore the more intervals had a chance to fire. Under stationarity-like assumptions about the conditional distribution of grid load given when t* was set, this makes D non-decreasing in t* in expectation: the later in the month the peak lands, the more curtailment hours you accumulate on average. This is a directional argument, not a strict theorem: in particular, t* is endogenous — conditioning on a late t* implies that prior loads stayed below the eventual peak, which biases pre-t* loads downward and partially counteracts the lower-threshold mechanism.

The relationship is sharp empirically. (Spearman ρ measures monotonic association in [−1, 1]; ρ → 1 means rankings track each other.) An empirical backtest on the 2024 and 2025 summer seasons (eight months), run through the decision engine at the default 1000 MW buffer, yields a Spearman ρ above 0.9 between the day-of-month on which the monthly peak was first set and the total monthly curtailment hours — high enough to be visible by eye in the scatter below, though with only eight months the underlying statistic carries wide confidence intervals (the directional pattern is far more robust than the exact value).

The pattern is visible across the backtested months. Peaks set in the first week (days 1, 4) produced 14–23 hours of curtailment. Peaks set mid-month (day 18) produced 40 hours. Peaks set in the final week (days 24, 28) produced 66–67 hours.

For tier-level averages across the full season, the same backtest gives the values below — with 4CP recall at 100% across all three tiers:

Per-site override: the system-wide-load threshold

The buffer-based logic above covers the standard case well. But some customers want a second, stricter signal — typically because they want to curtail defensively whenever grid-wide demand reaches a high absolute level, rather than waiting for the buffer to be crossed.

For these sites, we support a per-site override: a system-wide-load threshold set on the site's configuration. When the ERCOT-wide system load crosses this value, the alert fires regardless of any of the standard filters the decision engine would otherwise apply. It is a manually configured emergency brake — useful for high-risk sites or for shadow-running a more aggressive curtailment policy alongside the buffer-based default.

With the override active, the firing predicate becomes a disjunction with the buffer-based rule:

fire(t) ⇔ (L(t) ≥ T_site) ∨ (C₁ ∧ C₂ ∧ C₃)

where T_site is the per-site absolute threshold. The OR structure has a strict consequence: the override can only add fires, never remove them. A site with the override enabled always curtails at least as often as the same site without it.

The two rules are complementary by design. The buffer-based rule is adaptive: its firing threshold floats with the running monthly peak, so it always sits a fixed distance below whatever level the site has already proven it can be curtailed against. The override is absolute: its threshold is a fixed MW value chosen by the operator, independent of where the monthly peak currently sits. The two defend different things — the adaptive rule defends against the next monthly peak, while the absolute rule defends against any high-demand interval, useful precisely when the running peak has already moved well above current load and the adaptive rule has gone quiet.

Geometrically, the buffer-based rule fires in the region { L(t) ≥ peak(t) − b }; the override fires in the region { L(t) ≥ T_site }. The firing region is the union of the two. The override's distinctive contribution is the slice where L(t) ≥ T_site but L(t) < peak(t) − b — intervals at absolutely high but relatively low load, which the adaptive rule actively sleeps through because the running peak has moved above current load. For a site that has already absorbed a high monthly peak, the override is the only way to maintain a fixed minimum level of defense for the rest of the month.

Closing

ERCOT 4CP is a high-leverage problem: a single 15-minute decision sets a year of transmission costs. The hard part is not deciding what to do — every operator knows the answer is "curtail" — but knowing when, with enough lead time to act, and without flapping the load on every minor oscillation. The decision engine answers each: a forward-looking estimated CP load, a conservative firing logic that filters out intervals that cannot become 4CPs, noise tolerance that absorbs short oscillations without delaying any real fire, and a per-site override for customers who need a stricter trigger.

What makes this different from off-the-shelf CP signaling: most products stop at producing a signal and leave the fleet-side dispatch to the customer to wire up. Our integrated stack — decision engine plus Intelligent Miner — handles both halves, so there is no operator in the curtailment path and no integration burden on the customer side. If you operate mining load in ERCOT and 4CP charges are material to your operating budget, this is the kind of system that pays for itself in a single summer.

Interested in getting started? Visit luxor.tech/energy or reach out to [email protected].

— Happy Hashing!

About Luxor Technology Corporation 

Luxor delivers hardware, software, and financial services that power the global compute and energy industry. Its product suite spans Bitcoin Mining Pools, ASIC Firmware, Hardware trading, Hashrate Derivatives, Energy services, a Miner Management software, Commander, and a bitcoin mining data platform, Hashrate Index.

Disclaimer

This content is for informational purposes only, you should not construe any such information or other material as legal, investment, financial, or other advice. Nothing contained in our content constitutes a solicitation, recommendation, endorsement, or offer by Luxor or any of Luxor’s employees to buy or sell any derivatives or other financial instruments in this or in any other jurisdiction in which such solicitation or offer would be unlawful under the derivatives laws of such jurisdiction.

There are risks associated with trading derivatives. Trading in derivatives involves risk of loss, loss of principal is possible.