1 Introduction

The blockchain is frequently referred to as the technological innovation of the twenty-first century, which arguably possesses the potential to reshape and disrupt a plethora of economic activities. Since its introduction in 2008 (Nakamoto 2008), the concept of a distributed database that is governed and maintained without any central authority has recently outgrown its use as a verification mechanism for cryptocurrencies and is heading to a broad field of commercial applications. Today, the “trust machine” (Economist 2015) – which basically combines a distributed digital ledger, a decentralized consensus mechanism, and cryptographic security measures—is preparing to revolutionize the role of intermediaries and institutions by enabling new forms of value and supply chains, business models, and market structures. In consequence, visions of trust-free, transparent, and secure transaction systems (Beck et al. 2016), decentralized asset management approaches, autonomous registry systems (Fairfield 2015), and immutable event logs announce disruptive changes in organizational structures and business processes (Glaser and Bezzenberger 2015).

In this paper, we utilize the use case of the Danish Motor Register (DMR) to present a new way to record, manage, and track the status of ownership of physical assets, such as cars, and develop, implement, and evaluate a blockchain-based transaction system that aims to replace centralized institutions as trusted third parties. We have chosen Denmark as a technologically advanced nation and a front-runner in the digitalization of governmental services to illustrate the benefits of blockchain-based systems with respect to public registry and transaction systems. In collaboration with the Danish tax authority (SKAT), we explore the potential of a blockchain-based car register and illustrate how it might be able to replace traditional trust-based, centralized, and bureaucratic systems.

Within this scope, the contribution of our research is threefold: First, we introduce a built-in mechanism to reduce transaction risk associated with the irreversibility of blockchain transactions (Böhme et al. 2015). Second, we address the challenges of providing and maintaining a complete and consistent public record of vehicle history by replacing a traditional register with a blockchain-based alternative that includes a secure registration and transaction process. In doing so, we illustrate how to replace a potentially expensive, trust-based, incomplete, and inconsistent bureaucratic registry with an autonomous and potentially cost-efficient transaction log. Third, we propose to mitigate adverse selection effects in used goods or lemon markets (Akerlof 1970) by providing a reliable, transparent, and complete record of each marketable asset’s history. In addition, our generic software design introduces a generalized transaction framework, in which the DMR use case inherits its core functionalities from the high-level framework. This way, we take practical considerations into account as the generic system design allows the extensions to other assets and ensures applicability beyond the use case of cars.

In accordance with Gregor and Hevner (2013) the remainder of this paper is structured as follows. In Sect. 2, we provide an introduction to blockchain-based commercial systems by reviewing recent academic literature, introduce the use case of the DMR, and discuss the effects of adverse selection in lemon markets. In addition, we identify relevant gaps in existing blockchain research and formulate three research questions accordingly. Section 3 introduces the applied design science approach and highlights our guidelines as well as our main contributions. After this, Sect. 4 describes our blockchain-based IT artifact, including its software architecture and the prototype’s market design. Sections 5, 6, 7 evaluate, discuss, and conclude our results respectively.

2 Blockchain-based Commercial Systems

This section provides a brief introduction to blockchain-based commercial systems, outlines the DMR use case, and identifies a research gap at the interdisciplinary intersection of the fields of information systems and economics. In consequence, Sect. 2.1 reviews recent literature about blockchain-based systems, Sect. 2.2 illustrates the use case of the DMR and its practical challenges, and Sect. 2.3 introduces the problem of adverse selection in lemon markets, such as the market for used cars.

2.1 Literature Review

The blockchain was first introduced as a mechanism to prevent double-spending in the peer-to-peer electronic cash system known as Bitcoin. Based on the underlying idea of Nakamoto (2008), blockchain protocols provide an immutable record of transactions by combining a distributed database comprised of chronologically ordered and cryptographically interconnected blocks of transactions with a decentralized consensus mechanism and cryptographic security measures (Glaser 2017). The interplay of these elements impedes the dissemination of corrupted information and moderates frictions among potentially conflicting agents without the need for a central governing institution or authority (Fairfield 2015). In combination with smart contracts (Szabo 1994), i.e. programs running on the virtual machine borne by the peer-to-peer network of blockchain nodes (Buterin 2013; Wood 2017), the technology has outgrown its origin in cryptocurrencies and is heading to a variety of commercial applications (Nofer et al. 2017).

With its potential for disintermediation and its capability to mediate and resolve multilateral conflicts, the blockchain’s disruptive impact is not limited to the financial service industry (Wörner et al. 2016) but rather encourages discussions about use cases across various industries. Potential applications include decentralized market and application platforms, notary services (Wörner et al. 2016), digital proof of identity and legitimization (Wörner et al. 2016), digital rights management systems (Fujimura et al. 2015), validated, immutable, and consistent registries (Fairfield 2015; Glaser 2017; Xu et al. 2017), and transaction systems that track the ownership of (digital) assets (Fairfield 2015; Beck et al. 2016).

From a technological perspective, the consensus mechanism enables the creation of new blocks and allows agents to autonomously agree on the correct order of transactions and a shared system state at any given point in time (Buterin 2013) by decentralized timestamping (Gipp et al. 2015). However, to implement an effective mediation mechanism, the applied consensus scheme needs to be tailored to the specific use case at hand:

In public and anonymous scenarios, the creation of new blocks has to incur a sufficient amount of costs of effort, in order to prevent the dissemination of corrupted information. As a result, this increased cost of deception reduces the presence of conflicting information throughout the system (Lamport et al. 1982), mitigating the risk of Sybil attacks (Dinger and Hartenstein 2006; Douceur 2002). In practice, mechanisms such as proof-of-work (Nakamoto 2008; Anderson et al. 2016), proof-of-stake (Anderson et al. 2016; Kiayias et al. 2016), or proof-of-space (Ateniese et al. 2014; Dziembowski et al. 2015) artificially create costs for adding new blocks, and thus discourage potentially malicious nodes from tampering with the data. On the downside, they also create a tremendous amount of overhead costs, for instance in the form of electricity (O’Dwyer and Malone 2014), and thus impede the system’s efficiency.

In private networks with known participants on the other hand, there is no threat of Sybil attacks and expensive conflict resolution is not necessary. Therefore, identity-based identification schemes (Bellare et al. 2009), such as hash-based user authentication (Li et al. 2015), provide more efficient alternatives that also allow for different levels of privacy.

In summary, blockchain technology offers a distributed software architecture (Xu et al. 2016) that possesses no single point of failure or requirement for centralized governance. As a result, it enables autonomous, transparent, secure, and tamper-free transactional databases (Glaser 2017), reduces the complexity of writing contracts (Davidson et al. 2016), facilitates cost-efficient micro transactions (Beck et al. 2016), and allows for the emergence of novel organizational forms and business models (Glaser and Bezzenberger 2015).

Within this scope, Greiner and Hui (2015) introduce the notion of trust-free systems and propose to address trust issues in peer-to-peer systems by eliminating the need for trust. Consequently, costly trust-building mechanisms, such as trusted intermediaries, governing institutions, or interpersonal trust are replaced by cryptographic protocols, decentralized consensus algorithms, and smart contracts (Greiner and Hui 2015; Glaser 2017). Beck et al. (2016) apply this notion to the perspective of blockchain-based commercial systems and develop a proof-of-concept prototype of a transaction system, which “operates trust-free by completing transactions on the basis of self-enforcing rules” (Beck et al. 2016). The concept of being trust-free, however, remains ambiguous, since one could argue that trust will not be replaced but shifts from central institutions or market authorities towards algorithms (Lustig and Nardi 2015), which eventually govern the agents’ interactions (Maurer et al. 2013). Besides this ambiguity, understanding the technical protocols and implementations of distributed ledgers, decentralized consensus systems, and decentralized applications remains complex (Glaser and Bezzenberger 2015) and researchers and practitioners still struggle to grasp their full potential.

Aside from usability concerns, blockchain-based systems still face a variety of technological challenges as well. First, due to their nature as a transaction-based systems, smart contract applications cannot trigger themselves, but rather require some form of external intervention to execute (Glaser 2017). Second, as an emergent technology blockchain-based systems still face a variety of technical limitations, such as capacity, latency, and query issues (Glaser 2017; Beck et al. 2016; Wörner et al. 2016). Third, there are some drawbacks associated with the technical structure of blockchain protocols, such as the threat of 51% attacks (Nakamoto 2008; Böhme et al. 2015), increased costs related to the deployed consensus mechanism (Brenig et al. 2016; Beck et al. 2016; O’Dwyer and Malone 2014), privacy concerns (Kosba et al. 2015; Böhme et al. 2015), and transaction risk (Böhme et al. 2015).

Transaction risk relates to the irreversibility of transactions conducted via blockchain systems. In combination with decentralized timestamping and the interconnection of blocks, the irreversibility of transactions ensures the correct order of transactions and is essential to protect users from double-spending attempts and the dissemination of corrupted data by malicious agents. The resulting data immutability enables the transacting parties to trust the correctness of the stored transactional history. In the case of erroneous transactions or fraud, the irreversible character of current protocols, such as Bitcoin or Ethereum, remains an unsolved issue and poses a prohibitive obstacle for the transaction of valuable real-world assets, such as cars and securities. All things being equal, this leads users to prefer alternative systems that offer mechanisms to undo faulty transactions or to reclaim the transacted asset by force.

Overall, we take up the notion of cryptographic transaction systems introduced by Beck et al. (2016), extend the concept to the on-chain transmission of real-world assets, and formulate the following first research question:

Research Question 1: How can we decrease the transaction risk resulting from the irreversibility of blockchain transactions and still provide a valid transaction log?

2.2 Use Case – The Life Cycle of a Car in Denmark

In the course of its product life cycle, a vehicle and its owner(s) are involved in a variety of administrative and bureaucratic processes. These processes include a variety of steps, such as a car’s registration with the motor register, the payment of levies and taxes, repairs, modifications, inspections, and interactions with loan, leasing, or insurance firms. One of the most important and complicated steps is the transfer of ownership after a trade.

With Denmark being a small country, SKAT owns and oversees most of these administrative and bureaucratic processes and provides the related governmental services. More specifically, the DMR operates an IT system that handles the bureaucratic processes involved in vehicle transfers and provides a trusted record of ownership and vehicle-specific information throughout the vehicle’s life cycle. As a result, the DMR database serves as a repository for all inputs and outputs from various stakeholders, such as owners, dealerships, importers, and scrap dealers, as well as government agencies, such as transport authorities, police departments, SKAT themselves, and other third parties, such as insurance companies, banks, or leasing firms.

The following steps and Fig. 1 illustrate a vehicles life cycle in detail and highlight the involvement of SKAT, the DMR, and other stakeholders:

  • Import and initial registration Since there are no domestic car manufacturers in Denmark, all vehicles have to be acquired from foreign producers. Imported vehicles are registered at the DMR upon arrival and the importer has to pay levies and taxes to SKAT.

  • Allocation After the registration, the vehicles are transferred to dealerships, which allocate them to their new owners. As the status of ownership changes, the new owner as well as insurance information need to be reported to SKAT and stored in the DMR. Only if all requirements are met, SKAT issues a vehicle registration certificate and grants a road approval.

  • Maintenance During its life cycle, a vehicle experiences a variety of maintenance procedures, such as automobile inspections, repairs, or rebuilds. To ensure road safety and to maintain a correct record of vehicle information, the DMR records these maintenance activities and any other modifications.

  • Transfer of ownership When a current owner wants to sell his or her vehicle and a buyer is found, the interacting parties need to settle their trade by simultaneously exchanging the vehicle and the negotiated payment amount. To minimize fraud risk, it is crucial that the DMR provides a complete and valid record on the vehicle’s history and its characteristics.

  • De- and reregistration Following the transfer of ownership, the vehicle needs to be reregistered with SKAT and the DMR. Only if a vehicle is de- and reregistered correctly, taxes and levies are paid, and the transfer of ownership is recorded at the DMR, SKAT issues a new registration certificate legitimizing the new status of ownership and granting road approval.

  • Scrapping Eventually, a vehicle is worn-out or damaged and is scrapped. As a result, the owner receives a scrapping certificate and the DMR deregisters the vehicle.

Fig. 1
figure 1

The life cycle of a car in Denmark, related process steps, and stakeholder involvement (SKAT 2016)

Full size image

Across these steps, SKAT is involved at several points and faces individual challenges at each integration point, the transfer of ownership being the most crucial one. In addition, the integration of third party services, such as financial or insurance services, and updating and maintaining the centralized DMR database requires a significant bureaucratic and organizational effort. As a result, the increasing size of the centralized DMR database leads to an increase in complexity, an increase in hardware, maintenance, and conversion costs, and a decrease in performance (Connolly and Begg 2015; Elmasri and Navathe 2015).

Research Question 2: To which extend can a blockchain-based system address the challenges of operating a registry system for cars, such as the DMR, by providing a valid, consistent, and transparent public record of transactions?

2.3 Adverse Selection in the Market for Lemons

Adverse selection describes a situation in which interacting parties attach value to the quality of a transacted object but at the same time possess different levels of information about it. One of the best-known examples for a market with adverse selection effects is Akerlof’s Market for Lemons (Akerlof 1970), where used cars of differing quality are traded between buyers and sellers.

In order to dismantle this asymmetric distribution of information, potential buyers use heuristic approaches to assess the quality of their prospective purchase and try to infer the cars’ characteristics from statistical estimators based on prior experiences, markets trading similar goods, or price signals provided by sellers (Wolinsky 1983). Despite their efforts, however, the heuristic’s accuracy decreases in bi- or multilateral market setups and the buyers’ knowledge about the true value of a car often remains opaque and a residual uncertainty about quality cannot be resolved (Genesove 1993).

As a result, equilibrium prices reflect the average quality of all cars in the market (Wilson 1980) and good and bad vehicles sell at the same price, while only sellers know their true characteristics. In this pooling equilibrium, the sellers of low-quality cars (i.e. lemons) earn informational rents equal to the difference between the market price and the cars’ true values, and thus have an incentive to enter the market. The owners of high-quality cars on the other hand would earn negative rents as their vehicles’ true values are greater than the equilibrium price, and thus withdraw form the market. Eventually, Gresham’s Law comes into effect and the lemons drive out high-quality cars (Akerlof 1970). In a continuous world, different levels of quality create a cascading effect as lower quality cars continuously drive out the marginally better ones until no demand or supply is left and the market collapses.

Reality, however, is less extreme and studies such as Bond (1982), Hendel and Lizzeri (1999), or Peterson and Schneider (2014) show that markets for used cars never shut down completely and that the traded volume remains substantial despite the presence of information asymmetries.

One explanation for these findings is the development of counteracting institutions (Akerlof 1970; Bond 1982; Genesove 1993), which aim to ensure a minimum level of quality. These institutions include the provision of guarantees, licensing and certification, or the introduction of brand names. In addition, in a long-term relationship with repeated transactions reputation-based mechanisms can function as a disciplining device (Genesove 1993).

Another explanation is the impact of efficient sorting between drivers who prefer different levels of quality (Hendel et al. 2005). However, the resulting self-selection effect only holds for non-functional parts of cars, such as a vehicle’s exterior condition, and Peterson and Schneider (2014) find evidence that adverse selection effects prevail for vital parts, such as the engine or the transmission.

As a third solution, Tirole (2012) proposes governmental interventions that aim to support sellers with the strongest legacy assets and at the same time cleans the market of its weakest assets.

The fourth and final explanation simply describes a situation, in which the buyers are able to acquire enough information to approximate the cars quality sufficiently in order to overcome the adverse selection problem (Bond 1982).

Despite their limited efficacy, all of these counteraction measures are costly, and thus might impede a market’s efficiency beyond a socially optimal level (Bond 1982). The evidence of Gavazza et al. (2014) supports this notion and indicates a negative effect of transaction costs related to information asymmetries on transaction volumes, allocation, and the welfare of lower-valuation households. Similarly, Peterson and Schneider (2014) show that adverse selection effects have a negative impact on trading volume and overall quality in the US secondary market for cars.

In consequence, we follow Pagano and Jappelli (1993), Jappelli and Pagano (2002), Djankov et al. (2007), Karapetyan and Stacescu (2014), who identify a positive impact of the disclosure of privately held information on market efficiency and trading volume, and introduce a blockchain-based transaction system, that aims to resolve adverse selection by sharing previously private information. As a distributed, publicly available, consensually agreed, and secured ledger, the blockchain facilitates the disclosure of information and impedes the provision of intentionally corrupted information. The resulting transactional database provides a valid and transparent record of each vehicles history to all market participants – the less informed buyers and the well-informed sellers likewise – improving the ability of an uninformed buyer to approximate a car’s true quality and value. From an administrative perspective, the transaction system assumes the task of tracking changes of ownership and vehicle characteristics, improving the accuracy and transparency of the database at any given point in time. Overall, we propose to utilize the blockchain as an alternative to current institutions and a novel mechanism to publicly disclose vehicle information thereby reducing adverse selection effects in the market for used cars (Lewis 2011).

Research Question 3: To which extent can a blockchain-based transaction system provide a reliable, valid, and consistent record of transactions, that reduces the impact of quality uncertainty in a lemon market?

3 Methodology: Design Science Approach

To guide the creation, evaluation, and presentation of our prototype, we utilize the design science research (DSR) approach proposed by Hevner et al. (2004) and follow their guidelines in the process of developing our blockchain-based transaction system. Table 1 summarizes the mapping of our research against the DSR guidelines of Hevner et al. (2004).

The resulting IT artifact is a proof-of-concept prototype that aims to replace a traditional registry system with a trust-free, decentralized, and automated alternative with a built-in mechanism to prevent unwanted transactions. Utilizing the blockchain’s core features, it furthermore provides a resilient, transparent, and valid database for multiple parties, such as buyers and sellers of cars, government agencies, and other third parties that reduces information asymmetries by sharing previously private information.

In order to ensure the efficacy and efficiency of our artifact, we perform a detailed requirement analysis based on the use case of the DMR and continuously reevaluate the system within each iteration of the building phase (March and Smith 1995). Overall, we contribute to existing research of blockchain-based commercial systems by extending the knowledge on the development of a blockchain-based IT artifact, offering a new approach to address inefficiencies in public sector registries (Fairfield 2015). In addition, we go beyond known concepts and propose a novel solution to adverse selection effects by transacting assets in a trust-free setup without a central authority or institution.

Table 1 Mapping of our IT artifact against the DSR guidelines of Hevner et al. (2004)
Full size table

4 A Blockchain-based Motor Register

This section presents the design and implementation of our blockchain-based motor register. Section 4.1 outlines the design decisions leading to Ethereum as the blockchain protocol of choice and Sects. 4.2 and 4.3 describe the application design and its implementation respectively.

4.1 Blockchain Design Decisions

Based on the blockchain design decisions (Xu et al. 2016, 2017) discussed in Table 2, our proof-of-concept prototype utilizes the Ethereum framework introduced by Buterin (2013) and Wood (2017) as its underlying infrastructure.

Ethereum is a decentralized application platform that provides a quasi-turing-complete programming language enabling applications based on smart contracts. Running on a blockchain-borne virtual machine (Buterin 2013; Wood 2017), these decentralized applications enable the creation of trust-free systems that establish consensual agreements among multiple interacting agents. Within this scope, Ethereum allows users to create and deploy programs on a shared global infrastructure that will be automatically triggered and executed according to the data they receive (Glaser 2017). Utilizing these capabilities, we can promote automation through transaction-triggered smart contracts minimizing bureaucratic and organizational efforts related to the administration and maintenance of databases and registries, such as the DMR.

Ethereum furthermore possess the following desirable features: first, it provides security and resiliency through the integration of cryptographic hashing algorithms. Second, due to its distributed nature, data inconsistencies are exposed to the scrutiny of all users and there is no central point of failure. In addition, the block-based and chained data structure enables users to traverse through the entire database and to retrieve past transactions and reconstruct each vehicles history (Beck et al. 2016). In theory, this transparency alleviates the adverse selection effects, while the system’s openness resolves the data inconsistency issues introduced in Sect. 2.

In total, these features establish the technological environment of our trust-free transaction system that allows parties with divergent interests and information to move value and governs the transfer of ownership by generating a complete, transparent, and secure record of transactions without a central institution.

Table 2 Blockchain protocol and application design (Xu et al. 2016, 2017)
Full size table

4.2 Software Architecture and Market Design

Fig. 2
figure 2

Class diagram marketplace and tradable

Full size image

In order to build a powerful framework that meets the requirements described in Sect. 2, we choose an object-oriented software engineering approach and structure the underlying smart contracts hierarchically. To do so, we first define a generic marketplace structure (as shown in Fig. 2) that spans a structural framework, while the implementation of the prototype inherits its core functionalities.

The generic design utilizes a two-layer approach that combines a market platform with individual goods that can be traded on this platform. Both, the platform and the traded object are represented by smart contracts, which implement different methods, functions, and variables. The marketplace contract functions as an escrow agent that organizes trading activities and defines the transaction process. The tradable contract represents the physical asset, keeps track of its current owner, and allows ownership to change after a successful trade.

To ensure the marketplace’s extensibility, we and employ a hierarchical structure with three levels as depicted in Fig. 2: the Marketplace contract defines the interface and sets the minimum requirements for methods and corresponding events to achieve the basic functionalities specified above. The StandardMarketplce implements these methods and constitutes the basic implementation of a functional marketplace. The IndexedMarketplace extends the marketplace with a set of convenience methods that allow the offers on the marketplace to be indexed as iterated through. This way, we segregate the interface, the core logic, and the convenience methods, increasing the frameworks robustness, keeping it adaptable to different use cases and scenarios, and ensuring the testability of different modules.

In addition, we allow the onTransferOwnership() method of the Tradable contract to be overridden thereby allowing logic to happen during the transaction process. This way, our market platform allows the implementation of various background checks before a car is traded and grants the possibility to abort the trade by throwing the transaction, if certain conditions, such as an adequate insurance coverage or sufficient funding, are not met or one of the transacting parties does not comply to the previously agreed terms.

To implement the DMR marketplace (Fig. 3) we utilize the general marketplace structure shown in Fig. 2. The DMR contract extends the IndexedMarketplace with the business logic relevant for the DMR, such as the ability to issue vehicles and to keep track of their ownership status afterwards. To do so, the DMR contract holds a register of the issued vehicles, their current owners, and respective license plates. The cars traded on the market are implemented by the Vehicle contract, which extends the Tradable and supplements properties required for the registration of vehicles, such as the unique Vehicle Identification Number (VIN) and other vehicle-specific details.

Instead of Ether, which is the cryptocurrency used on the Ethereum blockchain, we use a token-based representation of traditional fiat currency, such as Danish Kroner, as means of payment. This way, we are able exclude any exposure to exchange rate risk. Using Danish Kroner however requires a third party, such as a central bank, a commercial bank, or a credit card company, to back or lock the value of the amount allocated to the buyer’s blockchain account (Broadbent 2016; Raskin and Yermack 2016). The same holds for the seller when he or she wants to extract his return from the system.

Fig. 3
figure 3

Class diagram DMR

Full size image

4.3 Prototype

To develop the prototype, we use the holistic deployment framework (Truffle 2017). Truffle (2017) supports all steps of the development process including testing and deployment and takes care of boilerplate code needed to use smart contracts in Ethereum.

To facilitate accessibility, we implement the prototype as web application that can be accessed via an URI from any Ethereum enabled browser, such as Mist (2017), or by manually running a local Ethereum client while accessing the URI. Figure 4 shows a snapshot of the web application short before the completion of a transaction. To improve privacy and increase usability, we provide user-specific interfaces to different parties interacting with the system, namely buyers and sellers, government agencies, and third parties. From a practical perspective, we implement the interfaces as three different views in the web application: A car registration view, a register lookup, and a personal view, from which owned cars can be retrieved, offered, and traded.

Fig. 4
figure 4

Snapshot of the prototype’s user interface after the acceptance and before the completion of a transaction

Full size image

To mitigate transaction risk, we divide the transaction process into the following four steps and implement two built-in safeguard mechanisms:

In the first step, we match buyers and sellers and they negotiate the terms of their trade. To reduce complexity and increase system performance, buyer-seller matching and pricing is not implemented in the prototype. Instead, buyers and sellers have to find each other and negotiate terms off-chain in the real world.

In the second step, after they successfully reached an agreement, the seller can reach out to the buyer through the marketplace contract and provide an on-chain offer to sell the car by calling extendOffer(). To do so, he or she logs into the DMR blockchain system via the web-interface and sends an offer (extendOffer()) to the potential buyer by specifying the buyer’s address, i.e. his public key, and the price. The public key is a hash representing the buyer’s unique address or account number on the blockchain. In a real-world setup, public keys would be connected to a personal or corporate ID, enabling human individuals as well as corporate entities to buy and sell cars. After the seller has initiated the offer, the buyer has the possibility to either accept it by calling acceptOffer() or to do nothing, i.e. do not accept the offer. In the case of acceptance, the buyer enters into an escrow agreement and acceptOffer() checks whether he or she has a sufficient amount of funds, withdraws the agreed price from his or her account, deposits it within the market, and notifies the seller about the acceptance of the offer. In the second case, the seller can revoke the offer via the revokeOffer() method. This is the first safeguard to prevent the provision of offers that differ from the previous off-chain agreement.

In the third step, the transacting parties meet in person and exchange the physical good off-chain. The actual transfer of ownership however, has not taken place, yet. To conduct this transfer, buyer and seller have to go back onto the blockchain to complete the transaction by calling completeTransaction(), releasing the previously deposited funds to the seller while transferring the ownership of the asset. More specifically, completeTransaction() simultaneously deposits the money to the seller’s account and transfers the certificate of ownership to the buyer. In line with this process, the vehicle is automatically deregistered and reregistered with the DMR.

If any problem occurs during the physical meeting, for instance if the car does not possess the previously advertised qualities, abortTransaction() aborts the transaction, reimburses the money to the buyer, and cancels the trade. This is the second safeguard mechanism and within this fourth and final step, each party has the means to cancel the transaction and withdraw from the agreement by calling revokeOffer() and abortTransaction() respectively. Aborting or revoking the transaction will remove the offer, transfer the funds deposited in the market back to the buyer, and stop the transfer of ownership. It is important to note, that the actual transfer of ownership of the asset and the payment comprise the final step of the two-legged transaction process and eventually settle the transaction. In both cases, the offer is deleted afterwards. As a result, both parties have the chance to abort an unwanted, unintentional, or erroneous transaction by using the transaction safeguards in the steps two and four (research question 1).

To illustrate the transaction process in greater detail, Figs. 5 and 6 depict the sequence of calls for a successful transaction and the different system states during the transaction process respectively.

Eventually, the transaction data is immutably stored on the blockchain and publicly visible enforcing transparency (research question 3) and at the same time providing a complete and consistent record of ownership to the transacting parties, as well as SKAT and other relevant stakeholders (research question 2). In combination with the inherited transparency of the blockchain, our market design allows for a full view of issued vehicles, their current owners, as well as their history, and thus facilitates the reduction of information asymmetries in used car markets.

A full version of the implemented prototype is available on GitHub (https://github.com/cholewa1992/marketplace).

Fig. 5
figure 5

Sequence diagram for a valid transaction

Full size image
Fig. 6
figure 6

State diagram for offers on the market

Full size image

5 Evaluation

The proof-of-concept prototype introduced in Sect. 4 enables an automated and secure registration and transaction process. The system is running on Ethereum and allows users to invoke the DMR contracts to register (issue) and trade vehicles securely at the DMR marketplace with any other registered and authorized user. In total, we provide a solution to all three research question posed in Sect. 2 and the use case of the DMR highlights the quality, functionality, completeness, and effectiveness of our IT artifact. Furthermore, the generalized software architecture and the market framework introduced in Sect. 4.2 ensure the utility of our artifact and the provision of value beyond this specific use case. To evaluate the utility and efficacy of the prototype in greater detail, we also conduct extensive structural (White Box) and functional (Black Box) tests (Hevner et al. 2004).

In the first step, we conduct various unit tests within JavaScript using the Chai Assertion Library (http://chaijs.com/) as well as the previously introduced Truffle (2017) framework. Chai is a JavaScript library that enables the creation of unit tests and allows for both test setup and teardown before every test method. Within the structural testing, we create about 1500 lines of code and conduct 46 unit tests in order to verify the correctness of the marketplace, the tradable, and the token. More specifically, the tests are designed to evaluate whether each public method behaves as expected when called with a correct sequence of inputs (see Fig. 5 for an example of a valid sequence of calls) and to ensure that the system behaves correctly during state changes.

In the second step, the scenarios of issuing, buying, and selling cars within the use case of the DMR serve as a functional testing environment and illustrate the execution of the artifact. This way, we aim to detect any failures or potential defects in the basic marketplace, the DMR extension, and the web application. Moreover, the execution of our prototype within the testing scenarios yields average computational costs equal to 403,000 gas for a completed transaction. As a block in the our setup accumulates roughly 3,140,000 gas, our system can process up to 8 transactions per block, assuming the blockchain is only utilized for the transaction of cars. If we furthermore set the average latency (i.e. block creation time) to 30 s, our prototype can handle up to 22,439 transactions per day.

Overall, the prototype addresses the transparency and data inconsistency issues related to the second hand trading of cars and illustrates how a blockchain-based transaction system approach can help to mitigate transaction risk by introducing escrow-like smart contracts. Furthermore, it allows third-party integration through observer patterns and dismantles adverse selection effects and information asymmetries through the transparent nature of the blockchain.

6 Discussion

The IT artifact presented in Sect. 4 introduces a novel approach to administrate registers of real-world assets by converting registration certificates into unique digital assets that are managed and maintained by the blockchain. Our system allows users to register vehicles and to trade registered vehicles securely with any other authorized user. After a transaction is completed, the traded vehicle is automatically de- and reregistered with the DMR. As a result, the registry system provides a complete and correct record of each car’s transactional history to potential buyers, government agencies, and other third parties without any institutional involvement.

The cryptographic interconnection of the data blocks captures the timely order of past transactions and builds the foundation for data immutability, which is essential to ensure data integrity and the validity of the historical record. In combination with the decentralization of the consensus authority, the responsibility for the correctness of the transactional data shifts away from centralized institutions and towards the stakeholders that are most affected by asymmetrically distributed information. This way, our system works as a transparency device that assures the availability of a complete, valid, and public record of vehicle history and past ownership changes, thereby disclosing previously private information. More specifically, as blockchain transactions are public, potential buyers of cars are able to access the history of each vehicle, and thus can improve their assessment of the quality of a potential purchase. Moreover, no single participant within the system has to be trusted, because the entries are stored based on a consensual agreement and cannot be altered afterwards.

A clear limitation of this setup is the requirement of trusted third parties to provide vehicle-specific information following inspections, repairs, or modifications. This dependence reintroduces the potential of fraud and offers the providers of vehicle characteristics the opportunity to collude with current owners to provide wrong information. As a result, all actions outside of the transaction process cannot be fully secure and a residual risk of someone inserting corrupted information about a vehicle’s characteristics remains.

Although the system is not able to prevent this kind of fraud, the provision of a tamper-free historical record limits the fraudsters’ ability to spread false vehicle data. Especially, if there is a certain fraction of honest nodes present in the system, traversing through the transactional history enables potential buyers and government agencies to uncover inconsistencies resulting from frauds, such as mileage manipulation. These inconsistencies could function as a signal to the buyer that indicates a low quality vehicle. In addition, the dependence on third party information is limited to vehicle characteristics, while the record of car ownership remains unaffected, and thus still provides valuable data for the assessment of quality.

Another way to handle the issue of fraud arises in the combination of blockchain technology and the Internet of Things (Zhang and Wen 2017). In context of our use case, the Internet of Things could relieve trusted third parties from data provision duties and instead let smart cars directly report their status and changes thereof to the registry system. This way, data provision could be conducted in an automated and cryptographically secure manner (Christidis and Devetsikiotis 2016). A prerequisite for this approach however, is the technical ability of a vehicle to determine and report its current status to the blockchain.

From a user perspective, buyers, sellers, and other parties access the system via a web application and transactions are conducted by an algorithmic process specified by smart contracts. This way, inadequate usage and misunderstandings are lowered to a minimum (Beck et al. 2016), as the direction of human behavior is governed by the deployed algorithms. In addition, the web application provides user-specific views with adequate information visualizations for each stakeholder facilitating the understanding of the transactional data.

In total, these measures aim to reduce the impact of adverse selection on market efficiency by dismantling the asymmetric distribution of information between interacting parties and minimizing the buyer’s uncertainty about the characteristics of the traded object.

Besides these use case-specific considerations, blockchain technology and especially the Ethereum framework are still emergent technologies, and thus face a number of technological challenges and limitations.

One main issue of today’s blockchains is scalability. Depending on the block’s size and block creation intervals, the actual throughput – measured by the number of conducted transactions per second – is limited and the execution of a transaction can be delayed in times with high transaction loads (Gervais et al. 2016). In the context of the DMR, the focus lies on infrequent transactions of a limited number of vehicles per time interval, and thus scalability issues do not have a significant impact in this specific use case. For other use cases however, scalability issues should be taken into account. If we apply our transaction system to a larger market setup, such as the German automobile market, or a different scenario, the limited scalability, latency issues, and query delays could be a prohibitive limitation for the adoption of cryptographic transaction systems. In addition, as the distributed ledger accumulates conducted transactions it continuously grows over time, and thus occupies an increasing amount of disk space.

These constraints however, are likely to be of a transient nature and might be resolved by further improvements of current and the development of new protocols as blockchain technology matures (Glaser 2017).

Besides technical limitations, public blockchains, such as the utilized Ethereum framework, also have negative implications for data privacy. To account for these privacy concerns, we propose an on- and off-chain storage model (Xu et al. 2016; Zyskind et al. 2015) for vehicle-specific and personal information and suggest a hash-based representation of personal and corporate IDs. In addition, market participants access the database via user-specific interfaces, and thus receive different information reflecting different levels of privacy. In combination with the permissioned blockchain setup, the requirement of an authorized ID restricts unauthorized access and ensures a minimum level of data protection.

Due to its prototypical character, the absence of real-world blockchain-based systems other than Bitcoin or other cryptocurrencies, and the variety of established IT systems, it remains challenging to assess our system’s actual large-scale applicability. However, to provide a general orientation, we provide an abstract and brief distinction between centralized and distributed databases and point out the advantages of blockchain technology in the following paragraphs.

In centralized databases, data is stored at one physical location and users access the stored data through an interface. As a result, centralized databases offer easy data management and maintenance, high performance, and remain scalable. On the other hand, centralization concentrates costs for setup and maintenance on the database provider, increases the risk of outages and data losses, and requires the users to trust in the governing operator (Elmasri and Navathe 2015; Connolly and Begg 2015).

In distributed databases, the storage and processing units are kept separately, data is stored at and linked across multiple locations, and user access the database via a network. To update the nodes and to maintain the database, data needs to be replicated and duplicated across the network. Central advantages of distributed database systems are the continuous availability and increased reliability, easy data recovery, and the flexibility of modular growth. These advantages however come at the costs of a high level of complexity, an increased processing overhead, and the exposure of data integrity to inconsistencies (Elmasri and Navathe 2015; Connolly and Begg 2015).

Blockchain-based systems combine characteristics of both systems and offer a resilient distributed database that ensures data integrity by the consensual agreement of all nodes, and hence provides a reliable database for multiple parties. Especially the openness of the transactional history to the independent scrutiny the interacting parties and other involved stakeholders minimizes the risk of duplications, errors, and data inconsistencies. Building a registry system on a blockchain infrastructure leverages these key properties and meets the main requirements of modern registries, which include integrity, availability, accessibility, efficient reading, and immutability (Tran et al. 2017).

To provide an orientation beyond the use case of registries, we furthermore propose three prerequisites that arguably should be met for blockchain-based systems to potentially constitute an improvement over traditional approaches.

First, due to its distributed nature and the integrated consensus mechanism, blockchain technology provides a conceptual approach to govern transactions between multiple parties in a public and anonymous setup without the involvement of a central party. As a result, these systems possess the ability to moderate interactions between agents with conflicting interests and motivations. If the conflicting interests provide a strong intrinsic motivation to participate in the truth revelation process, we can also discard the idea of monetary incentives prevalent in cryptocurrencies.

Second, we propose to utilize the blockchain as an approach to mitigate the exposure to asymmetrically distributed information and perceive and apply it as a toolbox to facilitate the provision, validation, and dissemination of a transactional history. Consequently, interactions without at least one party with private information cannot profit from an increase in transparency, and thus the benefits of blockchain-based systems remain limited.

Third, as a distributed system blockchain technology grants multiple parties writing access to a shared database without compromising data integrity. For these benefits to take effect however, use cases need to comprise at least two conflicting parties with writing access to the system. If there is only one party with writing access, there is no need for consensus and therefore the party with the writing access simply constitutes the equivalent of a central authority.

If we map these prerequisites to the use case of the DMR, we find that all three conditions are met: first, there is a conflict of interest, which arises between buyers and sellers, as sellers do not want to reveal their private information, while buyers want to learn about the true quality of the cars on the market. In addition, the multilateral market environment and the dynamic transaction process requires all parties involved to contribute data to the system.

7 Conclusion

The proof-of-concept prototype developed in this study aims to replace bureaucratic public registries with an alternative and illustrates what a blockchain-based transaction system for real-world assets might look like. In addition, it highlights how the blockchain could function as a transparency device to mitigate inefficiencies in markets with imperfect information. From a technological perspective, we provide a platform that governs the transfer of ownership of used cars and inherently provides a reliable and complete record of vehicle history to the transacting parties, government agencies, and other third parties. To implement the prototype, we apply an object-oriented software engineering approach that facilitates understanding and allows researchers and practitioners to go beyond the use case of trading cars and adopt the transaction system to other assets, transactional market setups, and registries systems.

Except for its practical relevance, our study’s contribution to academic research is threefold: First, we introduce a mechanism to reduce transaction risk resulting from the irreversibility of blockchain-based transactions. Second, we replace a trust-based, centralized, and bureaucratic register with a trust-free and autonomous transactional database system, which provides a secure registration and transaction process without the need for a central governing authority. Third, we propose a novel solution concept to reduce the uncertainty about quality and the resulting adverse selection effects in lemon markets by providing a reliable, transparent, and complete record of each asset’s history.

To reduce complexity and to focus on the research questions at hand, we furthermore forego the integration of third party services and official processes, such as automobile inspections or permissions for rebuilds. These and other features, however, might be included in future versions as the prototype matures.

Apart from the noted benefits, the applied technology is still at an early development stage and faces some challenges, such as limited scalability and privacy concerns that are not yet fully mastered. Also, users need to trust the correctness and accuracy of the operating algorithms (Lustig and Nardi 2015) and the provision of information about the asset by trusted third parties is still an important prerequisite. This provision however is limited to the update of vehicle-specific information following inspections, repairs, modifications, or accidents. The transaction process is conducted fully on-chain, and thus generating the transactional history does not require any third party integration. In part, this trust problem might be solved – at least in the case of cars – by the integration of the Internet of Things, where sensors provide the required data (Gubbi et al. 2013).

Irrespective of those concerns, our prototype provides a valid first step to apply blockchain technology to the field of public registries and transaction systems and illustrates the opportunities and challenges of this approach.