An introduction to decentralised technologies in the energy sector

Arran Kitson
May 17, 2019 · 10 min read

Part 1 in the Energy & Blockchain blog series by Validity Labs AG

Photo by seabass creatives on Unsplash

This is the first in a series of three posts by the Validity Labs team on the application of decentralised technologies to the energy sector from both a business model and technology perspective:

  1. Introduction (this article);
  2. Practical lessons from building a Proof of Concept (PoC) in one week;
  3. Moving from PoC to implementation — how the energy sector can deploy decentralised technologies and learn by doing.


Decentralised technologies fundamentally challenge the traditional traditional client-server model and enable peers on a network to transact directly with each other and to share an objective consensus on the state of ledger of transactions (whether financial, data or other).

Within the energy sector this opens the possibility for a range of new business models (platform use cases), and automation and process improvement opportunities (process use cases). On the platform side this includes peer-to-peer energy markets, micro-transactions for mobility applications and investment vehicles for financing and governing generation and flexibility assets through Decentralised Autonomous Organisations (DAOs) and on the process side it creates opportunities for streamlined and/or auditable certificate or origin tracking, billing, switching, metering and other processes.

Blockchain is an early stage technology which is developing rapidly. This, as well as the regulatory environment in which energy market participants act, are key considerations to bring into use case selection, business model design and the resulting architecture for any product that is being built. We briefly summarise some of the lessons learnt from both our recent client projects as well as giving an introduction to our own internally developed Proof of Concept for a community owned battery (through a DAO) where withdrawal capacity can be traded within the local community of prosumers and consumers.

The key lessons we list include: a pragmatic, and realistic, approach to the current and future capabilities of the technology, designing with customer and product in mind (not just the technology which is an enabler, not the business model or product itself), and an agile and iterative approach to product design, testing and build.

What are decentralised technologies?

The prevailing model for digital infrastructure is centralised: a large number of clients (computers, mobile devices etc) use the internet (or intranet) to access an application or database sitting on a permissioned centralised server behind a firewall.

The components of this client-server models include:

  • Browser;
  • Applications;
  • Processing;
  • File storage;
  • Data storage;
  • Communications and other protocols tying it all together.

While the rise of cloud computing has meant that it is increasingly cheap and fast to deploy such applications, a centralised model has a number of important weaknesses including:

  • Centralised servers mean a single point of weakness — if they go down the whole network goes down;
  • A centralised server is a honeypot for exploits, hacks and thefts of data; and importantly
  • It requires intermediaries and trust in individuals and third parties; and
  • It results in duplication since all actors keep their own database on its own island, which require confirmation and reconciliation processes between them for inevitable differences and errors, rather than one shared ledger upon which consensus is reached.

The term “decentralised technologies” is a broad catch-all for a set of digital technologies which challenge the traditional centralised server model of prevailing software-hardware infrastructures. It is much more than just blockchain (or DLT) and includes:

  • IoT devices and sensors producing ever increasing amounts of data;
  • Distributed Ledger Technology (including blockchain) and various forms of distributed ledger, computation and processing;
  • Communication layers;
  • Second layer scaling and payment solutions; and
  • Decentralised data and file storage.

A decentralised technology stack shares similar components to the centralised alternative with one truly fundamental difference — instead of being held on one server behind a firewall data is held across multiple nodes. For example in the case of blockchains, if they are included within the specific decentralised technology stack, multiple nodes have the same copies of the same ledger and reach consensus on the current state of the network and the transactions within it, rather than disparate databases on centralised and permissioned servers.

Web3* compatible browsers (and/or integrations including wallets) access decentralised applications (that are often a bundle of smart contracts) which may be linked to decentralised file and data storage (such as IPFS and BigchainDB) and oracles (external data sources e.g. price feeds); use a virtual machine (or similar) for processing, and that in turn is all tied together by communication, messaging, routing and other protocols, and with consensus on the state across the nodes determined by a consensus mechanism. The components of the stack are similar, but how they are delivered is very different.

*Web3 is the term used for the severless and decentralised web as opposed to the current server-client Web2.0.

What are the potential use cases in the energy sector?

Decentralised technologies have a number of potential advantages compared to traditional models:

  • — rather than relying on trusted intermediaries, trust can be placed in the system (hence the term “trustless”), giving the potential for disintermediation through peer-to-peer transactions and the resulting efficiencies and return of value to the peers from fewer layers of buyers, sellers, intermediaries, brokers etc;
  • — blockchains provide a record of transactions that cannot easily be amended, if at all. This means that they can be an objective source of “truth” that is transparent, traceable and auditable. This does not, of course, mean that all data needs to be publicly disclosed — what is on-chain or off-chain, whether a private/permissioned blockchain is used, whether privacy features are used etc is an architectural choice — but it does mean that what is chosen to be public becomes immutable, transparent and traceable;
  • — since peers on the network have read and write to the same ledger (assuming a public blockchain), there are no longer multiple fragmented sets of the same data and transactions sitting on isolated islands. Instead all peers have a common ledger of transactions that is shared and upon which consensus is reached systematically by the consensus mechanism;
  • — there is no central server to be taken off-line or exploited and if a node goes down the network as a whole will continue to operate;
  • — smart contracts (effectively code which can self execute if certain parameters are met, or functions are called) create the potential for automating processes.

In the context of energy markets these advantages create a wide range of possible implementations. As the 2016 dena report on blockchain in the energy transition summarises well, there are broadly two bundles of use cases in the energy sector: platforms and processes.

Platform use cases involve the accelerated liberalisation of existing markets, the creation of new marketplaces and interfaces that are not possible with a centralised architecture.

The most clear example are peer-to-peer energy markets where producers and consumers of energy (or flexibility) can transact directly with each other without intermediaries. Projects and pilots are running for peer-to-peer transacting at both the wholesale and retail trading levels.

Another example would be the creation of local flexibility markets where ancillary services can be bought and sold at an extremely granular level of the distribution grid, all directly between the owner and user of the flexibility.

Decentralised Autonomous Organisations (DAOs), and tokenisation of ownership rights, enable a structure for funding investment in generation and flexibility assets, as well as in their governance and the disbursement of dividends or similar rewards to investors, and tradeability of the resulting tokenised ownership rights (subject to applicable security, banking and other regulations).

In the mobility sector decentralised technologies open up new potential marketplaces for (autonomous) mobility services, charging point access, parking access, traffic congestion optimisation/routing markets etc.

Many process use cases use decentralised technologies as part of a wider digitalisation or automation programme, often combined with IoT data (e.g. from smart meters), analytics and AI/ML, and smart contracts to allow robust, verifiable and straight-through processing of linear processes and decisions.

Examples in the energy sector include automation of billing, metering and switching processes which are data based and involve “if this happens, do that” logic which is often a prime candidate for smart contract optimisation.

In the mobility sector examples include many non-market based (micro)payment solutions for mobility hire/use, parking, charging, road use, tolls etc among other use cases.

If you want to learn more, well known examples of energy blockchain builders across the energy, flexibility, data, investment and mobility spectrum include Ponton’s Enerchain, Power Ledger, Grid+, We Power, LO3 Energy, Electron, Share & Charge, Chorus Mobility and many more.

In addition to companies building PoCs and products, a number of consortia and alliances have emerged including the Energy Web Foundation, the Mobility Open Blockchain Initiative, and the Decentralised Autonomous Vehicle Alliance.

What are the challenges in implementing decentralised technologies in the energy sector?

The summary of use cases above gives an idea of the potential for decentralised technologies, but it is important to not give into hype, and that we are realistic about where we are in the technology life cycle and that we recognise the potential challenges that are being gradually addressed. Decentralised technologies hold huge promise, but they are still early in their development.

We typically see the following key questions challenges when working with out clients and building our own products:

  • It is important to realise that by itself . It will not suddenly create new markets with thousand of daily users, and it will not suddenly resolve all process issues or transform the legacy energy markets into completely digitalised visions of the future. What it can do is be key part of a wider technology stack to new products or improved processes, but the to ensure that the right mix of decentralised technologies is used for the right use case and that User Experience and User Interface (UX/UI) are properly considered since this is a key element of large scale adoption. Much of our work with clients is focused on the concept, business model and product first — only then do we move onto smart contract specifications and architecture.
  • Blockchain is in an and the hype and unrealistic expectations often placed on it mean that it can never meet the goals set for it. The technology is developing rapidly, as are second layer and other solutions, but any product or project implementing blockchain needs to plan carefully for how it will be used now, in the medium term and in the longer term as the technology develops (in particular what is on-chain, and what is off-chain, whether a private or public blockchain is more appropriate etc). This requires a good, and realistic, understanding of the current and future capabilities of decentralised technologies.
  • Blockchain has the potential to create new markets and enable transactions and data transfer in a way that was not envisaged when energy market or other (e.g. financial market, data protection & privacy) were designed. Navigating what can be done now and what can be implemented later as regulations evolve or are clarified is a key part of any blockchain implementation project — this must be built into the business model, product and architecture roadmaps from day 1.
  • The fast evolving technology and regulatory landscape mean that a traditional waterfall style approach to both the business model and the software design and build does not work with decentralised technologies. A iterative and approach is required to learn by doing, to refine the product as developments occur, and most importantly to constantly build customer feedback into the product backlog as new ways of interacting with dApps and transacting with peers are tested.

What Validity Labs is doing in the energy sector

We at Validity Labs have been building blockchain products, platforms and applications for clients across all sectors since 2016.

One of our main focus areas has been the energy sector with training, advisory and smart contract projects delivered for clients in the renewable energy, liquid fuels, flexibility and generation markets.

We have also recently built our own product which is currently in the Proof of Concept stage to learn by doing. The PoC is for a Decentralised Autonomous Organisation (DAO) for joint investment and governance of a community owned battery that sits within a community of prosumers and consumers so that they can own, and trade capacity of the community battery. We will share more about this PoC, and the lessons that we learnt building it, in the next blog in this series.

We are also hosting a blockchain and energy roundtable in Zurich in June 2019 to discuss use cases, potential and challenges of decentralised energy sector in the Swiss and European energy markets. If you would like to receive an invitation when the logistics are finalised please let us know.

To hear more about our services, Battery PoC or upcoming roundtable you can contact our team at energy ( at )

About the author

Arran Kitson is Head of Advisory and Ventures at Validity Labs. He has spent the last three years working on the application of decentralised technologies in the energy and mobility sectors, both in advisory and start-up roles. He is experienced with Agile methodologies and holds a Product Owner certification. Prior to this he was a Director in Deloitte’s Energy & Resources Advisory practice and has a total of 20 years’ experience in the energy, advisory and technology industries, including at BP, Essent, RWE and Deloitte.

Thanks go to Validity Labs colleagues for their constructive debate on the topics covered and for their feedback and comments on the various drafts of this blog, in particular:

Sebastian Bürgel — CTO and Co-founder

Thomas von Bomhard — Head of Projects & Technology

Qianchen Yu — dApp Developer


decentralized application development