The offline digital euro: when the secure element fails, what remains?

Two questions should be settled before the design is fixed

Every offline payment system rests on one assumption: that the payer’s device cannot be induced to spend the same money twice. The assumption is forced rather than chosen. Two parties with no access to a shared record cannot, by cryptography alone, prevent one of them presenting the same stored value to a third, so the burden falls on tamper-resistant hardware. The Eurosystem has placed it there, as every other serious offline design has. What has not been put clearly is what remains true when that hardware fails.

The European Central Bank’s presentation to the Euro Retail Payments Board in April 2026 describes the offline digital euro as comparable to a bearer instrument: funds spendable without connectivity, immediately re-spendable offline, held in an applet on a secure element that debits and credits a balance, with settlement final locally between the two devices.

Identifying compromised elements

A balance carries no history. When an element is compromised – not if, since certified elements have been broken and a technique that works once can be applied across devices of the same model or batch – the value it emits is indistinguishable from good value. No artefact records that a compromise occurred, nothing identifies which units are affected and there is therefore nothing to contain. The only signal is an aggregate one: the issuance component tracks the total in circulation, so an excess surfaces eventually at redemption. This tells the Eurosystem that value was created but not by whom, which units or whose holdings to stop.

That is the position of a counterfeit banknote. It circulates for months, is found where it happens to meet an inspection and when found identifies neither its source nor the other copies already passing from hand to hand. A banknote at least carries a serial number.

The number is most of the difference. Give each unit an identifier at issue, as a note has, and then give it what a note has not: a record of its own transfers, carried with it. Such an object is called a token in the technical literature, though a banknote is the closer picture. The central bank issues units in fixed denominations, each with a unique identifier and a signed origin. When one is handed on offline, the payer’s device appends an entry to the unit’s record – to whom it is going, at what position in the sequence – and signs that entry. The record travels with the unit, and the recipient checks it before accepting, much as a shopkeeper holds a note up to the light. Nothing in the payment requires a network.

The unit is verified when it is next presented online, which is the counterpart of a note returning to the central bank. The central bank keeps one line per unit: the furthest point in its history it has already seen. It compares. A unit that has been copied yields two incompatible continuations from the same point, which a device behaving correctly cannot produce, so the copy shows up when the second continuation is presented, with no history to reconstruct. The identifier then goes onto a published list of revoked units. Devices carry that list, so the next person asked to accept an affected unit refuses it while the unit is still circulating. This is the register of stolen banknote serials, made useful by being consultable offline.

Identification is a separate step and deliberately a later one. The evidence of a copy names the manufacturing batch of the element that produced it and the window in which it happened, and that much is available with nobody’s identity opened. Each transfer also carries the sender’s identity in encrypted form, under a key split so that several institutions in different hierarchies must act together to use it, and act on the single unit named in the evidence and no other. Disclosure is graduated: that a copy exists; then who made it; then a wider span of that unit’s history, each step on its own authorisation.

What emerges at the end is the custodian of a device rather than a culprit. A stolen phone used with its correct personal identification number produces the same evidence as deliberate fraud, and a liability rule has to be written to treat the inference as rebuttable.

Figure 1. What a compromised secure element leaves behind

A balance-based design compared with one in which each unit, or token, carries a record of its own transfers

Source: author, adapted from the graphical abstract of https://doi.org/10.5281/zenodo.22163575.

None of this prevents anything; prevention remains the hardware’s job. What it adds is inert while the element holds, and determines what can be said once it does not. The price should be stated plainly, because a proposal that claims to be free is not a proposal. A unit that carries its history is a larger object to transmit, and it grows with each transfer. This is a mathematical result rather than an implementation defect, so the growth has to be capped and units have to return to the issuer periodically. The central bank has to hold state. On the figures I set out elsewhere, a billion-unit deployment costs about 66 gigabytes to detect that a unit’s history has diverged, and roughly a terabyte to retain evidence a third party can check for itself. Neither is an obstacle. Both are budget lines, and they should be decided rather than discovered.

Who bears the loss?

The harder question is not cryptographic at all. When a compromised device spends the same value twice, two honest parties hold claims to the same money, and only one can be honoured unless the issuer is prepared to create value. Something has to decide which. The natural rule, and the one that will apply by default if no other is chosen, is that the first claim to reach settlement prevails.

The holder who reconnects later is the holder with worse connectivity. Offline capability exists for people with poor connectivity: for outages, thin rural coverage, the passengers of a stopped train, those whose data runs out before the month does. A rule that resolves conflicting claims by order of arrival concentrates the losses of a compromise on precisely the population the feature was built for. No improvement in the cryptography closes that gap, because it is not a cryptographic property.

The alternatives are all policy. The central bank can absorb the loss, as one recent academic design proposes. It can be shared. Or the order that decides can be a timestamp written by the payee at acceptance rather than the order in which branches reach the central bank. That shifts the incidence from the poorly connected to the poorly maintained, at the price of a window in which the payment is not yet final and a device that refuses to transact on an unattested clock. What cannot be done is to leave the matter undecided, because first arrival allocates the loss before anyone has considered fault.

I am not arguing for a different architecture. The offline solution is at specification stage and an argument for wholesale redesign is late. I am arguing that two questions be answered before the design is fixed. What artefact would allow a compromise to be identified after the fact: which units, from which device, within what window? And who bears the loss when it cannot be?

Both are cheaper to answer now than after issuance, and the second needs no technology at all. It needs a decision that is at present being left to the order in which people happen to get a signal.

A design whose security argument ends at the secure element is making a claim it cannot support at national scale. A design that gives each unit a memory can say what happens next, and the price it pays is at least a price that can be quantified.

Tzanko Golemanov is a lecturer in the Department of Computer Systems and Technologies, ‘Angel Kanchev’ University of Ruse. The technical treatment on which this article draws is available as an open preprint at Zenodo, https://doi.org/10.5281/zenodo.22163575.

OMFIF will be in Frankfurt on 3 December for the European digital sovereignty forum. Register to attend here.

Interested in this topic? Subscribe to OMFIF’s newsletter for more.

Join Today

Connect with our membership team

Scroll to Top