500MW and No Receipts

The power math

The AI buildout runs on power. Not compute - power. Projections vary by source and methodology, but converge on the same direction: data centre electricity demand is growing faster than most grid infrastructure was designed to accommodate. The discussion about whether AI will reshape energy markets is over. It already has.

What gets less attention is how the grid actually interacts with this new class of load - not as a passive consumer, but as a claimed flexibility asset.

The new industrial load

Large industrial consumers have always been significant grid participants. Aluminium smelters, steel mills, chemical plants: they have well-understood consumption profiles, decades of metering history, and established relationships with network operators. When an industrial facility commits to curtail 50 megawatts, the TSO (Transmission System Operator) has a reasonable basis for what that number means and how to verify it.

AI data centres are different in three ways that matter for flexibility markets.

First, consumption opacity. A GPU (Graphics Processing Unit) cluster’s power draw is a function of workload type, utilisation rate, cooling configuration, and dozens of variables that aren’t externally observable. The baseline - what the facility would have consumed without a curtailment signal - is not a reading. It’s a calculation. The calculation methodology is owned by the operator, not the network.

Second, claimed flexibility. Hyperscalers have begun positioning their campuses as demand response (DR) assets - large loads that can shed quickly on request. Some can. The architecture to prove they did is a separate question.

Third, scale asymmetry. A 500-megawatt campus is not a marginal flexibility participant. When it disputes a settlement, it does so with energy trading desks, legal counsel, and engineering teams whose headcount exceeds most TSO flexibility market departments. The structural imbalance is not accidental - it is a direct consequence of building settlement systems before the counterparty profile changed.

The baseline problem, again

Every demand response event produces two numbers: what the participant consumed, and what they would have consumed. The difference is the settlement. The first number is measured. The second is modelled.

The modelling methodology - how the counterfactual baseline is calculated, which version of the model was in effect, what parameters were applied - is where disputes live. Issue #007 described this architecture in terms of small and medium aggregators. The data centre case is the same problem at a different power level, with a counterparty that has resources to litigate every assumption in the baseline model.

The asymmetry is structural. Grid operators built flexibility market settlement systems when the largest participants were municipal utilities and industrial facilities. Both parties understood the same rules. The methodology was a shared assumption, not a contested artefact. That assumption no longer holds when the counterparty has a dedicated team whose job is to optimise settlement outcomes.

“Dispute-asymmetric” names something practitioners have felt for years without a precise term for it.

What verification looks like applied here

Issue #007 assembled five primitives into a minimum viable architecture for verifiable settlement: signed attestation of the metered record, a timestamp proving when the dispatch signal arrived, an immutable methodology version reference, an append-only log of the event chain, and a verifiable credential (VC) binding the participant’s identity to the claims they made.

The primitives work in the data centre case - but the implementation details are specific to how a large facility is actually instrumented, and those details are what determine whether the architecture is buildable or theoretical.

The metering layer. A large campus sits behind a utility interconnection point where grid-side metering produces the official consumption record. That record is owned by the DSO (Distribution System Operator) or TSO - not the facility. The facility has its own measurement infrastructure: a Building Management System (BMS) coordinating cooling and HVAC, power distribution units (PDUs) at the rack level, and an Energy Management System (EMS) aggregating facility-wide consumption. The gap between what the grid records and what the facility knows is where baseline disputes originate. The attestation primitive closes it: the EMS signs its consumption record at the point of origin, before any aggregation or transmission. The signing key lives in a hardware-backed key store and never leaves it. The signed record is the artefact - not the reported figure.

The baseline commitment. Before a DR event window opens, the operator’s baseline model runs against available forecast inputs: server utilisation trajectories, cooling load predictions, scheduled maintenance windows. The output — a signed baseline commitment — is submitted to the aggregator and timestamped by a TSA (Timestamp Authority — a third-party service that countersigns your data with its own clock, so neither you nor your counterparty can dispute when the commitment was made). This is the number the settlement will measure against. It is locked before the event. This detail is what most current DR implementations skip: baselines are typically calculated post-event, when the outcome is known. Moving the commitment pre-event is as much a governance change as a technical one, but it is what makes the settlement independently verifiable rather than retrospectively justified.

The event chain. When the dispatch signal arrives, three timestamps matter independently: when the signal was received, when curtailment actually began (power ramp-down observed in EMS telemetry), and when the facility returned to baseline. Each is appended to an append-only log with the signed measurement as payload. The aggregator collecting events from dozens of facilities builds this log per facility - the per-facility records are the source material; the portfolio-level settlement claim is the product derived from them.

The methodology reference. The aggregator’s baseline calculation methodology - the rules for what counts as a valid curtailment, how variance is calculated, what the tolerance bands are - is published to a content-addressed registry as a machine-readable specification. The version hash is embedded in every settlement record. Post-event, any party with the hash and the resolver endpoint can retrieve the exact methodology version in effect during the event. In markets operating under defined frameworks such as German Redispatch 2.0 or the UK DFS (Demand Flexibility Service), the methodology version may be co-defined with the TSO. In that case the registry is not just the aggregator’s internal policy - it is the agreed-upon ruleset for the market, and the hash is the stable reference both parties signed up to.

The verifiable credential. The facility operator’s identity is bound to its signed artefacts via a VC issued by the aggregator or a recognised certification body. The credential asserts: this facility, operating under this metering configuration, with this signing key. A TSO receiving a settlement claim can verify the chain without contacting the facility directly: VC → signing key → signed measurement → baseline commitment → methodology version hash. The resolver API (described in issue #007) is the lookup layer - given a methodology version hash embedded in a settlement record, it returns the exact specification document. The chain is self-contained and auditable without a phone call.

The implementation stack.

Event stream - The interval readings, signed receipts, and baseline state all flow over Apache Kafka (Amazon MSK as the managed deployment). Topic-per-facility, exactly-once semantics, log compaction for baseline state. The append-only ordering is Kafka’s native property - no separate implementation needed.

Signing service — A stateless sidecar co-located with the EMS aggregation layer. It subscribes to the raw readings topic, signs each record as a JWS (JSON Web Signature — a standard envelope, RFC 7515, that packages a payload with a cryptographic signature verifiable by anyone holding the public key), and publishes to a signed-readings topic. The signing key lives in AWS KMS using an asymmetric ECDSA P-256 key pair. KMS is hardware-backed internally — keys are stored in FIPS 140-2 validated HSMs that AWS operates — and the private key is non-exportable. Sign and verify operations execute inside the KMS service boundary.

Content-addressed store - Amazon S3 with Object Lock in compliance mode enforces the WORM policy at the storage layer, independent of application logic. The object key is the SHA-256 hash of the payload. Signed baseline commitments, methodology specification versions, and per-event attestations all land here. Deletion and overwrite are disabled at the bucket level - not as a configuration choice that can be reversed.

Event log — Three options at increasing levels of trust guarantee:

(A) The lowest-ops path is a hash-chained DynamoDB table: each item stores the SHA-256 of its payload concatenated with the previous item’s hash, with a sequence number and a facility identifier as the sort key. A Lambda function publishes a signed checkpoint to S3 on a fixed schedule - the checkpoint is the root hash of the current chain, signed with the aggregator’s KMS key. Any party holding a copy of the chain can recompute the root and verify it against the published checkpoint. This does not produce RFC-standard inclusion proofs, but it covers the tamper-evidence requirement at minimal operational overhead.

(B) For proper Merkle inclusion proofs, Trillian (Apache 2.0 — github.com/google/trillian) deployed on ECS or EKS with Aurora MySQL as the backing store produces signed tree heads and verifiable inclusion proofs that any party can check independently. The trade-off is operational: Trillian requires running and maintaining the log infrastructure, and the log operator is still a trusted party.

(C) For deployments where neither the aggregator nor the TSO should control the log, a public Layer 2 blockchain removes the trusted-operator problem entirely. The approach: store only the SHA-256 hash of the signed JWS bundle on-chain - not the reading itself, which stays off-chain and private. The on-chain record provides a consensus-enforced, permissionless timestamp, which also eliminates the need for a separate RFC 3161 TSA. Transaction costs on L2 networks (Arbitrum, Base, Optimism) are fractions of a cent, making the cadence practical at metering frequency. The caveat is regulatory: public blockchain infrastructure sits outside the established trust framework in most European energy markets, and some regulators will have views on it. The architecture is sound; the procurement conversation is harder.

Resolver API - A stateless read layer over the methodology registry: given a SHA-256 hash, return the corresponding methodology document from S3. AWS Lambda plus API Gateway, no persistent state, independently deployable by any market participant. The endpoint is cacheable; the object it returns is immutable.

VC store - Amazon DynamoDB keyed by facility identifier, storing the verifiable credential JSON and the registered public key. The TSO queries this to resolve a facility’s public key when verifying a settlement claim.

Timestamp authority — A TSA takes a hash of your data, appends a precise timestamp, and signs the combination with its own key. The signature belongs to the TSA — not to you or your counterparty — which is what makes it useful in a dispute: neither party can claim the timestamp was manipulated. The options are an eIDAS-qualified third-party provider (DigiCert, Sectigo, or equivalent), or Option C from the event log section above: if the log uses an L2 hash anchor, the block timestamp is already a consensus-enforced third-party attestation and the separate TSA requirement falls away entirely.

What this changes operationally. Most Data Centers already have the monitoring infrastructure. The gap is not instrumentation - it’s that the monitoring doesn’t produce externally verifiable artefacts. An EMS reading power consumption every 15 seconds and writing to a proprietary internal database delivers excellent operational visibility and zero settlement defensibility. The implementation delta is: add hardware-backed signing at the EMS output, publish the baseline commitment before events open, and route the signed records through an attestation pipeline that the aggregator’s settlement engine can consume. The timestamp authority, methodology registry, and VC infrastructure are the aggregator’s responsibility to provide - and ideally a shared market utility rather than a per-aggregator build. The facility’s work is largely at the metering layer, which is where its control is greatest and where the trust gap is widest.

Two markets worth watching

The architecture is directly applicable in two markets that are moving faster than most.

Switzerland is an early candidate. Swissgrid operates one of Europe’s most complex transit grids — a hub for power flows between Germany, France, Italy, and Austria — and manages more than 10 gigawatts of pumped hydro storage, the continent’s largest. Cross-border flexibility settlement already involves multiple TSOs, multiple baseline methodologies, and no shared source of truth. New AI data centre investment is accelerating, driven by renewable energy availability and political stability. Every new large load that enters the Swiss flexibility market adds another counterparty to a settlement framework that was not designed for them. The verification architecture maps directly onto that coordination problem, and Switzerland’s position outside EU regulatory structures (ElCom, not ACER) means operators have more room to adopt it without waiting for Brussels.

The UAE presents a different dynamic. DEWA and the ADNOC-linked utilities are building modern grid management infrastructure without the legacy settlement systems that constrain European operators. G42, Core42, and Microsoft are developing substantial AI data centre capacity in Abu Dhabi and Dubai. Facilities built now have the option of incorporating a verification stack from day one — the greenfield advantage most European operators no longer have. What gets written into UAE data centre PPAs this year is likely to become the template for broader GCC adoption.

The bankability signal

There is a financial dimension worth noting. Long-term power purchase agreements for AI data centre loads are increasingly conditioned on verifiable flexibility commitments - infrastructure investors funding storage assets behind them want evidence that flexibility markets settle reliably. Trust infrastructure is, in this context, a financing condition rather than a compliance overhead. It is not the primary argument for building this stack, but it is the argument that tends to get a budget approved.

What comes next

A data centre is a single participant with a large footprint. The same verification challenge at the scale of a virtual power plant (VPP) - where thousands of distributed assets aggregate into a single flexibility product - is several orders of magnitude more complex. Batteries, heat pumps, electric vehicles, commercial buildings: each has its own baseline problem, its own metering infrastructure, its own methodology.

The primitives from arc one still work. The governance structures required to apply them across thousands of participants, under a regulatory framework that treats AI-dispatched aggregators as critical infrastructure, are a different problem.

That’s where this newsletter goes next.