Daily Transaction Limits

You can restrict the number of transactions an account can complete daily, as well as the number of tokens that can be acted on. The max_daily_amount and max_daily_transactions input parameters to the createAccount method control this behavior. These parameters are optional.

You can achieve higher throughput if you do not set the daily transaction limits for an account.

Approval Requirements for Minting and Burning

You can set up approvals for minting and burning tokens, so that users with the minter or burner role must submit a request to an approver, instead of minting or burning tokens directly. Approvers can accept or reject requests to mint or burn tokens. To enable approvals for minting and burning, you use the mint_approval_required and burn_approval_required parameters in the specification file. You must then also specify values for mint_approver_role_name and burn_approval_role_name, as shown in the following example.

behavior: # Token behaviors
          - divisible: 
                decimal: 2  
          - mintable: 
                max_mint_quantity: 1000 
                mint_approval_required: true
          - transferable
          - burnable 
                burn_approval_required: true
          - holdable 
          - roles: 
                minter_role_name: minter
                notary_role_name: notary
                mint_approver_role_name: minter_notary
                burn_approver_role_name: burner_notary

When a burn request is made, the specified amount is immediately deducted from the available balance and added to the onhold_burn_balance field in the user's account object. If the request is approved, the tokens are burned. If the request is rejected, the tokens are returned from the onhold_burn_balance field to the available balance. You can use the getAccountOnHoldBurnBalance method to retrieve the account balance that is on hold for a particular user because of a burn request.

Fetching Transaction History from the Rich History Database

You can synchronize data to the rich history database and then fetch the data using chaincode API calls to retrieve transaction history from the rich history database. Before you can use these methods, you must run Oracle Autonomous Database with Oracle REST Data Services (ORDS) and OAuth enabled, as described in Oracle Database View Definitions for Wholesale CBDC.

Category and Description Attributes in Transaction Objects

• Category and description attributes must be included in the transferTokens, holdTokens, issueTokens, requestMint, requestBurn, burnTokens and rejectBurn methods in the controller file. The corresponding SDK methods must also include category and description attributes.
• The category and description attribute input is in the form of a JSON object named info_details, as shown in the following example.

  {
       "category" : "category input",
       "description" : "description input"
  }

• The info_details field is optional. You can pass only a category or only a description as needed.
• The GET methods related to any transactions for transferTokens, holdTokens, executeHold, releaseHold, requestMint, approveMint, rejectMint, requestBurn, approveBurn and rejectBurn must include category and description attributes in the payload response if they are present.
• The category field is limited 20 characters and the description field is limited to 250 characters.