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. If you want the broader policy and design context behind these choices, the Certified Central Bank Digital Currency (CBDC) Expert program is a reasonable place to start before getting into the architecture weeds below.

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

Since this section leans heavily on distributed ledger fundamentals, it is a good point to mention the Certified Blockchain Expert credential, which builds the underlying consensus, architecture, and DLT knowledge that the rest of this comparison assumes.

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. Engineers debugging issues at this level often round out their skills with a general Tech Certification, since the underlying systems and API fluency carries over well beyond any single DLT platform.

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. And if your role also involves explaining these architecture trade-offs to non-technical stakeholders or the public, a Marketing Certification is worth adding to your toolkit, since a technically sound CBDC design still needs clear communication to earn public trust.

FAQs

1. What is the relationship between CBDC and blockchain?

A Central Bank Digital Currency (CBDC) is a digital form of central bank money, while blockchain is one possible technology for recording and transferring digital assets. A CBDC does not automatically require blockchain. Central banks can use centralized databases, Distributed Ledger Technology (DLT), or hybrid architectures depending on their objectives. Blockchain becomes relevant when features such as shared recordkeeping, programmable settlement, interoperability, or distributed operation provide meaningful advantages over conventional infrastructure.

2. Does a CBDC need blockchain technology?

No. CBDCs can operate without blockchain technology. Unlike decentralized cryptocurrencies, a CBDC has an identifiable issuer and governance authority: the central bank. A centralized ledger may therefore provide adequate performance, control, and efficiency for some CBDC designs. DLT may make more sense where multiple authorized institutions need coordinated access to shared transaction records. The technology should follow the requirements, rather than beginning with blockchain and heroically searching for a problem afterward.

3. When does blockchain make sense for a CBDC?

Blockchain or DLT may make sense when a CBDC system involves multiple trusted participants that need synchronized records, programmable transactions, tokenized assets, or coordinated settlement. Wholesale CBDCs are particularly relevant because banks and financial institutions may transact through permissioned networks. DLT can also be explored for cross-border settlement involving several jurisdictions. Its benefits should be compared with centralized alternatives based on performance, resilience, security, privacy, governance, scalability, and total implementation cost.

4. What is the difference between blockchain and Distributed Ledger Technology in CBDCs?

Distributed Ledger Technology is a broader category of systems in which transaction records can be maintained across multiple participating nodes. Blockchain is one type of DLT that organizes records into linked blocks. CBDC projects may use blockchain-based platforms, other distributed architectures, or conventional centralized databases. Using the terms interchangeably can therefore be misleading. Central banks generally evaluate specific technical properties rather than adopting a technology merely because the broader market has attached an impressive vocabulary to it.

5. How is a blockchain-based CBDC different from cryptocurrency?

A blockchain-based CBDC remains central bank money even if distributed ledger technology supports its infrastructure. Cryptocurrencies such as Bitcoin typically operate without a central monetary issuer and use different governance and monetary models. CBDCs are issued under public authority and are designed to function within regulated financial systems. They may also use permissioned networks where only authorized participants can operate nodes, unlike public blockchains where network participation can be substantially more open.

6. What is a permissioned blockchain for CBDCs?

A permissioned blockchain restricts network participation to approved organizations or entities. In a CBDC environment, authorized nodes might be operated by the central bank, commercial banks, payment providers, or other designated institutions. Permissioned networks can provide greater control over governance, access, privacy, and performance than open public blockchains. They may therefore be more suitable for regulated financial infrastructure where participant identities and responsibilities must be clearly established.

7. Are public blockchains suitable for CBDCs?

Public blockchains may provide transparency and broad network participation, but they can create challenges involving privacy, governance, scalability, transaction costs, regulatory control, and operational responsibility. CBDCs generally require central banks to maintain authority over issuance and monetary integrity. As a result, many CBDC experiments involving DLT have focused on permissioned architectures rather than fully permissionless public networks. Public blockchain technology may still interact with regulated digital money in broader tokenized financial ecosystems.

8. What are the benefits of using blockchain for CBDCs?

Potential benefits include shared transaction records, improved coordination among participating institutions, programmable settlement, traceability, resilience, and integration with tokenized assets. DLT can also reduce certain reconciliation requirements when multiple institutions maintain synchronized information. These benefits are most relevant when a process genuinely involves distributed participants. A centralized system may remain simpler and faster when one trusted institution already controls the infrastructure, which is inconveniently often the situation when discussing central banks.

9. What are the disadvantages of blockchain-based CBDCs?

Potential disadvantages include technical complexity, scalability constraints, integration challenges, governance requirements, privacy concerns, cybersecurity risks, and higher implementation or operational costs. Maintaining multiple ledger nodes may also introduce overhead that a centralized architecture avoids. Some blockchain features designed for trustless environments provide limited value when all CBDC participants are already regulated and identifiable. Central banks therefore need to determine whether DLT provides enough practical benefit to justify additional architectural complexity.

10. Can blockchain improve CBDC security?

Blockchain can provide features such as cryptographic transaction verification, tamper-evident records, and distributed validation. However, using blockchain does not automatically make a CBDC secure. Security also depends on wallet protection, identity systems, cryptographic key management, APIs, software development, node security, access controls, network architecture, and operational procedures. A perfectly protected ledger is of limited comfort if attackers can simply compromise users' wallets or steal administrator credentials elsewhere in the system.

11. Can blockchain improve CBDC privacy?

Blockchain does not inherently guarantee privacy. In fact, permanently recording transactions on a shared ledger can create significant privacy concerns if transaction information can be linked to individuals. CBDC designs may therefore require encryption, pseudonymous identifiers, selective disclosure, zero-knowledge techniques, data segregation, or other privacy-enhancing technologies. Privacy requirements should influence the architecture from the beginning because attempting to bolt meaningful financial privacy onto an excessively transparent system afterward can become technically and legally difficult.

12. Can smart contracts be used with CBDCs?

Smart contracts could potentially support automated settlement and conditional payment processes involving CBDCs. For example, transactions might execute automatically when predefined conditions are satisfied. This could be useful for wholesale settlement, tokenized securities, trade finance, or machine-to-machine payments. However, central banks must consider security, legal enforceability, governance, software errors, and operational controls. Smart-contract functionality may also be implemented in supporting payment infrastructure without making the underlying currency itself universally programmable.

13. How can blockchain-based CBDCs support tokenized assets?

A wholesale CBDC operating on compatible digital infrastructure could potentially serve as a settlement asset for tokenized securities, bonds, funds, or other financial instruments. This may enable delivery-versus-payment, where the asset transfer and corresponding payment are coordinated closely or executed atomically. Such arrangements could reduce settlement risk and reconciliation requirements. Practical implementation depends on legal recognition, interoperability, technical standards, market participation, cybersecurity, and appropriate governance of the tokenized financial infrastructure.

14. How can blockchain support cross-border CBDC payments?

DLT can potentially provide shared infrastructure through which participating central banks and financial institutions coordinate cross-border transactions. Multi-CBDC platforms may support faster settlement, improved transparency, and more efficient foreign-exchange processes. However, distributed technology cannot solve every cross-border problem. Countries still need agreements concerning legal jurisdiction, AML requirements, sanctions, foreign exchange, data governance, access rules, dispute resolution, and monetary sovereignty. Software remains stubbornly incapable of negotiating international law by itself.

15. Can CBDCs use blockchain for atomic settlement?

Yes, certain DLT-based CBDC designs can support atomic settlement, where interconnected transaction legs either complete together or do not complete at all. This can be valuable for delivery-versus-payment in securities markets or payment-versus-payment in foreign exchange. Atomic settlement may reduce principal and settlement risks, although it can also affect liquidity requirements and existing market processes. Central banks and financial institutions therefore need to evaluate both the technical benefits and broader implications for financial-market operations.

16. How scalable is blockchain for CBDC transactions?

Scalability depends on the specific blockchain or DLT architecture rather than blockchain technology as a single category. Retail CBDCs may need to process very large transaction volumes with low latency and high availability. Permissioned networks can potentially achieve much higher performance than many public blockchains because their consensus and participation models differ. Central banks must test throughput, latency, resilience, storage, recovery, and peak-load performance before determining whether a DLT platform can support nationwide payment requirements.

17. Is blockchain better suited to retail or wholesale CBDCs?

DLT may have particularly compelling applications in wholesale CBDCs because multiple regulated financial institutions need to coordinate settlement and may also interact with tokenized assets. Retail CBDCs have different priorities, including enormous transaction volumes, user privacy, offline payments, accessibility, and simple consumer experiences. Blockchain can still be considered for retail systems, but a centralized or hybrid architecture may sometimes meet those requirements more efficiently. There is no universally superior architecture for every CBDC use case.

18. What are hybrid CBDC architectures?

Hybrid CBDC architectures combine elements of centralized and distributed infrastructure. For example, a central bank might maintain control over issuance and core records while intermediaries operate customer-facing services or additional distributed components. Hybrid approaches can attempt to combine centralized governance and performance with selected benefits of DLT. The exact meaning of “hybrid” varies between projects, so CBDC architectures should be evaluated according to their actual technical design rather than relying exclusively on convenient labels.

19. How should central banks decide whether to use blockchain for a CBDC?

Central banks should begin with functional and policy requirements, including transaction volume, privacy, resilience, offline capability, interoperability, governance, programmability, cybersecurity, and settlement needs. They can then compare centralized databases, DLT, and hybrid architectures using measurable criteria. Proofs of concept and pilots can test whether blockchain provides genuine benefits. Choosing DLT should therefore be an architectural conclusion reached after analysis, not a requirement inserted at the beginning because blockchain sounds sufficiently futuristic in a strategy presentation.

20. What is the future of CBDC and blockchain technology?

The future is likely to involve selective use of blockchain and DLT rather than universal adoption. Distributed ledgers may become particularly important for wholesale CBDCs, tokenized financial markets, programmable settlement, and cross-border experiments. Retail CBDCs may use centralized, distributed, or hybrid infrastructure depending on national requirements. The central question will increasingly shift from “Does the CBDC use blockchain?” to whether its technology delivers secure, scalable, private, resilient, interoperable, and economically useful digital central bank money.