Stablecoin Application Workflow

A stablecoin is a fungible token that represents digital currency with built-in compliance enforcement.

The stablecoin scenario enforces know your customer (KYC) and anti-money laundering (AML) policies, transfer restrictions, and multi-party approvals. The system supports direct transfers and hold-based transfers, which require approval before the transfer occurs.

  • Minter, burner, and notary roles are required.
  • The account policy enforces KYC/AML and restriction flags.
  • The approval policy defines thresholds and sequential approver requirements for hold-based transfers.
  • Transfer restrictions are optional and can be configured at any time.
  • Approval policy matching is used to determine whether approvals are required when the holdTokens API is used.
  • Transaction history APIs support auditing and monitoring.
The following table summarizes the actors in this scenario.
Actor Role Description
Administrator Token Admin Initializes the system, assigns roles, creates account and approval policies.
Minter Minter Requests minting of tokens.
Mint Approver Notary Approves or rejects mint requests.
Burn Approver Notary Approves or rejects burn requests.
Sender none Initiates direct or hold-based transfers.
Approver none Approves transactions in a defined sequence. Approvers are regular account holders who specified as approvers in the approval policy (not by an assigned role).
Notary Notary Completes or releases hold-based transfers after approval.
Receiver none Receives transferred tokens.
Auditor Token Auditor Queries transaction history for compliance and reporting purposes.
The administrator completes the following steps to initialize the system.
  1. Initialize a stablecoin by using the initializeStablecoinToken API.
  2. Register organizations by using the registerOrg API.
  3. Create accounts by using the createAccount and associateTokenToAccount APIs.
  4. Assign the minter, burner, and notary roles to the appropriate accounts by using the addRole API.
  5. Create account policies by using the createStablecoinAccountPolicyCheck API.
  6. Create approval policies by using the createApprovalPolicyCheck API.
After the system is initialized, a typical process flow follows these basic steps.
  1. Mint stablecoins.
    1. The minter uses the requestMint API to submit a request to mint stablecoins.
    2. The mint approver uses the approveMint API to review and approve the request to mint stablecoins. Alternately, the mint approver can use rejectMint API to deny the request.
  2. Transfer stablecoins without approvals.
    • The sender uses the transferTokens API to send stablecoins to a user.
  3. Transfer stablecoins with approvals.
    1. The sender uses the holdTokens API to request transfer of the tokens.
    2. If required, approvers use the approveTransaction API to approve the transfer, as specified by the approval policy.
    3. The notary uses the executeHoldTokens API to approve the transfer request. Alternately, the notary can use the releaseHold API to reject the transfer.
  4. Verify token balance.
    • Users can use the getAccountBalance API to get the amount of stablecoins they hold.
  5. Burn tokens.
    1. Users can use the requestBurn API to submit a request to burn their stablecoins.
    2. The burn approver uses the approveBurn API to review and approve the request. Alternately, the burn approver can use rejectBurn API to deny the request.
  6. Audit the transaction history.
    • Auditors and users can use the getAccountTransactionHistory and getAccountTransactionHistoryWithFilters APIs to get transaction history for auditing and reporting.

Account Policy Validation

Account policies are mandatory for all accounts that transfer or hold stablecoins. Account policies are validated in the following APIs: transferTokens, holdTokens, approveTransaction, executeHoldTokens.

Each account policy includes three parameters: KYC, AML, and restrictionFlag. These are validated for both sender and receiver before any tokens are transferred.

KYC (Know Your Customer)
The transfer is allowed only when KYC values are true for both the sender and receiver accounts.
AML (Anti-Money Laundering)
The transfer is allowed only when AML values are true for both the sender and receiver accounts.
restrictionFlag
If the restriction flag is set to false for both the sender and receiver account, validation passes. If the restriction flag is set to true for either the sender or receiver account, for the holdTokens, approveTransaction, and executeHoldTokens APIs, the transfer is allowed only if a lowest available approval policy exists and if the amount is within the policy limits. Otherwise, the transfer is blocked. For the transferTokens method, the transfer is allowed only if the amount is in the lower and upper bounds of the transfer restriction limits.

Approval Policy Matching

Approval policy matching is triggered after a call to the holdTokens API. Approval policies define transaction thresholds, required numbers of approvals, and approver details, and set the sequence for multi-level approvals. An approval policy is mandatory for a hold operation. Without an approval policy, users cannot hold or transfer tokens when restrictions apply.

Approval policy matching determines whether approvals are required before the notary can complete the hold transfer. If approvals are required, approval policy matching determines which approvers are needed and in what sequence.

If no restriction flag is set for both sender and receiver, the hold amount is compared against all configured approval policy thresholds to find a match. If a match is found, the corresponding approvers and sequence are used. If no match is found, no approval is required and the transaction proceeds directly to the notary.

If a restriction flag is set for either sender or receiver, the lowest available approval policy is used. If no policy is available, the transaction is blocked.

After a policy match is determined, the following details are extracted from the policy for use in the approval process:
  • Required approvers
  • Approval sequence
  • Required number of approvals

Transaction Approval

Transaction approval validation is triggered after a call to the approveTransaction API. The validation enforces all of the approval rules that are defined in the approval policy that was matched during the call to the holdTokens API. The validation runs for each approver in sequence according to the following steps.

  1. Validate Approver Identity: Checks if the current user exists in the required approvers list from the approval policy.
  2. Validate Sequence Order: Checks if the current approver is the expected approver at the current sequence position.
  3. Check for Duplicate Approval: Prevents the same approver from approving the same transaction more than once.
  4. Account Policy Validation: Runs account policy validation again to ensure that the sender and Receiver account statuses have not changed since the hold was created.
  5. Record Approval: Records the approval with time stamp, increments the approval count, and checks if all required approvals are complete.
If all approvals are recorded, the transaction is marked ready for completion by the notary. If more approvals are needed, the next approver in sequence is awaited.