Minutes of the CBDC Technology Forum – January 2022


Item 1: Welcome

Tom Mutton (Chair) welcomed the Members to the third CBDC Technology Forum meeting. He noted the publication of the House of Lords Economic Affairs Committee report on CBDC.

Item 2: Discussion of survey results

The Bank provided a short summary of the results of a survey conducted with Forum Members after the last meeting on 30 November 2021. The survey aimed to gather any further, more structured, thoughts from Members on the topics discussed at the meeting.

Item 3: Outline of a CBDC hypothesis vision

At the last meeting, Members thought that it was helpful to understand the objectives being pursued and the potential use cases for an eventual CBDC to facilitate more detailed technical discussions in the Forum. To that end, the Bank proposed a hypothetical CBDC vision, solely used for the purposes of informing the scope of the Forum’s conversations. This vision does not represent Bank of England policy and may change over time to facilitate other avenues of technology discussion.

A vision for a CBDC is to provision a public payment infrastructure for central bank money which would provide a universal settlement mechanism in a future of rapidly evolving digital ecosystems. Such a CBDC might encourage innovation by allowing a wide and varied range of private sector firms to develop more advanced services, in a safe and interoperable manner that fosters advantageous competition.

Item 4: CBDC systems – Account v Token v Hybrid

The Bank briefly introduced the topic providing an overview of account and token-based CBDC systems to frame the discussion. The objective of the session was to compare the different ledger data structures across a range of design areas to understand advantages and disadvantages of each.

One Forum Member presented a comparative examination of the account and token-based settlement systems, describing account systems as being balance-centric, and tokens being similar to banknotes. The presentation noted that CBDC pilot programs have experimented with two approaches to account-based settlement systems: (i) an account-based system in which accounts are stored at Payment Interface Providers (PIPs) and settlements take place at the core ledger, and (ii) a ledger-centric account-based system in which accounts are stored directly on the core ledger while PIPs provide access and additional service for end-users.

For token-based models, the presentation noted that CBDC pilot programs have mostly experimented with a standard token / UTXO-based settlement system in which users have either direct or intermediated access to their tokens which were spent and recreated for each transaction. The presentation also described a bill-based token settlement system, which worked similarly to UTXOs, with the difference of tokens not being recreated on transactions, but simply changing owner. It was assumed that token-based systems would use DLT technology, an assumption that was challenged by other Members.

The Member presentation concluded that the ledger-centric account model likely best met the requirements for CBDC.

In the following discussion, Members discussed the role of consensus and whether issuance of CBDC by the central bank would be desirable with a shared ledger, with broad consensus between the Bank and PIPs. Some Members argued that global consensus was not required in presence of a trusted third party. During the debate there was no consensus on which model was best for the UK.

A second Member presented on a hybrid Account-token model which aimed to ensure protection of user balances, support for offline payments and improved user privacy. The presentation stated that neither purely account-based nor purely token-based models met these key requirements. The proposed model blended aspects of the account system, such as balance protection, and the token system, such as offline capability, while allowing for improved privacy. Some Members challenged the assumption that CBDC balances should necessarily be protected by the central bank.

In the proposed hybrid model, CBDC accounts were represented by a set of public and private key pairs, which could be renewed regularly while the wallet was online to prevent user tracking and profiling when making different payments. CBDC transactions, represented by a chain of payer and payee signatures, would include the offline transaction history to ensure that the core ledger balances could be updated when the wallets went back online. Transaction history would be encrypted with the central bank’s public key so that only the central bank could decrypt it. The model assumed the central bank would need to be able to track funds in order to reconstruct the offline chain of payments, but some Members argued that this role could also be played by other trusted third parties. With regards to privacy, one Member warned that relying on encryption alone to protect transaction data shouldn’t be an acceptable proposition, as it had to be assumed encryption could be broken in the future.

Members discussed that, in addition to the complexity involved in syncing balances and transactions between the user’s device ledger and the core ledger, offline payments required a trusted execution environment on the user’s device to prevent tampering or double spending. There would be, in turn, great incentives to break those trusted environments. With respect to double spending, it was noted that a liability framework would be required to deal with this risk when both payer and payee were offline.

Item 5: Programmability

The Bank introduced its understanding of programmable money, programmable payments, and smart contracts, and framed the objective of the session, that of understanding what might be achieved with programmability, and the trade-offs and risks associated with different approaches.

One Member presented on the design landscape for programmability, which touched on legal agreements underpinning programmability, use cases, implementation and control.

The presentation compared the implementation of programmability on the core ledger vs as an overlay service. It concluded that programmability could be better implemented as an overlay service, with PIPs, FMIs or the ecosystem responsible for performing controls and checks. The presenter argued that this would create a greater scope for innovation, with the core ledger acting as an authoritative data store. It was also noted that a common set of data and process standards would be key to interoperability.

The presentation suggested that programmability could be implemented in the overlay layer in either a centralised or distributed manner. Entities implementing programmability in the overlay layer would need to comply with an agreed common data or process standards and core ledger APIs, but could use different technologies to do so. In comparing smart contracts in distributed ledger systems, the presentation stated that on-ledger contracts were better suited to deliver broad consensus and transparency, but risked delivering lower performance and reduced privacy.

The presentation also discussed complexities around exposing programmability to users and mechanisms for controlling what is programmable in CBDC. It suggested implementing programmability in stages, with more mature services being built over time.

The presentation concluded with an illustrative architecture with a common programmability overlay service layer across both CBDC and commercial bank money. The central bank’s CBDC ledger and the commercial banks ledgers would interact with the ecosystem through APIs (CBDC ledger API and Open Banking API, respectively).

Some Members favoured the idea of using programmability as the abstraction layer across CBDC and other forms of money, agreeing with the proposal for a common ecosystem. Other Members questioned what value would CBDC add in that scenario if programmability could be achieved with commercial bank money. It was argued that, in a scenario where a CBDC existed, this common ecosystem would ensure inclusion and avoid market fragmentation.

Other Members noted the suggested architecture raised the question of what enhancements would be needed to existing Open Banking APIs, in order for it to be part of an integrated platform with CBDC.

Closing remarks

The Chair closed the meeting and thanked the Members for their contributions. The next meeting would be in March 2022.

Annex: Meeting documents

Meeting slides


Tom Mutton (Chair), Bank of England
Will Lovell, Bank of England
Katie Fortune, Bank of England
Danny Russell, Bank of England
April Baracho, Bank of England
Nick Vaughan, Bank of England
Carmen Barandela, Bank of England
Harry Doyle, Bank of England
Guillermo Pons, Bank of England


Alan Ainsworth, Open Banking Implementation Entity
Andrew Flatt, Archax
Ashley Lannquist, IMF
Bejoy Das Gupta, eCurrency
David MacKeith, AWS
Dominic Black, Ledgerz
Edwin Aoki, PayPal
Geoff Goodell, UCL
Inga Mullins, Fluency
James Whittle, PayUK
Joshua Jeeson Daniel, JP Morgan
Keith Bear, Cambridge Centre for Alternative Finance
Lauren Del Giudice, Idemia
Lee Braine, Barclays
Mark Shaw, Spotify
Max Malcolm, Visa
Michael Adams, Quali-Sign
Patrick O’Donnell, Mastercard
Paul Lucas, IBM
Sarah Meiklejohn, IC3
Sean Mullaney, Stripe
Vikram Kimyani, Oracle

Guest speakers

Kamil Jamroz (Fluency)


National Cyber Security Centre


Matthieu Saint Olive (Consensys)
Richard Brown (R3)
Simon Brayshaw (ASOS)
Will Drewry (Google)


Source link

Earn $5,000 A MONTH From Home! Click Here