LabChain: A Modular Laboratory Platform for Experimental Study of Prosumer Behavior in Decentralized Energy Systems ^†

Abstract

The transition toward decentralized energy systems has amplified interest in peer-to-peer electricity trading. However, research on prosumer behavior in such markets remains fragmented, hindered by a lack of benchmarkable experimental infrastructure. Addressing this gap, the LabChain system was developed—a modular, interactive prototype designed to study human behavior in synthetic P2P electricity markets under controlled laboratory conditions. This system integrates real-world technologies, such as blockchain-based transaction backends, flexibility market interfaces, and asset control tools, allowing fine-grained observation of strategic and perceptual dimensions of prosumer activity. The research followed an iterative design approach to develop the infrastructure for experimental energy economics research, and to assess its effectiveness in aligning participant experience with design intentions. Based on the meta-requirements generality, affordance-centric design, and technological grounding, 13 detailed peer-to-peer market, software, and system requirements that allow for system evaluation were developed. As a proof of concept, seven participants simulated prosumer behavior over a week through interaction with the system. Their interaction with the system was analyzed through simulation data and focus group interviews, using a modified thematic content analysis with a hybrid inductive–deductive coding approach. The main achievements are (i) the design and implementation of the LabChain system as a modular infrastructure for P2P electricity market experiments, (ii) the development of an associated experimental workflow and research design, and (iii) its demonstration through an illustrative, proof-of-concept evaluation based on thematic content analysis of a single focus group session focusing on interaction and perceptions. The behavioral results from an initial session are limited, exploratory, and demonstrative in nature and should be interpreted as illustrative only. They nevertheless revealed tension between system flexibility and cognitive usability: while the system supports diverse strategies and market roles, limitations in interface clarity and information feedback constrain strategic engagement.

1. Introduction

1.1. Motivation

No topic other than the COVID-19 pandemic has dominated the public discourse of the early 2020s as much as climate change and the need for a green transformation towards climate neutrality until the middle of the century. The pandemic itself has acted as a driver for several structural shifts, including some in the energy sector, and sustainability transitions have increasingly featured on the agendas of local and national governments worldwide [1]. This broader trend is seen in refined emission reduction targets, new green deals, court rulings, and the media [2,3,4,5,6]. An important building block of energy transformation strategies is seen in decentralized energy resources (DERs) and energy community models. The past decades saw a steady increase in energy production from renewable energy sources, most of all solar and wind power (https://ember-energy.org/data/electricity-data-explorer/?metric=pct_share&tab=change&chart=change_by_source, accessed on 3 July 2025), which are distributed across the whole energy system as opposed to previous energy system models where a few centralized power plants supply many households. However, energy market models have not kept up with the pace and the need to deal with volatility. Traditional market models where these few power plant owners would trade energy exclusively on the exchange are challenged by the fact that DERs, in particular photovoltaic, are increasingly owned by many small actors, such as households (so-called prosumers) without access to electricity exchanges [7]. Simultaneously, these actors lack distribution channels for the generated electricity. This is particularly the case in Germany, where household PV systems were guaranteed a fixed feed-in tariff for a limited time frame of 20 years that expired (https://www.cleanenergywire.org/factsheets/20-years-german-renewables-pioneers-face-end-guaranteed-payment, accessed on 3 July 2025) for an increasing number of these households. This structural mismatch not only leaves potential untapped, but it also makes the economic case for households to adopt DERs less attractive and adds complexity to the utilization of many assets that ran out of the feed-in-remuneration.

This need for integrating these DERs into the current electricity system and make an economically viable business case leads to a growing interest in peer-to-peer (P2P) energy trading and market design [8,9,10]. Promises of an energy market design based on P2P trading are manifold: (i) access to the trade of electricity from PV systems and energy storage systems is provided to small actors [11], (ii) virtual energy communities are promoted [12], or (iii) new business models without the involvement of established players are enabled [13]. On a regulatory, institutional level, virtual energy communities and new P2P-based business models are already feasible today with varying restrictions within the European Union [14].

On a household level, these scenarios are technically enabled through the expansion of smart meter infrastructure and the Internet of Things [15]. On the coordination layer, however, this form of exchange requires infrastructure that allows for direct relations between households without a central coordinator that simultaneously offers the basic level of trust required for market transactions. Due to its decentralized nature and trustless architecture, blockchain technology has been intimately coupled with P2P electricity trade [16].

Capitalizing on the digital infrastructure in place and solving the organizational and regulatory hurdles require a paradigm shift that allows households to participate in the energy market directly [8].

Despite its potential, however, P2P electricity exchange has not yet been taken up beyond the level of pilot projects. Whereas this is also due to countless regulatory and legal issues of the model (see, e.g., [17] for the situation in Germany), another contributing factor in the dire need for this shift is the lack of insight into the conditions under which households would be willing to participate in P2P electricity trading. Studying the social needs and interests of future energy system actors such as households as a component of energy systems under investigation needs to be at least on par with the technological opportunities and regulatory requirements, and the mentioned actors are seen to be an elementary component of such an energy system, as underlined by [9]. Yet, this aspect of energy systems is often ignored by research that is dominated by traditional techno-economic research approaches. For this, it is valuable to employ methods based on behavioral economics (see [18]), such as laboratory experiments, as done in experimental energy economics.

As defined by Friedman and Sander, experimental economics theory addresses economic problems by analyzing data that are “deliberately created for scientific (or other) purposes under controlled conditions” in contrast to ‘happenstance data’ [19]. Experimental energy economics has a long history in the field of empirical economics.

It was pioneered by Edward Chamberlin, who predated the interest in experimental games surging in the 1950s and 1960s and who conducted controlled economic experiments already in 1948 [20]. In these, he argued that even simple classroom settings could reveal deviations from competitive equilibrium and thus offered a promising method to test economic theories under controlled conditions. While he did not explicitly articulate a broader theory termed “Experimental Economics,” his work opened the door for applying laboratory methods to a wider range of economic questions and demonstrated the potential of experiments for investigating applied market theory [21]. Building on this, Smith introduced control and replication protocols, incentive alignment, randomization, and repetition, transforming experimental economics into a rigorous science. A core step in its history was his double oral auctions [22], eventually resulting in his shared Nobel Prize in 2002 (see e.g., his iconic paper on experimental economics [21]).

While discrete choice experiments are a common tool for measuring consumer preference, research identifying itself as ‘experimental energy economics’ is rare. Reference [18] reviews 29 journal and conference papers as behavioral studies in energy economics that cover at least two of the three following concepts: experimental design, market engineering, and energy analytics, through field experiments, laboratory experiments, simulations, or surveys. However, the reviewed articles conduct laboratory experiments only as investigations within an established system, but do not perform experiments on novel proposed system designs. Similarly with simulation studies, only one reviewed article conducts a behavioral-informed analysis involving decision biases, whereas other approaches use artificial agents. Historically, the field focused on the wholesale side of the market, with the investigation of double auction incentives and market equilibrium studies.

Furthermore, experimental studies in the energy field address emission trading (e.g., [23,24]), energy policy (e.g., [25]), and energy consumption (e.g., [26,27,28]). Experimental studies on P2P electricity trade are rare (see, e.g., [10,29,30]), and this holds for market design as well (see [31,32,33,34] as notable exceptions). Finally, experimental tools are usually not employed in exploration, but confined to hypothesis testing.

This lack of maturity of experimental energy economics is particularly evident in the context of P2P electricity exchange. As noted in [16], the few studies comparing their developed mechanisms against another case [35,36,37,38,39,40,41,42,43] or a base case [15,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59] share no common evaluation framework or benchmark case, let alone employ an experimental setup or even study real-life human interactions and thus behavior. The research landscape is therefore scattered with isolated evaluations lacking comparability and consistency for the discourse on (blockchain-based) P2P market design.

The current research landscape thus suffers from two problems: few exceptions aside, methods of behavioral economics play a minor role and are techno-economic-centric, and existing studies lack comparability. While the work of [38] has been cited substantially (see https://www.researchgate.net/publication/325046265_Evaluation_of_peer-to-peer_energy_sharing_mechanisms_based_on_a_multiagent_simulation_framework/citations for its reception (as of 1 October 2025)), articles referencing it focus largely on their price structure, results, or research design. Their call for “[…] a systematic and general simulation framework […], which includes all fundamental elements of P2P energy sharing mechanisms and does not rely on specific forms of decision making or implementation models” has gone largely unnoted.

Through this lack of experimental grounding and benchmark infrastructure, comparability of market and system designs is rarely given, and knowledge about P2P market design and implementation is hard to systematically derive without a test bed. This is even more the case when real-life human interactions are taken into account, requiring the investigation of socio-technical systems in the respective context of usage [60].

During the course of the WindNODE project, the LabChain research infrastructure was developed as an interactive prototype for synthetic P2P trade in experimental energy economics (see [16] and the GitHub repository (https://github.com/IIRM/LabChain-documentation (accessed on 18 December 2025) for a more thorough system description)). The system allows participants to engage in an interactive simulation of P2P electricity exchange. Decisions for energy asset management and individual trades with peers, grid operators, and retailers are made by participants in a laboratory context according to a previously defined market design, enabling the study of market dynamics in the spirit of behavioral economics.

1.2. Research Objective

• Problem Identification

As sketched above and elaborated in Section 2.1, the field of studying P2P electricity trade is wide and use cases are defined mostly heterogeneously. In order to address the lack of comparable research infrastructure and benchmark cases [16], the LabChain infrastructure was developed. However, due to the wide range of cases and the case-by-case nature of the scientific discourse, an in-depth investigation of any specific use case seems to only be of limited use. Joining the call for a general and systematic simulation framework incorporating “[…] all fundamental elements of P2P energy sharing mechanisms” [38] and building on the value of combining multiple approaches in behavioral economics, such as laboratory experiments and simulations made in [18], this research is motivated by the lack of a comparison and benchmarking culture in experimental energy economics. This is achieved by contributing tools to enable behavioral economics to investigate designs under which private households are willing to engage in P2P trade (techno-economic focus of P2P market and system design research).

• Objective Definition

In order to address this problem, two needs were identified. First, the required research infrastructure was conceptualized and created, and the technical artifact was implemented. Secondly, the effectivity of the design needed to be shown. As the LabChain system is directed to be used by participants in the role of prosumers in a laboratory environment, a case study was devised and a simulation executed and evaluated in order to assess to what extent the requirements of the laboratory system are met and how the system needs to be improved to achieve alignment of the perception of the participants with the intention of the market design. While this implies an iterative research design (as already indicated in [16] and suggested by [18]), this article only reflects the first iteration that lies within the scope of the WindNODE research project. The objectives of the research described in this article are thus to

• Identify requirements for an interactive laboratory tool to investigate P2P market designs from a prosumer perspective;
• Implement the software components of the system;
• Devise a case study for the laboratory execution, as well as an in-depth research design to investigate participants’ perception of the modeled energy system;
• Execute the interactive simulation and collect data;
• Analyze data and assess the effectiveness of the design.

Based on these research objectives, meta-requirements, market, software, and system requirements were derived and instantiated in the LabChain prototype as an experimental approach to energy research for P2P electricity trading. This is a hermeneutic answer to the question of how existing market structures, software, and system requirements can be synthesized into a coherent laboratory infrastructure. The research questions in this article focus on the empirical evaluation of this approach by evaluating the design effectiveness and the perceptions of the laboratory participants:

• To what extent does the implemented LabChain prototype fulfill the system requirements and thus support the investigation of prosumer behavior in synthetic P2P electricity markets?
• How do the laboratory participants perceive the system’s affordance and where does the system fall short in empowering the laboratory participants?

As the focus of this research is the design and evaluation of the research infrastructure, the experimental study reported here is intended solely as an illustrative use case rather than as a full experimental energy economics (EEE) study. Its purpose is to demonstrate how the infrastructure enables rigorous and systematic experimental work that can address the requirements of EEE, rather than to provide substantive generalizable empirical findings on P2P market design or prosumer behavior.

The main achievements of this article are the

• Design and implementation of the LabChain infrastructure as a modular laboratory environment for studying P2P electricity markets, integrating prototype blockchain-based record-keeping, synthetic market interfaces, and asset representations;
• Specification of market, software, and system requirements that structure the design and enable systematic evaluation;
• Development of a reusable experimental workflow and research design evaluating configurable case studies in an interactive simulation;
• Execution and analysis of a small-scale proof-of-concept experiment that demonstrates the technical and methodological feasibility of the approach and illustrates how prosumer interaction and perceptions can be studied with LabChain in a qualitative, theme-oriented evaluation.

1.3. System Requirements

In order to assess how far the research objectives are met, a number of requirements are devised. These system requirements are to be understood in the light of a set of assumptions that the system is based on. The assumptions are as follows:

• Variation in prosumer electricity trade behavior can reasonably be measured within a laboratory context;
• The LabChain system provides the affordances relevant for P2P electricity trade;
• The LabChain P2P exchange model provides the versatility required to compare heterogeneous cases within the discourse.

The degree to which these assumptions are covered is crucial for assessing the quality of the approach. While it cannot be assumed that such an exploratory approach conforms to all assumptions perfectly, their reflection should play a key part in the evaluation of the approach. This is particularly the case with the assumptions related to design activities (i.e., assumptions 2 and 3). The first assumption is more of a paradigmatic nature that sets limitations to the validity and relevance of the results. This assumption needs to be theoretically grounded solidly in a mature model. The other, more design-related assumptions can be detailed into a set of technical and system requirements for the LabChain system.

In order to address the research objective, the system shall allow for socio-technical interactions within a range of simulated markets. This super-requirement can be translated into the three meta-requirements to be generic, affordance-centered, and technologically grounded (as has been achieved in [16]) in order to follow a generic and adaptive approach. These meta-requirements can be roughly associated with the requirements of the P2P market (generic), the software (affordance-centered), and the system (technologically grounded). The requirements are categorized using standardized terminology: “shall” indicates a mandatory, testable requirement; “should” indicates a desirable but non-mandatory feature.

• P2P Market Requirements (PMRs)

• The P2P market shall reflect the heterogeneity of the market approaches in the literature, in particular with respect to bid-matching and pricing;
• The P2P market shall provide an atomic and modular foundation that additional concepts can be built upon and should not exhibit any inherent mechanics such as matching algorithms or fundamentally complex offers;
• The P2P market should allow for flexible roles for the participants;
• The P2P market should allow for finely granular behavior and strategy;
• The P2P market shall provide a high degree of control.

The requirements for the software are centered around affordances and include the following.

• Software Requirements (SoRs)

• The software shall provide affordances for all actions necessary for market participation and the operation of prosumer assets;
• The software shall allow for planning and preparation of future actions by the prosumers;
• The software shall provide a clear user interface;  
• The software shall be modular and allow for adaptability.

Finally, the LabChain system as a whole addresses the requirements used to tackle the meta-requirement of being technologically grounded.

• System Requirements (SyRs)

• The system shall use real implementations of the technologies it is based on and provide the technical demonstration;
• The system should aid users’ understanding of the idiosyncrasies and effects of the technologies used;
• The system shall allow for flexible and adaptable prosumer asset and market configuration, as well as energy system parameters; 
• The system shall allow to record extensive behavioral data for the analysis of diverse research questions.

1.4. Structure

After motivating the themes tackled in this research (Section 1.1), defining the research problem and objective (Section 1.2), and the requirements it needs to address (Section 1.3), this working paper provides the necessary background for the research topic of P2P electricity trade (Section 2.1) and the technical basis of blockchain-based flexibility trading that the technical infrastructure is based upon (Section 2.2).

The working paper then details the methodological approach through the construction of the analyzed use case and its execution (Section 3.1) and the method of analysis of focus group interviews and synthesis through content analysis (Section 3.2) before it describes the technical design by presenting its architecture (Section 4.1), the user interface and its code organization (Section 4.2), as well as the external components involved in it (Section 4.3). The article then presents the results of the content analysis (Section 5.1) and the evaluation of the system requirements (Section 5.2), before it concludes and discusses limitations (Section 6.1) and future work (Section 6.2).

2. Background

This section details the conceptual components of the LabChain project in Section 2.1 and Section 2.2.

2.1. Peer-to-Peer Electricity Trade

As mentioned in the introduction, household adoption of decentralized energy resources is a growing trend that will intensify with increasing efforts to combat climate change and transform centralized systems. However, to build a sustainable economic case for households, business models that work beyond subsidies are necessary. In the current European context, electricity is mainly traded on regional wholesale spot markets, which were designed for a small number of large, centralized generators and licensed suppliers and remain highly restrictive in terms of who may participate directly. Small-scale prosumers usually only interact with these markets indirectly via retailers or aggregators and receive standardized remuneration through feed-in tariffs or market-dependent market-premium schemes (https://www.cleanenergywire.org/factsheets/20-years-german-renewables-pioneers-face-end-guaranteed-payment, accessed on 1 December 2025). A commonly discussed business model to address this shortcoming is peer-to-peer (P2P) electricity trade that has received a considerable boost in attention with the popularity of blockchain technology. In this use case, electricity is directly traded between prosumers (peers) that generate electricity (predominantly through rooftop PV systems) with other households (generally prosumers, thus ‘peers’), bypassing the traditional market roles involved in energy markets.

While the promotion of DERs through P2P trade is a common narrative in the scientific (and public) discourse, it constitutes only one motivation for the investigation of P2P electricity trade in the literature, especially for varieties that use blockchain technology as a data storage layer.

The scientific and gray literatures attribute numerous facets to P2P trade. These motivational aspects are connected to its performance, information quality aspects, user empowerment, or operational parameters, such as organizational design, market provision, transaction execution, settling, trust, and involved parties and technology management. A list of motivating properties of blockchain-based electricity exchange between peers is found in

Table 1. Motivation for blockchain-based peer-to-peer energy trade. Taken from [16] with permission.

Motivation	References
Performance
Settling time reduction	[44]
Improved system efficiency	[35]
Overcome scalability bottleneck of centralized systems	[59]
Less vulnerable than centralized solution	[61]
Efficiency	[62,63]
Cost-efficient transactions of smallest quantities	[63,64]
Higher operation speed	[65]
Scalability	[66,67]
Information Quality
Source of truth	[44]
Security	[15,36,45,55,56,62,65,66,67,68,69,70]
Quality tracking	[35]
Auditability	[45,47]
Transparency	[61,63,64,71,72]
Traceability	[61,63]
Transaction authentication/authenticity	[55,70]
Transaction accuracy	[70]
Data integrity	[65]
Reliability	[66,69]
Robustness	[56,65,67]
Credibility	[63]
Empowerment
Prosumer empowerment	[59]
Decentralization	[15,45,69]
Anonymity	[45]
Consensuality	[61]
Distributed architecture	[36]
Privacy preservance	[15,45]
Fairness	[68]
Disintermediation	[47]
User friendliness	[64,71]
Control shift to participants	[64]
Resolving conflicts of interest	[64]
Information symmetry	[64]

. Since many motivating factors are specific to operational parameters, these are listed separately in

Table 2. Motivation for blockchain-based peer-to-peer energy trade specific to operational parameters. Taken from [16] with permission.

Motivation	References
Operational Parameters
Operation simplification	[44]
Decentralized RT transactive energy management	[65]
Network monitoring and control (allowing system operators to monitor and control the network.)	[72]
Organizational Design
Regulation streamlining	[44]
Societal benefit (potential to benefit economic, political, humanitarian, and legal sectors.)	[64]
Market Provision
Decentralized market platform provision	[59,73]
Trustless market provision	[59]
Price-discriminatory market provision	[56]
Trading rules implementation	[72]
Market requirement suitability (of markets requiring automation, self-regulation and scalability.)	[67]
Transaction Execution
Conditional/automated contract execution	[59,63,65]
Power of smart contracts	[62]
Transaction automization/autonomous operation	[62,63,66,69]
Allows coordination for P2P trading	[47]
Record of traded electricity	[74]
Secure and reliable transactions	[66]
Trade enforcement	[67]
Settling
Capabilities for financial transactions	[59,63,69]
Transparent automated settlement system	[74]
Double-spending risk mitigation	[64]
Adaptable and secure financial model	[66]
Quick, guaranteed and cheap payment	[67]
Trust and involved parties
Trusty (allows transactions without mutual trust.)	[15,61,62,68,75]
Tackle reliance on trusted parties	[45]
Increased resilience and trust in microgrids	[64]
Operation without central supervision	[76]
Certifiability	[66]
3rd party management possibility	[67]
Openness	[63]
Technology Management
Adressing need for innovative ICT	[41]
Online interruption possibility	[67]
Interoperability	[67]

.

• Market and System Designs

Whereas not as numerous as the motivational aspects, market and system designs take many forms in the literature. This is particularly the case when it comes to price formation and offer matching. A selection of different approaches in the literature can be found in

Table 3. Market mechanisms found in the P2P literature (double entries possible if several are used in the same study).

Market Mechanism	Source
(Centrally) Optimized trade matching	[15,43,44,47,50,51,75,77,78,79,80,81,82,83]
Auction mechanisms	[15,37,40,46,58,65,66,67,68,71,73,76,82,83,84,85,86]
Order-book style matching	[59,63,64]
Pooled uniform pricing	[35,41,53,64,74,87,88]
Aggregator-determined pricing	[36]
Communally decided pricing	[38,40,43,54]
Game-theory-based pricing	[42,49,52,56,57,82,88]
Bilateral pricing	[69,74,82]

.

In order to encompass this variety of market designs, a modeling strategy is necessary that encompasses many, if not all of the shown market mechanisms. As the fundamental unit, the offers (bid/ask) themselves show a diverse range of data modeling for the offers and markets; yet all data points that relate to offers link time, quantity, and price for the delivered energy.

The market itself needs to accommodate this fundamental data modeling of offers and provide the respective guiding structure to relate time, quantity, and price to one another and to (if necessary) constrain the respective offers, without ingraining a subset of possible market designs in their description. For this, the market representation should specify the minimal and maximal size of offers, the maximum price (price ceiling), the length of bid time slices, fees, and the gate closure (latest time that offers can be submitted to the market in order to be counted as valid). Ideally, the market specification furthermore allows to distinguish between closure times for bids (offering a certain price for energy) and asks (offering energy for an asked price). These design choices relate to the P2P market requirements 1 and 2 as well and will further be discussed in the design described below.

• Market Roles

In addition to the offers used in the market and the market itself, many approaches model actors in a number of (market) roles. While the peer actor is an obvious component of all systems, other actors feature in different approaches, as listed in

Table 4. Non-peer roles in the surveyed literature. Taken from [16] with permission.

Actor/Role	Source
Aggregators	[15,35,36,44,55,56,58,82]
Grid or system operators	[37,43,46,48,52,55,58,66,69,73,82,83,85,87,89,90]
Community/trading managers/platform operators	[37,38,40,43,50,51,52,53,91]
Retailers	[44,73,88,91]
Utilities/suppliers	[35,38,48,50,51,52,53,64,82,87,89]
Energy sharing provider	[54]
Auctioneers	[56]
Controllers	[77]
Wholesalers	[44]
Governmental authorities	[35]
Load balancing authorities	[84]
Liquidity provider	[75]
Central market player	[76]
DER vendor	[91]
A wide potpourri of specialized agents	[58,69]

. This diversity of actors is hard to reconcile, but shows that a flexible and modular actor concept is needed to investigate different approaches, and an (extendable) generic actor would play an important role in a research setup for different designs. This actor should provide the role flexibility that is required as per PMR 3, as will be addressed in more detail below.

2.2. Blockchain-Based Flexibility Trading

The blockchain-sided technological layer of the LabChain within the WindNODE project was based on a blockchain implementation that the consortial partner Fraunhofer FOKUS developed for the blockchain-based flexibility market developed and evaluated within the WindNODE project. Although the use case of the flexibility market was very different in application to the P2P energy trade market, the basic design was reusable with some adaptation and an intermediate layer.

The following paragraphs elaborate on the original blockchain prototype for flexibility trading developed within the WindNODE project and the required adaptations to be able to use this prototype in the context of LabChain.

• The Original Blockchain Prototype for Flexibility Trading—A Short Digression

The original technical prototype was conceptualized to be the ledger infrastructure for experimentation with flexibility market implementation by different consortial partners within the project. Flexibility markets were thought of as locally bounded monopsony markets where flexibility providers (power plant operators) can offer a deviation from the norm operation of their assets in a positive or negative direction for compensation payment within technical bounds. To document bids decentrally in a tamper-resistant infrastructure, a private blockchain was implemented to model the flexibility market. It was adapted to this prototype to solve a trust gap between market participants and serves two critical functions:

• Establishing mutual trust: In a peer-to-peer network, participants (prosumers) may not know or trust each other personally. Blockchain acts as an intermediary allowing trust to shift from a central company to the technology itself.
• Tamper-proof record keeping: The distributed ledger provides an immutable history of energy production and consumption. Once a transaction is recorded, it is cryptographically sealed. This ensures that no single participant can manipulate the data to fake energy generation or avoid payment.

It offers a public API (Application Programming Interface) that provides functionality to receive and respond to requests from senders. Before sending requests, the sender, e.g., a prosumer, needs to be authenticated, thereby ensuring that it is the sender it claims to be. A dedicated authentication service is used for this purpose. After successful authentication, the client receives a service ticket (i.e., authentication code) to be used to communicate with the prototype, which can then validate the authorization and authenticity of the requests. Once the client has been validated, requests are processed and stored in a smart contract, which is already published in the blockchain network and can also be called to retrieve the information contained. In more detail,  access to the smart contracts is granted by using signed transactions sent to the private Ethereum network via the Ethereum client. At the time the experiments were conducted, the private Ethereum network was using the Proof of Work consensus mechanism. (This technical choice is independent of the use of the term proof of concept in this article, which refers to the demonstrator status of the research infrastructure and case study, not to a blockchain consensus protocol). After successfully storing the transmitted predictions in the blockchain, another client (e.g., a resource owner) could send requests to the prototype to retrieve the offers. Again, as a first step, the prototype verifies this client via the same security mechanism already used for the first sender. After successful verification, the prototype executes a signed transaction via its blockchain service, which retrieves the requested data from the private blockchain network and makes it available to the sender via the API.

In the original solution for modeling a flexibility market (see Figure 1), a distinction was made between two types of users: the power plant operator, who wants to place bids, and the grid operator, who wants to process the bids. However, it is important to mention that the prototype is not limited to these two users, in principle any number of clients could access the application in parallel (as can be seen in the paragraph related to the required adaptations).

The demonstrator consists of a front-end based on AngularJS and a backend that provides a web service interface to interact with the smart contracts in a secure and access-regulated way. The front-end is used solely for visualization, and requests could be made programmatically without the front-end, simplifying integration into existing processes. The backend is based on the previously described mechanisms. The AngularJS front-end provides a lightweight JavaScript-based way to design the front-end and interact with the backend. The backend runs a NodeJS application that allows interaction with the blockchain via well-defined interfaces. The implemented and deployed smart contracts are DayAheadTrading, IntradayTrading, the Registry, and the foundational AbstractBidManagement (not visualized in the figure). These artifacts originate from the previously existing prototype and were integrated into the current system to satisfy functional requirements. This architectural layer was deliberately preserved in its existing state. Given the proven stability of these contracts, the research focus was directed towards the development of novel application layers rather than re-engineering the blockchain core. Introducing major structural changes to the contract design at this stage would have resulted in disproportionate technical effort and unnecessary technical debt for the scope of this proof of concept. In addition, the original design adheres to the software engineering principle of separation of concerns, ensuring distinct responsibilities for each module:

• Registry: Solely handles the administrative layer, managing participant registration and whitelisting of devices.
• DayAheadTrading and IntradayTrading: Encapsulate the specific, distinct market mechanisms and business rules required for their respective time frames.
• AbstractBidManagement: Functions as an abstract parent contract to ensure modularity. It centralizes the shared business logic and data structures common to both bidding forms, thereby simplifying maintenance and extendability.

This modular approach parallels the concepts introduced by AdapT, which proposes a generalized abstraction layer to reuse verification and transaction logic for related transactions [92]. While the AbstractBidManagement contract shares the strategic objective of bundling common logic to reduce redundancy, it is a product of historical evolution within the prototype and does not currently implement the AdapT pattern. However, the pattern proposed by [92] serves as a robust reference point for future refactoring and further theoretical development of this trading system.

• Necessary Adaptation to the Original Solution

While this technical design was sufficient for evaluating local market concepts, it was not designed for P2P electricity trade and thus required some adjustments for this use case. In order to minimize implementation effort, the technical adaptation was kept to the bare minimum, and most of the adaptation of the original technical concept was done by reinterpreting the semantics significantly to allow for several offers for each participant and for the offer structure required in a P2P market. This reinterpretation is explained in Section 4.3.1 and the following is limited to the technical adaptations for the blockchain solution optimized for the flexibility market.

The representation of offers on the (external) blockchain layer is based on the involved partners’ requirements for a flexibility market. In this design, offers are associated with the market participant issuing the bid, the ID of the physical resources offering flexibility, and a positive and negative power series representing their flexibility bid in variable power and price for 15 min intervals. They furthermore offer an entry of contracted flexibility (by the grid operator) that notes the fraction of the contracted time slices for the individual 15 min steps in positive and negative flexibility in analogy with positive and negative primary and secondary balancing power in balancing markets. These flexibility products are designed for an intraday (4 × 15 min slots) and a day-ahead market (96 × 15 min slots), representing a full hour or a full day of contracted flexibility. Flexibility offers are registered with the corresponding ID of the resource offering the flexibility and the UTC timestamp (seconds elapsed from 1/1/1970, 12 am UTC time, excluding leap seconds) for the respective time slot. Offers are rejected as invalid if their timestamp doesn’t correspond to the UTC timestamp of the beginning of the trading interval, or an offer already exists for the respective resource and timestamp.

3. Materials and Methods

As mentioned, the two major objectives of this research were to implement the technical artifact needed for the envisioned infrastructure and to show the effectiveness of the design. While the infrastructure is designed to support mixed-method approaches, this article focuses on demonstrating the proof of concept; thus, the empirical evaluation is restricted to a qualitative analysis of a single focus group session and quantitative data is used solely to demonstrate the technical and methodological capabilities of the system.

Section 1.2 worked out the requirements the system needs to fulfil and Section 2.1 detailed the fundamental building blocks of the P2P trade system design that the system needs to include. The design that addresses these requirements is detailed in Section 4 and evaluated in Section 5. Since the methodological aspects of the development have already been addressed in [16], the methodological part of this working paper will focus on the second objective: to show the effectivity of the design.

Conceptually, the research logic follows a design science process, an approach that is commonly used to design and evaluate socio-technical (IT) artifacts within an appropriate environment [93]. This research adopts Hevner et al.’s understanding of IT artifacts as an instantiation that includes constructs, models, and methods involved in their creation that are independent of the envisioned social context (the P2P market in the case of this case study) that are not full-grown information systems (id.).

Methodologically, this research follows a condensed form of the design process laid out in [94], comprising a Problem Identification and Objectives Definition, a Design and Development, and a Demonstration and Evaluation step. Given the demonstrative and conceptual nature of this work, further iterative refinement cycles are left to future research.

The Problem Identification and Objectives Definition step was described in Section 1.2 and derived a set of system requirements from the problem and objectives that are used to evaluate the system. The Design and Development of the system is outlined in the remainder of this section and the next Section 4. Finally, the system is Demonstrated and Evaluated with the results based on the evaluation scheme described below in Section 3.2, with illustrative, preliminary results presented in Section 5.

As noted, the design is only effective if the people interacting with it perceive it according to the design intentions. As a socio-technical system, how the technical design enables household agent behavior and strategy is just as imperative as the technical aspects. In order to assess the simulation in context, a use case is designed as a demonstration case, which is detailed in Section 3.1.

The experiments were conducted with the LabChain software system, as developed by the IIRM at Leipzig University, Leipzig, Germany, version 1.0 as documented in https://github.com/IIRM/LabChain_release (accessed on 18 December 2025).

3.1. Case Study Design

The case study investigates the behavior and interaction of households in an interactive environment consisting of other households within the system and an external market that allows for feed-in of generated electricity (representing the grid operator) and purchase of electricity from the market (representing the electricity retailer) in the region of the case study (city of Leipzig, Germany). Household prosumers own a set of assets (PV systems, household storage systems, and loads representing the aggregated loads of the household.) they can manage and can engage in market activities (buying and selling of electricity).

The investigated use case is designed to study the behavior of a set of 7 prosumers with heterogeneous physical asset combinations within a typical summer week (the week of the 11th to 18th June of 2015. Weather data was taken from DWD for the city of Leipzig). The physical asset distribution among the prosumers is listed in

Table 5. Asset distribution of experiment participants.

Prosumer	Aggregated Loads	Storage	PV System
Prosumer 1	Large Load	-	Small PV
Prosumer 2	Large Load	Household Storage	Large PV
Prosumer 3	Large Load	Household Storage	Small PV
Prosumer 4	Small Load	Household Storage	-
Prosumer 5	Large Load	Household Storage	-
Prosumer 6	Small Load	-	-
Prosumer 7	Large Load	-	-

and the asset configuration is given in detail in

Table 6. Configuration of assets.

Asset	Parameters
Load Type	Shifting Length	Shifting Amount	Load Scaling
Large Load	2 h	10% of load	6000 kWh/yr
Small Load	2 h	10% of load	3500 kWh/yr
Storage Type	Charg. Power	Capacity	Charg. Efficiency
H. Storage	2.5 kW	5 kWh	99%
PV Type	Peak Power
Large PV	8.5 kW
Small PV	3 kW

.

The time series used for the load profiles of each prosumer is based on a standard household load profile (BDEW) that is first scrambled by varying single data points while keeping the total energy consumption steady and then rescaled by the size of the household it represents. The load allows for limited flexibility, permitting the shift of up to 10% of the load at a point in time for up to two hours. Prosumers that are endowed with a storage unit can operate a household storage with a capacity of 5 kWhs and a feed-in and feed-out power of 2.5 kW. The efficiency of a charge–discharge cycle is assumed to be 99%, while the self-discharge rate is assumed to be zero, and the storage is initialized empty. The case study assumes spatial proximity of the prosumers, so the generation profile for the prosumers that own a PV system is identical, but is scaled to heterogeneous peak generation as noted in Table 6. The load profiles are depicted in Figure 2 and the generation profile that is used as the base for scaling the individual generation profiles of the PV systems is shown in Figure 3.

Overall, the case study is constructed as a stylized prosumer scenario to demonstrate the LabChain infrastructure and experimental procedure. The combination of PV, storage, and demand profiles does not reproduce a specific empirical neighborhood nor test a particular theoretical benchmark model. Rather, the scenario is deliberately kept compact and didactic so that the interplay of assets, P2P market rules, and user interface elements remains transparent for both participants and researchers.

Prosumers are obliged to keep their grid access point balanced at each step of the investigated time horizon; based on the operation of assets and trade with external market participants, every time step, the net generation (generation − consumption + electricity purchases − electricity sales) is calculated and deviations from the 0-point (grid-neutral operation) are recorded. Deviations are financially penalized as depicted in Figure 4 in full 100 Wh steps, with a penalty higher than the maximum electricity purchase tariff, making it unattractive and irrational for participants to purposefully engage in operation leading to imbalance of the grid access point. For this, the penalty is calculated proportionally to the price of balance energy (i.e., incurred system cost) or retail price, whichever of these is higher. In addition to operating their assets, participants can interact with market participants external to the communities through feeding in or purchasing electricity (according to the dynamic feed-in and retail tariffs detailed in Figure 5). These dynamic series were created from taking current electricity tariffs and feed-in remunerations based on spot market prices from 25 June to 1 July 2015 and adjusted to price fluctuations on the wholesale market. Spot market prices were chosen for a different week than (but in the vicinity of) the time series of the weather data, as the spot market prices of that week were rather erratic and unrepresentative of the system. While not all effects on the spot market prices of that week are understood, it was deemed unlikely that the weather of that typical summer week had a dominating influence on the price series of the week of 11 June to 18 June 2015.

The experiment participants (in the role of prosumers) are permitted to operate their assets within the bounds described above, and trade electricity with the grid operator (feed-in of electricity) and the retailer (purchasing electricity). This functionality is provided by the LabChain system (as detailed in Section 4.2) through the asset dispatch and external market interaction functionality.

In order to trade electricity with other prosumers, participants can issue buy/sell offers (bids/asks) through a marketplace that records these offers on a blockchain infrastructure (and a central database as backup). These offers are characterized by the starting time, duration, and power over the period length of the offer and unit price for the energy of these offers. The valid region of these parameters depends on the market design (and is limited by a length of 48 time steps for the duration due to technical reasons). Issued offers are displayed individually in a market that allows participants to take up individual offers representing the exchange of electricity against money-representing units of the involved participants.

While the market design is very flexible by design, a rather liberal market design was chosen in order to not constrict experiment participants unnecessarily. Participants were neither constrained in volume nor price, and trade was technically possible until the time of delivery (real-time market design), both as asks (offering electricity for an asked unit price) and bids (requesting electricity for a unit price bid). In order to decrease complexity, complex offers were not implemented and offers could not be split, but only accepted fully.

Placed offers were registered on the blockchain and displayed in the market for all prosumers. Prosumers could filter the offers and select individual offers to purchase, which were registered with the blockchain API. When the counterparty was set with the offer, the offer was removed from the market view of the participants, and they could not attempt to secure it as a counterparty.

Experiment participants used a browser-based, client-side web application that provides the components to make this possible. The simulation takes place in hourly steps and allows the participants to dispatch assets (within operational bounds) and engage with electricity trade from third parties (the retailer and grid operator) for each time step lying in the future relative to the simulation step the participant is in. Actions are recorded in a database that can be analyzed by the researchers retrospectively.

• Experiment Execution

The demonstration of the proof of concept of the research approach was given through the execution of an interactive simulation on 5 February 2021 with seven participants not directly involved in the development of the software. The participants were recruited among university researchers and industry professionals (see

Table 7. Laboratory participant affiliation.

Institution	Number of Participants
Leipzig University	5
Stadtwerke Leipzig	2

) and had at least basic knowledge of energy economics. The participants were trained individually on the functionalities for asset dispatch and trade with external parties beforehand.

The session was conducted as a proof-of-concept demonstration of the LabChain infrastructure and experimental workflow. Participants were not offered performance-based incentives. Instead, they were asked to assume the role of prosumers, explore different operation and trading strategies, base their decisions on their own preferences and understanding of the scenario, and to reflect on the overall experience with a focus on their decisions and the software affordances.

In order to allow the participant to get oriented in their specific asset setup and perform actions to be balanced for the initial time steps, the participants were given five minutes for their initial actions (asset operation, trading with the grid operator and retailer, as well as posting offers to the P2P market) before the experiment was started with a tick duration of 18 s (i.e., each hour in the simulated week was compressed into 18 s simulation time). The experiment was conducted virtually through a production-deployed instance on a content-delivery network accessible through a web-browser-based client and participants were free to communicate with each other via a web-based video conference tool. Audio-visual data was not stored beyond the experiment and client-specific data was recorded through the clients and sent to a central database for subsequent analysis by the research team.

During the experiment, a rich host of data was recorded for each participant. This data was logged to illustrate the technical and methodological capabilities of the system; within the illustrative nature of the research described in this article, it was not analyzed and no insights were derived from participants’ behavioral data.

The data recorded for execution of the experiments is described by the following schema:

• {
•   "paidFees": {
•     "finalAmountTokens": "number"
•   },
•   "askCommitmentMarketActivity": [
•     {
•       "correspondingOffer": {
•         "id": "string",
•         "optionCreator": {
•           "power": "number",
•           "acceptedParty": "number",    // id reference
•           "price": "number",
•           "optionCreator": "number",    // id reference
•           "deliveryTime": "number",
•           "duration": "number",
•           "id": "string"
•         },
•         "deliveryTime": "number",
•         "duration": "number",
•         "price": "number",
•         "power": "number",
•         "acceptedParty": {
•           "power": "number",
•           "acceptedParty": "number",    // id reference
•           "price": "number",
•           "optionCreator": "number",    // id reference
•           "deliveryTime": "number",
•           "duration": "number",
•           "id": "string"
•         }
•       },
•       "context": {
•         "amountTokens": "number",
•         "t": "number",
•         "filterSetting": {
•           "maxPrice": "number",
•           "minDeliveryTime": "number",
•           "maxDeliveryTime": "number",
•           "minDuration": "number",
•           "maxDuration": "number",
•           "minPower": "number",
•           "maxPower": "number"
•         }
•       }
•     }
•   ],
•   "askMarketActivity": [
•     /* same pattern as askCommitmentMarketActivity or other
•      ask-events */
•   ],
•   "bidCommitmentMarketActivity": [
•     /* commitment bid events, analogous structure if present */
•   ],
•   "bidMarketActivity": [
•     /* non-commitment bid events, analogous structure if
•      present */
•   ],
•   "feedInActivity": [
•     {
•       "volume": "number",
•       "power": "number",
•       "context": {
•         "amountTokens": "number",
•         "t": "number"
•       }
•     }
•   ],
•   "retailActivity": [
•     {
•       "volume": "number",
•       "power": "number",
•       "context": {
•         "amountTokens": "number",
•         "t": "number"
•       }
•     }
•   ],
•   "inbalanceFees": [
•     {
•       "timeStep": "number",
•       "inbalancePower": "number",
•       "inbalancePaid": "number"
•     }
•   ],
•   "assetScheduling": [
•     {
•       "asset": "string",
•       "scheduledTimeStep": "number",
•       "plannedDispatchValue": "number",
•       "context": {
•         "t": "number",
•         "schedulingIndex": "number"
•       }
•     }
•   ]
• }

After the experiment was conducted, subjective participant perceptions were discussed jointly through a group discussion that was transcribed and analyzed by the research team after its conclusion. All participants were asked for their consent about this and all participants permitted the research team to record the group interview.

3.2. Experiment Evaluation

At the core of this research approach is the study of human behavior within an observable context. Herein, the perception of their (synthetic) environment, their motivation, their strategies, and their role within the unfolding market dynamics is of primary importance. While a full investigation of these is outside the scope of this proof-of-concept article, a rudimentary evaluation was performed by conducting a focus group interview.

The goal of the qualitative aspect of this research is to investigate the perception, goals, and strategies of prosumers participating in the experiment. Focus group interviews seem to be a promising approach, as they primarily strive to uncover meanings, beliefs, and culture influencing the participants’ behaviors [95]. This method is intended to discover meaning and implications for the research questions posed [96], and would thus inform how both the software affordances and the market design are perceived. Content analysis of focus group interviews is often structured in deductive approaches, where categories are formed in advance and data are mapped to them, and inductive approaches that construct the categories through the analysis of the data. Inductive methods themselves are distinguished into thematic content analysis (identification of common themes) and narrative analysis (aiming to make sense of individual stories) among others [97]. As this research is primarily interested in how market participants perceive and act within their environment as well as their perceptions, goals, and strategies, a form of thematic content analysis would be most appropriate, as it focuses on identifying recurrent themes rather than reconstructing individual narratives or quantifying frequencies. This analysis aims at uncovering the themes emerging within the group in order to identify their intentions and strategies.

As the perceptions, goals, and strategies of participants are clearly defined, and due to the prototypical nature of this research, the group interview requires an exploratory content analysis method from a set of fixed concepts of interest (operation, strategy, perception, self-optimization, planning and preparation, decisions, trading and behavior, interaction, exploration, and searching), representing the cognitive actions of interest and reflecting the design and research questions. These concepts served as broad, deductive coding domains: segments of text were assigned to these domains during coding, ensuring that the analysis remained aligned with the design-focused research interests. While an inductive approach seems most appropriate to uncover the themes due to the exploratory nature of inquiry and the lack of a theoretical basis in behavioral energy economics, the cognitive activities of interest are preconceived and a certain deductive quality is introduced into the content analysis. Therefore, a thematic content analysis with a hybrid inductive–deductive logic, in which coding is guided by the predefined cognitive categories, was applied, and induction took place at the level of interpreting patterns and relationships within and across these categories to derive the themes and insights reported in the results.

Whereas a relational approach (i.e., examining concept relationships) would be most interesting from the researchers’ perspective, the researchers expected the amount of data to not be sufficient to go beyond a conceptual content analysis. This approach is consistent with the purpose of this research and the analyzed information, as suggested by [96]. As the research is highly exploratory, the analysis was interested in the existence of strategies and mental conceptions of the participants, and thus the frequency of the concepts was deemed irrelevant and the analysis was aimed to be emergent–systematic. As such, a modified version of a constant comparison analysis (as described in [98]) was applied, in which segments of text were iteratively compared and coded, and the themes were developed by examining patterns and relationships within the categories for ordering the codes for the axial coding within the predefined cognitive categories. In this sense, the analysis constitutes a modified constant comparison variant of thematic content analysis, rather than a new qualitative method. The initial coding was performed by two researchers not participating in the experiment who also conducted the group interview (i.e., with high familiarity with the matter) to identify relevant sign-vehicles, in order to assess the reliability of coding [96]. These were subsequently ordered with the preconceived categories to identify emergent themes in the step corresponding to the selective coding. After an initial coding with the preconceived categories of perceptions, decisions, behavior, planning and preparation, strategy, operation, UI clarity, self-optimization and exploration and search by each researcher, each coded section of the transcript was discussed. If only one researcher coded the section or sections were coded differently, the coding decisions were discussed and justified until a consensus was reached. This was possible in all cases and helped refine the semantics of the respective codes. The results of the analysis are synthesized in Section 5.1.

The methodology used in this study follows the sketched adoption of the content thematic analysis mentioned above. Data was gathered through a structured interview process that was conducted by a moderator among the researchers not participating in the experiment after the experiment was concluded. The moderator contextualized and asked the questions, but limited himself to refocusing the group discussion when it deviated from the question. A second researcher involved in the development of the software contextualized the discussion when the mechanics of the software were unclear. Questions were brought up when the discussion fell silent and participants seemed to be unable to add new insights. The discussion was recorded with the consent of all participants and transcribed afterwards. Remarks about improving the software or feature requests were screened out, but recorded for future work. The questions for the group interview can be found in the Appendix A.

While focus group interviews and content analysis are usually conducted until saturation is reached (i.e., several groups are performed), this article aims at exemplifying the suitability of the research design for the research problem specified in Section 1.2. As such, the qualitative aspects serve to generate context for the design of future experiments in the LabChain and to demonstrate how a larger-scale qualitative investigation of the perceptions, strategies, and goals of the experiment participants (that might be explanatory in nature) could be performed. Accordingly, the qualitative findings reported in Section 5 should be interpreted as illustrative and non-generalizable, serving primarily to demonstrate how the LabChain infrastructure and evaluation approach can be applied.

4. Research Infrastructure

While the laboratory context and the case design have received considerable attention, the technical design of the LabChain system has not been presented in detail. This section addresses the system as an artifact designed as an interactive prototype for synthetic P2P trade research in experimental energy economics by presenting its architecture (Section 4.1), the UI and its code organization (Section 4.2), and the external components (Section 4.3) involved in it.

4.1. Architecture

The LabChain architecture is organized in three meta-components: the client-side user interface as a front-end, the server-side external components as backends, and the middleware that mediates between the components of the user interface and the external components, as seen in Figure 6.

The LabChain client as the central application of the system communicates with the external components (or more precisely, their APIs) through specific HTTP requests issued by the connector components in the middleware layer. Authentication to the blockchain and database layer is provided through the external components with authentication data specified in the LabChain client. The architecture of the respective layers and components is further specified in the following sub-sections. The external layers are hosted separately from the content-delivery network of the LabChain client. In order to prevent certain cross-origin resource sharing issues, depending on the implementation, middleware connectors may be hosted on a separate server than the rest of the LabChain client.

4.2. User Interface and Code/Software Organization

The user interface for the LabChain system is organized in a set of Angular modules (NgModules) that provide the functionality for different user roles, as well as common functionality (common module) and shared, static functionality (shared module). Additionally, functionality is encapsulated in the core module, which coordinates communication with the blockchain, data store, and clients through websockets and manages the welcome and time component, which are important for coordinating the layers, as well as providing core services (see below).

For the demonstration of the basic functionality of the LabChain system described in this article, roles other than the prosumer play at most a passive role and are not described in the following. As an NgModule, the prosumer modules separate components for presentation and interaction capabilities with local state and services for processing business logic and keeping inter-component states. Components are organized hierarchically, as shown in Figure 7 and roughly correspond to functionality.

Higher-level components (direct child-components of the Prosumer Component) provide the major interface interactions, showing the imbalance of the grid access point (Residual Load Component), displaying the prosumer assets and allowing interaction with the respective assets (Persistent Resource Display Component), offering a form to validate and submit offers to the blockchain component (P2P Bid Editor Component), displaying paid fees and levies (Fee and Levy Display Component) and providing a view of and interaction capabilities with the external market, the P2P market and the transactions already engaged in (Market View Component). While the business logic connected with these functionalities is depicted in the respective services, logic specific to the presentation and interaction of these functionalities is contained within the component.

The user-facing view of the LabChain is exemplified in two typical views for asset operation and retailer interaction (Figure 8) and interaction with other prosumers (Figure 9).

Services

Services are injectable classes that provide business logic or data management for the components. Prosumer-specific services in the LabChain system provide business logic for asset operation (cg-operation-logic.service, load-operation-logic.service, and storage-operation-logic.service) and calculating the net load at the grid connection point (i.e., the prosumer imbalance) based on generation, consumption, and market interactions (residual-load.service).

Most services, however, provide system-wide data and are not specific to the prosumers (and are thus situated in the core module). These services themselves can be separated into client-side services that manage the session, simulation time, and transactions between participants (UI layer in Figure 6) and the interface with external components (middleware layer in Figure 6), with the latter being described with the respective vertical layers in Section 4.3. The session management is implemented through the session-manager.service that loads the data from the respective database connector (in the middleware layer) as specified by the configuration and routes the participants to the respective URL path associated with the role. It initializes the connectors to the other layers (blockchain connector and coordination backend connector as depicted in Figure 6), as well as the session data. The session data (as managed through the session-data.service) is the central data reference of the simulation client instance and manages the prosumer (user) state and experiment instance data. It is further responsible for recording experimental data, such as (user-specific) market activity and asset scheduling data. The temporal dimension of the (client-side) simulation is managed by the time.service that keeps track of simulation time and notifies registered listeners of an update of the temporal dimension (on every time step of the simulation), as well as managing the simulation start and end. Finally, the transaction-clearing.service is responsible for processing market activities the respective prosumer is engaged in; it registers the respective fees, financial implications of transactions and the physical delivery (in the update of the uncontracted energy imbalance through the residual-load.service mentioned above) of both the P2P market transactions and the interactions with third parties (grid operators for power feed-in and retailers for energy purchases).

4.3. External Layers/Implementation

4.3.1. Blockchain Layer

The blockchain layer serves to transparently and securely store the transactions of the prosumers in the P2P market. It documents the submitted (ask and bid) offers, as well as the purchase transactions of the counteracting prosumer through a private Ethereum network that is accessible through an application programming interface (API) on a protected server at the Fraunhofer FOKUS institute. While offers are characterized through their start time, duration, power, and price (as well as the parties involved) within the simulation, their representation on the blockchain is quite different, as described in the background section on blockchain-based flexibility trading (Section 2.2). To translate between the respective representations, an interface was implemented as the blockchain connector in the middleware layer (depicted in Figure 6), which is detailed in the following.

The design presented in Section 2.2 poses several challenges to the representation of the offers outlined in Section 1.3 and Section 2.1:

• How can the market design flexibility required in Section 1.3 be realized despite the rather strict slotting requirements of the blockchain-based representation of the flexibility market?
• How can a monopsony market (single buyer) be adapted to a peer-to-peer market?
• How can the synchronicity of information between clients be ensured without modifying the web server the clients are getting information from?
• How can the requirement to allow for several offers of one participant for one market time slot be reconciled with the blockchain-side validation of only allowing one offer per time slot and resource?

While answering the first question required substantial conceptual effort, the latter three questions could be solved rather easily. Technically, the monopsony market was adapted to allow for any type of market participant to register as a purchaser of offers with the reinterpretation that the subject of the offer was not positive or negative power but rather energy amounts delivered (or more correctly promised to be injected or withdrawn from the grid). The synchronization of agents’ market information was achieved by implementing a watcher service that periodically polled the respective offers from the blockchain and updated the market views in the user interface. In order to address the issue of single offers for one resource, the concept of a resource on the blockchain side was reinterpreted as a one-to-one correspondence between resources and offers instead of resources and energy assets, which were aggregated into one homogeneous load. This reinterpretation allows participants to place several offers within the same time frame with different energy amounts and prices.

Reconciling the market designs (the flexibility-market-based one with fixed time slots and periods that restricted offers of a resource to a singular offer vs. the flexible market design needed for the LabChain) required a more liberal interpretation of the blockchain-side and the simulation-side conception of time and what is meant by a resource. This was done through decoupling the time slots on the blockchain from their physical time and a much more liberal approach to resource semantics.

For allowing offers that span over day borders (e.g., offers of several hours that start at 11 pm on one day and carry over), the original offer structure had to be fragmented into two segments of 48 time steps (i.e., 2 × 12 h).

In the blockchain connector, (physical) blockchain time is used as an anchor relative to the simulation, associating an arbitrary (blockchain-side valid) timestamp $t_{utc}$ with the first time step in the simulation and using the $(48\times i+1)$th time step of the simulation as the ith reference point associated with the time stamp $t_{utc}+i\times \mathrm{86,400}$ as the ith day of day-ahead trading from the trading day starting with $t_{utc}$. This interpretation yields 96 time slot entries in the respective day-ahead offer corresponding to 48 time steps in the simulation. Associating the $n^{th}$ time step of the simulation with the $\left(nmod48\right)$th entry in the $\lfloor {\displaystyle \frac{n}{48}}\rfloor$th and the $\left(nmod48\right)+48$th entry in the $\lfloor {\displaystyle \frac{n}{48}}\rfloor -1$th time step block (for $n\ge 48$) allows for flexibility regarding the context of the time step within offers. This flexibility allows for offers that include time steps from two time blocks (e.g., an offer at time step 47 with a length of 4) in order to prevent fragmentation of the offer. While this approach limited the length of offers to 48 time steps (in the border case), this restriction in the market design was deemed acceptable by the development team. This process is visualized as a flowchart in Figure 10.

• Blockchain Connector Implementation

The blockchain connector is a middleware component that translates between the LabChain-side data representation and the blockchain layer of the whole system through a number of services for resource management, offer processing (reading, writing, casting, and validation), logging and connector management that are provided through an interface service (blockchain-transaction.service), implementing a more generic blockchain interface that provides a number of multicasting observables to synchronize the blockchain-related state of the LabChain client.

The blockchain-related services are connected as depicted in Figure 11.

4.3.2. Database Layer

The underlying ambition of the Energiedatenmarktplatz (EDM, engl.: energy data market) developed within WindNODE was to create an interoperable and easily reusable open data platform for energy-related data sets. The EDM is built on a microservice architecture and a custom pipeline system, thereby facilitating flexible, dynamic, and secure compositions. However, in the context of this project and the respective experiments, it was mainly used to store relevant data related to the experiments in a secure way.

For the sake of (technical) completeness, the following will further describe three main components of the EDM—data acquisition, data hub, and security provider. The first one is responsible for the data acquisition from various data sources as well as data providers. The second main component is the central component to store and register the data. It encompasses a Virtuoso triplestore as a database, Elasticsearch as the indexing server, and an additional MongoDB for storing binary files. In addition, a web application built on Vue.js is available for viewing the energy-related data stored on the EDM. Lastly, the third main component handles authentication, authorization, and identity management. As mentioned, the EDM encompasses multiple microservices, Open-Source software, and a set of APIs. To support Single Sign-On (SSO) for all APIs as well as authentication to all microservices, the EDM makes use of Keycloak as a central identity and access management service. Keycloak also supports federated identities from external providers. Authentication and authorization on both front-end and backend services follow the OIDC (Open ID Connect, https://openid.net/connect/, accessed on 30 September 2025, a layer on top of the OAuth framework, allowing clients to check the identity of a user through an authorization service.) protocol (i.e., OIDC authorization code flow). All backend services also follow OIDC by requiring valid access tokens for each API call. Those tokens follow the JSON Web Token (JWT) standard. Since the JWT tokens contain the required information for user authentication and resource authorization, the backend services can perform the required checks without the need for communication with an additional database or Keycloak.

Similar to the external blockchain layer, all API requests are first validated and, if successful, the relevant information is retrieved or stored.

• Database Connector

The LabChain client is connected to the database layer through a database connector that allows for storing and retrieving experiment configuration and execution data to and from the backend. It consists of a set of classes within the Angular client that allows connections to the EDM as well as a central NoSQL database hosted through the Google Firestore service. For the connection to the EDM, it further provides an Express-based proxy backend with the usage of the axios HTTP client (https://github.com/axios/axios, accessed on 29 July 2021) that prevents cross-origin resource sharing issues.

The EDM connector service provides functions for loading and storing experiment descriptions and experiment instances. In order to authenticate them, it derives an RTP token from a dedicated endpoint of the EDM based on user credentials that is used in subsequent HTTP requests. All respective data sets are stored with the use of semantic data, usually in Turtle format.

Lastly, for connecting to the Firestore backend, the database connector uses the Angularfire (https://github.com/angular/angularfire, accessed on 29 July 2021) library to access the respective collections and documents of relevance in an asynchronous fashion.

4.3.3. Experiment Coordination Layer

The Experiment Coordination Layer (ECL) serves to coordinate the clients participating in the simulation in order to synchronize them temporally. Technically, it consists of a lightweight HTTP server implemented in the Express framework on the Node.js runtime environment, providing websocket-based communication through the socket.io framework, enabling bidirectional communication between the backend and clients in real time.

Upon connection, experiment participants can register for the experiment, disconnect, and signal their readiness through the websockets. For this, prosumers are registered in a list of connected clients. The ECL further allows for triggering the start and end of an experiment, provided the correct passphrase is inserted, which should only be known to the experimenter. For the experimenter to be able to start the experiment, all registered clients need to have signaled their readiness. In this case, the ECL emits a startSimulation event to the participants via the websocket to trigger the client-side cascade of actions taken upon simulation start in the coordination backend connector.

• Experiment Coordination Layer Connector

The coordination backend is connected to the LabChain client through a connector that integrates with the interfaces in the UI layer and the external components. The client uses the socket.io-client library (https://www.npmjs.com/package/socket.io-client, accessed on 15 June 2021) to connect to the coordination backend to emit and listen to events and interfaces with the time.service (Section 4.2) in the UI layer. It allows the participant to register for an experiment and signal their readiness, receiving the start and end signals for an experiment as well as broadcasts of registered users.

5. Results and Discussion

This section presents and discusses the data from the content analysis of the focus group interview data (Section 5.1), as well as the evaluation of requirements for the LabChain research infrastructure (Section 5.2). Finally, this section discusses the extent to which the objectives of this working paper were reached (Section 5.3). These results should be seen as illustrative examples from a demonstration session rather than as generalizable findings. Their purpose is to show how the infrastructure enables the collection and analysis of participant decisions and reflections, and to provide initial indications of how users interact with the implemented market and interface.

5.1. Content Analysis

The interactive simulation of inter-prosumer trade (LabChain) comprised a qualitative investigation of the participants’ perception of their behavior, market dynamics, and the simulation context, as well as their intention and how it translated towards their behavior. As Section 3.2 specified, this was achieved through a group interview following a simulation execution on the basis of structured questions. This interview was transcribed and coded independently by two researchers not participating in the experiment using the predefined cognitive categories as coding domains (with the preconceived categories of operation, strategy, perception, self-optimization, planning and preparation, decisions, trading, and behavior). After coding, the researchers jointly examined the coded material and, through discussion and constant comparison within and across categories, derived the themes and interpretive insights that are presented in the following sub-sections.

5.1.1. Operation

The operation of prosumer assets was reported to provide participants with all the affordances required. This was particularly the case from the perspective of the loads. The mechanics of the operation, however, were reported rather heterogeneously; while some participants attested good operability of their assets, others mentioned that it was hard to coordinate and only easy if they knew exactly what they were going to do.

5.1.2. Strategy

The strategy that prosumers engaged in can be characterized as a combination of a number of related strategic elements pertaining to trade (portfolio optimization, trading positions with price development, activity on P2P market, reactive trading based on basic strategy, and copying retail market strategy), asset management (balancing residual load and demand side management), and asset planning (peak reduction and filling of valleys, coverage of base load band, operation ahead to be reactive, and third-party trade delay). The major strategic goals and motivations of the participants were to be flexible with respect to the avoidance of imbalance penalty and time pressure, risk aversion, profit maximization, and cost reduction. While some participants used different strategic elements and prioritization, others reported that they did not act very systematically, particularly on the P2P market. The employment of these strategies was not static, but changed through the course of the simulation.

5.1.3. Perception

The analysis of perception gave rise to three major themes: (i) the perception of market signals and coverage, (ii) the cognitive burden on the participants, and (iii) the process of gathering information. Market signals themselves were discussed as price perceptions and market coverage perceptions. While price signals have a significant influence on behavior and strategy, they were barely perceived by the participants. Participants reported that price signals were hard to perceive on the P2P market and assessing their own prices remained a difficult task as opposed to trades with the retailer.

They also reported that they were not monitoring the price development and reported price dynamics that were contrary to the actual price developments. This is surprising, since profit maximization and cost reduction were major strategic goals and participants reported that they could procure electricity more cheaply on the P2P market. While many asks were reported to be too large for small loads, the development was seen to become less pronounced. The number of offers in the market was seen to increase throughout the simulation until this trend reversed towards the end of the simulation. Asks were primarily seen at the end of periods of high generation when the energy storage was loaded and excess energy was available. The lack of price perceptions can be explained by the cognitive burden imposed on the prosumers. The development of prices had to be processed on the participants’ own accord, and they reported that they could not memorize them or did not have an overall view of the development. This was further impeded by the lack of interface feedback (or the participants’ utilization) about which offers the participants had already put into the market. Finally, perception included information gathering, both with respect to information about other prosumers and an overview of the whole simulation. Information about other prosumers was reportedly hard to derive and price-setting participants had no indication about the demand of net-consumption prosumers, making it hard to set offers. This was aggravated by their lack of attention to the bid side of the market. Deriving information about the simulation, however, was complicated by the synthesis of different information sources. This was the case as an overview of offers could not be acquired, the presentation of the order book was only one-sided, and because benchmarking feedback was missing, causing participants to ‘fly blindly’. Prosumers reported that they could not derive global knowledge about the market in the simulation.

5.1.4. Self-Optimization

Self-optimization was a major strategic element of the participants’ behavior, as the purpose of the simulation was seen in working against balancing power and to balance out the grid access point. Reported motivations for this were to maximize self-consumption, reach supply reliability, and to make their energy balance look less threatening. The time frame of self-optimization was reported to be 1 or 2 simulation days rather than the entire week. This was mostly achieved through the participants’ energy storage, in particular to smooth the load curve and was done almost entirely on the retail market. Self-optimization was implemented through balancing imbalance fluctuation and through load shifting. The behavior of load shifting was reported to change throughout the simulation due to learning. Where it was reported to be focused on smoothing the load curve first, the behavior changed to a strategy where consumption was shifted into time frames where energy was more cost-effective to acquire.

5.1.5. Planning and Preparation

In addition to the longer-term time frame of self-optimization, both storage and offers were planned long-term. The storage was reported to be scheduled for several days in advance, for some participants even roughly partitioned over the entire period in the beginning. Similarly, the time frame for offer management was about 20–30 simulation hours in advance, reportedly due to the delay in offer processing. The planning period was furthermore influenced by long-term offers, which prompted participants to zoom out to the whole simulation perspective when long-term asks were observed. A motivation cited for this was the time pressure in the short term, which, inevitable in the beginning, caused participants to engage in less strategic behavior. Strategic aspects of planning and preparation were seen in the optimization of the portfolio, the use of a basic strategy to be balanced in the short term to be able to focus on the long term, extensive use of the storage asset, and the use of a base load band to reduce fluctuations. Strategy implementation aspects were to increase the length of these load bands for long-term planning and early commitment to offers to accommodate potentially long processing times.

5.1.6. Decisions

Decisions within the simulation were predominantly directed towards trading, in particular to price setting. These were reported to be made primarily on the basis of price curves of the retailers, partly because information was not structured sufficiently on the market to allow for price setting and the price ranges of third parties were the only point of reference (causing some participants to decide based on their ‘gut feeling’). This was further supported by the uncertainty of the future, as price setting was reported to depend on the expectation of the future. The influence of existing offers and risks was reported to be minimal or not existent at all. Criteria for the decisions were deriving an advantage from the trade, the size and price of offers, and the fit for the participants’ strategy. Furthermore, a match of the dimension of the load and the offer and the general price level was important, but participants reported that it was hard to cover the load demand on the P2P market, and that it was hard to derive global knowledge within a short time frame. It was moreover observed that the challenge of decision making depended on how easily a decision could be parameterized and thus formulated. Reaching decisions required price setting and deciding the amount of energy to introduce into the market, with the latter leading some participants to decide whether to enter the P2P market at all. Goals involved good storage management and its inclusion with market activity, as well as the prevention of risks and the reduction of peaks. Decisions were also influenced by the time pressure of the progression of the simulation and the uncertainty of submitted offers to the market.

5.1.7. Trading

In addition to specific trade behavior and perceptions, participants also discussed a number of other trade-related topics, pertaining to market design, trade behavior, intention, dynamics, and matching issues. The discussion on market design focused on the need for volatility, market depth, and market size. Participants observed that the market was too small for some strategies, for which too few consumers or offers existed. The large size of asks caused a small volume of trading, and often no alternative was available, so participants had to take what was offered. The pace of the simulation was further observed to have an adverse effect on market effects. Observations regarding trade behavior were centered on the particularities of the simulation. The novelty of the system was observed to require some experience that would allow participants to come together with others over time and was referred to as experimentation numerous times. Participants with generation capacity reported that they were not able to procure energy when they were short and that they mostly were focused on the retailer, in particular when no offers of interest were in the market. Price setting was usually not sensitive to risk perception and attempted to be somewhat heterogeneous. They were reported to be uncertain due to the lack of information on other participants’ asset composition. Prosumer intentions were focused on risk adversity, energy procurement in time when it was inexpensive, and the modularity of offer combinations. The uncertainty of the market furthermore prompted a switch away from a more rational optimization strategy. While the dynamic was expected to be rather short-term on the P2P market, the need to plan ahead mentioned above drove it more towards the long term. Participants reported that throughout the simulation fitting offers appeared that matched their strategy and were cost-effective, which they tried to acquire. While dynamics were perceived mostly towards the end of the simulation, they were predominantly reported to be uninteresting as they did not fit the participants’ needs or were too few in number. Stronger dynamics were hypothesized to be present without the time delay of the simulation. Finally, participants reported that small loads had trouble fitting with larger producers and storage units had issues serving the required load bands.

5.1.8. Behavior

Behavioral aspects were discussed predominantly in terms of impulsiveness and less informed behavior, as well as behavioral influence and priorities. Impulsive behavior was reported in transaction creation with no information about other participants, the lack of strategy in trading behavior, trying out different things, or even clicking something just to do anything, Less informed behavior was seen when market coverage was too sparse for reliable price setting, heuristic load smoothing without assessing price levels, or lack of detailed price information procurement, with a focus on purchasing outliers. Behavioral influences were reported through price dynamics of the retailer, time pressure for P2P trading, and its influence on the rate of mistakes with the user interface. The main point of orientation and contact was the retailer, which received most attention from the majority of the participants reporting their behavior. Similarly, balancing the grid access point at the beginning of the simulation was the most important priority. After this, the P2P market was seen to be the next point of action. With respect to load bands and the learning effect, this was done with attention to the storage in order to be compatible with the behavior. In addition to the aspects discussed above, phenomena pertaining to motivation and reactiveness, dynamics, interaction, and exploration were discussed. Reactive motivations were seen in balancing the grid access point after offer transactions were registered, in particular in the retail market and in reaction to the own composition of offers in the market. Other motivations were to work against the penalty more than market signals, smoothing offers, risk-averse behavior, and load band acquisition for balancing. While dynamics were seen through the learning process, participants also reported that their behavior did not change over the course of the simulation. Interaction and exploration manifested themselves in market observation of both the P2P and retail market and reaction to suitable offers of peers, retail transaction delay, and a change of behavior of long-term sales to the grid operator to a more uncertain, shorter-term P2P market.

5.2. System Requirement Evaluation

Section 1.3 introduced a number of requirements and assumptions of the system that are evaluated in the following section and visualized in Figure 12.

5.2.1. P2P Market Requirements

PMR 1:

Allowance for Market Approach Heterogeneity

The market requirement PMR 1 asked for a market approach that allowed for heterogeneity with respect to bid-matching and pricing. In the LabChain system, markets are parameterized by independent parameters specifying gate closure, trading windows (time slice length), price caps, minimal offer sizes, and transaction fees, with gate closure and offer sizes independent for both market sides (bid and ask). Market participants can submit and accept offers independent of one another and price setting is only restricted by the market design chosen by the study, i.e., allowing for the large heterogeneity of market designs required by Section 2.1.

PMR 2:

Atomic and Modular Market

As elaborated above, the market design modeling in the LabChain system is rather fundamental. The individual offer, as the smallest market unit, is chosen as the foundation, specifying delivery time, duration, unit price, quantity, and the participating parties. With this, it is only constrained by the market design built on top of it, which itself specifies the gate closure for different types of offers, the length of a (trading) time slice, the minimal size for different offer types, the maximal price, and the respective fees. This allows for numerous flexiblility market designs. With the possibility to mark the price as unlimited, ceiling-free markets can be depicted as well. This atomic and modular foundation allows building a large variety of matching algorithms and complex offers that are not inherent in the fundamental design, thus addressing PMR2.

PMR 3:

Flexible Prosumer Roles

The basic instantiation of the LabChain system described in this article includes only a small number of roles in addition to the prosumer (the researcher for experiment supervision and evaluation, the grid operator as rudimentary role to supervise the grid (and see the grid fees), and the public actor as passive role representing the political, administrative and regulatory authorities) and prosumers are free to take on functional roles (such as traders, aggregators, and energy community managers, as noted with the market roles in Section 2.1). While this enables prosumers to informally take on these roles, the software does not provide tools assisting prosumers in this, thus only providing this to a limited extent.

PMR 4:

Finely Granular Behavior and Strategy

The flexiblility market design of the system allows prosumers to place highly differentiated offers and operating assets in a fine-grained way. Through this it allows them to engage in a number of behaviors and strategies. However, during the focus group interview, prosumers reported a number of strategies they would have followed if the software provided the respective possibilities or made it easier to engage in these strategies. While these strategies would have been theoretically possible, in the current design, they would have taken too much time, preventing the prosumers from engaging in them.

PMR 5:

High Degree of Market Control

As mentioned before, the atomic and modular market design afforded the prosumers a lot of flexibility and freedom; however, as observed with PMR 4, this freedom came at the cost of high cognitive and temporal requirements to express more complex intentions. Also, since the design does not allow for more complex products, such as block bids, conditional bidding, stop orders, etc., offer structures requiring coupling are not inherent in the design. Due to the time delay of the blockchain processing and the lack of visual feedback on accepted offers in the market originated by the prosumers, participants did not experience as high a degree of control as intended by design. While the modular and atomic design is intended to allow for maximal control, in practice, participants experience somewhat limited control.

5.2.2. Software Requirements

SoR 1:

Affordances for Market Participation and Asset Operation

As the evaluation of the focus group interviews showed, market participation and asset operation were perceived by the participants to mostly allow for pursuing their intention. However, due to time pressure and unclear interfaces, market operation was seen as difficult at times, partially to the point where participants refrained from being active on P2P markets. The affordances for market participation were thus not addressed to the degree necessary for full participation.

SoR 2:

Allow for Planning and Preparation

Experiment participants reported a predominantly positive experience of the user interface with respect to planning and preparation. This was particularly the case for asset operation. Reported time frames for P2P trading were considered well in advance and trading behavior was strongly coupled with planning and preparation. However, due to difficulty with the user interface in engaging in P2P electricity trade, not all participants could participate through trading as desired.

SoR 3:

Clear User Interface

Clarity of the user interface is essential for participants to translate their intentions into actions. The user interface came up several times during the focus group interview. Participants mostly reported that they could implement their intentions accordingly. However, the user interface required considerable cognitive resources, in particular with respect to trading behavior. Some participants reported that it was not clear during the simulation how they would go about doing things. As such, user interface clarity was only partially met, and significant effort should go into user testing and interface development in the future to increase the efficacy of actions. This is particularly the case when the lack of behavior of the participants cannot be attributed to the market design or the design of the user interface. A clear user interface is key to investigating behavior based on market design.

SoR 4:

Modular Software Design

The software of the LabChain system is compartmentalized into different components with middleware-layer connectors implemented in the Angular framework. Each layer is a stand-alone component that is used for different use contexts in itself (except for the dedicated coordination backend). The user interface layer itself is organized in several modules, which are themselves logically subdivided into services and components. This modular implementation allows for easy adaptability to new functionality and contexts, addressing the software requirement 4.

5.2.3. System Requirements

SyR 1:

Real Implementations of Technologies

The layered component architecture of the LabChain system was chosen so that real existing components could be implemented independently. The blockchain layer is based on an implementation of a private Ethereum blockchain behind an API. While the choice of the blockchain to be a private network is not the most natural choice for a P2P approach (or any decentralized ledger technology), the energy sector is a heavily regulated application context, and central solutions are not unlikely to be used at first.

The database layer was intended to be covered through the energy data market open data platform. While the use of open data is a promising approach to break the data silo mentality that prevents the energy sector from reaching its full potential, this solution is problematic for laboratory contexts that address human behavioral data for privacy and ethical reasons. For the execution of the laboratory experiments, a central, cloud-hosted (logically) centralized NoSQL database was chosen. While this is a feasible choice, it can be debated whether this would constitute a real implementation of the required technology.

The coordination layer was implemented as a node.js backend with the socket.io framework. While this is a popular server-side technology and synchronization framework, this component would not be extant in a real implementation of P2P trade and is excluded from the discussion.

The UI layer was implemented in the Angular TypeScript framework, one of the ‘big three’ frameworks of the most popular web language. As such, it can be expected that it constitutes a real implementation of the technology. However, due to the popularity of smartphone- and tablet-based apps, a major usage format of the UI was not implemented.

All in all, the technical feasibility of the approach was demonstrated appropriately, even if some of the technological choices did not fully meet the requirements.

SyR 2:

Understanding Technology Idiosyncrasies

The use of real implementations of the technologies involved in the LabChain is intended to allow for experiencing the idiosyncrasies of the technologies through their behavior. As the idiosyncrasies of TypeScript are experienced primarily by developers and are usually much less exposed to users than their design decisions, participants are expected to experience few idiosyncrasies beyond the general experience of a web app. The only idiosyncrasy of a routed navigation was seen in the request of the researchers not to hit the ’back’ button as it would invalidate the state. Similarly, the coordination backend went unnoticed by the participants as it was abstracted away by the coordination interface and is only triggered at the beginning of the simulation. The database layer is of much more interest to the researchers than the participants. Experiment configuration is stored before the beginning of the experiment and behavioral data is stored afterwards. The only (potentially) noticeable idiosyncrasy of perception for the participants is data loading (which means a slight delay in populating/loading the view) and the request of the researchers not to close the browser window during the experiment and directly after the experiment. The blockchain layer, on the other hand, does come with considerable idiosyncrasies that were also experienced by the participants. This is particularly the case with the high transaction time and its variability/uncertainty (compared to a central database), but also to a smaller degree with participants intending to transact an offer that has already been transacted by another participant. Due to the private blockchain, no state inconsistencies that would be perceptible through the revocation of a transacted offer through the consensus could occur. Yet, participants could attempt to transact an offer that was marked for transaction before. This was, however, not reported by participants and went under in the noise of transaction time uncertainty. This latter phenomenon was very perceptible to the participants. Offers that were requested to be transacted took an unforeseeable time to process and made planning very hard. Participants repetitively reported that an offer they did not expect to transact still was recorded and threw their balancing behavior out of alignment. While time frames in a real implementation would be expected to be much longer (and the effect playing less of a role), this behavior of blockchain technology became very obvious to the participants.

SyR 3:

Flexible Configuration

As mentioned with requirements PMR 1 and 2, the market design was modeled to be very flexible to accommodate a large range of market designs. Prosumer assets (loads, storage, and PV systems) exhibit a range of parameters within sensible bounds (e.g., storage cycle efficiency being in the unit interval) and can in theory accommodate assets of any size. New parameters can easily be added with little adjustment in the respective components. This requirement thus was deemed to be fully met.

SyR 4:

Behavioral Data Recording

Prosumer behavioral data encompasses all operating parameters of the assets modeled in the system, as well as trading behavior, contextual data, and filter settings. Through this, a large range of data can be recorded, allowing for rich analyses. New behavioral parameters can furthermore be incorporated with little effort when specified, meeting requirement SyR 4.

5.3. Discussion of Objectives and Research Questions

The objectives of this research were the requirement identification and software implementation of the system, as well as the case study design, simulation execution, and data analysis. These objectives thus comprise the design, implementation, and demonstration of the system and the research approach around it. As the demonstration of the proof of concept of the idea and research approach, it was thus not aimed at providing empirically grounded insights into P2P market design or prosumer behavior, as can be seen both in the application of experimental energy economics and the execution of one single laboratory session.

The research problem was structured consistently through deriving 13 requirements that were systematically addressed. While the software development process is not shown in this article, it led to a functioning software system that was used for the subsequent objectives of this article. The code of the software is well-documented in a shared repository and a web-based documentation, and the development process can be seen through the commit history of the repository. For the demonstration of the system, a case study was devised that depicted a realistic, urban setting with an appropriate data selection and grounded assumptions that were transparently communicated. Laboratory participants were recruited and a simulation session was successfully executed, proving that the system and approach work well in general. While this was not empirically sufficient in sample size, it met the objective of demonstrating the proof of concept. The data recorded from the interactive simulation was analyzed through a transparently described methodology; again, insufficient data was collected to reach theoretical saturation, which lay out of the scope of this article.

All objectives were thus addressed well, and the weakness of the studies’ illustrative character was identified and openly communicated.

While the research objectives focused more on the design of the software and the methodology itself, the two research questions concentrated on their effectiveness and the affordances and perceptions offered to the laboratory participants:

• To what extent does the implemented LabChain prototype fulfill the system requirements and thus support the investigation of prosumer behavior in synthetic P2P electricity markets?
• How do the laboratory participants perceive the system’s affordance and where does the system fall short in empowering the laboratory participants?

Within the limits of this single, illustrative laboratory session, the evaluation indicates that the prototype fulfills most market, software, and system requirements at least partially, and in several cases fully, and can therefore support the investigation of prosumer behaviour in synthetic P2P electricity markets. The exploratory laboratory session further suggests that participants perceived many of the intended affordances—particularly for asset operation and planning and preparation—but also reported missing or cumbersome features in the trading interface and feedback, highlighting where the system still falls short and requires refinement in future iterations.

The research design hinged on three main assumptions:

• Variation in prosumer electricity trade behavior can reasonably be measured within a laboratory context;
• The LabChain system provides the affordances relevant for P2P electricity trade;
• The LabChain P2P exchange model provides the versatility required to compare heterogeneous cases within the discourse.

The research results and infrastructure are only as good as the scope of how far these assumptions hold. This can thus be seen as a limitation of the validity of the research; where they do not hold, neither does the laboratory infrastructure.

While assumptions (1) and (2) can at least partially be assessed within the scope of this research, assumption (3) requires the investigation of different market designs within this research infrastructure and needs to be addressed in future research.

The group interview has shown that the participants engaged in quite variable behavior, both in their trading and their perception of the system overall. While some affordances were missing from their perspective, the system generally offered the affordances relevant for P2P trade. Overall, it can be said that assumptions (1) and (2) mostly held, strengthening the overall credibility of the research.

While this assessment did not solve the research problem of a lack of a comparison and benchmarking structure, an important building block requiring the comparative investigation of several designs in the future has been devised (see Section 6.2). The application of tools from behavioral economics and a less techno-economic focus in this article was an important step in addressing the research problem, however.

6. Conclusions

While the description of the LabChain system in [16] focused on the development process and showed future directions of the software artifact itself, this article is centered on the application of the framework within a context constructed for this study.

The use case was evaluated through an in-depth analysis of the laboratory participants’ perception of the context. As the research question required the investigation of real-life participants within a simulative context (covering the demand for behavioral realism to model real-life behavior) within the scope of this working paper, it is to be interpreted as a proof of concept of the LabChain approach, rather than as a fully fledged experimental energy economics study. Instead, it is intended to give insight, allowing the assessment of future work.

As the demonstration of the proof of concept of the idea and research approach, it did not aim at providing empirically grounded insights into P2P market design or prosumer behavior, as can be seen in the execution of one single laboratory session. Instead, it serves to show that the LabChain infrastructure and workflow can be implemented end-to-end and to provide initial indications that can inform the design of subsequent, more extensive and incentive-compatible experiments.

As Section 5.3 noted, the objectives of this research were met, and the requirements were mostly fulfilled. As a proof of concept, the research was seen as successful; however, due to the design of this study, it did not prove that benchmarking or comparison is possible through the LabChain. In order to be able to claim that the system and research approach can be used in a comparative manner for market design, heterogeneous market design executions need to be performed and analyzed with the appropriate methodological tools.

6.1. Limitations

Designed as an exploratory approach in a young domain, this research comes with a range of limitations of the article’s approach, the design of the case, issues with the laboratory-based methodology, and the developed software. A limitation coming with this approach lies in its illustrative nature as proof of concept. To showcase the method and developed infrastructure, only one session was executed, which is far too little to derive any meaningful data for experimental insights. As the goal was an illustrative execution of the method, the feasibility of the approach was shown by developing a research design that allows addressing energy economics and experimental research questions in larger-scale research.

This point could further be extended to the singular case design of the case. Only one asset combination was investigated (which was, additionally, not strongly empirically or theoretically based), and no variation in market or system design was measured to contrast the results with. Due to this, results could just as well be artifacts of the dynamics of the exact run, and effects could not be distinguished. Through limiting the execution with human participants to only one iteration, learning effects can easily be confused with effects of dynamics. While this design is adequate for demonstrating the feasibility of the infrastructure and method, it restricts the robustness and generalizability of behavioral and system-level insights.

These limitations of the proof of concept carry over into the experimental design as well. An illustrative point is the lack of monetary incentives to the laboratory participants. Participants faced no real financial consequences, had no personal attachment to the simulated assets, and did not receive performance-based payments. As a result, the observed decisions should be interpreted as exploratory interaction with the LabChain system and its P2P market design, rather than as externally valid evidence on household trading behavior under financial risk. Fully specified market experiments should be very aware of the motivation and incentives of laboratory participants and should therefore adopt incentive-compatible payoff schemes and, where possible, involve participants with more realistic stakes in asset operation or energy costs.

Another set of limitations concerns the design of the case study used in this investigation, in particular, the economics of the peer-to-peer exchange. As it is commonplace in P2P-related research not to model fees and levies as well as grid state to a degree that is necessary for a full consideration of the influence of congestion and the regulatory context, the case without fees was chosen for this research. The large spread between the retail price and the grid feed-in tariff allows the investigation of large price corridors, which was not done within this research design, but comes with the same limitations as noted above. However, to study the merits of P2P trade vs. other concepts, such as direct marketing or through an intermediary actor, a more realistic case needs to be investigated. Furthermore, P2P trade rarely occurs without context, and research approaches in this avenue need to be more sensitive, be it through coupled microgrids, islanding, energy communities, smart districts, etc. These specific contexts pose requirements beyond the more generic ones set out in this article, and the presented approach only shows the more general approach to studying interactive, human-centered P2P trade. Future work should be more sensitive to these matters in case design in order to provide fairer and more substantiated results.

While the limitations noted above were related more to the specific issues of this study, some more general limitations also exist. A set of these limitations has to do with the more general issues of the artificiality of the laboratory setting. Real-world behavior is often contextual and the lack of attachment to one’s own assets and financial situation is a distorting factor by itself. However, an artificial laboratory setting where participants’ attention is focused purely on energy trading is even more detached from the real experience of peers. The sole focus on energy trading and asset operation is especially unlikely for household prosumers. This intensive asset operation and energy trading is thus interesting, rather indirectly, and can be valuable for deriving preferences for automatic trading or behavior schemes for agents representing the households, rather than serving to obtain insight into active energy trading by households in real-life contexts. Similarly, the game context that participants are involved in is emotionally detached from real life and thus less instructive to gain insights into participants’ real behavior.

Finally, a set of limitations relates to the design and use of the software. The LabChain framework constitutes a non-trivial software artifact, touching on different systems built for this within the project by a small team; the software can thus not be expected to be of the same maturity as professionalized research tools that were developed over a longer time frame. More seriously still, little possibility existed for user testing before the experiment. The experiment showed that some design assumptions did not hold (for some users) and that the system needs more user feedback iterations in order to be understood by users as intuitively as required. In commercial software development, the intentions of designers and users often differ somewhat, and this is no different with scientific tools. However, continuous evaluation and user testing could lessen the gap and improve the software over time. The design science research methodology and path for future work sketched in [16] seem to be a promising avenue that provides powerful tools to address this and should be pursued in the continued development of the software.

6.2. Future Work

Future work within the context of the LabChain system is seen in different strands for the development and improvement of the design, the application of the LabChain system, and methodological improvements. This would address many of the limitations noted above, allowing for more in-depth and more relevant investigations beyond this proof of concept.

The strand of the development and improvement of the LabChain design itself can be improved in at least two ways. As noted with the analysis of the focus group interviews, not all design decisions of the development team were as effective as intended. As suggested in [16], Design Science Research is a promising approach in addressing (and improving on) the design of artifacts in socio-technical systems in a structured and scientifically rigorous way. This approach would help to create an effective design where user perception agrees with designer intention and would thus allow the evaluation of the market design rather than of the user interface. Another facet of the development is the improvement of the software. Despite extensive testing, some bugs became obvious only during the execution of the experiment and it is reasonable to assume that more bugs have not been detected yet. Improvement on the LabChain software could address this specifically. This is particularly the case for recording behavioral data, which did not produce the data quality required for more multi-faceted analyses. Furthermore, the focus group interview showed the need for including more features. The extension of the software to depict all requirements in the software would provide valuable information for future approaches and fields of application as well. Another interesting direction for future work in this domain would be to refactor the smart contracts and to base the system on smart contracts that are explicitly designed for P2P electricity exchange, as, e.g., done in [92].

A different strand for future work on the LabChain system consists of the application of the LabChain system on a larger scale and of more sophisticated use cases and specific contexts. As this article was of an exploratory nature, only one session was executed and used for the analysis and the results might well be artifacts of this. An avenue of future work would thus be to conduct empirical studies with sufficient sample sizes in order to reach theoretical saturation and investigate more sophisticated research questions.

A natural next step would be to record and analyze quantitative data to apply the real effort paradigm instead of the stated effort paradigm implicitly used in this research. This would add a whole new level of empiricism to the research and allow insights into actual participant behavior. Data recorded in accordance with bounded rationality decisions would also be very valuable to be contrasted with analyses performed through rational optimization to see the influence and dynamics of behavior in real socio-technical systems. Such multi-paradigm comparative research might be very valuable as an ingrained part of a benchmarking infrastructure. For this, careful design of mixed-method research tools and a thorough discussion of how they integrate in the research process will be necessary.

A further step beyond this would be to perform comparative mixed-method studies. Through evaluating different market designs (against a reference case and one another), a much more complete picture would emerge and the practice of isolated evaluation of market design proposals that dominate the field could be extended with a comparison. This could lead to a more active and more informed discourse that would benefit the maturity of the proposed market designs.

In addition to the avenue of larger data sets and more quantitative methods, the LabChain concept could further be adapted to specific contexts. This would be particularly interesting for the virtual community case, where analyses of the price dynamics, coupled with discussions of social and equality dimensions with regard to fee sharing, the business model, and community governance might be of interest. This would be even more interesting if related to game-theoretic approaches (e.g., considering the Shapley value). The proposal for a research agenda below suggests a range of avenues for the investigation of use cases and research questions.

Which of these avenues (or combination of which) will be realized also depends on the field and the development of the discourse. Most of all, the LabChain system is a contribution to the field, with an invitation to work towards a common benchmarking structure, in order to derive fair comparisons of market or system designs. The LabChain system was designed to be adaptable to many approaches and designs and the authors believe that it would be very profitable for the field to contribute to the discourse.

• Proposal for a Research Agenda

The investigated case was of a rather simplistic nature. The LabChain system is designed to both address more elaborate cases and, through its modular nature, to easily be extended to address a number of research questions in experimental energy economics. Possible research questions could include (but are not limited to)

• Which price developments can be expected in (spatially) limited inelastic systems (such as microgrids) without economical balancing structures, such as external markets, risk aggregators, fixed purchasing rates, price-regulatory effects, etc.?
• What is the influence of different dynamical grid tariffs and fees on the actors in this system?
• How can the problems leading to dynamic grid tariffs be addressed by demand response or demand-side management measures? What economic benefit does this create or impede?
• What is the influence of flexible assets (such as storage units, flexible loads, flexible generators, etc.) and their connection to external systems (such as other microgrids) on the price dynamics addressed in the previous questions?
• How can the economic added value of asset flexibility be determined in this context? What pricing models (such as cost-based vs. opportunity-cost based vs. system benefit-based) can be used and what is their effect on the system? How can flexible consumption (as opposed a reference load curve) be determined? How can individualistically beneficial, but system-wide harmful strategic behavior, such as gaming, be prevented?
• What is the economic added value of flexibility platforms? What form do positive or negative effects take? What are the consequences of planned or implemented flexibility platforms?
• What is the influence of assigning redispatch cost to the originators of grid congestion on the (local) trade behavior?
• Which approaches exist to embed balancing group responsibility in P2P markets or microgrids and what are their (dis-)advantages within the laboratory context?
• What is the effect of introducing (different forms of) balancing markets into the considered use cases and research questions? To what extent does this depend on the restrictions of entrance of the assets? What is the effect of different sales possibilities of generators for different markets (such as energy-only markets (peer-to-peer, spot, and futures markets), flexibility markets, and reserve/balancing markets) on the systems driven by these markets, generator profitability, and consumer prices? What is the influence of market transparency on these research questions?
• What is the influence of transparency of offers and transactions on these price dynamics?
• What is the influence of the integration of spot and derivative markets on the investigated P2P markets? How does this influence differ with different market designs and whether these markets are endogenous or exogenous (intrinsically within the simulated system or extrinsically as a possibility to trade energy into/out of the system) to P2P the markets?
• What is the influence of aggregators in a highly granular market? What is the impact of market granularity on business models and what new business models does it enable? What is the influence of virtual power plants within the context of these business models and what are the (dis-)advantages compared with decentralized approaches?
• What forms of risk pooling do P2P markets and microgrids allow for and what are the (dis-)advantages of the different approaches?