Use case and innovation

The use case describes the exchange of a digital asset for digital euros. The asset is secured using HTLC. The preimage (key) is only transferred for release after payment.

This mechanism allows zero-trust transactions between parties, with only the DESP acting as a trusted authority. The innovation lies in the combination of existing blockchain mechanisms with the digital euro infrastructure and the use of standardized interfaces for automated payment processing.

Examples of assets that can be stored in an HTLC:

• NFTs (non-fungible tokens)
  • ERC-721 tickets or collectibles
    Example: soccer ticket, concert ticket, digital collectible
  • ERC-1155 assets (multi-token standard, e.g., playable items, divisible rights)
• Tokenized real-world assets
  • Digital proof of ownership (e.g., land registry shares, company shares, digitized stocks)
  • Tokenized invoices or receivables
  • CO2 certificates
• Stablecoins
  • USDC, USDT, EURC, DAI – important for atomic swaps, for example, when price certainty is desired
• Rights/access keys
  • Access tokens to closed platforms or events
  • Software licenses as NFTs
  • Streaming/subscription access as tokens
• Wrapped assets
  • wBTC, wETH, etc. – i.e., tokenized versions of coins on a different chain
• Cryptocurrencies
  • Bitcoin (on Bitcoin itself via script, e.g. in atomic swaps)
  • Ethereum (ETH)
  • Tokens according to the ERC20 standard (e.g. USDC, DAI, LINK, etc.)
  • Other coins on smart contract-enabled blockchains (e.g., AVAX, ADA, SOL – depending on HTLC functionality)Technical requirements

Technical requirements

For an asset to be HTLC-compatible, it must:

• be lockable by a smart contract and only releasable under certain conditions,
• not be automatically accessible to third parties (e.g., through publicly known keys or preimages),
• the blockchain must support HTLC functionality or an equivalent.

Required functions

To realize our use case, the following extensions are required.

• It must be possible to specify a hash (lock) when blocking.
• In the case of a hash-secured reservation, the corresponding preimage (key) is required for unlocking.
• The pre-image is documented (e.g. in the account statement).

Key takeaways and lessons learned

• HTLC-based transactions can be integrated into the DESP with little technical effort.
• The digital euro can be used for secure blockchain payments through targeted API extensions.
• Zero trust models for DvP can be mapped in regulatory and technical terms