XRPレジャーの委任アップグレードが10月5日に実施へ――XRPは恩恵を受けるか？

XRPレジャーは、ネットワークの35台中29台の信頼されたバリデータがアカウント権限アップグレードを支持したことを受け、PermissionDelegationV1_1を14日間の有効化期間に移行しました。

概要

• PermissionDelegationV1_1は、バリデータの支持率が80％以上の閾値を維持すれば、10月5日に有効化される可能性があります。

• このアップグレードにより、XRPLアカウントは、他アカウントに鍵の完全制御権を与えることなく、特定の権限を委任できます。

• 権限委任はXRPの供給量やトークノミクスを直接変更しないため、価格への影響は主に採用状況とネットワーク活動に依存します。

ライブXRPレジャーアメンダメントダッシュボードによると、カウントダウンは9月21日に開始され、期間中にバリデータの支持率が所定の閾値を維持すれば、10月5日11:18（UTC）にPermissionDelegationV1_1が適用されます。

35台の信頼されたバリデータのうち少なくとも28台が引き続きこのアメンダメントを支持する必要があります。カウントダウン終了前に支持率がこの水準を下回った場合、有効化タイマーはリセットされます。

PermissionDelegationV1_1はXRPレジャーのアカウント権限を分割します

PermissionDelegationV1_1は、XRPレジャーのアカウントが他のアカウントに特定のタスクを実行させる権限を与える方法を変更します。

現行のアカウント構造では、異なるシステムや従業員に業務を委託する企業が、運用アカウントに必要以上に高い権限を与える問題に直面します。権限委任はこうした責任を分離することを目的としています。

例えば、あるアカウントは別のアカウントに支払い実行権限のみを付与し、主アカウントの鍵変更権限は与えないことができます。ステーブルコイン発行者は、主要鍵をオフラインで保管しつつ、インターネット接続型のコンプライアンスシステムに、自社トークン保有者の承認権限のみを与えることが可能です。

各委任先アカウントには最大10の権限を付与でき、権限付与元アカウントはこれらの権限を変更・取消すことができます。

関連記事：XRPレジャー3.4.0版がレンディング機能とプロトコル修正を追加

この仕組みは、金融機関で一般的な役割分担（支払い・コンプライアンス・管理機能が同一アクセス権を共有しない）に類似しています。

PermissionDelegationV1_1は、xrpld 3.3.0で導入された一連のアメンダメントの一部です。同リリースにはBatchV1_1、ConfidentialTransfer、DynamicMPT、Sponsorも含まれ、これらは主に機関向け取引およびトークン発行を支援します。

Sponsorは、ユーザーのアカウントを制御せずに、他者がトランザクション手数料および準備金要件を負担できるようにします。DynamicMPTは、発行者にマルチパーパストークン（MPT）の特定属性に対する柔軟な制御権限を与えます。ConfidentialTransferは、承認済み当事者へのアクセス機構を維持しつつ、MPT残高および支払額を公開から非表示にします。

Crypto.newsは以前、ConfidentialTransferが、企業が取引のプライバシーを確保しつつ監査人やその他の承認済み関係者に情報を提供する必要がある機関向けユースケースを対象としていることを報じた。

パーミッション委任機能が、過去のセキュリティ欠陥修正後に復活。

PermissionDelegationV1_1は、XRP Ledgerに委任型アカウント権限を導入する2度目の試みである。

当初の改訂案は、コミュニティのテスト担当者が2025年9月15日に脆弱性を報告したため、本番ネットワークへの導入前に中止された。

問題のある実装では、ソフトウェアが取引の署名検証を適切に行う前に、アカウントが当該取引を実行する権限があるかをチェックしていた。一部の却下された取引でも手数料が発生していた。

攻撃者は、不正な高額手数料付き取引を送信し、署名が不正であっても他アカウントに支払いを強制できた。このプロセスを繰り返せば、被害者の保有XRP残高を枯渇させることも可能だった。

脆弱性発覚後、バリデーターには当該改訂案のサポートを控えるよう勧告され、影響を受けたバージョンが本番ネットワークで有効化されるのを防いだ。

代替版はxrpld 3.3.0に組み込まれ、未承認取引の処理方法が変更された。現在は、ターゲットアカウントに課金される可能性のある失敗タイプより前に署名検証が実行される。

セキュリティ対応後に復活した機能は、パーミッション委任だけではない。BatchV1_1は、開発者が別途重大な署名脆弱性を発見したため、以前のBatch実装に代わって導入された。修正・再審査後の改訂Batchアップグレードは、バリデーターによる投票を経て進展している。

PermissionDelegationV1_1はXRP価格に影響を与えるか？

PermissionDelegationV1_1はXRPの供給量・発行スケジュール・トークン経済に直接影響せず、単独での有効化がXRP需要を機械的に大幅に増加させる根拠はない。

この改訂案はXRPトークンそのものではなくアカウント権限を扱う。委任アカウントを利用する機関は、依然としてXRPLの通常手数料・準備金要件にXRPを使用するが、単に委任権限を利用するためだけに大量のXRPを購入・保有する必要はない。

ネットワークにおける最近の動向は、XRPL採用とXRP需要の違いがなぜ重要かを示している。

Ripple PrimeのXRP暴露度に関する先行分析によると、Rippleエコシステム内での機関活動が大きくても、それが自動的に同程度のXRP需要につながるわけではない。安定コインやその他の発行資産が大部分の価値移転を担う一方、XRPは引き続き取引手数料・準備金・一部ルーティング機能などの役割を果たす。

パーミッション委任にも同様の構造が適用される。ステーブルコイン発行者・トークン化資産プロバイダー・その他事業者は、この機能をXRPを転送資産とせずに利用できる。

価格への影響可能性は、むしろこのアップグレードが長期的にXRPLへの活動増加を促すかどうかに依存する。

高い権限キーをオフラインで管理したい機関発行者は、定期支払いやコンプライアンス業務に委任アカウントを活用できる。こうした機能が、より多くの事業者によるXRPL上での資産発行・取引処理を促進すれば、ネットワーク利用が拡大し、XRPは引き続き手数料・準備金に使われるネイティブ資産となる。

現時点までの証拠は、ネットワーク成長とXRP価格が必ずしも連動しないことを示唆している。RLUSDやトークン化資産はXRPL上で拡大している一方、XRP価格は弱含みの時期もあった。これは、台帳活動の増加が直ちにトークン買い圧力に結びつかないことを意味する。

6月のJPMorgan、Mastercard、Ondo Finance、Rippleによる機関テストも別の例である。米国財務省証券のトークン化償還にはXRP Ledgerが使用されたが、償還対象資産はXRPではなかった。XRPの直接的な役割は、基盤となるネットワークインフラに限定されていた。

したがって、PermissionDelegationV1_1は機関ユーザー向けの新たなインフラ要素となり得るが、XRP価格を大きく押し上げる独立した催化剂とはなりにくい。

アクティベーション前後の市場反応は依然としてあり得る。トレーダーはネットワークのアップグレードや採用に関する期待に応じて対応できるためだ。ただし、価格への持続的な影響は、単なるアメンダメントの有効化ではなく、その後の機能利用状況や他の市場要因に依存する。

XRP Ledgerは、機関向け取引のためのツールをさらに拡充中である。

パーミッション委任（Permission Delegation）はアクティベーションへ向けて進行中だが、他のXRP Ledger機能はアメンダメントプロセスの異なる段階にある。

BatchV1_1は、複数の操作を協調したトランザクションに一括バンドルする仕様で、含まれるすべての処理が同時に成功または失敗する。この構造は、資産とその支払いが同時に移転される決済プロセスを支援可能。

ConfidentialTransferにより、マルチパーパストークン発行者は残高・送金額を非表示にできるが、アカウント自体は可視のままとなる。提案設計では、許諾された関係者が必要なコンプライアンス情報を受け取れるよう配慮されている。

XRPL開発者は3.3.0リリース以降も作業を継続。9月16日公開のバージョン3.4.0では、提案中のレンディング機能の改訂に加え、その他プロトコル修正パッケージを導入。

レンディングフレームワークは、ネットワークのアメンダメントプロセスに従い、バリデータの承認を得た後でなければメインネット上で有効化されない。

詳しくはこちら：Hyperliquidがスポット市場を追加し、NEAR価格見通しが強化