Price the Tail, Bid the Curve: How a Battery Should Offer Into the Day-Ahead Market

Ask someone new to storage how a battery makes money and you will get a sensible-sounding answer: forecast prices, buy the cheap hours, sell the expensive hours. Under that mental model, the core asset is a good price forecast, and the output is a schedule: charge at 2 AM, discharge at 7 PM.

I want to argue that this model is wrong in two specific ways, and that fixing it changes what a bidding system should compute. The strategy object is not a forecast and not a schedule. It is a curve: the marginal value of stored energy, as a function of time and state of charge. Everything the battery submits to the market is a derivative of that one object.

Fact one: the money lives in the tail

ERCOT prices spend most of their life between roughly $15 and $80 per MWh. A few hours a year, they reach $500, $1,000, or the offer cap. The distribution is violently right-skewed, and the skew is where storage revenue concentrates: a single scarcity event can be a third of a month's revenue, and a battery that misses the one spike that mattered can post a fine average capture rate and a terrible year.

This has an immediate consequence for forecasting. A point forecast of tomorrow's expected price is nearly worthless, because the expected price barely moves on the days that decide the P&L. What moves is the probability of a spike, its likely severity, and its duration. A two-hour battery earns radically different money from one four-hour spike than from four scattered one-hour spikes, so even the temporal shape of the tail is load-bearing. The forecasting target has to be a calibrated distribution over the whole day, tails and hour-to-hour dependence included.

Fact two: nobody bids during the operating day

The second correction is about market mechanics. During delivery in ERCOT, there are no interval-by-interval decisions. SCED, the real-time dispatch engine, solves roughly every five minutes and dispatches each battery against its standing offer curves, subject to transmission constraints and telemetered state of charge. It issues a base point, publishes a price, and moves on. It does this 288 times a day.

The real-time "decision" is therefore entirely embedded in the shape of the curves on file. Offer your discharge steeply and SCED calls on you only in scarcity. Offer flat and you are dispatched constantly. The craft of operating a battery is encoding your price beliefs, your state-of-charge preferences, and your opportunity costs into piecewise-linear curves that a mechanical optimizer interacts with all day long.

So the deliverable is not a schedule. A schedule says what you will do. A curve says what you would do at every price, which is the only language the dispatch engine speaks.

The object in the middle: the value of a stored megawatt-hour

Put the two facts together and the right computation drops out. If revenue depends on an uncertain, fat-tailed future, and the market wants state-dependent willingness-to-sell rather than a plan, then the thing to compute is the value of energy in the tank: what a marginal megawatt-hour of state of charge is worth, at each hour, given everything that might happen next.

Call that quantity mu. It comes from working backward through the day: the value of energy at hour 18 depends on what it could earn at hour 19 and beyond, averaged over the scenarios your forecast assigns probability to. Two properties make it usable. It is decreasing in state of charge: the fuller the battery, the less another megawatt-hour is worth. And it is bounded and well-behaved, which means the curve it induces is monotone, which is exactly the shape the protocol requires a submission to have.

The reading I find most clarifying: mu is the internal transfer price at which the battery's present desk and future desk trade energy with each other. Every decision in the system reduces to a comparison against mu.

The offer curve is the derivative of the value function

Once you have mu, bid construction stops being a heuristic. The battery should be willing to sell a marginal megawatt-hour exactly when the market price exceeds what that megawatt-hour is worth if kept, adjusted for efficiency losses and cycling cost:

discharge offer price at fill s  =  mu(s) / discharge efficiency + cycling cost
charge bid price at fill s       =  charge efficiency * mu(s)

Sweep the state of charge from full toward empty and you trace the discharge curve: the first megawatt-hours out are offered cheap, because the battery is full and marginal energy is low-value; the last ones are offered dear, because they are the reserve held back for scarcity. Because mu decreases in state of charge, the resulting curve is monotone in price. It is submittable as-is.

Here is the part I find genuinely elegant. File those curves, and SCED, maximizing mechanically against them every five minutes, implements the optimal policy for you: the spike-chasing, the hoarding ahead of a risky evening, all of it, with no intra-hour human action. The dumb dispatch engine executes your stochastic control problem because your curve is the derivative of your value function.

Why calibration is a revenue line, not a statistics nicety

This construction consumes quantiles at specific probability levels, which is why calibration outranks sharpness. If your fitted 95th percentile of price is really the 90th, your mu is inflated at low state of charge, and the battery systematically hoards energy for spikes that arrive half as often as priced. That is not a modeling blemish. It is a quantifiable leak, paid every day the miscalibration persists. An honest wide distribution loses less money than a confident wrong one.

The same logic disciplines evaluation. The industry's standard benchmark, TB2, is the revenue an omniscient trader would earn by charging in the two cheapest hours of the day and discharging in the two most expensive. It is a fine yardstick and a terrible target: it is computed with realized prices nobody had at bid time. The honest question is what fraction of that opportunity a strategy captures using only information available before each deadline, scored walk-forward, with spike days reported separately from normal days. Perfect foresight is a denominator, not a strategy.

What this asks of a bidding system

Three things, and none of them is a better point forecast.

First, calibrated distributional forecasts with an explicit spike model: probability, severity, and persistence, verified against outcomes.

Second, a value computation that turns those distributions into mu, and curve construction that turns mu into compliant offers for energy and ancillary services, with committed positions handled carefully, because a day-ahead sale changes the risk calculus of every curve behind it.

Third, honest measurement: point-in-time backtests, attribution that separates forecast misses from execution misses, and benchmarks used as denominators rather than promises.

Price the tail. Bid the curve. The rest is plumbing, and the plumbing matters, but only in service of those two ideas.