This paper presents Block-Timer, a layer-optimized approach for executing BPMN processes with time constraints on blockchain networks. Time-bound activities are core components of business processes, representing regulatory deadlines and service level agreements. While blockchain technology ofers transparency and trustless coordination for process execution, implementing time constraints on blockchain presents significant technical challenges. Traditional blockchain platforms rely on vulnerable block timestamps, while executing complex processes entirely on Layer 1 faces economic and throughput limitations. We propose a conceptual hybridsolution where a block-number-based implementation of timer events ensures secure, manipulation-resistant, time tracking without external dependencies. Our solution automatically translates BPMN processes with timer events into executable smart contracts, with a comparative analysis of execution costs between Ethereum (Layer 1) and Arbitrum (Layer 2) across three diverse case studies. The analysis reveals that Layer 2 implementation reduces operational costs compared to Layer 1 while maintaining functional equivalence. Based on these findings, we propose an hybrid architecture that strategically distributes process operations between layers according to security requirements and cost considerations. This approach optimizes the balance between security guarantees and economic feasibility for blockchain-based business process execution, particularly for multi-party workflows requiring both trust and eficiency. Our security analysis confirms the integrity of the block-based timer implementation with no critical vulnerabilities, demonstrating a conceptual solution for time-constrained process execution on blockchain networks.
Business Process Model and Notation (BPMN) has emerged as the standard for modeling organizational
workflows, providing a graphical representation that bridges the gap between process design and
implementation [
Meanwhile, blockchain technology ofers important capabilities for business process execution
through immutable record-keeping, transparent operations, and trustless coordination between
participants [
However, implementing time constraints on blockchain presents significant technical challenges
[
While Layer 2 scaling solutions like Arbitrum significantly reduce transaction costs through optimistic
rollups, they introduce diferent security assumptions such as delayed finality through fraud-proof
mechanisms rather than immediate consensus, and potential vulnerability to validator collusion [
This paper presents an approach that addresses these challenges through a block-number-based implementation of timer events that ensures secure, manipulation-resistant time tracking without relying on external time services. We automatically translate BPMN processes with timer events into secure, executable Solidity smart contracts, along with a comparative analysis of execution costs between Ethereum (Layer 1) and Arbitrum (Layer 2) across three diverse case studies. From this analysis, we propose a conceptual hybrid architecture that strategically distributes process operations between Layer 1 and Layer 2 based on security requirements and cost considerations.
Our approach was validated through the implementation of three diferent BPMN case studies: a municipal document request process, an insurance policy application workflow, and an academic examination process. Each case demonstrates diferent patterns of timer event usage and inter-participant coordination. We provide a complete replication package including all the case study BPMN codes, the Java code of the automatic translator and the translated three smart contracts at this link to support reproducibility and verification.
The remainder of this paper is organized as follows: Section 2 provides background on blockchain time mechanisms and BPMN integration approaches. Section 3 details our methodology for block-based timer implementation and smart contract generation. Section 4 presents the implementation results and cost analysis across diferent blockchain layers. Section 5 introduces our proposed hybrid architecture. Section 6 discusses assumptions and threats of our study and section 7 implications, limitations, and concludes with future research directions.
Blockchain technology has emerged as a support for collaborative business processes among mutually
untrusting parties in decentralized environments. Recent research has developed several model-driven
approaches to implement business processes on blockchain platforms using standardized process
modeling notations, particularly BPMN. Di Ciccio et al. [
Time management is a challenge in blockchain-based systems due to the decentralized and
asynchronous nature of blockchain networks. Several approaches have been proposed to address these
points. Eichinger and Ebermann [
Several research eforts have explored the use of blockchain in multi-party processes, each contributing complementary insights into how operations can be classified and distributed across architectural layers for decentralized execution.
Argento et al. [
A complementary perspective is proposed by Alfarisy [
Further abstraction is explored by Pirani et al. [
Finally, the work in [
Together, these studies afirm the importance of categorizing blockchain-enabled operations not only by their functional scope, but also by their positioning across trust, orchestration, and abstraction layers. This classification is important for enabling scalable and maintainable process execution in decentralized environments.
Our research methodology combines BPMN process modeling with blockchain implementation on both Layer 1 and Layer 2 networks, focusing on secure and eficient timer event handling. This section details our approach to process modeling, smart contract generation, security verification, and cost analysis.
We created three representative BPMN collaboration diagrams using Camunda Modeler, each featuring diferent timer event patterns and multi-participant interactions. The first case study is a citizenmunicipality interaction for a document request process with 30-day and 15-day processing deadlines. The second one is a policyholder-insurer application workflow with 5-day and 7-day decision deadlines. The third application is a three-party (professor-student-secretary) workflow with 15-day evaluation and 7-day decision deadlines. Each process was designed to capture common time-constrained business scenarios while providing suficient complexity to validate our approach across various timer patterns and participant configurations.
We developed an automated BPMN-to-Solidity transformation tool that generates blockchain-executable smart contracts from BPMN diagrams. Our transformation approach employs a block-based timer implementation. Rather than using timestamp-based mechanisms, our approach converts ISO duration formats (e.g., "P30D" for 30 days) into block numbers. According to Ethereum network statistics 1, since October 2022, the daily average block time has maintained a consistent 12-second interval, providing a stable foundation for our time calculations. This stability allows us to reliably estimate that one day corresponds to approximately 7200 blocks (24 hours * 3600 seconds / 12 seconds per block). This conversion uses the formula: blockEstimate = days * 7200 blocks day
Arbitrum does not maintain a fixed block time like Ethereum. However, according to Ofchain Labs, the average latency of Arbitrum One blocks is around 250 milliseconds 2 3.
This approach provides resistance to miner manipulation of timestamps, a deterministic execution without relying on external time oracles, and a consistent timing across network conditions.
The generated contracts implement a state machine that tracks each BPMN element’s lifecycle through three states: DISABLED, ENABLED, and DONE. Element dependencies are enforced through state checks, ensuring process integrity.
Moreover, each function includes participant validation based on Ethereum addresses mapped to BPMN participants, ensuring that only authorized participants can execute their designated tasks.
Finally the generated contracts incorporate OpenZeppelin’s security patterns, including ReentrancyGuard, Ownable, and Pausable, providing protection against common attack vectors and administrative control mechanisms.
We implemented a two-stage security verification process. First, each generated contract underwent automated vulnerability detection using Slither [18], a static analysis framework that identifies common smart contract vulnerabilities including reentrancy, integer overflow/underflow, and access control issues. Then we supplemented the Slither analysis with custom checks specifically designed for timerbased operations, including verification of proper access controls for timer functions, analysis of block number manipulation risks, assessment of dependency enforcement mechanisms and validation of participant address handling.
These security measures ensured that the generated contracts maintained process integrity while addressing blockchain-specific vulnerabilities. All contracts passed both the Slither analysis and our custom security checks with zero critical vulnerabilities detected.
We deployed each smart contract on both Ethereum Sepolia Testnet (Layer 1) and Arbitrum Sepolia Testnet (Layer 2) using Remix IDE and MetaMask. For each contract, we executed the complete process flow, recording gas consumption for every operation. To provide a realistic cost assessment, we collected daily gas price data from Etherscan4 and Arbiscan5, along with cryptocurrency price data from CoinGecko67, over a one-month period (March 14 - April 13, 2025). We then calculated median gas price and the median cryptocurrency price and the standard deviation. We found for Ethereum 0.6350 ± 1.1438 Gwei and $1,887.76 ± 167.64, instead for Arbitrum 0.0174 ± 0.1042 Gwei and $0.33397 ± 0.03893.
This methodology provides a robust cost estimation that accounts for market fluctuations while avoiding outlier-driven distortions. By using median values rather than means, we established a realistic operational cost baseline for blockchain-based process execution across diferent layers.
This section presents our implementation of three case studies and the comparative cost analysis between Layer 1 and Layer 2 blockchain networks. The BPMN codes of the case studies, the Java code of the automatic translator and the translated three smart contracts are available at this link.
We implemented three distinct BPMN processes, each selected to represent diferent timer event patterns and multi-participant scenarios common in real-world applications.
The first case study in Figure 1 implements a municipal document request process between a citizen and municipality. This process includes a 30-day primary processing window and a 15-day extension period when additional processing time is needed. The workflow begins with a completeness check that creates an initial decision point, followed by document processing with enforced regulatory deadlines. This case study demonstrates how timer events ensure compliance with administrative procedures and service level agreements.
The second case study in Figure 2 models an insurance policy application process between a policyholder and an insurance company. This workflow includes two timer events: a 7-day proposal deadline for the insurance company to prepare a policy proposal and a 5-day decision deadline for the policyholder to sign the policy. The process includes decision points that create alternative paths depending on the completeness of the application and the policyholder’s acceptance decision. This case study demonstrates timer events that govern both organizational and customer-facing deadlines.
Finally, the third case study in Figure 3 represents an academic examination process involving three participants: professor, student, and secretary. This complex workflow features multiple timer events, including a 7-day registration period, a 15-day deadline for professors to evaluate exams, and a 7-day deadline for students to accept or reject their grades. The process also includes an auto-acceptance mechanism if no decision is made within the specified timeframe. This case study demonstrates how timer events can coordinate activities among multiple participants with interdependent responsibilities.
Each BPMN model was transformed into a Solidity smart contract using our automated conversion tool. The transformation process preserved the timer event semantics by implementing them as blocknumber-based mechanisms rather than traditional timestamp approaches. The generated smart contracts included security features from OpenZeppelin, participant role management, and comprehensive audit logging to track process execution.
We deployed each smart contract on both Ethereum Sepolia Testnet (Layer 1) and Arbitrum Sepolia Testnet (Layer 2) to analyze performance and cost diferences.
Function/Action Gas Used ETH Cost (USD) ARB Cost (USD) Contract Creation
startEvent() sendRequestToMunicipality()
receiveRequest() gatewayAction("CheckRequest")
elaborateRequest() f30DaysDeadlineForDocumentDelivery() gatewayAction("CheckDocuments")
sendDocuments() documentsReceived() sendFeedback()
Similar patterns emerged in the insurance policy application process (Table 2), where contract deployment required 5.2 million gas units ($6.24 on Ethereum, $0.0302 on Arbitrum). The timer functions for the 7-day proposal deadline and 5-day sign deadline consumed approximately 133,300 gas units each, equivalent to $0.16 on Ethereum and $0.00078 on Arbitrum.
The academic examination process, with its increased complexity and participant count, showed comparable per-operation gas consumption (Table 3) but higher cumulative costs due to the greater number of process steps. Contract deployment required 5.0 million gas units ($6.04 on Ethereum, $0.029 on Arbitrum), while individual operations ranged from 111,000 to 176,000 gas units.
Function/Action
Gas Used
ETH Cost (USD)
ARB Cost (USD)
Our analysis reveals that Arbitrum’s Layer 2 implementation reduces operational costs compared to Ethereum’s Layer 1. This dramatic cost reduction maintains the same functional capabilities and security properties while providing significantly better economic feasibility for complex business processes. The cost diference is primarily attributable to two factors: lower gas prices on Arbitrum (median 0.0174 Gwei vs. 0.635 Gwei on Ethereum) and the lower native token value ($0.33397 for ARB vs. $1,887.76 for ETH). While both factors contribute to cost reduction, the gas price diference represents the architectural eficiency of Layer 2 solutions, while token value diferences reflect market conditions. The median operation cost on Ethereum ($0.16-$0.18) would become prohibitive for complex processes with many participants and operations, potentially costing hundreds of dollars for complete process execution. In contrast, the same operations on Arbitrum cost fractions of a cent ($0.00076-$0.00090), making even complex processes economically viable.
Our block-number-based timer implementation demonstrated consistent and predictable behavior across both networks. By converting time durations to block numbers (7,200 blocks per day, assuming 12-second block times), the system created a reliable execution framework that avoided timestamp manipulation vulnerabilities. The gas consumption for timer-related functions remained consistent with other operations, indicating no significant performance penalty for implementing time constraints. This consistency suggests that complex time-dependent business processes can be implemented without disproportionate cost increases for timer management. Security analysis confirmed that our blockbased approach successfully prevented common time-based vulnerabilities. Both automated Slither analysis and custom security checks verified the integrity of the timer implementation, with no critical vulnerabilities detected.
Our comparative analysis of Layer 1 and Layer 2 execution costs reveals a compelling economic case for implementing BPMN processes on Layer 2 networks. However, certain operations may benefit from the stronger security guarantees of Layer 1. This section introduces a systematic framework for distributing process operations between Layer 1 and Layer 2 based on security requirements, economic considerations, and operational characteristics.
We propose a classification framework that categorizes BPMN operations based on three dimensions: security criticality, execution frequency, and data persistence requirements. This framework provides a structured approach to determining the most suitable execution layer for each operation. Security Criticality Assessment: Each operation is evaluated on a security criticality scale based on Table 4.
Financial impact Legal significance Trust requirements
Operations that directly influence financial transactions or asset transfers require the highest security guarantees Operations that create legally binding commitments or satisfy regulatory requirements demand strong immutability guarantees Operations involving multiple participants with limited trust relationships benefit from Layer 1’s stronger consensus mechanisms
Critical state transitions Major state changes that fundamentally alter process status Intermediate state updates Incremental changes that track process progression
Audit information Supportive data primarily used for verification and transparency
Based on the classification framework, Layer 1 primary candidates are process initialization operations that establish core parameters, operations with high financial impact ( <$1000 value transfer), final commitment operations with legal significance and major state transitions that fundamentally alter process status. Layer 2 primary candidates are routine operations with moderate security requirements, frequent status update operations, operations with minimal financial impact and intermediate data collection activities. Borderline cases can be timer events that enforce critical deadlines but have no direct financial impact, decision gateways that influence but don’t directly control asset transfers and operations with moderate legal significance. For borderline cases, we recommend additional assessment of the relative cost diferential between Layer 1 and Layer 2 implementation, the specific security guarantees required by stakeholders and the potential impact of a security compromise.
Our conceptual architecture proposes a multi-contract approach with Layer 1 serving as the authoritative system of record while Layer 2 handles routine operations.
The Layer 1 contract serves as the process anchor, maintaining core process parameters and participant information, critical state variables that define process status, authorization controls for cross-layer synchronization and final state commitments and financial settlements.
The Layer 2 contract handles daily operations, including routine task execution and status tracking, intermediate state updates, timer event monitoring, gateway decision processing and audit trail maintenance.
To maintain process integrity across layers, our framework would require a secure synchronization mechanism. Even if we do not implement this component in the current work, several established approaches from literature could be adapted for this purpose. The events-based architecture described by Bigiotti et al. [19] provides a promising foundation, where watchtowers monitor events from interface smart contracts to coordinate state changes across chains. Their protocol demonstrates how two transactions (one on each chain) can successfully complete cross-chain operations using standardized JSON message formats for event semantics.
Other potential approaches include Merkle-root state commitments for periodic validation [20], message passing protocols like LayerZero [21], and cryptographic proof validation [22] systems similar to those used in optimistic rollups.
The practical implementation of such synchronization mechanisms represents an important direction for future work, as our current focus is on the operation classification framework and on the economic analysis of hybrid approaches.
Layer 1 Operations Layer 2 Operations Process initialization (contract deployment) Request submission and reception Final document delivery confirmation Request elaboration tasks 30-15 days deadline start and end Intermediate status updates Gateway decisions (request completeness verification) Timer event triggers and tracking New operator assignment Feedback collection
This distribution in Table 7 reduces the total process execution cost compared to a pure Layer 1 implementation while maintaining appropriate security guarantees for critical operations. Similar patterns emerge in the insurance application and academic examination processes, with operations involving financial commitments, legal obligations, or final state determinations assigned to Layer 1, while routine coordination activities migrate to Layer 2.
The proposed solution can balance security and cost considerations through strategic operation placement. By executing only the most critical operations on Layer 1, we maintain strong security guarantees where needed while leveraging Layer 2’s cost eficiency for routine operations. For a typical process execution in our municipal document request case study, the hybrid approach reduces costs of a pure Layer 1 implementation while maintaining Layer 1 security for critical operations. This represents a balanced trade-of between the complete security of Layer 1 and the full economy of Layer 2. The architecture’s security properties derive from Ethereum’s underlying consensus mechanism for critical operations, while accepting Arbitrum’s security model for non-critical activities. This tiered approach ensures that operations receive security guarantees proportional to their criticality.
We acknowledge these assumptions, which were selected empirically at the time of the study and can be adjusted in future replications.
While our approach demonstrates promising results in addressing time-constrained execution in blockchain-based workflows, several limitations remain that warrant further attention. However, some important considerations must be acknowledged when interpreting our findings. Our case studies, while diverse, may not represent the full spectrum of business processes and timer event patterns. Additional validation across a broader range of process types and industry domains would strengthen the generalizability of our findings. The block-number-based time conversion assumes a relatively stable block time (12 seconds for Ethereum); however, actual block times can vary due to network conditions, potentially afecting the precision of timer events. Long-term monitoring of timer accuracy across network conditions would provide additional validation. Our cost analysis used median gas prices over a one-month period to provide a realistic baseline. However, gas prices can be highly volatile, particularly during network congestion periods. Cost projections should account for this potential variability. While our synchronization mechanism was conceptually described, a complete implementation and validation of cross-layer communication remains to be developed. The practical reliability of maintaining consistent state across layers requires further empirical validation. The security guarantees of our hybrid architecture rely on the underlying security models of both Ethereum and Arbitrum. Changes to these platforms or their security properties could impact the overall security of the implementation.
This paper presented Block-Timer, an end-to-end evaluation of block-number timers for implementing BPMN process execution with time constraints on blockchain. Our implementation of block-numberbased for timer events ensures secure, manipulation-resistant time tracking without relying on external time services, and the hybrid proposed solution can strategically distributes process operations between Layer 1 and Layer 2 blockchains based on security requirements and cost considerations. Our empirical analysis across three case studies demonstrated that Arbitrum’s Layer 2 implementation reduces operational costs compared to Ethereum’s Layer 1, while maintaining the same functional capabilities. The gas consumption for timer event operations remained comparable to other process operations (approximately 133,000 gas units), indicating no significant performance penalty for implementing time constraints. Although the hybrid architecture is not yet fully implemented, our preliminary evaluation suggests that it strikes a favorable balance between security and cost-eficiency by executing only the most critical operations (process initialization, major state transitions, and legally significant commitments) on Layer 1, while delegating routine operations (status updates, data collection, and timer tracking) to Layer 2. This approach ensures appropriate security guarantees for operations based on their criticality while significantly reducing overall execution costs. Our security analysis confirmed the integrity of the block-number-based timer implementation, with no critical vulnerabilities detected through automated and custom security checks. By converting time durations to block numbers (7,200 blocks per day), our approach provides resilience against timestamp manipulation attacks while creating a deterministic execution framework.
Several promising directions for future research emerge from this work. Implementing and evaluating a synchronization mechanisms between Layer 1 and Layer 2 deserves particular attention, with emphasis on optimizing the balance between security guarantees and operational costs. Extending the block-number-based approach to support more complex timer patterns represents another important direction. This includes recurring timers, calendrical expressions (e.g., "every Monday"), and business day calculations that account for holidays and working hours. By addressing these challenges, future research can further enhance the eficiency, security, and practicality of blockchain-based business process execution, particularly for time-sensitive multi-party workflows where trust and accountability are essential.
This work was partially supported by project SERICS (PE00000014) under the MUR National Recovery and Resilience Plan funded by the European Union-NextGenerationEU.
This work was partially funded by Ministero dell’Università e della Ricerca (MUR), issue D.M. 351/2022 “Borse di Dottorato”—Dottorato di Ricerca di Interesse Nazionale in “Blockchain e Distributed Ledger Technology”, under the National Recovery and Resilience Plan (NRRP).
We acknowledge financial support under the project HALO (Hazard-Analysis and Anti-Counterfeiting Ledger Oriented Protection) CUP F23C23000310008 in the context of Development Regional Program 2020-2024 Strategy 2-Economics Identity Project 2.1 - Technological Research and Innovation.
We acknowledge financial support under the National Recovery and Resilience Plan (NRRP), Mission 4 Component 2 Investment 1.5-Call for tender No. 3277 published on 30 December 2021 by the Italian Ministry of University and Research (MUR) funded by the European Union-NextGenerationEU. Project Code ECS0000038—Project Title eINS Ecosystem of Innovation for Next Generation Sardinia—CUP F53C22000430001-Grant Assignment Decree No. 1056 adopted on 23 June 2022 by the Italian Ministry of University and Research (MUR).
We acknowledge financial support under the project code PE0000021, Concession Decree No. 1561 of 11.10.2022 adopted by Ministero dell’Università e della Ricerca (MUR), CUP - to be indicated by each Beneficiary, according to attachment E of Decree No. 1561/2022, Project title “Network 4 Energy Sustainable Transition – NEST”.
We acknowledge financial support under the National Recovery and Resilience Plan (NRRP), by the Italian Ministry of University and Research (MUR) funded by the European Union-NextGenerationEU. Project Code ECS0000038—Project eINS Ecosystem of Innovation for Next Generation Sardinia—CUP F53C22000430001-Grant Assignment for the PoC “TraCCCS: Tracciabilità, Certificazione Blockchain e Valorizzazione dei Carbon Credits per PMI Sarde con Impianti di Produzione di Energia Rinnovabile”. Declaration on Generative AI: During the preparation of this work, the author(s) used ChatGPT, Grammarly in order to: Grammar and spelling check, Paraphrase and reword. After using this tool/service, the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content. for eficient development of complex multi-party interaction scenarios, Applied Sciences 13 (2023).
URL: https://www.mdpi.com/2076-3417/13/14/8094. doi:10.3390/app13148094. [18] J. Feist, G. Grieco, A. Groce, Slither: A static analysis framework for smart contracts, in: 2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), 2019, pp. 8–15. doi:10.1109/WETSEB.2019.00008. [19] A. Bigiotti, L. Mostarda, A. Navarra, A. Pinna, R. Tonelli, M. Vaccargiu, Interoperability between evm-based blockchains, in: L. Barolli (Ed.), Advanced Information Networking and Applications, Springer Nature Switzerland, Cham, 2024, pp. 98–109. [20] M. Westerkamp, J. Eberhardt, zkrelay: Facilitating sidechains using zksnark-based chain-relays, in: 2020 IEEE European Symposium on Security and Privacy Workshops (EuroSPW), 2020, pp. 378–386. doi:10.1109/EuroSPW51379.2020.00058. [21] R. Zarick, B. Pellegrino, C. Banister, Layerzero: Trustless omnichain interoperability protocol, 2021. URL: https://arxiv.org/abs/2110.13871. arXiv:2110.13871. [22] T. Xie, J. Zhang, Z. Cheng, F. Zhang, Y. Zhang, Y. Jia, D. Boneh, D. Song, zkbridge: Trustless cross-chain bridges made practical, in: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, CCS ’22, Association for Computing Machinery, New York, NY, USA, 2022, p. 3003–3017. URL: https://doi.org/10.1145/3548606.3560652. doi:10.1145/ 3548606.3560652.