
Learnings from ECB Exploratory Phase – Part 2: Review of the HTLC Mechanism
As digital assets and distributed ledger technologies continue to gain momentum, it is crucial to explore how Central Bank Digital Currencies (CBDC) can enhance the functionality, safety, and efficiency of securities settlement. This particularly necessitates the need of scalable and resilient functional patterns to process Delivery-versus-Payment (DvP) which ideally come without the need for new intermediary service providers and with the ability to bridge separated (DLT) infrastructures where asset and cash claims are being managed. One prominent functional mechanism – known has „Hash-TimeLock Contract (HTLC)“ – was tested in many Use Cases intensively during the ECB Exploratory Phase in 2024.
In the first part of our series „Learnings from ECB Exploratory Phase“ we looked at the DLT Infrastructure especially provided by Bundesbank and highlighted the potential for market participants to join those networks via operating an own node. In this second part we examine the functional mechanisms that have been used to conduct a decentralized and functional „Delivery-versus-Payment (DvP)“ of a securities-based transaction where a so-called „Market DLT“ Infrastructure on which asset tokens are being managed is separated from the DLT-based Triggersolution Infrastructure of Bundesbank. We discuss drawbacks of the method used and highlight the advantages of another DvP pattern which we introduced as ERC-7573 and already described in a previous blog article.
Review of Hash-Linked DvP
Delivery-versus-Payment (DvP) is a settlement method that enables to exchange security claims and cash simultaneously and is thus reducing the risk of failure-to-pay or failure-to-deliver. In a DvP based transaction, the buyer’s payment is made once the seller successfully delivers the securities, which can be easily secured by introducing a central intermediary agent. The challenge arises when enabling DvP across two independent Distributed Ledger Technologies (DLTs) on which digial asset and payment tokens reside separately. This was particularly the case in the ECB Exploratory Phase where the payment infrastructure was clearly separated from the so-called „Asset-Chains“ where asset claims are being managed. This introduced the necessity of a solid algorithmic link between both infrastructures. In the following we describe a basic smart-contract based mechanism called „Hash-Linked Swap“. We then review the so-called „HTLC“ Mechanism and discuss the rationale and frictions of this method.
Hash-Linked Swap in a Nutshell
To perform a transfer between two separated DLT-Infrastructures a hash-based functional transaction scheme – called „Hash-Linked Swap“ – is well-known. This schema is completely functional and thus does not require an extra intermediary service: Only the Buyer and the Seller of the Asset Tokens are needed in the transaction while the transaction flow is controlled by two smart contracts, one of those installed on each infrastructure. Linking this transfer via a hash is explained in a nutshell and illustrated in the diagram below: The Seller (Alice) locks some asset token amount on the first infrastructure while placing the condition that this amount will only be transferred to the receiver (Bob) if he is able to provide the secret of the hash. The payer ot the transaction (Bob) – willing to receive the tokens locks the cash amount he is willing to pay on the second infrastructure by using the same public known hash. Now, if Alice claims to retrieve the locked cash she can only do so by revealing the secret of the hash. This triggers the cash-transfer and second enables the buyer to claim the locked tokens by also presenting the now public known secret. The following picture shows the basic transaction pattern between two separated Smart Contracts HLC1 and HLC2 residing on the Asset and Market Chain respectively. The pattern is called „Hash-Linked“ because to claim the cash tokens in the locked contract „HLC2“ the seller needs to release the Secret which the Buyer can use to claim the asset tokens against contract on the Asset Chain „HLC1“.

The Need of a Timelock Component (HTLC)
Above story tells the ‚happy path‘ if both parties act accordingly. But this scheme is problematic: If Bob does not act, Asset Tokens will remain locked in HLC1. If Alice does not act, Cash Tokens remain locked in HLC2. This is why a Time-Out-Component might offer the advantage to force both participants to act within a certain time window – one time window for each Infrastructure. If the time interval on the asset side has passed the locked the tokens will be transferred back to the seller. If the time window on the cash side has passed and the seller did not provide the secret the cash is transferred back to the buyer. Clearly the time window on the cash side needs to be smaller than on the asset side because otherwise an (fraudulent) seller could claim back its asset tokens and also the cash tokens thereafter.
HTLC Mechanism on Bundesbank Triggersolution
The following picture shows the transaction scheme which was used for securities-based experiments and trials on Bundesbank Triggersolution. Interestingly, no participant made use of the possibility to host an own Node on Bundesbank Triggersolution which would have shown advantageous in designing event-driven, full-automated transaction flows – as explained in our first article. Most of the trials which were conducted showed a high level of manual interaction and coordination between the participating parties.

Frictions: The HTLC-Mechanism offers a free option and can be compromised
The time-lock component solves the problem on the unhappy path but introduces new frictions. In the case the buyer cannot claim its asset tokens within the specified time window – e. g. due to technical reasons – the tokens will be transferred back to the seller which in the end would own both. On the other hand the seller has control over the buyer’s liquidity as the seller decides when to lock the asset tokens and also when to claim the cash.
To sum up – the Hash Time Lock Contract (HTLC) scheme:
- introduces a free option: Alice is allowed to collect Bobs cash tokens within a certain time. She is free to choose if or when.
- can be compromised: Bob needs to collect the asset tokens within a certain time, otherwise it goes back to seller. Consider a Denial-Of-Service attack against Bob.
These two frictions leave the parties with an undesirable ‘Trade-Off’: Longer Timeout-Periods increase security but decrease efficiency of this scheme.
An alternative Oracle-Solution for DvP by Banca d’Italia
To resolve this Banca d’Italia introduced an Oracle Solution which replaces the time-lock component with a third-party oracle. This oracle will generate and store two secret keys for the parties: One secret key revealed to the Buyer if the Payment was successful to retrieve the asset tokens and one key revealed to the Seller to reclaim the asset tokens in case the payment fails. The Oracle will publish the respective keys depending on payment success or failure. This proposed oracle-based scheme explicitely does not rely on the existence of cash tokens (so locking of cash is also not needed) and rather assumes a generalistic functional payment pattern. Drawback: The Oracle needs to be involved in each transfer process and is stateful because it needs to generate and hold the keys for each transaction.
ERC-7573: Conditional Encryption for a Smart-Contract based DvP
In our view an oracle-based solution is the only way to overcome the above described frictions. The challenge will be how lightweight the oracle service can be designed without being deeply involved in each single transaction. With ERC-7573 we designed the oracle solution differently with the main aim to keep the oracle service stateless. In ERC-7573 makes use of public-private key encryption. A ‚Decryption Oracle‘ provides its public key for the involved settlement parties to encrypt keys for failure and success and on the other hand it will provide decrypt an encrypted secret by using its private key. This ‚Decryption Oracle‘ does not need to know anything about the transaction itself, it only listens to a dedicated smart contract address where the encrypted key gets emitted from. The following picture illustrates the important functional elements of this protocol.
- An oracle service offers encryption and conditional decryption (upon payment state) without being involved in the transaction and its data
- Buyer and Seller agreed to install a dedicated asset contract and a payment contract one on each infrastructure
- Buyer will encrypt a key for failure, feller will encrypt a secret key for sucess by using the oracle’s public key
- Both parties prepare DvP by calling an ‚incept/confirm transfer‘ functional pattern
- Depending on success or failure the payment contract will request the respective key to be encrypted
- the oracle will decrypt and release the respective key which then can be used by the buyer or seller to claim the locked asset tokens
- Based on this fact only asset tokens need to get locked

Conclusion
To perform Delivery-versus-Payment for a securites-based transaction based on Smart Contracts robust and scalable digital protocol standards are needed. The most prominent used algorithm HTLC shows to have frictions which should be enhanced. ERC-7573 enables to remove the timelock-feature by introducing a lightweight third-pary oracle which could be operated e. g. by the payment infrastructure operator or any other service provider. This seems reasonable since most CBDC infrastructures have the central bank involved in the cash-settlement. In comparison to a centralistic transaction manager which will would be involved in the entire DvP process – especially the unhappy path – the proposed oracle service is very lean in the sense that it only needs to provide a service to decrypt and distribute a key by using it’s private key. The parties will use the oracle’s public key to encrypt failure and success keys which leave both parties to process DvP mostly decentralized and completely functional without being dependent on direct interaction. We are looking forward to enhance and discuss our approach with other market participants – e.g. via Ethereum Magicians.
Diese Themen interessieren uns

Learnings from ECB Exploratory Phase – Part 2: Review of the HTLC Mechanism

Learnings from ECB Exploratory Phase – Part 1
