Digital Building Twins and Blockchain for Performance-Based (Smart) Contracts

• Actual building energy use can be up to 250% above predictions, with construction quality, operational practices, and monitoring continuity contributing to the performance gap.Source: §1 · p. 1
• AEC fragmentation misaligns incentives across stakeholders and lifecycle phases, producing displaced agency; low-bid tendering favors low initial cost over whole-life savings.Source: §1 · pp. 1–2
• Performance-based contracts tie parties’ profit to operational targets and can align lifecycle incentives through servitization, which also offers producer, customer, and environmental benefits.Source: §1 · p. 2
• Adoption remains limited by accountability, nonstandard performance evaluation, unfamiliar financial concepts, and upfront communication burdens, while owners commonly bear long-term operating risk.Source: §1 · p. 2
• Digital twins can set expectations, measure actual performance, and guide operations, while blockchain can provide transparent records and tamperproof transaction logic; few such contracts have been studied or implemented.Source: §1 · p. 2
• The paper investigates how blockchain-based smart contracts combined with digital building twins could support a transition to a more performance-driven built environment.Source: §1 · p. 3

2.1. Towards a performance-based built environment

• Unlike traditional construction, where owners pay for construction and bear later lifecycle costs, performance-based service payments leave production, operations, maintenance, and disposal with the producer.This aligns incentives to improve performance and minimize lifecycle costs; the simplified model can also apply to technical subsystems, and stakeholder roles may vary.Source: §2.1 · pp. 3–4, Figure 1 · p. 3

2.2. Current practice of performance-based contracts

• Performance contracts can align owner and contractor around agreed baseline performance, but adoption remains slow amid financing, verification, communication, accountability, and business-model barriers.Energy performance contracts can give builders and operators incentives to maintain and improve equipment after installation.Source: §2.2 · p. 4

2.3. Digital Building Twins

• Digital building twins link physical assets and virtual models through IoT data exchange, enabling real-time performance assessment and a data platform for performance-based contracts.BIM models often lack automated physical-digital exchange, while connecting BIM and IoT can update the model to reflect building conditions.Source: §2.3 · pp. 4–5

2.4. Blockchain

• Blockchain provides transparent, immutable transaction records and smart contracts that can automate interactions; performance-based incentives are considered well aligned with blockchain use.The cited construction literature finds blockchain most likely to be needed for new payment or incentive schemes, particularly where participants are unknown or interests are misaligned.Source: §2.4 · pp. 5–6

2.5. State of the art

• Prior prototypes separately explored blockchain-linked digital twins, automated construction payments, and performance smart contracts, but none connected the full stack to incentivize performance across asset life-cycle phases.Examples include a digital-twin prototype without performance contracts, simulated incentives, and an Ethereum energy-performance contract without sensor and twin integration or cross-phase incentives.Source: §2.5 · p. 6

2.6. Research gap and scope of the study

• The study addresses the gap in cross-phase performance contracts by prototyping an Ethereum–Siemens architecture and testing a thermal-performance smart contract with two days of real-building twin sensor data.The paper also discusses challenges and opportunities for performance-based smart contracts and digital building twins in a built environment as a service.Source: §2.6 · pp. 6–7

3. Proposed performance-based smart contract architecture

• The architecture combines a sensor-equipped built asset and interacting human stakeholders in the physical layer with a cyber layer of twin platform, smart contracts, and front- and back-end oracles.Source: §3 · p. 7

3.1. Building twin platform

• The building twin processes and stores sensor live data and stakeholder-created static data, including BIM models, and can map dynamic data to locations in the model.It is hosted on one or multiple cloud servers, where performance simulations are also facilitated.Source: §3.1 · p. 7

3.2. Performance-based smart contracts

• Smart contracts assign roles and permissions, check actual performance against agreed service levels, and execute payouts from escrowed funds when those levels are met.They store relevant user and system addresses, sensor and twin IDs, and external performance data; because oracles cannot establish whether sensor or human inputs are correct, implementations should minimize that risk.Source: §3.2 · p. 8

3.3. Front-end oracle

• The front-end oracle provides a web interface for stakeholder inputs and transfers static information to the blockchain, supporting contract setup, role and address registration, function interactions, and status checks.Without a graphical interface, stakeholders would need to know contract addresses, functions, and parameters.Source: §3.3 · p. 9

3.4. Back-end oracle

• The back-end oracle fetches processed sensor performance data from the digital twin database through APIs, translates it into the required format, and initiates a blockchain transaction.Source: §3.4 · p. 9

4.1. Use Case

• The prototype was tested on Technology Center 2 in Vienna, whose Siemens-platform digital twin monitors and controls the building using sensors.The commercial building has a 5,600 m2 floor area and includes photovoltaic panels, a heat pump, energy storage, and thermally activated building systems.Source: §4.1 · pp. 9–10
• The implemented full-stack system used a front-end oracle for entering contract information and a back-end oracle linking the smart contract to the twin and sensor data.The tested use case was limited to a cross-phase thermal performance contract.Source: §4.1 · p. 10, Figure 5 · p. 10

4.1.1. Incentive Design

• The owner, building contractor, and facility manager agree on a performance target before construction; the owner funds escrow, and the contract pays for target delivery during operation.After construction and setup of the digital twin, the building, sensors, and facility-manager role are registered; the contract is deactivated when no longer needed.Source: §4.1.1 · p. 10

4.1.2. Performance contract

• The exemplary contract leases thermal performance as a service, paying the contractor and facility manager from escrow for agreed performance rather than specifying a finished contract.Its performance evaluation uses common thermal-performance metrics and actual Tz2 sensor data.Source: §4.1.2 · p. 10
• The evaluation measures overall energy consumption and occupant comfort, comparing interval-average energy use with expected consumption and room temperature and humidity with their targets.Tz2 sensor inputs include indoor temperature, relative humidity, CO2, and heating and cooling energy consumption; assessment requires agreed expected energy use, comfort scenario, and CO2 target.Source: §4.1.2 · pp. 10–11
• Thermal comfort uses a simplified predicted mean vote model based on air temperature and relative humidity, because Tz2 does not measure air speed or mean radiant temperature.The logic also compares interval-average CO2 with a target level, often assumed to be below 1000ppm.Source: §4.1.2 · p. 11
• Facility-manager rewards require two of three temperature, humidity, and CO2 targets for full payment; two failed targets yield no reward, with reduced payment between those outcomes.The contractor’s reward depends on total energy performance relative to room-temperature comfort, preventing energy savings through reduced comfort and avoiding contractor failure due to excessive facility-manager heating.Source: Table 1 · p. 11, §4.1.2 · p. 12, Figure 6 · p. 12

4.2.1. Thermal performance smart contract

• The Ethereum contract is written in Solidity and separates role and access management from thermal-performance logic, using Truffle and Ganache for development.The contract inherits OpenZeppelin role and ownership templates; the deployer can assign roles to the building owner, contractor, and facility manager.Source: §4.2.1 · p. 13
• The contract assigns role-based access, records case terms and funded escrow, then evaluates incoming building data and tracks earned payments for redemption.The owner deploying the contract assigns stakeholder roles; the case specifies duration, building, sensors, and performance baseline. Rewards can be redeemed every six months, and the owner can release remaining escrow when the contract ends.Source: §4.2.1 · pp. 13–14
• The front end uses a web form and Web3.js for authorized stakeholder transactions, while a Node.js back-end oracle fetches twin data and submits it using a registered server address.Stakeholders sign actions with MetaMask; the back-end uses Siemens APIs and an access token, and signs transactions with its private key rather than MetaMask.Source: §4.2.1 · pp. 14–15
• Because storing data on-chain raises transaction costs, the implementation randomizes sensor and sampling times, averaging five indoor-environment readings daily and one weekly heating-energy reading.This approach was selected to limit submitted data while addressing manipulation risks; fewer sensors or fixed collection times were also considered but could reduce data diversity or create attack vectors.Source: §4.2.1 · pp. 15–16

4.2.4. Siemens building twin platform

• The Siemens platform combines IFC-based static building information with real-time sensor data in a 3D model and supplies mapped sensor readings to the smart contract.Sensors are linked to BACnet addresses in the IFC files, allowing relevant devices and spaces to be identified and their data fetched from the twin database.Source: §4.2.4 · p. 16

4.3.1. Test Setup

• The test ran on Ethereum’s Rinkeby network for two days with three imaginary stakeholders; 190 thermal-performance measurements per day compressed a six-month measurement interval into the test.Baselines were 45 kWh weekly energy consumption, 21° C set point temperature, 40% relative humidity, and 1000ppm CO2.Source: §4.3.1 · pp. 16–17

4.3.2. Transaction Data

• The prototype stored 1,241 measurements, executed transactions as encoded, and correctly identified thermal failures, but accelerated data collection and baseline assumptions made performance and rewards unrepresentative.The authors state that these results validate the architecture’s feasibility, not actual building performance.Source: §4.3.2 · p. 17
• 460'217'196 Gas were consumed; sensor-data costs accounted for 97% of total transaction costs, despite contract creation, case registration, and final payout being the most expensive transactions.Gas amount is comparable to Ethereum mainnet, whereas the test-network Gas price is not meaningful; Figure 11 shows Gas amounts for the executed transactions.Source: Figure 11 · p. 17, §4.3.2 · pp. 17–18
• 41.33 ETH, or 13’327 USD, was the estimated six-month cost using an 89.8 Gwei average Gas price and 322.5 USD/ETH market price.The estimate depends on Gas and ETH prices at execution, and costs could vary with the blockchain and contract use case.Source: Figure 12 · p. 18, §4.3.2 · p. 18

4.3.3. Stakeholder Feedback

• Stakeholders expressed interest and confidence in the concept, particularly valuing its automated, verifiable approach, but feedback came from a nine-person survey with no statistical significance.The survey also collected perceived benefits and challenges.Source: §4.3.3 · pp. 18–19, Figure 13 · p. 19
• Stakeholders’ main concerns were incompatibility with existing business relations, fair evaluation criteria, accurate baseline simulations, and legal limitations; technical concerns included twin development, security, maturity, and trust.The paper characterizes the nontechnical concerns as general barriers to performance-based building.Source: Figure 13 · p. 19, §4.3.3 · p. 19

5.1. Proof of concept

• The Ethereum proof of concept is feasible, but near-term deployments may favor private permissioned DLTs, while future services involving unknown stakeholders could favor public permissionless systems.The use case combines token payments, automated smart-contract execution, and transparent transaction records. ETH volatility and network congestion can raise Gas costs; stablecoins, future contracts, more efficient code, and reduced on-chain storage are possible responses, but cost suitability for industry adoption needs further assessment.Source: §5.1 · pp. 20–21

5.1.2. Performance-based smart contract

• The two-day test showed the Solidity contract worked as expected, but its preliminary logic, simplified workflow, and arbitrary payouts do not establish a validated performance contract.Further work must establish fair performance baselines and rewards, suitable escrow and penalty rules, reliable measurement, cheating prevention, and treatment of external effects; applicability to all aspects of building performance remains unclear.Source: §5.1.2 · p. 21
• Solidity handled the simple prototype but has limits for advanced calculations, and deployed contracts are difficult to patch without prior governance; security and jurisdiction-specific legal issues require further study.Storing sensor data on-chain increases cost, privacy risks, and blockchain bloat; alternatives range from storing aggregated off-chain calculations to sending only a true/false performance result, trading trust against storage expense.Source: §5.1.2 · pp. 21–22

5.1.3. Digital building twin as external data source

• The building twin eases sensor access, selection, and data harmonization while reducing on-chain storage, but dependence on a maintained twin across asset life-cycle phases limits applicability.Fetching data directly from sensors could reduce twin dependence, but complicates data cleaning and increases on-chain storage demands.Source: §5.1.3 · p. 22
• The back-end oracle is a critical single point of failure, and the twin platform’s convenience entails security and redundancy tradeoffs that may affect system trust.Future work could investigate decentralized server meshes and additional defenses against human-factor risks, including fraud involving BIM models, twin platforms, sensors, or blockchain.Source: §5.1.3 · p. 22

5.1.4. Front-end

• A simple, easy-to-use front end is critical to stakeholder interaction and overcoming socio-technical barriers, while human-factor security risks at the front-end oracle need study.More research should investigate applications that help stakeholders set up and interact with performance-based smart contracts.Source: §5.1.4 · p. 22

5.2. Crypto economic life-cycle incentives for servitization

• The scenario illustrates how cryptoeconomic incentives could align performance targets with profitable service models while saving energy and reducing CO2 emissions.Smart contracts could support transparent, low-bureaucracy collaboration among many parties; unassessed token rewards might also recognize reputation or non-monetary metrics and enable service contracting among anonymous stakeholders.Source: §5.2 · p. 23

6. Conclusion

• The combination could digitize trusted performance contracts, scale built-environment use cases, and link life-cycle performance to crypto-economic incentives that support new business models.The authors also suggest this could align incentives for better performance and a smaller environmental footprint with profitable business cases.Source: §6 · pp. 23–24
• The first full-stack proof of concept demonstrated an exemplary thermal performance-based smart contract using Ethereum, Siemens’ building twin platform, and sensors in a real-world building.The paper describes the technical infrastructure as early-stage and frames its main contributions as identifying challenges for further research.Source: §6 · p. 23
• Defining fair performance logic, baselines, and payouts proved more challenging than coding the contract, making these and associated business models priorities for further research.Stakeholders gave positive feedback on the solution’s potential, but the authors call for more research into the underlying performance logic before wider adoption.Source: §6 · p. 23
• Scalable, secure implementation faces blockchain usability and error-protection gaps, rising costs, and the challenge of reducing on-chain data storage without compromising trust.Costs were reasonable for the tested contract in Ethereum’s early years, but recent price and network-use increases have made them unreasonable for large-scale implementation.Source: §6 · pp. 23–24
• The precise interaction between building twins and blockchain needs further research, and the approach depends on well-developed, maintained twins that are not often achieved in industry.The authors note that secure interaction between centralized infrastructure and the trusted, decentralized blockchain environment is not straightforward.Source: §6 · p. 24

7. Author contributions

• DH contributed contract background, citation materials, feedback, and content direction; all authors finalized and approved the submitted article.MM’s master thesis was written under the supervision of JH and DH.Source: §7 · p. 24

8. Funding

• The research received no specific grant from public, commercial, or not-for-profit funding agencies.Source: §8 · p. 24