Source-linked AI summary
Digital Building Twins and Blockchain for Performance-Based (Smart) Contracts
Jens J. Hunhevicz, Mahshid Motie, Daniel M. Hall
TL;DR
Performance-based building contracts have seen limited adoption because performance evaluation, accountability, and financial arrangements remain difficult. This paper connects a digital building twin with blockchain smart contracts to automate trusted performance evaluation and payments, and demonstrates the approach in an Ethereum-based prototype. The prototype functioned as intended, but the authors identify unresolved issues involving performance baselines, cryptocurrency costs, centralized data dependencies, and contract design.
Problem
Performance-based contracts have limited practical adoption because performance evaluation, accountability, and financial concepts remain challenging, while building energy use can substantially diverge from predictions.
Method
The paper conceptualizes and implements a cross-phase performance-based smart contract connecting the Ethereum blockchain with digital building models and sensors through the Siemens building twin platform.
Results
The prototype functioned as intended: 1241 measurements were stored, and encoded transaction logic correctly identified observed thermal performance failures.
Takeaways & Limitations
Combining digital building twins with blockchain-based smart contracts is presented as a way to digitize trusted performance contracts and support lifecycle-linked business models.
Takeaways & Limitations
The study identifies unresolved questions about fair performance baselines, rewards, measurement, cheating prevention, external effects, and service pricing.
Abstract
from arXiv · showhide
Performance contracts used for servitized business models enable consideration of overall life-cycle costs rather than just production costs. However, practical implementation of performance contracts has been limited due to challenges with performance evaluation, accountability, and financial concepts. As a solution, this paper proposes the connection of the digital building twin with blockchain-based smart contracts to execute performance-based digital payments. First, we conceptualize a technical architecture to connect blockchain to digital building twins. The digital building twin stores and evaluates performance data in real-time while the blockchain ensures transparency and trusted execution of automatic performance evaluation and rewards through smart contracts. Next, we demonstrate the feasibility of both the concept and technical architecture by integrating the Ethereum blockchain with digital building models and sensors via the Siemens building twin platform. The resulting prototype is the first full-stack implementation of a performance-based smart contract in the built environment.
2 Basler & Hofmann AG, Zurich, Switzerland
The paper identifies digital building twins, BIM, IoT, blockchain, and smart contracts as core concepts for performance-based built-environment services.
- The paper combines digital building twins, BIM, IoT, blockchain, and smart contracts around performance-based contracts and built-environment servitization.
1. Introduction
The paper frames performance-based contracts as a response to lifecycle performance gaps and fragmented incentives in construction, while proposing digital twins and blockchain as implementation technologies. It investigates their combination for performance-driven built environments.
- Actual building life-cycle energy use can reach 250% above predicted use, illustrating the building-energy performance gap.
- Fragmented AEC stakeholders can pass costs and risks across life-cycle phases because incentives and agency are misaligned.
- Performance-based contracts link parties’ profits to mutually agreed operational performance levels over longer-term commitments.
- Adoption remains limited because of accountability problems, nonstandardized performance evaluation, unfamiliar financial concepts, and additional communication burdens.
- Digital building twins connect physical assets with digital replicas, while blockchain provides transparent records and tamperproof transaction logic.
- The paper investigates combining blockchain-based smart contracts with digital building twins to support a more performance-driven built environment.
2. Departure
The paper situates performance-based contracts within servitized building services and reviews digital twins and blockchain as enabling technologies. It then prototypes a cross-phase thermal performance contract using Ethereum and a Siemens building twin platform.
- 2.1. Towards a performance-based built environment: Servitized buildings shift payment from a capital sum toward purchased services while the producer retains operational, maintenance, and disposal responsibilities.
- 2.1. Towards a performance-based built environment: This model aligns lifecycle performance and cost-minimization interests, although the simplified analogy omits differences between buildings and manufacturing.
- 2.3. Digital Building Twins: Digital building twins extend BIM with automated physical-to-digital data exchange and support real-time performance optimization and what-if assessment.
- 2.4. Blockchain: Blockchain provides distributed, transparent transaction records and smart contracts that execute encoded interaction logic on-chain.
- 2.5. Blockchain and performance-based contracts: Blockchain-based incentives are presented as potentially useful for trust and collaboration across construction life-cycle phases.
- 2.6. Research gap and scope of the study: The study prototypes and tests an Ethereum-based cross-phase thermal performance smart contract using sensor data from a real-world building twin.
- 2.6. Research gap and scope of the study: The paper discusses challenges and opportunities for combining digital building twins with blockchain toward a built environment as a service.
3. Proposed performance-based smart contract architecture
The proposed architecture links sensed physical performance, a digital building twin, blockchain smart contracts, stakeholder interfaces, funds, and oracle middleware. The components jointly support automated performance evaluation and payment execution.
- The architecture separates physical and cyber layers, with sensors measuring built-asset performance and stakeholders interacting with the asset, twin, or contract.
- The digital building twin stores and processes dynamic sensor streams alongside static BIM and stakeholder data on cloud servers.
- Smart contracts continuously receive performance data, check it against encoded rules, and execute workflow steps such as payments.
- Contract roles assign blockchain addresses and permissions to managers, owners, contractors, and service users.
- Performance terms encode agreed service levels, which are checked against actual data before payout logic executes.
- Escrowed cryptocurrency or tokens provide funds for timely contract payments.
- Front-end and back-end oracles connect stakeholder input and digital-twin performance data to the blockchain.
4.1. Use Case
The use case demonstrates a cross-phase thermal performance contract for Tz2, linking agreed performance targets to rewards for construction and operation. Its logic evaluates energy consumption and indoor comfort using sensor data and assigns full, reduced, or no rewards based on performance.
- Building and scenario: The prototype tests a cross-phase thermal performance contract on Tz2, a real-world building monitored through the Siemens building twin platform.Tz2 is located in Vienna and includes sensors, smart meters, energy systems, and thermal building systems.
- Building and scenario: The contract is established during design among the owner, contractor, and facility manager, with the owner setting performance targets.The agreed scope, logic, and performance basis apply across construction and operation.
- Contract logic: The contract leases thermal performance as a service and automatically pays the contractor and facility manager from escrow when agreed levels are delivered.The implementation demonstrates an incentive case rather than a finished performance-contract template.
- Reward assessment: The use case collects indoor temperature, relative humidity, CO2 concentration, and heating and cooling energy consumption, with performance baselines agreed in advance.The agreed inputs include expected energy consumption, temperature and humidity set points, and a target CO2 level.
- Contract logic: Performance assessment combines overall energy performance with temperature, relative humidity, and CO2 comfort measures.Energy performance compares actual average consumption with expected consumption, while comfort ratios compare measured conditions with agreed targets.
- Reward assessment: The facility manager receives full reward when two of three comfort targets are reached, reduced reward for intermediate outcomes, and no reward when two targets fail.The contractor’s reward depends on total energy performance relative to room-temperature comfort, balancing both parties’ incentives.
4.2. Technical implementation
The implementation connects a Siemens digital building twin to an Ethereum smart contract through front-end and back-end oracles. The prototype stores sensor data, evaluates performance, and triggers rewards while addressing transaction-cost and data-integrity constraints.
- Blockchain implementation: Ethereum was selected for the proof of concept, while the Solidity contract was developed with Truffle and tested using Ganache.The paper notes that other blockchains could be selected in future implementations.
- Blockchain implementation: The smart contract separates role and access management from thermal performance logic for the owner, contractor, and facility manager.The deploying contract owner assigns the other stakeholder roles through OpenZeppelin templates.
- Contract execution: During execution, the oracle submits energy and indoor-comfort data at defined intervals; the contract stores, evaluates, and acts on the results.Stakeholders can redeem rewards every six months, and the owner can release remaining escrow after contract completion.
- Oracle architecture: A front-end oracle lets stakeholders configure and interact with the contract, while a back-end oracle transfers building-twin data to Ethereum through Web3.js and Infura.The front end uses a wallet such as MetaMask to sign authorized transactions.
- Constraints: Storing data on-chain increases transaction costs, so submitted data must be minimized while preserving contract functionality and addressing oracle manipulation risks.Large volumes of smart-contract data may become costly and economically infeasible.
- Data acquisition: The test implementation randomized sensor and time selection, sampling indoor measurements on average five times daily and heating energy once weekly.Randomization was selected to reduce predictable data-fetching patterns and related manipulation opportunities.
- Building-twin integration: The technical architecture uses the Siemens building twin platform as an external source for performance-based smart contracts.Static IFC data maps sensors to physical devices and spaces, while dynamic sensor data is fetched from the twin database.
4.3. Test results
The prototype validated the feasibility of executing performance-based smart-contract logic, while exposing substantial cost and implementation-scope constraints. Stakeholder feedback supported the appeal of automated verification but identified organizational, evaluative, legal, and technical barriers.
- Test setup: The two-day Rinkeby test used a 45 kWh weekly energy baseline and comfort baselines of 21° C, 40% relative humidity, and 1000ppm CO2.Thermal measurements increased from 5 to 190 per day to emulate six months of data and generate a payout event within the test period.
- Prototype execution: The Ethereum smart contract functioned as intended: 1241 measurements were stored, transactions followed encoded logic, and thermal-performance failures were correctly identified.However, the accelerated data collection and assumed performance baselines made the observed performance and reward logic unrepresentative of actual building performance.
- Transaction costs: 460'217'196 total Gas was consumed, with sensor-data transactions accounting for 97% of total transaction costs.The contract creation, case registration, and final payout calculation were the three most expensive individual transactions, but cumulative sensor storage dominated costs.
- Transaction costs: Main-net cost estimates for a six-month deployment depend on Gas and ETH prices at execution time and the prototype’s total Gas consumption.The estimate is based on average historic Gas and ETH prices for the test case.
- Transaction costs: Cost estimates are specific to the Ethereum-based prototype, network state, and implemented contract, so another blockchain or use case could produce significantly different costs.This scope dependence limits direct generalization of the financial-viability assessment.
- Stakeholder feedback: Nine stakeholders viewed automated and verifiable execution positively, but most-mentioned concerns involved changed business relations, fair evaluation criteria, performance baselines, and legal limitations.Digital-twin maintenance, technical security and maturity, and trust in the technical system were the leading technical challenges.
5. Discussion and outlook
The prototype demonstrates the feasibility of connecting digital building twins, sensors, and Ethereum smart contracts for performance-based payments, while exposing substantial scalability, security, incentive, and applicability challenges. The discussion therefore frames the architecture as promising but not yet ready for broad real-world deployment.
- Prototype outcome: The full-stack prototype integrated Ethereum, digital building models, and sensors through the Siemens building twin platform, demonstrating feasibility of the concept and technical architecture.The implemented thermal performance contract also functioned as expected during a two-day test run.
- Blockchain limitations: Public permissionless blockchains face ETH price volatility, network congestion, high Gas prices, throughput, privacy, and transaction-cost challenges for long-term or large-scale contracts.The implementation could also be optimized by reducing on-chain computation and stored data; private permissioned DLTs are suggested for short-term testing.
- Prototype outcome: Performance-contract logic remains preliminary because the workflow and participants were simplified, thermal evaluation needs refinement, and rewards were selected randomly.No appropriate rewards for the business case were calculated.
- Business logic and scope: Fair performance baselines, rewards, measurement rules, external-effect handling, and incentive structures require further research before cross-phase contracts can support valid business cases.The paper also leaves open whether the technology stack applies to all aspects of building performance.
- Data architecture: Storing sensor data on-chain increases transaction costs, privacy risks, and blockchain bloat, motivating designs that calculate metrics off-chain and store only aggregated or Boolean results.The proof of concept reduced stored measurements through randomization, but on-chain data still accumulates over time.
- Data architecture: The building twin simplifies sensor access and data harmonization but introduces dependence on a centralized provider and requires maintenance across all asset life-cycle phases.This dependency currently limits the number of built assets to which the proposed architecture can be applied.
- Implementation requirements: Secure back-end infrastructure and usable front-end applications remain necessary because convenience can trade off against security, redundancy, and socio-technical accessibility.Further security layers are needed to address human-factor risks involving BIM models, twin platforms, sensors, and blockchain.
- Future potential: The proposed approach could support servitized built-environment business cases by transparently recording transactions and automating reward logic for multi-party collaboration.The paper presents this as a potential way to align performance targets with profitable business cases, while token-based reputation or non-monetary rewards remain unassessed.
6. Conclusion
The paper presents blockchain-based smart contracts connected to digital building twins as a way to digitize trusted performance contracts and support life-cycle incentives. A full-stack prototype demonstrates feasibility, while fair performance logic, blockchain scalability, and digital-twin integration remain research challenges.
- Contribution: Blockchain-based smart contracts connected to digital building twins can digitize performance contracts and link crypto-economic incentives to life-cycle performance.The combination is proposed to support trusted, scalable performance-based use cases and new built-environment-as-a-service business models.
- Demonstration: A full-stack proof-of-concept implemented a thermal performance-based smart contract using Ethereum, Siemens building-twin technology, and sensors from a real-world building.The prototype demonstrates feasibility of the concept and technical architecture.
- Challenges: Defining fair performance logic, baselines, and payouts is more challenging than coding the smart contract itself.The authors identify performance logic and associated business models as priorities for further research.
- Challenges: Scalable and secure implementation remains constrained by blockchain usability, on-chain data-storage requirements, and the secure interplay between centralized infrastructure and decentralized blockchain.The infrastructure is not yet sufficiently usable to protect stakeholders from setup and interaction errors.
- Challenges: The approach depends heavily on well-developed and maintained digital building twins, which are not often pursued or achieved in industry.This dependence limits current practical readiness.
- Implications: The interplay between blockchain and digital building twins could align incentives for better performance with a smaller environmental footprint while preserving profitable business cases.The paper frames this potential within a trusted peer-to-peer economy and built environment as a service.
7. Author contributions
JH and MM contributed equally, with responsibilities spanning writing, analysis, implementation, and supervision-related work. DH contributed background materials, feedback, and content direction, and all authors finalized and approved the article.
- JH and MM contributed equally to the work.
- JH conducted the writing and data analysis, while MM implemented the code and wrote the master thesis underlying the paper.
- DH contributed performance-contract background, citation materials, feedback, and content direction; all authors finalized and approved the submitted version.
8. Funding
The research received no specific grant funding from public, commercial, or not-for-profit funding agencies.
- The research did not receive any specific grant from public, commercial, or not-for-profit funding agencies.