オファー

XRP Ledgerの分散型取引所では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと発行済み通貨の取引、または発行済み通貨間の取引（同一通貨コードだがイシュアーが異なる発行済み通貨を含む）を行うことができます。（同一コードでイシュアーが異なる通貨は、ripplingによって取引することもできます。）

オファーのライフサイクル

OfferCreateトランザクションの処理時に、このトランザクションは一致するオファーまたはクロスオファーを可能な限り自動的に消費します。（既存のオファーのレートが要求よりも良い場合には、オファーの作成者はTakerGetsの全額よりも低い額を支払い、TakerPaysを全額を受領できます。）それによりTakerPaysの額を完全に満たせない場合、オファーはレジャーのOfferオブジェクトになります。（OfferCreateフラグを使用してこの動作を変更できます。）

既存のオファーに対応する追加のOfferCreateトランザクション、またはオファーを使用してペイメントパスを接続するPaymentトランザクションのいずれかにより、レジャー上のオファーは履行されます。オファーの部分的な履行と、部分的な資金化が可能です。1つのトランザクションで、レジャーのオファーを最大850件まで消費できます。（この数を超えるとメタデータが大きくなり過ぎて、tecOVERSIZEとなります。）

オファーのTakerGetsパラメーターで指定された通貨をいくらかでも（ゼロ以外のプラスの額）保有している限り、オファーを作成できます。オファーは、TakerPaysの額が満たされるまで、TakerGetsの額を上限として保有している通貨を売却します。オファーによって誰かに負債が発生することはありません。

レジャーにすでに記録されているオファーにクロスするオファーを出した場合、関連する額に関係なく古いオファーは自動的に取り消されます。

次の場合には、オファーは一時的または永久に 資金化されない 可能性があります。

  • 作成者にTakerGetsの通貨がない場合。
    • 作成者がその通貨を取得すると、オファーに資金が再び供給されます。
  • オファーに資金を供給するために必要な通貨が凍結されたトラストラインで保有されている場合。
    • トラストラインの凍結が解除されると、オファーに資金が再び供給されます。
  • オファーに必要な新しいトラストラインの準備金として十分な額のXRPを作成者が保有していない場合。（オファーとトラストを参照してください。）
    • 作成者がXRPをさらに取得するか、または必要準備金が減額されると、オファーに資金が再び供給されます。
  • オファーに指定されている有効期限が最新の閉鎖済みレジャーの閉鎖時刻よりも前である場合。（オファーの有効期限を参照してください。）

資金化されないオファーはレジャーに無期限で残ることがありますが、特に影響はありません。次の方法でのみ、オファーはレジャーから完全に削除されます。

  • Paymentトランザクションまたは対応するOfferCreateトランザクションにより全額が請求される。
  • OfferCancelトランザクションまたはOfferCreateトランザクションによりオファーが明示的に取り消される。
  • 同じアカウントからのOfferCreateトランザクションが以前のオファーにクロスする。（この場合、古いオファーが自動的に取り消されます。）
  • トランザクションの処理中にオファーへの資金が供給されていないことが判明する。一般的に、オファーがオーダーブックの先中で最も有利なレートであったことが原因です。
    • これには、オファーのいずれかの側が、rippledの精度でサポートされているよりも0に近いことが検出されるケースも含まれます。

資金化されていないオファーの追跡

すべてのオファーの資金化状況の追跡は、コンピューターにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金化の状況に影響することがあります。このため、rippledではオファーの検出と削除を積極的に行なっていません。

クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初にbook_offersメソッドを使用してオーダーブックを取得し、次にオファーのtaker_gets_fundedフィールドを調べます。次にtransactionsストリームをサブスクライブし、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。

オファーとトラスト

トラストラインの限度額（TrustSetを参照）はオファーに影響しません。つまり、オファーを使用して、イシュアーの信用できる最大精算額を上回る額を取得できます。

ただし、XRP以外の残高を保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが受け入れられると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。アカウントが保有する必要のある準備金はトラストラインによって増加するため、新しいトラストラインを必要とするオファーがある場合、そのトラストラインの準備金として十分なXRPをアドレスに保有する必要があります。

トラストラインはあなたが信用するイシュア―を示し、限度額の範囲内でそのイシュア―のイシュアンスを支払いとして受領します。オファーは特定通貨を取得するための明示的な指示であるため、これらの限度額を超えることができます。

オファーの優先度

既存のオファーは為替レート（「オファークオリティ」とも呼ばれます）によってグループにまとめられます。為替レートは、TakerGetsとTakerPaysの比率として計算されます。為替レートが高いオファーが優先的に処理されます。（つまり、オファーを受け入れる人は、支払われる通貨額に対して可能な限り多くを受領します。）同じ為替レートのオファーは、最も古いレジャーバージョンで出されたオファーに基づいて受け入れられます。

同じ為替レートのオファーが同じレジャーバージョンに記録されている場合、オファーの処理順序はレジャーへトランザクションを適用する ための正規の順序 によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。

オファーの有効期限

トランザクションの伝搬と確定には時間がかかることがあるため、レジャーのタイムスタンプからオファーの有効性を判断します。オファーが有効期限切れとなるのは、有効期限が最新の検証済みレジャーよりも前の場合だけです。つまり、Expirationフィールドが指定されているオファーが「アクティブ」であると見なされるのは、ローカルクロックに関係なく、その有効期限が最新の検証済みレジャーのタイムスタンプよりも後である場合です。

閉鎖時刻が有効期限と同じかそれよりも後である完全な検証済みレジャーが作成されたら、Expirationが指定されているオファーの最終的な処理を即時に判断できます。

注記: レジャーを変更できるのは新しいトランザクションだけであることから、有効期限切れのオファーは、非アクティブになった後でもレジャーに残ることがあります。このオファーは資金化されていないと見なされ特に影響はありませんが、（ledger_entryコマンドなどの）実行結果に、引き続き表示される可能性があります。後に、サーバーが処理中に有効期限切れのオファーを検出すると、このオファーは別のトランザクション（別のOfferCreateなど）の結果として最終的に削除されることがあります。

OfferCreateトランザクションが最初にレジャーに追加された時点で、このトランザクションに指定されているExpiration時刻をすでに経過していた場合は、トランザクションはオファーを実行しません。このようなトランザクションの結果コードは、Checks Amendmentが有効であるかどうかによって異なります。Checks Amendmentが有効な場合、トランザクションの結果コードはtecEXPIREDです。それ以外の場合、トランザクションの結果コードはtesSUCCESSです。いずれの場合でも、このトランザクションには、トランザクションコストとして支払われたXRPを消却する以外に影響はありません。