Wholesale CBDC Application Workflow
After you install and configure the sample wholesale CBDC application, you can use it in scenarios where a system owner (a central bank) and participant organizations (other financial institutions) interact in an interbank market.
The sample application supports eleven roles, or personas. Each role has a different interface and set of operations that support the entire workflow of token management in the wholesale CBDC scenario.
System Roles
- System administrator: Manages the entire system.
- System creator: Creates tokens. After a creation request is submitted, it is sent to the system manager, who either approves or rejects the request. After the minting request is approved, tokens are credited to the system creator's account. The creator can then transfer these tokens to a system issuer.
- System manager: Approves or rejects requests for minting, burning, and holding tokens. Hold request approvals are used for transfers between organizations.
- System issuer: Transfers tokens to financial institution officers or to the system retirer for burning. Users in this role receive tokens from the system creator and financial institution officers. The system manager must approve any transfers between organizations.
- System auditor: Has read-only access to all organizational data in the system.
- System retirer: Burns tokens. This role receives tokens from the system issuer. After a burn request is submitted, it is sent to the system manager.
Organization Roles
- Organization administrator: Manages their specific organization.
- Organization officer: Receives tokens from the system issuer. They can transfer these tokens to users in any organization or return tokens to the system issuer. All transfers must be approved by the organization approver.
- Organization user: Receives tokens from the officers of their respective organizations. They can transfer these tokens to users and officers in any organization. All transfers must be approved by the organization approver.
- Organization manager: Approves or rejects hold requests for their specific organization. Hold requests and approvals are used for all transfers between or within organizations.
- Organization auditor: Has read-only access to data that is specific to their organization.
Onboarding
After you install, configure, and stage the application, complete the following steps to access the application.
- After the application is staged, navigate back to the home page.
- On the application dashboard, locate the staged application. The status is shown as Staged next to the application name.
- Click the drop-down menu under Staged and select the application name.
- Copy the link or open the staged application in a new browser tab or window to test and review the application.
In generic mode, all accounts are displayed and tracked by user IDs. In confidential mode, accounts are displayed and tracked by bank account IDs. Bank account IDs are random alphanumeric strings that are generated when the account is created. In confidential mode, the bank account ID replaces the user ID in the application interface.
In confidential mode, account balances are calculated
on-demand using a consolidation method
(consolidateRunningBalanceInTransactions
), which is defined in
the chaincode. When consolidation runs, all pending transactions are processed and
the account balance is updated. Account balances are available only after
consolidation is run for an organization. If consolidation has not run for an
organization, account balances are shown as Reconciliation
Pending.
The consolidateRunningBalanceInTransactions
method consolidates account balances for the caller's organization. This method can be called by a Token Admin
or Org Admin
. System owners must authenticate using the SYSTEM_ADMINS
user account that is associated with the tokenAdmin
token role. Participant organizations must authenticate using their respective ORG_ADMINS
user accounts, each of which is associated with the orgAdmin
token role.
To keep account balances accurate across the network, the consolidation method must be run at regular intervals. You can use the scheduleTransactions
REST API endpoint in Oracle Blockchain
Platform to run consolidation automatically. For best results, set the scheduler to run every two minutes, and set the expiry string to a high value such as 120M (ten years). For more information, see Schedule Transaction to Run.
Invalid Account. Please Contact Admin
The
interface that is displayed after a user logs in depends on their role.The first time that any user attempts to log in to the application, no user accounts have been created yet. Only users from the System_Admins
group who also have the tokenAdmin
role assigned to them can log in. All other login attempts will fail. The following section includes more information about the exception for the SYSTEM_ADMINS
persona.
System_Admins
Exception
The login process is different for users with the SYSTEM_ADMINS
persona. Users in the System_Admins
group can log in even if their account has not yet been created, but these users must have the tokenAdmin
role.
When you deploy the chaincode, ensure that users in the System_Admins
group have the tokenAdmin
role. The parameters that are passed during chaincode initialization must include the system administrator users as having the tokenAdmin
role. This allows the System_Admins
group to log in to the application for the first time to create the other user accounts.
If you log in to the application as a user in the System_Admins
group, and that user was not included as an initialization parameter when the chaincode was deployed, you must manually assign the tokenAdmin
role to the user. You can manually assign the tokenAdmin
role by using a Postman collection.
Application Workflow
The following steps show the actions of the various roles in a complete application workflow. The first seven steps must be completed to use the application.
- The system administrator logs in.
- The system administrator initializes the token.
- The system administrator creates their own bank account and then reloads the home page to see the updated network details.
- The system administrator creates bank accounts for all CBDC
personas, as shown in the following table.
Application Group Role System_Admins
Token Admin
System_Auditors
Token Auditor
System_Creators
Minter
System_Managers
Escrow
System_Issuers
none System_Retirers
Burner
- The system administrator creates organization administrator bank
accounts, which have the
Org Admin
role. - Confidential mode only: The system administrator and organization administrators configure the scheduler to run consolidation automatically. This ensures that displayed account balances are accurate. For more information, see Schedule Transaction to Run.
- The organization administrator logs in and creates accounts for users of their organization.
- The system administrator assigns roles to the new organization
users, as shown in the following table.
Application Group Role Org_Admins
Org Admin
Org_Users
none Org_Officers
none Org_Managers
Escrow
Org_Auditors
Org Auditor
- The system creator logs in and requests that tokens be minted.
- The system manager logs in and approves or rejects the minting request. If the request is approved, the tokens are credited to the system creator.
- The system creator transfers the tokens to the system issuer.
- The system issuer logs in and transfers the tokens to an organization officer. If the transfer is approved by the system manager, the tokens are transferred. Alternately, the system issuer can transfer the tokens to the system retirer for burning.
- The system auditor logs in, selects auditing policies, and reviews the relevant transaction data.
- The system retirer logs in and requests that tokens be retired. If the system manager approves, the tokens are burned.
- The system manager logs in and approves or rejects the request to issue tokens. If the transfer is approved, tokens are credited to the organization officer, who can then transfer them to organization users.
- The organization officer logs in and transfers tokens to organization users, other organization officers, or back to the system owner. All transfers require the approval of the organization manager.
- The organization manager logs in and approves or rejects transfer requests.
- organization users log in and transfer tokens to other organization users at any organization.
- The organization auditor logs in, selects auditing policies, and reviews the relevant transaction data.