A 500MW/1GWh battery struggles to reach profitability on a single stream of power sales. Scotland’s Coalburn 1 BESS built a long-term revenue base by stacking three contracts — power optimization, capacity market and ancillary services. That layering is the core of how a utility-scale BESS business case works.
Current condition: A large BESS that relies only on price swings in the wholesale power market has unstable revenue.
Change after application: Coalburn 1, developed by Copenhagen Infrastructure Partners (CIP), combines a 10-year power optimization contract with SSE, a 15-year capacity market contract covering 300MW, and a 7-year ancillary services contract covering 75MW. The battery system was supplied by e-STORAGE, a subsidiary of Canadian Solar.
Connecting logic: Each of the three contracts covers a different risk (price volatility, supply shortage, frequency regulation), and stacking contracts with different maturities shrinks the revenue gap that would otherwise open when any single contract ends.
Comparison by contract type
| Contract type | Term | Risk covered |
|---|---|---|
| Power optimization | 10 years | Price volatility |
| Capacity market | 15 years (300MW) | Supply shortage (peak response) |
| Ancillary services | 7 years (75MW) | Frequency regulation |
What this table says: The shorter the contract, the more flexibility it offers, but the larger the re-contracting risk — Coalburn 1 lowered that risk by spreading its maturities.
CIP is building three BESS projects in Scotland totaling 1.5GW/3GWh, including the follow-on Coalburn 2 and Devilla, and plans to expand into a 4.3GW grid-scale BESS portfolio across Great Britain.
Reading the three contracts from the equipment side
On paper the three contracts are financial instruments. On site they are three different operating demands placed on the same battery racks and the same PCS. The optimization contract rewards moving energy in and out when prices diverge, which means frequent charge-discharge cycling and wide SOC swings. The capacity market contract rewards being available when the system is short, which means holding energy in reserve rather than spending it. The ancillary services contract rewards fast response to frequency deviation, which means keeping headroom in both the charge and discharge directions at all times.
These demands pull in different directions. Arbitrage wants to empty the battery at the price peak; the capacity obligation wants energy still in the battery when the peak arrives; frequency response wants the battery parked near the middle of its SOC range. The contracts therefore do not simply add up. They have to be arbitrated inside the EMS, and the arbitration rules become as much a part of the business case as the contract prices.
The fact that the capacity contract covers 300MW and the ancillary contract 75MW of a 500MW asset is significant here. Each contract is written against a defined share of the plant, not the whole of it. That leaves the operator with a partitioning problem: which share of power and energy is committed to which obligation at any given hour, and what happens to the remainder.
Contract character comparison — what each one asks of the plant
| Item | Optimization | Capacity market | Ancillary services |
|---|---|---|---|
| Cycling intensity | High | Low (event-driven) | Frequent, shallow |
| SOC requirement | Wide swings allowed | Reserve must be held | Mid-range headroom |
| Response speed | Market-interval scale | Called ahead of stress | Fastest of the three |
| Revenue driver | Price spread | Availability | Availability and performance |
| Degradation exposure | Largest | Smallest | Moderate |
The table shows that the three contracts differ not only in the risk they hedge but in how they consume the battery. The optimization contract is the one that wears the cells; the capacity contract is the one that constrains dispatch; the ancillary contract is the one that dictates control speed. A stacked-revenue BESS is only as good as the rules that decide which of these wins when they conflict at the same moment.
Decision order for a stacked-revenue BESS
- Confirm the markets exist. Check that a capacity market and a procured ancillary services market are actually open to storage in the target region. Without them, the structure collapses back to a single revenue stream.
- Map maturities on one timeline. Lay out each contract’s start and end. Any year in which several contracts expire together is a re-contracting cliff, and it should be treated as a design risk, not a finance footnote.
- Write the dispatch priority rule before signing. Decide in advance which obligation takes precedence when an arbitrage opportunity, a capacity call and a frequency event overlap, and how SOC is reserved for each.
- Allocate the degradation budget. Cycling from the optimization contract consumes cell life that the longer capacity contract still depends on. The warranty and augmentation plan have to cover the longest contract term, not the shortest.
- Check availability penalties. Capacity and ancillary contracts pay for being available. Maintenance windows and PCS outages have to be planned against those terms.
Items to verify: the exact dispatch arrangement between the optimization counterparty and the capacity and ancillary obligations at Coalburn 1 has not been described in the information above, and should not be assumed.
Boundary conditions
This structure pays off in regulatory environments such as Great Britain, where capacity and ancillary services markets are mature. In regions where such multiple markets have not formed, dependence on a single PPA is unavoidable and the risk is larger.
The advantage also narrows if the EMS cannot arbitrate between obligations in real time. A plant that is contractually stacked but operationally single-purpose will either miss capacity calls or leave arbitrage value unused, and the stacking becomes a source of penalties instead of stability. The single selection criterion is this: does the target market offer at least two independent, contractable revenue streams with staggered maturities? If yes, stack them; if no, the project is a single-PPA bet and should be evaluated as one.
