By 2026, more than 130 countries have explored central bank digital currencies according to the Atlantic Council CBDC Tracker. At least eleven jurisdictions run live retail or wholesale implementations in some form. The Bahamas Sand Dollar, Nigeria’s eNaira, Jamaica’s JAM-DEX, the Eastern Caribbean DCash, plus the People’s Bank of China e-CNY are no longer theoretical. The Bank for International Settlements has shipped six named multi-bank pilots. The European Central Bank has moved the digital euro into preparation phase. The Monetary Authority of Singapore has scaled Project Guardian into a multi-jurisdictional tokenized asset framework.
The question has moved. From early-stage discussion of whether to issue a CBDC to architectural deployment of how the infrastructure is built.
This article is the infrastructure article. Not the policy article. It assumes the reader is a bank architect, a regulator, an infrastructure vendor, or a central bank pilot team member who is past the introductory framing and wants the technical decision tree. We will cover the structural choices that drive every other choice, the stack inside the major BIS and MAS pilots, the role oracle networks play in cross-system data, the privacy and security baseline, the live infrastructure provider landscape, plus the unsolved problems that still separate pilot work from production.
By 2026, most of the technical questions have answers. The infrastructure roster is visible. The vendor categories are clear. What follows is what is actually being built, by whom, on what.
Matrixed.Link sits inside this stack as a Chainlink node operator with ISO/IEC 27001:2022 certification and a multi-year on-chain track record. The view in this article is the operator view.
What CBDC Infrastructure Actually Means
CBDC infrastructure is not one thing. It is a family of related architectures that share a common property: a central bank issues digital liability. The technical stack determines how that liability flows through the financial system.
Four structural choices drive every other choice.
Wholesale vs retail. Wholesale CBDC settles between commercial banks, clearing houses, plus other regulated financial institutions. The user count is small. The transaction count is small. The transaction values are large. Retail CBDC is consumer money. The user count is in the tens of millions per jurisdiction. The transaction count is high frequency. The privacy requirements are different. The two stacks share almost no design constraints. Most production progress through 2026 has happened on the wholesale side.
Account-based vs token-based. An account-based CBDC tracks balances against identities. The unit of state is the account. A token-based CBDC represents value as discrete digital instruments that move between holders. The unit of state is the token. Account-based systems map cleanly onto existing banking software. Token-based systems map onto distributed ledger primitives. Hybrid models exist where wholesale tokens settle into retail accounts.
Centralized vs distributed ledger. A central bank can issue digital money on a fully centralized ledger that the central bank operates. The China e-CNY uses a centralized architecture. A central bank can issue on a permissioned distributed ledger that multiple validators run. BIS Project Cedar tested distributed ledger settlement. A central bank can issue on a public chain with permission layers. Some Project Agorá design elements explored this. The choice has cascading effects on resilience, programmability, settlement finality, plus vendor lock-in.
Tiered vs direct. A tiered model puts commercial banks between the central bank and end users. The central bank issues to banks. Banks distribute to consumers. A direct model puts the central bank into a direct relationship with consumers. Almost every advanced pilot uses a tiered model. Documented operational reasons include preserving existing bank relationships, distributing KYC obligations, plus limiting direct technical load on the central bank.
These four choices are upstream of the policy decision. A central bank cannot decide “what kind of CBDC do we want” without first deciding the structural stack, because the stack constrains what the policy can do. A retail token-based CBDC on a public chain implements a different policy reality than a wholesale account-based CBDC on a permissioned ledger, even when the legal framing is similar.
The BIS CBDC System Design and Interoperability paper covers this decision tree in detail. The pilots have answered most of these questions in their narrow scope. The next sections cover what.
The Core Technical Stack
A production CBDC system has four functional layers. Every named pilot through 2026 implements some version of all four.
The issuance layer. The central bank operates the authoritative node or node cluster. This layer holds the cryptographic keys that mint or burn digital currency, enforces the supply ceiling, plus signs the canonical state. Key management at this layer uses hardware security modules (HSMs), multi-party computation, plus threshold signature schemes. Boston Fed Project Hamilton documented two architectural variants for this layer: a single transaction processor that scales vertically alongside an atomizer architecture that distributes the processor horizontally. Both architectures reached throughput levels relevant to retail-scale transaction volumes in published Hamilton research.
The distribution layer. Commercial banks, payment service providers, plus other regulated intermediaries run nodes that connect to the issuance layer. This is where most production CBDC activity actually happens. Distribution-layer nodes hold customer balances, route transactions, settle obligations between intermediaries, plus integrate with existing core banking systems. The core infrastructure decisions for banks happen here: which DLT platform to support (Corda, Hyperledger Besu, Quorum, an Ethereum L2 variant), how to integrate with legacy payment rails (TARGET2, FedNow, RTGS), how to manage liquidity across CBDC plus reserves. The Blockchain for Banks deep dive covers the institutional integration pattern.
The end-user layer. Wallets, payment instruments, plus compliance hooks live here. The wallet model differs between wholesale and retail. Wholesale wallets are institutional custody implementations. Retail wallets are consumer apps with KYC at onboarding. Compliance hooks at this layer include anti-money laundering screening, sanctions checking, transaction limits, plus (in some pilots) programmable rules that constrain how the money can be spent. The end-user layer is where most public discussion about CBDC concentrates, even though most production infrastructure work has happened at the issuance plus distribution layers.
The cross-system interoperability layer. A CBDC is useful in proportion to what it can settle against. Cross-system interoperability connects a CBDC to other CBDCs (cross-border settlement), to tokenized commercial bank deposits (BIS Project Agorá), to tokenized assets (BIS Project Helvetia, MAS Project Guardian), to existing payment networks (SWIFT integration trials), plus public blockchain ecosystems where stablecoins or tokenized funds live. This is the layer where oracle networks become structurally necessary. Cross-system data verification cannot happen inside any single ledger.
Each of these four layers has an operator question. Who runs the node? Who signs the transactions? Who reconciles the data? Who attests to the reserves? In retail and wholesale pilots alike, the operator question is being answered by a small set of institutional infrastructure vendors with track records that predate the CBDC conversation. The pilots are not choosing first-movers. They are choosing operators with multi-year history of running adjacent infrastructure: oracle networks, custody systems, validator clusters, settlement layers for tokenized assets. That selection logic is one of the structural dynamics shaping CBDC vendor rosters.
Cross-Border CBDC Infrastructure: The Pilot Reality
Cross-border CBDC is where pilots get real. The hard problems (FX, settlement finality, legal jurisdiction, time zones) cannot be papered over with national policy. Each pilot below validated specific infrastructure decisions.
BIS Project Mariana. Banque de France, Monetary Authority of Singapore, Swiss National Bank, plus the BIS Innovation Hub Eurosystem, Singapore, Switzerland Centres. Mariana tested automated market maker (AMM) infrastructure for cross-currency settlement of wholesale CBDCs. The pilot proved that AMM mechanics from DeFi can settle CBDC trades between three central bank ledgers. The infrastructure choice: a common token standard across all three jurisdictions, with AMM liquidity pools providing FX conversion. Per the BIS Mariana report, settlement finality across jurisdictions reached seconds rather than days.
BIS Project Agorá. Seven central banks (Federal Reserve Bank of New York, Bank of England, Bank of France, Bank of Japan, Bank of Korea, Bank of Mexico, Swiss National Bank) plus the BIS along with more than 40 private-sector firms. Agorá is structurally different from Mariana. It explores tokenized commercial bank deposits settling alongside wholesale CBDC on a unified ledger. The implication is structural: commercial bank money becomes interoperable with central bank money at the protocol level. Agorá is the largest multi-jurisdictional CBDC infrastructure pilot in the public record by participant count.
BIS Project Cedar (NY Fed). Phase II tested distributed ledger cross-border settlement between the New York Fed Innovation Center and the Monetary Authority of Singapore. The infrastructure question Cedar answered: can a DLT-native settlement system between two central bank ledgers reach acceptable finality, atomicity, plus resilience properties for production deployment. The answer from the public report: yes, for the tested scope.
BIS Project Dunbar. Reserve Bank of Australia, Bank Negara Malaysia, Monetary Authority of Singapore, South African Reserve Bank. Dunbar built a multi-CBDC platform where multiple central banks could issue onto a shared infrastructure. The technical lift is heavy. The governance lift is heavier. The pilot proved feasibility for the technical side. Production deployment of a multi-CBDC platform remains a forward question.
MAS Project Guardian. Singapore’s tokenized asset framework. Guardian is broader than CBDC. It covers tokenized funds, tokenized FX, tokenized commercial bank liabilities, plus CBDC settlement. Named participants include major global banks (JPMorgan, Standard Chartered, DBS, UOB) along with asset managers. Guardian has become a reference architecture for jurisdictions thinking about programmable institutional finance. The Tokenization of Assets primer covers the wider tokenization context.
Boston Fed Project Hamilton. Joint research between the Federal Reserve Bank of Boston and MIT’s Digital Currency Initiative. Hamilton is the retail-scale throughput research. The two architectures tested (single transaction processor, atomizer) demonstrated that a CBDC system can plausibly handle US retail transaction volumes. Hamilton is not a production system. It is the public reference that proves the throughput question is solved at the research level.
What every pilot validated: cross-border CBDC settlement is technically possible with current DLT and oracle infrastructure. What every pilot left unsolved: production deployment requires legal, regulatory, plus governance frameworks that have not converged across jurisdictions. The World Bank cross-border CBDC review is the canonical summary of the pilot landscape.
The Oracle Layer in CBDC Infrastructure
CBDCs do not exist in a vacuum. Every production CBDC system needs data that does not live on its own ledger. FX rates. Securities prices. Reserve attestations. Regulatory data feeds. Cross-system transfer messages. Oracle networks are the infrastructure that brings this data on-chain in a verifiable, cryptographically signed form. The What Is a Blockchain Oracle? explainer covers the underlying primitive.
The oracle role in CBDC infrastructure is not optional. It is structural.
Cross-chain CBDC settlement. Chainlink CCIP (Cross-Chain Interoperability Protocol) provides the infrastructure for moving tokenized value across multiple ledgers with cryptographic verification of each transfer. SWIFT has run public blockchain interoperability trials using CCIP. The CCIP architecture matters for CBDC because it provides a vendor-neutral way for one central bank’s ledger to communicate with another central bank’s ledger, with cryptographic guarantees about message integrity that a bilateral integration cannot provide. Read the Chainlink CCIP deep dive for the protocol-level mechanics.
FX and market data delivery. Chainlink Data Streams delivers low-latency market data to on-chain consumers, including FX rates and securities prices. For CBDC infrastructure, this matters in three ways. Cross-currency CBDC settlement (Project Mariana style) needs verified FX rates to clear trades. Tokenized asset trials (MAS Project Guardian style) need verified securities prices to mark portfolios. CBDC-to-stablecoin off-ramps need verified peg rates. Each of these is a data flow that cannot trust a single centralized source without introducing a single point of failure. The Chainlink Data Streams article covers the delivery model in detail.
Reserve attestation. Chainlink Proof of Reserve provides on-chain cryptographic attestation that off-chain reserves back on-chain claims. For CBDC infrastructure, this applies to tokenized commercial bank deposits (Project Agorá style), to stablecoin reserves that interface with CBDC rails, plus to tokenized money market funds that may be used as CBDC collateral. The Tokenized Money Market Funds article covers the institutional tokenized fund landscape. The infrastructure question Proof of Reserve answers: how does a market participant verify, without trusting the issuer, that a claim on-chain is backed by real assets off-chain.
The operator perspective. Running oracle infrastructure for institutional pilots is not the same as running a DeFi price feed. Bank-grade integrations require certified information security management (ISO/IEC 27001:2022 minimum), hardware-rooted key management, geographic redundancy, audit-grade logging, plus a multi-year track record of correct submissions on production networks. Matrixed.Link has operated in the Chainlink ecosystem since the network’s early operational phase. The operator class that wins CBDC pilot work is the class that already runs adjacent institutional infrastructure today. That selection has already happened in most cases. The vendor list is short.
What this means for a bank architect: the oracle layer is not a future decision. It is a present decision. The networks and operators that will support CBDC integration are running production data flows now. The Chainlink Data Provider explainer covers the adjacent institutional data layer.
Privacy and Security Requirements
Retail and wholesale CBDC have different privacy models. Both have non-negotiable security requirements.
Retail privacy. The European Data Protection Supervisor has published the most explicit framework for retail CBDC data protection. The position: personal data processing must be minimized at the protocol level, not just at the policy level. This pushes specific cryptographic requirements into the infrastructure. Zero-knowledge proof systems that allow transaction validity to be verified without revealing transaction details. Selective disclosure mechanisms that expose transaction data only to authorized parties under specific legal triggers. Pseudonymous account systems that separate identity from on-chain state.
The trade-off is real. Privacy at the protocol level can constrain anti-money laundering enforcement. The pilots have approached this through tiered privacy: small transactions get strong privacy, large transactions trigger enhanced compliance disclosure. The thresholds are policy decisions. The capability to enforce them at the protocol level is an infrastructure decision.
Wholesale privacy. Different problem. Counterparty identity is generally known. Trade details are commercially sensitive. The privacy requirement is to prevent leakage of trading positions, not to hide identity. Pilots like Project Guardian have used permissioned subnets with encrypted transaction payloads, where validators can verify execution without seeing trade details. This is a mature pattern from existing wholesale financial infrastructure.
Cryptographic primitives in production pilots. Zero-knowledge proofs (zk-SNARKs, zk-STARKs) for transaction validity verification. Threshold signature schemes for distributed key management. Hardware security modules for key custody at issuance and intermediary nodes. Multi-party computation for sensitive cross-jurisdictional operations. Trusted execution environments where appropriate. None of these are research-stage. All of these are production-deployed in named pilots through 2026.
Information security baseline. For any operator running infrastructure inside a CBDC pilot, ISO/IEC 27001:2022 information security management certification has become the floor, not the ceiling. SOC 2 Type II audit, geographic redundancy with documented failover, hardware-rooted attestation for signing keys, real-time security monitoring with audit-grade logging, plus incident response procedures with documented SLAs are all standard requirements in BIS-led pilots.
The operator implication: security certifications that were treated as differentiators five years ago are now baseline. An infrastructure vendor without ISO/IEC 27001:2022 is not in the conversation for CBDC pilot work. Matrixed.Link holds this certification and treats it as the entry requirement, not the achievement.
The Infrastructure Provider Landscape
By 2026, the CBDC infrastructure provider landscape has consolidated into recognizable categories. The vendor names recur across pilots.
DLT platforms. R3 Corda powers wholesale CBDC pilots that prioritize permissioned, identity-bound transaction privacy. Hyperledger Besu and Quorum (now ConsenSys) cover Ethereum-compatible permissioned deployments. Native Ethereum L2s (zkSync, Polygon CDK variants) appear in tokenized asset trials that interface with CBDC rails. Hedera, IOTA, plus Algorand have run specific CBDC pilots in named jurisdictions. The platform choice is downstream of the wholesale-vs-retail along with the permissioned-vs-public decision.
Oracle networks. Chainlink dominates institutional pilot work. The dominance is structural rather than competitive: the Chainlink network has the longest documented production track record in the oracle category (mainnet since 2019), a broad documented set of institutional integrations (DTCC, SWIFT, US Department of Commerce data on-chain, US Treasury data initiatives), plus the most established operator class. For CBDC infrastructure, Chainlink CCIP, Chainlink Data Streams, plus Chainlink Proof of Reserve are the dominant institutional choices.
Custody and key management. Qualified custodians (BNY Mellon, State Street, Northern Trust, BitGo, Anchorage, Fireblocks) handle institutional custody for tokenized assets that interact with CBDC rails. Specialized MPC vendors provide threshold signing along with key sharding services. The Digital Asset Custody article covers the institutional custody landscape.
Node operators. This is the layer Matrixed.Link occupies. Node operators run the consensus infrastructure of oracle networks plus DLT platforms. The selection criteria for institutional pilot work are clear: ISO/IEC 27001:2022 certification, multi-year on-chain track record, demonstrated infrastructure reliability, geographic redundancy, plus existing institutional client relationships. The class of operators that meet these criteria across all relevant networks is small. The What Is a Chainlink Node Operator? explainer covers the operator role.
System integrators. IBM, Accenture, Boston Consulting Group, Deloitte, R3, plus ConsenSys provide the integration work between legacy banking systems and CBDC infrastructure. This is the consulting layer, not the infrastructure layer. Banks deploying CBDC integration typically use a system integrator for the legacy banking side plus direct relationships with infrastructure providers for the on-chain side. The Web3 Infrastructure for Enterprises article maps the wider enterprise stack.
The pattern across all five categories: incumbency built on prior production work in adjacent systems (oracle networks, tokenized asset infrastructure, institutional custody). The CBDC opportunity is being awarded to operators with established track records, not to first-movers.
Unsolved Problems in CBDC Infrastructure
The pilots have answered most of the engineering questions. The unsolved problems through 2026 are these.
Cross-CBDC interoperability at scale. Every named cross-border pilot is bilateral or small-group. Project Dunbar tested four central banks. Project Agorá scales the participant count higher but on a single platform. No pilot through 2026 has tested production-grade interoperability between independent CBDC systems running on independently chosen technology stacks. Hub-and-spoke models, mesh models, plus shared-platform models each have proponents. The infrastructure pattern for global CBDC interoperability is not yet decided.
Privacy regulation alignment. EU GDPR pushes data minimization. US transparency expectations push counterparty visibility. Asian jurisdictions push data localization. These three frameworks generate conflicting infrastructure requirements. A CBDC system designed for one regime may be illegal in another. The technical patterns that resolve this (selective disclosure, federated identity, jurisdiction-aware routing) exist. The legal frameworks that govern them do not converge.
Offline payment support. Retail CBDC has a hard requirement that wholesale CBDC does not: the ability to transact when the network is unavailable. The cryptographic primitives for offline-capable digital cash exist. Mastercard, Visa, plus others have demonstrated working systems. The integration with online ledger state is technically difficult. Resolution of double-spend risk in offline transactions requires either trust assumptions or hardware-rooted attestation. The pilots have prototypes. Production deployment at scale is the next challenge.
Programmability bounds. A CBDC can be programmable. Conditional transfers, expiring money, geographic restrictions, plus merchant-category restrictions are all technically possible. The acceptable scope of programmability varies by jurisdiction. The infrastructure decision (how programmable to make the protocol layer) is upstream of the policy decision (which programs to allow).
Settlement finality models. Probabilistic finality (typical of public chains) is incompatible with how legal settlement finality is defined in most jurisdictions. Deterministic finality requires specific consensus mechanisms. The pilots have used both. Production deployment will require legal frameworks that recognize specific finality models as legally final.
These are policy decisions waiting for engineering input, not engineering decisions waiting for policy input. The Federal Reserve CBDC overview along with the IMF CBDC Virtual Handbook provide the canonical institutional summary of these open questions.
How Matrixed.Link Operates Inside This Stack
Matrixed.Link is a Chainlink node operator with a multi-year track record in institutional oracle infrastructure. The operating posture maps to the requirements that CBDC pilots are starting to formalize.
Operator history. Matrixed.Link has run Chainlink network infrastructure since the network’s early operational phase. The Chainlink ecosystem now backs SWIFT’s blockchain interoperability trials, the US Department of Commerce on-chain macroeconomic data initiative, BIS Project Agorá tokenized commercial bank deposit work, plus DTCC’s blockchain integration program. Operators with longer track records are advantaged in this class of work because the institutional buyers can verify performance history on-chain.
Certifications and ratings. ISO/IEC 27001:2022 certified information security management system. AAA validator rating on StakingRewards. The certifications are the entry requirements for institutional pilot work in 2026. Matrixed.Link holds them as baseline.
Infrastructure posture. Geographic redundancy with documented failover. Hardware security module key management at the signing layer. Real-time monitoring with audit-grade logging. Production track record across 500+ price feeds, 12M+ data points delivered on-chain, more than $200M secured at peak.
Client roster. Approved named clients include Chainlink, Lido, Enjin, Stake.link, plus bitsCrunch. The institutional client base is broader and developing. The relationship pattern: long engagement cycles, infrastructure-grade SLAs, multi-year contracts.
The pattern as CBDC pilots formalize. Pilot work moves to production. Production work goes to operators with track records that predate the pilot conversation. The Chainlink ecosystem operators positioned today are positioned for the next decade of institutional integration work. CBDC infrastructure is one slice of that opportunity. Tokenized assets are another. Cross-chain institutional settlement is another. The same operator capabilities support all three.
Work with Matrixed.Link
Matrixed.Link operates institutional-grade infrastructure inside the Chainlink network. Banks, asset managers, plus central bank pilot teams evaluating oracle layer integration for CBDC, tokenized asset, or cross-chain settlement workflows can contact the Matrixed.Link team to discuss requirements.
ISO/IEC 27001:2022 certified. AAA validator rating on StakingRewards. Multi-year on-chain operator track record across Chainlink, Lido, Enjin, Stake.link, plus bitsCrunch.
