Five Primitives No One Assembled

The design constraint

Minimal doesn’t mean undersized — it means constrained. Every component must close a specific gap. Anything that adds complexity without closing a gap is out.

The five properties a verifiable settlement record must satisfy: provenance, reproducibility, ruleset versioning, tamper-evidence, independent verifiability. Each maps to a building block. None of the building blocks are novel. The work is the composition.

The five building blocks

Provenance → Signed attestation

A signed attestation is a structured record of lineage: what inputs were used, what executed, in what environment, at what time — signed by the party that ran the calculation.

What it requires at runtime: a settlement completion event on an append-only event stream triggers the attestation pipeline. The attestation payload — input data references, methodology version identifier, execution timestamp, output hash — is signed using an asymmetric key pair where the private key lives in an HSM (Hardware Security Module) backed key store and never leaves it. The signed attestation is written to a content-addressed object store: the SHA-256 hash of the payload is the object key. Write-once policy enforced at the storage layer. The address of the object is permanent and deterministic — the same payload will always resolve to the same address.

The result: a per-settlement artefact that is tamper-evident by construction. Any modification changes the hash, which changes the address. The original is always retrievable at its original address.

Reproducibility → Machine-readable methodology specification

A methodology that can’t be implemented to convergence by independent parties isn’t a specification — it’s a description. The building block is a schema-defined, machine-readable methodology document where every tie-break is explicit, every adjustment deterministic, and the definition validated against a shared test suite.

What it requires at runtime: the methodology document is published to the same content-addressed object store as attestations. A SHA-256 hash identifies each version permanently. A thin API layer maps human-readable version aliases (v1.2.3) to content hashes — the alias can be updated, the hash cannot. A pub/sub notification fires on new version publication; downstream systems subscribe and validate the new spec against the shared test suite before accepting it in live settlement. If the test suite fails, the version is not accepted.

The hermetic build principle applied to energy settlement: same inputs, same methodology version, same environment equals same output. If two independent parties diverge, the discrepancy is in the inputs — not in the interpretation.

Ruleset versioning → Immutable methodology registry

Settlement records need a permanent, stable reference to the methodology version that produced them. Not a name — a content-addressed identifier. The same way @1.2.3 in a package registry refers to exactly one artefact permanently, a methodology registry assigns stable identifiers and keeps old versions permanently accessible.

What it requires at runtime: WORM (write-once, read-many) storage policy enforced at the infrastructure layer — not application-level logic. Objects are immutable on write. Deletion is disabled. Old versions are not archived; they are permanently online. A settlement record from October 2023 carries a hash that resolves to exactly the rules in effect in October 2023, regardless of what was published later. Any party with the hash and the resolver endpoint can fetch the exact spec that ran.

Tamper-evidence → Append-only Merkle log

Corrections are legitimate. The question isn’t whether they should be allowed — it’s whether they should be silent. Certificate Transparency (RFC 9162) solved this in PKI (Public Key Infrastructure): every issuance is appended to a public, cryptographically-structured log. You can’t amend a prior entry. Corrections are new entries that reference what they supersede.

What it requires at runtime: an append-only event stream is the write path — entries can be added but not modified or deleted. Periodically (by entry count or time window), a Merkle tree is built over the accumulated entries and the log operator signs the root hash, timestamp, and entry count — this is the Signed Tree Head (STH). The STH is published to a well-known endpoint. Any entry can produce a Merkle inclusion proof: a path from the entry to a given STH root that any party can verify with the root hash and the entry content. No callback to the log operator required.

The cross-operator property: any two STHs from overlapping entry ranges must be consistent — one must be a verifiable prefix of the other. Inconsistency is cryptographic proof of log misbehavior. Independent operators exchange STHs; the consistency check is the audit mechanism.

Independent verifiability → Verifiable Credential

W3C Verifiable Credentials 2.0 is a published standard for structured, signed, selectively-disclosable claims. A settlement record structured as a VC (Verifiable Credential) — carrying the log reference, the attestation hash, and the methodology version identifier — can be verified by any party with the issuer’s public key.

What it requires at runtime: each issuing party publishes a DID (Decentralized Identifier) — did:web:tso.example.de or equivalent — with a DID Document at a well-known URL containing their public key. The VC is issued in W3C VC 2.0 JSON-LD format. Selective disclosure is handled via SD-JWT (IETF) or BBS+ signatures: a verifier can confirm that a specific field satisfies a constraint without the holder revealing the underlying value. A Bitstring Status List endpoint handles revocation. Verification is fully offline: resolve the DID, fetch the public key, verify the signature. No call to the issuer.

Commercial sensitivity is a first-class design requirement here, not an afterthought. An aggregator can prove delivery to a regulator without disclosing dispatch profiles to a competitor. A verifier gets the proof they need; they get nothing else.

The runtime layer

The five building blocks share four cross-cutting components:

Event streaming — an append-only, replayable event stream connects the settlement system to the attestation pipeline. Settlement completion fires an event; the event triggers attestation; the attestation triggers log append; the log append triggers VC issuance. Each step is decoupled and independently retryable. The stream is also the replay substrate: any historical settlement can be re-run from the original event, with the original inputs and methodology version, to produce a verifiable reproduction.

Key management — HSM-backed key store with non-exportable private keys, role-scoped access, and full audit logging on every signing operation. The signing service exposes a single endpoint: present a payload, receive a signature. Private key material never leaves the HSM (Hardware Security Module). Key rotation produces a new DID Document version; old keys remain verifiable for historical records.

Timestamping authority — an RFC 3161 TSA (Trusted Timestamp Authority) issues a signed timestamp token on each attestation at creation time. This is a third-party timestamp — independent of the issuer — that binds the attestation to a specific point in time in a way that is verifiable without trusting the issuer’s clock. Useful when the question is not just what was calculated but when the calculation was locked.

Resolver API — a single external-facing interface: resolve a methodology version hash to its document, query a log for an inclusion proof, verify a VC against its issuer DID, fetch an STH (Signed Tree Head) from any operator. This is the surface aggregators, regulators, and auditors interact with. The underlying components don’t need public exposure; the resolver provides a controlled interface.

A settlement event triggers the pipeline. The baseline calculation produces a signed attestation carrying the input references, the methodology version hash, and an RFC 3161 timestamp. The attestation is appended to the Merkle log; the log returns an inclusion proof. The chain — attestation, log reference, methodology version, issuer DID — is wrapped in a Verifiable Credential. One object. Any party that holds it can verify it offline, without contacting the issuer or the log operator.

The multi-party problem — and why blockchain is the wrong answer

Here is where most proposals go off track.

The obvious objection: who runs the log and the registry? If a system operator runs both, the conflict of interest the architecture was meant to address is just relocated — not resolved.

The obvious answer people reach for is blockchain. No single operator, no single point of control. The appeal is genuine.

The problem is that it doesn’t solve the problem — it relocates it. Someone decides which chain. Someone decides which consensus mechanism. Someone selects the validators. The governance problem migrates to a layer that is less visible, less accountable, and harder to reason about than a named operator running a log. The energy sector has seen approximately one thousand blockchain-for-settlement proposals in the last decade. Most of them died at the governance question they were supposed to solve.

Equigy got the governance model right — and used blockchain as the trust mechanism

Equigy is worth examining here. Founded in 2020 by TenneT, Terna and Swissgrid, it is a neutral crowd balancing platform that gives aggregators a single interface to multiple TSO flexibility markets. No single TSO controls it. Multi-party ownership is the explicit design choice. The governance instinct is exactly right — neutral shared infrastructure, no dominant party, a single interface that works across market boundaries.

Equigy used blockchain (Ethereum) as its trust mechanism.

The architecture in this issue is reaching for the same governance outcome. Multi-party, neutral, no single controller. The question it answers differently is whether the trust layer underneath that governance model needs to be a distributed ledger.

CT-style federated Merkle logs are not a novel idea requiring industry buy-in to a new protocol. They are the same infrastructure that has secured every HTTPS connection since 2018. Multiple independent operators each run a node and publish signed tree heads. Consistency between operators is verifiable cryptographically. Any party can check any entry against any operator. No blockchain required — just the same cryptographic commitments and multi-operator coordination that Certificate Transparency has run in production for over a decade.

The Equigy governance model is the template. The log federation is the trust mechanism. They compose cleanly.

What this looks like in practice

An aggregator dispatches a portfolio of commercial buildings for a demand response event under Redispatch 2.0.

Under the current architecture: the TSO calculates the baseline, posts a settlement statement, and the aggregator receives a number. Dispute means asking the party whose number you’re disputing to review it.

Under the minimal architecture: the TSO’s system produces a signed attestation on settlement — input days referenced by hash, methodology version identified by content address, output hashed, signed via HSM, timestamped by the RFC 3161 TSA. The attestation is appended to the log. The settlement record is issued as a VC against the issuer’s DID.

The aggregator’s platform resolves the methodology version hash, fetches the spec, runs the same calculation against the same inputs. Same number — or a flagged discrepancy. If a discrepancy surfaces: both parties hold the same inputs, the same spec, the same signed output. The dispute is about the delta. Not about access to the working.

The TSO hasn’t lost authority. The calculation is still the TSO’s calculation. What’s changed is that it’s auditable — by the aggregator, by the regulator, by any party the VC is presented to — without the TSO’s involvement. The conflict of interest isn’t resolved by removing the TSO from the process. It’s resolved by making the process observable.

The part that isn’t a technology problem

Every component in this architecture is in production somewhere. Content-addressed object stores are commodity infrastructure. HSM-backed key management is standard in financial services. Append-only event streams with replay are the backbone of modern data platforms. RFC 3161 TSAs are built into every major PKI deployment. W3C VC 2.0 has multiple production implementations. Merkle logs run Certificate Transparency at global scale.

The hard part is governance: who publishes canonical methodology versions, who endorses trusted log operators, who sets inclusion policy. Equigy shows what that governance structure looks like — multi-TSO, neutral, shared ownership. The open question is whether the trust mechanism underneath it needs to be a distributed ledger or whether the CT (Certificate Transparency) model gets there with less friction.

This resolves through adoption, not design. DTCC emerged because counterparty risk got bad enough that the industry built shared infrastructure. SWIFT came from banks tired of correspondent banking overhead. Let’s Encrypt came from making certificate issuance cheap enough to become ubiquitous.

The settlement verification layer will follow the same pattern. An aggregator or software vendor, tired of losing disputes they should win, builds the attestation layer as a commercial differentiator. A regulator, tired of adjudicating disputes a verifiable record would have avoided, starts requiring log references in settlement documentation. Adoption creates the governance question in a form regulatory bodies can answer — because by then, there are working systems to point at.

The technology is ready. The sequencing is what it always is: commercial pressure precedes regulatory mandate.

Next

The next question is deployment: where does this architecture land first, and what does the minimum viable deployment look like in a specific market? The candidates — UK DFS, Redispatch 2.0, Gulf flexibility markets being designed from scratch — each have a different build order. The architecture is the same.

Sources

· SLSA framework: slsa.dev

· Certificate Transparency, RFC 9162: datatracker.ietf.org/doc/html/rfc9162

· W3C Verifiable Credentials Data Model 2.0: w3.org/TR/vc-data-model-2.0

· SD-JWT — Selective Disclosure for JWTs (IETF): datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt

· RFC 3161 — Internet X.509 PKI Timestamping Protocol: datatracker.ietf.org/doc/html/rfc3161

· Equigy crowd balancing platform: equigy.com

· ACER Network Code on Demand Response (March 2025): acer.europa.eu

· NESO Demand Flexibility Service: neso.energy