CBDC and Blockchain should not be treated as inseparable. A central bank digital currency can run on a conventional centralized ledger, a permissioned distributed ledger, or a hybrid model. The right choice depends on who needs to validate transactions, how much programmability is required, and whether the system must connect across institutions or borders.

That distinction matters. A CBDC is a liability of the central bank in digital form. Blockchain is only one possible database and coordination method. Sometimes it helps. Other times it adds consensus overhead, governance complexity, and operational risk without solving a real problem.

CBDC Architecture: Centralized Ledger or Distributed Ledger?

Most CBDC designs fall into two broad infrastructure models.

Centralized ledger: One logical ledger is controlled by the central bank or its appointed operator. Validation, settlement, and final record keeping sit under a single authority.
Distributed ledger: Multiple authorized nodes maintain synchronized copies of the ledger. Updates are accepted through a consensus process among approved participants.

Blockchain is a specific form of distributed ledger technology, or DLT, where transactions are grouped into blocks and linked in sequence. CBDCs usually do not need public, permissionless blockchains like Bitcoin or Ethereum mainnet. Central banks need identity controls, legal enforceability, transaction reversals in limited cases, and policy discretion. That points toward permissioned systems when DLT is used.

Centralized ledgers are not outdated. Existing real time gross settlement systems already move large values through tightly governed centralized infrastructure. They can be fast, predictable, and easier to supervise. If one central bank is the only trusted validator, a centralized design may be the cleanest answer.

Where CBDC Development Stands in 2024 and 2025

CBDC research is broad, but live deployment is still limited. The Bank for International Settlements 2024 survey, BIS Paper 159, found that 91 percent of 93 central banks were working on retail CBDC, wholesale CBDC, or both. Wholesale CBDC work is generally more advanced, especially in advanced economies.

As of the end of 2024, three jurisdictions had live retail CBDCs: The Bahamas with the Sand Dollar, Jamaica with JAM-DEX, and Nigeria with the eNaira. The Atlantic Council CBDC tracker reports that 134 countries, representing about 98 percent of global GDP, are investigating CBDCs. It also tracks dozens of pilot projects and engagement by all G20 economies.

China's e-CNY pilot is the largest live experiment. Public tracker data has cited cumulative transaction volumes of about 7 trillion yuan. That is serious testing, even though it is not the same as full global acceptance or proof that every country needs the same architecture.

When Distributed Ledgers Make Sense for CBDCs

Multiple institutions need shared control

DLT becomes attractive when several supervised institutions must operate parts of the system. Think commercial banks, payment service providers, securities depositories, or several central banks in a cross border network.

In that setup, a shared ledger cuts reconciliation work. Each participant sees the same state, subject to access rules. Settlement can be atomic, meaning either both sides of a transaction happen or neither does. That matters for foreign exchange payment versus payment and for securities delivery versus payment.

The BIS Innovation Hub and the World Economic Forum CBDC Policy Maker Toolkit both frame this as the real test: does the system need distributed validation, or is there already a single source of trust?

Tokenized assets need central bank money on the same rails

Wholesale CBDC has become the strongest case for DLT because financial markets are moving toward tokenized bonds, funds, deposits, and collateral. If the asset leg sits on a DLT platform but the cash leg settles later in a separate RTGS system, you reintroduce timing risk and reconciliation.

Project Venus showed this clearly. The Banque de France, Banque centrale du Luxembourg, and the European Investment Bank tested primary issuance of a tokenized EIB bond with settlement in experimental wholesale CBDC on private permissioned DLT platforms. The practical point is simple: tokenized securities work better when cash settlement can happen natively in central bank money.

Projects such as Jasper, Ubin, Inthanon, Aber, Jura, Dunbar, mBridge, and Helvetia have also used enterprise DLT platforms to test wholesale settlement, multi currency payment flows, and integration with existing financial market infrastructure.

Programmable settlement is part of the design

Smart contracts are not magic, but they are useful for narrow, rule based settlement. A wholesale CBDC can support conditional payments, escrow, collateral movements, coupon payments, and delivery versus payment logic.

To be blunt, programmability is overhyped in retail CBDC discussions. Most consumers do not need money that runs code. Wholesale markets are different. There, reducing settlement fails, automating margin calls, and synchronizing asset transfers can save real operational cost.

If you have worked with permissioned ledgers, you know the problem is rarely the demo. It is state design. In Hyperledger Fabric tests, the error MVCC_READ_CONFLICT is a common signal that too many transactions are competing over the same key. For a CBDC payment system, that kind of detail matters more than a polished slide about smart contracts.

Resilience and auditability justify the added complexity

Distributed replication can reduce single points of failure. If one node or data center goes down, other nodes can keep operating within the rules of the network. For critical payment infrastructure, that resilience is useful.

DLT also gives strong audit trails. Append only histories make unauthorized alteration harder and support post incident investigation. Supervisors can be granted specific visibility without giving every participant full access to every transaction.

Privacy design is not automatic, though. European data protection authorities have warned that DLT systems must prove they offer better privacy and performance than alternatives. A poorly built permissioned ledger can expose too much metadata. A well designed centralized system with privacy enhancing technology may be safer for some retail use cases.

When a Centralized Ledger Is the Better CBDC Choice

A centralized ledger often wins for domestic retail CBDC when the requirements are clear: high throughput, low latency, central bank control, legal simplicity, and limited need for multi party validation.

The Bank of England has argued that a central bank is already a trusted authority, so DLT should only be chosen when it brings a clear extra benefit. The BIS retail CBDC technology workshop reached a similar position. If validation trust is centralized and programmability can be handled in external systems, a conventional ledger can do the job.

Public permissionless blockchains are especially poor fits for most CBDCs today. They make central control harder. They complicate privacy. They do not map neatly to asset freezes, court orders, wallet recovery, and consumer remediation. Permissioned DLT can address many of these issues, but then the design starts to look closer to a distributed database operated by approved institutions.

Retail CBDC vs Wholesale CBDC: Different Technology Logic

Retail CBDC serves households and businesses. It needs wallet usability, fraud controls, offline options, tiered identity checks, accessibility, and privacy. The Bahamas, Jamaica, and Nigeria have focused on financial inclusion, payment resilience, and public access to digital central bank money.

Wholesale CBDC serves banks and financial market infrastructures. It deals with larger values, fewer participants, and more complex settlement workflows. That is why DLT fits wholesale CBDC more naturally. The network participants are known, the use cases are settlement heavy, and tokenized asset integration is a real requirement.

A Practical Decision Framework for CBDC and Blockchain

Use DLT for a CBDC only if you can answer yes to several of these questions:

Do multiple regulated institutions need to validate or maintain the ledger?
Does the system cross borders or involve more than one central bank?
Will the CBDC settle tokenized securities, deposits, or other digital assets?
Are atomic settlement and smart contract based workflows core requirements?
Does distributed resilience justify extra governance and performance work?
Can the design meet privacy, compliance, and legal enforcement requirements?

If most answers are no, start with a centralized ledger. It is simpler to test, easier to govern, and often faster. Add DLT only where shared state, tokenization, or cross border settlement creates a strong case.

Skills Professionals Need for CBDC Infrastructure

CBDC projects sit between monetary policy, payment systems, cryptography, distributed systems, and regulation. If you are building expertise here, study both sides. Learn how RTGS systems work. Then learn permissioned DLT, consensus, smart contracts, digital identity, custody, and privacy engineering.

For structured learning, Blockchain Council's Certified Blockchain Expert™ can help you build the foundation, while Certified Blockchain Developer™ and Certified Smart Contract Developer™ are useful paths if you want to work on tokenized settlement or enterprise DLT prototypes.

Final Take: CBDC Does Not Automatically Mean Blockchain

The strongest case for CBDC and Blockchain is wholesale settlement across multiple institutions, especially where tokenized assets and cross border payment flows are involved. The weakest case is a single country retail system where one central bank controls validation and needs very high performance.

Your next step: map the CBDC use case before choosing the technology. If the design depends on shared control, atomic settlement, and tokenized assets, test a permissioned DLT. If not, build the centralized ledger first and make DLT prove its value.