Proof of Delivery Smart Contract for Performance Measurements

The growth of the enterprise blockchain research supporting supply chain management calls for investigations of their impact and mindfulness of their design, use cases, and pilots. With a blockchain design for the Proof of Delivery (PoD) process management, this paper contributes to learning about performance measurement and the transaction costs implications during the development and application of smart contracts. An experimental design science approach is applied to develop an open-source blockchain to explore ways to make the delivery processes more efficient, the proof of delivery more reliable, and the performance measurements more accurate. The theory of Transaction Costs is applied to evaluate the cost implications of the adoption of smart contracts in the management of the PoD. The findings show that smart contracts make the delivery processes more efficient and proof of delivery more reliable. Yet, the methods and metrics are too complex and qualitative, limiting the smart contract’s capability to measure performance. Our findings indicate potential transaction costs reduction by implementing a blockchain-based performance measurement. The complexities of the delivery process and proof of delivery call for pre-contractual steps to identify the processes and performance metrics to design blockchains. Smart contracts need further development and digital aids to handle qualitative inspections and proof of delivery generation during the delivery process. The blockchain requires the system’s capacity to record off-chain transactions, such as in case of disputes resolutions. The authors extended blockchain research beyond the theoretical level, designing an open-source blockchain for supply chain management within the use case, pilot design, and case study.


I. INTRODUCTION
P Roof of delivery (PoD) is one of the essential elements for supply chain (SC) and logistics because of its legal, operational, financial, price, disputes, and other implications. A PoD certificate acknowledges the delivery of assets and documentation on time, place, quantity, quality, and completion as agreed by the parties. It can trigger the transfer of ownership of assets, the operational takeover of custody, financial payoffs for assets and their delivery services, acceptance or correction of the prices according to the delivery conditions (e.g., damaged goods, packaging, late delivery), or non-repudiation of the delivery conditions in case of disputes between the seller and the buyer [1], [2]. Current drawbacks of the PoD include the lengthy verification of compliance with the delivery terms. Manual verification processes may take around 37 minutes per delivery, or up to 190 minutes per day in the Fast-Moving Consumer Goods sector [3]. Manual PoD systems are complex and slow down the operations [4], render operations data unreliable and inaccurate, and limit collaborative decision-making processes between SC and logistics actors [5].
The delivery and PoD problem is not new. It is steadily growing due to the mass customization paradigm in supply chain and logistics [6], e-commerce, and omnichannel realtime information and visibility requirements [7]. Potential buyers select Logistics Service Providers that better perform the delivery [8]; in other words, those with better Delivery 'On-Time, in Full' (OTIF) performance are more likely to survive. For instance, it was estimated that global electronics providers were late 99.7% of the time, concerning the requested delivery time [9], and COVID-19 exacerbated the problem [10].
Data inaccuracy or unreliable delivery performance increase operational costs and inventory holding costs and deteriorates customer relationships [11], [12]. This may lead to reshaping supply chains and increasing the costs of search, negotiation, and administrative controls with new clients and LSPs, increasing overall transaction costs [13]. Auto-identification technologies like hand-held or mobile devices, automatic identification systems, Internet of Things (IoT) devices, etc., facilitate the process, verification and performance of delivery [1], [14]. However, auto-identification technologies can be tampered, and electronic data erroneously registered, for instance, to counterfeiting goods in the SC [15], hiding shrinkage [16], for fraudulent consumer behaviour [17], or due to unintentional errors [18].
While logistics 4.0 addresses some delivery and PoD prob-lems with real-time tracking, tracing, monitoring, and notifications for fleet management [19], it tends to rely on centralized infrastructures, increasing end-to-end SC risks of information technology cyberattacks, data integrity loss, lack of transparency, auditability, and mistrust in current systems [20]- [22]. Given the emergence of the blockchain, distributed ledger technologies (DLTs), and smart contracts as potential solutions for such issues [23], the aim of this article if threefold. First, to examine the case study of an open-source supply chain delivery performance smart contract designed with an Italian food industry company. The food supply chain is chosen because it has been reported in the literature that criticality to measure performance in terms of delivery time, conditions, as freshness is not only a matter of quality, but also of safety as for instance good performance measurements allows to precisely determine the food's precise shelf-life [24]- [26]. Second, to show its applicability, functionality, and potential implications in terms of overall transaction costs. And third to explore the implications for the management of the logistics process related to the PoD of the adoption of BC/BDLT, using the lens of the Transaction Cost Theory [13]. Specifically, it tries to answer how use BC/DLT to measure the performance metrics related to the PoD? What transaction costs are implied with the Blockchain/DLT for PoD?
To answer the above questions, the rest of the article is structured as follows. Section II presents the literature considering how DLTs support key SC processes and operations, specifically the delivery of physical goods. Section III discusses the case study and design science methodology used in this investigation. Section III-B describes the case study. Section IV is devoted to the DLT architecture. Section V discusses our research, results, managerial and strategic implications. And section VI, concludes with the novelty of our results and future research directions.

A. DISTRIBUTED LEDGER TECHNOLOGIES FOR SUPPLY CHAIN AND LOGISTICS MANAGEMENT
The relevance of distributed ledger technologies, blockchains, and smart contracts (DLTs) for SCs is increasingly discussed in the literature. Treiblmaier [13] discusses at a theoretical level how firms can use them to better structure or manage contracts, govern SCs, develop competencies, and set relationships. Chang et al. [27] showed at the operational level how supply chains could deploy DLTs to monitor and control business processes more efficiently. Hooper and Holtbrugge [28] discussed their strategic use to safeguard property rights, internalize externalities, transaction costs reduction, monopolistic powers prevention, and better distribute social welfare throughout international supply chains. Nandi et al. [29] show that SC adoption might be focused on improving operational performance through information sharing and coordination rather than on better strategic orientation based on a review of 126 cases. Thus, there is no doubt about the theoretical, operational, and strategic relevance of DLTs, compared to when blockchains were thought to be fit only for banking or financial transactions because those would not require physical movement of goods [30].
On the other hand, as Xu et al. [31] and Hald and Kinra [32] argue, not all is sweet with DLTs. There are potential negative impacts on supply chain's performance, for example, loss of privacy, transparency, exertion of power and surveillance, potential negative technological path-dependencies created by the designer and owner of the technologies, SC segregation, loss of trust, SC rigidity, reduced organizational and labor competencies, etc. [31], [32]. Nevertheless, innovations inevitably shift previous coordination mechanisms, systems and relationships, cooperation and competition among stakeholders, complementarities and strategies, networks and interactions, and users and value streams [33], [34].
Although the SC community has studied good, bad, and ugly sides of DLTs, further examinations of the implications for the delivery process, PoD, and their transaction costs are still pending.
While the delivery process of goods or components from source to customers is key for supply chain management [35], supply chain scholars have not yet analyzed how such a key process might be affected using DLTs. Conversely, computer science scholars have started analyzing it, judging by the 11 Scopus and 8 Web of Science publications retrieved from a keyword search for 'Proof of Delivery' and 'Blockchain' from 2018 to 2020. Thus, the authors believe that SC scholars might have a greenfield to contribute in this area in collaboration with computer scientists.

B. DISTRIBUTED LEDGER TECHNOLOGIES FOR PROOF OF DELIVERY
A successful delivery implies quality, accuracy, and integrity of sourced goods [36], in the correct place and time [37]. Verifying whether delivery is successful is time-consuming because it entails inspecting goods, transportation, and documents and producing the PoD. This process may be manual, semi-manual (Barcode), or with auto-ID systems, i.e. RFID or IoT [38], [39]. After the PoD confirms the match between order specifications and delivery conditions, suppliers may invoice buyers, and LSPs may invoice suppliers [3], [3], [40].
There are many advantages of digitalizing the delivery process [41], [42], but DLTs have been said to make the process even more transparent and less disputed. For instance, Hasan & Salah [21], and Rohan et al. [43] proposed sets of electronic keys be handed over to the transporter and buyer. Once all participating entities sign to confirm that the terms and conditions set in a smart contract have been fulfilled, suppliers can withdraw the collateral deposits and submit payoffs. In case of disputes, the resolution goes to an arbitrator. Caro et al. [20] proposed a traceability-based system, AgriBlockIoT, with IoT sensors whose data is retrieved by a smart contract to create transparent, fault-tolerant, and auditable records of the whereabouts of goods and assets at a given time. The architecture was tested on Ethereum and Hyperledger Sawtooth, concluding that Ethereum performed better. The problem is that visibility of goods' location does not necessarily translate to acceptance (i.e. PoD) of the goods by the receiving personnel.
Given that the PoD requires managing the logistical operations and relationships between SC parties, a single, smart contract dealing with both aspects might be too complex to handle [44]. Chauhan et al. [44] proposed a permissionless blockchain architecture based on Ethereum Quarkchain with a smart contract for operations transactions to secure the participants' interactions. The computer science community contributes to the SCM community by developing new systems, improving network performance, and making information more accessible, accurate, and non-contestable. The question is whether smart contracts used in the delivery process are legally binding for SC managers or whether they are considered just a piece of code in a programming language.

C. SMART CONTRACT AND SUPPLY CHAIN DELIVERY PERFORMANCE
Smart contracts can be considered 'protocols deployed to execute computerized transactions when predefined conditions in a contract are met' triggered with specific business logic either in blockchains, distributed ledgers, or as stand-alone computer programs [45]. The first implementations of smart contracts were in the financial services long before the development of blockchains [46], but they can also be used to measure delivery performance [47]. The delivery performance (mainly On-Time, In-Full) is one of the most important key performance indicators (KPI) in SCM and logistics operations. It centers on customer satisfaction. Gunasekaran et al. [48] argue that while the price is a supplier qualifying factor, the history of delivery reliability secures them a contract. There are four key performance indicators for the delivery process: orders delivered on time, in full, in perfect condition, and with accurate documentation [49]. Bushuev [50], Das Roy and Sarker [51] took the case of low on-time delivery performance and justified penalties due to early deliveries increasing inventory holding costs of clients, late deliveries contributing to production stoppage, lost sales, and goodwill loss. DLTs promise to optimize SC and logistics operations and to be legally binding with the use of smart contracts. For instance, Zhao et al. [52] and Rohan et al. [43] showed that DLTs could make the delivery process and PoD more reliable with IoT systems (i.e., RFIDs). Demir et al. [53] argued that theoretically, delivery performance can be assured with its record of cancellation, complete, and returned status stored in the blockchain. Meng & Qian [47] decompose the delivery metrics 'On-Time In-Full' (OTIF) to generate blockchain-based real-time business intelligence with historical logistics operations performance data [47].

D. THE LEGAL STATUS OF SMART CONTRACTS FOR SUPPLY CHAIN AND LOGISTICS MANAGEMENT
Whether legally binding SC and logistics agreements can be hosted in smart contracts or chaincodes of a programming language seems to be ongoing. Giancaspro [54] warns that the uncertainty of smart contracts hampers the legal status and renders them unenforceable. For instance, coding errors may lead to costs miscalculation and escalation, losses, disputes, and liabilities; or parties may not be aware that their deployment implies a contractual agreement. Nguyen et al. [55] included chaincode's misunderstanding, fraudulence, exploitation, negative impacts on externally connected information systems, execution failures, and frequent need for patches, which can affect the enforceability, and supplier-client relationships.
On the other hand, smart contracts have been around for a long time, automating transactions, especially in the financial sphere, before the blockchain became popular. They have been tested and validated; they undergo semantic analyses. There is a clearly defined context of deployment. They are unambiguous, and there is no need to cover the full extent of a legal agreement. Still, only parts of it [56]. Six et al., [57] proposed the 'Request for Information (or 'Request for Project') process to be the SC or logistics contractual context where parties can agree on how to implement smart contracts and which parts of it to be legally binding. This implies that Blockchain/DLTs with smart contracts can be used to measure, manage, and govern supply chains and logistics relationships.

E. THE TRANSACTION COSTS OF IMPLEMENTING DLTS FOR PROOF OF DELIVERY
The transaction costs of managing supply chain and logistics relationships with Blockchain/DLTs ought to be assessed [13]. Based on a comprehensive literature review and multiple case studies, Roeck et al. [58] identified that the implementation of the blockchain can reduce a series of transaction costs, namely: assisting managers with their limited capacity to identify operational errors; reducing opportunistic behavior; reducing the costs of partners' performance evaluation; reducing the costs of selecting or switching partners; reducing costs of monitoring and enforcing penalties; reducing the costs of rebalancing asymmetric information; optimizing operational processes; reducing costs of contractual arrangements throughout increased bargaining power. The blockchain capabilities that showed to reduce costs in Roeck et al.'s [58] multiple case studies were transparency, trust, and disintermediation.
Similarly, Dutta et al. [59] and Li et al. [60] showed that blockchain contract automation offers more security and lowers transaction costs with faster execution time compared to traditional contracts. Further, Cole et al., [4] suggested that Blockchain/DLTs can reduce the need for intermediaries, making supply chains more agile and transparent; and, in turn, reducing the risk of opportunistic behavior in the supply chain [61]. Schmidt & Wagner [62] argue that performance measurement is more certain with the blockchain because there is less external environmental uncertainty with the elimination of intermediaries.
An important consideration raised by Treiblmaier [13] is to assess the partners switching costs when reshaping supply chains or the increased risk of power imbalances shifting with the concentration of supply chain partners with fewer intermediaries. In this line, a survey of Indian and North American firms found a reduction in overall transaction costs by increasing supply chain transparency and performance with blockchain/DLTs [63].
Another comprehensive empirical investigation by Roeck et al. [58] based on multiple case studies of the impact of Blockchain/DLTs implementations on transaction costs showed that they could decrease or increase. Reductions may be enabled by the following: 1) assisting managers with their limited capacity to identify operational errors, 2) reduces opportunistic behavior and enhances trust in the network thanks to an increase in transparency, 3) easy of evaluating partners' performance, 4) easy of search of partners, 5) automating monitoring and enforcement.
In sum, whether transaction costs will be reduced is a question that needs to be answered empirically. One of Roeck et al.'s [58] multiple case studies consisted of provenance assurance in the food industry. In the present article, a single case study, also in the food industry, is analyzed; but with a different use case, i.e., the blockchain/DLT for PoD. The aim is to verify Roeck et al.'s [58] transaction costs approach, using similar theoretical constructs for the same industry but with a different use case, and unveil the reasons underpinning the potential increase or decrease of transaction costs.
While the literature has focused on a single player in the supply chain, we want to investigate the transaction costs related to the PoD embracing the views of two participants, i.e., buyer and seller; with a full development cycle for their interaction with smart contracts to ease the delivery process, PoD, and SC delivery's performance measurements.
For this article, computer science and SC scholars pursued an explorative design science approach [72]- [74] to develop an SCM-relevant DLT. The approach has four phases: problem identification, proposed solution, evaluation, and contribution to solving the problem. The design science methodology has been successfully used in the development of DLT enabled SCs, such as in the construction industry [75], commercial real estate [76], industry 4.0 applications [77], semiconductor industry [78], and so on.
To avoid running the risk issued by Wang et al. [75] about the tendency to centralize decision-making in the DLTs development process, which leads to unfair governance of DLT networks. Our design process was shared and iterated, reflecting the DLTs capabilities from the computer scientists' point of view and the expected value-added from the SC and logistics scientist and practitioners' point of view.
The DLT followed Hevner et al.'s [72] Generate/Test cycle framework: 1) Developing an architecture concept for SCM based on Hyperledger Fabric, 2) Presenting the concept to an advisory board composed of companies, SC, DLT, and information engineering professionals, exploring alternatives upon constraints indicated by the advisory board, 3) Redefining the research problem to focus on the delivery processes and PoD problems, 4) Proposing alternative architectures, including Ethereum, to increase flexibility and general capabilities for the SCM objectives. The advisory board agreed on the suitability of the new architecture, highlighting the need to measure the performance of the delivery and PoD processes. This process took three cycles from generation to final validation by the company.
The following section describes Ponti's case study, with which the research problem was identified, the solution validated, and the transaction costs estimated.

B. THE CASE STUDY OF PONTI 1) Company background, and problem description
The Blockchain/DLT was conceptualized based on a problem identified by Ponti, a medium-size Italian company that produces specialty vinegar, conserves, and other food items.
The key markets are Italy, France, and United States, with its international revenues accounting for 13% of its total. The company's distribution network consists of 3 Italian Distribution Centres (DC) and two national transit points to cover the Italian territory. With the expansion, the complexity of the logistical operations increased together with the fragmentation of flows and capacity to manage relationships due to: 1) Increasing presence in marketplaces, with increasing frequency of smaller orders; 2) Increased demand for larger sizes of individual items; VOLUME 4, 2022 3) Increasing demand from discount market channels.

2) Supply chain, delivery, and performance
The company's SC consists of producers delivering raw/fresh food to Ponti's food manufacturing plant; manufacturing and shipping to its clients' distribution centers. They are then delivered to the retail outlets. Both inbound and outbound delivery processes are complete after arrival within the allotted time by the receiving client's warehouse, further unloading goods, verification of quantity, state of the cargo, the origin of the shipment, and producing a PoD. Typically, the warehousing is managed by the company, and the distribution services are outsourced, which leads to establishing the current and expected future service levels and non-compliance penalties in the LSPs contractual agreement (i.e., Service Level Agreement).
The increasing diversification and geographical distribution had led the company to use express delivery services more often with the risk of delivery fragmentation, lengthy cargo inspection times, increased acceptance with reserves, deferred cargo inspections due to logistical practices of new clients delaying the PoD, increased returns, and unclear documentation and writing manual PoD certificates, and the corresponding late delivery penalties, reconciliation costs, and collaterals, etc.
At times, the receiving warehouse personnel transmits inaccurate information regarding the delivery time slot allocation, resulting in delivery delays, penalty costs for late delivery, and increasing friction and potential disputes between the manufacturer and distributors. Given that the distribution is outsourced, the company cannot monitor this delivery process.
The described context constitutes a very interesting case to be analysed and explored to develop a Blockchain/DLT to address the need to access more reliable data generated in the delivery process between shippers, LSPs, and clients' receiving warehouses.
The following subsections provide further details about the DLTs solution from a theoretical and technological perspective.

A. DELIVERY PROCESS AND POD WORKFLOW
A Buyer submits a pre-contractual agreement to the Seller and, upon verification by the Seller of available stock, production capacity, fleet, and delivery capacity confirms the contract. The contract has starting at time T s and end time T e . The Seller must deliver order quantities in the range [Q m , Q M ] during a time interval [T s , T e ] to the specified warehouse location, with a minimum success rate r. During the term of the contract, the Buyer creates order delivery of tasks containing order parameters, estimated time of arrival (ETA), i.e., t eta > τ + T p , where τ is the task creation time, T p is the contract parameter for the minimal allowed gap between task creation and emission of an ETA t eta .
Following Fotouhi et al. 's [79] operational model, the Seller can accept or reject order delivery tasks submitted by the Buyer within a specific time. If accepted, Seller organizes the order delivery task. On delivery, Seller and Buyer create a transaction with the order delivery parameters, the actual delivery time, and whether the goods comply with the quality. If the delivery time is within the range of the ETA [t eta − ∆t eta , t eta + ∆t eta ] and if the order quantity and quality are adequate, the delivery is successful. If both the Seller and the Buyer signals are successful, the delivery is successful. If both signals are unsuccessful, the delivery has failed. However, if they have different views on the quality of the delivery, a dispute is opened.
The empirical success rater is in the interval [s/Q · 100%, (s+d)/Q·100%]. Q = s+f +d, where s, f , d and Q are the number of successful, failed, disputable and total deliveries correspondingly. Only disputable deliveries can change their status over time. Furthermore, the change can be a successful or failed type. So, the interval can only shrink. The Seller can get a bounty payout once s/ The workflows for the performance contract and single order delivery tasks are as follows. Single order quantities are constrained in size by production capacity, availability of supplies for production, capacity of LSPs performing the physical distribution. Thus, an economic order quantity as described by Utama et al. [80] and Combe [81] is negotiated during the pre-contractual agreement. The algorithm of the delivery performance contract is as follows (Figure 1): 1) The algorithm starts.
2) Buyer defines Seller as a seller, defines the agreed contract parameters • T s and T e time for contract start and end. This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication.

7) Buyer sets wanted delivery parameters
• the estimated time of arrival t eta • the string detailsString delivery task details regarding the order, logistics, SC specifications, correct documentation, etc. Note. We considered it a predefined string for the current paper and was not processed in the smart contract. It is assumed that a delivery task details contains observations, reservations, etc. Upon accepted of the delivery, a PoD can be produced, regardless of observations or reservations.

8) If
• it is not too late to process the order where τ is the current time • orders are available in the wanted time slot Q ⌈ τ+teta−Ts ∆T ⌉ < Q ∆ • the maximum number of orders is not reached Q < Q M then the parameters are valid and go to Step 9, otherwise, return to Step 6. 9) Increase the number of proposed orders Q, the number of deliveries without a final decision d , and the number of VOLUME 4, 2022 7 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. ⌉ by 1. If Q equals Q M , then set f lagContinue = F alse. Both start the single delivery processing (Step 10). 10) Process the single delivery order. All the deliveries are processed independently and in a parallel manner (denoted with black parallel lines in Flowchart 1-a). 11) If the result of the delivery is "success," then increment s by 1, otherwise increment f by 1. Decrease d by 1. Move to Step 6. 12) If f lagContinue = T rue and f lagDesicion = F alse and either 100·s/Q > r-guaranteed high success rateor r/100 + f /Q > 100-guaranteed low success rate, then set f lagDesicion = T rue and go to Step 13. If 100 · · · s/Q > r, the contract result is "success" and go to Step 14. Else if r/100 + f /Q > 100, then the contract result is "f ail" and go to Step 15. 13) Seller has shown high performance: success. The execution terminates. 14) Seller has shown low performance: f ail. The execution terminates. 15) After T a set f lagSign = F alse as Seller has not signed the contract on time. Go to Step 4. 16) At the time T e set f lagContinue = F alse and go to Step 12. Building upon Sarac et al. [82] and Chen et al. [83], the following algorithm to process a single order delivery controls two main criteria, the deviation from the maximum waiting time for the delivery truck (i.e., Estimated Time of Arrival or delivery time), and the deviations from the quality of the cargo (i.e., order quantity, the origin of the cargo, the destination of the cargo, and condition of the goods and packaging) ( Figure  2): 1) The algorithm starts.

2) Set
• acceptable deviation from ETA equal to ∆t eta = α · t eta . • the flag if the final decision has been made f lagDecision = F alse. Move to Step 3 and Step 17. 3) If the Seller sends the "agree" transaction, then process the delivery at Step 4. If Seller sends the "reject" transaction, then the delivery has failed, and the execution is terminated at Step 5.
Note. The on-time notification that Seller will not complete delivery is a better event than failing the delivery once accepted. However, we do not distinguish between these situations.

4) Set
• the number of users who provided the delivery log a = 0 • the number of "success" answers between Seller and Buyer b = 0 and start a parallel answer collection for Seller and Buyer at Steps 6 and 7. 5) Set f lagDesicion = T rue.Terminate the algorithm.
The result is "f ail." -1 6-7) A party provides delivery log as a pair t d , f lagCargoOk, where t d is the time of delivery and f lagCargoOk is a flag for the quantity and quality of the cargo, i.e. T rue if the cargo is ok on delivery and F alse if it is not ok.

B. SYSTEM ARCHITECTURE
The system functions as one smart contract deployed on the network. The smart contract contains the information of the agreements between the entities, i.e., Seller and Buyer. This information can be hard-coded, or an instance of the smart contract can be deployed, bypassing the required number of parameters specific to the use case. Current functionality dictates that for each agreement, a new smart contract is deployed, and the contract's parameters cannot be modified, e.g., if the duration of the contract is written, it cannot be extended or reduced. 8 VOLUME 4, 2022 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Agreements are made between the entities off-chain, and the information is added to the smart contract, for example, start date, end date, number of deliveries, etc. The smart contract is deployed on the network from the Buyer's address with a time frame for the Seller to agree. The Seller should agree upon the deployed smart contract's agreement such that no different information is added other than the off-chain agreement. The Seller should either accept or reject the on-chain smart contract agreement during this time frame. On acceptance, the smart contract functions as per algorithm, else the smart contract is annulled, and no functions can transact on-chain. In the latter case, a new smart contract should be deployed, and the Seller should agree to it. Only then, the smart contract can be executed. Upon finalization of the transactions, the smart contract expires, and further orders and deliveries require the deployment of new smart contracts. Even after smart contracts expire, historical data registered can be accessed, as DLTs can intentionally be made irreversible accessible, as described in Miloslavskaya [84], Mehendale et al. [85], and Wouda and Opdenakker [76]. The smart contract, TradingAgreement, is deployed, and it contains three types of data structure that stores the following information: 1) orderBookConsignment: orderBook records the information based on orders by the buyer, function orderConsignment is called to make order requests to the seller. The orderBook contains the following fields: a) consignmentNumber: serial number for consignment's order. If the order exceeds the maximum allowed orders, the system throws an error. VOLUME 4, 2022 9 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3185634 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ b) timeSlotOfOrder: the slot interval, when the order was made, the system enables the Buyer either to order consignment weekly or all at once, with different ETAs c) timeOfOrder: the time when the Buyer made the order. d) consignmentSender: stores the address of the Seller. e) ETA for each consignment order ETA is specified. f) DeliveryReviewed: set to false and changes to true when the consignment is delivered. 2) receivingConsignmentBook: deliveryConsignmentInformation records the delivery information of the order. The function receiverConsignement is called by the Buyer to update the information of the corresponding order. The deliveryConsignmentInformation contains the following fields: a) consignmentnumber: Serial number of the consignment delivery, the same as the consignment order. b) consignmentOrderTime: Written from the order-Book, which stores consignment's ordering time. c) consignmnetShippingTime: For each consignment order, the data field specified the time of consignment shipping. d) ETAasPerOrder: ETA of the consignment that was recorded while ordering. e) BuyerATA: Buyer, while receiving, mentions the actual delivery time. f) SellerATA: Seller, while receiving, mentions the actual delivery time. g) consignmentSender: Address of the Seller h) DeliveryStatus: Based on consignment's ETA, Buyer's ATA, and Seller's ATA, one of the following conditions are possible: • NONE: Initial condition for all consignments before the delivery. • SUCCESS: If the Seller and Buyer agree on the ETA within specific the range corresponding to the ETA. • FAIL: The delivery can fail on two conditions: i) The Buyer rejects the consignment on delivery for some reason, for example, if tampered consignment. ii) The Seller and Buyer do not agree on ATAs, or the ATA is out of range of the ETA.
• DISPUTE: If one entity claims delivery on time and the other does not, then, in that case, a dispute arises. All disputes should be addressed and rectified, and the decision for that specific consignment should either be successful or fail.
All delivered consignments have an ETA when ordered and ATA when delivered. Based on these two parameters, a consignment decision is changed status to success, fail or dispute. i) flagDecision: Only for success or failure of the consignment's delivery a flag is marked.
3) multiSigBook: A contract cannot be completed or concluded if there are raised disputes of consignment. To conclude the contract, all the disputed consignments should be resolved. For this, the entities can off-chain agree to a specific ATA, not necessarily within the range of ETA. Based on the decided ATA, a consignment is marked success or fail, resolving the dispute. After agreeing to a specific ATA, both entities sign transactions agreeing on the ATA, and only then is it marked as resolved.

C. PONTI'S DLT'S TRANSACTION COSTS ESTIMATES
Based on the developmental process of the DLT architecture and multiple in-depth interviews with the Ponti's chief supply chain officer, the adoption of the DLT and its potential transaction costs estimates were assessed. An important use of the KPIs derived from implementing the DLT is the better and more reliable selection of future LSPs. However, the company states that it would require comparable performance information across qualifying LSPs for a complete assessment. Such data can be on-chain or off-chain, albeit the former traceable and certifiable. The asymmetric or lack of performance information about LSP implies higher costs for the company to evaluate, yet it is not a disqualifying factor for future contractual arrangements. Thus, it is not the selection of the LSPs that are at stake, but the reduction of costs of selecting LSPs. The DLT for performance measurement needs to be perceived as an industry standard to justify to the company its enforcement among its supply chain and logistics partners. Another important implication is the reduced cost of transparency and visibility of their operations and those of their LSPs. The company states that the DLT allows them to hold objective and certifiable data, reducing the likelihood of disagreements with their partners and clients, automatically enforcing penalties to their LSPs, and processing credit notes in real-time for their clients when 10 VOLUME 4, 2022 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3185634 deliveries fail the "OTIF" standards. The company's relatively high bargaining power with its suppliers and relatively low with its clients is not expected to change substantially, as the DLT for performance measurement and PoD is not expected to change the market power. The company requires their top clients to agree to adopt the DLT to adapt it themselves and enforce it on their supply chain partners. The company was asked to assess to what extent each one of the DLT capabilities was expected to have a reduction in their supply chain transaction costs. The objective was to answer the research question and compare the company estimates with the food industry case study reported by Roeck et al. [58].
The company stated that the three DLT capabilities (i.e., transparency, trust, disintermediation) could reduce the costs of monitoring LSPs' performance and automate the monitoring and enforcement of penalties (e.g., automatic credit-notes generation). Transparency is the main mechanism for reducing transaction costs for the company. While disintermediation might be the second most important mechanism to reduce transaction costs, the company would rather reduce transaction costs by building trust along the supply chain than by disintermediating.

V. DISCUSSION OF FINDINGS
A prototype of DLT to monitor the performance of an agreement is implemented and executed on randomly generated data of arbitrary order size. ETA and ATA for each delivery are measured and recorded on the blockchain. The sender and receiver have the privilege to 'propose' and 'accept' the ETA for a specific order. The smart contract is programmed to conclude the outcome of a consignment delivery based on three parameters, i.e., expected ETA, sender's ATA claim, and receiver's ATA claim. Based on these parameters, the contract's overall performance is determined by calling the function in the smart contract that measures the performance only after executing all orders, especially evaluating proof-of-delivery for all consignments for a specific order. The code is available on GitHub [86].
The DLTs development shows that an SC pre-contractual agreement requires a negotiation process to define protocols and conditions for business processes to align with all SC partners. Thus, our findings support Six et al. [57] and Azzopardi et al.'s [87] recommendations to set up pre-contractual negotiation processes during a Request for Project process.
This DLT solution allowed programming and compiling into chaincode agreed business protocols. The chaincode is then deployed to Ethereum's contract address, which stores chaincodes and executes functionalities when external accounts send instructions in the form of transactions, i.e., instructions to initiate transaction processes on the blockchain. The implementation of smart contracts does not make written contracts obsolete. Written contracts can also be stored on the blockchain using InterPlanetary File System (IPFS) to share data in a distributed manner. Moreover, although chaincodes and written contracts are not entirely interchangeable, the former can, at least, contain parts of a written contract in the form of logical operations.
While supply chain delivery performance can be measured periodically or in real-time, as Meng and Qian [47] proposed our DLT dealt with multiple other complexities (i.e. managing multiple order placements, with multiple order sizes, varying delivery time ranges, etc.) that were considered more important to address. However, given that performance can be measured after the conclusion of the smart contracts, our DLT can be set to deploy smart contracts on time ranges required for performance measurements, i.e., monthly, quarterly, yearly, etc.
Our DLT may contribute to the structure and manage SC contractual agreements and relationships. Treiblmaier [13] predicted that DLT could change SC relationships. In our case, in a real-world operational setting, we would expect SC relationships to strengthen depending on the delivery performance. As expected by Chang et al. [27], improving SC performance monitoring with DLTs may drive operational certainty with less conflicting data between LSPs and the receiving warehouses. This may contribute to a general feeling of fairness between partners, even when failed deliveries lead to penalties.
The company's expectations of reducing transaction costs, based on transparency, trust, and disintermediation, are in line with Roeck et al. [58] and Hooper and Holtbrügge [28] because the DLT for PoD can reduce the costs of data verification and dispute resolutions. The case study also suggests that disintermediation contributes to reducing information asymmetry and supporting managers in identifying operational errors, in line with Roeck et al.'s, [58] multiple case studies. However, when LSPs with potentially valuable (context and background) information do not adopt the DLT for PoD, disintermediating them or removing them from the network might increase transaction costs. This is because disintermediation, according to Sun et al. [88]) and Catalini & Gans [89], might not add more value than DLT capabilities Transaction Costs Reduction Estimates Transparency Trust Disintermediation Assisting managers with their limited capacity to identify operational errors --Reduce opportunistic behaviour by supply chain and logistics partners -Cost of partners' performance evaluation ---Cost of selecting, or switching to, new partners --Automating the monitoring and enforcement of penalties ---Reduce information asymmetry in the supply and logistics chains --Optimize supply chain and logistics operational processes --Increased network dependency on transparency -Increase bargaining power with supply chain and logistics partners - creating new roles for network actors, such as collecting and adding the necessary background and contextual information to the DLT to reduce information asymmetries and identify operational errors. Thus, while DLTs for PoD are rapidly being theorized and developed as described in the literature section, our case study shows a need to design DLTs capable of handling the complexities of the delivery processes, as well as information for robust performance measurements, and this was showed in the critical analysis of the reduction and/or increase of transaction costs according to the capabilities of transparency, trust, and disintermediation. However, given that much of the delivery processes remain off-chain, there is an urgency for digitalizing the SC to further enable better SC performances with DLTs or introduce new roles to gather relevant data from LSPs and supply chain partners.
In this article, two of the four SC delivery KPIs were addressed, i.e., on-time, in-full delivery. Two additional KPIs were assumed to be within specifications, i.e., accurate documentation and goods in perfect condition. And while the verification of specifications is assumed to be an off-chain operation, the validation and acceptance are on-chain transactions. Given the increased transparency in the SC with DLTs, applying automated penalties is hard to repudiate. Such capability incentivizes LSPs to deliver at the ETA and receiving warehouses to minimize unloading and delivery scheduling errors.

VI. CONCLUSION AND FUTURE WORK
Blockchain, distributed ledger technologies, and smart contracts applied to SCM are in the early stages of technological maturation and adoption. This article discussed whether DLTs might address the delivery and PoD processes, measure performance accurately, reduces information misalignment between partners, and reduce transaction costs. We developed a DLT system architecture within a case study with an explorative design science approach [72]- [75].
The DLT capabilities include the management of delivery processes, delivery performance measurement, automated payoffs, and dispute resolutions. Despite many off-chain operations, these are used as inputs to verify and register in the DLT architecture to reduce information asymmetries. While SC scholars have found that DLTs may reduce trust, in some cases transparency, and may increase SC rigidity [31], [32], our case study indicates the company might rather use the DLT to build transparency and trust, whilst disintermediation would not necessarily be the aim of future implementation. Data accuracy, transparency, reliability, and better performance measurement might induce fairness, trust, and better SC relationships.
According to Treiblmaier [13], transaction costs should be assessed before and after a DLT implementation. Our investigation agrees with such statements; for instance, it is expected that by implementing the DLT, delivery failures may decrease over time, reducing penalties and overall transaction costs. And our results show that three capabilities could decrease transaction costs (i.e., transparency, trust, and disintermediation). On the other hand, there are trade-offs between reducing transaction costs with the DLT and the increased opportunity and cost by disintermediation or switching SC partners with low performance. Nevertheless, given that the search and selection of new partners become less costly with the smart contract for performance measurement, switching costs are expected to be compensated with a reduction in search and selection of LSPs. This article assumes that off-chain dispute resolutions are embedded into the DLT. However, in practice, the parties require resolution agreements to be signed off-chain, upon which the smart contract validates the resolution and registers it 12 VOLUME 4, 2022 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3185634 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ into the blockchain. Future developments might include using private keys to encrypt information instead of relying on a trusted third party as a funded escrow arbitrator.
This shows another critical point that future research endeavours should address: supply chains, in general, require digitalization and Electronic Data Interchange, Auto-ID, and IoT, as suggested by Puggioni et al. [39], and Caro et al. [20]. Future work on DLTs should consider using such systems and technologies and assess the cost-investment implications of digitalization of the entire supply chain or intermediate/progressive steps of digitalization. The current testbed implementation is deployable in the Ethereum network. Alternatively, Hyperledger Fabric [90], Exonum [91], Hyperledger Besu, etc., can be used in a productive environment. Furthermore, the nodes have been developed in an Ethereum Virtual Machine, and deploying the smart contracts in physically dislocated Ethereum Virtual Machines and living-lab environments will be the aim of future investigations.

ACKNOWLEDGMENT
Yash Madhwal's reported study was funded by RFBR according to the research project No 20-37-90128. This research received funding from LIUC Università Cattaneo under the project "Secured by blockchain: developing cyber-risk free supply chains". We would like to thank the precious inputs from Ponti's Chief Supply Chain Manager Andrea Gaggianese, and Supply Chain Specialist Flavio Manara. Thanks the Secured by Blockchain project research team and collaborators: Prof. Fabrizio Dallari, Prof. Claudia Colicchia, Prof. David Menachof, Prof. Horst Treiblmaier, Prof. Luca Urciuoli, and to the project's Advisory Board, and the attendants of LIUC's Secured by Blockchain Forums.