XRP Ledgerが権限委任を有効化、機関向けに新たなウォレット管理機能を提供
重要ポイント
- •PermissionDelegationV1_1修正案は、9月下旬のバリデータのコンセンサス承認を経て、10月8日のレジャー107,524,865でXRP Ledgerメインネット上で有効化されました。
- •この機能により、プライマリアカウントは最大10個の権限を他のアカウントに委任でき、各割り当てはDelegateレジャーエントリとして記録され、プライマリアカウントが取り消しできます。
- •委任先は暗号鍵の変更、追加の委任の作成、付与された権限の範囲外の操作は行えず、各委任はプライマリアカウントの準備金要件にカウントされるレジャー上のオブジェクトを生成します。
- •この修正案は技術的な権限のみを割り当てるため、KYC確認、制裁スクリーニング、法的責任は発行体およびそのサービスプロバイダーに留まり、カスタムの支払いポリシーはこの機能だけでは適用できません。
- •XRPLのドキュメントは、別の修正案であるfixCleanup3_4_0が有効化されるまでPaymentBurn権限の委任を避けるよう推奨しています。権限を持つ委任先が特定の状況下で代替性トークンを発行できる可能性があるためです。

XRP LedgerのPermissionDelegationV1_1修正案がメインネットで有効化されました。XRPL修正案トラッカーによると、この機能は10月8日のレジャー107,524,865で有効になったと記録されています。修正案は9月下旬にバリデータ承認期間を完了しており、そのプロセスにより、レジャー上のライブのアカウント管理ツールが実現しました。XRPLの修正案プロセスでは、バリデータがコンセンサスで承認した後にのみ機能がメインネットに導入されるため、今回の有効化はツールが本番利用可能となった時点を意味します。
この有効化により、機関はPermission Delegationを利用可能になりましたが、現時点で実装を公表した銀行、ステーブルコイン発行体、ファンドマネージャーはありません。企業はXRPL上でこれらの権限構造を直接構築できるようになりましたが、実務上の詳細はウォレットプロバイダー、カストディアン、社内セキュリティチームの責任となります。この修正案が対応するニーズは、機関のデジタル資産運用において長年存在していたものであり、日常的なトランザクションの署名権限は、金庫を管理するマスター認証情報とは通常分けて保管されています。Permission Delegationは、その分離の一部をオフチェーンのソフトウェアに完全に任せるのではなく、レジャー自体に移します。
ステーブルコイン発行体は日常業務を複数アカウントに分割できる
例えばステーブルコイン発行体は、適格顧客の承認を行うチームと、日常的な送金を処理するチームを分ける必要があるかもしれません。新しいモデルでは、発行体のプライマリアカウントはより厳格な管理下に留まり、コンプライアンスアカウントはKYC確認後のトラストライン承認権限を、オペレーションアカウントは支払い権限をそれぞれ取得します。各アカウントは割り当てられた役割のみを保持ため、日常用の鍵が漏洩した場合の被害が限定されます。
企業はウォレットの職務を以下のように分割できます:
- プライマリアカウント: 鍵をより厳格な管理下に置いたまま、委任された役割の作成、変更、取り消しを行う。
- コンプライアンスアカウント: 定義された顧客承認タスクの権限を取得する。
- オペレーションアカウント: 支払いなど、承認されたカテゴリのトランザクションを送信する権限を取得する。
XRPLは各割り当てをDelegateレジャーエントリに記録します。割り当てを受けたアカウントは自身の認証情報で署名し、自身の残高からトランザクション手数料を支払いますが、承認された操作はプライマリアカウントに対して有効になります。XRPLのドキュメントは、この仕組みをマルチシグと併用可能なロールベースのアクセス制御として説明しています。
委任された権限の限界
企業は、特定のトランザクションタイプや事前定義された細分化された機能について権限を付与できます。各委任先は最大10個の権限を保持でき、プライマリアカウントは別のDelegateSetトランザクションを通じてこれらを更新または取り消しできます。
一部の権限はプライマリアカウント専用のままです。委任先は暗号鍵の変更、追加の委任の作成、付与された権限の範囲外のトランザクションの送信は行えません。また、各委任はレジャー上のオブジェクトを生成し、プライマリアカウントの準備金要件にカウントされます。
権限セットにはカスタムの支払いポリシー機能は含まれていません。企業はPermission Delegationだけでは、「1万ドル未満の支払いのみ」や「これらのアドレスへの送金のみ」といったルールを適用できません。そのような管理は引き続きウォレットソフトウェア、承認ワークフロー、コンプライアンスシステムに委ねられます。
レジャー上の権限とコンプライアンス判断は分離されたまま
Permission Delegationが決定するのは、承認されたXRPLの操作をどのアカウントが送信するかという点のみです。KYC確認、制裁スクリーニング、投資家記録、ファンド文書、法的責任は、発行体およびそのサービスプロバイダーに留まります。この修正案は技術的な権限を分割するものであり、根底にあるコンプライアンス判断を自動化するものではありません。
ブラジルのCSD BRとのXRPLのファンド記録管理パイロットも同様の原則に従っています。レジャーは管理されたワークフローを支援できますが、公式の所有記録の責任は既存の市場インフラが担います。Permission Delegationにより、このモデルを利用するプロジェクトは、承認されたレジャー操作をどのアカウントが実行するかについてより柔軟に対応できる可能性があります。
特定の委任権限には公表された警告あり
XRPLのドキュメントは、別の修正案であるfixCleanup3_4_0が有効化されるまで、PaymentBurnの細分化された権限を委任しないよう企業に推奨しています。この修正が適用されるまで、PaymentBurnの権限を持つ委任先は、特定の状況下で代替性トークンを発行できる可能性があるとドキュは述べています。他の細分化された権限には影響ありません。
この警告は修正案全体ではなく単一の権限に適用されるものですが、日常業務を別のオンラインアカウントに移す前に、各委任された役割を確認する必要がある理由を示しています。
企業が新機能でできること
Permission Delegationにより、XRPLの発行体は、メインアカウントを管理する認証情報を共有することなく、ウォレット間で責任を分割できます。その実用上の価値は、構築されるポリシー次第です。どのタスクを委任するか、権限をどれだけ迅速に取り消せるか、ウォレットプロバイダーがこのプロトコル機能を実用的な業務管理システムに変えられるかが鍵となります。直近のシグナルは推測ではなく観測可能なものであり、ウォレットおよびカストディプロバイダーが新しい委任トランザクションとレジャーエントリのサポートを追加するか、そしてfixCleanup3_4_0が有効化に達するかどうか — これはPaymentBurnを委任できるようになるためにXRPLのドキュメントが定める条件です。
この記事は情報提供のみを目的としたものであり、法的、金融、投資に関する助言を構成するものではありません。企業は委任された権限を使用する前に、XRPLの最新の技術ドキュメントおよび自社のセキュリティポリシーを確認する必要があります。