文：@JayLovesPotato, Four Pillars
翻訳：AididiaoJP, Foresight News
核心ポイント
EVM上の規制準拠型トークン標準は、単一の統一仕様へと収束するのではなく、機能ごとに明確に分業化されている。したがって、ERC-1450、ERC-3643、ERC-7943は互いに競合する標準と見なすべきではなく、それぞれ発行、アイデンティティ、執行、統合を担う補完的なコンポーネントとして理解すべきである。
注：規制準拠型トークン標準とは、簡単に言えば「規制対象となるトークン」のために設計された技術仕様である。通常のトークン（例えば標準的なERC-20）は自由に送金・保有でき、ほぼ制限がない。しかし規制準拠型トークン（Regulated Token）は異なり、通常は現実の証券、ファンド持分、債券、RWA（現実資産）などの規制対象資産に対応し、トークンを「誰でも自由に送金できる」状態から「金融規制要件を満たす」技術ルールへと変える。
各チェーン間の重要な違いは、規制機能の有無ではなく、それらの機能が実装・実行される場所にある。EVMは個別の資産コントラクトレベルで高い柔軟性を保持し、SolanaやMoveベースのチェーンは多くの機能を共有トークンフレームワークに配置し、StellarやXRPLでは台帳に直接組み込まれ、CantonやAvalanche L1ではさらに市場やネットワーク運営層にまで拡張される。
規制準拠型トークン標準の競争力は、将来的には機能の数よりも、規制変更への適応の柔軟性によって決まる可能性が高い。より現実的な方向性は、コンプライアンススタックを構築することである。すなわち、凍結、強制転送、送金前検証などの繰り返し現れる執行機能を標準化し、同時にアイデンティティプロバイダー、管轄区域ルール、保有上限などのプロダクト固有のポリシーを交換可能なモジュールに分解する。
機関投資家が最も慣れ親しんでいるイーサリアムのEVM環境においてさえ、複数のERCが規制準拠型トークンの同様のニーズに対応している。それらは一般的に、送金制限、投資家資格チェック、凍結、強制転送、資産紛失時の復旧をサポートする。しかし、各標準が前提とする法的構造と運営権限には顕著な違いがある。
EVM以外でも、他のチェーンはトークンプログラム、台帳、またはネットワークレベルで同等の機能を追加し、規制対象資産の実装パスをさらに広げている。
これはある程度、規制準拠型トークン標準がまだ明確な構造を形成していないことを反映している。より根本的な理由は、規制対象資産に必要な機能を単一の仕様に押し込むのが難しいことにある。誰が証券の法的記録を管理するのか、どの機関が投資家資格を認証するのか、事故が発生した際に運営者がどの程度の制御権を保持すべきか――これらの問題はプロダクトや管轄区域によって異なる。
したがって、市場は、完全に自己完結した単一の標準を追求するのではなく、これらの機能を複数のレイヤーに分散させ、必要に応じて組み合わせるアーキテクチャへと向かっている。
EVM上の規制準拠型トークン標準
初期の標準の多くは、従来の金融の運営構造をそのままトークンコントラクトに複製しようとした。ERC-1450では、登録済みトランスファーエージェント（Registered Transfer Agent）が発行と償還だけでなく、すべての送金を執行し、一般ユーザーはtransferやapproveの呼び出しが禁止される。これにより、誰が法的記録を管理し、誰が裁判所命令や鍵紛失に対応するのかが明確になる。しかし同時に、従来のDEXやレンディングプロトコルが前提とするパーミッションレスな資産移動からは遠ざかることになる。
ERC-3643は、規制機能を単一の権威に集中させるのではなく、トークンコントラクト、アイデンティティレジストリ（Identity Registry）、信頼できる発行体レジストリ（Trusted Issuers Registry）、独立したコンプライアンスモジュールに分散させる。送金は、KYCステータス、居住地、適格投資家資格などを含む、信頼できるエンティティが発行した証明と照合して検証される。発行者はさらに、投資家数や国別の保有上限などのルールを追加できる。基本的なERC-20構造を維持しながら、個別のルールを交換可能であることは有意義な利点である。その代償として、複数のコントラクト、アイデンティティ発行者、特権管理ロールの調整に伴う運用負担が生じる。
より新しいERC-7943は異なるアプローチをとっており、規制ポリシー自体を定義するのではなく、canSend、canReceive、canTransfer、凍結残高照会、強制転送関数を含む汎用インターフェースを公開する。これにより、ウォレット、取引所、カストディアン、DeFiサービスが一貫した方法で異なる規制対象資産とやりとりできる。言い換えれば、ERC-3643は規制準拠型トークンを作成するためのスタックであり、ERC-7943は複数のスタックを接続する統合層に近い。最近、CMTATの実装がERC-7943のサポートを追加したことは、この最小限のインターフェースが既存の発行標準の上に重ねられることをさらに示している。
ERC-7518とERC-8047は、より専門的なニーズに対応する。ERC-7518は、異なる株式クラス、管轄区域、ロックアップ条件を単一のERC-1155パーティションに適用する。ERC-8047は、資産移動時に親子の系譜を記録し、アカウント全体ではなく特定の資金フローに対して執行を行えるようにする。前者は単一資産内での権利の区別をより明確にし、後者は事後的な追跡と執行をより精緻にする。これらは、ERC-3643の万能標準を置き換えるというより、より広範なコンプライアンススタックを補完するモジュールとして機能する可能性が高い。
他のチェーンは規制機能をどこに配置しているか
Solanaのアプローチは、繰り返し現れるトークン機能をより低レイヤーの共有層に配置する点が特徴である。Transfer Hook、Permanent Delegate、Confidential Transferなどの機能は、汎用のToken Extensionsライブラリを通じて提供され、Solana Attestation Serviceは、KYCステータス、位置情報、投資家資格などのオフチェーン情報をアプリケーションが再利用できるようにする。これにより、各発行者が同じ機能を個別に再構築・監査する必要性が減る。ただし、ウォレットやプロトコルが特定の拡張機能をサポートしていない場合、統合が断絶する可能性がある。また、Permanent Delegateなどの強力な発行者コントロールが設定された資産は、DeFiアプリケーションが追加のカウンターパーティリスクとして扱わなければならない。
StellarとXRPLは、承認、凍結、回収を台帳ネイティブ資産の属性として公開する。これらのコントロールは送金やネイティブ取引機能で一貫して有効であり、アプリケーションはトークンコントラクトごとにカスタムロジックを再解釈する必要がない。StellarはStellar Asset Contractsを通じて台帳資産とスマートコントラクト環境の接続を拡張しており、XRPLはMPTを中心に、許可付き保有、凍結、復旧からプライバシー関連機能へと進んでいる。しかし、ルールが台帳に深く組み込まれるほど、その進化はネットワークのアップグレードとコンセンサスに依存する。また、コントロール設定が資産の流動性や利用範囲をより直接的に制約する可能性がある。
SuiとAptosは、EVMのコントラクト中心モデルと台帳ネイティブモデルの中間に位置する。SuiはCurrency Registryで規制対象資産の拒否リスト状態とグローバルな一時停止権限を記録する。AptosはFungible AssetフレームワークのTransferRefを使ってアカウントを凍結するか、必要に応じて特権的な転送でこれらの制限を迂回する。アドレスのブロックや緊急一時停止など、繰り返し現れる執行機能はフレームワークによって提供され、投資家区分や国別の保有上限といったより複雑なポリシーは、独立したMoveモジュールに委ねられる。この点で、これらのアーキテクチャはEVMエコシステム自身が進みつつあるモジュール化の方向性に最も近い。
Cantonは、規制の範囲をトークンから市場運営全体に拡張する。CIP-56は、残高の転送を標準化するだけでなく、特定当事者への情報開示、受取人の承認、アトミックDvP（受渡同時決済）を含む。Token Standard V2は独立した2026年のDevNetでテスト中である。この設計は、より強力な運営の一貫性とプライバシーを提供するが、専用のアイデンティティと開発環境を必要とする。したがって、既存のパブリックチェーンの流動性とアプリケーションは簡単には移行できない。
Avalanche L1は、規制準拠型トークンを発行するだけでなく、規制された市場そのものを構築するための選択肢として理解するのが適切である。運営者はホワイトリストで取引参加者やコントラクトデプロイヤーを制限でき、バリデータにKYC、AML、または免許条件を課すことができる。このスタックは、JumioやKeyringなどのアイデンティティプロバイダーをtxAllowlistに接続することもでき、機関限定の取引所や決済ネットワークに非常に適している。その代償は運営面にある。バリデータ、アップグレード、クロスチェーンブリッジ、流動性はすべて独立して管理する必要があり、既存のEVMネットワーク上で単一のトークンを発行するよりもコストと断片化の程度がはるかに高い。
汎用的な執行機能と規制ポリシーの分離
総合的に見ると、これらのアプローチは、規制スタック全体をネットワークに埋め込むにせよ、すべての機能を単一のERCに委ねるにせよ、両極端には明らかな限界があることを示している。ほとんどの規制対象資産で繰り返し現れる汎用的な執行機能――送金前検証、凍結、強制転送、緊急一時停止、管理権限とその関連リスクを開示するメタデータ――は、トークンフレームワークや台帳、あるいはERC-7943のような最小限のインターフェースの近くに配置するのが最善である。これにより、発行者間の実装の差異と監査コストが低減され、ウォレット、取引所、カストディアンは資産のコントロール構造を一貫して識別できるようになる。
対照的に、どのアイデンティティプロバイダーを信頼するか、どの管轄区域を許可するか、投資家区分ごとの保有上限とロックアップ期間をどのように計算するか、誰が法的命令を執行できるか――こうした決定は、資産固有のERCや独立したモジュールに委ねる方が適している。これらのルールはプロダクトや管轄区域によって異なり、法改正に応じて更新されなければならない。それらをネットワークの基盤ルールにハードコードすると、アップグレードが遅れるだけでなく、特定の金融市場の政策選択が汎用チェーンのデフォルト設定になってしまう可能性がある。
言い換えれば、規制型トークン市場は、単一の標準に収束するよりも、コンプライアンス・スタックのかたちで発展する可能性が高い。このモデルでは、交換可能なアイデンティティ、管轄区域、商品固有のルールが、共通の執行機能の上に構築される。イーサリアムとより広範なEVMエコシステムは、ポリシーの柔軟性と既存の流動性へのアクセスにおいて依然として優位性を持ち、台帳ネイティブチェーンは実行の一貫性と運用の簡潔性でより強く、Cantonのような専用ネットワークはプライバシーと機関向けワークフローにおいて最も際立っている。
したがって、採用率は、どの標準機能リストが最も長いかによって決まる可能性は低い。より重要なのは、規制政策が、資産を再発行することなく、またウォレット、取引所、カストディ機関にゼロからの統合再構築を強いることなく、変更できるかどうかである。もう一つの重要なテストは、外部参加者が、資産に組み込まれた強力な管理権限を明確に識別し、評価し、管理できるかどうかである。
