ECB Digital Euro proposal

Nym R&D Team Provide Their Initial Observations on the Design Requirements

Recently, the European Central Bank announced a market research exercise for the implementation of the Digital Euro. The digital euro is a CBDC issued by Eurosystem, allowing end users to exchange payments electronically with central bank money.

While there has been a lot of debate on the privacy properties of CBDC designs [1], we leave the discussion of concerns around those to a separate article in due course. In this post, we analyse the technical requirements outlined in the market research exercise and comment on the technologies which could be used to implement them. We limit ourselves to discussing three of them; first, we share some observations and then the potential technical challenges.

Key Observations

We found this a well-thought-out and clearly communicated set of requirements; however, it is worth noting that there is no existing design that is able to fully satisfy them all. As the requirements are very detailed, we do not present them fully here but focus on a few key interesting features.

No Blockchain in Sight

While there is a ledger, there is no explicit mention of blockchain anywhere in the document. Thus, while the Eurosystem includes a payment ledger for settlements, the designers are clearly concerned about not only the privacy of individuals’ transactions but also their linkability. Hence included is the requirement to prevent the settlement layer of the Eurosystem from linking transactions involving the same physical individual, or from learning an individual’s holdings or any identifiable data [2]. This is clearly a key “must-have” requirement; simple pseudonymous addresses tied to individuals are explicitly forbidden. Thus, no existing blockchain solution can fully satisfy these requirements.

Intermediaries

A user has an account at an intermediary (for simplicity, one can think of this as a bank) which forms transactions for the settlement layer. While the settlement ledger component of the Eurosystem cannot link transactions belonging to the same individual, the intermediary can link all transactions done by their customers when they exchange payments or withdraw/deposit money. The intermediaries are also responsible for ensuring compliance with AML/CFT requirements.

Payments

The technical design seems to be based around the ideas of the eCash protocols introduced by Chaum in one of his seminal papers in the late 80s [3]. The workflows for this are roughly as follows:

1. User creates a digital coin; their account is debited by this amount.
2. User pays for a chocolate bar with the coin; the shop can verify the validity and check with the bank whether the coin was not previously spent.
3. Shop deposits the coin into their bank, which checks against double-spending, and credits the shop’s account.

Thanks to the anonymity property of the eCash protocol, the bank cannot link the deposited coin to its issuance, and thus cannot tell who bought the chocolate from the shop. Moreover, multiple transactions performed by the same user cannot be linked. This is actually better privacy than many blockchain systems, including Ethereum.

Onboarding

The process requires the intermediaries to run KYC checks and ensure AML/CFT compliance. The onboarding process also requires verification with the Eurosystem to ensure a particular individual (identified at this stage by, for example, a hash of their national ID) already has accounts/wallets opened with other intermediaries. No personal data is shared with the Eurosystem or other intermediaries during onboarding, but the Eurosystem must know which intermediaries are responsible for managing which users’ accounts.

Technical Challenges

Offline Payment Challenges

Although the original Chaum’s eCash scheme does not support offline payments (neither do blockchain-based solutions!), more recent designs [4, 5, 6] do. One might wonder about double spending the coin and how this can be prevented offline. In the academic literature, this is tackled by allowing double-spenders’ identification. However, the main drawback of Chaum’s design and the newer schemes [4, 5, 6] is non-transferability, i.e., the received coin cannot be directly spent to another user without contacting the bank and updating individual balances first (it’s not a very good coin if you have to take it to the bank instead of being able to spend it in another shop straight away!) [7]. This requires the spender and the receiver of any system to always be online.

An alternative approach is transferable eCash [8], which allows users to re-transfer obtained coins, while at the same time remaining offline. However, the efficiency of these schemes is questionable vs the requirements of the Digital Euro. On the other hand, the document mentions the use of trusted hardware as mandatory, so perhaps this was the intended way of mitigating double-spending. Alternatively, leaving room for choice in implementation was intentional.

The key challenge with supporting offline transactions we feel is a comment in the offline section mentioning that “a card-based solution should be supported”. While clearly desirable from a user perspective, in our view, current bank cards are:

• Incompatible with transferable eCash schemes.
• Incompatible with implementations involving trusted hardware (Secure Elements).

However, the card-based solution is only mentioned once, while the rest of the offline section concentrates on mobile phone-based implementations of the offline payment workflow.

Moving Bank (Intermediary)

The key requirement is that the individual can, in case of emergency, reconstruct their account and move to another intermediary without their old intermediary being online. We guess this is useful to recover funds in the case of a banking collapse or technical problem with the bank. This could create challenges in the context of:

• Offline transactions.
• User disconnection (this cannot be extracted from the ledger as the ledger is not allowed to “know” the holdings of any individual user).

Unlike in the case of the card-based implementation of offline systems, we do think there are designs that support this, but this is in our view clearly a desirable feature that is challenging to support.

Additional Payment Checks

As stated in the document, before transactions can be settled, the intermediaries might be required to carry additional checks on the party with which their user is transacting, for example, to ensure that a payer is a legitimate person complying with financial regulations or legislation. However, the personal data obtained by intermediaries during onboarding should not be shared with other intermediaries. A potential solution for a privacy-preserving KYC process is the use of anonymous credentials, like zk-nyms (based on the Coconut protocol, implemented by Nym Technologies and available on the Nyx blockchain), allowing the intermediaries to verify that the parties transacting with their users comply with a particular policy without learning any personally identifiable information about them.

---

Overall, while the ECB put forward a very detailed and thought-through set of technical requirements, which appear to take privacy seriously, we stress that the entire Digital Euro implementation will require careful privacy considerations and analysis. As we at Nym Technologies have discussed at the United Nations Internet Governance Forum in 2022 [9], without privacy built in from the bottom-up, a CBDC might pose a threat not only to users’ privacy but also to national security. We recommend the European Central Bank reviews existing designs and developments in relevant privacy-enhancing technologies (for example, differential privacy and eCash) and ensure that the solution enables financial access with full respect for privacy to ordinary people.

---

The above blog post was written by the Nym Research Team. If you have any questions comments, please contact ania@nymtech.net and andrei@nymtech.net.

Notes:

1. George Danezis and Sarah Meiklejohn, “Centrally Banked Cryptocurrencies“, 2016.
2. There are some cryptic notes on the potential implementation of this. See Annex 1, footnote 13, which, in our view, still leaves some room for implementation choices.
3. David Chaum, “Blind Signatures for Untraceable Payments”, 1982.
4. Jan Camenisch, Susan Hohenberger, and Anna Lysyanskaya, “Compact E-Cash”, 2005.
5. David Pointcheval, Olivier Sanders, and Jacques Traoré, “Cut Down the Tree to Achieve Constant Complexity in Divisible E-cash”, 2017.
6. Sébastien Canard, David Pointcheval, Olivier Sanders, and Jacques Traoré, “Scalable Divisible E-cash.”, 2015.
7. Note that the same restrictions apply to blockchain-based offline payment channels (e.g., Lightning Network).
8. Balthazar Bauer, Georg Fuchsbauer, and Chen Qian, “Transferable E-cash: A Cleaner Model and the First Practical Instantiation”,