In the previous post, I described the characteristics we’d want to see in a competitive heat market. In short, we want many heat networks of varying sizes to function as markets that are fast, efficient, accessible, cheap and decentralised. I also tried to show that simply copying the electricity market for heat is a bad idea.
So what model should we adopt? In this post, I propose a new model based on blockchains, the technical innovation that underpins cryptocurrencies like Bitcoin and Ether.
A blockchain? What’s a blockchain?
A blockchain is a continually updated digital ledger, the truth of which is agreed upon by the parties who write to it, even if those parties don’t trust each other. Here’s a short introduction to blockchains from PwC if you’d like detail.
Oh, and they’re super zeitgeisty and often overhyped. Silicon Valley is gaga for blockchain-based start-ups and we’re routinely promised that blockchains will fix everything from humanitarian aid to global democracy (with few meaningful results so far).
In reality, most of the time blockchains are a (very cool) solution in search of a problem. But in this case, they’re just what we need – mainly because they have a number of important characteristics:
- They’re decentralised. Each participant on the network holds a copy of the digital ledger.
- They’re constantly updated. New blocks can be added and confirmed as often as agreed by the participants. For example, for Bitcoin this is every 10 minutes.
- They’re practically indelible. Once new information has been added to the blockchain and confirmed by the other participants, it’s difficult or impossible to change.
- They enable decentralised consensus. The rules for writing to the blockchain are embodied in the software run by each participant, each of whom can “vote” to change these rules by changing the software.
- They’re low cost. Many blockchain implementations (including Bitcoin and Ethereum) are open source.
- They impose security and accountability. The use of cryptographic keys proves who did what.
Stick with me and hopefully you’ll agree that, applied appropriately, blockchains could enable the creation of a new genuinely competitive heat market.
A quick note before we start
Even as they grow and interlink, there will probably still be many district heat networks across the country rather than one monolithic network (as in electricity). Each decentralised heat network will be its own market, but there’s no reason the systems and structures I’m proposing couldn’t be used by all competitive markets in the district heat sector.
Ok, now let’s get stuck in.
Proposed model for a competitive heat market
The parties involved on each district heat network are the customers (e.g. residential or commercial blocks), generators, suppliers and the distributor. Incidentally, some market players, e.g. suppliers, could operate across multiple markets but a unit of heat bought on one network can only be sold on that same network
In my proposed model, each market relies on three key systems: an exchange, a blockchain (aka distributed ledger) and the blockchain software that determines how parties write to the ledger.
The exchange is the electronic marketplace where the parties come together to compete and enter into contracts. Importantly, it’s the main mechanism that allows pricing information to flow between the parties right up to the current settlement period. But it’s not the only way to agree a deal: parties would also be free to enter into contracts voluntarily outside the exchange.
The blockchain ledger holds:
- All contracts between parties, from the first day of operation, right up to the current settlement period. Contracts agreed on the exchange are cryptographically signed by both parties and instantly registered on the digital ledger. Contracts agreed outside the exchange only become official once they’re signed by the parties and written to the ledger.
- All payments between parties. These are records of real pounds and pence, changing hands between the parties. To be valid, these transactions must be signed, proving payment and receipt (an approach dubbed triple entry accounting).
- All heat delivered onto the network by generators, by settlement period.
- All heat taken from the network by customers, by settlement period.
Each party on the district heat network runs the blockchain software on at least one computer with a reliable connection to the internet. This means each party maintains and writes to their own copy of the digital ledger.
The blockchain software embodies the rules of the game for each network. This includes, for example, imbalance pricing method and how to resolve conflicting meter reads at a contract boundary.
All parties have the opportunity to write to the ledger, but a given party’s version will only be accepted by the other parties (and therefore written to their own local copies of the ledger) if they’ve followed the rules embedded in the agreed version of the blockchain software.
The blockchain software for district heat must be open source, just like Bitcoin and Ethereum, and totally free. This means bug fixes or improvements created by large players would automatically be shared with small players, and vice versa. Think Linux and IBM.
By reading the blockchain ledger, any party on the network can instantly determine:
- Imbalance position of all parties, include money owed or owing.
- Consumption, production and price trends.
- Distribution network losses.
- Credit history of all parties.
Some detail for enthusiasts
Only agreed parties are able to write to the ledger, though in the interests of transparency it may be desirable for the ledger to be readable by anyone. In line with this, the consensus mechanism is based on proof of stake rather than proof of work. Furthermore, there’s no need to associate a digital asset (like Bitcoin or Ether) with this blockchain.
Does this model meet our needs?
Here’s a check against our shopping list of requirements for a competitive heat market:
| Aspect | Requirement for proposed competitive heat market | Requirement fulfilled? | Detail |
| Topology | Able to cope with lots of heat networks of varying sizes | Yes | Each network would function as its own heat market, without relying on a central authority like National Grid |
| Time dependency | Similar to electricity. Perhaps hourly? | Yes | Meters connected to network and consumption written to ledger by settlement period (e.g. hourly) |
| Trust and authority | Parties on a network should be able to interact directly without reference to a central authority | Yes | Blockchain allows peers to make decisions by consensus according to agreed rules. |
| Coordination | Use price information to coordinate production and consumption up to current settlement period | Yes | The exchange could be used to form contracts up to an including the current settlement period |
| Timeliness and information flow | Imbalance position could be clear in days or even hours | Yes | Provided meters (and nodes) are connected to the internet, imbalance position could be clear within minutes of end of the settlement period |
| Transparency of imbalance pricing | Imbalance pricing should be simple, transparent and appropriate for each individual network | Yes | Imbalance pricing is calculated according to the rules embodied in the blockchain software, which is run by all parties. This doesn’t guarantee simplicity but complexity can only come with the agreement of the parties |
| Cost to suppliers | IT and people cost must be low. Cost of credit should be minimised by tightening information loop | Yes | Blockchain software is free and open source, so that development work by any party on any network can be shared across the entire sector |
Does the proposed model meet the needs of a new competitive heat market? I think it does. A lot more work would be needed before we know this approach is viable, but I hope this initial pass is sufficient to show that it’s an idea worth exploring further.
A note about transportation of heat
While customers might change suppliers and suppliers might change generators, you can’t swap out the pipes buried in the ground. Transportation of heat will always be a monopoly controlled by the owner of the pipes (for example, a Pipeco). This is the same in the electricity market where DNOs own the distribution networks.
In addition, pipes that connect generators to customers are expensive to install. A client procuring a heat network could try and get better value for money by allowing an independent infrastructure provider to install it and the standard of work might be enforced by regulation. But ultimately transportation of heat will always remain a monopoly and will almost certainly have to be regulated.
carbon limited 
Interesting stuff! 🙂
I can definitely see blockchain as a neat way of ensuring that ‘you’ always have access to ‘your’ metering/billing data – even if key people go under the bus or everybody has a spectacular contractual falling out.
Many operators are *totally* reliant on a single 3rd party for acquiring, process, and storing their data. “Don’t worry, we’re a big company,” “Don’t worry, we’ve been doing this for years,” or “Don’t worry, we’ll take care of all of this for you.” are the usual justifications. Sometimes a tender will even use these as assessment criteria.
Those attributes are nice to have in my view, but an operator should *always* have access to their data in such a way that even if there’s a spectacular failure by the 3rd party or there’s a spectacular contractual dispute there’s nothing that the 3rd party can do to *prevent* the operator from recovering from this disaster. Lots of tenders fail to consider this until the disaster happens. “They’re a big established trustworthy company and the contract we had said that they would always let us log into see our data” won’t wash as an excuse.
There are many ways to skin this cat and ensure that the operator always has access to their data for the purposes of business continuity. Blockchain makes it non negotiable at architecture level which is pretty neat and worth looking into for this reason alone.
Thoughts on blockchain based network management off the top of my head:
Whilst the exchanges could be bypassed you’ll still be baking substantial parts of “how the network operates” into the blockchain software. This will be (1) inflexible and I think (2) difficult to agree. The OMS (open metering system) lot have been trying to get a much less extensive/binding collaboration agreed since 2007:
http://oms-group.org/en/
I think it’s something that you’d want apply only after you’d thoroughly thought through the market structure and prototyped it with a more conventional (simpler to implement/iterate) centralised architecture. Worth exploring though! 🙂