既知のAmendment

[ソース]

メインネットの既知のAmendment

以下に示すのは、本番環境のXRP Ledgerに関する既知のAmendmentのすべてとそのステータスをまとめた総合リストです。

ヒント: このリストは手動で更新されています。最新のステータスはXRPScan Amendmentダッシュボードをご覧下さい。

注記: 多くの場合、旧バージョンのソフトウェアには不完全バージョンの修正用コードが存在します。上の表内の「導入済み」バージョンは最初の安定バージョンです。「未定」は、修正がまだ安定していないと見なされていることを示します。

開発中のAmendment

以下は、現在開発中のAmendmentのリストで、変更をテストするためのテストネットが利用可能です。

名前	ステータス	追加情報
Hooks		XRPL Hooks
OwnerPaysFee

注記: このリストは手動で更新されています。もしあなたがAmendmentに取り組んでいて、その変更をテストするためのテストネットワークを持っているなら、このページを編集して開発中のamendmentをこのリストに追加することができます。XRP Ledgerへの貢献についての詳細は、XRP Ledgerのコードへの貢献をご覧ください。

撤回または廃止されたAmendment

以下は、以前のバージョンで廃止され削除された、あるいは撤回され削除のマークが付けられた、既知のAmendmentの一覧です。

名前	登場	ステータス
fixNFTokenNegOffer	v1.9.2
fixNFTokenDirV1	v1.9.1
NonFungibleTokensV1	v1.9.0
CryptoConditionsSuite	v0.60.0
SHAMapV2	v0.32.1
FlowV2	v0.32.1
SusPay	v0.31.0
Tickets	v0.30.1

既知のAmendmentsの詳細

fixAMMOverflowOffer

このAmendmentにより、決済エンジンにおけるAMMの大規模な合成オファーの不適切な処理が修正されます。このAmendmentは重大な修正であるため、ソースコードのデフォルトの投票はYESに設定されています。

fixInnerObjTemplate

このamendmentにより、AMMのsfVoteEntryとsfAuctionSlotの内部オブジェクトのsfTradingFeeフィールドとsfDiscountedFeeフィールドにアクセスする際の問題が修正されました。

現在、内部オブジェクトのテンプレートはオブジェクトの生成時に設定されません。オブジェクトにsoeDEFAULTフィールドがあり、初期値にデフォルト値が設定されている場合、そのフィールドにアクセスすると、状況によってはtefEXCEPTIONエラーが発生します。このamendmentにより、内部オブジェクトテンプレートを設定するための追加の真偽値引数を含むSTObjectコンストラクタのオーバーロードが追加されます。

fixNFTokenReserve

このamendmentにより、NFTokenAcceptOfferトランザクタにOwnerCountが変更されたかどうかのチェックが追加されます。変更された場合、更新されたオブジェクト数に対して準備金要件が満たされているかどうかを追加でチェックします。

fixDisallowIncomingV1

このamendmentにより、ユーザが自分のアカウントでlsfDisallowIncomingTrustlineフラグを有効にした後にトラストラインを承認する際の問題が修正されます。

この問題を再現するには

1. 発行者が自分のアカウントにasfRequireAuthを設定します。

2. ユーザが自分のアカウントにasfDisallowIncomingTrustlineを設定します。

3. ユーザはSetTrustトランザクションを発行者に送信します。

4. 発行者はトラストラインを承認できません。

このamendmentにより、発行者はトラストラインを認可できるようになりました。

このamendmentは、DisallowIncoming amendmentが有効でない場合、影響はありません。

fixFillOrKill

このamendmentはFlowCrossamendmentで導入された問題を修正します。tfFillOrKillフラグが設定され、tfSellフラグが設定されていないオファーは、オファーの取引レートがオーダーブックのレートよりも良いが、完全に一致しない場合に失敗します。

このamendmentにより、決済エンジンはこのシナリオを適切に処理できるようになり、オファーの交差が可能になります。

このamendmentは、FlowCross amendmentが有効でない場合、影響はありません。

DID

World Wide Web Consortium標準に準拠した分散アイデンティティ(DID)機能を追加します。DIDは、中央集権的な機関に依存せず、DID主体によって管理されるデジタルIDを提供します。

次の新しいトランザクションを追加します。

• DIDDelete - XRPLアカウントに関連付けられたDIDを削除します。
• DIDSet - 新しいDIDを作成するか、既存のDIDを更新します。

新しいDIDレジャーエントリタイプを追加します。

いくつかの新しいトランザクション結果コードを追加します。

AMM

既存の分散型取引所と統合された形で、自動マーケットメーカー(AMM)機能に追加します。各アセット（トークンまたはXRP）のペアは、Ledger上に最大1つのAMMプールを持つことができ、誰でも流動性を提供することで、収益と為替リスクを比例配分することができます。各AMMプールのインスタンスはその資産を保持するための特別なアカウントを持ち、流動性プロバイダーに対してその預入額に応じて"LPトークン"を発行します。流動性プロバイダーは、LPトークンのシェアに基づいてAMMプールの取引手数料に投票することができます。ユーザは、一定期間取引手数料が割引される権利にLPトークンを使って入札することができます。

追加される新規トランザクション

• AMMBid - 取引手数料を割引するAMMプールのオークション枠に入札します。
• AMMCreate - AMMプールの新しいインスタンスを作成し、初期資金を供給します。
• AMMDelete - 空となったAMMプールのインスタンスを削除します。
• AMMDeposit - 既存のAMMプールに資金を供給し、LPトークンを受け取ります。
• AMMWithdraw - LPトークンをAMMプールに返却して資金を引き出します。
• AMMVote - AMMプールの取引手数料について投票します。

既存のトランザクションを新たな機能でアップデートします。

• 資産の取引に利用可能なPaymentとOfferCreateトランザクションは、より最良の取引レートを利用可能とするためにOfferとAMMの任意の組み合わせを利用します。
• AMMの特別なアカウントに送信できないトランザクションがあります（例えば、AMMはCheckを換金できないため、AMMへのCheckCreateは許可されません）。

新しいタイプのレジャーエントリAMMを追加し、AccountRootレジャーエントリタイプにAMMIDフィールドを追加します。

いくつかの新しい結果コードを追加します。

CheckCashMakesTrustLine

CheckCashトランザクションを修正し、Checkを現金化して発行されたトークンを入手すると、トークンを保持するトラストラインを自動的に作成するようにしました。この新しい動作は、ユーザが分散型取引所でトークンを購入する際のOfferCreateトランザクションの動作に似ています。自動的に作成されたトラストラインには限度額0が設定されています。これにより、Checkでトークンを受け取る前にトラストラインを設定するという設定ステップがなくなります。(XRPを送信するCheckは影響を受けません)。

この修正を適用しない場合、ユーザは、Checkを発行トークンと交換する前に、別途TrustSetトランザクションを送信する必要があります。

この修正は、XRP Ledgerにおいて不要なトークンを保持することを誰にも強制できないという原則を変えるものではありません。

Checks

「Checks」をXRP Ledgerに導入します。Checksは個人用の紙の小切手と同様の機能を持っています。送信者はトランザクションに署名して、具体的な最高額と受取人を入力したCheckを作成します。その後、受取人はCheckを換金して、指定された金額を上限として現金を受け取ることができます。金銭の移動が実際に発生するのはCheckが換金されるときなので、送信者の現在の残高と流動性の状況によっては、Checkを換金できない場合があります。Checkを換金できない場合、Checkオブジェクトはレジャーに残るため、後日換金できるようになる場合があります。

送信者と受信者は、換金前であればいつでもCheckを取り消すことができます。Checkには有効期限を設定できます。有効期限が過ぎた後は換金できなくなり、誰でもそのCheckを取り消すことができます。

新たに導入するトランザクションタイプは次の3つです。CheckCreate、CheckCancel、CheckCash。また、新しいレジャーオブジェクトタイプはCheckです。新たに追加するトランザクション結果コードtecEXPIREDは、有効期限が過去の日時であるCheckを作成しようとすると発生します。

Clawback

規制上の目的から、発行者の中には、発行されたトークンがアカウントに配布された後に回収する能力を持たなければならない場合があります。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を 回収(claw back) することができます。

Clawbackはデフォルトでは無効になっています。Clawbackを使用するには、AccountSetトランザクションを使用してlsfAllowTrustLineClawbackフラグを設定する必要があります。

この修正の詳細については、Clawbackをご覧ください。

XChainBridge

クロスチェーンブリッジを追加し、メインネットとサイドチェーンなどのネットワーク間でのデジタル資産の移動を可能にします。

次の新しいトランザクションを追加します

• XChainAccountCreateCommit - 発行チェーン上でトランザクションを提出するために、Witnessサーバ用の新しいアカウントを作成します。
• XChainAddAccountCreateAttestation - Witnessサーバが使用するアカウントが作成されたことを証明します。
• XChainAddClaimAttestation - ロックチェーンで資産がロックされた証明書を提出します。
• XChainClaim - 送信先チェーンで資産を請求します。
• XChainCommit - ロックチェーン上の資産をロックします。
• XChainCreateBridge - Bridgeレジャーオブジェクトを作成します。
• XChainCreateClaimID - クロスチェーン送金に使用される新しいクロスチェーン請求IDを作成します。
• XChainModifyBridge - ブリッジのパラメータを変更します。

次の新しいレジャーエントリタイプを追加します

• Bridge - XRP Ledgerを別のブロックチェーンと接続する単一のクロスチェーンブリッジ。
• XChainOwnedClaimID - 送信元チェーン上の資金をロックまたはバーンする送信元チェーン上のアカウントの情報を含むクロスチェーン送金の値(ID)。
• XChainOwnedCreateAccountClaimID - クロスチェーン送金でアカウントを作成する際の証明書。

いくつかの新しいトランザクション結果コードを追加します。

CryptoConditions

この修正は有効ですが、SusPay Amendmentも有効でない限り、何の影響も及ぼしません。SusPayの修正は、Escrowの修正に置き換えられたため、CryptoConditionsの修正は効力を持ちません。

CryptoConditionsSuite

EscrowCreateトランザクションとEscrowFinishトランザクションで使用するために、公式のCrypto-Conditions仕様から数種類のCrypto-Conditionsを導入するものでした。

しかし、この修正は実装が完了する前にrippled v0.60.0に追加されました。その結果、このAmendment IDは、ほとんど何もしない不完全なコードを参照することになりました。他のcrypto-conditionsのサポートを追加するために既存のAmendmentを変更すると、すでにリリースされたソフトウェアにある古いバージョンの修正案との衝突が発生します。将来のリリースで追加の暗号条件のサポートが追加される場合、新しい別のAmendment IDを使用する必要があります。

DeletableAccounts

アカウントを削除できるようになります。

この修正を適用しない場合、新しいアカウントはSequence番号が必ず1で始まります。また、レジャーの状態データからアカウントを削除できません。

この修正を適用した場合、新しいアカウントは、そのアカウントが作成されたレジャーのインデックスに一致するSequence番号に等しいSequence番号で始まります。この変更により、一度削除され、その後再作成されたアカウントが、古いトランザクションを再度実行しないように保護することができます。新しいAccountDeleteトランザクションタイプを追加すると、アカウントと、そのアカウントがレジャーに所有する特定のオブジェクトが削除されます。ただし、特定の種類のオブジェクトはこの方法で削除できないため、そのようなオブジェクトに関連付けられているアカウントは削除できません。また、現行のレジャーインデックスから256を引いた値がアカウントの現行Sequence番号より低い場合も、アカウントは削除できません。この修正に関する詳しい解説については、XRP Community Standards Draft 7をご覧ください。

DepositAuth

新しいアカウントフラグDepositAuthを追加します。これにより、他のアカウントから送信されたトランザクションに係る入金が厳密に拒否されます。企業はこのフラグを使用することで、あらゆる送金人からの送金を受け入れる前に規則に準拠して適切に対処することができます。

支払先のアカウントのこのフラグが有効になっている場合、支払いがXRPでなされるか、トークンでなされるかにかかわらず、Paymentトランザクションは失敗となります。アカウントが支払先である場合、支払先アカウント自体から上記のトランザクションが送信されなければ、EscrowFinishトランザクションとPaymentChannelClaimトランザクションは失敗します。Checks amendmentが有効である場合、CheckCashトランザクションを送信することによってXRPまたはトークンをアカウントで受け取ることができます。

例外として、DepositAuthが有効になっているアカウントでは、現在のXRP残高がアカウントの準備金を下回る場合、少額のXRP（アカウント準備金の最低額以下）のPaymentトランザクションを受け取ることができます。

また、EscrowCreateトランザクションとPaymentChannelCreateトランザクションで誤ってDisallowXRPフラグを適用してしまうバグも修正します。これは強制力のない勧告フラグとするものです。（レジャー自体にDisallowXRPフラグを適用しないことで、アカウント準備金を満たしトランザクションコストを支払うのに必要なXRPを、アカウントが引き続き受け取ることができます。）

DepositPreauth

Deposit Authorizationのユーザに特定の送信者を事前承認する手段を提供して、承認された送信者が支払いを直接送信できるようにします。

事前承認の追加または削除のために新しいトランザクションタイプDepositPreauthを、あるアカウントから別のアカウントへの事前承認の追跡のためにDepositPreauthレジャーオブジェクトタイプを追加します。JSON-RPCコマンドdeposit_authorizedを追加します。これは、アカウントが別のアカウントへ支払いを直接送金することが承認されているかどうかを問い合わせるためのものです。

あるアカウントからそれ自身へのクロスカレンシー決済において、そのアカウントがDeposit Authorizationを必要とする場合の動作を変更しました。このamendmentなしでは、これらの支払いは常にtecNO_PERMISSIONというコードで失敗します。この修正により、Deposit Authorizationが無効な場合と同様に、これらの支払いは成功します。

また、アカウントにDeposit Authorizationが必要な場合、アカウントから自身への異なる通貨間での支払いの動作も変更します。この修正を行わない場合、これらの支払いはコードtecNO_PERMISSIONにて常に失敗します。この修正を行う場合、これらの支払いはDeposit Authorization無効時と同様に成功します。

DisallowIncoming

Checks、Payment Channels、NFTokenOffer、およびトラストラインを自分のアカウントが受信するのを個別にブロックするためのオプションを提供します。アカウントでこれらのオプションを有効にすると、他のアカウントは、そのアカウントを宛先としてその種類のオブジェクトを作成することができなくなります。

4つの新しいAccountSet Flagsを追加し、AccountSetトランザクションで有効化および無効化できるように変更します。

• asfDisallowIncomingCheck
• asfDisallowIncomingPayChan
• asfDisallowIncomingNFTOffer
• asfDisallowIncomingTrustline

対応するオブジェクトタイプを作成する前に、これらのフラグの状態をチェックするようにトランザクション処理を変更します。宛先アカウントがそのフラグを有効にしている場合、トランザクションはエラーコードtecNO_PERMISSIONで失敗します。

この修正が適用されない場合、どのアカウントでも、任意のオブジェクトの宛先としてこれらのオブジェクトを作成することができます。これは通常問題はないものの、後でアカウントを削除する際に妨げになったり、詐欺の一部として使用される可能性があります。

EnforceInvariants

トランザクション処理にサニティーチェックを追加して、所定の条件が常に満たされるようにします。これにより、トランザクション処理時のバグを防ぐ独立した追加のレイヤーができます。このレイヤーがなければXRP Ledgerが脆弱なものとなり悪用される可能性が生じます。rippledの将来バージョンでは、Amendmentを追加せずに不変性チェックをさらに追加する予定です。

2つの新しいトランザクションエラーコード、tecINVARIANT_FAILEDとtefINVARIANT_FAILEDを導入します。新しいチェックを追加するためにトランザクション処理を変更します。

不変性チェックの例:

• トランザクションによって消却されたXRPの合計額は、トランザクションコストと正確に一致していなければなりません。
• XRPは作成できません。
• レジャー内のAccountRootオブジェクトは、DeletableAccountsが有効でない限り削除できません。（関連項目: アカウントの削除）
• レジャー内のオブジェクトのタイプは変更できません。（LedgerEntryTypeフィールドは変更できません。）
• XRPにトラストラインはありません。

Escrow

SusPayおよびCryptoConditions Amendmentを置き換えます。

XRP Ledger内のEscrowにXRPの「仮払い」機能を提供します。これにはInterledger Protocol Crypto-Conditionsのサポートが含まれます。仮払い用のレジャーオブジェクトタイプと、仮払いを作成、実行、取り消すためのトランザクションタイプを新規作成します。

ExpandedSignerList

この修正により、署名者リストの最大サイズが拡大され、各署名者にオプションのデータを関連付けることができるようになりました。追加データは署名者を特定するために使用でき、スマートコントラクトや、大規模な組織で誰が鍵を管理しているかを特定するのに便利です。例えば、IPv6アドレスやハードウェアセキュリティモジュール（HSM）の識別子を保存することができます。

この修正が適用されない場合、署名者リストの最大サイズは8人で、各署名者にはAccountとSignerWeightの2つのフィールドが存在します。

この修正により、SignerListオブジェクトの最大サイズは32エントリになります。さらに、各SignerEntryオブジェクトは、任意のデータを含む256ビットのWalletLocatorフィールドを含むことができます。この修正により、SignerListSetトランザクションもそれに応じて変更されます。

FeeEscalation

提案されたトランザクションにトランザクションコストを適用する方法を変更します。トランザクションコストの高いトランザクションの優先順位が高くなるよう、コンセンサスプロセスを変更します。

この修正により、前のコンセンサスラウンドに含められなかったトランザクションに固定サイズのトランザクションキューが導入されます。コンセンサスネットワーク内のrippledサーバに重い負荷が課されている場合、トランザクションコストの低いトランザクションは後のレジャーのキューに入れられます。各コンセンサスラウンドでは、トランザクションコスト（Fee値）が高いキューのトランザクションが優先され、コンセンサスネットワークで処理できる限りのトランザクションが含められます。トランザクションキューが一杯になると、トランザクションコストが最も低いトランザクションから順にキューから完全に除外されます。

コンセンサスネットワークに重い負荷がかかる一方で、正規のユーザは高めのトランザクションコストを支払い、トランザクションを確実に処理することができます。この状況は、未処理の低コストのトランザクションが完全に処理または除外されるまで続きます。

1つのトランザクションは、以下のいずれかが発生するまでキュー内に残ります。

• 検証済みレジャーに適用される（成功か失敗かには関係ありません）
• 無効になる（例えば、LastLedgerSequenceによって有効期限切れとなる）
• キュー内にトランザクションコストの高いトランザクションがたくさんあるため除外される

fix1201

送金手数料に限度を正しく導入し、100%の料金にします。これは、TransferRate値の最大値である2000000000を表します。（この場合の100%の料金とは、送信する1ユニットごとに2ユニットのトークンを送信する必要があることを意味します。）この修正を行わない場合、有効な限度はTransferRate値の2³²-1、つまり約329%の料金となります。

この修正を行う場合、AccountSetトランザクションのTransferRateを2000000000より高く設定すると、トランザクションは結果コードtemBAD_TRANSFER_RATEにて失敗します。以前のルールに従って高い値が設定されている既存のすべてのTransferRateには、そのまま高い率が適用されます。

fix1368

有効であるべき一部の支払いが失敗となる、トランザクション処理の小さなバグを修正します。具体的には、支払い処理中に、特定金額の通貨を生成する支払いステップの一部で、浮動小数点の表示に関する精度の不良により、わずかに異なる金額が生成されてしまうことがあります。この状況が発生すると、正確な金額を送金できないため支払いが失敗します。fix1368 Amendmentにより、トランザクション処理が修正されれば、このような支払いの失敗はなくなります。

fix1373

特定の支払いパスを作成する際にエラーを引き起こすトランザクション処理の小さなバグを修正します。この結果、有効であっても正しく作成されていないパスを、支払いで使用できなくなりました。この修正を行わない場合、支払い時に好ましくないパスの使用を強制されたり、失敗したりする恐れがあります。

fix1373 Amendmenによりこの問題は修正されるため、正しく作成されたパスを使用して支払いを行えます。また、現在は許可されているものの適切ではない一部のパスが無効になります。これには、同じオブジェクトを2回以上ループしてコンフリクトを起こすフィールドやパスを含むステップを持つパスが含まれます。

fix1512

一部の無効なPaymentChannelClaimトランザクションが、不正確なエラーコードで失敗するトランザクション処理のバグを修正します。この修正を行わない場合、トランザクションの結果コードはtecクラスとなりますが、レジャーに入力されず、トランザクションコストは支払われません。

この修正により、トランザクションは適切な結果コードtemBAD_AMOUNTにて失敗します。

fix1513

FeeEscalation Amendmentが行われると、新しいSTAmountCalcSwitchoversコードが使用されないトランザクション処理のバグを修正します。

この修正により、新しいSTAmountCalcSwitchoversコードが適用されるため、計算の違いによってトランザクション処理に若干の変更を生じる場合があります。金額の四捨五入のやり方が異なり、その結果、オファーが異なる順序で実行される場合があります。

fix1515

Paymentトランザクションがオファーを処理していく方法を変更して、支払処理とオファー処理における流動性の消費の仕方のわずかな違いをなくします。（FlowCrossが有効の場合、オファーCreateトランザクションの処理方法にも影響します。）

この修正を行わない場合、トランザクションが同じ為替レートで2000を超えるオファーを消費すると、支払い処理は特定のオーダーブックを使用しなくなります。この場合、支払いはそれらのオファーの流動性を使用せず、支払いを完了するときにそのオーダーブックに残された流動性を考慮しません。

この修正により、同じ為替レートで1000を超えるオファーを処理するトランザクションはすべて、そのトランザクションの最初の1000のオファーの流動性を消費し、支払いを完了時にはそのオーダーブックに残された流動性は考慮されません。

どちらの場合でも、トランザクション処理は他のパスまたは為替レートからの流動性を使用して完了できます。

fix1523

支払先アカウント別の追跡機能をEscrowに追加します。この修正を行わない場合、保留中のEscrowは送信者別にしか追跡できません。この修正により、account_objectsメソッドを使用して支払先アドレスごとに保留中のEscrowを調べることができます。ただし、この修正が有効になる前に作成された保留中のEscrowを除きます。また、この修正では、EscrowCreateトランザクションを支払先のトランザクション履歴に表示することができます。これはaccount_txメソッドによる表示と同様です。

この修正により、新しいEscrowが送信者と受信者両方の所有者ディレクトリーに追加されます。また、Escrowレジャーオブジェクトに新しいDestinationNodeフィールドも追加され、支払先の所有者ディレクトリのどのページにEscrowがあるかを表示します。

fix1528

バリデータがさまざまなタイムスタンプでコンセンサスレジャーを構築できることが原因で、検証済みレジャーの宣言プロセスに遅れをもたらす可能性があるバグを修正します。このような状況の発生は正確なタイミングを要するため、管理テスト環境の外部にいるバリデータがこのバグに遭遇することはあまりありません。

この修正は、バリデータがコンセンサスレジャーの終了時刻の交渉方法を変更して、レジャー内容について合意を得ることはできないが、異なるタイムスタンプでレジャーバージョンを構築できるようにします。

fix1543

予約済のフラグ範囲を、まだ正しく適用されていないトランザクションタイプに適用します。未定義または未知のフラグ、または予約された範囲のフラグが有効になっている場合、影響を受けるトランザクションタイプのトランザクションは無効と見なされるようになります。（この変更による影響を受けないトランザクションには、すでに同じルールが正しく適用されています。）

この修正を行わない場合、特定のタイプのトランザクションで未定義または予約されたフラグが有効になっていても、そのトランザクションタイプは有効と見なされます。

影響を受けるトランザクションタイプは以下のとおりです。

• Escrowトランザクション: EscrowCancel、EscrowCreate、EscrowFinish
• Payment Channelトランザクション: PaymentChannelClaim、PaymentChannelCreate、PaymentChannelFund

fix1571

以下のようにEscrowの問題を修正します。

• EscrowCreateトランザクションにConditionフィールドまたはFinishAfterフィールド（またはその両方）が必要となるように変更します。この修正以前に作成された、ConditionやFinishAfterのいずれも持たないEscrowは、CancelAfter時間より前ならいつでも誰でも終了できます。
• 時間ベースのEscrowが特定の状況下で終了されるのを誤って妨げる欠陥を修正します。

fix1578

以下の2つのトランザクションタイプから返される結果コードを変更します。

• OfferCreateトランザクションを変更して、オファーがtfFillOrKillフラグを使用していて中止された場合に、新しい結果コードtecKILLEDが返されるようにします。この修正を行わない場合、オファーは中止されますが、トランザクション結果はtesSUCCESSになります。
• TrustSetトランザクションを変更して、トラストラインがマイナス残高であるため、NoRippleフラグを有効にしようとしてもできない場合に、tecNO_PERMISSIONで失敗するようにします。この修正を行わない場合、トランザクションでNoRippleフラグを有効にできなくても、トランザクション結果はtesSUCCESSになります。

fix1623

変動金額で換金されたCheckCashトランザクションのメタデータに送金額を追加します。（Checks Amendmentが有効でないかぎり効果がありません。）

この修正を行うと、トランザクション処理にて変動金額のCheckCashトランザクションのメタデータにDeliveredAmountフィールドが追加されます（DeliverMinフィールドを使用します）。この変更はレジャーデータに書き込まれるため、この修正を行わずにトランザクションを処理した場合とは異なるレジャーハッシュとなります。これは実際に送信される金額には影響しません。また、この修正を有効にすると、txメソッドとaccount_txメソッドによってCheckCashトランザクションのdelivered_amountフィールドが返されます。（delivered_amountフィールドはトランザクションの検索時に計算されるものであり、レジャーに書き込まれるデータの一部ではありません。）

fix1623 Amendmentは、固定金額のCheckCashトランザクション（Amountフィールドを使用）またはその他のトランザクションタイプには影響しません。

fix1781

循環パスの検出時に、特定のXRPエンドポイントがチェックされない不具合を修正します。

この修正が適用されない場合、支払いパスの入力がXRPで、パスの中間ステップでもXRPが出力されるようなパスが存在し得ます。これは「ループ」決済であり、前方と後方で実行すると異なる結果になる可能性があるため、決済エンジンはこのようなパスを禁止しています。

この修正が適用された場合、これらの支払いは、代わりに結果コードtemBAD_PATH_LOOPで失敗します。

fixAmendmentMajorityCalc

丸め処理の影響により、Amendmentが過半数を達成した後、信頼できるバリデータの80%にわずかに満たない賛成で有効になることがあるバグを修正しました。

この修正が適用されない場合、Amendmentが有効になるための最小閾値は、信頼できるバリデータの204/256を丸めた値であり、これはその時の信頼できるバリデータの数に依存します。例えば、36人中28人(約77.8%)のバリデータがあれば、補正は有効になりえます。この修正により、実際に必要な最小限のバリデータの数は、信頼できるバリデータの80％を下回ることはありません。

fixCheckThreading

Checksトランザクションがアカウントのメタデータに影響を及ぼす方法を変更し、Checksが受信アカウントのアカウント履歴に適切に追加されるようにします。（具体的には、受信アカウントのAccountRootオブジェクトのPreviousTxnIDフィールドとPreviousTxnLedgerSeqフィールドを更新します。これは、アカウントと、アカウントが所有するオブジェクトに影響を及ぼしたトランザクションの「スレッド」を追跡するために使用できます。）

この修正を適用しない場合、Checksトランザクション（CheckCreate、CheckCash、およびCheckCancel）は送信者のアカウント履歴のみを更新します。この修正を適用した場合、これらのトランザクションは、送信アカウントにも受信アカウントにも影響します。この修正は、Checks Amendmentも有効でないかぎり効果がありません。

fixMasterKeyAsRegularKey

アカウントのレギュラーキーペアがマスターキーペアと一致するように設定できるものの、マスターキーが無効になった場合に、そのキーによって署名されたトランザクションを送信できなくなるバグを修正します。

この修正を適用しない場合、ユーザは、レギュラーキーがマスターキーと一致するように設定し、その後マスターキーを無効にすることで、意図せずアカウントを「ブラックホール」にしてしまうおそれがあります。ネットワークは、マスターキーペアとレギュラーキーペアの両方で署名されたトランザクションを拒否します。コードは、トランザクションが現在有効なレギュラーキーで署名されていると認識する前に、無効なマスターキーで署名されていると解釈するためです。

この修正を有効にした場合、SetRegularKeyトランザクションはレギュラーキーがマスターキーに一致するよう設定できないため、そのようなトランザクションでは、トランザクションコードがtemBAD_REGKEYになります。また、この修正により、署名検証コードが変更されるため、レギュラーキーがマスターキーに一致するよう_すでに_設定しているアカウントは、そのキーペアを使用して正常にトランザクションを送信できます。

fixNFTokenDirV1

この修正では、NFTokenオブジェクトがどのNFTokenPageに属するかを判断する際に、いくつかの特定のケースで発生した境界値判定エラーが修正されました。また、NFTokenPageの不変性チェックの制約を調整し、特定のエラーケースがtecINVARIANT_FAILEDエラーコードで失敗する代わりに、tecNO_SUITABLE_TOKEN_PAGEなどの適切なエラーコードで失敗するようにしました。

この修正は、NonFungibleTokensV1 Amendmentが有効でない限り、何の効果もありません。この修正は、その効果がNonFungibleTokensV1_1の一部として含まれているため、廃止されました。

fixNFTokenNegOffer

この修正は、NonFungibleTokensV1 Amendmentのコードにおいて、NFTが負の金額で取引されてしまうバグを修正したものです。この修正が適用されない場合、ユーザは負の金額でNFTの売買を申し込むことができ、その結果、NFTを「買う」人は「売る」人からお金も受け取ることになります。この修正により、マイナスの金額でのNFTのオファーは無効とみなされます。

この修正は、NonFungibleTokensV1 Amendmentが有効でない限り、何の影響もありません。この修正は、その効果がNonFungibleTokensV1_1の一部として含まれているため、廃止されました。

fixNFTokenRemint

fixNFTokenRemint Amendmentは、同じNFTが同じシーケンス番号で複数回鋳造され、衝突の可能性を生じさせる事態を防ぐため、NFTシーケンス番号の構成方法を変更するものです。このAmendmentにより、NFTシーケンス番号の構成が次のように変更されます。

• AccountRootに、新しいフィールドFirstNFTSequenceを作成します。このフィールドは口座が最初のNFTを発行したときに現在のアカウントシーケンスに設定されます。それ以外の場合は設定されません。

• FirstNFTSequence+MintedNFTokens（その後、MintedNFTokensは1ずつ増加）として、新しく作成されたNFTのシーケンスを計算します。

このamendmentにより、アカウント削除の制限も導入されます。アカウントは、FirstNFTSequence + MintedNFTokens + 256が現在のレジャーシーケンスより小さい場合にのみ削除できます（256はアカウント削除のヒューリスティックな制限として選択されたもので、アカウント削除制約にすでに存在します）。この制約がなければ、特定の条件下で同一のNFTが再ミントされる可能性があります。

fixNonFungibleTokensV1_2

fixNonFungibleTokensV1_2 Amendment は、プルリクエストプロセスを通じて個別に feature/nft-fixes にマージされたバグ修正の組み合わせです。

バーン不可能なNFTの修正

現在、NFTは500以上のオファーがあるとバーンすることができません。この制限を取り除くため、この修正では、NFTを焼却する際にちょうど500個のオファーを削除し、残りのオファーはそのままにします。これにより、発行者アカウントがlsfBurnableフラグを有効にしたNFTを、オファー数が多いために焼却できない問題が解決されます。

参考: PR 4346.

NFTokenのオファー承認に関する3つの問題の修正

問題1：アカウントが資金不足という誤った条件により、取引を仲介できない問題を解決する。

問題2：買い手がアカウントの送金手数料をカバーするための資金が不足している問題を解決する。

問題3：トークン発行者が自身のトークンでNFTを売買できるようにする。

参考: PR 4380.

NFTokenの所有者への売却が仲介されないようにする （#4374を修正）

この修正により、ブローカーが既にトークンを保有しているアカウントに対してNFTを販売することができなくなります。

参考: Issue 4374.

宛先のみがNFTオファーのブローカー決済可能とする (#4373を修正)

NFTオファーに宛先を設定した場合、その宛先のみが仲介で決済できるように修正します。

参考: Issue 4373.

fixPayChanRecipientOwnerDir

PaymentChannelCreateトランザクションタイプを変更し、受取人の所有者ディレクトリに新しいPayment Channelが追加されるようにします。この修正を適用しない場合、新しいPayment Channelは送金者の所有者ディレクトリーにのみ追加されます。この修正を有効にする場合、新しく作成したPayment Channelは両者の所有者ディレクトリーに追加されます。既存のPayment Channelは変更されません。

この修正により、受取人によるPayment Channelの検索が容易になります。また、アカウントがオープンPayment Channelの受取人だった場合に、そのアカウントが削除されないようにします（ただし、この修正の前に作成されたチャンネルを除きます）。

fixQualityUpperBound

クロスカレンシー決済における個々のステップの入出力比を計算するための使用されていないコードのバグを修正する。

この修正は、取引処理に影響を及ぼさないことが確認されています。

fixReducedOffersV1

四捨五入を調整し、残額の四捨五入によって為替レートが影響を受ける減額オファーによってオーダーブックがブロックされることを回避します。

一般的に、オファーは3つの方法で減額することができます：

• オファーは、注文時に部分的に約定することができます。
• オファーはオーダーブックに登録された後、部分的に約定されることがあります。
• オファーは資金不足(オファーの所有者が指定した資金よりも少ない資金しか持っていない状態)になる可能性があります。

このamendmentにより、減額されたオファーの取引レートは、(テイカーの観点から)元のオファーと同等かそれ以上となるように丸められます。これにより、減額されたオファーは、元の全額と一致するオファーによって約定されます。丸められた金額は、XRPの1ドロップまたはトークンの1e-81を超えることはありません。

このamendmentがない場合、残額が非常に少ないオファーは、四捨五入後の取引レートが当初よりも大幅に悪化する可能性があります。このため、非常に少額のオファーが、同じオーダーブック内のより良いオファーの取得を「ブロック」してしまう可能性があります。

fixRemoveNFTokenAutoTrustLine

このフラグを使用した発行者に対するDoS攻撃から保護するために、非代替性トークンのtfTrustLine設定を削除します。このフラグを有効にすると、tfTrustLineフラグを有効にしたNFTokenMintトランザクションは無効とみなされ、コンセンサスによって検証されません。したがって、NFTokenオブジェクトはこのフラグを使用してミントをすることができません。

この修正が適用されない場合、攻撃者は意味のない新しい代替可能トークンを作り、そのトークンとNFTを売買することで、発行者に紐づく多数の無駄なトラストラインを作り、発行者の準備金を増加させることができます。

この修正は、すでにミントされたNFTokenオブジェクトのコードを変更するものではありません。NonFungibleTokensV1_1がすでに有効になっているテストネットワークでは、tfTrustLineフラグが有効なNFTokenをすでにミントしている発行者は、fixRemoveNFTokenAutoTrustLine Amendmentの有効後も脆弱性があることを意味しています。

この修正は、NonFungibleTokensV1または NonFungibleTokensV1_1が有効になっていない限り、影響を及ぼしません。発行者を保護するため、このamendmentはNonFungibleTokensV1またはNonFungibleTokensV1_1の前に有効にする必要があります。

fixRmSmallIncreasedQOffers

この修正は、特定のオファーがほとんど約定された状態で、そのオファーが最初に配置されたときよりも取引レートが大幅に悪化する問題を修正するものです。これは、片方または両方の資産の残額が非常に小さいため、オファーが置かれたときと同様の比率に丸めることができない場合に起こるものです。

この修正が適用されない場合、この状態でのオファーは、よりレートの良いオファーがより深いオーダーブックでブロックされ、本来成功するはずの支払いやオファーが失敗することがあります。

この修正により、決済および取引は、通常、トランザクションが約定済みまたは未約定のオファーを削除するのと同じ方法で、これらのタイプのオファーを削除できるようになります。

fixSTAmountCanonicalize

Amount型フィールドのデシリアライズにおけるエッジケースの問題を修正しました。この修正が適用されない場合、一部の稀なケースで、この操作により、デシリアライズ中に有効なシリアライズされた金額がオーバーフローしてしまう可能性がありました。この修正により、XRP Ledgerはより迅速にエラー状態を検出し、問題となるようなケースを排除します。

fixTakerDryOfferRemoval

XRP Ledger内にドライオファーを残す可能性があるオートブリッジのバグを修正します。ドライオファーとは、オファーを掛け合わせても資金を調達できないオファーのことです。

この修正を行わなければ、ドライオファーがレジャー上に残り、所有者の必要準備金に加算されることになり、所有者に何も利益をもたらしません。正しいタイプとクオリティで掛け合わせた別のオファーによって、ドライオファーを除去することができます。ただし、タイプとクオリティがうまく掛け合わされたオファーがめったにない場合、ドライオファーの除去には時間がかかることがあります。

この修正により、これらのドライオファーがオートブリッジで一致した場合に、XRP Ledgerによって除去されます。

fixTrustLinesToSelf

この修正により、古いバグにより作成されたアカウントから自身へのトラストラインが2つ削除されます（いずれも2013-05-07のもの）。この修正が有効になると、IDが2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1と326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1Aのトラストラインが存在していれば削除します。削除後、この修正は他に何もしません。

これらのトラストラインを持たないテストネットワークでは、この修正はは何の影響も及ぼしません。

fixUniversalNumber

10進浮動小数点演算のコードを簡略化し、統合します。場合によっては、以前のコードよりも精度が若干向上し、最下位桁が以前のコードで計算したときと異なる計算結果になることがあります。この計算結果の違いにより、オファーのランキングや複数の異なるパスを使用する支払い処理など、精密な計算が使用される他のエッジケースにおいて違いが生じる場合があります。 この修正が適用されない場合、コードは引き続きSTAmountとIOUAmountオブジェクトに対して別々の計算を使用し、自動マーケットメーカー(XLS-30d)は計算のために新しい3つめの計算方法を使用します。

Flow

支払い処理エンジンを、より堅固で効率的に作られたFlowエンジンに置き換えます。この新バージョンの支払い処理エンジンは、旧バージョンと同じルールを踏襲しますが、浮動小数点の丸め処理により異なる結果をもたらすことがあります。この修正はFlowV2 Amendmentに代わるものです。

また、Flowエンジンは、さらなるAmendmentを通じて、支払いエンジンの改善や拡張を容易にします。

FlowCross

XRP Ledgerの分散型取引所において、オファーの掛け合わせのロジックを合理化します。Flow Amendmentから更新されたコードを使用してオファーの掛け合わせを行うため、OfferCreateトランザクションとPaymentトランザクションは多くのコードを共有します。オファーの処理方法には微妙な違いがあります。

• 丸め方が一部のケースで少し異なります。
• 丸め方の違いが原因で、一部のオファーの組み合わせのランク付けが以前のロジックより上下したり、優先されたりします。
• 新しいロジックによって、以前のロジックより多めまたは少なめにオファーが削除される場合があります。（これには、丸め方の違いによるケースや、以前のロジックによって資金供給なしとして不正に削除されたオファーが含まれます。）

FlowSortStrands

決済エンジンの計算を改善し、最もコスト効率の良いクロスカレンシー取引の実行方法を見つけます。

この修正が適用されない場合、エンジンは可能な各パスを介して支払いをシミュレートし、各パスの品質（入力と出力の比率）を計算します。この修正により、エンジンは完全な支払いをシミュレートすることなく、各パスの理論的な品質を計算します。この変更により、決済エンジンは一部のクロスカレンシー決済をより速く実行し、より多くのケースで最も費用対効果の高いパスを見つけることができるようになり、従来の決済エンジンでは十分な流動性を見つけることができなかった特定の条件でも、一部の決済を成功させることができるようになります。

FlowV2

これはFlow Amendmentの旧バージョンです。バグが原因で不採用となり、バージョン0.33.0で除外されました。

HardenedValidations

バリデータは、バリデータが完全に検証されたとみなす最新の台帳のハッシュを証明する新しいオプションフィールドをバリデーションに含めることができるようにします。コンセンサスプロセスでは、この情報を使用してコンセンサスの堅牢性を高めることができます。

Hooks

トランザクションの前後にアカウント上で実行できる小さなコードという形式で、オンチェーンのスマートコントラクトを追加します。詳細はHooksドキュメント （英語のみ）をご覧ください。

ImmediateOfferKilled

オファーがtfImmediateOrCancelを使用し、トランザクション処理で資金を移動せずにオファーを終了した場合、トランザクションはtesSUCCESSではなく結果コードtecKILLEDを使用するようにOfferCreateトランザクションを変更します。Offerが少額でも資金を交換した場合、トランザクションは引き続きtesSUCCESSを使用します。トランザクションの処理自体には変更はありません（例えば、トランザクション処理中に台帳に表示された期限切れのオファーや未入金のオファーをクリーンアップするかどうかという点など）。

この修正が適用されない場合、資金の移動に失敗した「Immediate or Cancel」注文は、結果コード「tesSUCCESS」を返し、そのトランザクションが事実上何もしなかったため、混乱する可能性を残します。

MultiSign

トランザクションの承認方法としてマルチシグを導入します。SignerListレジャーオブジェクトタイプとSignerListSetトランザクションタイプを作成します。省略可能なSignersフィールドをすべてのトランザクションタイプに追加します。一部のトランザクション結果コードを変更します。

この修正により、マルチシグのアドレスからトランザクションを承認できる署名者のリストをそのアドレスに保持できるようになります。このリストには定数があり、1から8で重み付けされた署名者が記載されています。これにより、「5人のうち任意の3人」や「Aの署名とその他任意の2人の署名」などの多様な設定が可能になります。

署名者は資金供給のあるアドレスでも資金供給のないアドレスでも可能です。署名者リストのうち資金供給のあるアドレスは、レギュラーキー（定義済みの場合）またはマスターキー（無効でない場合）を使用して署名できます。資金供給のないアドレスは、マスターキーを使用して署名できます。マルチシグトランザクションは、レギュラーキーで署名されたトランザクションと同じ権限を持ちます。

SignerListを持つアドレスは、レギュラーキーが定義されていなくてもマスターキーを無効にすることができます。また、SignerListを持つアドレスは、マスターキーが無効な場合でもレギュラーキーを削除することができます。tecMASTER_DISABLEDトランザクション結果コードはtecNO_ALTERNATIVE_KEYに名前が変更されます。tecNO_REGULAR_KEYトランザクション結果コードは廃止となり、tecNO_ALTERNATIVE_KEYに代わります。さらに、この修正は以下の新しいトランザクション結果コードを追加します。

• temBAD_SIGNER
• temBAD_QUORUM
• temBAD_WEIGHT
• tefBAD_SIGNATURE
• tefBAD_QUORUM
• tefNOT_MULTI_SIGNING
• tefBAD_AUTH_MASTER

MultiSignReserve

XRP LedgerアカウントがマルチシグSignerListを所有する場合、アカウントに加算される所有者準備金を削減します。

この修正を行わない場合、SignerListの所有者準備金は、リスト内の署名者数に応じて15～50XRPの範囲となります。

この修正により、新しいSignerListの所有者準備金は、署名者数に関係なく5XRPとなります。以前に作成されたSignerListオブジェクトの準備金は、そのまま変更されません。この修正の後に作成されたSignerListオブジェクトの準備金を削減するには、この修正実施後に、SignerListSetトランザクションを使用してSignerListを置き換えます。（この置き換えは、前のバージョンの場合とまったく同じです。）

NegativeUNL

ネットワークがどのバリデータが一時的にオフラインになったかを追跡し、定足数計算の際にそれらのバリデータを無視できる「ネガティブUNL」システムを実装します。これにより、ネットワークが不安定な状態でも、ネットワークを進展させる能力を高めることができます。

NonFungibleTokensV1

非代替性トークンのネイティブサポートを追加します。標準規格案: XLS-20d。

注意: この修正には、台帳にtecINVARIANT_FAILEDエラーが表示される問題を含む、いくつかの既知の問題が存在します。これはNonFungibleTokensV1_1 Amendmentに置き換えられました。

この修正では、新たに5種類のトランザクションが追加されます。

• NFTokenAcceptOffer
• NFTokenBurn
• NFTokenCancelOffer
• NFTokenCreateOffer
• NFTokenMint

また、新たに2種類の台帳オブジェクトが追加されます。

• NFTokenOffer object
• NFTokenPage object

さらに、AccountRootオブジェクト型を変更し、MintedNFTokens、BurnedNFTokens、NFTokenMinterの3つの新しい任意のフィールドを追加しています。

また、AccountSetトランザクションを変更し、NFTokenMinterフィールドを設定できるようにしました。

NonFungibleTokensV1_1

NonFungibleTokensV1の後に発見されたいくつかの問題の修正を含む非代替性トークンのネイティブサポートを追加します。

この修正は、以下の修正内容を統合し、個々のAmendmentsを廃止するものです。

• NonFungibleTokensV1
• fixNFTokenNegOffer
• fixNFTokenDirV1

それ以外の影響はありません。

注意: fixRemoveNFTokenAutoTrustLineは、このAmendmentの既知の問題を修正します。新しいテストネットワークを作成する場合、これらの修正を一緒に有効にするか、またはAmendmentの修正を先に有効にする必要があります。

OwnerPaysFee

OfferCreateトランザクションタイプとPaymentトランザクションタイプで、送金手数料の計算方法に相違があるのを修正します。この修正を行わない場合、オファーがオファープレースメントで実行される際にイシュアンスの保有者が送金手数料を支払いますが、トランザクションの最初の送信者は支払い処理の過程で実行されるオファーの送金手数料を支払います。この修正により、オファーがPaymentトランザクションまたはOfferCreateトランザクションの一部として実行されるかどうかにかかわらず、イシュアンスの保有者が常に送金手数料を支払います。支払い以外のオファー処理は影響を受けません。

この修正については、Flow Amendmentを有効にする必要があります。

注記: 不完全なバージョンのこのAmendmentについては、v0.33.0で導入され、v0.80.0で削除されました（有効となったことはありません）。

PayChan

XRPの「Payment Channel」を作成します。Payment Channelは、2名の当事者間で一方向の繰り返しの支払い、またはそれに伴う一時的な貸付を容易に行えるようにするツールです。Rippleは、この機能がInterledger Protocolに役立つと期待しています。ある当事者がPayment Channelを作成し、そのチャンネル内に有効期限を事前に設定してXRPをいくらか確保します。次に、レジャー外部の安全な通信を介して、送信者は「クレーム」メッセージを受信者に送信できます。受信者は有効期限の終了前にクレームメッセージを清算することも、支払いが必要ない場合は清算しないことも選択できます。受信者は、クレームを実際にネットワークに分散させてコンセンサスプロセスで清算されるのを待たなくとも、請求を個々に確認してから、有効期限内であれば多数の少額クレームをまとめて後で清算することができます。

新たに作成するトランザクションタイプは次の3つです。PaymentChannelCreate、PaymentChannelClaim、PaymentChannelFund。新たに作成するレジャーオブジェクトタイプはPayChannelです。レジャー外のデータ構造Claimを定義し、ChannelClaimトランザクションに使用します。新たに作成するrippledAPIメソッドは次のとおりです。channel_authorize（署名されたクレームを作成します）、channel_verify（署名されたクレームを検証します）、account_channels（アカウントに関連するチャンネルをリストを作成します）。

詳細は、Payment Channelsのチュートリアルをご覧ください。

RequireFullyCanonicalSig

XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも完全に正規でない署名は無効とします。これにより、tfFullyCanonicalSigフラグを有効にしたトランザクションのみを保護することに代わって、すべての トランザクションにおいてトランザクションの展性から守られます。

この修正が適用されない場合、トランザクションがsecp256k1署名を使用し、tfFullyCanonicalSigが有効でない場合は、変更可能となります。ほとんどの署名ユーティリティは、デフォルトでtfFullyCanonicalSigを有効にしていますが、例外もあります。

この修正により、単独署名のトランザクションは展性になりません。(署名者が必要以上の署名を提供した場合、マルチシグのトランザクションはまだ展性であるかもしれません)。すべてのトランザクションは、tfFullyCanonicalSigフラグに関係なく、署名の完全な正規の形式を使用する必要があります。完全に正規化された署名を作成しない署名ユーティリティはサポートされていません。Ripple社が提供するすべての署名ユーティリティは、少なくとも2014年以降、完全に正規化された署名のみを提供するようになっています。

詳しくは、rippled issue #3042をご覧ください。

SHAMapV2

rippledがレジャーを表示する際に使用するハッシュツリー構造を変更します。新しい構造は以前のバージョンよりもコンパクトで効率的です。この修正はレジャーハッシュの計算方法が変わりますが、その他にユーザに与える影響はありません。

この修正が適用されると、ネットワークでハッシュツリー構造への変更を計算している間、XRP Ledgerはしばらく使用できなくなります。

SortedDirectories

DirectoryNodeレジャーオブジェクト内の項目をソートして、削除されるべき所有者ディレクトリのページが場合によっては削除されないというバグを修正します。

警告: このが適用されていない旧バージョンのrippledは、新しいルールでソートされたDirectoryNodeによって機能が停止するおそれがあります。この問題を回避するには、rippledバージョン0.80.0以降にアップグレードしてください。

SusPay

この修正は、Escrow Amendmentに置き換えられました。

TicketBatch

この修正により、通常のシーケンス番号順ではないトランザクションを送信する方法として、Ticketsが追加されます。

標準規格案: XLS-13d.

Tickets

この修正は、TicketBatch Amendmentに置き換えられました。

TickSize

オーダーブック内でオファーをランク付けする方法を変更して、通貨発行者がオファーを為替レートでランク付けする際に考慮する有効桁数を設定できるようにします。この修正により、オファーの交換レートが設定された有効桁数に丸められるため、同じ交換レートを持つオファーが増加します。この修正の目的は、以前のオファーよりもランク付けを高くするには、価格面で意味のある改善をしなければならないようにすることです。主要な発行者がこれを採用すれば、既存のオファーよりわずかなパーセンテージだけ上回るオファーでレジャーを攻撃しようとするスパムが低減します。また、よりバラツキの少ない為替レートでオファーをグループ化できるため、レジャー内のオーダーブックを効率的に保管できます。

アカウントにTickSizeフィールドを追加します。このフィールドはAccountSetトランザクションタイプを使用して設定できます。通貨発行者がTickSizeフィールドを設定すれば、発行者の通貨を取引するオファーの為替レート（資金の入出金率）がXRP Ledgerによって丸められ、丸められた為替レートに合わせてオファーの金額が調整されます。トランザクションにて1つの通貨にのみTickSizeが設定されていれば、その有効桁数が適用されます。異なるTickSize値が設定された2つの通貨を取引する場合は、有効桁数が最も小さいTickSizeが適用されます。XRPにTickSizeは設定されません。

TrustSetAuth

承認されたトラストラインを使用する場合に、会計関係の事前承認（ゼロバランストラストライン）を許可します。

この修正が適用されれば、tfSetfAuthを有効にしたTrustSetトランザクションにおいて、RippleStateノードの他のすべての値をデフォルト状態にしたままでも、新しいRippleStateレジャーオブジェクトを作成できます。新しいRippleStateノードでは、トランザクションの送信者が低いノードと見なされるか高いノードと見なされるかに応じて、lsfLowAuthフラグまたはlsfHighAuthフラグが有効になります。トランザクションの送信者は、asfRequireAuthフラグを有効にしてAccountSetトランザクションを送信することで、事前にlsfRequireAuthを有効にしておく必要があります。

XChainBridge

メインネットとサイドチェーンなど異なるネットワーク間でアセットを同期させるための「クロスチェーンブリッジ」を追加します。標準規格草案： XLS-38d Cross-Chain Bridge。

XRPFees

トランザクションコストの計算を簡素化し、「手数料単位」で間接的に計算し、結果をXRPに変換するのではなく、直接XRPを使用するようにしました。プロトコルや台帳データにおける「手数料単位」のインスタンスを全て変更し、XRPの代わりにdropsを使用するように修正します。修正には以下を含みます。

• Fee Votingプロトコルを更新し、XRPのdropsを使用するように変更します。
• FeeSettingsの台帳の項目タイプを変更します。BaseFee、ReferenceFeeUnits、ReserveBase、ReserveIncrementフィールドをBaseFeeDrops、ReserveBaseDrops、ReserveIncrementDropsに置き換えます。
• SetFee トランザクションタイプを変更します。BaseFee、ReferenceFeeUnits、ReserveBase、ReserveIncrementフィールドをBaseFeeDrops、ReserveBaseDrops、ReserveIncrementDropsに置き換えます。

このAmendmentがなければ、トランザクションの形式と台帳の項目は同一です。