Merge pull request #1741 from develoQ/japanese-dex

[JA] translate DEX, offer, offers page
2025-11-04 11:55:50 +00:00 · 2023-02-27 11:44:05 -08:00
parent b325de64be 1d1da4b245
commit bffc0da445
5 changed files with 162 additions and 63 deletions
--- a/content/concepts/decentralized-exchange/decentralized-exchange.ja.md
+++ b/content/concepts/decentralized-exchange/decentralized-exchange.ja.md
@@ -0,0 +1,70 @@
+---
+html: decentralized-exchange.html
+parent: concepts.html
+template: pagetype-category.html.jinja
+blurb: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザーはトークンをXRPに、あるいはXRPをトークンにに交換できます。
+---
+# 分散型取引所
+
+XRP Ledgerには、世界でおそらく最も古い _分散型取引所_ (「DEX」と略されることもあります)があり、2012年のXRP Ledgerのローンチ以来、現在まで稼働し続けています。この取引所では、ユーザーが[トークン](tokens.html)をXRPや他のトークンと売買することができ、ネットワーク自体に課される[手数料](fees.html)はごく僅かです。(いかなる当事者にも支払われることはありません)
+
+**注意:** 誰でも好きな通貨コードやティッカーシンボルで[トークンを発行](issue-a-fungible-token.html)して、分散型取引所で販売することができます。トークンを購入する前に必ずデューデリジェンスを行い、発行者に注意を払うようにしてください。さもなければ、価値あるものを手放し、それと引き換えに価値のないトークンを受け取ることになるかもしれません。
+
+## 構造
+
+XRP Ledgerの分散型取引所は、無制限の通貨ペアで構成されており、ユーザーが取引を行う際にオンデマンドで追跡されます。通貨ペアは、XRPとトークン、または2つの異なるトークンから構成されます。トークンは常に、発行者と通貨コードの組み合わせによって識別されます。同じ通貨コードで異なる発行者のトークン同士、または同じ発行者で異なる通貨コードのトークン同士の取引も可能です。
+
+XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](transaction-basics.html)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.html)と呼ばれています。オファーは事実上、ある通貨(XRPまたはトークン)を特定の金額で他の通貨と売買するための[_指値注文_](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC)です。ネットワークがオファーを実行する際、同じ通貨ペアでマッチングするオファーがあれば、最も良い取引レートから順に約定されます。
+
+オファーは、全額または一部が約定されることがあります。すぐに全額が約定されなかった場合は、残りの金額は台帳上のOfferオブジェクトとなります。その後、他のオファーや[クロスカレンシー支払い](cross-currency-payments.html)がオファーにマッチし、約定する可能性があります。このため、Offerは最初に注文したときは指定した取引レートよりも高いレートで約定し、後で注文したときは指定した取引レートと全く同じレートで約定することがあります。（端数処理のためのわずかな差は除きます）
+
+オファーは、発注後、手動または自動でキャンセルすることができます。この機能およびその他の機能については、[オファー](offers.html)を参照してください。
+
+2つのトークンを取引する際、トークンとトークンを直接取引するよりも、トークンとXRP、XRPとトークンを取引した方が安くなる場合、[オートブリッジ](autobridging.html)によって自動的に取引レートと流動性を向上させることができます。
+
+### 取引の例
+
+{{ include_svg("img/decentralized-exchange-example-trade.svg", "図: XRPでトークンを購入する注文が一部約定する。") }}
+
+上の図は、分散型取引所での取引例です。この例では、Tranというトレーダーが、WayGateという架空の企業が発行するFOOという通貨コードのトークン100個の購入オファーを出しています。(簡潔にするため、「FOO.WayGate」はこれらのトークンを指します。)Tranは、合計で最大1000XRPまで支払う意思があることを明記しています。Tranのトランザクションが処理されると、次のようなことが起こります。
+
+1. ネットワークは、購入する通貨額を支払う通貨額で割ることによって、TranのOfferの取引レートを計算します。
+0. このオーダーブックには、金額や取引レートが異なる他のトレーダーからのオファーがすでに複数存在します。このケースでは、FOO.WayGateの売りとXRPの買いのオーダーブックを意味します。
+0. Tranのオファーが全額約定するか、Tranのオファーは、Tranのオファーで指定されたレートと同等以上の取引レートのオファーがなくなるまで、最良の取引レートから順に、一致するオファーを約定していきます。この例では、22 FOO.WayGateのみが指定されたレート以上で取引可能です。約定したオファーはオーダーブックから削除されます。
+0. Tranは、この取引で調達できたFOO.WayGateの量を、それまで売り注文を出していた様々なトレーダーから受け取ります。これらのトークンはWayGateのFOOに対するTranの[トラストライン](trust-lines-and-issuing.html)に送られます。(Tranがまだトラストラインを持っていなかった場合、自動的に作成されます。)
+0. その見返りとして、それらのトレーダーは、提示された取引レートに従って、TranからXRPを受け取ります。
+0. ネットワークはTranのオファーの残りを計算します。元々のオファーが100 FOO.WayGateの購入で、これまでTranは22を受け取っているので、残りは78 FOO.WayGateとなります。元の取引レートを使用すると、Tranのオファーの残りは780 XRPで78 FOO.WayGateを購入することになります。
+0. この「残り」は、Tranの取引と同じ向きの取引、つまりXRPの売りとFOO.WayGateの買いのオーダーブックに載せられます。
+
+同じ台帳でTranの直後に実行されたものも含め、その後の取引は更新されたオーダーブックを使って行われるため、Tranのオファーが全額約定するかTranがキャンセルするまで、その一部または全額を約定することができます。
+
+**注記:** 元帳がクローズされ、検証される際の取引の実行順序は、取引が送信された順序と同じではありません。複数のトランザクションが同じ台帳の同じオーダーブックに影響を与える場合、それらのトランザクションの最終結果は、トランザクション送信時に計算された暫定的な結果とは大きく異なる可能性があります。取引結果が確定する場合、確定しない場合の詳細については、[結果のファイナリティー](finality-of-results.html)をご覧ください。
+
+
+## 制限事項
+
+分散型取引所は、以下のような制限を設けて設計されています。
+
+取引は新しい台帳がクローズするたびに（約3～5秒ごと）実行されるだけなので、XRP Ledgerは[高頻度取引](https://ja.wikipedia.org/wiki/%E9%AB%98%E9%A0%BB%E5%BA%A6%E5%8F%96%E5%BC%95)には適していません。台帳内で取引が実行される順番は、[フロントランニング](https://en.wikipedia.org/wiki/Front_running)を阻止するため、予測できないように設計されています。
+
+XRP Ledgerは、成行注文、指値注文、レバレッジ取引などの概念をネイティブに表現するものではありません。カスタムトークンやOfferのプロパティをクリエイティブに利用することで、いくつかは実現できるかもしれません。
+
+分散型システムであるXRP Ledgerは、取引に関わる[アカウント](accounts.html)の背後にいる実際の人々や組織に関する情報を一切持っていません。また、ユーザーや発行者は、様々な種類の裏付け資産を表すトークンの取引を規制するために、関連する法律に従う必要があります。[凍結](freezes.html)や[認可トラストライン](authorized-trust-lines.html)などの機能は、発行者が関連法規を順守できるよう意図しています。
+
+## 関連項目
+
+- **コンセプト:**
+    - [Offers](offers.html): XRP Ledgerでのトレードの仕組みについて
+    - [トークン](tokens.html): XRP Ledgerで様々な種類の価値を表現する方法の概要について
+- **リファレンス:**
+    - [account_offersメソッド][]: アカウントから注文されたオファーを検索
+    - [book_offersメソッド][]: 指定された通貨ペアの売買のオファーを検索
+    - [OfferCreateトランザクション][]: 新規オファーを発注や既存のオファーの置き換え
+    - [OfferCancelトランザクション][]: 既存のオファーをキャンセル
+    - [Offerオブジェクト][] 台帳のオファーのデータ構造
+    - [DirectoryNodeオブジェクト][]: 特定の通貨ペアと取引レートのすべてのオファーを追跡するデータ構造
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/concepts/decentralized-exchange/decentralized-exchange.md
+++ b/content/concepts/decentralized-exchange/decentralized-exchange.md
@@ -66,8 +66,6 @@ As a decentralized system, the XRP Ledger does not have any information on the a
    - [Offer object][] for the data structure of passive Offers in the ledger
    - [DirectoryNode object][] for the data structure that tracks all the Offers for a given currency pair and exchange rate.

-<!-- NOTE: There aren't really any tutorials for using the DEX. When there are, add them here. -->
-
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
--- a/content/concepts/decentralized-exchange/offers.ja.md
+++ b/content/concepts/decentralized-exchange/offers.ja.md
@@ -1,79 +1,110 @@
 ---
 html: offers.html
 parent: decentralized-exchange.html
-blurb: オファーはXRP Ledgerの通貨取引オーダーの形態です。オファーのライフサイクルと特性について説明します。
+blurb: オファーはXRP Ledgerの通貨取引に関する機能の一つです。オファーのライフサイクルと特性について説明します。
 labels:
  - 分散型取引所
 ---
 # オファー

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

 - オファーを作成するには、[OfferCreateトランザクション][]を送信します。
- 即時に履行されないオファーはレジャーデータの[Offerオブジェクト](offer.html)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは消費されます。
- [複数通貨間の支払い](cross-currency-payments.html)はオファーを消費して流動性を提供します。
+- 即時に約定されないオファーはレジャーデータの[Offerオブジェクト](offer.html)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは約定されます。
+- [クロスカレンシー支払い](cross-currency-payments.html)はオファーを約定して流動性を提供します。


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

-OfferCreateトランザクションの処理時に、このトランザクションは一致するオファーまたはクロスオファーを可能な限り自動的に消費します。（既存のオファーのレートが要求よりも良い場合には、オファーの作成者は`TakerGets`の全額よりも低い額を支払い、`TakerPays`を全額を受領できます。）それにより`TakerPays`の額を完全に満たせない場合、オファーはレジャーのOfferオブジェクトになります。（[OfferCreateフラグ](offercreate.html#offercreateフラグ)を使用してこの動作を変更できます。）
+[OfferCreate トランザクション][]は、2つのトークン、またはトークンとXRPの間で取引を行なうための命令です。それぞれのトランザクションは購入額（`TakerPays`）と売却額（`TakerGets`）を含みます。トランザクションが処理されると、自動的に一致または交差するオファーが可能な限り約定されます。その結果、新しいオファーを完全に約定しきれない場合、残りは台帳上のOfferオブジェクトとなります。

-既存のオファーに対応する追加のOfferCreateトランザクション、またはオファーを使用してペイメントパスを接続する[Paymentトランザクション][]のいずれかにより、レジャー上のオファーは履行されます。オファーの部分的な履行と、部分的な資金化が可能です。1つのトランザクションで、レジャーのオファーを最大850件まで消費できます。（この数を超えるとメタデータが大きくなり過ぎて、[`tecOVERSIZE`](tec-codes.html)となります。）
+Offerオブジェクトは、他のオファーやクロスカレンシー決済で完全に約定されるまで、台帳に保存されます。オファーを作成したアカウントは、そのオファーの所有者と呼ばれます。自分が作成したオファーは、専用の[OfferCancelトランザクション][]、または[OfferCreateトランザクション][]のオプションとして、いつでもキャンセルすることが可能です。

-オファーの`TakerGets`パラメーターで指定された通貨をいくらかでも（ゼロ以外のプラスの額）保有している限り、オファーを作成できます。オファーは、`TakerPays`の額が満たされるまで、`TakerGets`の額を上限として保有している通貨を売却します。オファーによって誰かに負債が発生することはありません。
+台帳にOfferオブジェクトがある間は、あなたのXRPの一部が[所有者準備金](reserves.html)として設定されます。何らかの理由でOfferオブジェクトが削除されると、そのXRPは再び使えるようになります。

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

-次の場合には、オファーは一時的または永久に _資金化されない_ 可能性があります。
+オファーを作成する際、その取引で売却する資産の一部でも保有していない場合、取引は「資金不足」として拒否されます。

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

-資金化されないオファーはレジャーに無期限で残ることがありますが、特に影響はありません。次の方法でのみ、オファーはレジャーから*完全に*削除されます。
+**トークンを売却する** には、以下のいずれかが必要です。

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

-### 資金化されていないオファーの追跡
+ただし、オファーで指定された全額を保有する必要はありません。オファーを作成することで資金が拘束されるわけではないので、同じトークン（またはXRP）を売却するために複数のオファーを作成したり、オファーを作成した後で十分なトークンまたはXRPを調達することも可能です。

-すべてのオファーの資金化状況の追跡は、コンピューターにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金化の状況に影響することがあります。このため、`rippled`ではオファーの検出と削除を積極的に行なっていません。
+**XRPを売却する** には、Offerオブジェクトを台帳に保存するための準備金と、購入するトークンを保存するためのトラストラインの準備金を含む、必要な[準備金](reserves.html)を確保する必要があります。準備金を確保した後にXRPが残っていれば、Offerオブジェクトを作成することができます。
+
+他のオファーと自身のオファーがマッチした場合、両方のオファーが、その時点における所有者の資金の範囲内で実行されます。マッチングしたオファーがあり、自分のオファーが完全に約定される前に資金が尽きてしまった場合、残りのオファーはキャンセルされます。トークンの発行者でない限り、オファーによってトークンの残高がマイナスになることはありません。(発行者であれば、オファーを使って、オファーで指定された合計金額まで新しいトークンを発行できます。発行したトークンは、発行者の立場からはマイナス残高として表示されます)。
+
+台帳に存在する自身のオファーと重なるオファーを作成した場合、金額にかかわらず、重なった古いオファーは自動的にキャンセルされます。
+
+次のような場合には、オファーが一時的または長期に渡って「資金不足」になる可能性があります。
+
+- 所有者が売却する資産を一切保有しなくなった場合。
+    - オーナーがその資産を再度取得すると、オファーに資金が供給されるようになります。
+- 売却する資産が[凍結されたトラストライン](freezes.html)に含まれるトークンである場合。
+    - トラストラインが凍結解除されると、オファーは再び資金が供給されるようになります。
+- オファーが新しいトラストラインを作成する必要があるが、オーナーがその[準備金](reserves.html)の増加に伴う十分なXRPを持っていない場合。
+    - オーナーが追加のXRPを調達するか、準備金の必要量が減少すると、オファーは自動的に使用可能になります。
+- オファーが失効した場合。([オファーの有効期限](#offer-expiration)を参照)
+
+資金不足のOfferオブジェクトは、トランザクションによって削除されるまで、台帳に残ります。台帳からOfferオブジェクトを削除するには、以下の方法があります。
+
+
+- 一致するオファーまたは[クロスカレンシー支払い](cross-currency-payments.html)によってオファーが全額約定される。
+- 所有者が明示的にオファーをキャンセルする。
+- 所有者が交差する新しいオファーを作成することにより、暗黙のうちにオファーをキャンセルする。
+- トランザクション処理中にオファーが資金不足または期限切れであることが判明する。
+    - これには、オファーが支払うことができる残額がゼロになる場合も含まれます。
+
+### 資金不足のオファーの追跡
+
+すべてのオファーの資金状況の追跡は、コンピューターにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金状況に影響することがあります。このため、XRP Ledgerでは資金不足や期限切れのオファーの検出と削除を _積極的には_ 行なっていません。

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


 ## オファーとトラスト

-トラストラインの限度額（[TrustSet](trustset.html)を参照）はオファーに影響しません。つまり、オファーを使用して、イシュアーの信用できる最大精算額を上回る額を取得できます。
+トラストラインの限度額（[TrustSet](trustset.html)を参照）はオファーに影響しません。つまり、オファーを使用して、発行者に対して設定したトラストラインの限度額を上回る額を取得できます。

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

-トラストラインはあなたが信用するイシュア―を示し、限度額の範囲内でそのイシュア―のイシュアンスを支払いとして受領します。オファーは特定通貨を取得するための明示的な指示であるため、これらの限度額を超えることができます。
+トラストラインの制限は、あなたの希望以上のトークンを受け取ることを防ぐためのものです。オファーとは、トークンをどれだけ欲しいかを明示的に示すものであるため、この制限を超えることができます。


 ## オファーの優先度

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

-同じ為替レートのオファーが同じレジャーバージョンに記録されている場合、オファーの処理順序は[レジャーへトランザクションを適用する](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source: Applying transactions")ための[正規の順序](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering")によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。
+同じ取引レートのOfferオブジェクトが同じ台帳ブロックに記録されている場合、オファーの処理順序は[レジャーへトランザクションを適用する](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source Code: Applying transactions")ための[正規順序](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source Code: Transaction ordering")によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。


 ## オファーの有効期限

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

-閉鎖時刻が有効期限と同じかそれよりも後である完全な検証済みレジャーが作成されたら、`Expiration`が指定されているオファーの最終的な処理を即時に判断できます。
+有効期限は秒単位で指定できますが、オファーが期限切れとなる時刻は、実際には正確ではありません。オファーが期限切れとなるのは、期限切れ時刻が直前の台帳のクローズ時刻より前か等しい場合です。それ以外の場合は、現実の時刻がオファー期限よりも後でも、オファーが約定する可能性があります。言い換えると、有効期限が最新の有効な台帳のクローズ時刻よりも遅ければ、実際の時計がどうであろうと、オファーはまだ「有効」なのです。

-**注記:** レジャーを変更できるのは新しいトランザクションだけであることから、有効期限切れのオファーは、非アクティブになった後でもレジャーに残ることがあります。このオファーは資金化されていないと見なされ特に影響はありませんが、（[ledger_entry](ledger_entry.html)コマンドなどの）実行結果に、引き続き表示される可能性があります。後に、サーバーが処理中に有効期限切れのオファーを検出すると、このオファーは別のトランザクション（別のOfferCreateなど）の結果として最終的に削除されることがあります。
+これは、ネットワークのコンセンサス形成の仕組みによるものです。ピアツーピアネットワーク全体が合意に達するには、トランザクションを実行する際に、すべてのサーバーがどのオファーが期限切れであるかに合意する必要があります。個々のサーバーはシステム時刻の設定にわずかな違いがあるため、各サーバーが「現在」時刻を使用した場合、どのオファーが期限切れであるかについて同じ結論に達しない可能性があります。台帳のクローズ時刻は、その台帳のトランザクションが実行されるまで分からないため、サーバーは「前の台帳」の正式なクローズ時刻を代わりに使用します。[台帳のクローズ時刻は丸められます](ledgers.html#ledger-close-times)。このため、オファーが期限切れかどうかを判断するための時刻と実世界の時刻の差が生じる場合があるのです。
+
+**注記:** 期限切れのOfferオブジェクトは、トランザクションによって削除されるまで、台帳内に残ります。それまでは、APIから取得したデータ（[ledger_entryメソッド][]などを使用）に表示され続ける可能性があります。トランザクションは、有効期限が切れたOfferオブジェクトや資金不足のOfferオブジェクトを見つけると自動的に削除します。通常、オファーやクロスカレンシー決済を実行すると、そのOfferオブジェクトはマッチングまたはキャンセルされます。Offerオブジェクトに対応する所有者準備金は、Offerオブジェクトが実際に削除されたときにのみ再び利用可能になります。
+
+## 関連項目
+
+- **コンセプト:**
+    - [トークン](tokens.html)
+    - [パス](paths.html)
+- **リファレンス:**
+    - [account_offersメソッド][]
+    - [book_offersメソッド][]
+    - [OfferCreateトランザクション][]
+    - [OfferCancelトランザクション][]
+    - [Offerオブジェクト](offer.html)

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


 <!--{# common link defs #}-->
--- a/content/references/protocol-reference/ledger-data/ledger-object-types/offer.ja.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/offer.ja.md
@@ -1,16 +1,16 @@
 ---
 html: offer.html
 parent: ledger-object-types.html
-blurb: 通貨取引を行うためのオーダーです。
+blurb: 通貨取引を行う注文
 labels:
  - 分散型取引所
 ---
 # Offer
 [[ソース]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L57 "Source")

-`Offer`オブジェクトタイプは、XRP Ledgerの分散型取引所での（従来は _オーダー_ と呼ばれていた）通貨取引オファーを記述します。[OfferCreateトランザクション][]は、レジャーにすでに含まれている他のオファーを消費することでは完全にオファーを実行できない場合に、レジャーに`Offer`オブジェクトを作成します。
+台帳の`Offer`項目は、XRP Ledgerの[分散型取引所](decentralized-exchange.html)で通貨を交換する[オファー](offers.html)を表しています。（金融ではより伝統的に _オーダー_ として知られています）。[OfferCreateトランザクション][]は台帳にある他のOfferを全額約定できない場合、台帳に`Offer`項目を作成します。

-オファーがレジャーに存在している間に、ネットワークの他のアクティビティによってオファーが資金化されないことがあります。ただし`rippled`ではトランザクション処理において資金化されないオファーはすべて自動的に取り除かれます（レジャー状態を変更できるのはトランザクションだけであることから、これはトランザクション処理で _のみ_ 行われます）。
+オファーがネットワーク上の他の活動によって資金不足になることはありますが、元帳には残ります。トランザクションを処理する際、ネットワークはトランザクションが見つけた資金不足のオファーを自動的に削除します。( _トランザクションのみ_ が台帳の状態を変更できるため、削除が行われないと資金不足のオファーが残ってしまいます。)

 詳細は、[オファー](offers.html)を参照してください。

@@ -41,31 +41,31 @@ labels:

 `Offer`オブジェクトのフィールドを次に示します。

-| 名前              | JSONの型 | [内部の型][] | 説明 |
-|-------------------|-----------|---------------|-------------|
-| `LedgerEntryType`   | 文字列    | UInt16    | 値が`0x006F`（文字列`Offer`にマッピング）の場合は、このオブジェクトが通貨取引オーダーを記述することを示します。 |
-| `Flags`             | 数値    | UInt32    | このオファーに対して有効になっているブール値フラグのビットマップ。 |
-| `Account`           | 文字列    | AccountID | このオファーを所有するアカウントのアドレス。 |
-| `Sequence`          | 数値    | UInt32    | `Offer`オブジェクトを作成した[OfferCreate][]トランザクションの`Sequence` 値。`Account`とこのフィールドの組み合わせによってこのオファーが識別されます。 |
-| `TakerPays`         | 文字列またはオブジェクト | Amount | オファー作成者が要求する残額と通貨の種類。 |
-| `TakerGets`         | 文字列またはオブジェクト | Amount | オファー作成者が提供する残額と通貨の種類。 |
-| `BookDirectory`     | 文字列    | Hash256   | このオファーにリンクしている[オファーディレクトリー](directorynode.html)のID。 |
-| `BookNode`          | 文字列    | UInt64    | オファーディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |
-| `OwnerNode`         | 文字列    | UInt64    | 所有者ディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。**注記:** このオファーには、オファーを含む所有者ディレクトリーへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
-| `PreviousTxnID`     | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
-| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
-| `Expiration`        | 数値    | UInt32    | （省略可）このオファーが資金化されなかったとみなされる時刻を示します。詳細は、[時間の指定][]を参照してください。 |
+| 名前              | JSONの型 | [内部の型][] | 必須? | 説明 |
+|-------------------|-----------|-----------|------|-------|
+| `Account`           | 文字列    | AccountID | はい  | このオファーを所有するアカウントのアドレス。 |
+| `BookDirectory`     | 文字列    | Hash256   | はい  | このオファーにリンクしている[オファーディレクトリー](directorynode.html)のID。 |
+| `BookNode`          | 文字列    | UInt64    | はい  | Offerディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒント。 |
+| `Expiration`        | 数値    | UInt32    | いいえ | （省略可）このオファーが資金不足とみなされる時刻。詳細は、[時間の指定][]を参照してください。 |
+| `Flags`             | 数値    | UInt32    | はい  | このオファーに対して有効になっているブール値フラグのビットマップ。 |
+| `LedgerEntryType`   | 文字列    | UInt16    | はい  | 値が`0x006F`（文字列`Offer`にマッピング）の場合は、このオブジェクトが通貨取引オーダーを記述することを示す。 |
+| `OwnerNode`         | 文字列    | UInt64    | はい  | 所有者ディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒント。**注記:** このオファーには、オファーを含む所有者ディレクトリーへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
+| `PreviousTxnID`     | 文字列 | Hash256 | はい  | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
+| `Sequence`          | 数値    | UInt32    | はい  | `Offer`オブジェクトを作成した[OfferCreate][]トランザクションの`Sequence`値。`Account`とこのフィールドの組み合わせによってこのオファーが識別されます。 |
+| `PreviousTxnLgrSeq` | 数値 | UInt32 | はい  | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
+| `TakerPays`         | 文字列またはオブジェクト | Amount | はい  | オファー作成者が要求する残額と通貨の種類。 |
+| `TakerGets`         | 文字列またはオブジェクト | Amount | はい  | オファー作成者が提供する残額と通貨の種類。 |

 ## Offerのフラグ

-[OfferCreateトランザクション][]でOfferオブジェクトを作成するときに有効化または無効化できる各種オプションがあります。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 _lsf_ で始まる名前が付いています。
+[OfferCreateトランザクション][]でOfferオブジェクトを作成するときに有効化または無効化できる各種オプションがあります。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 **`lsf`** で始まる名前が付いています。

-`Offer` オブジェクトには以下のフラグ値を指定できます。
+`Offer`オブジェクトには以下のフラグ値を指定できます。

-| フラグ名 | 16進値 | 10進値 | 説明 | 対応する[OfferCreateフラグ](offercreate.html#offercreateフラグ) |
+| フラグ名 | 16進数値 | 10進数値 | 対応する[OfferCreateフラグ](offercreate.html#offercreateフラグ) | 説明 |
 |-----------|-----------|---------------|-------------|------------------------|
-| lsfPassive | 0x00010000 | 65536 | オブジェクトはパッシブオファーとして配置されました。レジャー内のオブジェクトには影響しません。 | tfPassive |
-| lsfSell   | 0x00020000 | 131072 | オブジェクトはセルオファーとして配置されました。レジャー内のオブジェクトへの影響はありません。これは、要求したレートよりも良いレートを得た場合にのみtfSellが関連するためです。この状況はオブジェクトがレジャーに記録された後では発生することはありません。 | tfSell |
+| lsfPassive | `0x00010000` | 65536 | tfPassive | オブジェクトはパッシブオファーとして発注されています。レジャー内のオブジェクトには影響しません。 |
+| lsfSell   | `0x00020000` | 131072 | tfSell | オブジェクトは売却オファーとして発注されています。これは台帳にあるオブジェクトには何の影響もありません (`tfSell`は指定したレートよりも良いレートが存在する場合にのみ意味を持ち、台帳にこのフラグを持ったオブジェクトが入ることはありません。)。 |

 ## オファーIDのフォーマット

@@ -73,7 +73,9 @@ labels:

 * Offerスペースキー（`0x006F`）
 * オファーを行うアカウントのAccountID
-* オファーを作成した[OfferCreateトランザクション][]のシーケンス番号。
+* オファーを作成した[OfferCreateトランザクション][]のシーケンス番号
+
+    OfferCreateトランザクションが[Ticket](tickets.html)を使用した場合、代わりに`TicketSequence`値を使用します。

 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
--- a/dactyl-config.yml
+++ b/dactyl-config.yml
@@ -887,12 +887,10 @@ pages:
            - ja

    -   md: concepts/decentralized-exchange/decentralized-exchange.md
+        targets:
+            - en

-    -   name: 分散型取引所
-        html: decentralized-exchange.html
-        parent: concepts.html
-        template: pagetype-category.html.jinja
-        blurb: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザーは発行済み通貨をXRPに、あるいはXRPを発行済み通貨に交換できます。
+    -   md: concepts/decentralized-exchange/decentralized-exchange.ja.md
        targets:
            - ja