Confidential Wholesale CBDC Application Workflow

The confidential wholesale central bank digital currency (CBDC) scenario represents currency that is distributed through a structured financial institution hierarchy, with sensitive information stored privately.

The confidential version of the wholesale CBDC scenario differs in how transaction data is handled. Non-sensitive information such as basic transaction details and organizational account information is stored on the public ledger. Sensitive information (such as user IDs, actual balance values, and blinding factors) is stored in each organization's private data collection and passed to the chaincode via a transient map, so that it is never written to the public ledger. Account balances and on-hold balances are represented as Pedersen commitment values on the public ledger, allowing public verification through zero-knowledge proofs without exposing the underlying amounts. At the central bank level, hold transfers use a two-phase commit process for an atomic transaction that requires simultaneous execution of both the executeHoldTokensSender and executeHoldTokensReceiver APIs, which maintains confidentiality throughout the transfer. Transfers at the financial institution level use the standard single executeHoldTokens API.

The following table summarizes the key differences between the non-confidential and confidential versions of the wholesale CBDC scenario.
Operation/Data Non-Confidential CBDC Confidential CBDC
Inter-Organization Transfer (central bank approver executes hold) executeHoldTokens API (single call) executeHoldTokensSender and executeHoldTokensReceiver APIs (two simultaneous calls done in two-phase commit)
Intra-Organization Transfer (financial institution approver executes hold) executeHoldTokens API (single call) executeHoldTokens API (single call, no difference)
Transaction Data on Ledger All data stored in plain form on the public ledger, no data separation Non-sensitive data on public ledger, sensitive data (user IDs, actual balances, blinding factors) stored in each organization's private data collection
Balance Representation Actual balance values stored directly Balances represented as Pedersen commitment values, actual amounts not exposed on the public ledger
Verification Method Direct: values are readable on the ledger Zero-knowledge proofs enable public verification without revealing underlying amounts
Sensitive Data Handling Stored on public ledger Passed via transient map to chaincode, not written to the public ledger

Note:

The executeHoldTokensSender and executeHoldTokensReceiver APIs must be called simultaneously as part of a two-phase commit process. Calling only one without the other results in an error.
The following table summarizes the actors in this scenario.
Actor Role Description
Administrator Token Admin Initializes the system, assigns roles.
Creator Minter Requests minting of tokens and receives minted tokens.
Central Bank Approver Notary Approves all operations at the central bank level.
Issuer none Receives tokens from the creator, routes tokens to the financial institution officer or retirer.
Financial Institution Officer none Receives tokens from the issuer, distributes tokens to financial institution users.
Financial Institution Approver Notary Approves hold transfers from financial institution officer to financial institution users.
Financial Institution User none Final recipient of transferred tokens at a financial institution.
Retirer Burner Receives tokens from the issuer and sends burn requests to the central bank approver.
The administrator completes the following steps to initialize the system.
  1. Initialize the CBDC system by using the initializeCBDCToken API.
  2. Register organizations by using the registerOrg API.
  3. Create accounts by using the createAccount API.
  4. Associate the token to accounts by using the associateTokenToAccount API.
  5. Assign the minter role to the creator, the notary role to the central bank approver, and the burner role to the retirer by using the addRole API.
After the system is initialized, a typical process flow follows these basic steps.
  1. Mint currency.
    1. The token creator uses the requestMint API to submit a request to mint deposit tokens.
    2. The central bank approver uses the approveMint API to review and approve the mint request. The tokens are credited to the creator's account. Alternately, the central bank approver can use rejectMint API to deny the request.
  2. Transfer tokens to the issuer.
    • The creator uses the transferTokens API send tokens to the issuer.
  3. Transfer tokens to financial officers.
    1. The issuer uses the holdTokens API send tokens to a financial institution officer.
    2. The central bank approver uses the executeHoldTokensSender and executeHoldTokensReceiver APIs as part of a two-phase commit to validate and approve the transfer request. Alternately, the central bank approver can use the releaseHold API to reject the transfer.
  4. Issue tokens to users.
    1. The financial institution officer uses the holdTokens API send tokens to a financial institution user.
    2. The financial institution approver uses the executeHoldTokens API to validate and approve the transfer request. Alternately, the financial institution approver can use the releaseHold API to reject the transfer.
  5. Burn tokens.
    1. The issuer uses the transferTokens API to transfer tokens to the retirer.
    2. The retirer uses the requestBurn API to send a burn request to the central bank approver.
    3. The central bank approver uses the approveBurn API to approve the burn request, and the tokens are destroyed. Alternately, the central bank approver can use the rejectBurn API to reject the request.
  6. Verify token balance.
    • Users can use the getAccountBalance API to get the total number of currency they hold.