A CBDC that is just a digital banknote misses the policy opportunity. Programmability — conditional payments, targeted disbursements, time-limited money — is what makes a CBDC architecturally different from existing digital money.
Central Bank Digital Currencies are issued digital claims on the central bank, but their value comes from programmability. A CBDC can have conditional spending rules (government welfare payments restricted to food categories), built-in expiry (stimulus money that must be spent within 90 days), targeted geographic restrictions (support local economy programmes), and real-time monetary policy transmission (negative interest rates applied directly at the wallet level). These capabilities require a different architecture from traditional payment systems. PROPELOO designs CBDC infrastructure with two-tier architecture (central bank issues to commercial banks, commercial banks distribute to end users), programmable money mechanics, a privacy model that protects user transaction data while maintaining AML visibility, and interoperability bridges to existing payment systems and correspondent banking rails.
Frequently Asked Questions
What makes a CBDC different from existing digital money?
Existing digital money (bank deposits) is a claim on a commercial bank — if the bank fails, deposits may be at risk (up to deposit insurance limits). CBDC is a direct claim on the central bank — it carries sovereign credit. Programmability is the other key difference: CBDC can have spending conditions, expiry, and automatic monetary policy transmission that commercial bank deposits cannot.
Does a CBDC require blockchain?
Not necessarily. A CBDC can be implemented on a traditional database for single-institution retail management and only use distributed ledger technology for multi-institution settlement (between central and commercial banks). The architecture choice should be driven by the trust model and the participants involved, not by a preference for blockchain.
How is user privacy protected?
Privacy architecture options: transaction amounts hidden via confidential transactions (Hyperledger Fabric private data), identity separation between transaction layers (pseudonymous at commercial bank level, reportable at central bank level for large transactions only), zero-knowledge proofs for balance proofs without revealing amounts. The specific privacy model is a policy decision made by the central bank.
What is the difference between wholesale CBDC and retail CBDC?
Wholesale CBDC is restricted to financial institutions and central banks for interbank clearing, cross-border payments, and securities settlement. It prioritises ultra-high throughput, gross settlement finality, and institutional access control. Retail CBDC is issued directly to citizens and businesses for daily consumer payments, requiring offline resilience, user-friendly mobile wallets, tiered privacy, and anti-bank-run holding limits.
How do you implement offline CBDC transactions safely?
Dual-offline transactions require tamper-resistant hardware security elements (e.g., secure elements in smartphones or smart cards). Counterparties exchange cryptographically signed value increments locally using NFC or BLE. To mitigate double-spending risks while disconnected from the central ledger, we implement consecutive transaction caps, rolling balance maximums, and asynchronous reconciliation mechanisms upon network reconnection.
Which ledger architectures work best for CBDC deployments?
Permissioned distributed ledgers like Hyperledger Fabric, R3 Corda, or private high-throughput EVM subnets are industry standards. Corda excels in wholesale bilateral financial agreements because transaction data is shared only on a need-to-know basis. Fabric provides modular consensus and private data channels. We also architect hybrid topologies where a centralised core handles peak retail loads while a permissioned DLT manages interbank settlement.
How does CBDC integrate with existing core banking and RTGS systems?
We build ISO 20022 compliant messaging bridges, API gateways, and settlement adapters connecting the CBDC core with legacy RTGS (Real-Time Gross Settlement), Fedwire, TARGET2, or local instant payment rails. Commercial banks can deposit reserves to mint digital currency (programmable issuance) and burn CBDC to redeem central bank reserves automatically.
How does CBDC prevent double-spending without public proof-of-work consensus?
Unlike public blockchains that rely on computationally expensive PoW or PoS, CBDC platforms use deterministic BFT (Byzantine Fault Tolerant) consensus protocols such as Raft, IBFT 2.0, or Tendermint among designated validator nodes (the central bank and supervised clearing institutions). Transactions achieve instant, sub-second finality with complete mathematical determinism and zero forks.
