Programmable payments for industry 4.0: a state channel–based trigger solution

The rise of Distributed Ledger Technology (DLT) is revolutionizing financial systems, introducing innovations such as programmable payments, and allowing Machine-to-Machine (M2M) payments, which are essential for Industry 4.0. Despite their potential, DLT-based financial systems face barriers, including operational efficiency, regulatory uncertainty, limited institutional acceptance, and challenges in integrating with conventional financial systems. Trigger solutions emerge as a promising approach to bridge these gaps by combining the programmability and immutability of DLT systems with the regulatory certainty and established trust of conventional financial systems. This work explores key requirements for trigger solutions to support interoperability between DLT-based and conventional financial systems, enabling high-frequency programmable payments and regulatory compliance for industry 4.0. We present a state channel–based trigger solution (SCTS) tailored to meet industry’s requirements, offering a blueprint for integrating advanced payment capabilities into conventional financial systems. SCTS leverages the concept of justified trust-building on technological advantages to enable scalable programmable payments. We find that SCTS enables businesses to adapt to the technological demands of Industry 4.0.

1 Introduction

The emerging digital economy refers to a heterogeneous economy of diverse participants, e.g., IoT devices, digital entities, software agents running in the cloud, and humans that can enter binding agreements and execute business transactions (Poddey and Scharmann, 2019).

The rapid evolution of digital payment systems supporting the emerging digital economy, driven by Distributed Ledger Technology (DLT), is reshaping the financial landscape toward open finance. In these open financial systems, the digital representation of value and programmable value transfers (i.e., payments) are essential components for enabling seamless and efficient economic transactions. As a result, conventional financial systems and industry stakeholders are increasingly disrupted by DLT-based financial systems (Schwarzer et al., 2022). The emergence of crypto-assets, stablecoins, and other types of digital money enables programmable payments, fostering automation in value transfer (Bechtel et al., 2022). These advancements allow participants to automate processes such as Machine-to-Machine (M2M) transactions, which are highly anticipated by industry stakeholders for use cases in Industry 4.0. However, DLT-based financial systems also face significant challenges, including regulatory uncertainty, a lack of standards, and limited institutional adoption. This underscores the strategic importance of developing future financial systems that enable states to maintain their sovereignty in an increasingly globalized world (Schwarzer et al., 2022; Balz, 2021).

Discussions around central bank digital currencies further underscore the shift towards digitization in financial services. The development of open finance frameworks, such as those advocated by the European Union, highlights the need for interoperability and openness within financial systems. However, it is unclear how recent advancements will integrate with conventional financial systems to support use cases within Industry 4.0 (Zachariadis and Ozcan, 2017).

Trigger solutions seem promising for ensuring seamless interoperability, mitigating risks, and fostering trust across conventional and emerging financial systems. They are technical bridges that connect DLT-based systems with conventional financial systems, allowing the automatic initiation (triggering) of payments in the conventional financial systems, using them as a medium for transaction settlement (Mridul et al., 2024). By automatically executing payment processes upon predefined conditions, trigger solutions facilitate programmable payments. Trigger solutions combine the technical advantages of DLT-based systems while building on the extant accountability and regulatory certainty of conventional financial systems, thereby providing a trusted environment to its users—a concept we refer to as justified trust. Trigger solutions can facilitate DLT-based transactions (e.g., micro-transactions, state updates) by building on conventional financial systems, addressing regulatory requirements, and supporting the adoption of programmable payments across various industry sectors.

Existing trigger solutions, such as those by the German Bundesbank, are limited to wholesale use, meaning they are tailored for the needs of financial institutions rather than industry applicants (Deutsche Bundesbank, 2024). Increasing globalization and competition in Industry 4.0 accelerate the adoption of advanced technologies such as M2M payments. Companies that fail to adapt to these innovations risk losing their competitive edge to more agile competitors. In response to this, private entities, such as Tether (Tether, 2024) and Circle (Circle, 2024), have begun developing (unregulated) payment systems tailored to the requirements of industrial applications. While offering flexibility, these solutions risk fragmenting payment ecosystems, hindering standardization, interoperability, and widespread adoption across sectors (Fliche et al., 2023).

To mitigate these challenges, a more inclusive and open approach to developing trigger solutions is necessary, one that bridges the gap between the requirements of financial institutions and the business needs of industry stakeholders.

To support the development of trigger solutions suitable to the industry’s needs, we approach the following research questions:

1. What are key requirements for trigger solutions to enable programmable payments in Industry 4.0?

2. What are the key characteristics of a trigger solution design that meets industry’s needs?

To answer the research questions, we apply a three-step research approach. First, we gathered an overview and identified conceptual gaps through a comprehensive review of existing trigger solutions and developed a preliminary concept of our state channel–based trigger solution. The second phase involved the identification of industry key requirements derived from the expert interviews. The final phase focused on refining the trigger solution through successive rounds of expert interviews. This refinement continued until no further improvements were suggested (Myers, 2013).

The primary purpose of this work is to support the development and adoption of programmable payments for Industry 4.0, by offering a trigger solution that can bridge the gap between DLT-based and conventional financial systems. In particular, this work has the following main contributions: First, we present a requirements catalog of 11 key business, technical, and regulatory requirements for designing trigger solutions in Industry 4.0, providing a foundation for future developments. Second, we explain the foundational concept of justified trust to better understand how trigger solutions leverage conventional financial systems and how they can increase widespread adoption of programmable payments. Third, we present SCTS, a state channel–based trigger solution design with three core layers, offering flexibility and incremental adoption aligned with industry’s needs and technological advancements. Lastly, we address practical design decisions, including token standard compatibility (e.g., ERC20, ERC721), to enhance the adaptability and usability of trigger solutions for diverse industrial applications.

Our proposed trigger solution offers a regulation-compliant, transitional pathway that can be implemented in the short term, enabling industry stakeholders to integrate DLT-based operations within a regulated environment. By combining the advantages of decentralized technologies with established payment systems, we aim to provide the necessary flexibility for further evolution alongside the regulatory framework.

2 Distributed ledger technology, programmable payments, and trigger solutions

The following section systematically introduces the key concepts and building blocks in a structured manner, providing readers with a clear understanding of trigger solutions and programmable payments.

2.1 Distributed ledger technology

Distributed Ledger Technology (DLT), including blockchain technology, is a key enabler of programmable payments in open financial systems. DLT provides a decentralized infrastructure that allows for secure, transparent, and immutable recording of transactions (Kirste et al., 2023). DLT can help standardize processes related to digital payments by offering a shared and unified infrastructure that ensures consistency in transaction processing and reconciliation across different payment service providers (Lamberty et al., 2024).

One of the fundamental features of DLT systems is the ability to execute programmable logic through smart contracts. These are self-executing contracts with the terms of the agreement directly written into code, securely embedded within the DLT system (Kannengießer et al., 2020). Smart contracts facilitate programmable payments by automating transactions based on predefined rules or conditions (Kannengiesser et al., 2021). When specific conditions are met, the smart contract automatically triggers the payment, eliminating the need for intermediaries and reducing the potential for human error or fraud. This capability transforms conventional payment processes by introducing conditional logic that can handle complex financial arrangements (Schwartzbach, 2020).

The immutability and transparency of smart contracts in DLT systems ensure that once a smart contract is deployed, its logic cannot be altered, and all parties involved can verify the contract’s terms and the execution of payments (Kannengiesser et al., 2021). This builds trust among participants and enhances the security and reliability of financial transactions.

2.2 Scaling distributed ledgers

Naive application of DLT does not inherently provide cost and time efficiency. Therefore, the scalability of DLTs is an inherent problem that must be overcome. Payment, state, and generalized state channels are promising approaches designed to minimize the number of required on-chain interactions. An overview of generalized state channels is provided by reference (Dziembowski et al., 2018; Coleman et al., 2018). These state-of-the-art approaches enable secure and trustless, off-chain interactions, ensuring security and dispute resolution by anchoring critical transactions on the DLT.

Exemplary state channel implementations include hash time-locks (Poon and Dryja, 2016; Miller et al., 2019), ForceMove (Close and Stewart, 2018), and Perun (Dziembowski et al., 2019b). Extensions to state channels can increase on-chain efficiency and allow for multi-party interactions, enabling broader applicability and scalability. (Dziembowski et al., 2019a; Close, 2019).

State channels collectively facilitate secure off-chain transactions, significantly reducing costs and delays while ensuring trusted settlement. State channel implementations integrate seamlessly with DLT systems while addressing scalability and performance challenges.

2.3 Programmable payments

Conventional Real-Time Gross Settlement (RTGS) systems like TARGET2, have historically served as the cornerstone of global financial markets, ensuring transaction reliability, safety, and operational robustness. Such conventional financial systems operate within an established trust framework built on legal systems, regulatory oversight, and institutional guarantees, providing users with a high degree of confidence and predictability in executing and recording financial transactions (Dupont and Karpoff, 2020).

However, these systems operate within centralized and often fragmented architectures, characterized by high operational costs, batch processing, and reliance on multiple intermediaries for clearing and settlement (IMF, 2023). These limitations hinder their ability to adapt to the growing demand for programmable payments enabling real-time, seamless, and cost-efficient financial transactions (Mancini-Griffoli, 2024).

In emerging digital economies, the digital representation of value and programmable value transfers are crucial for enabling seamless and efficient economic transactions. Digital value representation refers to the digitization of assets, currencies, and other forms of value, allowing them to be stored, transferred, and managed electronically (Lamberty et al., 2023). Programmable payments enable transactions to be automated based on predefined rules or conditions, thereby creating secure and efficient economic ecosystems (GFMA, 2023). They involve conditional logic, enabling complex rules and conditions to govern when and how payments are made. This increases payment efficiency by streamlining processes, eliminating intermediaries, and reducing transaction times and costs. When implemented through smart contracts, programmable payments also increase transparency security allowing all parties to view the terms and conditions embedded in smart contracts.

Programmable payments enable programmable forms of money, which integrates rules directly into the currency to govern or constrain its functionality (Morgan, 2024). Each digital currency unit is embedded with its own rules and conditions for use, allowing it to operate autonomously and adapt to a wide range of applications. Programmable money represents a subset of digital money (e.g., digital euro), which is typically recognized as a central bank-backed store of value with legal tender status. Digital money is distinct from crypto-assets (e.g., Bitcoin), which refer to a broader range of non-central bank-backed representations of value (European Union, 2023).

2.3.1 Implementation of programmable payments

Programmable payments have been implemented through various approaches, both within DLT systems and in conventional financial systems. In non-DLT environments, programmable payment systems rely on centralized infrastructures, such as automated clearing houses, to schedule and execute payments. Services like PayPal (PayPal Inc, 2024) and Stripe (Stripe Inc, 2024) integrate programmable features within traditional payment infrastructures, allowing for automated transactions based on predefined conditions (Zachariadis and Ozcan, 2017).

In DLT systems, smart contracts are utilized to automate payments on blockchain platforms (Kannengießer et al., 2020). Ethereum’s ERC-20 token standard, for example, enables the creation and transfer of tokens on the Ethereum blockchain, facilitating programmable payments through self-executing contracts (GFMA, 2023). Enterprise-grade frameworks like Hyperledger allow programmable payments to be integrated into larger business networks, enhancing efficiency and transparency (BWCon, 2023).

2.3.2 Applications of programmable payments

The potential applications of programmable payments are vast and transformative. One example is machine-to-machine (M2M) transactions, where fully automated payments occur between devices, such as an electric vehicle independently paying a charging station without human intervention. This automation facilitates settlement without requiring manual intervention, increasing efficiency while minimizing risks, delays, and operational costs (Lamberty et al., 2023).

Usage-based consumption is also significant, involving direct payments based on consumption or usage. An example is a leased manufacturing machine calculating the cost of individual usage units and independently processing the related payments. Other applications include supply chain automation, where automated payments occur upon fulfillment of contractual obligations, enhancing efficiency in supply chain management. Insurance claims processing benefits as well, with automatic disbursement of funds when specific events occur, such as natural disasters triggering insurance payouts (Deutsche Bundesbank, 2021).

2.4 Trigger solutions

Trigger solutions, sometimes referred to as payment adapter or payment extension, have emerged as a vital mechanism for bridging DLT-based systems and conventional financial systems (European Central Bank, 2024). The term trigger, in its narrower sense, refers to the automatic initiation of transactions based on predefined conditions. Trigger solutions enable the automatic execution of value transfers in conventional financial systems based on predefined conditions or events occurring within a DLT environment, facilitating programmable payments across platforms (European Central Bank, 2024; Bank for International Settlements, 2022). For instance, the German Bundesbank has investigated integrating wholesale Central Bank Digital Currency (wCBDC) with its RTGS system, TARGET2, to combine the strengths of DLT with traditional financial infrastructure. Despite their promise, such integrations face challenges related to divergent technical architectures and regulatory frameworks (Deutscher Sparkassen- und Giroverband DSGV, 2021). Trigger solutions address these issues as an interim approach, enabling the adoption of programmable payments while bridging the gap between these distinct systems, thereby facilitating interoperability and enhancing the programmability and efficiency of financial transactions.

Common implementations of trigger solutions monitor events on a DLT system and initiates corresponding actions in the conventional financial system (Deutscher Sparkassen- und Giroverband DSGV, 2021). For example, when a smart contract condition is fulfilled on a blockchain, the trigger solution is able to detect this event and triggers a payment through established conventional financial systems. This approach allows organizations to leverage the benefits of DLT and smart contracts enabling programmable payments without requiring all parties to transfer the value with cryptographic assets in the DLT system.

This allows trigger solutions to process transaction logic and initiation within the DLT environment, leveraging smart contracts for automation and programmability, while actual value transfer is settled through conventional financial systems. This integration enables organizations to benefit from the advantages of DLT, such as immutability and programmability, while anchoring the settlement within the regulated and secure framework of conventional financial systems (Deutsche Bundesbank, 2024).

2.4.1 Implementations of trigger solutions

The Deutsche Bundesbank Trigger Solution enables the settlement of DLT-based wholesale financial transactions using central bank money by bridging DLT platforms with the Eurosystem’s TARGET2 RTGS infrastructure. Their trigger solution prioritizes interoperability between existing financial systems to provide a compliant and efficient settlement mechanism for financial institutions (Deutsche Bundesbank, 2024). Technically, the Deutsche Bundesbank Trigger Solution uses advanced hash time-locks to enable atomic settlement of DLT-based securities and TARGET2 cash transfers to minimize counterparty risks. However, the Deutsche Bundesbank Trigger Solution heavily relies on nodes hosted by Deutsche Bundesbank to govern the operation of the system.

The DLT2Pay solution by GFT exemplifies an innovative approach to bridging DLT networks and traditional banking systems (GFT, 2024). A pre-defined token type, called “PaymentOrderToken,” functions similarly to a digital payment instruction. DLT2Pay enables seamless payment processing via SEPA, TARGET2, and SWIFT. This ensures compatibility with conventional accounting practices and regulatory requirements. However, its limitations, such as latency and lack of support for real-time streaming payments, highlight ongoing challenges in enabling fully integrated, Industry 4.0 use cases (GFT, 2024).

While practical trigger solutions exist for demonstration purposes, each has distinct design trade-offs in architecture, scalability, target audience and adoption feasibility. The Deutsche Bundesbank Trigger Solution ensures strong compliance with TARGET2, but its reliance on central bank accounts creates limitations in the target audience (i.e., wholesale user). DLT2Pay, developed by GFT, introduces a tokenized payment order model to bridge DLT and banking networks, but its batch processing approach lacks real-time streaming support, which limits Industry 4.0 applications.

2.4.2 Related work on trigger solutions

The development of trigger solutions to bridge DLT-based and conventional financial systems aligns with ongoing innovations in digital ecosystems and emerging technologies. Recent studies highlight the integration of DLT and smart contracts to enhance payment processes but significant gaps in addressing industrial requirements (Bechtel et al., 2022).

Mridul et al. (2024) have developed a DLT-based framework to enhance the efficiency and security of cross-border payments through the use of smart contracts, while aligning with international standards (e.g., ISO20022). They emphasize automation and compliance, but they give limited attention to promoting interoperability across various financial ecosystems (Mridul et al., 2024). Other works delve into technical challenges and propose solutions tailored to specific use cases. Flynn et al. designed a cross-language system for data integration in decentralized finance (DeFi) but lacks compliance with financial standards (Flynn et al., 2023).

Luo et al. (2019) propose a blockchain-based framework that automates payment triggers through smart contracts (Luo et al., 2019). Their work highlights the importance of formalizing trigger conditions into executable logic and leveraging blockchain for transparency in the construction industry. This means, their proposed solution is tailored to linear, milestone-based payment structures typical in construction projects, which do not fully translate to more dynamic and high-frequency payment environments seen in Industry 4.0.

3 Methodology

The methodology applied in this work involved a series of semi-structured expert interviews designed to refine and validate our proposed trigger solution design for programmable payments in Industry 4.0. Participants were selected through a broad network of professionals with deep expertise across economic, technical, and regulatory domains related to financial systems and Industry 4.0.

The interviewees comprised senior professionals from banking, consulting, and industrial sectors, ensuring a high level of domain expertise and familiarity with both, DLT-based and conventional financial systems. All participants possessed at least 5 years of professional experience in their respective domains. This diversity enabled a comprehensive and multifaceted validation of our design. Table 1 provides an overview of the interviewees’ backgrounds.

Table 1

Table 1. Overview of expert interviewees.

The development of our trigger solution design followed a three-step research process. First, we identified conceptual gaps through a comprehensive review of existing trigger solutions and developed a preliminary concept based on the state-channel architecture (Bryman, 2012). This phase focused on programmable payments, emphasizing industrial applications and operational efficiency. The second phase involved the identification of industry key requirements derived from expert interviews (Bryman, 2012). The final phase focused on refining the trigger solution through successive rounds of expert feedback. This refinement continued until no further improvements were suggested (Myers, 2013; Mayring, 2014).

Semi-structured interviews were selected for their flexibility, balancing structured questions with open-ended exploration to foster in-depth discussions (Myers and Newman, 2007). This approach supported identifying key requirements and validating conceptual frameworks, adhering to qualitative research best practices (Bryman, 2012). The method allowed participants to express nuanced needs and constraints while critically evaluating our trigger solution design.

A semi-structured interview guide was developed to facilitate the interviews, following established practices in qualitative research (Bryman, 2012; Myers, 2013). The guide consisted of five parts. In the first part, we introduced the interviewees to the research project and obtained their consent to record the interview. In part two, we clarified the technological background and concepts used in this work. In the third part, we focused on the gathering of key requirements for trigger solutions. Then, we presented our trigger solution concept and details on the state channel architecture in the fourth part. Finally, the fifth part of the interview focused on validating the feasibility of the proposed solution by guiding open-ended discussions. This allowed us to refine the conceptual architecture (Myers, 2013).

Feedback from each interview was systematically documented and analyzed to refine the trigger solution (Mayring, 2014). In total, eleven expert interviews were conducted and each expert interview took about 55 min on average.

During the first two interviews, the core concept of using state channels to facilitate high-frequent and efficient transactions was generally well-received, though participants emphasized areas of refinement. Both interviewees emphasized the importance of minimizing collateral requirements. They suggested that depending on the trust level between contracting parties, the trigger solution could primarily serve as a bookkeeping mechanism on the blockchain rather than requiring large upfront collateral deposits. This feedback led to the incorporation of a negotiation phase, enabling users to mutually agree on the under-collateralization of state channels depending on the established trust between both transacting parties. Therefore, the state channels function as an efficient bookkeeping mechanism, significantly reducing the capital intensity of the trigger solution.

Feedback from the fourth and fifth interviews focused on the necessity of supporting various tokenized assets for collateralization, including different stablecoins and other tokenized asset representations, such as non-fungible token. Six of our experts suggested leveraging stablecoins to reduce volatility related to genuine cryptocurrencies, even if they’re solely used for collateralization. As a result, the refined design incorporated mechanisms for handling multiple currencies.

The later interviews addressed risk mitigation strategies for payment settlement. Two experts recommended extensions through insurance models to hedge against payment defaults if transacting parties agreed on an under-collateralization. This feedback led to the enhancement of new stakeholders in the process, such as insurance companies providing the collateral for users, ensuring a more capital-efficient solution.

Ultimately, we reached the ending condition after 11 interviews as the interviewees in the last three interviews did not mention additional criticisms and improvements related to our trigger solution.

4 State channel–based trigger solution (SCTS)

Our proposed state channel-based trigger solution (SCTS) operates as a bridge between DLT-based systems and conventional financial systems (e.g., SEPA, Target2). Our design leverages smart contracts and state channels on a DLT to facilitate high-frequency micro-transactions and accounting and integrates into the conventional financial system for actual value transfers (i.e., settlement). The solution leverages the ISO 20022 messaging standard, utilizing established formats such as pain.001, pain.002, and camt.054 to ensure seamless interoperability and compliance with conventional banking processes. The proposed design enables innovative payment models for Industry 4.0.

4.1 Trigger solution requirements catalog

We gathered and aggregated requirements for trigger solutions through a structured qualitative content analysis of expert interviews (Mayring, 2014). Using a coding process, recurring themes and patterns were identified and organized into three categories: Business Requirements, Technical Requirements, and Regulatory Requirements. This systematic approach ensures thorough coverage of all essential aspects while aligning with industry expectations (Mayring, 2014).

4.1.1 Business Requirements

• [R-BU1] Programmable Payments: The system must support programmable payments, such as streaming payments and pay-per-use models, to foster innovative business applications. This requirement allows dynamic, condition-based pricing structures that align payments with real-time usage, which directly contributes to business innovation.

• [R-BU2] Cost-Effectiveness: The system shall reduce transaction fees, operational costs, and processing expenses for low-value, high-frequency transactions to encourage adoption and ensure economic competitiveness compared to existing payment systems.

• [R-BU3] Multi-Currency Support and Plurality: The system must support transactions involving multiple types of currencies, including fiat (USD, EUR) and cryptocurrencies (BTC, ETH), as well as alternative value units represented digital assets.

• [R-BU4] Usability and Adoption: The system shall offer a seamless onboarding process to reduce barriers to adoption and simplify operational complexity. This includes integration with existing enterprise systems, such as ERP and CRM, to ensure compatibility with established workflows without disrupting existing processes.

• [R-BU5] Information Protection: The system shall protect sensitive business information to prevent third-party analysis of payment behaviors.

4.1.2 Technical requirements

• [R-TE1] Smart Contracts and Programmability: The system must implement smart contract functionality to automate and execute payments based on predefined conditions, such as flexible payment intervals or event-driven triggers. This requirement highlights the technical mechanisms necessary to realize automated payments, reduce manual intervention, improve process accuracy, and ensure automated transactions.

• [R-TE2] Performance and Scalability: The system must efficiently process low-value, high-frequency transactions to guarantee high transaction throughput with low latency. It should scale effectively to accommodate increasing business demands and ensure high availability and minimal downtime.

• [R-TE3] Interoperability and Integration: The system must integrate seamlessly with enterprise infrastructure (e.g., ERP, CRM, and conventional financial systems like SEPA) as well as banking interfaces such as EBICS. This ensures compatibility with established payment workflows, minimizes disruptions, and leverages existing resources for efficient financial operations.

• R-TE4] Confidentiality: The system shall implement mechanisms for securing sensitive transaction data to protect confidentiality.

4.1.3 Regulatory requirements

• [R-RE1] Regulatory and Legal Compliance: The system must comply with all relevant financial regulations and legal frameworks to maintain operational integrity and mitigate legal risks.

• [R-RE2] Auditability: The system must ensure immutable transaction tracking to support dispute resolution and adhere to regulatory standards.

4.2 Technical overview

4.2.1 Architecture of the state channel–based trigger solution

The trigger solution consists of three layers. First, the banking layer with the conventional financial system that is used to settle payments, utilizing the existing payment systems (e.g., SEPA, Target2). Second, the DLT layer which implements the custodian contract, that is a trusted anchor for all users in the system. Third, the state channel layer which consists of peer-to-peer state channels between users of the trigger solution.

4.2.1.1 Banking layer

The foundational banking layer represents the conventional financial systems, making use of established payment networks such as SEPA, Target2 or SWIFT to settle transactions in established fiat currencies. By operating within the regulated financial system and well-regulated procedures, this layer provides a trusted and compliant mechanism for executing and recording payments.

Governmental institutions regulate the banking layer, fostering trust among users who believe in the government’s oversight (Dupont and Karpoff, 2020). We refer to this established trust framework as justified trust within the banking layer. This is crucial, as it provides legal certainty in corporate environments, fostering broader adoption and reducing the risks associated with emerging payment technologies.

4.2.1.2 DLT layer

The DLT layer implements the custodian contract, which serves as both, a trustworthy intermediary and a dispute resolution mechanism, as a smart contract running on a DLT.

The custodian contract serves as a central component of our trigger solution and takes custody of the deposited funds between the transacting users. Once deployed, the contract’s code cannot be altered (Kannengiesser et al., 2021), nor can deposited funds be accessed by external parties, ensuring trustless interactions between participants. Upon successful business completion, payment settlement is executed through conventional payment systems, while both users’ staked funds are held in custody for potential dispute resolution if the settlement through conventional payment systems fails.

A notable feature of the custodian contract is its role as an adjudicator, capable of resolving disputes that may arise during execution. In the event of a disagreement, the contract can mediate by evaluating predefined conditions and chained cryptographic proofs provided by the disputing users, ensuring a fair and unbiased resolution process. This built-in dispute resolution mechanism strengthens trust in the system while reducing reliance on external arbitration.

The custodian contract acts as both a custodian and an adjudicator minimizing the required trust of users into other users or their banks. By enabling decentralized, automated dispute resolution, it aligns with the requirements for secure financial transactions.

4.2.1.3 State channel layer

The state channel layer enables efficient off-chain, peer-to-peer exchanges of value between participants. State channels allow users to conduct high-frequency transactions without incurring on-chain fees or latency for every interaction. Periodically, these off-chain states are reconciled to the DLT layer, ensuring that disputes and final settlements can be resolved in a trust-minimized and verifiable manner.

In environments where trust between participants is already established, the state channel layer can function purely as a bookkeeping mechanism. In such cases, transactions are recorded within the state channel without the need for full collateralization. This mechanism reduces the capital intensity typically associated with state channels.

The state channels in the trigger solution are capable of executing smart contract code, allowing users to execute programmable payments in the state channel. By combining the stability and compliance of conventional financial systems with the programmability and efficiency of state channels, our trigger solution design supports fast and cost-effective programmable payments for industrial use cases.

4.2.2 Negotiation and initialization

The initialization of the custodian contract (see Figure 1) between two or more users begins with the negotiation of contract terms (Step 0). During this phase, users mutually define key parameters of the state channel, such as the funding rate, type of collateral, collateralization ratio, and the settlement interval in the banking layer. These agreed-upon parameters are securely stored in the custodian contract, serving as a reference in case a dispute resolution becomes necessary. Once the parameters for the custodian contract have been agreed upon, either user can proceed to start the instantiation of the state channel (Step 1). Following the instantiation, each participant is required to deposit their designated collateral into the custodian contract (Step 2). The custodian contract securely holds this collateral, ensuring its availability for dispute resolution scenarios, should they arise. After both users have successfully deposited their agreed collateral into the custodian contract, the custodian contract fully instantiates the state channel (Step 3). Afterwards, the state channel becomes active and users can start to transact using the state channel.

Figure 1

Figure 1. Negotiation and initialization of the custodian contract.

4.2.3 Economic interaction and high-frequency transactions

The transacting users engage in economic activities, where the state channel enables high-frequency off-chain transactions. In addition, the state channel serves as a high-frequency bookkeeping mechanism that records value transfers between users. Users can then update the state channel and begin executing high-frequency off-chain transactions. Each transaction transitions the state channel to a subsequent state, enabling efficient and seamless updates without the need for on-chain interactions for every individual transaction (Step 4 in Figure 1). The state channel is settled and reverted in intervals as agreed between the users using the conventional financial system in the banking layer. The settlement mechanisms are described in the following.

4.2.4 Settlement and re-balancing

The high-frequency bookkeeping state channels are settled in accordance with the terms specified in the custodian contract and agreed upon by the users. The settlement process is depicted in Figure 2.

Figure 2

Figure 2. Settlement and external re-balancing via banking layer.

To settle and rebalance the state channel to its initial state, User A, who is in debt in this scenario, initiates a bank payment $m_A$ at Bank A to transfer the outstanding amount to User B’s account at Bank B (Step 1). Typically, this is facilitated via a pain.001 message sent by User A to instruct the payment. Bank A acknowledges receipt of the payment instruction by signing and sending a pain.002 status message, providing confirmation of processing or acceptance and leading to the signed message $m_{A,BA}$. This acknowledgment is then sent to User A and, optionally, to User B as well (Step 2).

To rebalance the state channel, User A creates a new state transition and appends the counter-signed payment message $m_{A,BA}$ to the state channel record (Steps 3 and 4), resulting in state update $N+1$ which has equal balances as state 0 in the initialization phase (see Figure 2).

After Bank B confirms receipt of the payment from Bank A, it counter-signs the bank payment message (e.g., via CAMT.054), resulting in $m_{A,BA,BB}$, which serves as a confirmation of the successful fund transfer (Step 5). Next, User B signs the state channel update initiated by User A and appends $m_{A,BA,BB}$, completing the rebalancing process of the state channel (Step 6). Finally, after the successful external fund transfer, the two transacting users can continue to engage in high-frequency off-chain transactions (Step 7).

4.2.5 Dispute resolution

In our trigger solution design, the custodian contract plays a central role in dispute resolution by leveraging chained cryptographic proofs submitted by transacting users and banks. Any user can initiate a dispute resolution process by submitting the latest state of the state channel to the custodian contract and requesting settlement. The custodian contract verifies whether any user has outstanding settlement obligations. If such obligations exist, the indebted user is granted a predefined timeout period to either provide a more recent state of the state channel or submit verifiable proof of executing the required settlement. Once the timeout expires or both users provide their latest state and settlement proof, the custodian contract utilizes the most recent state of the state channel provided and resolves the outstanding amounts by liquidating the collateral of the indebted user. This approach ensures the enforceability of settlements while maintaining the integrity of the dispute resolution process.

In the first scenario for dispute resolution, depicted in Figure 3, user A acts maliciously by refusing to settle the state channel through the banking layer (Step 2). As a result, user B does not receive the expected payment and subsequently submits the current state of the state channel to the custodian contract, requesting settlement by claiming the corresponding portion of user A’s collateral (Step 3). Upon initiation of this dispute process, user A is allocated a predefined timeout period within which they must either provide a more recent state of the state channel or submit verifiable proof of having executed the settlement transaction $m_{A,BA}$ (Step 4). In this instance, user A, having denied settlement, is unable to provide the required transaction proof or an updated state. Consequently, the custodian contract forcibly terminates the state channel (Step 5) and resolves the outstanding obligation by transferring the appropriate portion of user A’s collateral to user B (Step 6). This mechanism ensures the integrity and enforceability of settlements despite user misconduct.

Figure 3

Figure 3. Dispute resolution–Scenario 1.

In the second scenario, depicted in Figure 4, User B fraudulently asserts that they did not receive the payment. Initially, User A executes the settlement (Step 2), obtains the signed transaction confirmation $m_{A,BA}$ (Step 3), and updates the state channel to state $N+1$ (Step 4). User B, however, denies this update (Step 5.1) and dishonestly initiates settlement enforcement through the custodian contract by submitting state $N$. Upon receiving this claim, the custodian contract initiates the dispute resolution process and allocates a timeout period for User A to provide verifiable proof of settlement or a more recent state of the state channel (Step 6). User A responds by submitting state $N+1$ along with the settlement proof $m_{A.BA}$, confirming that the bank executed the payment (Step 7). The custodian contract then validates $m_{A,BA}$ via standardized banking interfaces (e.g., EBICS) to confirm the authenticity of the payment execution (Step 8). Based on the verified outcome, the custodian contract finalizes the state channel at state $F$ (Step 9). Since User A successfully executed the payment, the state channel can be closed without requiring the use of collateral for forced settlement, ensuring integrity and accountability in the dispute resolution process. The state channel is closed by clearing and returning any remaining collateral to respective users.

Figure 4

Figure 4. Dispute resolution–Scenario 2.

4.3 Requirements mapping

To validate our proposed state channel–based trigger solution design, we map its functionality against the gathered requirements (Palomares et al., 2021). Below, we describe how our proposed design satisfies the business, technical, and regulatory requirements.

4.3.1 Business requirements

• [R-BU1] Cost-Effectiveness: The proposed trigger solution reduces transaction fees compared to conventional financial systems. This is achieved through leveraging state-of-the-art implementations of state channels for scaling to enable cost-efficient micro-transactions.

• [R-BU2] Programmable Payments: Our trigger solution achieves programmable payments by leveraging smart contracts and state channels to encapsulate transaction rules and conditions directly. Programmability is achieved through the integration of smart contracts that encode the specific rules and conditions governing the payment process. These conditions may include milestones, time delays, or external data inputs provided by trusted oracles. Within the state channel, these rules are executed off-chain, enabling iterative or conditional interactions without incurring the costs and latency associated with on-chain transactions.

• [R-BU3] Multi-Currency Support and Plurality: The trigger solution achieves multi-currency compatibility by employing a modular architecture capable of supporting diverse tokenized assets, including fungible (e.g., ERC-20, ERC-777) and non-fungible tokens (e.g., ERC-721). This is ensured through a whitelist of supported tokens.

• [R-BU4] Usability and Adoption: The trigger solution promotes usability and adoption by aligning with existing systems, workflows, and standards, such as ERP platforms, bookkeeping guidelines, and ISO 20022. This combination of standards alignment addresses usability challenges and fosters adoption.

• [R-BU5] Information Protection: The architecture of the trigger solution prioritizes data confidentiality by anchoring sensitive transaction data on the respective state channel layer while only essential information is reconciled on the public DLT. Additionally, state channel technology ensures that transactional details remain private between the involved users, reducing exposure to third-party observation. This dual-layered design aligns with industry needs for secure and compliant data management.

4.3.2 Technical requirements

• [R-TE1] Smart Contracts and Programmability: The proposed trigger solution leverages smart contract technology to automate payment processes and execute programmable payments. By embedding payment logic directly into the DLT and state channel layer, the system ensures that transactions are executed based on pre-defined criteria, reducing the need for manual oversight. This enables use cases such as dynamic payment intervals, usage-based payments, and automated dispute resolution, significantly enhancing operational efficiency.

• [R-TE2] Performance and Scalability: The trigger solution addresses performance bottlenecks by utilizing generalized state channels to process low-value, high-frequency transactions off-chain. This approach minimizes latency and transaction fees, as only the final settlement states are anchored on-chain. With the capacity to handle transaction throughput exceeding 100,000 TPS (Dziembowski et al., 2018), the solution ensures exceptional performance and scalability, making it ideal for industrial environments.

• [R-TE3] Interoperability and Integration: A core design principle of the trigger solution is its seamless integration with existing enterprise infrastructure, such as ERP systems. This interoperability is facilitated through standardized APIs and data exchange formats, such as EBICS and ISO 20022 standards, allowing for real-time synchronization of payment data across systems. This enables the interoperability with various DLT and conventional financial systems.

• [R-TE4] Confidentiality: The trigger solution ensures confidentiality through a multi-layered security approach. Sensitive transaction data is primarily processed within the state channel layer, which maintains privacy by conducting all high-frequency transactions off-chain. Only aggregated state updates are periodically anchored on the DLT layer, minimizing data exposure while ensuring immutability and verifiability. Furthermore, the banking layer adheres to strict confidentiality protocols and secure data transmission standards (e.g., TLS and encryption). By combining off-chain processing, cryptographic anchoring, and secure banking protocols, the design effectively safeguards sensitive information, preventing unauthorized access or observation. This approach aligns with modern confidentiality demands, providing trust and security for all users involved.

4.3.3 Regulatory requirements

• [R-RE1] Regulatory and Legal Compliance: Compliance with regulatory frameworks can be embedded at every layer of the trigger solution. Most important, the banking layer ensures that the actual value flows, all fiat-based settlements, are conducted in the banking layer through fully-regulated conventional financial systems (e.g., TARGET2, SEPA). Smart contracts deployed on the DLT layer are designed to reflect contractual agreements that adhere to national and international legal requirements and standards (e.g., AML, CFT), reducing the risk of regulatory breaches.

• [R-RE2] Auditability: Auditability is achieved through bilateral off-chain transaction recording and on-chain cryptographic anchoring. State channels generate cryptographic proofs (e.g., signed transactions) stored securely and periodically hashed. Instead of detailed on-chain data, an aggregated state hash ensures privacy while providing an immutable anchor for verifying transaction history. The custodian contract validates state hashes against chained cryptographic proofs during disputes or compliance reviews, ensuring integrity without accessing individual transaction details.

In conclusion, our proposed trigger solution effectively addresses the business, technical, and regulatory requirements essential for facilitating secure, efficient and scalable programmable payments. This mapping highlights the applicability and effectiveness of the concept, positioning it as a viable bridge between decentralized DLT environments and centralized conventional financial systems.

5 Discussion

This work presents SCTS, a state channel–based trigger solution designed to address the unique demands of Industry 4.0. By bridging DLT and conventional financial systems, SCTS facilitates secure and efficient programmable payments. In the following, we discuss our principal findings, point out the main contributions and limitations of this work, and outline future research directions.

5.1 Principal findings

This study uncovers pivotal insights into the domain of trigger solutions, demonstrating their practical relevance and their role in bridging DLT systems with conventional financial systems.

We find that the domain of trigger solutions remains predominantly driven by practical, industry-led initiatives rather than academic research. This underscores the need for trigger solutions to address real-world challenges and bridge gaps in programmable payments and conventional financial systems. The rise in industry interest highlights the relevance of trigger solutions as a transitional mechanism within evolving digital economies, paving the way for further academic exploration.

We observe that programmable payments emerge as a cornerstone for the next-generation of industrial applications, particularly in the context of Industry 4.0 and open finance. Their ability to automate high-frequency, condition-based payments is recognized by industry stakeholders as essential for enabling advanced use cases, such as pay-per-use, delivery-vs-payment (DvP) and machine-to-machine (M2M) transactions. However, these use cases impose stringent requirements on transaction throughput and operational efficiency.

We recognize that state channels, as a scaling mechanism, exhibit both significant potential and inherent limitations. They are effective in facilitating cost-efficient, high-frequency micro-transactions but are constrained by their capital intensity. The refinement process of SCTS identified flexibility in the degree of collateralization (e.g., via under-collateralization) as pivotal for adoption. Feedback suggested that state channels could operate primarily as a bookkeeping mechanism in scenarios with high trust between transacting users, significantly reducing capital intensity of state channels. This would also decrease potential delays caused by the settlement through conventional financial systems.

Finally, we observe that while SCTS adheres to messaging standards that facilitate interoperability with conventional financial systems, regulatory compliance remains an important area requiring further attention. For instance, Basel III—a global banking regulatory framework—imposes capital reserve requirements that could significantly influence how deposits are managed within the (under-) collateralized state channels utilized by SCTS (King and Tarbert, 2011).

These findings underscore the necessity for continued interdisciplinary research to optimize and expand the adoption of trigger solutions in industrial applications.

5.2 Contributions

This work makes four contributions to the field of trigger solutions.

First, we highlight practical design decisions of trigger solutions, such as the acceptance of token standards (e.g., ERC20, ERC721), which expand the adaptability of trigger solutions by supporting diverse collaterals. This guides practitioners in developing flexible and usable trigger solutions suitable for various industrial applications.

Second, by leveraging the concept of justified trust, we help practitioners understand theoretical concepts utilized in trigger solutions. Applying this concept creates a more rigorous understanding of trigger solutions and how they bridge the gap between DLT systems and conventional financial systems while preserving regulatory certainty.

Third, we present a structured requirements catalog including 11 key business, technical, and regulatory requirements for trigger solutions in Industry 4.0, as detailed in Section 4.1. This catalog serves as a foundation for designing trigger solutions that can combine the cost-efficiency and scalability with the compliance and reliability of conventional financial systems.

Fourth, by proposing SCTS, we extend the trigger solution design space. Our trigger solutions design consists of three core layers (Banking layer, DLT layer, and state channel layer), prioritizing flexibility and enabling corporations to adopt and evolve their use of trigger solutions incrementally. This helps researchers get a broader view of trigger solution designs that meet market demands and leverage technological advancements (e.g., in light of commercial bank money tokens or central bank digital currencies).

Through these contributions, our work provides a robust framework for implementing trigger solutions and establishes a pathway for enabling programmable payments tailored to the needs of Industry 4.0. By leveraging DLT-based mechanisms such as smart contracts and state channels, the design facilitates seamless integration with regulated, conventional financial systems, fostering scalability and operational feasibility for innovative industrial use cases.

5.3 Limitations and future work

While the proposed trigger solution demonstrates significant potential in bridging DLT-based systems and conventional financial systems, certain limitations remain. The state channel layer allows for high-frequency bookkeeping and aggregating settlement. The rebalancing of state channels through settlement in conventional financial systems is less suited for singular micro-transactions (e.g., below 1 cent). Therefore, users must optimize rebalancing intervals to reduce cost caused by the settlement through the conventional financial system.

SCTS allows industry players to leverage programmable payments while relying on the compliance and regulatory certainty of the conventional financial system. However, SCTS requires users to deposit their collateral in the form of tokenized assets, requiring its users to hold digital representations of value, which could introduce new risks and require adoption. Additionally, the state channel’s reliance on collateral within may raise concerns about capital efficiency. Exploring mechanisms such as insurance- or bank-collateralized state channels could improve liquidity management and reduce the possible adoption barriers for participants.

Scalability and interoperability pose additional challenges, particularly when integrating with diverse DLT ecosystems. While SCTS adopts token standards to enhance adaptability, variations in protocol design and technical infrastructures require continuous adjustment.

Finally, global adaptability can be improved by developing frameworks for seamless cross-border multi-currency support, including native central bank digital currencies and emerging tokenized assets (e.g., commercial bank money tokens). Collaboration with regulators and industry stakeholders will also be critical in evolving compliance mechanisms to support broader adoption.

6 Conclusion

This work presents a scalable state channel–based trigger solution (SCTS) designed to bridge the capabilities of programmable payments enabled through DLT and conventional financial systems, while addressing the requirements of Industry 4.0 applications. SCTS combines the programmability, scalability, and cost-efficiency of DLT-based state channels with the reliability, regulatory compliance, and usability of conventional financial systems. By leveraging interoperable frameworks and standardized messaging protocols, such as ISO 20022, SCTS ensures seamless integration in conventional financial systems, leveraging their widespread trust and operational efficiency.

By presenting SCTS, we contribute to the advancement of modern financial infrastructures that bridge the gap between emerging DLT systems and established financial infrastructures. We envision SCTS as a foundational step toward enabling programmable, real-time, and cost-efficient payments to the demands of automated, high-frequency environments characteristic of Industry 4.0.

SCTS provides a robust framework for future research and development, paving the way for the adoption of DLT-driven innovations in financial ecosystems.

Data availability statement

The original contributions presented in the study are included in the article/supplementary material, further inquiries can be directed to the corresponding author.

Ethics statement

Ethical approval was not required for the studies involving humans because this study did not require formal ethical approval as it did not involve research with human subjects in the sense of medical, psychological, or personally sensitive data collection. Instead, we conducted expert interviews with professionals in their respective fields, discussing study-relevant topics within their area of expertise. The interviewees participated voluntarily, provided consent and were aware that their insights would contribute to a academic study. No personal, sensitive or private data was collected. Therefore, ethical approval from an institutional review board was not deemed necessary in accordance with the research guidelines. The studies were conducted in accordance with the local legislation and institutional requirements. The participants provided their written informed consent to participate in this study.

Author contributions

RL: Conceptualization, Supervision, Writing – original draft, Writing – review and editing. DK: Writing – original draft, Writing – review and editing. AP: Conceptualization, Writing – review and editing.

Funding

The author(s) declare that no financial support was received for the research and/or publication of this article.

Conflict of interest

Authors RL, DK, and AP were employed by the company Robert Bosch GmbH.

The remaining authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Generative AI statement

The author(s) declare that no Generative AI was used in the creation of this manuscript.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

References

Balz, B. (2021). Digital payments and European sovereignty. Available online at: https://www.bundesbank.de/resource/blob/926812/4f3552a2a4be80d567c76f65aef1960c/mL/process-description-data.pdf (Accessed 11 November 2024).

Google Scholar

Bank for International Settlements (2022). Options for access to and interoperability of cbdcs for cross-border payments. Available online at: https://www.bis.org/publ/othp52.pdf (Accessed 17 October 2024).

Google Scholar

Bechtel, A., Ferreira, A., Gross, J., and Sandner, P. (2022). “The future of payments in a DLT-based European economy: a roadmap,” in The future of financial systems in the digital age (Springer), 89–116. doi:10.1007/978-981-16-7830-1_6

CrossRef Full Text | Google Scholar

Bryman, A. (2012). Social research methods. Oxford: OUP.

Google Scholar

BWCon (2023). Dlt-based credit and compensation system for open-source resources. Available online at: https://www.bwcon-research.org/fileadmin/user_upload/Startseite/1_Ueber_uns/1_die_bwcon_Gruppe/bwcon_research_gGmbH/DLT-Based_Credit_and_Compensation_System_for_Open-Source_Resources.pdf (Accessed 17 October 2024).

Google Scholar

Circle (2024). USD coin (USDC). Available online at: https://www.circle.com (Accessed 28 November 2024).

Google Scholar

Close, T. (2019). Nitro protocol. Available online at: https://eprint.iacr.org/2019/219 (Accessed 01 December 2024).

Google Scholar

Close, T., and Stewart, A. (2018). Forcemove: an n-party state channel protocol. Available online at: https://magmo.com/force-move-games.pdf.

Google Scholar

Coleman, J., Horne, L., and Xuanji, L. (2018). Counterfactual: generalized state channels. Available online at: https://www.bgp4.com/wp-content/uploads/2019/05/statechannels.pdf (Accessed 28 November 2024).

Google Scholar

Deutsche Bundesbank (2021). Digitales Geld: Optionen für den Zahlungsverkehr. Available online at: https://www.bundesbank.de/resource/blob/864372/8dd7e83c9ce700c93693dc0c061ffd51/mL/2021-04-digitales-geld-data.pdf (Accessed 21 November 2024).

Google Scholar

Deutsche Bundesbank (2024). Trigger solution. Available online at: https://www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/trigger-solution/trigger-solution-927660 (Accessed 23 November 2024).

Google Scholar

Deutscher Sparkassen- und Giroverband (DSGV) (2021). Europe needs new money – an ecosystem of cbdc, tokenised commercial bank money and trigger solutions. Available online at: https://die-dk.de/media/files/20210625_DK_Ergebnisdokument_DE_mrCkDI3.pdf (Accessed 28 October 2024).

Google Scholar

Dupont, Q., and Karpoff, J. M. (2016). The Trust Triangle: Laws, Reputation, and Culture in Empirical Finance Research. Journal of Business Ethics. 163. doi:10.1007/s10551-019-04229-1

CrossRef Full Text | Google Scholar

Dziembowski, S., Eckey, L., Faust, S., Hesse, J., and Hostáková, K. (2019a). “Multi-party virtual state channels,” in Annual international conference on the theory and applications of cryptographic techniques.

Google Scholar

Dziembowski, S., Eckey, L., Faust, S., and Malinowski, D. (2019b). “Perun: virtual payment hubs over cryptocurrencies,” in IEEE symposium on security and privacy (SP).

Google Scholar

Dziembowski, S., Faust, S., and Hostáková, K. (2018). “General state channel networks,” in Proceedings of the 2018 ACM SIGSA Conference on Computer and Communications Security, New York, NY, USA: Association for Computing Machinery, 949–966. doi:10.1145/3243734.3243856

CrossRef Full Text | Google Scholar

European Central Bank (2024). Modernising finance: the role of central bank money. Available online at: https://www.ecb.europa.eu/press/key/date/2024/html/ecb.sp240209∼d481464c19.en.html (Accessed 17 October 2024).

Google Scholar

European Union (2023). Regulation (EU) 2023/1114 of the European parliament and of the council of 31 may 2023 on markets in crypto-assets, and amending regulations (EU) No 1093/2010 and (EU) No 1095/2010 and directives 2013/36/EU and (EU) 2019/1937.

Google Scholar

Fliche, O., Uri, J., and Vileyn, M. (2023). Decentralised’ or ’Disintermediated’ finance: what regulatory response? Available online at: https://acpr.banque-france.fr/sites/default/files/medias/documents/20230403_decentralised_disintermediated_finance_en.pdf (Accessed 14 November 2024).

Google Scholar

Flynn, C., Bennett, K. P., Erickson, J. S., Green, A., and Seneviratne, O. (2023). Enabling cross-language data integration and scalable analytics in decentralized finance. Available online at: https://arxiv.org/abs/2311.02272 (Accessed 17 December 2024).doi:10.1109/bigdata59044.2023.10386383

CrossRef Full Text | Google Scholar

GFMA (2023). Impact of distributed ledger technology on global capital markets. Available online at: https://www.gfma.org/wp-content/uploads/2023/05/impact-of-dlt-on-global-capital-markets-full-report.pdf (Accessed 17 December 2024).

Google Scholar

GFT (2024). DLT to pay: solutions for payments based on distributed ledger technology. Available online at: https://www.gft.com/de/de/solutions/dlt-to-pay (Accessed 28 November 2024).

Google Scholar

IMF (2023). Target2 and global financial systems: challenges and opportunities. Available online at: https://www.elibrary.imf.org/downloadpdf/journals/002/2011/223/article-A001-en.pdf (Accessed 18 November 2024).

Google Scholar

Kannengiesser, N., Lins, S., Sander, C., Winter, K., Frey, H., and Sunyaev, A. (2021). Challenges and common solutions in smart contract development. IEEE Trans. Softw. Eng. doi:10.1109/TSE.2021.3116808

CrossRef Full Text | Google Scholar

Kannengießer, N., Lins, S., Dehling, T., and Sunyaev, A. (2020). Trade-offs between distributed ledger technology characteristics. ACM Comput. Surv. 53, 1–42. doi:10.1145/3379463

CrossRef Full Text | Google Scholar

King, P., and Tarbert, H. (2011). Basel iii: an overview. Bank. Financial Serv. Policy Rep. 30, 1–18.

Google Scholar

Kirste, D., Kannengießer, N., Lamberty, R., and Sunyaev, A. (2023). How automated market makers approach the thin market problem in cryptoeconomic systems. doi:10.48550/arXiv.2309.12818

CrossRef Full Text | Google Scholar

Lamberty, R., Kirste, D., Kannengießer, N., and Sunyaev, A. (2024). Hybcbdc: a design for central bank digital currency systems enabling digital cash. IEEE Access 12, 137712–137728. doi:10.1109/ACCESS.2024.3458451

CrossRef Full Text | Google Scholar

Lamberty, R., Poddey, A., Galindo, D., de Waard, D., Koelbel, T., and Kirste, D. (2023). Efficiency in digital economies – a primer on tokenomics. doi:10.48550/arXiv.2008.02538

CrossRef Full Text | Google Scholar

Luo, H., Das, M., Wang, J., and Cheng, J. C. (2019). Construction payment automation through smart contract-based blockchain framework. ISARC. Proc. Int. Symposium Automation Robotics Constr. 36, 1254–1260. doi:10.22260/ISARC2019/0170

CrossRef Full Text | Google Scholar

Mancini-Griffoli, T. (2024). G-20 note on financial platforms: what are they and what are their macro-financial implications? Available online at: https://www.imf.org/external/pubs/ft/g20/financial_platforms.pdf (Accessed 14 November 2024).

Google Scholar

Mayring, P. (2014). “Qualitative content analysis: theoretical foundation, basic procedures, and software solution,” 2nd edn. Cham: Springer.

Google Scholar

Miller, A., Bentov, I., Bakshi, S., Kumaresan, R., and McCorry, P. (2019). “Sprites and state channels: payment networks that go faster than lightning,” in International conference on financial cryptography and data security.

Google Scholar

Morgan, J. P. (2024). Programmable payments and purpose-bound money. Available online at: https://www.jpmorgan.com/onyx/programmable-payments-purpose-bound-money (Accessed 30 December 2024).

Google Scholar

Mridul, M., Gupta, A., Chang, K., and Seneviratne, O. (2024). Smart contracts, smarter payments: innovating cross-border payments and reporting transactions. arXiv, 1–8. doi:10.1109/cifer62890.2024.10772792

CrossRef Full Text | Google Scholar

Myers, M. D. (2013). Qualitative research in business and management. SAGE Publications.

Google Scholar

Myers, M. D., and Newman, M. (2007). The qualitative interview in is research: examining the craft. Inf. Organ. 17, 2–26. doi:10.1016/j.infoandorg.2006.11.001

CrossRef Full Text | Google Scholar

Palomares, C., van Meulen, I., Herrmann, A., Mendez, D., Franch, X., and Gorschek, T. (2021). The state-of-practice in requirements elicitation: an extended interview study at 12 companies. Requir. Eng. 26, 273–299. doi:10.1007/s00766-020-00345-x

CrossRef Full Text | Google Scholar

PayPal Inc (2024). Paypal: online payment services. Available online at: https://www.paypal.com (Accessed 12 April 2024).

Google Scholar

Poddey, A., and Scharmann, N. (2019). On the importance of system-view-centric validation for the design and operation of a crypto-based digital economy. Available online at: http://arxiv.org/abs/1908.08675 (Accessed 12 October 2024).

Google Scholar

Poon, J., and Dryja, T. (2016). The bitcoin lightning network: scalable off-chain instant payments. Available online at: https://lightning.network/lightning-network-paper.pdf (Accessed 18 November 2024).

Google Scholar

Schwartzbach, N. I. (2020). An incentive-compatible smart contract for decentralized commerce. Available online at: https://arxiv.org/abs/2008.10326 (Accessed 14 October 2024).

Google Scholar

Schwarzer, M., Gürpinar, T., and Henke, M. (2022). To join or not to join? A framework for the evaluation of enterprise blockchain consortia. Front. Blockchain 5, 935346. doi:10.3389/fbloc.2022.935346

CrossRef Full Text | Google Scholar

Stripe Inc (2024). Stripe: online payment processing for internet businesses. Available online at: https://www.stripe.com (Accessed 12 November 2024).

Google Scholar

Tether (2024). Tether: the world’s most trusted stablecoin. Available online at: https://tether.to (Accessed 28 November 2024).

Google Scholar

Zachariadis, M., and Ozcan, P. (2017). The api economy and digital transformation in financial services: the case of open banking. Available online at: https://swiftinstitute.org/wp-content/uploads/2017 (Accessed 20 December 2024).

Google Scholar