True offline payments are impossible. Or are they?

Sometimes, I hear the claim that true offline payments are impossible. Fortunately, that false claim can be debunked quite easily.

But first, we need to understand where this claim comes from. In their pivotal 2021 paper, Kahn et al. describe the “offline payment trilemma”, which can be explained very easily: no digital payment scheme can simultaneously be offline-capable, prevent double-spending, and accommodate for loss recovery.

This can be visualised using the above triangle. When designing a system, you need to pick a side. Physical cash can be used offline and prevents double-spending. But if you lose your wallet, you lose your money. Similar for the other sides: Debit cards cannot be used offline. Credit cards and paper cheques do not prevent double-spending.

This correlates to a well-understood principle from computer science, the so-called “CAP theorem”. It describes a fundamental limitation of database systems, which need to compromise on either availability, consistency, or resilience against loss of connectivity. This is not caused by poor engineering, but by the physical properties of networks: a law of nature.

The connection between Kahn’s trilemma and the CAP theorem is quite simple:

• offline capability corresponds to partition tolerance;
• no double-spending corresponds to consistency; and
• loss recovery corresponds to availability.

Where should CBDC sit? By its nature, it is a central bank liability, so there cannot be any compromise on double-spending. And in terms of features, offline capabilities are highly desirable for resilience and financial inclusion. This leaves us only with one choice: designing CBDC like banknotes.

The CAP theorem teaches us that we can – in theory – simultaneously achieve offline capability and prevent double-spending. We can accept some restricted availability, for example, it is not possible to top-up one’s offline wallet from a bank account without online connectivity. Many database systems choose a similar trade-off.

But how can we achieve all that in practice? More concretely, what defence mechanisms can we utilize to protect against double-spending?

The answer is a “defence in depth” approach, where we do not rely on a single measure, but multiple layers.

For CBDC, there are three layers:

1. The bottom layer is strong hardware security: Secure Elements are tamper-resistant chips that provide a strong defence against attacks such as the one outlined above.
2. In the middle, secure payment protocols and channels provide protection against attacks when money is being moved. For example, wallets should always employ end-to-end encryption to prevent eavesdroppers from cloning tokens.
3. Finally, the central bank must always be able to tell authentic from counterfeit money. This is very easy with a token system because every token can only be used once.

For offline payments, it is particularly important that all layers work together. Even if a wallet cannot validate a token on the spot during payment, it should reconcile it when it regains connectivity, for example, when the user tops up from their bank account. This reduces overall risk in the system.

Unfortunately, while the other layers are uncontroversial, the use of strong hardware security is repudiated by some, leading to the claim that true offline payments are impossible. This argument does not hold up to scrutiny for a very simple reason: Strong hardware security is already employed in today’s payment system – as well as connectivity and many other industry sectors – in the form of hardware-based Secure Elements.

To this day, there are no known exploits on payment cards, despite the large incentive: imagine an attacker that could clone credit cards at a large scale. If it works well in this highly exposed landscape, it will work well for CBDC. Users have the choice whether they want to store their holdings on special-purpose devices (like a dedicated smart card), or on an existing device (like a smartphone).

To conclude: true offline payments are possible. They rely on, among other measures, strong hardware security, which is well-established in the industry. What is new is that CBDC will enable additional use cases, for example when both payer and payee are offline. But the technology for that is already there.