XRP Ledgerの機能

XRP Ledger（XRPL）は、XRPの送金に加え、トークンの発行、資産の交換、条件付きの支払い、複数人による口座管理などを行える公開型の分散型台帳です。これらの主要な機能はプロトコルに組み込まれており、利用者は送金や設定変更などの処理を指示するトランザクション（取引）を送信して利用します。

基本機能

XRPの送金と取引の承認

利用者はアカウントを作り、秘密鍵で署名した取引を送信します。ネットワークは合意形成を通じて取引を検証し、残高や設定を台帳に記録します。XRPからXRPへの通常の送金では、通貨交換の経路を指定する必要はありません。取引手数料はXRPで支払い、使用された手数料は消却されます。

アカウントや台帳上のデータには準備金が必要です。準備金は取引ごとに消費する手数料とは異なり、台帳資源の使用に応じて確保する残高です。取引所などが一つのアドレスを複数の顧客で共有するときは、宛先タグを使って入金先の顧客を識別できます。

公式資料：Direct XRP Payments ／ Reserves ／ Transaction Cost

XRP Ledgerコンセンサスプロトコル

XRP Ledgerでは、複数のサーバーが取引と台帳の状態を共有し、コンセンサスプロトコル（合意形成の手順）によって次のレジャーに含める取引を決めます。レジャーは、ある時点の台帳の状態と、その更新に使われた取引をまとめたものです。合意形成に参加するサーバーであるバリデータは取引候補を提案し、互いの提案を確認・修正しながら合意を形成します。各サーバーは合意した取引を共通の規則と順序で処理し、計算結果を要約した値（ハッシュ）を照合します。十分な数の信頼するバリデータが同じ結果を確認すると、そのレジャーは検証済み（validated）として確定します。

各サーバーが合意形成で参照するバリデータの集合をUNL（Unique Node List）と呼びます。これはネットワーク全体の単純な多数決ではなく、各サーバーが選んだ信頼対象に基づく仕組みです。安全に同じ台帳へ合意するには、信頼対象の十分な重なりと、結託しない運営主体の選択が重要になります。合意が成立しない場合には、無理に取引を確定せず進行を止めることで整合性を守ります。

通常は数秒ごとに新しいレジャーが確定します。ただし、送信直後にAPI（ソフトウェアからサーバーの機能を利用する窓口）が返す暫定結果と確定結果は異なります。送金の成功は、取引が検証済みレジャーに含まれ、成功結果になっていることを確認して判断します。

公式資料：Consensus Protocol ／ Consensus Structure ／ Unique Node List

ビットコインとの違い：合意形成と確定

ビットコインはProof of Work（PoW）を用い、マイナーが計算作業によってブロックを提案します。各ノードは規則に従ってブロックを検証し、有効なチェーンのうち累積作業量が最大のものを採用します。分岐による組替えの可能性があるため、後続ブロックが増えるほど取引の確実性が高まる仕組みです。

一方、XRPLは採掘競争を行わず、信頼するバリデータの合意と検証によってレジャーを確定します。XRPの保有量や預け入れ量で投票の重みを決める方式でもありません。両者は、計算作業に基づくチェーン選択と、信頼対象の重なりに基づく合意という、異なる安全性の前提を持っています。

公式資料：Bitcoin Developer Guide：Block Chain ／ XRPL：Consensus Protocol

アカウント方式とUTXO方式の違い

XRPLはアカウント方式を採用しています。各レジャーは、その時点のアカウント残高を含む台帳の状態を持っています。現在のXRP残高は、最新の検証済みレジャーにあるアカウントの情報から直接取得でき、過去のレジャーを遡って入出金を集計する必要はありません。

台帳にはアカウントごとのXRP残高や取引の連番、各種設定が記録され、取引によってこれらの状態が更新されます。トークン残高や注文などは、関連する専用の台帳データで管理します。アカウントは残高だけでなく、署名や入金の条件などを継続して設定できる単位でもあります。

ビットコインのUTXO（Unspent Transaction Output）は、過去の取引で作られ、まだ使用されていない出力です。通常の初期同期では、過去のブロックを順に検証し、使用済みの出力を除外しながらUTXOの集合を構築します。その後はこの集合を保持・更新するため、残高を確認するたびに全履歴を遡るわけではありません。ウォレットの残高は、利用者が使用できるUTXOを合計して表示します。送金時にはUTXOを入力として消費し、受取人への出力や、自分へのお釣りの出力を新しく作ります。

例えば、手数料を除いて考えると、10単位から3単位を送る場合、アカウント方式では送信側の残高を10から7へ更新します。UTXO方式では10単位の出力を消費して、相手への3単位と自分への7単位の出力を作ります。アカウント方式とUTXO方式は残高の管理方法、PoWとXRPLのコンセンサスは合意形成の方法であり、それぞれ独立した設計上の選択です。

公式資料：XRPL：Accounts ／ XRPL：Consensus Protocol（各レジャーが保持する状態） ／ Bitcoin Developer Guide：Transactions

トークンの発行とトラストライン

XRPLでは、XRP以外の資産を表すトークンも発行できます。従来型のトラストライントークンは、通貨コードと発行者の組み合わせで識別します。同じ「USD」という名称でも、発行者が異なれば別の資産です。トラストラインは、相手が発行するトークンの残高や受入上限などを管理する台帳上の関係です。

法定通貨などの価値を表すトークンであっても、その価値や償還は発行者の仕組みに依存します。発行者のないXRPとは性質が異なります。現在は、トラストライン方式に加えて、後述するMPTという発行方式もあります。

公式資料：Fungible Tokens

分散型取引所（DEX）

台帳に組み込まれたDEXでは、XRPとトークン、またはトークン同士を交換できます。利用者が数量と交換条件を指定して出した注文は、条件に合う反対注文と照合されます。約定しなかった部分は、注文の設定に応じて注文板に残ります。

この注文板の流動性は、売買だけでなく通貨を交換する支払いにも利用されます。後から追加されたAMMは、注文板とは別の方法で流動性を供給し、取引や支払いで両者を組み合わせて使えます。

公式資料：Decentralized Exchange

通貨を交換する支払いと経路探索

送信する資産と受け取る資産が違う場合、注文板やAMMなどを利用して交換を伴う支払いができます。複数の交換を含む場合も、一つのPaymentトランザクションとして処理されます。支払いは原子的に処理され、途中の交換だけが実行された状態にはなりません。

経路探索は、ウォレットなどがサーバーのAPIを使い、送金元と送金先をつなぐ経路の候補と必要な送信額を調べる仕組みです。例えば、JPY建てトークンからCNY、EURを経てUSD建てトークンへ交換する経路も考えられます。中間資産としてXRPを使うことは必須ではありませんが、必要な注文や流動性、トラストラインなどの条件を満たす必要があります。

経路探索と取引の実行は別の段階です。通常は送信前に候補を調べて取引に指定し、実行時には指定された経路と既定の経路から利用する流動性が決まります。APIがあらゆる経路や最安経路を必ず見つける保証はなく、探索後に交換条件が変わることもあります。一つの支払いで複数経路を組み合わせることもできます。

公式資料：Paths ／ Cross-Currency Payments

オートブリッジ

オートブリッジは、トークン同士を直接交換する経路に加えて、XRPを中間資産にした交換を利用する仕組みです。例えばUSD建てトークンからEUR建てトークンへの交換では、直接の注文板と、USDからXRP、XRPからEURという組み合わせを比較して、交換条件を改善できる流動性を使います。直接交換とXRP経由の交換を一つの取引で併用する場合もあります。

経路探索が支払いに利用できる経路の候補を探すのに対し、オートブリッジはXRP経由の流動性を直接交換と組み合わせます。

公式資料：Auto-Bridging

リップリングと発行トークンの管理

リップリングは、同じ通貨コードのトラストライン間で残高を調整し、支払いを中継する仕組みです。アカウントの設定によっては、同じ通貨コードを持つ異なる発行者の残高が置き換わるため、利用者はリップリングを許可する範囲を管理します。

発行者は、発行トークンの保有に承認を要求したり、凍結機能で利用を制限したりできます。これらは発行トークンの管理機能であり、発行者が他人のXRPを凍結する権限ではありません。

公式資料：Rippling ／ Freezing Tokens

Amendmentで追加された機能

Amendmentは、ネットワークの合意によって有効化するプロトコルの仕様変更です。以下では、年表に掲載した26件の機能を有効化順に紹介します。投票可能になった日と有効化日は「XRP Ledgerの歴史」の年表を参照してください。

マルチサイン（MultiSign）

複数の鍵による署名を組み合わせて、アカウントの取引を承認する機能です。署名者ごとに重みを設定し、その合計が必要な値に達したときに承認します。「3人のうち2人が署名する」といった共同管理が可能です。署名者数の拡張は、後述のExpandedSignerListによるものです。

公式資料：MultiSignの解説・仕様

送金処理の更新（Flow）

交換を伴う支払いを処理する内部アルゴリズムを更新したAmendmentです。送金の条件に応じて、経路上の流動性を利用する計算処理を担います。

公式資料：Flowの解説・仕様

注文価格の有効桁数（TickSize）

発行者がトークンの注文価格に使う有効数字の桁数を設定する機能です。ごく小さな価格差の注文が増えることを抑え、注文板を整理しやすくします。設定の対象は注文価格の精度で、トークンの数量単位は維持されます。

公式資料：TickSizeの解説・仕様

エスクロー（Escrow）

資産を一時的にロックし、時刻や暗号学的な条件を満たした後に受取人へ渡す機能です。受渡しを完了するには、条件を満たしたうえで完了用の取引を送信します。取消可能時刻が設定されていれば、その時刻以降に取消用の取引で戻せます。当初の対象はXRPで、トークンへの拡張はTokenEscrowで行われました。

公式資料：Escrowの解説・仕様

ペイメントチャネル（PayChan）

XRPをチャネルに確保し、送信者が署名した支払請求情報を受取人に渡す仕組みです。個々の請求情報は台帳外で検証でき、受取人が台帳上で精算します。少額の支払いを頻繁に行う用途に向き、個々の支払いを毎回レジャーに記録する負担を減らせます。

公式資料：PayChanの解説・仕様

入金承認（DepositAuth）

受取側が、承認していない相手からの入金を制限する機能です。アカウントが一方的に入金を受けたくない場合などに利用します。残高が少ない場合のXRP送金など、一部の入金には仕様上の例外が適用されます。

公式資料：DepositAuthの解説・仕様

入金の事前承認（DepositPreauth）

入金承認を使うアカウントが、指定した送金元からの入金をあらかじめ許可できるようにした機能です。後から追加されたCredentialsとの組み合わせでは、資格情報に基づいた承認にも対応します。

公式資料：DepositPreauthの解説・仕様

アカウント削除（DeletableAccounts）

不要になったアカウントを、所定の条件を満たしたうえで削除し、残るXRPを指定先へ移す機能です。削除を妨げる台帳データを整理する必要があり、削除時には専用の取引手数料もかかります。削除後も過去の取引履歴は残ります。

公式資料：DeletableAccountsの解説・仕様

小切手型の支払い（Checks）

送信者が受取人と上限額を指定した小切手を作り、受取人が後から換金する機能です。作成時点で資金を取り置くエスクローとは異なり、残高が動くのは換金時です。その時点で資金などが不足すると換金は失敗します。

公式資料：Checksの解説・仕様

チケット（TicketBatch）

取引に使うシーケンス番号をチケットとして先に確保する機能です。複数の取引を準備し、通常の連番順に縛られず送信できます。複数人から署名を集めるなど、送信準備に時間がかかる取引にも利用できます。各取引には通常どおり署名による承認が必要です。

公式資料：TicketBatchの解説・仕様

合意形成の耐障害性（NegativeUNL）

信頼対象のバリデータが一時的に停止したとき、その影響を抑えるための仕組みです。合意した手続きにより、稼働していないバリデータを検証の定足数計算から一時的に除外します。信頼対象の選択を維持しながら、一時的な障害への耐性を高めます。

公式資料：NegativeUNLの解説・仕様

署名者リストの拡張（ExpandedSignerList）

マルチサインの署名者リストを、従来の最大8アドレスから最大32アドレスへ拡張しました。より多人数の組織や管理体制で、署名者の重みと必要な合計値を使った承認ルールを設定できます。

公式資料：ExpandedSignerListの解説・仕様

NFT（NonFungibleTokensV1_1）

一つずつ区別できる非代替性トークンを、XRPLの組込み機能で発行・保有・売買できます。NFTの売買オファーなど専用の取引を利用します。画像や作品などの関連情報は、URI（情報の参照先を示す識別子）によって外部のデータと結び付けられます。

公式資料：NonFungibleTokensV1_1の解説・仕様

クローバック（Clawback）

必要な設定をした発行者が、自ら発行したトークンを保有者から回収する機能です。法令対応などを想定した発行者側の管理手段で、標準では無効です。対象は発行トークンであり、他人のXRPを回収することはできません。

公式資料：Clawbackの解説・仕様

自動マーケットメーカー（AMM）

2種類の資産を蓄えた流動性プールから、自動的に交換を行う仕組みです。流動性を提供した利用者は持分を表すLPトークンを受け取り、取引手数料収入に参加する一方、資産価格の変動に伴う損失リスクも負います。XRPLでは既存の注文板と統合して利用できます。

公式資料：AMMの解説・仕様

分散型識別子（DID）

アカウントに対応する分散型識別子の情報や、関連文書への参照を台帳で管理する機能です。外部の認証サービスなどと連携する基盤になります。実名や資格の確認は、連携する認証サービスなどが担います。

公式資料：DIDの解説・仕様

価格オラクル（PriceOracle）

外部の価格情報を台帳に登録し、アプリケーションから参照できるようにする機能です。価格情報の信頼性は提供者に依存するため、利用するアプリケーション側で情報源を評価します。

公式資料：PriceOracleの解説・仕様

AMMのクローバック対応（AMMClawback）

クローバックが有効なトークンをAMMで利用できるようにした拡張です。発行者がAMMに預けられた対象トークンを回収するための取引も追加されました。流動性を提供するときには、対象トークンの回収条件も考慮する必要があります。

公式資料：AMMClawbackの解説・仕様

NFTの発行と売却提示（NFTokenMintOffer）

NFTの発行時に売却オファーも作成できるようにした機能です。発行と販売準備を一つの取引で行えます。売却の成立には、買い手がそのオファーを受け入れるなど、別途売買の条件を満たす必要があります。

公式資料：NFTokenMintOfferの解説・仕様

ディープフリーズ（DeepFreeze）

発行トークンの利用を、通常の凍結より厳しく制限する機能です。対象のトラストラインについて送信だけでなく受信も制限できます。通常の凍結との設定上の関係があり、XRP残高を凍結する機能ではありません。

公式資料：DeepFreezeの解説・仕様

動的NFT（DynamicNFT）

変更可能として発行したNFTのURIを更新できるようにする機能です。参照先の内容が更新される会員証などの用途に利用できます。更新できる範囲は、発行時の設定と変更権限に従います。

公式資料：DynamicNFTの解説・仕様

資格情報（Credentials）

資格情報の発行、受入れ、削除を台帳上で管理する機能です。例えば、特定の発行者が認めた資格を持つアカウントに入金やサービス利用を許可する仕組みの基礎になります。資格情報の意味と審査は発行者側が定めます。

公式資料：Credentialsの解説・仕様

多目的トークン（MPT）（MPTokensV1）

従来のトラストライントークンとは異なるデータ構造で、代替可能なトークンを発行・移転する機能です。発行者は用途に応じた管理条件を設定できます。従来型トークンと対応機能がすべて同じではないため、DEXや経路支払いなどとの組み合わせは個別に対応状況を確認する必要があります。

公式資料：MPTokensV1の解説・仕様

許可型ドメイン（PermissionedDomains）

指定された発行者の資格情報などを条件として、参加資格を定義する機能です。承認済みの参加者だけが利用するサービスの基盤になります。公開されたXRPL上で、資格情報に基づく参加条件を表現します。

公式資料：PermissionedDomainsの解説・仕様

トークンのエスクロー（TokenEscrow）

エスクローの対象を、XRPに加えてトラストライントークンとMPTへ広げました。発行者側のロック許可やトークンの設定など、対応する条件を満たす必要があります。これにより発行トークンにも、時刻や条件に基づく受渡しを利用できます。

公式資料：TokenEscrowの解説・仕様

許可型DEX（PermissionedDEX）

許可型ドメインに基づき、参加条件を満たすアカウントが注文を出し、取引する市場を提供します。通常のオープンなDEXと並存し、特定の参加条件を持つ取引環境をXRPL上に作れます。

公式資料：PermissionedDEXの解説・仕様

インターレジャーとの連携

インターレジャープロトコル（Interledger Protocol：ILP）は、異なる台帳や決済ネットワークをつないで支払いを中継するためのオープンなプロトコルです。コネクターと呼ばれる仲介者を通じて、異なる通貨やシステムの間で価値を移転します。XRPL内の経路探索とは対象が異なり、特定の通貨やブロックチェーンの使用を必須としません。

XRPLでは、エスクローとペイメントチャネルがAmendmentで追加され、ILPと連携するための基盤が整いました。2017年の公式リリース発表でも、これらの機能を含む更新がILPとの互換性を提供すると説明されています。外部のILP接続ソフトが、XRPLのエスクローやペイメントチャネルを利用して連携します。

エスクローは、期限や暗号学的な条件に従って資金の受渡しを制御する機能で、初期のILPとの連携に利用できるものとして紹介されました。ペイメントチャネルは、台帳に確保したXRPに対する署名付きの支払請求情報を台帳外で更新し、後から精算する仕組みです。ILPの接続実装では、参加者間の支払いをXRPで精算する手段として利用できます。

用途の一例として、ILPv4の上で動くSTREAMと組み合わせれば、動画の視聴時間などに応じて少額ずつ支払うストリーミング送金も構成できます。送受信を制御するソフトと、精算を担うXRPLのペイメントチャネルを組み合わせることで、個々の少額支払いを毎回レジャーに書き込む必要がなくなります。

公式資料：rippled 0.60.0：ILP対応、Escrow、Payment Channels ／ Interledger Protocol V4 ／ XRPペイメントチャネルを利用するILP接続実装 ／ STREAM

開発中の機能：量子耐性への対応

量子耐性とは、量子コンピューターを使った攻撃にも耐えられる性質を指します。XRPLが現在利用するsecp256k1とEd25519は楕円曲線暗号に基づき、将来、十分に高性能な量子コンピューターが実用化された場合には影響を受けます。このため、資産の移転を許可する署名などを耐量子方式へ移行する研究・開発が進められています。

Rippleは2026年4月20日、2028年を目標とする段階的な対応計画を公表しました。NISTの耐量子署名方式などを評価し、署名の大きさ、検証負荷、処理性能への影響を試験する方針です。AlphaNetでのML-DSAの試作にも触れ、2026年後半にはDevnetから既存署名と候補方式を併用する試験を進める計画を示しています。最終段階では、新しいAmendmentを提案して本格的な移行を目指すとしています。

XRPLにはアカウントを維持したまま署名鍵を変更する仕組みがあります。量子耐性を実現するには、これに加えて耐量子署名方式への対応が必要です。メインネットへの導入は開発・移行計画の段階にあり、2028年はRippleが掲げる目標時期です。実際の有効化日は今後の開発と合意形成によって決まります。

公式資料：Cryptographic Keys ／ Ripple：Post-Quantum Readiness on the XRP Ledger（2026-04-20）

XRP Ledgerの歴史

XRP Ledgerは2012年に稼働を開始し、その後、送金・資産管理・分散型取引の機能を拡張してきました。ここでは、XRPの誕生と主要な機能追加を時系列で整理します。

XRPの誕生と当初の名称「XNS」

XRPは2012年6月2日に誕生しました。当初の名称は「XNS」で、アーサー・ブリット氏が作成したコードによって1,000億単位が生成されました。この初期数量が、現在のXRPの発行総量の起点です。

2012年6月にはXRP Ledgerのネットワークが稼働し、取引を処理していました。初期開発では、バイナリ形式の変更に伴ってレジャー番号を複数回リセットし、取引履歴を消去しましたが、そのたびに1,000億XRPを再発行したわけではありません。現在につながるレジャーの履歴は2012年12月に始まり、その最初の約1週間分（レジャー1～32,569）は失われており、現存する最古のレジャーは32,570です。このため、XRPの誕生日と現存する取引履歴の開始日は一致しません。

出典：2012年6月2日の開発記録／デイビッド・シュワルツ氏による誕生日・初期名称の記録／ネットワークの稼働と初期のリセット／2012年12月以降の履歴／初期レジャーの欠落範囲（XRPL公式資料）。

機能の投票開始と有効化

年表の「投票開始日」は、公式リリースで当該Amendmentへの投票が可能になった日を示します。別途、公式の投票開始告知がある機能は、その日付を注記付きで掲載しています。提案書の作成日や個々のバリデータが初めて投票した日時とは区別しています。

機能は、投票で必要な支持を2週間維持した後、メインネットで有効化されます。年表の「有効化日」は、XRPL.orgのメインネット一覧に記載されたEnabledの日付です。出典：Amendments。

主要な機能追加を有効化日順にまとめています。個別の不具合修正は対象を絞って掲載しています。日付は各公式資料の表記に従い、GitHubの公開日時はUTCの日付を使用しています。確認日：2026-09-27。

参考：メインネットのAmendment一覧／MultiSignの投票予定に関する告知／PayChanの本番有効化準備に関する告知。