Why the Same Termination Fee Schedule Doesn't Work for Every Large Load

A data center service agreement and a crypto mining service agreement can use the identical six-provision checklist — load commitment and phase milestones, infrastructure cost allocation, termination and stranded cost, creditworthiness and security, power quality obligations, renewable energy access — and still leave the utility with two very different levels of protection. The provisions aren’t the problem. The calibration is.

The Termination Fee Has to Track Actual Stranded Cost

The formula is simple: termination fee equals the un-amortized infrastructure cost minus the cumulative rate recovery to date. On a $10 million dedicated infrastructure investment, that fee is the full $10 million in year one, because nothing has been recovered through rates yet. By year five, if $1.67 million has come back through depreciation and rate recovery, the fee is $8.33 million.

The core problem: a step-down schedule copied from the last agreement, rather than built around the load type sitting in front of you, either overprotects a customer that never posed much risk or leaves ratepayers exposed to a customer that does.

The pace of that decline has to match the risk profile of the load, not a generic amortization schedule:

• Crypto mining: front-load the fee. The largest exposure sits in years one through three, because that’s when departure risk is highest and the equipment behind the load can be gone in weeks. No economic hardship exception belongs in this agreement — the obligation has to survive a facility sale or a bankruptcy, with successor language that says so explicitly.
• Hyperscale data centers: a gradual step-down, roughly 10–12% a year, tracking the infrastructure as it’s paid down through rates.
• Industrial loads and electrolyzers: tied more directly to the depreciation schedule itself, since abandonment risk is lower and, for electrolyzers, often paired with a policy change clause if IRA credits are eliminated or modified.

Security Has to Be Sized to Maximum Exposure, Not Average Expectation

The deposit gets posted before construction begins, not after. In practice, I use this preference order:

1. Irrevocable letter of credit — fastest draw, and the utility’s only remaining risk is the bank’s, not the developer’s.
2. Cash escrow — no counterparty risk at all, though it ties up more of the developer’s capital.
3. Performance bond — works, but the draw is slower and a surety can dispute how a default gets characterized.

A parent company guarantee should never be the sole security instrument. It’s the one form of protection most likely to fail exactly when the utility needs it — when the developer itself is under financial stress.

Risk Isn't Uniform Across Load Types

The stranded asset risk table below is the reference point I use when a rate case or negotiated agreement crosses my desk. It's also the piece I'd want a commission asking about before approving any large-load rate application or special contract.

Load TypeStranded Asset RiskStep-Down PaceCrypto MiningVery HighFront-loaded (Years 1–3)AI Compute / TrainingHighGradual, with spike provisionsElectrolyzerModerate–HighModerateHyperscale Data CenterModerateGradual (~10–12%/year)EV Charging HubModerateModerateIndustrialLowerDepreciation-based

Five Questions Worth Asking Before Approval

1. Does the rate recover full incremental cost — and if not, is the exact shortfall quantified and the party bearing it identified?
2. If a cross-subsidy exists, are the benefits quantified through an independent economic impact analysis, not developer projections?
3. Are the stranded cost protections calibrated to this specific load type, or borrowed from the last filing?
4. Is security posted before the utility spends anything, sized to maximum exposure rather than average expected outcome?
5. What is the impact on every other customer class if this load leaves early?

Those questions apply the same way whether you're drafting the service agreement provisions themselves or working out how the rate is priced against the customer's load factor. Once the agreement is signed, how the developer's contribution actually gets booked — and whether it reduces rate base at all — is a separate question I've covered in how these deferred infrastructure costs are treated under ASC 980.

The checklist doesn't change from one load type to the next. The numbers behind it should.