How to Architect a Hybrid CBDC Model (Account-Based and Token-Based)

A hybrid CBDC architecture merges two foundational ledger models: the account-based system, familiar from traditional banking, and the token-based system, native to blockchain. In an account-based model, ownership is recorded as a balance linked to a verified identity, requiring a central ledger to check account status for every transaction. In contrast, a token-based model treats the currency as a digital object (like a banknote) where ownership is proven by cryptographic signature, enabling offline verification and peer-to-peer transfer. The hybrid approach aims to capture the strengths of both: the control and integration of accounts with the resilience and privacy potential of tokens.

Architecting this model requires a clear separation of concerns across different layers. The core settlement layer, typically operated by the central bank, maintains the ultimate record of ownership using an account-based ledger. This ensures monetary policy control and finality. A parallel distribution layer issues digital tokens that represent claims on these central bank liabilities. These tokens can circulate on permissioned Distributed Ledger Technology (DLT) networks or specialized hardware (like secure elements in phones), enabling offline-capable, peer-to-peer transactions. Interoperability protocols synchronize state between these layers, ensuring tokens are always backed 1:1 by reserves in the settlement system.

Smart contracts are crucial for automating the lifecycle of these digital tokens. A minting contract on the settlement layer can lock central bank money and issue a corresponding token on the distribution network. A burning contract destroys tokens and releases the underlying funds. For example, an Ethereum-compatible system might use an ERC-20 style contract on a permissioned chain for the token layer, with bridge contracts managing the mint/burn process. Code audits and formal verification of these contracts are non-negotiable for security, as they manage the direct liability of the central bank.

Key design decisions involve privacy, scalability, and offline functionality. The account layer inherently requires identity, but the token layer can be designed for varying degrees of privacy using zero-knowledge proofs or blind signatures. Scalability is addressed by handling high-volume, small-value transactions on the fast distribution layer, while the settlement layer processes batched net positions. For offline payments, hardware-secured tokens can change hands without network access, with disputes or double-spend attempts resolved later against the central ledger, similar to the Swiss National Bank's Project Helvetia Phase III wholesale CBDC experiments.

Implementation typically follows a phased approach. Phase 1 establishes the core settlement ledger and a simple API for authorized financial institutions. Phase 2 introduces the DLT-based distribution layer for interbank transactions. Phase 3 expands access to businesses and consumers, integrating hardware wallets for offline use. Each phase requires rigorous testing for security, resilience, and compliance with regulations like AML. The Bank for International Settlements (BIS) Innovation Hub provides multiple case studies, such as Project Dunbar and Project Jura, which explore these architectural trade-offs in a multi-central bank context.

The hybrid model is not without challenges. It introduces complexity in system design and requires robust key management for end-users. However, it offers a pragmatic path forward, providing the central bank with necessary oversight while enabling a modern, flexible, and inclusive digital payments infrastructure. Developers and policymakers must collaborate closely, using iterative prototyping on testnets like Hyperledger Besu or Corda to refine the technical and policy frameworks before any live deployment.

The account-based model is the digital equivalent of a traditional bank account. Access and transactions are tied to a verified identity. This model provides strong anti-money laundering (AML) and know-your-customer (KYC) controls, as the central bank or a regulated intermediary can monitor and control account activity. It's ideal for wholesale settlements and large-value transactions where counterparty verification is paramount. The core technology is a permissioned ledger where account states (balances) are updated by authorized validators.

Conversely, the token-based model mirrors physical cash. Value is stored in a digital token (like a UTXO or an NFT) that can be held in a digital wallet and transferred peer-to-peer without an intermediary verifying the holder's identity for each transaction. This offers greater privacy for users and efficiency for small payments. The technological foundation is a form of digital bearer instrument, often implemented using smart contracts on a blockchain that can validate the token's authenticity and ownership cryptographically.

A hybrid CBDC architecture seeks to leverage the strengths of both models. A common design uses a two-tier system: the wholesale, interbank layer is account-based, managed by the central bank on a permissioned ledger. The retail layer is token-based, where commercial banks or payment service providers issue digital tokens to the public, backed by reserves in the wholesale system. This separation allows for regulated issuance with the flexibility of tokenized peer-to-peer payments.

Core technologies enabling this include permissioned blockchains like Hyperledger Fabric or Corda for the account-based layer, and tokenization standards like ERC-20 or a custom central bank ledger for the token layer. A critical linking component is a secure mint-and-burn mechanism, where a token is only issued (minted) when a corresponding amount is debited from a reserve account, and burned when redeemed. Privacy-enhancing technologies (PETs) such as zero-knowledge proofs can be integrated to allow for transaction validation without exposing personal data on the token layer.

From a development perspective, architecting the interface between the two systems is key. A smart contract on the token ledger must have authorized, cryptographically-secured access to trigger mint/burn functions on the account ledger (or via a trusted oracle). For example, a user requesting digital cash from their bank account would trigger a process where the bank's reserve is debited on the account ledger, and a mint function is called on the token contract to create the corresponding digital token in the user's wallet.

Successful implementation requires clear legal frameworks defining the roles of the central bank, commercial intermediaries, and end-users, as well as robust cybersecurity measures for key management and transaction finality. The hybrid model is being explored by several central banks, including the European Central Bank's digital euro investigation and the Bank for International Settlements' Project Tourbillon, which experiments with these exact architectural trade-offs.

A hybrid CBDC model operates on a single, unified ledger that supports two distinct but interoperable representations of value: account-based balances and token-based UTXOs. The account layer is managed by a central authority (e.g., a central bank) and links funds to verified identities, enabling features like interest accrual, programmable monetary policy, and loss recovery. The token layer functions as a bearer instrument, allowing for offline-capable, private peer-to-peer transactions similar to cash. The ledger's core innovation is a synchronization engine that ensures a fungible unit of currency can move seamlessly between these two representations without creating or destroying money.

The foundational data model requires two primary tables with a linking mechanism. The accounts table stores (account_id, verified_identity_data, on_ledger_balance). The token_utxos table stores (utxo_id, value, owner_public_key, spent_flag). A critical third table, the hybrid bridge registry, maps relationships: (account_id, linked_utxo_id, conversion_timestamp). When a user converts balance to tokens, the system debits their on_ledger_balance, creates a new UTXO, and records the link. This registry is essential for audit trails, proving the token's legitimate origin from a sanctioned account, which is a key anti-money laundering (AML) requirement.

Transaction logic differs per layer. For account-based transfers, the system validates sender identity and balance, then updates ledger entries atomically. For token-based transfers, the system validates cryptographic signatures against the UTXO's owner_public_key and checks the spent_flag. The complex operation is the cross-layer transfer. Converting balance to token (account -> UTXO) requires: 1) an authorized debit transaction, 2) minting a new UTXO, and 3) recording the mint in the bridge registry. The reverse (UTXO -> account) requires: 1) a token proof-of-burn transaction, 2) crediting the associated account, and 3) updating the registry to close the loop.

Implementing this requires a dual-validation consensus mechanism. Account-layer transactions may use a permissioned consensus (e.g., Practical Byzantine Fault Tolerance) among validated nodes. The token layer, to support wider distribution, could use a ZK-Rollup or similar scaling solution anchored to the main ledger. Here, token transactions are batched and their validity is proven with a zero-knowledge proof, with only the proof and final state posted to the core ledger. This keeps the token system performant and private while maintaining a sovereign-grade audit trail on the primary account layer.

Key design considerations include privacy trade-offs. The account layer is inherently identifiable. The token layer can offer stronger privacy, but regulators may require selective disclosure via the bridge registry. For example, law enforcement with a warrant could query the registry to find the account that minted a specific UTXO. Offline functionality is another major consideration. Token wallets can use secure hardware to sign offline transactions, which are later settled on the network, while account access always requires an online connection to the central ledger for identity verification.

A hybrid Central Bank Digital Currency (CBDC) model combines the account-based system's regulatory clarity with the token-based system's programmability and peer-to-peer transfer capabilities. The core architectural challenge is designing a secure, atomic conversion mechanism that allows a digital currency unit to exist in either state. This is typically implemented using a smart contract on a permissioned blockchain or distributed ledger technology (DLT) platform like Hyperledger Fabric or Corda, which acts as the system's single source of truth for all CBDC holdings.

The conversion mechanism is governed by a smart contract we'll call the HybridLedger. This contract maintains two parallel ledgers: an account ledger mapping user identifiers to balances, and a token ledger tracking the ownership of unique, non-fungible token (NFT) representations of CBDC units. A critical design pattern is the burn-and-mint model. When converting from token-based to account-based, the user's token is permanently destroyed (burned) and their account balance is credited. The reverse process mints a new token and debits the account, ensuring the total money supply is conserved.

Here is a simplified Solidity-style pseudocode structure for the core conversion functions:

solidityCopy
function tokenToAccount(address user, uint256 tokenId) public {
    require(ownerOf(tokenId) == msg.sender, "Not token owner");
    _burn(tokenId); // Destroy the token
    accountBalance[user] += TOKEN_VALUE; // Credit the account
    emit ConvertedToAccount(user, tokenId);
}

function accountToToken(address user) public {
    require(accountBalance[user] >= TOKEN_VALUE, "Insufficient balance");
    accountBalance[user] -= TOKEN_VALUE; // Debit the account
    uint256 newTokenId = _mint(user); // Create a new token
    emit ConvertedToToken(user, newTokenId);
}

These functions must be permissioned, allowing only the central bank or authorized intermediaries to invoke them, and must include robust identity verification checks linking the blockchain address to a verified real-world identity.

For the system to be practical, the token standard must be carefully chosen. A common approach is to use a non-fungible token (NFT) where each token has a unique ID and a fixed, underlying value (e.g., 1 CBDC unit). This provides auditability and prevents double-spending. Alternatively, a semi-fungible token standard (like ERC-1155) could be used to batch denominations. The token's metadata should include essential regulatory information, such as the issuing authority, creation timestamp, and any travel rule or compliance data required for cross-border transactions.

Security and finality are paramount. The conversion transaction must be atomic—it either fully succeeds or fully fails, with no intermediate state where value is duplicated or lost. This is achieved by the all-or-nothing execution of the smart contract. Furthermore, the system must integrate with a robust digital identity layer (e.g., a decentralized identifier or verified credential system) to ensure the address in the account ledger is irrevocably tied to a known entity. This prevents anonymous users from holding account-based balances, maintaining the regulatory distinction between the two models.

In production, this architecture would be extended with features like transaction limits, tiered access controls for different user types (retail, wholesale), and integration with legacy real-time gross settlement (RTGS) systems. The hybrid model's power lies in this conversion gateway, enabling use cases like programmable welfare payments (via account-based issuance) that the recipient can then convert to token-based CBDC for offline or peer-to-peer commerce, all within a single, unified monetary system.

Central Bank Digital Currencies (CBDCs) present a fundamental design choice: account-based or token-based systems. An account-based CBDC, like a traditional bank account, identifies the holder and records balances in a central ledger. A token-based CBDC, analogous to physical cash, is a digital bearer instrument where possession implies ownership, offering greater privacy. A hybrid model architecturally combines both, enabling transactions with varying levels of privacy and identification to meet different use cases and regulatory requirements. This approach is central to proposals from institutions like the European Central Bank for a digital euro and the Bank for International Settlements in its Project Tourbillon.

The core technical challenge is implementing a system where the central bank or regulated intermediaries can selectively access transaction data. In a pure token-based system, this is impossible by design. The hybrid model solves this by using programmable digital tokens on a distributed ledger. Each token can carry embedded logic, such as a RegulatoryCompliance smart contract. For low-value, peer-to-peer payments, tokens can be transferred pseudonymously. For high-value transactions, crossing a threshold, or interacting with a regulated entity, the token's logic can require the sender to provide verified identity credentials to an authorized validator before the transaction is finalized.

Architecturally, this requires a layered approach. The settlement layer, often a permissioned distributed ledger technology (DLT) like Hyperledger Fabric or Corda, records the definitive ownership of all CBDC units. The transaction layer handles user interactions through wallets. Here, the hybrid model is implemented: wallets can hold both identified account balances and unlinkable digital tokens. A critical component is an identity layer using verifiable credentials (VCs) and zero-knowledge proofs (ZKPs). For example, a user could prove they are over 18 or are not on a sanctions list without revealing their full identity, using a ZKP-SNARK circuit to generate a proof that is checked by the token's compliance smart contract.

For developers, implementing a compliance check in a token's smart contract is key. Consider a simplified Solidity example for an ERC-20 like CBDC token with a gated transfer function. The contract would store a threshold and have a function to verify a proof.

solidityCopy
// Pseudo-code for a compliant token transfer
function transferWithCompliance(address to, uint256 amount, bytes calldata zkProof) public {
    if (amount > COMPLIANCE_THRESHOLD) {
        require(
            ComplianceVerifier.verifyThresholdProof(msg.sender, zkProof),
            "Compliance proof required for large transfer"
        );
        // Log compliant transaction for auditor
        emit LargeTransfer(msg.sender, to, amount);
    }
    _transfer(msg.sender, to, amount);
}

The ComplianceVerifier contract would validate the zero-knowledge proof, confirming the user has a valid, unexpired credential from a trusted issuer without learning the user's identity.

The final architectural consideration is data governance and access. Transaction data on the ledger should be encrypted or hashed. Access to the plaintext data or the ability to link transactions to an identity should be controlled via on-chain access policies. For instance, a financial intelligence unit could be granted a decryption key via a multi-signature smart contract, requiring approval from a judge and the central bank to activate for a specific investigation. This creates a transparent, auditable trail for any privacy intrusion, balancing the need for anti-money laundering (AML) and counter-terrorist financing (CTF) oversight with fundamental privacy rights. The hybrid model, therefore, is not just a technical design but a framework for encoded legal and policy principles.

Implementing a hybrid CBDC requires careful consideration of the interoperability layer between the two ledgers. A common approach is to use a settlement bridge—a set of smart contracts or a dedicated module within the central bank's core ledger. This bridge manages the atomic locking of funds on the account ledger and minting of equivalent tokens on the token ledger (and vice-versa). The design must ensure finality and prevent double-spending across systems, often using cryptographic proofs like Merkle proofs or zero-knowledge validity proofs for state verification.

For developers, the next step is to prototype using existing blockchain frameworks. You could model the account-based layer with a permissioned chain like Hyperledger Fabric or Corda, which offer strong identity and privacy controls. The token-based layer can be built using a modified version of Ethereum (e.g., a private EVM instance) or a dedicated UTXO-based chain for its inherent privacy features. The key is to implement the bridging logic, perhaps as a set of Solidity contracts for the token side and chaincode for the account side, ensuring they reference a common, authoritative oracle for exchange rate and policy data.

Future exploration should focus on advanced privacy and regulatory compliance. Techniques like zero-knowledge proofs (e.g., zk-SNARKs) can enable selective disclosure for the token layer, allowing for audits without revealing all transaction details. Furthermore, integrating programmable policy hooks—smart contracts that enforce monetary policy, transaction limits, or geographic restrictions—will be crucial. These hooks can be triggered during the bridge transfer process, making the system adaptable to different economic conditions.

Testing and simulation are critical. Before any live deployment, use a digital sandbox to stress-test the system under various conditions: - High transaction volume spikes - Bridge failure scenarios - Attempted double-spend attacks - Changes in monetary policy parameters. Tools like Cadence for Flow or the Hyperledger Caliper benchmarking framework can be instrumental in this phase.

The architectural journey doesn't end at deployment. A hybrid CBDC system must be designed for continuous evolution. This includes planning for upgrade mechanisms for core smart contracts without disrupting service, establishing clear governance processes for protocol changes, and designing monitoring dashboards that provide the central bank with real-time visibility into both ledger layers while preserving user privacy where required.