Stablecoinアプリケーションワークフロー

ステーブルコインは、コンプライアンスの実施が組み込まれたデジタル通貨を表す真菌性トークンです。

安定したコインのシナリオでは、顧客(KYC)とマネーロンダリング防止(AML)ポリシー、転送制限、マルチパーティの承認が強制されます。システムでは、直接振替と保留ベースの振替がサポートされており、振替が発生する前に承認が必要です。

  • Minter、Burner、Notaryの役割が必要です。
  • アカウント・ポリシーにより、KYC/AMLおよび制限フラグが強制されます。
  • 承認ポリシーは、保留ベースの転送のしきい値および順次承認者の要件を定義します。
  • 転送制限はオプションであり、いつでも構成できます。
  • 承認ポリシーの一致は、holdTokens APIの使用時に承認が必要かどうかを判断するために使用されます。
  • トランザクション履歴APIでは、監査および監視がサポートされています。
次の表に、このシナリオのアクターの概要を示します。
アクター ロール 説明
Administrator トークン管理 システムを初期化し、ロールを割り当て、アカウントおよび承認ポリシーを作成します。
マイナー マイナー トークンのミントを要求します。
ミント承認者 公証人 ミント要求を承認または否認します。
消化承認者 公証人 書き込み要求を承認または拒否します。
送信者 なし 直接または保留ベースの転送を開始します。
承認者 なし 定義済の順序でトランザクションを承認します。承認者は、承認ポリシーで(割り当てられたロールではなく)承認者として指定した通常のアカウント所有者です。
公証人 公証人 承認後に保留ベースの転送を完了またはリリースします。
受信者 なし 転送されたトークンを受け取ります。
監査者 トークン監査者 コンプライアンスおよびレポート目的でトランザクション履歴を問い合せます。
管理者は、次のステップを実行してシステムを初期化します。
  1. initializeStablecoinToken APIを使用してstablecoinを初期化します。
  2. registerOrg APIを使用して組織を登録します。
  3. createAccountおよびassociateTokenToAccount APIを使用してアカウントを作成します。
  4. addRole APIを使用して、minterロール、burnerロールおよびnotaryロールを適切なアカウントに割り当てます。
  5. createStablecoinAccountPolicyCheck APIを使用してアカウント・ポリシーを作成します。
  6. createApprovalPolicyCheck APIを使用して承認ポリシーを作成します。
システムの初期化後、一般的なプロセス・フローは次の基本ステップに従います。
  1. ミントのstablecoins。
    1. minterは、requestMint APIを使用してmint stablecoinsにリクエストを送信します。
    2. ミント承認者は、approveMint APIを使用して、ミントstablecoinsへのリクエストを確認および承認します。または、ミント承認者はrejectMint APIを使用してリクエストを拒否できます。
  2. 承認なしでstablecoinsを移動します。
    • 送信者は、transferTokens APIを使用してstablecoinsをユーザーに送信します。
  3. 承認付きでstablecoinsを転送します。
    1. 送信者は、holdTokens APIを使用してトークンの転送をリクエストします。
    2. 必要に応じて、承認者はapproveTransaction APIを使用して、承認ポリシーで指定された転送を承認します。
    3. 公証人は、executeHoldTokens APIを使用して転送リクエストを承認します。または、公証人はreleaseHold APIを使用して転送を拒否できます。
  4. トークンの残高を確認します。
    • ユーザーは、getAccountBalance APIを使用して、保持するstablecoinsの量を取得できます。
  5. トークンを書き込みます。
    1. ユーザーは、requestBurn APIを使用して、安定したコインを書き込むリクエストを送信できます。
    2. バーン承認者は、approveBurn APIを使用してリクエストをレビューおよび承認します。または、バーン承認者はrejectBurn APIを使用してリクエストを拒否できます。
  6. トランザクション履歴を監査します。
    • 監査者およびユーザーは、getAccountTransactionHistoryおよびgetAccountTransactionHistoryWithFilters APIを使用して、監査およびレポート用のトランザクション履歴を取得できます。

アカウント・ポリシー検証

アカウントポリシーは、ステーブルコインを譲渡または保持するすべてのアカウントに必須です。アカウント・ポリシーは、transferTokens、holdTokens、approveTransaction、executeHoldTokensのAPIで検証されます。

各アカウント・ポリシーには、KYC、AMLおよびrestrictionFlagの3つのパラメータが含まれます。これらは、トークンが転送される前に、送信者と受信者の両方で検証されます。

KYC (顧客身元確認)
転送が許可されるのは、送信者と受信者の両方のアカウントでKYC値がtrueの場合のみです。
AML (マネーロンダリング防止)
転送が許可されるのは、送信者と受信者の両方のアカウントでAML値がtrueの場合のみです。
restrictionFlag
送信者と受信者の両方のアカウントで制限フラグがfalseに設定されている場合、検証は成功します。送信者または受信者アカウントのholdTokens、approveTransactionおよびexecuteHoldTokens APIの制限フラグがtrueに設定されている場合、使用可能な最小の承認ポリシーが存在し、その量がポリシー制限の範囲内にある場合にのみ、転送が許可されます。それ以外の場合、転送はブロックされます。transferTokensメソッドの場合、転送が許可されるのは、その量が転送制限の下限と上限にある場合のみです。

承認ポリシー照合

承認ポリシーの一致は、holdTokens APIのコール後にトリガーされます。承認ポリシーは、トランザクションしきい値、必要な承認数および承認者詳細を定義し、複数レベルの承認の順序を設定します。保留操作には承認ポリシーが必須です。承認ポリシーがない場合、ユーザーは制限が適用されたときにトークンを保持または転送できません。

承認ポリシー照合によって、公証人が保留振替を完了する前に承認が必要かどうかが決まります。承認が必要な場合は、承認ポリシーの一致によって、必要な承認者と順序が決まります。

送信者と受信者の両方に制限フラグが設定されていない場合、保留金額が構成されたすべての承認ポリシーしきい値と比較され、一致が検索されます。一致が見つかった場合は、対応する承認者および順序が使用されます。一致するものが見つからなかった場合、承認は必要なく、トランザクションは公証人に直接進みます。

送信者または受信者に制限フラグが設定されている場合は、使用可能な最も低い承認ポリシーが使用されます。ポリシーを使用できない場合、トランザクションはブロックされます。

ポリシーの一致が決定されると、承認プロセスで使用するポリシーから次の詳細が抽出されます。
  • 必須承認者
  • 承認連番
  • 必要な承認数

トランザクション承認

トランザクション承認検証は、approveTransaction APIのコール後にトリガーされます。検証では、holdTokens APIのコール中に一致した承認ポリシーに定義されているすべての承認ルールが適用されます。次のステップに従って、各承認者の検証が順番に実行されます。

  1. Validate Approver Identity (承認者IDの検証): 承認ポリシーの必須承認者リストに現在のユーザーが存在するかどうかをチェックします。
  2. Validate Sequence Order(順序順序の検証): 現在の承認者が現在の順序位置で予想される承認者であるかどうかを確認します。
  3. 重複承認のチェック: 同じ承認者が同じトランザクションを複数回承認できないようにします。
  4. アカウント・ポリシー検証: アカウント・ポリシー検証を再度実行して、保留が作成されてから送信者および受信者のアカウント・ステータスが変更されていないことを確認します。
  5. レコード承認: 承認をタイム・スタンプで記録し、承認数を増やして、必要なすべての承認が完了しているかどうかを確認します。
すべての承認が記録されると、トランザクションは公証人によって完了準備完了としてマークされます。さらに承認が必要な場合は、次の承認者を順番に待ちます。