【技術者向けテックノート04】金融トークンはどう設計するのか

Mint、Burn、Freeze、Role、Proxy、監視・障害復旧を本番運用までつなぐ

ステーブルコインやトークン化預金を発行するというと、ERC-20コントラクトへMint機能を追加すれば実装できるように聞こえる。しかし、金融トークンの本番設計は、トークンを増減させるコードだけでは成立しない。
誰が発行できるのか。どの預金・準備資産を根拠に発行するのか。特定ウォレットを止めるのか、システム全体を止めるのか。誤送金や不正取得に対して残高を強制移転できるのか。コントラクトを更新するとき、既存残高を壊さずにロジックだけを差し替えられるのか。
さらに本番稼働後は、ノード、コントラクト、銀行側台帳を同時に監視し、異常時には停止、影響範囲特定、残高照合、補正、再開までを一つのRunbookとして運用する必要がある。第4号では、金融トークンを「発行するコード」から「本番運用できる制御システム」へ引き上げるための設計を分解する。

1．最初に結論

·         金融トークンは、Token Contractだけでなく、銀行側台帳、本人確認、権限、監視、照合を含む制御アーキテクチャである。
·         Mint、Burn、Freeze、Pause、Clawbackは別々の業務目的を持つ。単一の管理者機能としてまとめてはいけない。
·         本番では単一Ownerではなく、Role Based Access Control、職務分離、四眼承認、Timelock、Multisig等を組み合わせる。
·         アップグレード可能性は不具合修正に有効だが、管理鍵の侵害やStorage Layout破壊という新たなリスクを生む。
·         技術的に取引が成功していても、銀行側残高、Token Supply、顧客残高、会計、AML/CFTが一致しなければ業務完了ではない。

2．金融トークンの全体アーキテクチャ

金融トークンの中核は、アドレスごとの残高を管理する台帳である。しかし、銀行預金や法定通貨準備資産を裏付けにする場合、トークン台帳は単独で存在できない。銀行側の預金・準備資産、発行・償還指図、本人確認、移転制限、監視、照合が必要になる。

図の中央にあるToken Contractは、残高と移転を記録する実行層である。発行根拠を確認するのは銀行側または発行者側のControl Layerであり、移転可能性を判定するのはIdentity / Compliance Layerである。Eventを取得し、異常検知と残高照合を行うのはMonitoring / Reconciliation Layerである。
この分離を曖昧にすると、スマートコントラクトに過大な責任を持たせるか、逆にコントラクト外の運用が属人的になる。設計時には「どの状態をチェーンで正本とするか」「どの状態を銀行側で正本とするか」「差異が生じたとき誰が補正するか」を明示する必要がある。

3．Mint、Burn、Transfer、Redemptionを分けて考える

MintとBurnはToken Supplyを変えるため、Transferより強い権限管理が必要である。またRedemptionはBurnと同義ではない。顧客から償還依頼を受けた時点、トークンを拘束した時点、Burnした時点、銀行口座へ払戻した時点は、それぞれ異なる業務状態である。

実装では、各ステップを一つの同期処理に押し込むより、Request ID、Tx Hash、銀行仕訳ID、償還受付番号を関連付けた状態機械として管理する方が安全である。タイムアウトや障害が起きた場合に、どこまで完了したかを再現できるからである。

4．金融トークンに必要な制御機能

これらの機能を「発行者なら何でもできる管理機能」としてまとめると、管理鍵が一つ漏えいしただけで全顧客の資産を操作できる。機能ごとにRoleを分け、操作可能範囲、限度額、承認者、利用可能時間、実行後の監視を定義する。

5．無料部分のまとめ：設計対象はコントラクトではなく制御システム

金融トークンの設計をERC-20の機能一覧から始めると、本番運用に必要な論点が後から追加される。先に、発行・移転・償還・停止・強制措置・アップグレード・監視・照合という業務能力を定義し、それをコントラクト、銀行側システム、オペレーションへ配分するべきである。
·         何を正本とするか: Token Supply、顧客残高、銀行側預金・準備資産
·         誰が実行できるか: Mint、Burn、Freeze、Pause、Upgrade、Role変更
·         どう止めるか: システム全体、特定Wallet、特定機能、特定取引
·         どう戻すか: 再送、Burn、強制移転、銀行側補正、顧客補償
·         どう証明するか: Event、監査ログ、承認記録、照合結果、変更履歴
ここから有料
ここから先では、金融トークンの権限設計、Proxyアップグレード、Storage互換性、監視・障害復旧、照合までを実装レベルで分解します。