トランザクションの結果の確認

XRP Ledgerを効果的に使用するには、トランザクションの結果を次のように把握することが重要です。トランザクションは成功したか？トランザクションは何を遂行したか？失敗した場合は、なぜか？

XRP Ledgerは共有システムとなっていて、すべてのデータが公開された形で正確に記録され、データはそれぞれ新しいレジャーバージョンで安全に更新されます。誰もが任意のトランザクションの結果を確認し、トランザクションメタデータによってその実行内容を確認できます。

このドキュメントでは、トランザクションの結果がもたらされた理由を把握する方法について、詳細に説明します。エンドユーザー向けには、トランザクションの処理内容を表示するとわかりやすいです。例えば、XRPチャートを使用して、記録されたトランザクションについての説明を英語で参照できます。

前提条件

これらの手順で説明されているトランザクションの結果を理解するには、以下が必要となります。

理解する対象となるトランザクションがわかっている。トランザクションの識別用ハッシュがわかっていれば、それによりトランザクションを検索できます。また、最近のレジャーで実行されたトランザクションまたは特定のアカウントに最後に影響を及ぼしたトランザクションを確認することもできます。
信頼できる情報と、トランザクションの送信日時に関する必要な履歴を提供するrippledサーバーにアクセスできる。
最近送信したトランザクションの結果を確認する場合、トランザクションの送信時に使用したサーバーがネットワークと同期されていれば、そのサーバーにアクセスできるだけで十分です。
古いトランザクションの結果については、全履歴を記録するサーバーを使用できます。

ヒント: この他にも、Data APIやエクスポートされた他のデータベースを使用するなど、XRP Ledgerからトランザクションのデータを照会する方法があります。ただし、これらのインターフェイスは正式なものではありません。このドキュメントでは、最も直接的で信頼できる結果を得るために、rippled APIを直接使用してデータを確認する方法を説明します。

1. トランザクションステータスの取得

トランザクションが成功したか失敗したかを確認するには、2つの問いが必要です。

トランザクションが検証済みレジャーに記録されたか。
記録されていた場合、結果としてレジャーの状態はどのように変化したか。

検証済みレジャーにトランザクションが記録されていたかどうかを確認するには、通常、トランザクションが記録されている可能性のあるすべてのレジャーにアクセスする必要があります。最も簡単で確実な方法は、全履歴を記録するサーバーでトランザクションを検索する方法です。txメソッド、account_txメソッドまたはその他のrippledからの応答を使用します。コンセンサスにより検証されたレジャーバージョンがこの応答に使用されていることを示す"validated": trueを検索します。

結果に"validated": trueがない場合は、その結果は一時的である可能性があり、トランザクションの結果が最終的なものであるかどうかを知るには、レジャーが検証されるまで待機する必要があります。
結果に目的のトランザクションが含まれていない場合、またはtxnNotFoundエラーが返される場合は、サーバーにある利用可能な履歴に保存されているどのレジャーにもそのトランザクションはありません。ただし、このことだけでトランザクションが失敗したかどうかを判断できないことがあります。サーバーに保存されていない検証済みレジャーバージョンにトランザクションが記録されている、または今後検証されるレジャーにトランザクションが記録されている場合があるためです。以下を把握することで、トランザクションが記録されるレジャーの範囲を制限することができます。
トランザクションが記録されている可能性のある最古のレジャー。つまり、トランザクションを初めて送信した後に最初に検証されるレジャー。
トランザクションが記録されている可能性のある最新のレジャー。つまり、トランザクションのLastLedgerSequenceフィールドで定義されるレジャー

以下の例では、成功したトランザクションがtxメソッドによって返され、検証済みレジャーバージョンに記録されています。わかりやすくするために、JSON応答のフィールドの順序を並べ替え、一部を省略しています。

{
  "TransactionType": "AccountSet",
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Sequence": 376,
  "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",

  ... (省略) ...

  "meta": {
    "AffectedNodes": [
      ... (省略) ...
    ],
    "TransactionResult": "tesSUCCESS"
  },
  "ledger_index": 46447423,
  "validated": true
}

この例では、rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnというアドレスを持つアカウントが、シーケンス番号 376を使用して、AccountSetトランザクションを送信したことを示しています。トランザクションの識別用ハッシュは017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567で、その結果はtesSUCCESSです。トランザクションは、検証済みのレジャーバージョン46447423に記録されたため、結果は最終的なものです。

ケース: 検証済みレジャーに記録されていない

トランザクションが検証済みレジャーに記録されていない場合は、共有XRP Ledgerの状態には いかなる 影響も及ぼしません。 今後レジャーに記録されるトランザクションの失敗が最終的となる場合、その失敗が将来影響を及ぼすことはありません。

トランザクションの失敗が最終的でない場合は、 将来の 検証済みレジャーに記録される可能性があります。トランザクションを現在のオープンレジャーに適用して得た暫定的な結果から、トランザクションが最終レジャーに及ぼすと思われる影響を事前に確認できます。ただし、実際の結果はさまざまな要因によって変わる場合があります。

ケース: 検証済みレジャーに記録されている

トランザクションが検証済みレジャーに記録 されている 場合、トランザクションメタデータにはトランザクションの処理結果として、レジャーの状態に対して行われたすべての変更を網羅したレポートが含まれます。メタデータのTransactionResultフィールドには、以下のような、結果を要約したトランザクション結果コードが含まれます。

コードtesSUCCESSは、トランザクションが、おおよそ成功したことを示します。
tec-クラスコードは、トランザクションが失敗したことを示します。このことがレジャーの状態に及ぼす影響は、XRPトランザクションコストを消却し、場合によっては有効期限切れのオファーの削除およびPayment Channelの閉鎖などのブックキーピングを行うことだけです。
どのレジャーにもその他のコードは表示されません。

結果コードは、トランザクションの結果の要約にすぎません。トランザクションの実行内容を詳しく理解するには、トランザクションの指示とトランザクションの実行前のレジャーの状態に照らして残りのメタデータを確認する必要があります。

2. メタデータの解釈

トランザクションメタデータは、以下に示すフィールドをはじめとして、トランザクションがレジャーに適用された方法を 正確に 示します。

フィールド	値	説明
`AffectedNodes`	配列	このトランザクションで作成、削除、または修正されたレジャーオブジェクトのリストと、個々のオブジェクトに対する具体的な変更内容。
`DeliveredAmount`	通貨額	廃止予定。`delivered_amount`で置き換えられます。Partial Paymentsでない場合は省略されます。
`TransactionIndex`	符号なし整数	トランザクションが記録されているレジャーでのトランザクションの位置。この配列は0から始まります。（例えば、値が`2`の場合、そのレジャーの3番目のトランザクションであったことを意味します）。
`TransactionResult`	文字列	トランザクションが成功したか、どのような理由で失敗したかを示す結果コード。
`delivered_amount`	通貨額	`Destination`アカウントが実際に受取った通貨額。このフィールドは、トランザクションがPartial Paymentsであるかどうかにかかわらず、送金された金額を特定するために使用します。

ほとんどのメタデータは、AffectedNodes配列に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元のAccountRootオブジェクトを変更してXRPトランザクションコストを消却し、アカウントのシーケンス番号を増やします。

情報: このルールの例外として疑似トランザクションがあります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトのBalanceフィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。Free Key Resetトランザクションの場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）

以下は、上記のステップ1からの応答全文例です。レジャーに対して行われた変更を把握できるか確認してください。

{
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Fee": "12",
  "Flags": 2147483648,
  "LastLedgerSequence": 46447424,
  "Sequence": 376,
  "SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
  "TransactionType": "AccountSet",
  "TxnSignature": "30450221009B2910D34527F4EA1A02C375D5C38CF768386ACDE0D17CDB04C564EC819D6A2C022064F419272003AA151BB32424F42FC3DBE060C8835031A4B79B69B0275247D5F4",
  "date": 608257201,
  "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
  "inLedger": 46447423,
  "ledger_index": 46447423,
  "meta": {
    "AffectedNodes": [
      {
        "ModifiedNode": {
          "LedgerEntryType": "AccountRoot",
          "LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
          "FinalFields": {
            "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
            "AccountTxnID": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
            "Balance": "396015164",
            "Domain": "6D64756F31332E636F6D",
            "EmailHash": "98B4375E1D753E5B91627516F6D70977",
            "Flags": 8519680,
            "MessageKey": "0000000000000000000000070000000300",
            "OwnerCount": 9,
            "Sequence": 377,
            "TransferRate": 4294967295
          },
          "PreviousFields": {
            "AccountTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
            "Balance": "396015176",
            "Sequence": 376
          },
          "PreviousTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
          "PreviousTxnLgrSeq": 46447387
        }
      }
    ],
    "TransactionIndex": 13,
    "TransactionResult": "tesSUCCESS"
  },
  "validated": true
}

このno-opトランザクションによって行われた唯一の変更はAccountRootオブジェクトの更新で、送金元のアカウントは以下のように表されています。

Sequence値は376から377に増えます。
このアカウントのXRPのBalanceは、396015176から396015164（XRPのdrop数）に変わります。残高から差し引かれた12dropはトランザクションコストで、このトランザクションのFeeフィールドに指定されています。
このトランザクションが、このアドレスから送信された最新のトランザクションとなったことを反映してAccountTxnIDが変わります。
このアカウントに影響を及ぼした以前のトランザクションは、レジャーバージョン46447387で実行されたトランザクションE710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CFで、PreviousTxnIDおよびPreviousTxnLgrSeqフィールドに指定されています。（このことは、アカウントのトランザクション履歴をさかのぼる際に役立つ場合があります。）

注記: メタデータには明示的に示されませんが、トランザクションがレジャーオブジェクトを変更すると、必ずそのオブジェクトのPreviousTxnIDおよびPreviousTxnLgrSeqフィールドが現在のトランザクションの情報で更新されます。同じ送金元の複数のトランザクションが1つのレジャーバージョンに含まれている場合、最初のトランザクション以降の各トランザクションは、これらすべてのトランザクションを記録するレジャーバージョンのレジャーインデックスを値とするPreviousTxnLgrSeqを提供します。

rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2JpnのアカウントのModifiedNodeエントリーがAffectedNodes配列の唯一のオブジェクトであるため、このトランザクションの結果として、このレジャーに対してその他の変更は行われませんでした。

ヒント: トランザクションによってXRPが送信または受信される場合、送金元の残高の変動額はトランザクションコストと合算され、Balanceフィールドの正味金額は1回で変更されます。例えば、1XRP（1,000,000drop）を送信し、トランザクションコストで10drop消却した場合、メタデータにはBalanceが1,000,010（XRPのdrop数）減少したと示されます。

汎用的なブックキーピング

ほぼすべてのトランザクションにより、以下のような変更が行われます。

シーケンスとトランザクションコストの変更: 送金元のシーケンス番号を増やし、トランザクションコストの支払いに使用するXRPを消却するために、前述のとおりどのトランザクション（疑似トランザクションを除く）も、送金元のAccountRootオブジェクトに変更を加えます。
アカウントのスレッド化: オブジェクトを作成する一部のトランザクションでは、目的の受取人または宛先のアカウントのAccountRootオブジェクトも変更し、そのアカウントに関連する何らかの要素が変更されたことを示します。このアカウントを「タグ付け」する手法で、オブジェクトのPreviousTxnIDおよびPreviousTxnLgrSeqフィールドのみを変更します。これにより、これらのフィールドに指定されたトランザクションの「スレッド」を追跡することで、アカウントが保持するアカウントのトランザクション履歴を効率よく検索することができます。
ディレクトリーの更新: レジャーオブジェクトを作成または削除するトランザクションは、多くの場合DirectoryNodeオブジェクトを変更して、どのオブジェクトが存在しているかを追跡します。また、トランザクションによって、アカウントの所有者準備金に反映されるオブジェクトが追加されると、所有者のAccountRootオブジェクトのOwnerCountが増加します。オブジェクトを削除すると、OwnerCountが減少します。

アカウントのOwnerCountを増やす例:

{
  "ModifiedNode": {
    "FinalFields": {
      "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
      "Balance": "9999999990",
      "Flags": 0,
      "OwnerCount": 1,
      "Sequence": 2
    },
    "LedgerEntryType": "AccountRoot",
    "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
    "PreviousFields": {
      "Balance": "10000000000",
      "OwnerCount": 0,
      "Sequence": 1
    },
    "PreviousTxnID": "B24159F8552C355D35E43623F0E5AD965ADBF034D482421529E2703904E1EC09",
    "PreviousTxnLgrSeq": 16154
  }
}

多くのトランザクションのタイプで、DirectoryNodeオブジェクトが作成または変更されます。これらのオブジェクトは、ブックキーピングに使用します。アカウントが所有するすべてのオブジェクト、またはすべてのオファーを追跡して、同じ為替レートで通貨を交換します。トランザクションがレジャーに新しいオブジェクトを作成した場合、トランザクションは既存のDirectoryNodeオブジェクトにエントリーを追加するか、別のDirectoryNodeオブジェクトを追加してディレクトリーの別のページを表さなければならないことがあります。トランザクションがレジャーからオブジェクトを削除した場合、トランザクションは不要となった1つ以上のDirectoryNodeオブジェクトを削除しなければならないことがあります。

新しいオファーディクトリーを表すCreatedNodeの例:

{
  "CreatedNode": {
    "LedgerEntryType": "DirectoryNode",
    "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
    "NewFields": {
      "ExchangeRate": "4E11C37937E08000",
      "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
      "TakerPaysCurrency": "0000000000000000000000004254430000000000",
      "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
    }
  }
},

トランザクションメタデータを処理する際に探すその他の項目は、トランザクションのタイプによって異なります。

支払い

PaymentトランザクションはXRP間の直接トランザクション、複数通貨間の支払い、または（XRP以外の）発行済み通貨での直接トランザクションを表します。発行済み通貨からXRPへのトランザクション、またはXRPから発行済み通貨へのトランザクションなど、XRP間の直接トランザクション以外はすべてpartial paymentが可能です。

XRPの額は、AccountRootオブジェクトのBalanceフィールドで追跡されます。（XRPはEscrowオブジェクトおよびPayChannelオブジェクトにも存在する可能性がありますが、Paymentトランザクションがそれらに影響を及ぼすことはありません。）

支払いでいくら支払われたかを確認するには、必ずdelivered_amountフィールドを使用する必要があります。

支払いにLedgerEntryTypeがAccountRootのCreatedNodeが含まれている場合は、その支払いによってレジャーの新しいアカウントへの資金供給が行われたことを意味します。

発行済み通貨での支払い

発行済み通貨を利用する支払いは、多少複雑です。

発行済み通貨残高の変更は、トラストラインを表すRippleStateオブジェクトにすべて反映されます。一方の当事者のトラストラインで残高が増加すると、相手側当事者の残高は同じ額だけ減少すると考えられます。このことは、メタデータには、RippleStateオブジェクトの共有Balanceに対する1回の変更としてのみ記録されます。この変更が「増加」または「減少」のどちらで記録されるかは、どちらのアカウントのアドレスが数値として大きいかによって決まります。

1回の支払いは、複数のトラストラインとオーダーブックで構成される長いパスをたどる場合があります。間接的に当事者間を接続する複数のトラストラインの残高を変更するプロセスをRipplingと呼びます。トランザクションのAmountフィールドに指定されたissuerに応じて、支払先アカウントに結び付けられている複数のトラストライン（RippleStateアカウント）で支払額を分割することもできます。

ヒント: 変更されたオブジェクトがメタデータに表示される順序は、支払いを処理するときにこれらのオブジェクトにアクセスした順序とは必ずしも一致しません。AffectedNodesメンバーを並べ替えて資金がレジャーまでたどったパスを再構成すると、支払いの実行の詳細を把握しやすくなります。

複数通貨間の支払いでは、オファーの一部または全額を消費して、通貨コードとイシュアーが異なる通貨間で変更が行われます。トランザクションでOfferタイプのDeletedNodeオブジェクトが示される場合は、全額が消費されたオファーを示しているか、または処理の時点で期限切れになるか、または資金化されないことがわかったオファーを示している可能性があります。トランザクションでOfferタイプのModifiedNodeが示される場合は、オファーの一部が消費されたことを示します。

トラストラインのQualityInおよびQualityOut設定は、トラストラインの一方の側における発行済み通貨の額に影響を与える可能性があるため、残高の数値の変化は、送金元におけるその通貨の額と異なります。delivered_amountは、受取人による評価額でいくら送金されたのかを示します。

送金額と受取額が発行済み通貨の精度の範囲外である場合は、一方のトランザクションで0に丸められる金額が、他方から引き出される可能性があります。そのため、両当事者が、お互いの残高に10¹⁶倍の差があるときに取引をすると、丸めることによって少額の発行済み通貨が「作成」または「消却」される可能性があります。（XRPは丸められないので、XRPではこの状況は発生しません。）

パスの長さに応じて、複数通貨間の支払いのメタデータは長くなります。例えば、トランザクション8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B では、rHaaans...が発行した2.788 GCBを送金しXRPを支払いますが、2人のイシュアーのUSDを経由し、2つのアカウントにXRPを支払います。r9ZoLsJからのEURをETHと交換する資金供給されていないオファーを削除し、変更された合計17の異なるレジャーオブジェクトのブックキーピングを行います。

オファー

OfferCreateトランザクションでは、成立した額や、トランザクションがtfImmediateOrCancelなどのフラグを使用したかどうかによって、レジャーにオブジェクトが作成される場合と作成されない場合があります。トランザクションがレジャーのオーダーブックに新しいオファーを追加したどうかを確認するには、LedgerEntryTypeがOfferのCreatedNodeエントリーを探します。例:

{
  "CreatedNode": {
    "LedgerEntryType": "Offer",
    "LedgerIndex": "F39B13FA15AD2A345A9613934AB3B5D94828D6457CCBB51E3135B6C44AE4BC83",
    "NewFields": {
      "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
      "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C59269BFDDB2E",
      "Expiration": 608427156,
      "Sequence": 1082535,
      "TakerGets": {
        "currency": "EUR",
        "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
        "value": "2157.825"
      },
      "TakerPays": "7500000000"
    }
  }
}

タイプOfferのModifiedNodeは、成立し、かつ一部が消費されたオファーを示します。1つのトランザクションで多数のオファーを消費できます。2種類の発行済み通貨を交換するオファーが、オートブリッジングによってXRPを交換するオファーを消費することもあります。両替取引のすべてまたは一部をオートブリッジングできます。

LedgerEntryTypeがOfferのDeletedNodeは、すべて消費された成立オファー、処理の時点で期限切れになるか、または資金化されないことがわかったオファー、または新しいオファーを発行する過程でキャンセルされたオファーを示すことができます。キャンセルされたオファーは識別できます。これは、キャンセルされたオファーを発行したAccountは、そのオファーを削除するトランザクションの送信元であるためです。

削除されたオファーの例:

{
  "DeletedNode": {
    "FinalFields": {
      "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
      "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C595EDE3E1EE9",
      "BookNode": "0000000000000000",
      "Expiration": 608427144,
      "Flags": 0,
      "OwnerNode": "0000000000000000",
      "PreviousTxnID": "0CA50181C1C2A4D45E9745F69B33FA0D34E60D4636562B9D9CDA1D4E2EFD1823",
      "PreviousTxnLgrSeq": 46493676,
      "Sequence": 1082533,
      "TakerGets": {
        "currency": "EUR",
        "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
        "value": "2157.675"
      },
      "TakerPays": "7500000000"
    },
    "LedgerEntryType": "Offer",
    "LedgerIndex": "9DC99BF87F22FB957C86EE6D48407201C87FBE623B2F1BC4B950F83752B55E27"
  }
}

オファーでは、両方のタイプのDirectoryNodeオブジェクトを作成、削除、変更して、オファーの発行者と、どのオファーがどのような為替レートで利用可能になっているのかを追跡できます。一般的に、ユーザーがこのブックキーピングに細かな注意を払う必要はありません。

削除するオファーがなかった場合でも、OfferCancelトランザクションには、コードtesSUCCESSが含まれる可能性があります。トランザクションが実際にオファーを削除したことを確認するには、LedgerEntryTypeがOfferのDeletedNodeを探します。削除されていなかった場合は、そのオファーは以前のトランザクションによってすでに削除された可能性があります。またはOfferCancelトランザクションで、OfferSequenceフィールドに誤ったシーケンス番号が使用された可能性があります。

OfferCreateトランザクションが、タイプがRippleStateのCreatedNodeを示す場合は、取引で受け取った発行済み通貨を保持するために、オファーがトラストラインを作成したことを示しています。

Escrow

成功したEscrowCreateトランザクションは、レジャーにEscrowオブジェクトを作成します。LedgerEntryTypeがEscrowのCreatedNodeエントリーを探します。NewFieldsには、escrowに預託されたXRPと同じAmountと、指定したその他のプロパティが示されます。

成功したEscrowCreateトランザクションは、送金元から同じ額のXRPを引き出します。最終的なフィールドのAccountがトランザクションの指示にあるAccountのアドレスと一致する、LedgerEntryTypeがAccountRootのModifiedNodeを探します。XRPのBalanceは、（トランザクションコストの支払いのためにXRPが消却されたのに加えて）XRPがescrowに預託されたため減少します。

成功したEscrowFinishトランザクションは、受取人のAccountRootを変更して（Balanceフィールドの）XRP残高を増やし、Escrowオブジェクトを削除し、escrow作成者の所有者数を減らします。escrow作成者、受取人および終了者をすべて異なるアカウントにしても、同じアカウントにしてもかまわないため、結果としてLedgerEntryTypeがAccountRootのModifiedNodeオブジェクトが 1～3個 になる可能性があります。XRPがescrowの最初の作成者に返されることを除けば、成功したEscrowCancelトランザクションは極めて類似しています。

EscrowFinishは、escrowの条件を満たす場合にのみ成功し、EscrowCancelはEscrowオブジェクトの期限が前のレジャーの閉鎖時刻よりも前である場合にのみ成功します。

Escrowトランザクションでは、関係する送金元の所有者準備金やアカウントのディレクトリーを調整するために通常のブックキーピングも行われます。

次に示すコードの抜粋では、r9UUEX...の残高が10億XRP増加し、その所有者の数が1人減少しています。これは、そのアカウントからの自分自身へのescrowが正常に終了したためです。第三者がescrowを完了したためSequence番号は変更されません。

{
 "ModifiedNode": {
    "FinalFields": {
      "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
      "Balance": "1650000199898000",
      "Flags": 1048576,
      "OwnerCount": 11,
      "Sequence": 23
    },
    "LedgerEntryType": "AccountRoot",
    "LedgerIndex": "13FDBC39E87D9B02F50940F9FDDDBFF825050B05BE7BE09C98FB05E49DD53FCA",
    "PreviousFields": {
      "Balance": "650000199898000",
      "OwnerCount": 12
    },
    "PreviousTxnID": "D853342BC27D8F548CE4D7CB688A8FECE3229177790453BA80BC79DE9AAC3316",
    "PreviousTxnLgrSeq": 41005507
  }
},
{
  "DeletedNode": {
    "FinalFields": {
      "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
      "Amount": "1000000000000000",
      "Destination": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
      "FinishAfter": 589075200,
      "Flags": 0,
      "OwnerNode": "0000000000000000",
      "PreviousTxnID": "D5FB1C7D18F931A4FBFA468606220560C17ADF6DE230DA549F4BD11A81F19DFC",
      "PreviousTxnLgrSeq": 35059548
    },
    "LedgerEntryType": "Escrow",
    "LedgerIndex": "62F0ABB58C874A443F01CDCCA18B12E6DA69C254D3FB17A8B71CD8C6C68DB74D"
  }
},

Payment Channel

Payment Channelの作成時に、LedgerEntryTypeがPayChannelのCreatedNodeを探します。また、送金元の残高の減少を示す、LedgerEntryTypeがAccountRootのModifiedNodeも探す必要があります。アドレスが送金元に一致することを確認するためにFinalFieldsのAccountフィールドを探し、XRP残高の変化を確認するためにBalanceフィールドの差異を確認します。

fixPayChanRecipientOwnerDir Amendment が有効な場合は、メタデータは宛先のアカウントの所有者ディレクトリーを変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが削除されることを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）

Payment Channelの閉鎖を要求する方法は、Payment Channelの不変のCancelAfter時刻（作成時にのみ設定されます）以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeがPayChannelのModifiedNodeエントリーがあり、FinalFieldsのExpirationフィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合にPayChannelに対して行われる変更を示します。

{
  "ModifiedNode": {
    "FinalFields": {
      "Account": "rNn78XpaTXpgLPGNcLwAmrcS8FifRWMWB6",
      "Amount": "1000000",
      "Balance": "0",
      "Destination": "rwWfYsWiKRhYSkLtm3Aad48MMqotjPkU1F",
      "Expiration": 608432060,
      "Flags": 0,
      "OwnerNode": "0000000000000002",
      "PublicKey": "EDEACA57575C6824FC844B1DB4BF4AF2B01F3602F6A9AD9CFB8A3E47E2FD23683B",
      "SettleDelay": 3600,
      "SourceTag": 1613739140
    },
    "LedgerEntryType": "PayChannel",
    "LedgerIndex": "DC99821FAF6345A4A6C41D5BEE402A7EA9198550F08D59512A69BFC069DC9778",
    "PreviousFields": {},
    "PreviousTxnID": "A9D6469F3CB233795B330CC8A73D08C44B4723EFEE11426FEE8E7CECC611E18E",
    "PreviousTxnLgrSeq": 41889092
  }
}

TrustSetトランザクション

TrustSetトランザクションは、RippleStateオブジェクトとして表されるトラストラインを作成、変更、または削除します。1つのRippleStateオブジェクトに、関与する両当事者の設定が含まれます。これには両当事者の制限やRipplingの設定などがあります。トラストラインの作成と変更によって送金元の所有者準備金と所有者ディレクトリーの調整も行われます。

以下の例は、rf1BiG... がrsA2Lp... によって発行されたUSDを最大110 USDまで保持するという新しいトラストラインを示します。

 {
  "CreatedNode": {
    "LedgerEntryType": "RippleState",
    "LedgerIndex": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B",
    "NewFields": {
      "Balance": {
        "currency": "USD",
        "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
        "value": "0"
      },
      "Flags": 131072,
      "HighLimit": {
        "currency": "USD",
        "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
        "value": "110"
      },
      "LowLimit": {
        "currency": "USD",
        "issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
        "value": "0"
      }
    }
  }
}

その他のトランザクション

その他のほとんどのトランザクションは、特定のタイプのレジャーエントリーを作成し、送金元の所有者準備金と所有者ディレクトリーの調整を行います。

AccountSetトランザクションは、送金元の既存のAccountRoot objectを変更し、指定されたとおりに設定とフラグを変更します。
DepositPreauthトランザクションは、特定の送金元のDepositPreauthオブジェクトを追加または削除します。
SetRegularKeyトランザクションは、送金元のAccountRootオブジェクトを変更し、指定されたとおりにRegularKeyフィールドを変更します。
SignerListSetトランザクションは、SignerListオブジェクトを追加、削除、または置換します。

疑似トランザクション

疑似トランザクションにもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（このAccountの値は、base58エンコード形式の数字の0です）、レジャーのAccountRootオブジェクトを変更してSequenceシーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。

EnableAmendment疑似トランザクションは、Amendmentレジャーオブジェクトを変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
SetFee疑似トランザクションは、FeeSettingsレジャーオブジェクトを変更して、トランザクションコストおよび必要準備金のベースレベルを変更します。