1 Introduction
Payment refers to the act whereby one party provides value, discharge, or compensation to another party for the goods exchanged or the services rendered according to the pre-agreed terms (Wunder, 2015). Although payment disputes are inevitable in our business activities, construction is particularly recognized as a business sector that is suffering one of the worst payment records (Wu et al., 2011). Unlike manufacturing products that are designed, produced, and sold off-the-shelf, and upon then, recovered the prepaid costs by the producers, construction products (e.g., a building, or an infrastructure) are bespoke by the clients, and often involve huge prepaid costs for materials, machinery, and workforce that are too burdensome to be bored by the contractors for long. Therefore, payment in construction has its own unique characteristics. Firstly, progress/interim payment is usually adopted to reimburse the contractors for their works completed within a time period rather than waiting for the end of the project (Ahmadisheykhsarmast and Sonmez, 2020). Secondly, the progress payment is further paid through a cascading mode: The project client to the main contractor, then the main contractor to the subcontractors down the chain (Ansah, 2011). Lastly, it is common to place retention to allow for the circumstance when work has not been conducted timeously or correctly (Ramachandra and Rotimi, 2015). Payment disputes can take place in any of the scenarios.
The reasons for late payment are rather complicated. It could be owing to insufficient funds owned by the clients (Badroldin et al., 2016). It can also be attributable to the clients or the main contractors unfairly withholding the payment for their own benefits (Ramachandra and Rotimi, 2015). A late payment could also be attributed to disagreements between the clients and contractors on progress evaluations and variation orders (Ye and Rahman, 2010). Bureaucratic procedures are also recognized as another cause (Peters et al., 2019): Payment requests are often need to be verified and approved by endless parties before a disbursement certificate can be issued.
Late payment exerts negative impacts on construction stakeholders. It may bring cash-flow problems to construction companies, thereby negatively affecting the profit margins and ultimately resulting in insolvency (Abdul-Rahman et al., 2009). Also, late payment can result in the inability to pay wages, further leading to lengthy project delays and adversarial relationships between parties (Wu et al., 2008). Moreover, it may tarnish the image of project participants (Peters et al., 2019), bring difficulties in acquiring funds from financial institutions (Xiang et al., 2012), and minimize the potential to undertake future construction projects (Badroldin et al., 2016). Owing to the negative consequences of late payment, many measures have been adopted to tackle the problem in construction (Price, 2011; HKDB, 2015). Nevertheless, late payment remains a chronical problem in the construction industry worldwide.
Recent advancement of blockchain technologies seems to provide a fresh opportunity to solve this old problem. A blockchain refers to a distributed ledger with cryptography and decentralized consensus mechanisms (Xue and Lu, 2020). Initially, blockchain was introduced as transaction ledgers for cryptocurrencies such as Bitcoin but later has evolved into other decentralized applications, such as smart contracts (Lu et al., 2021c). Construction is an industry that relies heavily on contracts to get the business done. A smart contract may refer to a contract that can be self-executed smartly (Li et al., 2021). In contrast, a traditional contract needs to be performed in a centralized manner by a trusted third party, resulting in long execution periods and additional costs (Zheng et al., 2020). Hamledari and Fischer (2021b) pointed out that blockchain-based smart contracts (BBSCs) can reduce payment issues because they have two key characteristics. First, BBSCs decentralize the execution of payment terms. Second, they provide guaranteed execution of payment terms and eliminate unexpected outcomes for parties.
Researchers have started to tap into the unprecedented opportunity offered by blockchain to the payment problems in construction. For example, Hamledari and Fischer (2021a; 2021c) discussed how the decentralization mechanism of blockchain can change the cascading hierarchical relationships among clients, main contractors, and subcontractors to improve payment. They further explored payment automation using BBSCs and computer means in construction. Das et al. (2020a) explored the fund security for construction payment by using blockchain. Ahmadisheykhsarmast and Sonmez (2020) explored payment automation using BBSCs in construction. These studies made significant contributions to improving payment in construction.
However, the problem domain is still too complicated, which requires further studies. Firstly, there is a lack of a framework to guide the establishment of a decentralized smart payment system for improving the certainty and efficiency of progress payment in construction. Furthermore, there is a lack of an effective system architecture to support BBSC payments while being compatible with existing payment systems (e.g., money transfer through banks). To entirely avoid accepted intermediaries (e.g., banks) in the current construction payment system might be too ideal. Likewise, to exchange the real cash into some cryptocurrencies for payment seems too radical to be trusted by stakeholders, let alone the cryptocurrencies are highly volatile. Finally, the prototype system that can solve the above challenges has not been explored in empirical research.
This study, therefore, aims to develop a BBSC system to improve the late payment problem in construction by focusing on payment freezing and disbursement. It has three specific objectives: (1) to establish a BBSC framework as a reference for smart payment in construction; (2) to instantiate the framework by proposing a system architecture of BBSC payment; and (3) to develop a BBSC prototype system by implementing the system architecture in a case study. The study makes three main contributions to the body of knowledge. First, it provides a BBSC framework to improve the certainty and efficiency of payments by freezing funds in the payer’s accounts and mobilizing smart contracts to quickly and autonomously complete a disbursement cycle. Second, to bridge the conceptual framework and implementation, this study presents the system architecture of the BBSC payment. The proposed system allows banks to use tokens to transfer assets between payers and payees. This is advantageous because it is unrealistic to change the current institutional arrangements of the financial industry, especially the intermediary role of banks. Meanwhile, not involving unstable cryptocurrencies such as Bitcoin can help project stakeholders avoid high volatility and maintain financial stability in the market. Third, to provide a valuable reference for designing BBSC governance policies, the study implements a prototype system that allows policymakers to simulate various BBSC payment scenarios for different construction projects.
The rest of the paper is organized as follows. Section 2 is a review of research focusing on late payments in construction. Section 3 provides a brief overview of blockchain and smart contract technologies. Section 4 delineates the BBSC framework, and Section 5 describes the system architecture of the BBSC payment system. Section 6 implements and illustrates the BBSC prototype system via a case study of a modular construction project. Section 7 offers our discussion, and Section 8 concludes this study.
2 Late payment in construction
A typical progress payment cycle in construction involves four stages: Payment initiation, validation, finalization, and disbursement, as shown in Fig. 1. The payment initiation stage includes applications initiated by the payee (e.g., contractor) after a certain amount of designated work has been completed. The payment validation stage consists of operations such as site inspections and valuation by the validator (e.g., inspector and quantity surveyor), followed by the endorsement of a payable amount through the issuance of payment certificates. In the payment finalization stage, the payer (e.g., owner) finalizes the payment and informs the bank to transfer the finalized amount to the payee’s account. The final stage (i.e., disbursement) involves payment from bank to bank.
Based on the real-life scenarios of progress payment in construction, researchers have investigated the causes of late payment, which could be related to (a) insufficient fund by the clients; (b) unfairly withholding the fund by the clients or main contractors; (c) disputes over the project progress, variations, and quality; and (d) bureaucracies. First of all, a typical reason of late payment is that a client may not have sufficient fund for a project. This is particularly true nowadays when many construction clients (e.g., some real estate developers) tend to use high-risk, high leverage funds and expedite their investment periods. Payment can also be frequently delayed during an economic downturn, where projects not considered priority are often placed on hold or suspended indefinitely (Badroldin et al., 2016).
Another common reason is that payers (e.g., clients or main contractors) may improperly use the funds to improve their own cash flows instead of paying payees (e.g., contractors or subcontractors) promptly (Ramachandra and Rotimi, 2015). It is not uncommon for clients to deliberately delay their payment to the contractors, or even drag the contractors in the circle, e.g., by compensating a property unit for the materials they supplied. Unfortunately, some contractors are forced to accept late payment to maintain good relationships with clients (Ye and Rahman, 2010). In fact, this is becoming an ill culture imprinted in construction business. Without properly dealing with late payment, stakeholders such as clients, contractors, and suppliers will be caught in a vicious circle.
A more monolith reason causing late payment in construction is the dispute over the project progress, variations, and quality (Ye and Rahman, 2010). Instead of blaming the clients only, actually, both clients and contractors/suppliers could be the culprits of late payment. A smooth payment cycle will be starting from a quantity surveyor (QS) or contract manager of the main contractor to issue an interim payment application to the client. Once the QS or architect as the consultant of the client verifies the application, the client will ask its consultant to issue payment certificates to the bank to release the payment. However, when clients and contractors have disagreements over progress valuations, variation orders, or quality of the materials and installation craftsmanship (Ramachandra and Rotimi, 2015), payment will be delayed or even suspended infinitely.
Finally, bureaucratic procedures could lead to late payment in construction (Peters et al., 2019). Generally, government clients often have sufficient funds and do not deliberately withhold project funds, but it is difficult for construction companies to receive payment in time because numerous government departments have to sign payment releases (Laryea, 2010). On the contrary, private clients tend to offer high profits but getting paid timely is difficult too as they may run into financial problems or withhold the payment unfairly (Badroldin et al., 2016).
Despite significant efforts, payment issues in the construction business seem to witness stagnant improvement. An approach that is compatible with existing payment systems (e.g., money transfer through banks) is highly desired to facilitate payment certainty and efficiency, endorse conditions of progress payments, and automatically record payment transactions for construction projects. The latest developments in blockchain technology, especially its smart contracts, seem to provide a novel opportunity to improve the late payment issue in the construction industry.
3 Blockchain and smart contracts
3.1 Blockchain basics
Three main components support the functioning of a blockchain, namely cryptographic algorithms, consensus mechanisms, and distributed ledgers (Xue and Lu, 2020). Hash algorithms are typical in cryptography, ensuring that the recorded transaction data cannot be manipulated (Li et al., 2021). In addition, blockchain incorporates a consensus mechanism to endorse the sequence and correctness of the blocks (Lu et al., 2021c). A blockchain database including ledgers that immutably record transaction data is distributed among network participants (Sadeghi et al., 2021). Owning to these mechanisms, information safeguarded in blockchain is immutable, endorsable, and trackable (Moosavi et al., 2021).
Relying on the mechanisms mentioned above, some blockchain platforms, such as Ethereum and Hyperledger Fabric, enable users to tokenize assets securely. Tokenization refers to the representation of assets as tokens (e.g., non-fungible tokens), allowing participants in the blockchain network to use the ledger to establish an item’s unique ownership and transfer ownership using a consensus mechanism (Hamledari and Fischer, 2021c). Smart tokens are created with three attributes: Owner, type, and quantity (Hyperledger Fabric, 2019). Specifically, the owner identifies the blockchain network participants that can transfer or redeem the token through their authorized identities. Further, the type defines the asset represented by the token (e.g., US dollars), and the quantity is the number of units of the type that the smart token represents. For example, each smart token of type US dollar can represent 100 dollars.
3.2 Smart contract
Smart contracts can be perceived as a great advance in blockchain technology, in which execution of contract terms can be performed on the blockchain with self-executed computerized protocols (Ahmadisheykhsarmast and Sonmez, 2020). Smart contracts include two main components: (a) predefined conditions and (b) responses to be performed when the predefined conditions are met (Li et al., 2021). The life cycle of a smart contract can be summarized into four consecutive phases: (I) initialization, (II) configuration, (III) self-execution, and (IV) completion (Zheng et al., 2020). In Phase I, relevant stakeholders will negotiate their rights and prohibitions. After that, lawyers will be committed to drafting an agreement, and software engineers will transform the agreement into smart contracts (Das et al., 2020a). In Phase II, smart contracts will be configured to the blockchain (Zhong et al., 2020) to form the BBSCs. In Phase III, once the pre-set conditions of the contracts are met (e.g., material reception), contractual responses will be self-executed (Li et al., 2021). Finally, the BBSCs will complete the life cycle by updating the transaction records in the blockchain (Zheng et al., 2020). Many operation transactions created during the configuration, self-execution, and completion phases occur in the blockchain network. Therefore, these transactions will be recorded in the blockchain to allow them be traced retrospectively.
3.3 Smart contract applications in the construction industry
The applications of smart contract start to emerge from the construction industry. For example, Fox (2016) reported that smart contracts allow any changes made by stakeholders to project documents to be automatically recorded. Further, Das et al. (2020b) noted that smart contracts could support document management systems through automation. Sheng et al. (2020b) pointed out that smart contracts may help to improve the efficiency of quality compliance checks in construction. Several studies (Wang et al., 2017; 2020; Sheng et al., 2020a; Zhang et al., 2020; Li et al., 2021; Lu et al., 2021a; 2021b) described that smart contracts could automate the invoke and update operations in blockchain networks. Many researchers (Salar and Sönmez, 2018; Chong and Diamantopoulos, 2020) identified the payment automation of construction contracts as a potential application for smart contracts. Hamledari and Fischer (2021b) further explained that current payment applications, even if computerized, cannot support reliable automation of progress payments due to their reliance on centralized control mechanisms and lack of guaranteed execution. Therefore, they recommended BBSCs to overcome these limitations. Elghaish (2020) adopted blockchain and smart contracts to execute financial transactions in integrated project delivery (IPD) projects automatically.
Existing studies have exploited blockchain’s merits such as decentralization, immutability, traceability, and verifiability. Hamledari and Fischer (2021c) asserted that BBSCs can eliminate centralized control mechanisms and provide execution guarantees, thereby increasing the certainty of payments. Due to the immutability of blockchains, payment protocols written in smart contracts cannot be arbitrarily altered once they are defined (Elghaish et al., 2020). Thus, smart contracts will self-execute responses once the predefined conditions are met. Despite alternative technologies such as Internet-based payment applications that support automation, they lack such certainty (Hamledari and Fischer, 2021a). Moreover, BBSCs can improve payment efficiency by reducing administrative work (Luo et al., 2019). Once the predefined conditions (e.g., delivery report) are inputted, BBSCs can automatically notify the bank to transfer the money from the payer to the payee, shortening the payment cycle (Das et al., 2020a). Researchers have made many valuable contributions in the areas of decentralized contractual relationships, smart contract design and execution, and payment automation, as a way to improve the rampant late payment issues in construction.
4 A blockchain-based smart contract framework for smart payment
A BBSC framework (as shown in Fig. 2) was developed by combining the smart contract lifecycle and the real-life scenarios of progress payment in construction. The framework is composed of three parts, namely initialization and configuration, payment freezing, and disbursement. In the first part, participants (e.g., contractor, manufacturer, QS, architect, inspector, client, and bank) should first agree on payment terms. Then, the agreed terms are developed as computer protocols through smart contracts configured in the blockchain network. In the second part, the payee should submit a payment guarantee request at the start of each payment cycle. The estimated progress payment amount for the subsequent progress payment period of the project can also be calculated by utilizing the project’s planned cash flow after the project starts. The smart contract will automatically check the conditions for freezing payments. If the preset conditions are met, the bank will guarantee the corresponding amount of the payer. The payee should then submit a disbursement application at the end of each payment cycle. Similarly, the smart contract will automatically check the conditions of disbursement applications. Once the predefined conditions are satisfied, the bank will release the funds to the payee.
In the proposed BBSC framework, if the payee does not request progress payment in 30 days or the payer does not approve the payee’s request in 30 days, the bank can then release the frozen amount to avoid the payer’s funds being blocked indefinitely in case of a dispute. The operation transactions generated during payment freezing and disbursement application will be endorsed and recorded in the blockchain through its decentralized consensus network and distributed ledger. The details of the framework are illustrated in the following sections.
4.1 The structure of the blockchain-based smart contract framework
It is crucial to guarantee that the account of the payer has sufficient funds at the beginning of each payment cycle and to transfer the funds to the payee efficiently when payment conditions are endorsed and satisfied. The BBSC structure can directly affect payment performance. Thus, the BBSC framework contains a mechanism for payment freezing, adopts smart contracts for checking the conditions of payment guarantee and disbursement application, and includes banks for freezing or transferring funds.
Smart payment has numerous operations, varying in different payment phases, such as payment freezing and disbursement application. Each operation can be regarded as a transaction, and each transaction stores detailed data of the operation. Thus, a particular smart payment’s specific operation can be matched to a specific transaction. The design of mapping operations with transactions ensures that the BBSC structure can handle various payment operations. Figure 3 shows the transaction structure. Each transaction contains a timestamp, the signature of the person in charge, the hash value of the current transaction, the hash value of the previous transaction, and the data. The data consists of a key–value pair. The key provides payment freezing stages such as “Payment freezing request”, or disbursement stages. The value shows in the form of an object containing the content of payment freezing data, such as “Payment Freezing_ID” and “Payment Freezing Estimated_Sum”, or the disbursement data. With the data frame structure, the operation transactions can be format-free when inputted into the BBSC system.
Smart contracts are used to check whether all payment data inputted by the user or called from the blockchain has been wholly collected (condition) in each stage. According to the check result, the smart contract will trigger a response by rejecting the operation transaction or sending it to a blockchain-based network for consensus. The conditions and responses of smart contracts for the BBSC framework for payment freezing and disbursement application are summarized based on the inter-relation of processes, participants, and payment-related conditions of progress payment cycles. The upper part of Fig. 4 shows the first type of smart contract used in payment freezing, involving five stages. For instance, at the stage of payment freezing request, only when the smart contract confirms the “Payment Freezing_ID”, “Payment Freezing Estimated_ Sum”, and “Payment Freezing_ Request_Date” have been included in the transaction, will it trigger a response by sending the transaction to the blockchain-based network for consensus. Similarly, the lower part of Fig. 4 shows the second type of smart contract used in disbursement application, involving six stages. For example, after the payee submits the disbursement request, the inspector should input the “Proof_Of_Inspection” based on the on-site inspections. After that, only when the smart contract confirms “Disbursement_ID” and “Disbursement_Inspection_ Date” have also been included in the transaction will it trigger a response by sending the transaction to the participants in the blockchain network to reach a consensus about its validity.
After transactions are endorsed in the network through the consensus mechanism, they can be stored in blockchains held by the participant. Each block includes a head and a set of transactions, as presented in Fig. 5(a). Block header is composed of an index, a timestamp, signatures of participants, and hash values of the current and the previous blocks. Banks will freeze the corresponding funds of the payer or transfer the funds to the payee depends on whether endorsed transactions are for payment freezing or disbursement application (see Fig. 5(b)).
4.2 Smart payment processes in blockchain-based smart contract structure
After the project is launched, the payee can initiate the payment guarantee through the BBSC system at the beginning of each month. It includes five stages: Request, valuation, certification, finalization, and completion (see Fig. 6). Smart contracts are used to check the conditions of each payment freezing stage automatically. Firstly, the payee will submit a request for payment freezing. Subsequently, QS will input the valuation of the payment guarantee. Next, the architect will submit a verified evaluation period, and then the payer will enter the checked certification period. Finally, once the conditions of payment freezing are met for each above stage, the bank will freeze the corresponding amount of the payer.
Similarly, the payee can initiate a disbursement at the end of each month. The disbursement application includes six stages, as shown in Fig. 6. In the first stage, the payee will first submit a disbursement application. Then, the inspector will input the actual progress and quality of the work. Next, QS will input the valuation of the disbursement, the architect will submit the validated valuation period, and the payer will input the checked certification period. Finally, once the conditions for disbursement finalization are met, the bank will transfer the corresponding funds to the payee and issue proofs. Smart contracts are used to check the conditions of each disbursement application stage. Until the project is finished, the payment freezing and disbursement application will be repeated for the next progress payment cycle. The operation transactions originated from the above processes will be endorsed and recorded in the blockchain-based network.
5 System architecture
Based on the proposed framework, the system architecture of the BBSC system is developed, as shown in Fig. 7. The architecture includes three essential layers, from the bottom to the top, including the Infrastructure as a Service (IaaS), Blockchain as a Service (BaaS), and Software as a Service (SaaS).
5.1 Infrastructure as a Service (IaaS)
IaaS of the BBSC system allows participants to input relevant data for payment freezing and disbursement application through three applications. The first application is a user input application (A1) that allows all participants to enter the required data during the corresponding stage of the payment freezing or disbursement application. For example, the payee can input the ID, estimated sum, and request date of payment freezing through A1. Once the smart contract confirms that it has received all the required data from the data interface (condition), it will send it to the blockchain-based network for consensus (response) (see Fig. 4 in the upper part). The second application is a project management application (A2) which is designed to help QS calculate progress data (e.g., planned and actual completion dates) and cost data (e.g., planned and actual cost). For example, the QS can choose the first progress payment month and calculate the planned cost using A2. The module will then send the planned progress cost to A1. After the smart contract checks corresponding conditions (see Fig. 4 in the upper part), it will send data to the blockchain-based network for consensus for payment freezing valuation. A similar procedure can be done for disbursement valuation using A2. Besides, a mobile-based inspection application (A3) is included. According to the workflow, A3 allows inspectors to check the actual progress and quality of the work by inputting photos and posting comments.
5.2 Blockchain as a Service (BaaS)
BaaS of the BBSC system includes a primary functional module to interoperate information such as payment operation transactions. In BaaS, Hyperledger Fabric (a permissioned blockchain platform) is used, containing the services of the chaincode (in Hyperledger Fabric, smart contracts are packaged as chaincode), BBSC network, and ledger.
5.2.1 Chaincode
The BBSC system is configured with chaincode S1 and S2. S1 contains five smart contracts and services for payment freezing. Each contract helps to check the conditions of the corresponding payment freezing stage automatically. Figure 8(a) shows an example of the smart contract algorithm used to check the conditions at the stage of payment guarantee valuation. The smart contract can initiate the valuation of payment freezing using hash values as start signals after the payee sending the payment freezing request. Then, the smart contract will call the requested data from the blockchain and quantity surveyor and check the related conditions. When the preset conditions are met, the smart contract will convert the data into a transaction and send it to the blockchain network for consensus.
S2 contains six smart contracts and services for the corresponding disbursement stages (see Fig. 4 in the lower part). For instance, Fig. 8(b) shows an example of the smart contract algorithm used to check the conditions at the stage of on-site inspection. The smart contract can initiate the inspection using hash values as start signals after the payee sending the disbursement request. Next, the smart contract will call the requested data from the blockchain and inspector and check the related conditions. When the preset conditions are met, the smart contract will convert the data into a transaction and send it to the network for consensus. Similarly, smart contracts can also automatically check the conditions at other stages of disbursement.
5.2.2 Blockchain-based smart contract network and ledger
The BBSC network is a two-channel structure that provides ledgers (L1, L2) to facilitate distributed storage. The network consists of six organizations: Payee (M1), Inspector (I2), QS (Q3), Architect (AR4), Payer (P5), and Bank (B6), as shown in Fig. 9(a). Also, the network has two configurations, CC1 and CC2, which list the organizations’ policies. These policies define the role each organization will play in the channels. CC1 is agreed upon by M1, Q3, AR4, P5, and B6. Moreover, M1, Q3, AR4, and B6 will join peers (usually the manager of an organization), named MP1, QP3, ARP4, and BP6, to Channel 1, while P5 owns O, the ordering service of the channels. These peers will hold a copy of the ledger (L1) of Channel 1, where payment freezing related transactions are recorded. Besides, they will also interact with Channel 1 through Applications A1 and A2, which they own. Similarly, these organizations, including I2, will join their peers on Channel 2. These peers will hold a copy of the ledger (L2) of Channel 2. They will interact with Channel 2 through Applications A1, A2, and A3. All six organizations have a corresponding Certificate Authority (CA1–6) authorized by O, generating the certificates to approve their identities.
In BBSC, two types of ledgers (L1, L2) are used to record transaction information. L1 will only record payment freezing information that occurred in Channel 1, and L2 will record disbursement information that occurred in Channel 2. Figure 9(b) shows that each ledger includes two different but related parts — a world state and a blockchain. The ledger world state includes the key–value pair of a transaction (see Fig. 3). The second part, blockchain, is a historical record of how transactions reached their current states (see Fig. 5(a)).
5.3 Software as a Service (SaaS)
By involving a consensus mechanism at the SaaS layer, all transactions related to payment freezing and disbursement application can be endorsed before being recorded in the ledgers of the BBSC system. The consensus mechanism used in the BBSC can ensure that the relevant peers agree on the correctness and order of transactions. The BBSC system uses Hyperledger Fabric as the core blockchain infrastructure in BaaS, and this permissioned blockchain works with a set of pre-authorized peers. Thus, the BBSC system adopts a basic Crash Fault-Tolerant (CFT) consensus mechanism to endorse the transactions produced from payment freezing and disbursement. Since the CFT in the permissioned blockchain does not involve the expensive mining process like the Proof of Work, it can maintain high throughput and low latency.
6 A prototype system
Based on the proposed framework and its system architecture, a BBSC prototype is developed as a shadow system parallel to the existing payment system to illustrate its processes and advantages. The research team chose the off-site mock-up production (OMP) phase of a modular construction project as the pilot scenario for developing and implementing the prototype system. The OMP included ten modules under production in a factory. The budgeted cost of OMP of the ten modules is 5 million dollars.
6.1 Three applications for the IaaS layer
The implementation of the BBSC system first included three applications. A1 was developed by HTML5/CSS3/PHP/JavaScript, and the Web3.js library was adopted for interacting A1 with the blockchain peers and the smart contracts. Therefore, users participating in the smart payment processes can input data through the user interfaces of A1 for payment freezing requests and disbursement applications. For example, after the project has started on June 1, 2021, Manufacturer A (payee) used A1 to request to safeguard the first month’s estimated sum by inputting the “Payment Freezing Estimated Sum” and “Payment Freezing Request Date” (see Fig. 10(a)). Similarly, Manufacturer A applied for the progress payment of the first month by inputting bank name, account name, disbursement sum, and request date in A1 on July 1, 2021. Besides, the QS used A1 to input all the required data to validate the payment freezing request and disbursement application. Also, the architect adopted A1 to input data to certify the payment freezing request and disbursement application. After the prior stages were completed, the client (payer) used A1 to finalize the payment freezing request/disbursement application and notify banks to freeze or transfer payments.
A2 was developed for project management in C# with Visual Studio 2019. For example, at the payment freezing evaluation stage of the case project, QS selected the corresponding month (June in the case project) and the file containing the cost data through A2 to calculate the planned progress payment amount. Similarly, the actual cost data was determined by pressing the “Actual Cost” button on July 1, 2021, as shown in Fig. 10(b). And A3 was developed by Flutter (an open-source application development kit). After Manufacturer A submitted the disbursement request, the inspector uploaded the corresponding inspection results (e.g., progress) through the mobile-based user interface of A3 (see Fig. 10(c)).
6.2 Smart contract and blockchain network for the BaaS layer
The smart contract part (backend) was developed in JavaScript language, and the developed smart contracts were packed as chaincode S1 and S2 (see Fig. 11(a)) and installed on corresponding blockchain peers. In addition, the Docker engine (version 19.03.13) was utilized to form an environment for managing chaincode. The blockchain-based network was established on Hyperledger Fabric (version 2.0, Alpha). The development environment was in Linux version 5.4.0-58-generic-lpae (5.4.0-58.64~18.04.1) (Ubuntu 18.04.1 LTS), and the Docker-Compose (version 1.21.2) was employed to organize Docker containers to facilitate the formation of the network. Six organizations were configured in the network, namely, Client, Manufacturer A, Inspector, QS, Architect, and Bank, as shown in Fig. 11(b). Moreover, Channels 1 and 2 were configured for passing transactions related to payment freezing requests and disbursement applications to ledgers, respectively (see Fig. 11(c)).
6.3 Consensus service for the SaaS layer
The genesis block of the BBSC network was configured to initialize the consensus mechanism for payment freezing and disbursement services, as demonstrated in Fig. 12(a). FabTokens were used to tokenize the assets in the case project, and each token was defined as one dollar. According to the endorsed payment freezing request, the bank was simulated to freeze 1960000 client’s FabTokens on June 1, 2021. As a result, the client’s wallet balance changed from 5000000 FabTokens (see Fig. 12(b)) to 3040000 FabTokens (see Fig. 12(c)). On July 1, 2021, after the smart contracts checked all the disbursement conditions and blockchain peers endorsed the transac-tions, the bank was then simulated to release 1560240 FabTokens to Manufacturer A (see Fig. 12(d)). The excess 399760 (i.e., 1960000 − 1560240) FabTokens were transferred back to client through the bank.
7 Discussion
The BBSC framework developed in this study provides an effective solution to improve the late payment issue in construction. Table 1 lists the current challenges faced by traditional construction progress payments, and they are aimed to be solved by the proposed BBSC framework. This study draws on real-life scenarios of progress payment in construction to design a BBSC system architecture, taking into account the characteristics of blockchain and smart contract technologies. The prototype system illustrates implementation of the proposed system architecture in improving late progress payment in construction.
Tab.1 Current challenges in traditional construction progress payments and corresponding solutions of this study |
| Current challenges in traditional progress payments | Solutions of this study |
|---|---|
| Low certainty of progress payment | Freezing the funds in the payer’s account at the beginning of each payment cycle through the BBSC system |
| Inefficient paper-based payment application | User friendly web-based interfaces for payment application |
| Low efficient on-site inspection for payment validation | Digital inspection through developed mobile-based inspection application |
| Manually conducted valuation for payment validation | Semi-automatic valuation through developed project management application |
| Manually checked conditions for disbursement | Automatic check of the conditions of payment freezing and disbursement applications through the BBSC system |
| Centralized control mechanism for progress payment (e.g., the client controls payment) | BBSCs decentralize the payment mechanism; therefore, after corresponding parties meet the payment conditions, smart contracts can be automatically executed to notify the bank to pay the payee |
The developed BBSC system in this study is compared with the existing solutions (Ahmadisheykhsarmast and Sonmez, 2020; Das et al., 2020a; Hamledari and Fischer; 2021a), as shown in Table 2. It has five novelties. Firstly, the BBSC framework increases the certainty of payment by freezing the funds in the payer’s account at the beginning of each payment cycle. Secondly, the BBSC system is integrated with a mobile-based digital inspection application, allowing efficient inspection for payment validation. In contrast, the traditional on-site inspection (Das et al., 2020a) is inefficient, and the use of reality capture technologies in the study of Hamledari and Fischer (2021a) is limited to certain building elements (e.g., partitions). Thirdly, similar to Ahmadisheykhsarmast and Sonmez (2020), the BBSC system incorporates a customized project management application to achieve semi-automatic valuation (cost calculation) for payment validation. Fourthly, due to the self-enforceability of smart contracts, the BBSC system improves payment efficiency (automatic check of the conditions of payment freezing and disbursement applications) compared with manual works (Ahmadisheykhsarmast and Sonmez, 2020). However, when using computer vision techniques such as in Hamledari and Fischer (2021a), the condition check may not be completely accurate, requiring further algorithm improvement. Fifthly, unlike Ahmadisheykhsarmast and Sonmez (2020) and Hamledari and Fischer (2021a), the proposed BBSC system can work with existing payment systems by allowing banks to use tokens to transfer assets between payers and payees. This is advantageous because it will be unrealistic to change the prevailing institutional arrangements in the finance industry, particularly banks’ intermediate roles. Meanwhile, not involving unstable cryptocurrencies such as Bitcoin can help project stakeholders avoid high volatility and maintain financial stability in the market. Further, Das et al. (2020a) involved a manual process to associate records of payments made through external bank transactions with the proposed framework for progress payment through payment proof. However, the current study overcomes this shortcoming by using tokens.
Tab.2 Comparison between the existing solutions and the proposed BBSC system |
| Ahmadisheykhsarmast and Sonmez (2020) | Das et al. (2020a) | Hamledari and Fischer (2021a) | This study | |
|---|---|---|---|---|
| Payment freezing | Provided | Not provided | Not provided | Provided |
| On-site inspection for payment validation | Not mentioned | Traditional on-site inspection | Reality capture technologies | Mobile-based digital inspection application |
| Valuation for payment validation | Semi-automatic valuation based on Microsoft Project add-on | Manually conduct valuation | Manually conduct valuation | Semi-automatic valuation based on developed project management application |
| Payment finalization (payment condition check) | Manually check payment conditions | Automatically check payment conditions by smart contracts | Automatically check conditions by using computer vision-based solution | Automatically check payment conditions by smart contracts |
| Payment completion | Peer to peer payment (Cryptocurrency) | Bank to bank transfer (Electronic transfer) | Peer to peer payment (Cryptocurrency) | Bank to bank transfer (token) |
Despite these novelties, this study also faces some limitations that should be addressed in the future. Firstly, in the current system, due to the immutability of the blockchain, smart contracts cannot be modified once deployed. However, accommodating changes in timeline is happening ubiquitously in real-life projects. Thus, the proposed BBSC system will be extended to deploy a method for amending payment contracts in the future. Secondly, some stages involved in preparing the inputs still require human involvement. Smart contracts cannot work without real-world information. Nevertheless, the developed BBSC system lacks an oracle, which means an agent can verify events in the real world and forward this information to the smart contract. Therefore, future studies are encouraged to form an oracle framework. Thirdly, there is a lack of a systematic framework for forecasting the costs of a production-scale, commercial BBSC payment system. Thus, a detailed cost assessment of the proposed BBSC is desired when better empirical data is available.
Even though the limitations can be addressed by future studies, the hurdles to prevent such a payment system from actual implementation should not be underestimated. It would constitute an over-optimism to assume that a technology such as a blockchain can easily disrupt the persistent payment problems in an old industry. Some of the problems are caused by current contract forms associated with a procurement model, e.g., design, bid, and building (DBB). Even with their decentralization, BBSCs are not effective because the change of the current cascading payment mode or the hierarchical relationships among the parties cannot occur without changing the existing legal system. The positive side is that some new procurement models (e.g., IPD) provide an opportunity for BBSC systems. Likewise, it is unrealistic to eliminate the role of banks and shift to a decentralized smart payment without intermediaries. Looking at the volatility of cryptocurrencies, people may trust the sovereign currencies operated by banks in serious transactions such as construction projects. However, BBSC systems can still operate with banks’ promotion of digital currency/electronic payment (DC/EP) (Lu et al., 2021c). The special ingredient is that banks no longer serve the clients only but as a more impartial intermediary to facilitate payment between the payers and payees.
8 Conclusions
This research developed a blockchain-based smart contract (BBSC) system to solve the keen issues of late payment in construction. The BBSC system starts from writing agreed payment terms as smart contracts (i.e., computer protocols) and configures them in the blockchain-based network hosted by banks. Then, payees are required to submit payment freezing requests at the start of each payment cycle. Smart contracts will automatically check the conditions of payment guarantee, and notify the bank to freeze the estimated progress amount. In the end, payees can submit disbursement applications at the end of each payment cycle and the smart contract will automatically check the conditions of disbursement applications and notify the bank to release the fund or otherwise. A case study of developing a BBSC prototype system and implementing it as a shadow system in a modular construction project showed that our BBSC system can improve the certainty and efficiency of progress payment in construction.
The BBSC system shows several novelties. Firstly, instead of developing an all-around smart payment system, the BBSC system focuses on payment freezing and disbursement as a basic cycle that has not been investigated before. Secondly, it can work compatibly with existing institutional arrangements such as prevailing contractual relationships and banks’ roles in construction. Lastly, it will not adopt the radical approaches, such as tokenizing payment as cryptocurrencies, but use sovereign currencies. This actually provides an opportunity for banks gradually change their roles in using DC/EP in a blockchain era. Despite the novelties, the BBSC payment system is still in the early stages of research and development. Future research can focus on (1) the development of a method for amending smart contracts in the blockchain-based network; (2) evaluating the impact of decentralized contract administration on the dynamics of project delivery methods; (3) the proposition of an oracle framework for smart contracts to bridge the physical- and cyber-worlds; and (4) the design of a framework for forecasting the costs of a production-scale, commercial BBSC payment system.