出典: Beosin

2025年8月1日、香港におけるステーブルコイン発行者に対する規制体制が正式に施行されました。同時に、香港金融管理局（HKMA）の「認可ステーブルコイン発行者に対する監督ガイドライン」および「 マネーロンダリング及びテロ資金供与対策ガイドライン（認可ステーブルコイン発行者に適用）」も施行され、ステーブルコイン発行者に対する詳細な規制指針を提供することを目指しています。

「認可ステーブルコイン発行者監督ガイドライン」は、香港におけるステーブルコインの規制枠組みに関する詳細な技術仕様を規定しており、ステーブルコインの価値安定性（完全準備金）、償還能力（適時償還）、リスク分離（準備資産の独立性）、消費者保護といった規制目標の確保を目指しています。以下は、Beosinセキュリティチームによる「認可ステーブルコイン発行者監督ガイドライン」におけるブロックチェーン技術仕様の解釈と監査計画であり、ライセンシーがガイドラインに定められたブロックチェーン技術要件を満たすための支援となります。

1. ブロックチェーンの技術仕様の解釈

マネーロンダリングおよびテロ資金供与対策に関するガイドラインの第 2.1 条、第 3.3 条および第 5.4 条に従い、ライセンシーはリスクベースのアプローチを採用し、事業の性質、規模、複雑さに基づいてマネーロンダリングおよびテロ資金供与対策のポリシー、手順、管理措置を策定および実施し、発行時および償還時に効果的な取引監視システムを実装して疑わしい取引を特定して報告し、関連するマネーロンダリングおよびテロ資金供与リスクを効果的に管理および軽減する必要があります。

1. 分散型台帳

規制ガイドラインでは、ステーブルコイン発行ネットワークとして特定の分散型台帳（イーサリアムなど）を指定していません。ただし、第6.5.5条では、ライセンシーが分散型台帳のセキュリティと信頼性（一般的な攻撃への耐性、コード欠陥の存在、悪用リスクなど）について詳細な評価を行うことを明示的に推奨しています。

ライセンシーは、ステーブルコインが発行される分散型台帳を厳密に評価し、安定性と市場実績が証明されたパブリックブロックチェーン上で運用される分散型台帳を優先する必要があります。さらに、ライセンシーは、分散型台帳に回復不能な障害が発生した場合にステーブルコインの償還を容易にするための追加措置を講じ、ステーブルコインエコシステムのセキュリティと安定性を確保する必要があります。

2. トークン管理

2.1 技術文書

ライセンシーが発行を予定している特定のステーブルコインごとに、ライセンシーは以下のことを明確に記録する必要があります。

• 使用されるトークン標準
• 特定のステーブルコインが発行される分散型台帳。
• ステーブルコインに関連するすべてのスマート コントラクトのアーキテクチャ (トークン コントラクト、プロキシ コントラクト、マルチ署名コントラクトなどを含む)。これには、アップグレード可能性 (ある場合)、状態変数、関数、関数修飾子、ライブラリ、インターフェイスなどが含まれます。

2.2 権限制御

「監督ガイドライン」の第6.5.3条では、ライセンシーは、発行する各ステーブルコインのライフサイクル管理全体に関連するすべての操作を明確に定義することが推奨されており、これには、展開、構成、鋳造、破棄、アップグレード、停止、復元、ブラックリストへの登録、ブラックリストからの削除、凍結、凍結解除、ホワイトリストへの登録、およびオペレーティングウォレットの使用が含まれます。

ステーブルコインのライフサイクルにおける各操作において、ライセンシーは適切なレベルの承認とトリガー条件を実装する必要があります。高リスクな操作（コントラクトのデプロイ／アップグレード、大規模なミント、アカウントの凍結など）は、マルチ署名契約（例：5人中3人の署名）を通じて実行する必要があります。

追加のリスク管理措置:

• 取引速度制限を設定する
• ホワイトリストに登録されたアドレスのみがコインを発行できる
• 特定の操作にタイムロックを設定する
• 特定の操作のトランザクションに事前署名し、トランザクションをブロードキャストする前にオフチェーンシミュレーション検証を実行し、署名されたトランザクションをチェックします。

2.3 技術監査

年次監査およびイベントドリブン監査：規制ガイドライン第6.5.5条では、ライセンシーは、発行済みステーブルコインに関連するスマートコントラクトの監査を、少なくとも年に1回、第三者の専門会社（Beosinなど）に委託することを推奨しています。さらに、特定のステーブルコインのスマートコントラクトが初めてデプロイ、再デプロイ、またはアップグレードされるたびに、速やかに監査を実施する必要があります。このアプローチは、内部監査のギャップを解消し、スマートコントラクトが設計どおりに正しく実行され、意図された機能を満たすことを保証し、コントラクトに脆弱性やセキュリティ上の欠陥がないことを高いレベルで保証することを目的としています。

2.4 ステーブルコイン監視システム

監督ガイドラインの第 6.5.6 条および第 6.8.3 条では、ライセンシーが、基盤となるテクノロジーの可用性、容量、パフォーマンス、および予想される更新や変更を継続的に監視し、異常(スマート コントラクトの脆弱性、ハード フォークやソフト フォークなどの分散型台帳関連のイベント、深刻なネットワークの輻輳、停止、攻撃、回復不可能な障害、秘密鍵の不正使用など) を報告するための対策を実施することを推奨しています。

3. キーセキュリティ

鍵管理（秘密鍵およびニーモニックを含む）は、規制ガイドラインの中で最も詳細かつ重要な領域の一つです。ライセンシーは、鍵の生成、配布、保管、使用、バックアップ、復旧、破棄など、鍵のライフサイクル全体をカバーする包括的な管理措置と運用手順を確立する必要があります。特に、ステーブルコインスマートコントラクトに関わる重要な操作（コントラクトの展開とアップグレード、権限とロールの管理、大規模な鋳造と破棄など）については、鍵のセキュリティを確保し、不正アクセスや潜在的なリスクを防止するために、より高いセキュリティ基準を採用する必要があります。

キーライフサイクルの推奨実装は次のとおりです。

• 鍵生成：重要な鍵については、生成プロセスは完全にオフライン環境で実行し、より高いレベルのセキュリティを適用する必要があります。実際には、シード鍵および／または秘密鍵の生成は、不正アクセスや漏洩を防ぐため、厳格な物理的セキュリティ管理が整備された物理的に隔離された環境で実行する必要があります。
• 鍵の保管：適切な認証メカニズムを備えたハードウェアセキュリティモジュール（HSM）鍵は、のような安全な保管媒体に保管する必要があります。保管場所は、厳格なアクセス制御および監視システムを備えた香港内、または香港金融管理局が承認した他の安全な場所に設置する必要があります。シード鍵や秘密鍵の管理に使用されるその他のハードウェアまたはソフトウェアデバイスも、同様に安全な環境で適切に保護する必要があります。マルチ署名スキームで使用される複数のニーモニック鍵や秘密鍵は、集中リスクを軽減するため、別々の安全な環境に保管する必要があります。
• 鍵配布：ライセンシーは、ニーモニックおよび／または秘密鍵の完全性と機密性を確保するために、安全かつ信頼性の高い方法で配布する必要があります。具体的な対策としては、完全性検証メカニズムの適用、物理的なセキュリティ対策（手動配布の場合）、および配布プロセス中の漏洩や改ざんを防止するための検証済みの暗号化アルゴリズムを用いた送信および保管などが挙げられます。
• 鍵の使用：ライセンシーは最小権限の原則を遵守し、鍵へのアクセスを厳格に制限する必要があります。鍵の漏洩や不正使用のリスクを軽減するため、鍵は信頼できる環境または物理的に隔離された安全な環境でのみ使用する必要があります。
• 鍵のローテーションと破棄：ライセンシーは、鍵の漏洩に伴うセキュリティリスクを軽減するため、鍵の定期的なローテーションを検討する必要があります。また、未使用または期限切れの鍵が完全に破棄され、不正な取得や悪用を防止するための鍵破棄プロセスを策定・実装する必要があります。
• 鍵のバックアップ：ライセンシーは、シード鍵および／または秘密鍵を香港内の複数の安全な場所（または香港金融管理局（HKMA）が承認したその他の場所）にバックアップする必要があります。バックアップの場所と内容は、第三者から厳重に機密に保持する必要があります。ライセンシーは、単一の物理的な場所にあるバックアップのみに頼ることで、シード鍵および／または秘密鍵を復元できないようにする必要があります。バックアップは信頼性の高い媒体に保存し、不正アクセスを防止するための必要なセキュリティ対策と、バックアップの整合性とセキュリティを確保するための改ざん防止機能を備える必要があります。

ステーブルコインセキュリティ監査プログラム

ステーブルコインのスマート コントラクト セキュリティと運用管理の要件に応えて、Beosin は次の監査ソリューションを立ち上げ、ライセンシーにブロックチェーン テクノロジーの詳細な監査と技術サポートを提供し、ライセンシーが HKMA の関連規制要件と運用基準を継続的に満たせるようにすることを目指しています。

1. スマートコントラクト監査

1.1 監査の範囲:

契約セキュリティ監査は以下をカバーします。

• ステーブルコインのコアコントラクト機能（鋳造、破棄、譲渡、凍結、停止など）
• 権限および役割管理システムの設計と実装
• アップグレードメカニズム（UUPS / 透過プロキシ）
• 緊急メカニズム関連機能（一時停止、フリーズ、ブラックリスト、ホワイトリストなど）
• イベント記録とオンチェーン行動のトレーサビリティ
• インターフェース標準の互換性（ERC 20、許可、メタデータなど）

1.2 監査内容:

（１）鋳造と破壊

• mint() 関数を許可されたロールのみが呼び出せるかどうか。
• burn() は残高と総供給量を正しく減らします。
• バイパス パスまたはロジックの脆弱性はありますか (たとえば、エスカレーションによる権限チェックのバイパスなど)。
• オフチェーン入金確認 (PoR 署名や管理者確認など) をサポートするかどうか。

（2）転送ロジック

• transfer() と transferFrom() が ERC 20 標準に準拠しているかどうか。
• 凍結されたアドレスまたはブラックリストに登録されたアドレスが転送を開始できないようにするかどうか。
• 一時停止状態でトークンの移動を効果的に防止できるかどうか。

（３）懸濁および凍結

• pause() / unpause() および freeze() / unfreeze() が特定のロールに対して制限されるかどうか。
• 一時停止状態で、トークンの転送、鋳造、破棄などの操作を完全に停止できるかどうか。
• アドレス凍結機能が送金や鋳造に有効かどうか。

1.2.2 権限構造と役割管理

（１）役割の定義（網羅的ではない）

• 管理者: 最高権限を持ち、すべてのロールとアップグレード操作を管理します。
• MINTER: トークンを発行する権利。
• PAUSER: 契約を一時停止および再開する権利。
• FREEZER: アドレスを凍結および凍結解除する権利を持ちます。
• UPGRADER: 契約のアップグレードを開始する権利を持ちます。

（2）権限設定チェック

• 展開または初期化中にすべてのロールが適切に割り当てられていますか?
• 単一点制御の喪失を回避するために、高権限ロールはマルチ署名ウォレットによって制御されていますか?
• 失効および緊急交換 (タイムロック管理など) をサポートするかどうか。

（３）マルチ署名とタイムロック制御

• 鋳造やアップグレードなどの機密性の高い操作には、マルチ署名 + タイムロック プロセスが必要ですか?
• タイムロックの遅延が 48 時間以上であれば、ライセンシーと規制当局が監視して対応しやすくなります。
• 契約で安全なアップグレード プロキシ モード (UUPS など) が使用されているかどうか。
• initialize() 関数に初期化修飾子が追加されているかどうか。
• 二次初期化のリスクはありますか？
• _authorizeUpgrade() 特定のロールによる呼び出しのみを許可するかどうか。
• 変数の上書きを防ぐために、アップグレード前後のストレージ構造が一貫しているかどうかを確認します。

1.2.4 イベントログと操作追跡

すべてのキー操作が明示的なイベントを発行するかどうか。

推奨イベントは以下の通りです。

• Mint(送信先アドレス、uint 256 金額、送信先アドレス)
• Burn(アドレス開始, uint 256 量, アドレス終了)
• 一時停止(アドレス指定) / 一時停止解除(アドレス指定)
• フリーズ(アドレス対象、アドレス指定) / フリーズ解除(アドレス対象、アドレス指定)
• アップグレード(アドレスnewImpl、アドレスby)
• 各イベントの提案には、演算子、ターゲット アドレス、タイムスタンプ、詳細なパラメータが含まれます。
• ログ情報は、監査の追跡と規制のレビューを容易にします。

1.2.5 標準インターフェースの互換性

• ERC 20 標準インターフェースが完全に実装されているかどうか (名前、シンボル、小数点、balanceOf など)。
• EIP-2612 (許可、ガス認可なし) がサポートされているかどうか。
• ウォレットの識別と表示に ERC 20 メタデータがサポートされているかどうか。
• すべての標準インターフェースが仕様どおりに値を返し、異常な入力を処理するかどうか。

2. 運用・保守ガバナンスとセキュリティ戦略のアップグレード

2.1 監査範囲

長期的な運用保守プロセスにおいて、ステーブルコイン契約システムのガバナンス構造設計、権限管理ロジック、契約アップグレードプロセスのセキュリティ、主要な運用管理メカニズムに重点を置きます。これにより、プロジェクトが持続可能な運用保守能力と、権限濫用やバージョンハイジャックなどのリスクに抵抗するメカニズムを備えることを目指します。

2.2 監査内容

• 契約アップグレード計画:安全なアップグレード モード (UUPS や透過プロキシなど) が使用されているかどうかを評価し、アップグレード機能に権限制御とアクセス制限があるかどうかを確認し、ロジック コントラクトとプロキシ コントラクトのストレージ レイアウトが一貫しているかどうかを確認して、ストレージ競合のリスクを回避します。
• アップグレード権限の境界と承認メカニズム:アップグレード操作が特定のロール (UPGRADER など) に制限されているかどうか、_authorizeUpgrade() などのメカニズムが承認保護に使用されているかどうかを確認し、そのような権限が他のロジックによってバイパスされていないことを確認します。
• 高権限操作制御メカニズム：キャスト、アップグレード、フリーズなどの操作が独立した役割によって管理され、多重責任による権限の乱用リスクを回避するなど、システムが権限の分離と最小権限の原則を備えているかどうかを確認します。
• マルチ署名ウォレットとタイムロックの構成:キー権限 (ADMIN や UPGRADER など) がマルチ署名ウォレットによって制御されているかどうか、また、ガバナンス観察期間とリスクバッファーを導入するために、タイムロック契約を通じてキー操作の遅延ウィンドウが拡大されているかどうかを確認します。
• ロール システムと権限ライフサイクル管理:長期的な運用および保守ロールと一時的なロール (運用アカウント、アップグレード管理者など) が明確に分割されているかどうかを評価し、ロールが長期間にわたって制御不能になることを防ぐための権限の譲渡、取り消し、回復のメカニズムがあるかどうかを確認します。
• 緊急管理メカニズム:潜在的な攻撃、外部のセキュリティ インシデント、または内部の運用エラーによってもたらされるシステム リスクを防ぐために、契約の一時停止、ロールの凍結、権限の取り消しなどの緊急対策がサポートされているかどうかを分析します。
• アップグレード動作記録と監査ログ:アップグレードおよび運用とメンテナンス関連のイベントにオンチェーン ログ (Upgrade、GrantRole、Pause など) があるかどうかを確認し、イベント後の追跡可能性を確保し、監査とコンプライアンス調査を容易にします。
• オンチェーンガバナンスの適応性と拡張性:将来的にオンチェーンガバナンスモジュールを導入する予定がある場合は、現在の権限構造がガバナンス契約の引き継ぎ操作をサポートしているかどうか、またガバナンス結果に基づいてアップグレード、取り消し、凍結などの操作をトリガーできるかどうかを評価することをお勧めします。

3. ログ分析とリスク監視

3.1 監査範囲

Beosin は、運用中のステーブルコイン契約のオンチェーン動作ログとそこから生じるリスクに焦点を当て、ログ収集、動作モデリング、リスク識別、コンプライアンス報告、リアルタイム監視システム サービスを提供し、ライセンシーが包括的な運用追跡可能性、視覚的なリスク管理、コンプライアンス対応機能を持つことを保証します。

• オンチェーンログ収集と分析

契約によってトリガーされるオンチェーンイベント（Mint、Burn、Transfer、Freeze、RoleGrantedなど）に基づいて、ステーブルコインのライフサイクル全体の操作記録が確立され、異なる契約バージョンと異なる展開環境のログ互換性分析がサポートされます。

• 自動行動分析

ログとオンチェーン状態のスナップショットを組み合わせることで、動作モデリングを使用して、異常な操作パス、異常なトランザクション頻度、その他の疑わしい/リスクの高い動作を自動的に識別します。

• リスクレベルの識別とレポート生成

時間、アドレス、トランザクションハッシュ、操作タイプ、許可パスなどの情報を含む標準化された動作監査レポートを出力し、プロジェクト関係者が保管し、HKMAがレビューできるようにします。また、運用リスクレベルも同時にレポートにマークされ、プロジェクトの内部参照に使用されます。

• 監視システムの統合と警報機構

Beosinは専用のオンチェーン監視システムを提供し、複数の指標（大規模鋳造、異常な破壊、権限変更、ブラックリスト取引のトリガーなど）をリアルタイムで監視します。設定されたリスク閾値に達すると、システムは直ちにアラームを発し、プロジェクトがタイムリーに対応できるよう支援します。