The Private Path: Sign CBDC on Hyperledger Fabric-X¶

Design Principles¶

A central bank digital currency (CBDC) puts sovereign money on a ledger that citizens, businesses, and banks use every day. That ledger has to leave monetary authority with the central bank, keep each payment private from parties with no role in it, and let policy be built into money without opening the ledger to arbitrary code. A public ledger cannot meet all three on its own, so this path is permissioned. Sign CBDC is our permissioned platform on which a central bank issues, distributes, supervises, and redeems sovereign digital money. It rests on five positions:

• Central Bank Authority: The central bank is the sole issuer and governs membership, certificates, network roles, and the rules of finality. Only the committed ledger establishes the state of the currency. Commercial banks onboard customers, perform KYC and AML checks, service wallets, and authorize their customers’ transactions, without gaining monetary authority. This is the two-tier model that the BIS Innovation Hub and the Hong Kong Monetary Authority prototyped in Project Aurum, which combined a wholesale interbank system with retail wallets operated by intermediaries (source).

• Privacy with Accountable Oversight: Amounts, token types, and owner identities are hidden from ordinary ledger participants. The Monetary Auditor, a mandatory central bank checkpoint described below, validates every transaction privately, and linking a transaction to a person requires a governed legal process.

• Programmability under Control: Programmable money runs only from templates the central bank has approved, and participants cannot deploy contracts of their own, so programmability enforces policy and never becomes a second monetary authority.

• One Ledger for Settlement: A single ledger, using an Unspent Transaction Output (UTXO) token model with account-style balance views, serves wholesale and retail money and is designed to take over the settlement functions now split between two systems: the Real-Time Gross Settlement (RTGS) system, through which banks settle large payments in central bank money, and the general ledger, the central bank’s accounting system.

• Open-Source Foundation: The platform is built on open-source Hyperledger Fabric-X and the Panurus token framework, so the ledger and token code at the core of the national currency is open to inspection.

Platform Foundation: Fabric-X and Panurus¶

Hyperledger Fabric-X is a re-architecture of Hyperledger Fabric that splits Fabric’s all-in-one node, called the peer, into separate services that each scale on their own. Endorsement checks and signs a proposed transaction, ordering agrees the order of transactions, and commitment validates them and writes them to the ledger. Fabric-X validates transactions in parallel using a dependency graph, and its Byzantine Fault Tolerant (BFT) ordering service works on compact batch attestations instead of full transaction payloads. Published upstream benchmarks report throughput above 150,000 transactions per second for a single-organization configuration of 16 virtual machines on a light synthetic workload (source). These figures show architectural headroom and are not deployment guarantees; each deployment’s performance is established by testing in its target environment against its agreed targets (Table 10).

Token operations use Fabric Smart Client and Panurus, an open-source framework for token applications that supplies token APIs, wallet services, privacy drivers, and transaction assembly. We are a core contributor to Panurus alongside other organizations in the Fabric-X token ecosystem and contribute our changes upstream instead of maintaining separate versions, which gives us detailed knowledge of the platform our CBDC runs on.

We chose Fabric-X over Hyperledger Fabric 2.5, Hyperledger Besu, Corda, and a conventional centralized ledger. All of them offered permissioned governance and deterministic finality; Fabric-X was the best fit for BFT ordering, a UTXO token model with privacy drivers, independent scaling of each processing role, and performance headroom. Its main gap, a short production history at national scale, is mitigated by testing in the target environment and by staged adoption (Adopting in Stages).

Reference Architecture¶

Figure 7 shows the principal components and the boundaries between participating institutions, the central bank platform, the ledger network, and existing financial infrastructure.

Institutions reach the central bank platform through one authenticated entry point, the Facade, which authenticates, constrains, and routes requests without holding monetary state. Behind it, the Central Business Hub runs policy, limit, and fee services and the connections to the RTGS and the general ledger. The Issuer executes only the Mint and Burn operations the central bank has approved. The Monetary Auditor is a mandatory policy gate: every transaction carries a confidential audit package, and the Auditor must validate it before the transaction can reach the ledger.

Wallet Nodes prepare transactions for the wallets each bank services, reserving unspent inputs and building each transaction with its zero-knowledge proof. Each bank’s wallets sit in a separate partition, and a Wallet Node’s token view is an operational copy, never the authoritative state. The ledger network has Endorsers that simulate and sign proposals, a BFT ordering service that sets the canonical order, and Committers that validate and commit blocks and answer controlled queries. Identity and trust services provide certificate authorities, credential issuance, and key management on Hardware Security Modules (HSMs), with separate custody domains for the central bank and each bank. An alias service lets users pay to a phone number or email address instead of a wallet address, and observability covers every component for operations, audit, and incident response.

Every institution-initiated operation, whether an issuance, a transfer, a payment, or a redemption, follows one lifecycle that keeps preparation, owner authorization, policy enforcement, and commitment apart (Figure 8).

The servicing bank’s Wallet Node partition applies limits, builds the transaction with its proof and audit package, and returns an authorization challenge. Once the owner approves the payment in the bank’s channel, the bank’s protected credential holder, the secure enclave in which the bank keeps the owner’s anonymous credential (Wallets, Custody, and Key Management), signs that exact challenge with that credential, which proves that an eligible owner authorized the transaction without revealing who the owner is. The Monetary Auditor then validates the audit package privately; a rejected transaction never reaches the ledger. Endorsers sign the proposal under the endorsement policy, the ordering service sequences it, and Committers validate the proofs and commit it, which makes it final. Committed history is never rewritten. A refund or reversal is a new transaction, linked to the original and authorized separately.

Wallet Node Placement¶

We recommend hosting Wallet Nodes on the central bank platform, with a separate partition for each bank. Each bank keeps its customer relationships, KYC, channels, and the protected credential holder that authorizes its customers’ transactions, while the central bank runs one hardened platform for all of them. Each bank’s partition is isolated: the bank holds its keys in its own hardware security modules, and role-based access control limits what platform administrators can do, with every administrative action logged.

This placement follows how authority already works in a CBDC: the central bank issues the currency, runs the Monetary Auditor, governs the ledger, and defines finality. A single partitioned platform is secured, upgraded, monitored, and recovered once for every participant. A new bank or payment service provider joins by having a partition configured, without building and staffing its own payment infrastructure, which makes it easier for smaller institutions to take part.

Placement is a deployment choice the central bank makes. Where it prefers that commercial banks prepare transactions in their own technical domains, each bank can operate its own Wallet Node with the same transaction lifecycle, privacy model, and policy gate. The two models can also be combined, for example with larger banks running their own Wallet Nodes and smaller institutions hosted on the central bank platform. Each wallet is served by one Wallet Node, requests are routed to whichever node serves it, and Wallet Nodes share state only through the ledger, so they need no synchronization with each other. A bank can move from one model to the other through a planned migration of its wallets.

Privacy Model¶

In our view, a citizen’s payment should be visible only to the parties with a role in it, and any wider disclosure should go through a governed, recorded process. Two cryptographic mechanisms carry this. Sign CBDC uses the ZKAT-DLOG token privacy scheme, under which token types and amounts are hidden in Pedersen commitments: values that conceal a number but still let the ledger check that the sums balance. Each transaction carries a zero-knowledge proof that inputs and outputs share a permitted token type, that value is conserved including any fee output, and that every output is within the allowed range. The selected profile needs no trusted setup, the one-time key ceremony that some proof systems require and whose leftover secrets could be used to forge proofs. Owners authorize transactions with Identity Mixer (Idemix) anonymous credentials: each presentation is freshly randomized and bound to the exact transaction challenge, so a verifier learns that an eligible owner authorized the transaction and nothing about the owner’s identity, secret, or full credential. Table 2 shows what each party learns.

Table 2: Privacy boundaries in Sign CBDC

Personal data, KYC files, credentials, secrets, and proof witnesses never enter the ledger, which stores only commitments, anonymous owner representations, proofs, references, and validation results. The design does not hide the existence or timing of transactions or the spending graph; metadata minimization, scoped application views, and monitoring limit what can be inferred from them. The result protects citizens’ financial privacy and still meets the central bank’s need for supervision and the banks’ obligations for AML and counter-terrorist financing. BIS research points the same way: in Project Tourbillon, the BIS Innovation Hub Swiss Centre and the Swiss National Bank showed that consumers can pay digitally without disclosing personal information to merchants, banks, or the central bank, while the central bank still sees transaction amounts (source). Sign CBDC takes a more conservative position for AML purposes, because the servicing bank always knows its own customer. For a transfer between customers of different banks, the originator and beneficiary information that the FATF Travel Rule (Recommendation 16) requires is designed to travel in an encrypted message between the two banks, outside the ledger, so the receiving bank can screen it. Banks report suspicious transactions to the financial intelligence unit as they do today, and a sanctions freeze runs through the same signed-order control as any other freeze.

Wallets, Custody, and Key Management¶

In the reference configuration each wallet has one active servicing bank, which holds the owner’s anonymous credential and secret inside a Trusted Execution Environment or secure enclave in the bank’s domain. Standard PKCS#11 HSMs do not support the pairing-based proofs that Idemix requires, so HSMs hold the conventional keys instead: certificate authority, TLS, and issuer keys under a three-tier public key infrastructure with an offline central bank root, central bank intermediates, and a subordinate authority for each bank. A customer who moves to another bank keeps the wallet identifier; the new bank enrolls new credentials, holdings move in an ordinary ledger transaction, and no secret passes between banks. Non-custodial wallets, in which citizens hold their own credentials on secure devices, are an option a central bank can assess during design.

Network Roles and Consensus¶

At launch the central bank can operate the ordering service and Committers, so that one accountable authority runs the system of record while other participants qualify. The reference endorsement policy still requires the central bank’s Endorser and at least one eligible bank Endorser from the start, so no transaction is endorsed by the central bank alone. Selected banks may take on further approved combinations of Endorser, Consenter (a node of the ordering service), and Committer roles, and no institution has to host a full network stack to participate. The BFT ordering service tolerates fewer than one-third faulty or malicious consenters; the reference profile places four consenters across the central bank’s primary and disaster recovery sites, tolerates the failure of any one of them, and grows as banks become consenters. The loss of a whole site stops new transactions until the disaster recovery procedure restores quorum within the recovery time agreed with the central bank; a deployment that must keep running through a site loss places consenters in at least four locations. Membership, certificates, and configuration change only through signed configuration transactions under central bank control, and the central bank keeps emergency controls such as suspending operations during a security incident.

Programmable Money Under Central Bank Control¶

Programmable money in Sign CBDC is money that carries its purpose. It is built from a small set of configurable controls: limits, fee calculation, grouped policy rules, and marked tokens with recipient restrictions. These are combined with workflows into delivery profiles that the central bank approves (Table 3). Each rule runs in the narrowest component that can enforce it safely. Domain policy services evaluate limits and eligibility; workflow services handle approvals, external evidence, and exceptions; and deterministic chaincode, the smart-contract code that runs on the Fabric-X ledger, enforces only the invariants that must hold atomically with the state change, such as an escrow release.

Table 3: Controlled programmability in Sign CBDC: uses and examples

Only approved templates, code, and parameter schemas execute. No rule can mint or burn currency, alter a final transaction, relax a higher-priority central bank control, or bypass owner authorization and the Auditor. Chaincode makes no external calls and reads no clock, personal data, or secrets; external facts enter a transaction only as authenticated evidence from the responsible workflow.

Which controls a program uses, and when they may be applied, are policy decisions that the government makes under its own law. The platform enforces what that law sets: a restriction, expiry, or recall applies only to the funds a program designates; a freeze, reversal, or recall runs only on a signed order from an authority registered in the platform, and the order is recorded with it; the holder’s wallet shows any restriction, expiry, or freeze and the authority behind it; and the active rules are listed in a register that the supervisor can always see and that the government may publish.

Issuance, Redemption, and Settlement¶

At launch the platform works alongside the central bank’s existing infrastructure. New currency is minted only after central bank approval and final RTGS settlement, and released to the requesting bank’s wholesale holding. Banks distribute it to customer and merchant wallets against deposit-account debits; a top-up is an ordinary transfer and does not change supply. For redemption, the RTGS reserves liquidity, the bank authorizes a Burn of its holding, the Issuer executes it, the ledger commits it, and the RTGS settles the conventional leg. The general ledger receives accounting information through controlled read-only access.

Only the central bank’s Issuer can sign a mint or a burn, and every transfer carries proofs that its outputs equal its inputs and that each amount is within range, which committers verify before the transaction becomes final. The Monetary Auditor sees the amounts in every transaction it validates and is designed to reconcile the total in circulation against the Issuer’s mint and burn records, raising an alarm if they differ. We recommend an independent review of the cryptographic protocols before launch.

The settlement interface accepts the message formats central banks use today, such as SWIFT MT-based RTGS messages, as well as ISO 20022 profiles for payment initiation, status, and regulatory reporting. A central bank can connect to its current RTGS and move to ISO 20022 later without changing the ledger, and connect to international infrastructure as other systems complete their own migration.

The same ledger serves both tiers of the monetary system. In the wholesale tier, the central bank, commercial banks, and the treasury hold balances, interbank transfers are final on commitment once the platform holds the legal designation that settlement finality rules require, and repurchase operations, payment-versus-payment, and delivery-versus-payment settle under approved profiles. Programmable wholesale money can also carry monetary policy operations: in Project Pine, the BIS Innovation Hub and the Federal Reserve Bank of New York built a smart-contract toolkit that pays interest on reserves, runs open market operations, and manages collateral, and it carried out the intended operation immediately in each of ten normal and stressed market scenarios (source). In the retail tier, citizens and businesses pay through bank and payment-provider channels: person to person, at merchants by QR code, between businesses, and to and from government. Alias-based payments by phone number make the currency easier to use for underbanked people, and payments can continue offline during outages (National Payments).

Tools for Financial Stability¶

A retail CBDC should not draw deposits out of commercial banks, least of all under stress. The central bank sets the tools that prevent this: holding limits per wallet, enforced by the same limit controls as every payment; automatic sweeps, designed to move any amount above the limit to the holder’s linked bank account and back when a payment needs it, so that a limit never blocks a payment; remuneration at zero or in tiers; and tighter limits on conversion from deposits into CBDC when stress requires them. Each tool is a parameter that the central bank can change without a software release.

Consolidating RTGS and General Ledger Functions¶

While the platform runs alongside existing systems, every change in supply waits on the RTGS and every balance is reflected in the general ledger. The CBDC ledger settles in real time at any hour, but issuance and redemption can move only as fast as RTGS operating hours and the general ledger’s posting and reconciliation cycle allow, and the central bank pays to run and change three systems. In many central banks the RTGS and general ledger are legacy platforms that are expensive to operate and slow to change, and they set the limits of what the new ledger can do. The ledger is designed to perform their core settlement functions: it records the central bank money each institution holds, settles gross transfers between participants, and makes each transfer final and auditable. The BIS blueprint for the future monetary system describes the same end point, a unified ledger on which tokenized central bank money, commercial bank money, and other assets settle together (source). Our direction is one ledger instead of three, and the platform is designed so that a central bank can consolidate onto it in stages:

1. Integrate: The ledger connects to the existing RTGS and general ledger, and supply changes settle against the RTGS.

2. Settle Reserves on the Ledger: Interbank reserve balances move onto the same ledger, and transfers between banks settle there in parallel with the RTGS, which remains the fallback.

3. Retire Legacy Settlement: After an agreed parallel run with the ledger as system of record, interbank transfers leave the RTGS. The general ledger becomes a reporting consumer of ledger data, and the central bank’s own financial accounting continues in its enterprise systems.

Each stage is a central bank decision with its own acceptance criteria. An RTGS does more than settle: it manages intraday liquidity, collateral, and queues, links to securities settlement for delivery versus payment, supports monetary policy operations, and, under settlement finality rules, carries the legal designation that protects its settlements from being unwound, for example if a participant becomes insolvent. Each operational function must move to the platform’s workflow services and integrations before the RTGS is retired. The platform itself should receive that legal designation earlier, before it carries live interbank value. Over time we expect the network to widen in the same staged way, as qualified banks take on Endorser and Consenter roles and the ledger connects to other central banks through the interoperability routes below.