Cash flow management is crucial to the financial wellbeing of construction and engineering firms and the on-time and successful delivery of construction and infrastructure projects (Peters et al. 2019 ).
Construction progress payments constitute a big portion of cash flow on a project, compensating the general contractor, subcontractors, suppliers, and equipment providers for the work performed during a billing period. The payment practices in the architectural, engineering, and construction (AEC) industry suffer from slow payments (Chen and Chen 2005; Durdyev and Hosseini 2019), information asymmetry (Xiang et al. 2015) , and low productivity due to ineffective contracting practices (McKinsey 2017) . Poor payment practices are a major risk for the industry (El-Sayegh 2008) and create distrust between stakeholders (Manu et al. 2015) .
In the past decade, the AEC industry has experienced an increasing interest in automated progress monitoring at job sites, with research studies focused on reality capture technologies (Akinci 2015) : the use of robotics, artificial intelligence, and building information modeling (BIM) for 1) capturing (Ham et al. 2016; Omar and Nehdi 2016) , 2) analyzing (Pătrăucean et al. 2015; Tang et al. 2010) , and 3) modeling the job site conditions (Cerovsek 2011; Volk et al. 2014 ). These efforts result in semantically rich as-built BIMs and progress data that has potential to streamline payments and automate the transition from product flow to cash flow in the construction supply chain.
Despite the availability of digitized progress data, payment automation is far from reality. Projects still rely on traditional payment applications that are time consuming, information intensive, and heavily intermediated (Penzes et al. 2018) . In recent years, digital payment management systems have been developed, commercial solutions that enable project participants to complete the payment application online instead of using paper. This reduces the payment processing effort by 84% (Barrón and Fischer 2001) .
These digital platforms, however, still cannot support payment automation. This is partly due to their inability to use the output of reality capture technologies and partly because they adopt the same underlying manual and intermediated workflows as paper-based applications. As a result, they suffer from centralized control mechanisms and a lack of guaranteed execution (Hamledari and Fischer 2020) .
To address these limitations, this paper introduces a novel smart contract-based solution to automate and decentralize the conditioning of progress payments on the progress assessments, enabled by the on-site deployment of reality capture technologies. It proposes a method for automating the transition from product flow to cash flow, taking advantage of content addressable and distributed data sharing, blockchain's immutability, and the smart contracts' self-enforceability. The method was evaluated in two commercial construction projects where robotic reality capture was used to document the progress at job sites; the proposed solution was utilized to process payments to a series of subcontractors. This is followed by a discussion of the method's implications for project management and an analysis of its potential for increasing the frequency, granularity, and transparency of payments.
Each construction progress payment can be viewed as a transition from product flow to cash flow ( Fig. 1) . Borrowing from the works of John Searle (Searle 2010; Searle 1995) , the authors distinguish between the two types of facts involved in payment processing. These are respectively referred to as "brute facts" and "institutional facts". The former describes the status of construction and observations regarding the product flow; the latter describes the flow of cash, and its status depends on human agreements, the choice of observer, and their interpretation. In the context of construction payments, institutional facts comprise, among others, the interpretation of payment terms and contractual agreements.
In this work, the terms "physical reality" and "reality" are used interchangeably to refer to the brute facts (i.e., product flow) (Fig. 1a) . The term "reality capture", hence, refers to the use of technology for capturing and documenting the status of physical reality. The term "social reality" is used to refer to institutional facts (i.e., cash flow) (Fig. 1b) . Blockchain-enabled smart contracts have the potential to automate and decentralize both the transition from physical to social reality but also the construction of social reality (i.e., payment settlement) (Hamledari and Fischer 2020) . Section 2.1 reviews the existing body of research on the applications of smart contract and its underlying technology, blockchain, in AEC industry. Section 2.2 reviews solutions focused on construction payments, this work's area of focus, and section 2.3 elaborates the points of departure and the gaps in research that motivate this work.
While the literature has focused on different application domains in AEC, there are two common themes to most studies: 1) increasing transparency via blockchain's traceability feature and 2) creating improved governance models via the use of smart contract's self-executability features.
1. Transparency: the blockchain's traceability feature fosters collaboration among AEC stakeholders (Altay and Motawa 2020), and it helps increase the trust in the data used in construction management applications (Shojaei et al. 2019; Turk and Klinc 2017 (Yang et al. 2020 ).
One study (Singh and Ashuri 2019) classified the design events related to BIM-based processes and proposed a blockchain-based framework for keeping an immutable record of these events. This helps project members to review the historical changes made to a model. Another work (Zheng et al. 2019) proposed the use of blockchain for keeping track of modifications to BIM; this was achieved by storing the cryptographic hashes of files on blocks. A drawback to such approach is the information redundancy.
A framework was proposed to integrate internet of things (IoT), smart contracts, and information models for improved tracking of maintenance and operation records for physical assets (Li et al. 2020) . The ability to keep track of changes and the ownership of data was stated to be the major benefit of blockchain for asset information management systems (Raslan et al. 2020a ); this motivated a conceptual framework for asset information models based on blockchain and focused on operation stage (Raslan et al. 2020b ).
These studies are a great step toward creating shared and transparent view of information; however, they need to go beyond the theory and see further validation in real-world projects.
A framework was proposed for tracing the quality information for precast concrete components using blockchain (Zhang et al. 2020) . Another work (Lanko et al. 2018 ) focused on the integrated use of passive RFID technology and blockchain for tracking ready-mix concrete panels from production to onsite delivery; both solutions need to be validated in future. The possibility of creating a single-source of truth was identified as the most important benefit of blockchain in construction supply chain management (Lanko et al. 2018) . A comparison of traditional and blockchain-based solutions reveals that the latter is better suited for tracking the embodied carbon content in the construction supply chain due to 11 features including decentralization, anonymity, and increased security .
A research study focused on the workflows in water infrastructure projects (Piao 2020) demonstrated that significant performance improvements can be achieved using blockchain. Through case study-based validation, the technology was applied on 44 tasks and across 12 real-world wastewater treatment plant projects. The blockchain-based solution was shown to reduce work hours by 49% (Piao 2020).
2. Governance: new governance models are needed to facilitate blockchain adoption (Li et al. 2019) , and the lack of such models is the primary barrier to successful use of smart contracts in AEC (Sharma and Kumar 2020) . With that regard, researchers have focused on using smart contract's selfexecutability to create new governance models or improve the existing ones.
Through a case study-based approach and analyzing the Dubai government's use of smart contracts, a new model was proposed for delivering government services on a blockchain-based ecosystem (Alketbi et al. 2020) . A novel method (Elghaish et al. 2020) proposed the use of smart contracts for creating a financial system for integrated project delivery (IPD), keeping an immutable record of cost performances against 5D BIM. Non-owner parties interact with smart contract by communicating the performance (retrieved from cost-loaded BIM) and can invoke payments at milestones; the smart contract processes requests based on planned and achieved profits. While the work is yet to be validated, the proof of concept provides potential for creating transparency and eliminating management overhead in IPD.
It was argued (Sreckovic and Windsperger 2019) that smart contract can automate the collaborations across the construction value chain by reducing the reporting overheads and by risk transfer; a conceptual framework was proposed for the use of decentralized autonomous organization (DAO). However, it was not validated. Others argue that the construction supply chain cannot adopt blockchain and smart contracts unless it undergoes major transformations with regard to its business model and procurement arrangement (Tezel et al. 2020) . The weaknesses and threats can be further mitigated by a better understanding of the role of project stakeholders and their responsibilities (Tezel et al. 2020) .
A peer-to-peer (P2P) system was proposed for collaboration, where construction stakeholders become authorized to participate as miners in the P2P network after receiving a digital certificate from institutions such as BuildingSMART (Shi et al. 2020) . While the proposal takes advantage of blockchain's consensus algorithm for content curation in AEC, it needs more specific use cases and a demonstration of its applicability to a particular domain with real-world validation. A smart contractbased solution was proposed for quality acceptance in construction (Sheng et al. 2020a ). The research modeled the workflows based on a set of state transitions, taking advantage of the underlying blockchain protocols. The relationship between actors, their decision, and how they enable state transitions were further formulated (Sheng et al. 2020b) . The method needs to be validated in future. A series of semistructured interviews (Qian and Papadonikolaki 2020) revealed that smart contracts reduce the cost of contract signing and bidding, and they enhance the projects' capital flow issues. The researchers further state that opportunistic behaviors can be minimized on projects where smart contract use provides historical data with regard to project stakeholders and their participation (Qian and Papadonikolaki 2020) .
Future work needs to focus on the integration of smart contract with new contractual models ).
The automation of contract administration and relevant project management workflows have been identified among the first viable application areas for smart contracts and blockchain technology in AEC (Li et al. 2019; Mason 2017; Ye et al. 2018 ). This focus area has received increasing attention in the past few years and due to the technology's elimination of third-party intermediaries and the manual work involved in payment processing Salleh et al. 2020 ).
One study identified the increased transparency in payment systems, resulting from the blockchain's traceability features, and the increase in the quality of cost and schedule data as the key values added by smart contracts (Penzes et al. 2018) . Another work (Hamledari and Fischer 2020) explored the 'why' of blockchain for payments, arguing that payment automation can be achieved using alternative technologies but not reliably; blockchain-enabled smart contracts addresses two major shortcomings of current payment solutions: 1) centralized control mechanisms, and 2) lack of guaranteed execution (Hamledari and Fischer 2020) . If successful, smart contract-based payment solutions have benefits that go beyond improved cash flow; establishing a seamless payment system is the first step toward e-commerce applications in AEC (Wang et al. 2007 ).
Few studies have focused on the security of payments: a smart contract-based solution was introduced (Ahmadisheykhsarmast and Sonmez 2020) to safeguard subcontractors and contractors from the insolvency of the project owners. At the beginning of a cycle, the contractor requests a blockage of funds stored in smart contract for a period of 30 days, to be released afterwards upon owner's review of progress. This helps guarantee that funds will be available at the end of payment period; the workflows for submitting and reviewing payment applications, however, still follow traditional solutions and are susceptible to shortcomings caused by centralized control. A trust-less system was introduced for secure sharing of payment records among stakeholders and semi-automatic enforcement of interim payment terms (Das et al. 2020) .
Others have investigated the automation and decentralization of the workflows around payments:
CryptoBIM ) creates a shared, immutable, and distributed view of BIM on blockchain to facilitate the data transfer between BIM and smart contracts; such integration is key to successful adoption of smart contracts (McNamara and Sepasgozar 2018). Another study (Luo et al. 2019 ) introduced a semi-autonomous method based on Hyperledger (Androulaki et al. 2018 ) that comprised two steps: the contractor manually submits the application for payment along with the supporting documents (e.g., quantity of material) to a consensus algorithm where each project participant acts as a node in the blockchain network; if all nodes approve the submission, it will be passed to a party for manual authorization. This work demonstrates the use of consensus algorithm. However, it necessitates that stakeholders run full nodes, and the process still rely on intermediated workflows present in today's payment applications, subject to potential gatekeeping.
In a case study-based approach, a framework was developed for integrating smart contracts, sensing technology, and BIM for payment automation (Chong and Diamantopoulos 2020) . A notable contribution by this work was conditioning the smart contract execution on the real-world sensor feed.
The smart contract, however, was developed by a third-party vendor and its design was not detailed.
Furthermore, the solution works for elements that are installed on job sites, only applicable to a few element types.
The existing literature clearly demonstrates the power of smart contracts for enhancing construction payments. The applications of smart contracts, reviewed herein, eliminate some of the overhead around payment processing; however, much of the workflows still rely on intermediated processes (e.g., manually submitting, reviewing, and approving applications for payments and their supporting documents). These create opportunities for centralized control, denials of service, and hurt the guarantee of execution. The mere computerization of payment application is not the goal for smart contracts, as automation can be achieved using other alternatives; smart contracts' key value proposition is enabling reliable automation (De Filippi et al. 2020 ) by eliminating intermediated workflows and by creating guarantees and predictability (Hamledari and Fischer 2020) . It is necessary to tailor the design of the smart contract solution based on the properties of the industry problem (Hunhevicz and Hall 2020) to take advantage of its key decentralization feature.
Importantly, there is a need for a smart contract-based solution that can automate the transition from progress data (i.e., physical reality), enabled by reality capture technologies, to payments (i.e., social reality) (Fig. 1) . Such automation needs to be decentralized, free of intermediated workflows, and free of manual applications for payments. Currently, there is no solution for processing payments directly using the outputs of reality capture solutions: the vast array of semantically rich progress data and as-built
BIMs. There is a need for solutions that integrate construction supply chain flows (Kifokeris and Koch 2019) .
Antitrust risks are present with respect to the current studies' use of consortium blockchains such as Hyperledger (i.e., private blockchains run by a pre-selected group of institutions) for handling the cash flow data: the immutability, irreversibility, and guarantee of execution do not always hold in consortium blockchains (Buterin 2015) and depend heavily on group dynamics. Project stakeholders can have competing business objectives and are prone to collusions that can impair the soundness of the consensus algorithm (Schrepel 2019) . Such risks are less present in public blockchains (Schrepel and Buterin 2020) .
Additionally, the broader research landscape has seen very few validations (Kasten 2020 ) and is mostly theoretical and not ready for use in real-world projects (Darabseh and Martins 2020) . This lack of implementations has further created a fear of the unknown and doubts about the automation capability of this technology for AEC practitioners (Mason and Escott 2018) . Therefore, in addressing the limitations discussed above, this work focuses on real-world implementation of its proposed solution.
Automating the transition from physical to social reality faces four major challenges: 1) accurately capturing the physical reality; 2) creating a shared understanding of the captured physical reality in a common language; 3) autonomously conditioning project social reality on shared physical reality; and 4) creating an immutable and secure shared view of project realities. In this work, these challenges are respectively addressed by utilizing reality capture, content-addressable file sharing, smart contracts, and blockchain technology; these 4 pillars (Fig. 2 ) enable reliable automation of construction payments.
The proposed blockchain-based payment system (Fig. 3 ) autonomously translates the progress at job sites (Fig. 3a , product flow) to construction progress payments (Fig. 3c , cash flow) without reliance on centralized, intermediated, and resource-intensive workflows such as invoice collection and application/certification for payments. contractual agreements, and it is deployed on the Ethereum virtual machine (EVM). With each update to the product flow status (i.e., progression of work at job site), the EVM determines the resulting transactions, accounts payable, and accounts receivable by having all its nodes, and not just one, execute the project's smart contract script (Fig. 3c) .
The Ethereum blockchain (Buterin 2014; Wood 2014) was used for the development of the method due to its support of generic developments within the decentralized application ecosystem and its more powerful scripting language compared to Bitcoin blockchain (Nakamoto 2008; Narayanan et al. 2016 ). Project participants do not need to run a full node in the Ethereum network and can either inquire the status of transactions and blockchain via the RPC without participation in Ethereum or alternatively run a light node, a simple verification (SPV) client.
This overlay protocol and consensus-based approach to payments creates predictability and a guarantee of contract administration. In other words, this work's smart contract-based payment system achieves reliable automation by means of decentralizing the payment administration.
Accurate and timely understanding of changes in the physical reality (i.e., product flow) is the first step toward successful payment automation. In this work, construction progress is measured using remote capture solutions mounted on robotic platforms (e.g., camera-equipped unmanned aerial vehicles) or operated manually (e.g., laser scans). The captured data is analyzed using machine intelligence to arrive at the percentage completion data for various scopes of work. The resulting progress data is incorporated into as-built 3D/4D BIM. This creates an integrated data-driven approach through which job site physical reality can be directly used to value the work completed.
The importance of reality capture to payment automation is twofold:
1. It addresses a major challenge associated with blockchain applications: the gap between the onand off-chain realities (solutions bridging this gap are known as 'oracles'). This disconnect makes it impossible to condition the blockchain state transitions on real-world events.
2. It introduces objectivity into the interpretation of physical reality. The valuation of the work becomes independent of the observer, increasing the reliability of the input data provided to smart contract, and also ensuring data consistency across different projects and across each project's life cycle.
While the proposed method operates independently from the choice of remote sensing solution, it is crucial that key data used for the valuation of the work are communicated to the smart contract. This includes the raw data captured at job sites, the project's schedule of values, and the analytics solution used for data processing. This creates auditability and contributes to the reproducibility of the computations.
After the progress of the work is captured and analyzed, the incremental progress needs to be valued based on the project's schedule of values and structured for use by smart contract. There are few challenges associated with this step: 1) the product flow cannot be stored on blockchain due to prohibitively expensive on-chain storage; 2) storing data on blockchain risks the integrity of project information due to the auditability of Ethereum public blockchain; 3) project participants need a means of referencing the same data throughout a project's life cycle without duplicating files across platforms and organizations.
To address these barriers, this work proposes the use of content-addressable file sharing for offchain storage of product flow and across the project P2P network. A private InterPlanetary File System (IPFS) (Benet 2014) network is used to store key data including the schedule of value, as-built BIMs, progress data, and the scripts used for analyzing the status of construction work (Fig. 3a) . The files are stored in a distributed manner and across the IPFS cluster.
The proposed solution references project data by 'what' it is and not by 'where' it sits. IPFS creates a unique content identifier (CID) for each file, the value of which is calculated using cryptographic hash function and hence changes with any modification to the file content. For example, an as-built BIM used for the valuation of work receives a new CID each time new progress data is incorporated into it.
Whereas current data storage approaches reference a file by its location on a project server (e.g., "https://cife.stanford.edu/TR233"), the proposed solution references the same file using a permanent identifier (e.g., "QmXvTCjaxAW4YHnnQMePU1kahvJ1s8jEEuYRwPNppDUFXn). Any stakeholder participating in the private IPFS network can retrieve the same exact file using this identifier. Given the distributed nature of the storage, it is less susceptible to down time since data does not sit with a 'server'.
This reduces the denial-of-service attacks, creates a common language for efficient data referencing between independent stakeholders, reduces file duplication, and creates a permanent link to data across the project life cycle.
More importantly, this work's use of content-addressable identifiers creates a means of bridging between the off-chain supply chain data and blockchain; the CIDs corresponding to key project information used in the valuation of the construction work are communicated to the smart contract and included in state transitions (Fig. 3b-c) . These references will be meaningless to a public viewer of the Ethereum blockchain, but they can be used by project participants to retrieve the raw data used in payment processing. Fig. 4 . The sequence diagram of the workflows involved in smart contract-based autonomous payments: a) smart contract deployment on blockchain; b) on-site reality capture; c) publishing progress data to blockchain; and d) on-chain payment settlement
The smart contract used for autonomous payments (Fig. 4a ) conditions its outputs, the flow of cash and the transfer of lien rights, based on the input it receives regarding project's physical reality (Fig.   4b -c). Contract accounts cannot initiate transactions on their own. The externally owned accounts (EOA), controlled by project participants, need to trigger smart contract functions through a series of calls. The method identifies the incremental construction progress, as analyzed by the reality capture solution (Fig.   3a ), and it values the work using the project's schedule of values, the building elements' semantics and geometry (retrieved from BIM), and the percentage completion data. This process is independent of the level of granularity; it can be high for projects where as-built modeling is performed at a building element level and low for projects where the progress evaluation is performed as a percentage competition for the work on multiple building elements (e.g., electrical work 80% complete).
The method constructs a call to smart contract (Fig. 4c) , communicating the valuation of the work, the public key of the subcontractors performing the valued work, and the CIDs of input data used for the valuation of incremental progress (Fig. 5c) ; the latter includes CIDs for the list of elements and their globally unique identifiers (GUID), as-built BIM, schedule of values, raw progress data, and the automated solution used for progress evaluation.
The call is broadcasted by P2P network to the smart contract's public function, ReceiveUpdate ( Fig. 5a-2) ; this function ensures the calls are correctly formatted and triggers internal functions to initiate on-chain payment settlement.
The function first controls the address of the node publishing the updates against P2P network and verifies that the right CIDs are included. For example, the function controls whether the correct schedule of values is used for the valuation of the work by comparing the CIDs extracted from the call against the CID corresponding to the latest schedule of values, specified by project team and hardcoded into the smart contract. Second, the function keeps track of processed payments by populating smart contract's storage with records of elements, issued transactions, and lien right transfers. This is crucial to avoiding double payments. Writing to storage changes the blockchain states and hence costs gas.
Alternatively, event logs can be utilized to achieve similar functionality. In the latter case, an off-chain algorithm, executed by project P2P network, needs to accumulate the list of payments.
Third, the ReceiveUpdate function triggers internal functions that handle payment settlement and lien right transfer. In this work, payments are settled using Ether, and the lien rights are represented using the LIEN token, modeled using ERC-721 protocol. The method takes advantage of the blockchain's smart property feature, with each non-fungible ERC-721 token representing a unique lien right transfer. As shown in Fig. 5a , the smart contract inherits from both ERC-20 (Vogelsteller and Buterin 2015) and
ERC-721 specifications (Entriken et al. 2018) . 
The internal functions include PaymentSettlement, ConstructPayment, TransferPayValue, IssueLienToken, and TransferToken (Fig. 5a) ; they cannot be triggered from outside the smart contract.
Their logic and parameters are updated and digitally verified by project stakeholders each time there is an amendment to the project's contractual agreements.
Once the public function ReceiveUpdate calls the internal function PaymentSettlement, the latter verifies the smart contract account's balance and calls other internal functions (ConstructPayment and IssueLienToken) to construct the transaction that compensates the payee and to mint a new ERC721 token representing the lien rights associated with the valued work (Fig. 4d) . The TransferPayValue transfers the payment in Ether and to the contractors responsible for the work, as specified by ConstructPayment.
The payment metadata, including references to the building elements and the payment value, are incorporated into the lien token. This is achieved by populating the ERC-721 token's URI with the CID corresponding to the building elements for which the right is transferred. Upon payment settlement, the corresponding lien token is transferred to the owner using TransferToken. If the balance is not enough, the token will be automatically transferred to the contractors responsible for the work; the ERC-721 token can be sent to the contract address to be automatically redeemed for its value.
The smart contract directly writes these transactions to the underlying Ethereum blockchain (Fig.   5d ). This creates an auditable and immutable record of both product and cash flows; these records are semantically rich since they include references to off-chain data sitting on project's IPFS network. For example, inspecting the Ethereum's append-only ledger, project participants can retrieve payments, their corresponding lien token, and the raw data regarding the physical reality that triggered the payments. The CID incorporated as metadata on blockchain (i.e., as part of the transactions on the ledger) are key to retrieving the corresponding data off-chain.
Other interactions with the smart contract include calls to public functions that read the status of blockchain. For example, the stakeholders can inquire the status of payment requests broadcasted to smart contract (PaymentStatus) and the status of lien tokens (TokenStatus) (Fig. 5a) . These interactions do not write to Ethereum. Alternatively, each stakeholder can listen on event logs; as shown in Fig. 5a -1, the smart contract emits events each time new tokens are issued and when payments are settled.
The proposed smart contract-based solution was implemented in Solidity v0.6.2. The Web3 and Infura were respectively used to set up the RPC module and to enable queries about the status of Ethereum blockchain.
The method was used for processing progress payments on two commercial construction sites.
The transactions were processed on Ethereum network, and a private IPFS network was created among the project participants including the owner, the general contractor, and the subcontractors. Table 1 lists the description of each project, the number of trades for which the payments were processed, and the type of building elements covered in the reality captures. Project A is in the state of Ontario (Canada), and it was visited for data collection over a period of 4 weeks. Project B is in the state of California (United States), and data capture was performed at the site for a period of 5 months. The data capture at Project A was performed using a camera-equipped unmanned aerial vehicle (UAV) (Fig. 6a) , resulting in digital images (Fig. 6b) ; a laser scanner mounted on an unmanned ground vehicle (UGV) (Fig. 6c ) was used to capture the state of construction progress at Project B (Fig. 6d) . Table 2 and Table 3 list the 3 tests that were designed to evaluate the feasibility of using the proposed method. The tests performed at Project A (tests 1 and 2) and Project B (test 3) use different reality capture solutions, sensors, data analytics tools, and data formats; additionally, the first two tests have more granular product flow (Table 3) with progress data available per 104 inspected building elements with connection to BIM. The third test's product flow, on the other hand, is low in granularity and provides aggregate percentage completion. These disparities are intended to help better evaluate the generalizability of the proposed method and its applicability in commons progress monitoring practices.
In tests 1 and 2, UAV-captured digital photos are passed to a computer vision-based solution Hamledari et al. 2017) to generate the states of progress for indoor partitions. The progress data is incorporated into industry foundation classes (IFC)-based 4D BIMs using an automated method . The remote sensing solutions were run on a laptop computer with a Windows 64-bit platform, 2.6 GHz core i7 CPU, and 16 gigabytes of memory.
In test 3, the UGV-captured point clouds are processed by an outside vendor, and the progress data are directly used for payment processing and were not incorporated into 4D BIM. In all tests, the raw data, progress assessments, and the as-built 4D BIM were stored on the IPFS network and used as input to initiate the payment process (Fig. 2) . (Fig. 6c) Laser scans (Fig. 6d) Outside vendor -.rvt, .nwd XML * See Table 1 for project details Test 1 and 2 only differ in terms of the payment frequency (Table 3 . In both tests, the same scope of work is valued and compensated. However, the payments are processed bi-weekly and monthly, respectively in test 1 and 2. This was intended to evaluate the feasibility of using the method for more frequent payments. Monthly Low** 20 * Progress data collected and analyzed per GUID ** Aggregate progress data reported for all inspected building elements Table 4 lists the results of the performed tests, including the processing time per each payment cycle, the accuracy of both remote sensing and the proposed smart contract-based solution, and the number of payment cycles. The progress assessments and the method's outputs including the transactions were manually verified to assess the accuracy. The accuracy of the remote sensing solution is defined as the percentage of elements for which the state of progress was accurately identified (i.e., reported as-built condition matches the on-site condition, manually verified by the authors). The reality capture accuracy is not available for test 3 because the outside vendor does not manually verify the on-site condition, nor they publicly share the accuracy of their platform. As for the payment processing, a payment is considered accurate if the monetary value transferred by smart contract, the recipient, and the incorporated metadata (e.g., CIDs) match the ground truth. All transactions were manually verified, and no issues were observed with the accuracy of the smart contract's payment settlement. In addition, the payments were successfully settled for the entire scope of work covered in the progress reports.
The payment processing times reported per cycle (Table 4) 1 and 2) . The processing times do not include the data collection time (i.e., site visits) and data preparation (e.g., transferring data from robots to computer). 5 20 5 hours*** 4 minutes -100% * Automated detection of progress and model updating (excludes data collection time) ** The construction of calls to smart contract, smart contract execution, and on-chain payment settlement (12 block confirmations) *** Reported by outside vendor
The proposed method was successfully used to arrive from the observations of job site conditions (physical reality) to progress payments (social reality) without reliance on centralized control mechanisms. In contrast with traditional payment applications, no party submitted applications for payment in the proposed method; the transactions were autonomously processed based on reality capture outputs.
Increased payment frequency is an important impact of smart contract-based payment settlement; the lower bound for the duration of the payment cycle is limited by the capability of the reality capture solution and not the smart contract; the latter can process payments as frequently as data becomes available with respect to incremental construction progress. Taking into consideration the processing times (Table 4) , the duration of robotic data capture at sites, and the data preparation times, the entire process can span between one to few days.
In other words, payments can be processed within one to few days after on-site observations. The implications are significant for a cash-poor industry where it takes engineering and construction firms around 3 months to receive payment (PwC 2018), with industry performance degrading over time (PwC 2019). Furthermore, the Ethereum blockchain's throughput does not seem to pose challenges for the scalability of construction payments. Even with highly granular cash and product flows, the construction payments are still relatively high in value and low in volume compared to industries such as retail.
This increased granularity is not limited to the temporal scale, and can be further extended to the product and cash flows. The method can process payments for highly granular choices of elements (e.g., framing completed for a particular wall); this granularity is a function of the reality capture solution. For example, highly granular payments were not a possibility for test 3 due to the progress reporting format of the outside vendor.
While the proposed smart-contract-based solution was demonstrated to be highly accurate (Table   4 ), the accuracy of its input data (outputted by reality capture technologies) is of paramount importance to seamless and reliable payments. For example, in tests 1 and 2 (Table 4) , the state of progress was inaccurately detected for 5% of the building elements (e.g., a painted partition classified as a plastered partition). The implication was that ~5% of payments, those associated with misclassified elements, were either delayed or processed sooner than expected. This accuracy can still be higher than manually reported progress data, subjective to the interpretation of the inspector. Additionally, the discrepancy does not affect the total valuation of the work, but the timing of a small fraction of payments. This calls for further attention on the integration between reality capture and smart contracts.
Increased transparency is a key benefit that directly translates to the three desirable characteristics of smart contracts, as outlined in Nick Szabo's pioneering works on the concept (Szabo 1994; Szabo 1997; Szabo 1997b) : observability, privity, verifiability. In a traditional payment system, the subcontractors cannot easily identify the source of payment delay, whereas in the smart contract-based method the status of payments and the completed workflows can be directly inquired from the contract account for each scope of work and without reliance on gatekeepers. This increases observability ex post.
The availability of past interactions increases trust development (Buvik and Rolfsen 2015) and hence increases observability ex ante.
The privity is ensured due to the elimination of third parties. The sensitive supply chain cash flow data, for example, is encapsulated from external financial institutions as they are pushed to the periphery (Fig. 2d) . The verifiability feature is enabled via integration. The off-chain data storage and on-chain referencing enables project participants to verify past transactions and in relationship with the data captured on the job site, the script used for analyzing the data, and the schedule of values used for valuation. All smart contract's computations and the resulting cash flow can be re-computed and audited with permanent links to the input data. This creates trust by design and in an environment that is inherently trust-less due to the competing business objectives of its participants. Additionally, integration is key to automation (Kunz and Fischer 2020) . The proposed method's integration of cash and product flow further allows for taking corrective measures, autonomously with the publication of new progress data.
Smart contract-based payment processing has a few implications for project management including a change to the governance model and data management practices. The proposed use of smart contract for payment processing results in a model of construction project as a singleton state machine where the project's truth (i.e., its physical and social realities) are represented by a number of discreet states (Fig. 7a) . These states consist of variables that are globally accessible (within project network) and
contain project information that is of concern to supply chain stakeholders.
Changes to the physical status of job sites triggers transactions that progress the project singleton machine from one state to the next (Fig. 7b) . These state transitions are based on the underlying blockchain's state transitions (Fig. 7c) . At any given time, a project's truth is reflected in the latest state and is the aggregate effect of all the transactions broadcasted up to that point. The key benefit of this model, besides the autonomy and decentralization, is the step-wise development of project's truth among stakeholders, in more frequent intervals and in a transparent manner. Stakeholders can arrive at the same conclusion regarding the current state of a project by independently studying the genesis state and taking into consideration the aggregate effect of all ensuing transactions. This is in contrast with current project management models where stakeholders develop their understanding of truth in isolation and independently. The chances of conflict are potentially lower in the former model. Furthermore, the singleton machine's state transitions are processed by a network of miners that are geographically distributed and independent from project's stakeholders (Fig. 7e) . The incentive structure for these miners is based on block and transaction fees and not impacted by what project transactions are processed, which stakeholder is at the receiving or giving end of a transaction, and how the construction work is valued.
As shown in Fig. 8 , the changes in accessing project information is the other implication of blockchain-enabled smart contracts for project management. Currently, project participants develop their independent data siloes, while transferring data between each other (Fig. 8b ). In the blockchain-based model (Fig. 8a) , on the other hand, the data sits in a common data layer (e.g., the IPFS network in this work, with references stored on chain). Instead of transferring data, project participants transfer the rights to data, and the blockchain ensures those with the right level of access can view or edit the underlying information. The consequences are fourfold: 1) the data redundancy is reduced, contributing to the creation of a single source of truth; 2) barriers to entry are reduced for participants (Catalini and Gans 2016 ) since they do not need to develop their own application and data stack from scratch; 3) a common language is created where project participants can reference the same data in shaping agreements around project's truth; and 4) information integration is increased; in project with integrated information, "no one person or discipline is the gatekeeper of information or interpretation" (Fischer et al. 2017 ). 
The construction industry has been continuously moving toward digitalization, a trend that is significantly accelerated due to the strains imposed on its supply chain by the coronavirus pandemic (McKinsey 2020). Addressing the inefficiencies of the payment system is key to a successful move toward the next normal.
Payment autonomy calls for a move away from today's manual and heavily intermediated workflows around payments including the preparation, review, approval, and execution of payment applications. Smart contracts, enabled by blockchain technology, are argued to address these limitations due to two key features: decentralization and guaranteed execution. Despite its potential advantages, the technology's adoption in the payment systems faces a major barrier: a lack of a link between on-chain payment settlement and off-chain physical reality. The authors argue for an integration between digitized progress data, enabled by reality capture technologies and BIM-based progress monitoring, and smart contract protocols, not only to increase the feasibility of smart contracts application but to also increase the utilization of the semantically rich progress data captured at today's job sites.