CBDC architecture: the choices that lock you in

Every central bank digital currency conversation we are invited into opens with the ledger. Which chain, permissioned or public, which consensus mechanism, whether it needs a chain at all. It is the most enjoyable question in the room and close to the least consequential. A ledger can be swapped during a pilot without anyone outside the programme noticing. The decisions that cannot be swapped are usually settled in the same fortnight, in a paragraph nobody argues about, and they set what the system is capable of for the next twenty years.

Our own footing here is worth stating plainly, because a lot of writing on this subject is produced by people who have never had to operate anything. We shipped our first production ledger system in 2016. We have issued tokens on public infrastructure, put three token platforms into production, and built a wallet where the user holds their own private keys. On central bank work we do architecture: the model, the record, the settlement path and the wallet, alongside the institution that carries the mandate. What follows comes from that, and from noticing which early decisions became expensive later.

The distribution model decides who answers the phone

Two shapes get drawn. In the direct model the central bank holds a claim for every holder, and with it the relationship. In the two-tier model the central bank issues to regulated intermediaries, and those intermediaries hold the customer. On an architecture diagram the difference looks like where an account table sits. In operation the difference is a national support function.

Holding the customer means onboarding them, checking identity, replacing credentials on a lost phone, freezing a balance when a court says so, settling the balance of someone who has died, and answering the call in whichever languages the country actually speaks at whatever hour it happens to be. Central banks are not staffed for that and mostly do not want to be. Commercial banks and payment providers are, because it is the job they already do badly enough to have learned from.

Reversing that choice after issuance means re-papering the legal claim of every holder in the country. The claim is what the currency is. No amount of good software makes that migration a technical exercise.

Two-tier carries its own architectural obligation, and it is one programmes tend to leave until late. If an intermediary fails, holders cannot lose access to money issued by the state. That means balances have to be portable to another intermediary, or temporarily back to the centre, on a timescale measured in hours. Portability of that kind has to be in the record format and the identity binding from the beginning. It is not something a resolution plan can add later in prose.

We saw a small version of the support problem in DigieCash, a self-custody wallet on Ethereum where balances never depend on a central ledger. Users hold their own keys, which is exactly the property the product promised and exactly the property that makes a lost phone final. Every support conversation collapses into a question about what the user still has. An institution that puts the wallet directly into a citizen's hands inherits that conversation at national scale, with a statutory duty behind it and no option to close the ticket.

The privacy model is a floor

Whatever the ledger records, it records. If the design captures payer, payee, amount and timestamp for every payment, that history exists from day one, and every future administration inherits it along with whatever legal powers exist to read it. Design it to capture less and there will eventually be a case, probably a serious one, where an investigator asks for something the system genuinely cannot produce and the answer has to be no. Both of those are real costs. Only one of them can be chosen.

The workable middle is tiered. Small balances and small payments carry little identifying data; larger ones are bound to a verified identity; the threshold is set in policy. That has a specific engineering consequence which is easy to miss. The system must be able to establish which tier a wallet sits in without learning who is in it, and it must hold that boundary while the same person moves between tiers over years. Whoever designs the wallet lifecycle is deciding the privacy model, whatever the policy document says.

Nothing in a ledger's history can be un-collected. The privacy decision is made once, at the start, by people who will not be in the room when it matters.

A citizen cannot choose a different currency the way they can choose a different bank. That single fact is the argument for conservatism here. Anything the system is capable of doing, it will eventually be asked to do, by someone with the authority to ask.

Offline capability is a hardware programme wearing a feature's clothing

Offline payment means two devices agreeing a transfer with no third party present. There is no safe way to do that in software alone. It needs a secure element on the device, a cap on the value a device can hold offline, a limit on how many times value can hop between devices before it settles, and a written accounting position on the losses the design is prepared to accept. All of that is decided at the start or not at all.

Finding out late costs a great deal more than a sprint. It means a hardware selection, a certification cycle and a physical distribution programme, inside an institution whose procurement moves in quarters. Adding offline to a design that assumed connectivity is closer to starting again than to a release.

The case for offline is the same one that runs through public sector work generally. A citizen cannot shop around for a different tax portal, and cannot shop around for a different currency either. It has to work on a cheap phone, on a weak connection, in the part of the country with the worst coverage, in the hour when the network is congested because everyone is paid on the same day.

The foreign exchange application we built for Zain Islamic Bank in Iraq is the small version of the same lesson. It was the first foreign exchange application in that market, and it ended at a branch counter, because that is where the cash was. We designed the flow around booking a collection slot rather than pretending the digital step was the whole journey. A design that only works for people with good connectivity and a recent handset serves the people who least need it.

What is actually locked in

After a few of these, the list of decisions we push hardest to settle in the first month is short and unromantic.

• Where the holder's claim sits: on the central bank, or on a regulated intermediary.
• What the ledger records about each payment, and how long that record is retained.
• Whether value can move without connectivity, and therefore what hardware is in scope.
• Which identity system a wallet is anchored to, because that anchor becomes a dependency of the currency itself.
• The format of the record, which will outlive every piece of software that reads or writes it.

Everything else can be revisited: consensus mechanism, throughput target, the number of intermediaries, the wallet interface, the fee model, cloud or metal. Programmes routinely spend their first six months on that second list, because it is the list engineers enjoy and the list vendors are selling against.

A pilot answers a different question from the one being asked

Pilots recruit willing participants with working phones, in a city, supported by a team that answers messages personally. They prove the payment works. They do not test what happens when a holder loses the device, when an intermediary is down for four hours on a payday, when fraud arrives at volume with an economic motive behind it, or when the population includes people who have never held a bank account and are not going to start with this.

That is worth saying out loud in the governance pack, because a successful pilot generates political momentum that the architecture then has to absorb. A pilot that proves the payment path while quietly deferring recovery, dispute handling and the offline question is not evidence about the system anyone will actually be asked to run.

The cryptography will not last as long as the currency

A currency issued this year is expected to be in use in the 2040s. No algorithm chosen now is good for that period. The record format needs an algorithm identifier and a version field from the first commit, signature verification needs to sit behind an interface, and the archive needs a re-signing path that somebody has actually executed rather than described in a design document.

Confidentiality is the smaller half of the problem, because a good deal of a ledger's content is deliberately not secret. Signatures are the larger half. A record whose signature can no longer be verified, or could be forged retrospectively, is a record nobody can rely on in a dispute years later, and the whole system rests on that reliance.

The ledger systems from that era that are still cheap to change are the ones whose record formats were versioned on day one. The ones that were not are the ones where every change since has been a migration with a maintenance window attached. That is the entire practical argument for crypto-agility, and it costs almost nothing to buy at the start.

The parts nobody demonstrates

Demonstrations show a payment. Operations live on everything else: reconciliation between the central ledger and the intermediaries' own books, dispute handling when money lands in the wrong place, refunds and whether they exist at all, and what a shopkeeper sees on a screen when the payment fails with a queue forming behind the customer.

Finality deserves its own conversation with the people who sign the design off, in language they can act on. If a payment is final on confirmation, the recovery path for a mistaken payment is legal and social rather than technical, and somebody has to staff it. If it is reversible, there is a window during which the money sits in a state the holder will not understand and cannot see. Either answer is defensible. Choosing one without telling the operations team which one is not.

Reconciliation is the item most likely to be underestimated, because in a two-tier design there are two sets of books that must agree every day, maintained by organisations with different incentives and different release calendars. The reconciliation report becomes the most consulted artefact in the whole programme, since it is the only place an argument about a number can be settled.

The ledger question will still be asked first, and it deserves a serious answer. It will not decide whether this system can be changed in 2035. Settle the five decisions above, get them signed by people who will still be accountable when the pilot ends, and accept that everything else in the architecture will be rewritten at least once by engineers who have not been hired yet.