chore: rename deprecated i18n to l10n

2025-12-06 09:18:00 +00:00 · 2024-09-23 15:13:11 +03:00
parent 6cbb3a036f
commit 9a0c010600
502 changed files with 984 additions and 122 deletions
--- a/@l10n/ja/CODE-OF-CONDUCT.md
+++ b/@l10n/ja/CODE-OF-CONDUCT.md
@@ -0,0 +1,46 @@
+# コントリビューター行動規範
+
+## 誓約
+
+私たちコントリビューターとメンテナーは、オープンで友好的な環境を育むために、年齢、体格、身体障害、民族、性的特徴、性自認および性表現、経験の度合い、学歴、社会経済的地位、国籍、容姿、人種、宗教、性的同一性および性的指向などを問わず、誰もが私たちのプロジェクトとコミュニティーに不快な思いをすることなく参加できるよう努めることを誓います。
+
+## 標準
+
+前向きな環境を作り上げることに貢献する行動の例:
+
+* 友好的で差別のない言葉の使用
+* 異なる観点や経験の尊重
+* 建設的な批判の素直な受け入れ
+* コミュニティーにとっての最善への注力
+* 他のコミュニティーメンバーへの共感の表示
+
+前向きな環境を作り上げることに貢献しない行動の例:
+
+* 性的な意味を含む言葉や画像の使用、望まない性的注目や誘いかけ
+* あおり、侮辱的または軽蔑的なコメント、個人攻撃や政治攻撃
+* 公的または私的な嫌がらせ
+* 住所やメールアドレスなどの個人情報の、明確な許可なしでの公開
+* 職場において不適切であると合理的に考えられる、その他の行為
+
+## 責任
+
+プロジェクトのメンテナーは、許容できる行動の基準を明確にする責任があります。また、許容できない行動がなされた場合に、適切かつ公平な是正処置を講じることが期待されます。
+
+プロジェクトのメンテナーは、この行動規範に沿わないコメント、コミット、コード、wiki編集、issueなどの投稿を削除、編集、拒否する権利と義務を有します。また、他の不適切、脅迫的、攻撃的、嫌がらせと考えられる行動を取ったコントリビューターを一時的もしくは恒久的に追放する権利と義務を有します。
+
+## 適用範囲
+
+この行動規範はすべてのプロジェクトスペース内で適用されます。また、個人がパブリックスペースでプロジェクトやコミュニティーを代表する際にも適用されます。プロジェクトやコミュニティーを代表する際の例としては、プロジェクトの公式メールアドレスを使用すること、公式ソーシャルメディアアカウントで投稿すること、もしくはオンラインまたはオフラインのイベントで、任命された代表者を務めることが挙げられます。プロジェクトを代表する行為については、プロジェクトのメンテナーがさらに細かく定義して明確にすることができます。
+
+## 執行
+
+暴言、嫌がらせ、またはその他の許容できない行動は、プロジェクトチーム（<ripplex@ripple.com>）に連絡して報告することができます。すべての申し立ては確認、調査されたうえで、その状況に対して必要かつ適切と判断された対応が取られます。プロジェクトチームは、事象の報告者に関する秘密を保持する義務があります。特定の執行方針の詳細は、別途掲載される場合があります。
+
+この行動規範を誠実に遵守または執行することができないプロジェクトのメンテナーは、プロジェクトを率いる他のメンバーの判断により、一時的または恒久的な措置が執られることがあります。
+
+## 帰属
+
+この行動規範は、[コントリビューター行動規範][ホームページ]バージョン1.4（https://www.contributor-covenant.org/version/1/4/code-of-conduct.html）から抜粋したものです。
+
+[ホームページ]: https://www.contributor-covenant.org
+この行動規範に関するよくある質問と回答については、https://www.contributor-covenant.org/faq をご覧ください。
--- a/@l10n/ja/CONTRIBUTING.md
+++ b/@l10n/ja/CONTRIBUTING.md
@@ -0,0 +1,3 @@
+# コントリビューション
+
+コントリビューションの情報には[「ドキュメントへの貢献」](https://xrpl.org/ja/resources/contribute-documentation/)をご覧ください。
--- a/@l10n/ja/about/faq.md
+++ b/@l10n/ja/about/faq.md
@@ -0,0 +1,155 @@
+---
+seo:
+    description: XRP Ledger、XRPLエコシステム、コミュニティに関するよくある質問にお答えします。
+subtitle: XRPLについての質問にお答えします
+top_nav_grouping: 概要
+labels:
+  - ブロックチェーン
+---
+# よくある質問
+
+<!--#{ using h4s for questions to keep them out of the right side nav (too cluttered when they display) and to provide appropriate text size for questions. #}-->
+#### XRPはリップルと呼ぶのですか？
+
+いいえ。XRPは**エックスアールピー**と呼びます。日本国内の多くの取引所などはXRPをRippleやリップルなどと表記していることがありますが、それは間違いです。
+またXRP Ledgerは**エックスアールピーレジャー**と呼びます。
+
+#### XRP Ledger(XRPL)はRippleが所有するプライベートブロックチェーンですか？
+
+いいえ。XRPLは分散型のパブリックブロックチェーンです。トランザクション処理やコンセンサスに影響を与えるような変更は、ネットワークバリデータの80％以上の承認が必要です。Rippleはネットワークへの貢献者の一員ですが、その権利は他の貢献者たちと同じです。ネットワークには150以上のバリデータが参加しており、うちデフォルトのユニークノードリスト(UNL)に登録されているものは35以上です。Rippleはこれらのうち[1つのノード](https://foundation.xrpl.org/2023/03/23/unl-update-march-2023/)を運営しています。
+ユニークノードリスト(UNL)に関しては[ユニークノードリスト（UNL）とは何ですか?](#ユニークノードリストunlとは何ですか)の項目をご覧ください。
+
+
+#### プルーフ・オブ・ワーク(PoW)が最善の検証メカニズムではないのですか？
+
+プルーフ・オブ・ワークは、信頼できる第三者を必要とせずに二重支出の問題を解決する最初のコンセンサンス・メカニズムでした。[XRP Ledgerのコンセンサスメカニズム](../docs/concepts/consensus-protocol/index.md)は、同じ問題をはるかに速く、安く、より良いエネルギー効率で解決します。
+
+
+#### XRPLではXRP以外の通貨も取引できますか？
+
+はい。XRPLは米ドル、ユーロ、石油、金、リワードポイントなど、任意の資産をトークン化できるように構築されており、どんな通貨でもXRPL上で発行することができます。成長中のXRPLコミュニティは様々なフィアットトークンや暗号通貨をサポートしており、これを裏付けています。
+
+
+#### XRPLは決済専用ではないのですか？
+
+いいえ。当初は決済のユースケース向けに開発されましたが、台帳であるXRP Ledgerとそのネイティブ・デジタルアセットであるXRPの両方は、NFTなどのブロックチェーンの革新的ユースケースで更に人気を集めています。自動マーケットメーカー(AMM)、スマートコントラクト機能Hooks、相互運用サイドチェーンの開発などが現在進行中です。
+
+
+## バリデータ（検証者）とユニークノードリスト
+
+#### トランザクション（取引）のバリデータはどのようなサービスを提供するのですか?
+
+バリデータは、トランザクションがプロトコル要件を満たしていて、結果として「有効」であるかどうかを判断します。バリデータが独自に提供する機能は、順序付けされた単位にトランザクションをグループ化し、二重支払いを防ぐことを目的としてその順序に同意することです。
+
+コンセンサスプロセスの詳細は、[コンセンサス](../docs/concepts/consensus-protocol/index.md)をご覧ください。
+
+
+#### バリデータの実行にはいくらかかりますか?
+
+バリデータを実行するのに手数料やXRPは必要ありません。メールサーバを稼働するための電気代相当です。
+
+
+#### ユニークノードリスト（UNL）とは何ですか?
+
+UNLとは、ある参加者が共謀しないと信じるバリデータのリストです。各サーバ運営者は自分のUNLを選ぶことができますが、通常は信頼できる発行元から提供されたデフォルトを参考にします。(信頼できる発行元からのデフォルトセットはデフォルトUNLまたは _dUNL_ と呼ばれることがあります)。
+
+
+#### どのUNLを選択すればよいですか?
+
+バリデータは誰でも実行できるため、信頼できるバリデータを選ぶ責任はネットワーク参加者にあります。現在、RippleとXRP Ledger財団が、過去の実績、証明された身元、責任あるITポリシーに基づき、高品質なバリデータの推奨デフォルトリストを公表していることが知られています。しかし、すべてのネットワーク参加者は、自身が信頼できるバリデータを選択することができ、上記の2つの発行者のいずれかに従う必要はありません。
+
+
+#### RippleがそのUNLの採用を推奨しているなら、それは中央集権的なシステムを形成することにならないのですか?
+
+いいえ。XRP Ledgerネットワークはオプトイン方式です。各参加者は直接的または間接的に自身のUNLを選択することができます。万が一、Rippleが活動を停止したり、Rippleが悪意を持って行動したりした場合、参加者は自身のUNLを変更してXRP Ledgerを引き続き使用することができます。
+
+
+#### バリデータにとってインセンティブとなるものは何ですか?
+
+バリデータを運営する主なインセンティブは、ネットワークの安定的な運用と健全な進化を維持・保護することです。XRP Ledgerの進化を決定するのはバリデータであり、XRP Ledgerを利用する、あるいはXRP Ledgerに依存するビジネスには、ネットワークの信頼性と安定性を確保するインセンティブが内在しています。バリデータはまた、このように貢献することでコミュニティからの評価と信頼を得ることができます。
+
+ネットワークに参加するためにXRP Ledgerのサーバを運営する場合やバリデータを運営するための追加コストや手間は最小限です。つまり、ビットコインにおけるマイニング報酬のような追加のインセンティブは必要ありません。Rippleはバリデータを運用するための報酬としてXRP支払うことはしないため、そのようなインセンティブがバリデータの行動を歪めることはありません。
+
+インセンティブがどのようにバリデータの行動を歪めるかの例については、[miner extractable value (MEV)](https://arxiv.org/abs/1904.05234)をご覧ください。
+
+
+#### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?
+
+いいえ。トランザクション選択のためにカスタマイズされたバリデータポリシーを金融機関が設定することはできません。バリデータは既存のプロトコルに従う、従わないのいずれかを選択します。ソフトウェアは、プロトコルルールに従わない場合は機能しません。そのため、金融機関が社内の専門知識なしにカスタム実装を求めることは推奨されません。
+
+
+#### ネットワーク内の20%を超えるノードが他の多数ノードと一致しない場合はどうなりますか? レジャー（台帳）の最終バージョンはどのように選択されますか?
+
+通常、あるトランザクションの有効性について係争があった場合、多数派が合意に達するまでそのトランザクションは保留されます。しかしネットワークの20％超が多数派と同じプロトコルルールに従わなかった場合、ネットワークは一時的に停止します。参加者が互いに合意を得たいUNLに基づいてUNLを再設定すれば再開できます。この一時的な処理の遅延は二重支出よりも望ましいでしょう。
+
+レジャーの正式バージョンを決定する過程で、一時的な内部バージョンが複数存在する可能性があります。分散システムでは、すべてのノードが同じ順序でトランザクションを受け取るわけではないため、このような内部バージョンは自然に発生します。ビットコインにおける類似の動作は、2つのブロックがほぼ同時に採掘されたために、2つのサーバがそれぞれ異なる最長チェーンを見ることです。
+
+しかし、レジャーの最新バージョンは常に1つだけであり、他のバージョンは無関係で無害です。
+
+XRP Ledgerのコンセンサスメカニズムが不利な状況でどのように動作するかについては、[攻撃と失敗モードに対するコンセンサスの保護](../docs/concepts/consensus-protocol/consensus-protections.md)をご覧ください。
+
+
+#### XRP Ledgerでは正式なバリデータのオンボーディングプロセスを使用していますか?
+
+いいえ。XRP Ledgerは、中央権限のないシステムであるため、正式なバリデータのオンボーディングプロセスのようなものは存在しません。
+
+個々のデフォルトUNLの発行者は、推奨リストにいつバリデータを追加したり削除したりするかについて、独自のポリシーを設けています。
+
+推奨事項やベストプラクティスについては、[バリデータとしての`rippled`の実行](../docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。
+
+
+#### デフォルトUNL(dUNL)がネットワークに最も影響力を持つなら、XRPLは中央集権的ではないでしょうか？
+
+バリデータはdUNLや広く使われているUNLを使わないこともできます。誰でもいつでも自由にUNLを作ることができます。
+
+同じネットワーク上で複数のUNLが使われても構いません。各運営者は自分のサーバのUNLをカスタマイズすることもできるし、別の推奨リストに従うこともできます。これらすべてのサーバは同じチェーンを実行し、互いにコンセンサスを得ることができます。
+
+しかし、もしあなたのUNLが他の人が使っているUNLと十分に重複していなければ、あなたのサーバが他のネットワークからフォークしてしまう危険性があります。あなたのUNLが他の人が使っているUNLと90％以上重なっていれば、フォークから完全に保護されます。重複が少ない場合、同じチェーンをフォローできるかもしれませんが、重複が少ないほど、ネットワークの接続性が悪いほど、UNLに信頼できないバリデータや悪意のあるバリデータがあるほど、フォークする可能性が高くなります。
+
+
+## XRPの役割
+
+
+#### XRPはどのような目的で利用されますか？
+
+XRPはXRP Ledgerのネイティブ資産として、これまでのどのデジタルアセットよりも速く、環境に優しく、安価な次世代の決済を実現するために作られました。XRPはまた、スパムから台帳を保護し、XRP Ledgerの分散型取引所で[通貨のブリッジ](../docs/concepts/tokens/decentralized-exchange/autobridging.md)を行うことがユーザにとって有益である場合に、その役割を果たします。時間とともに、XRP Ledgerコミュニティは、XRPの新しい[ユースケース](/about/uses)やXRP Ledgerそのものを発展させてきました。
+
+
+#### XRP Ledgerにおいて大量のトランザクションに対してはどのように対応しますか?
+
+XRP Ledgerは、スパム対策として、需要に基づいて[トランザクションコスト](../docs/concepts/transactions/transaction-cost.md)を動的に設定するように設計されています。潜在的なXRPの操作による影響は、時価総額とトランザクション量の増加に伴うネットワークサイズの拡大によって最小限に抑えられます。
+
+
+#### マネーロンダリングや疑わしい経済活動に対して、どのような標準操作手順が実施されていますか?
+
+XRP Ledgerネットワークはオープンネットワークであり、すべての取引はオープンに公開されています。
+
+Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、該当する疑わしい活動をFinCENに報告することにコミットしています。
+
+[XRP Forensics / xrplorer](https://xrplorer.com/)は、XRP Ledgerのマネーロンダリング、詐欺、詐欺、不正使用を追跡し、最小限に抑えるための勧告リストを維持しています。取引所やその他のサービス・プロバイダは、金融犯罪を防止し対応するためにこのサービスを利用することができます。
+
+
+## セキュリティ上の懸念
+
+
+#### サードパーティにより提供されたコードは審査プロセスはどのようになっていますか？
+
+コードへの貢献のプロセスは、開発者が[`rippled`リポジトリ](https://github.com/xrplf/rippled/)のようなソースコードリポジトリに[プルリクエスト](https://docs.github.com/ja/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)を行うことから始まります。
+
+このプルリクエストは、自動化された単体テストと統合テスト、そしてプルリクエストが影響するコード領域で重要な専門知識を持つ複数の開発者によりコードレビューが行われます。
+
+プルリクエストが自動テストに合格し、レビュアーの承認を受けると、信頼できる[リポジトリのメンテナ](https://opensource.guide/best-practices/)が次のベータ版に含めるための手続きを行います。
+
+
+#### RippleはXRP LedgerまたはXRP Ledgerネットワークを所有または管理していますか?
+
+いいえ、RippleはXRP LedgerまたはXRP Ledgerネットワークを所有も管理もしていません。
+
+Rippleは、コアとなるXRP Ledgerサーバ（[`rippled`](https://github.com/xrplf/rippled)）のリファレンス実装へ貢献し、オープンソースコードベースに貢献しているエンジニアチームを雇用しています。Rippleはまた、利用可能なソフトウェアのプリコンパイル済みバイナリーパッケージを定期的に公開しています。必要に応じて、誰でも自由に[ソースからソフトウェアをダウンロードしてコンパイル](../docs/infrastructure/installation/index.md)できます。
+
+いくつかの団体が推奨バリデータリスト（UNL）を公開しています。2023年7月現在、RippleはデフォルトのUNLにある35のバリデータのうち1つのみを実行しています。
+
+
+#### XRP Ledgerは検証用のコードベースとユーザソフトウェア用のコードベースを区別していますか?
+
+XRP Ledgerの[クライアントライブラリ](../docs/references/client-libraries.md)は、ソフトウェア開発者向けのものです。これらのライブラリは、ネットワークを支え、トランザクションを検証する[XRP Ledgerのコアサーバ](../docs/concepts/networks-and-servers/index.md)とは異なるコードベースとリポジトリを持っています。
--- a/@l10n/ja/community/report-a-scam.md
+++ b/@l10n/ja/community/report-a-scam.md
@@ -0,0 +1,31 @@
+---
+html: report-a-scam.html
+parent: contribute.html
+---
+# 詐欺の報告
+
+発展する業界において、信頼とセキュリティは非常に重要ですが、詐欺はクリプトとブロックチェーンの進歩を妨げ続けています。Xrplorer forensicsチームのようなXRP Ledgerコミュニティ全体の個人やチームは、詐欺を報告するための無料ツールを提供することで、これらの詐欺行為を抑制する手助けをしています。
+
+## 報告する
+詐欺に遭ったと思ったら、詐欺の手口や詐欺業者について、できるだけ早く、できるだけ多くの情報を集めるようにしてください。どのように行動すべきかは以下の方法を確認してください。
+
+{% admonition type="warning" name="注意" %}誰もXRP Ledgerのアカウントを凍結したり、トランザクションを元に戻したりすることはできません。これはXRP Ledgerブロックチェーンの分散型設計によるものです。{% /admonition %}
+
+1. [Xrplorerの調査チーム](https://xrplorer.com/forensics/submit)に詐欺業者のウォレットアドレスを提出してください。
+
+     これにより、不正行為に使用されたアカウントにフラグを立て、他のユーザ、ウォレット、および取引所に対する追加の監視、自動追跡、および警告に含めることができます。
+
+2. 最寄りの警察署に通報してください。詐欺業者が捕まれば、お金を取り戻せる場合があります。
+
+3. 詐欺業者が取引所にXRPを送金した場合は、必ず取引所のサポートチームに連絡してください。取引所は詐欺業者の口座を凍結することができます。以下は、いくつかの有名な取引所のサポートリンクです。
+
+    - [Binance](https://www.binance.com/en/support)
+    - [Coinbase](https://help.coinbase.com/)
+    - [Uphold](https://support.uphold.com/hc/en-us/requests/new)
+    - [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
+
+4. 詐欺業者がXRP Ledger上でXRPを他のトークンと交換した場合、そのトークンの発行者に連絡してください。発行者は[詐欺業者のトラストラインを凍結する](../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md)ことができるかもしれません。
+
+詐欺業者の報告に関する詳細は、[Xrplorer Forensicsのヘルプ](https://xrplorer.com/forensics/help)をご覧ください。
+
+XRP Ledgerコミュニティからのヘルプについては、[XRPChatフォーラム](https://xrpchat.com)を利用することもできます。
--- a/@l10n/ja/docs/_snippets/checkcash-prereqs.md
+++ b/@l10n/ja/docs/_snippets/checkcash-prereqs.md
@@ -0,0 +1,9 @@
+Checkを換金するための前提条件は、正確な金額を換金する場合も変動金額を換金する場合も同じです。
+
+- 現在レジャーに記録されているCheckオブジェクトのIDが必要です。
+  - 例えば、以下の例では、あるCheckのIDとして`838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334`を使用していますが、各ステップをご自分で行う際には、異なるIDを使用する必要があります。
+- Checkに記載されている受取人の**アドレス**と**秘密鍵**。このアドレスは、Checkオブジェクトの`Destination`アドレスと一致している必要があります。
+- 発行済み通貨用のCheckの場合は、ご自身（受取人）にイシュアーに対するトラストラインがある必要があります。このトラストライン上のご自身の限度額は、受け取る金額を追加するための残高より十分高くなければなりません。
+  - トラストラインと限度額について詳しくは、[トークン](../concepts/tokens/index.md)および[トラストラインと発行](../concepts/tokens/fungible-tokens/index.md)をご覧ください。
+- [トランザクションに安全に署名できる手段](../concepts/transactions/secure-signing.md)。
+- XRP Ledgerに接続できる[クライアントライブラリ](../references/client-libraries.md)か、それとも[HTTPライブラリ、WebSocketライブラリなど](../tutorials/http-websocket-apis/build-apps/get-started.md)。
--- a/@l10n/ja/docs/_snippets/clawback-disclaimer.md
+++ b/@l10n/ja/docs/_snippets/clawback-disclaimer.md
@@ -0,0 +1 @@
+_[Clawback amendment](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0039d-clawback)が必要です。_
--- a/@l10n/ja/docs/_snippets/conf-file-location.md
+++ b/@l10n/ja/docs/_snippets/conf-file-location.md
@@ -0,0 +1 @@
+[推奨インストール](../infrastructure/installation/index.md)では、デフォルトで`/etc/opt/ripple/rippled.cfg`という設定ファイルを使用します。その他の場所としては、`$HOME/.config/ripple/rippled.cfg`(`$HOME`は`rippled`を実行しているユーザのホームディレクトリです)、`$HOME/.local/ripple/rippled.cfg`または`rippled`を起動した現在の作業ディレクトリがあります。
--- a/@l10n/ja/docs/_snippets/data_types/account_sequence.md
+++ b/@l10n/ja/docs/_snippets/data_types/account_sequence.md
@@ -0,0 +1,11 @@
+シーケンス番号とは、32ビットの符号なし整数であり、指定された送金元からのトランザクションが正しい順序で1回だけ実行されるようにするために使用されます。
+
+すべての[XRP Ledgerアカウント](../../concepts/accounts/index.md)には、`Sequence`フィールドに1つのシーケンス番号があり、アカウントがトランザクションを送信し、そのトランザクションが[検証済みレジャー](../../concepts/ledgers/index.md)に記録されるたびに、1ずつ増加します。シーケンス番号は各[トランザクション](../../concepts/transactions/index.md)の`Sequence`フィールドにもあり、そのトランザクションが実行される際にアカウントの現在のシーケンス番号と一致している必要があります。各アカウントで、各シーケンス番号は番号順に一度だけ使用できます。
+
+[DeletableAccounts Amendment](/resources/known-amendments.md#deletableaccounts) を適用する場合、アカウントの`Sequence`番号の始まりが、アカウントが作成されたレジャーバージョンの[レジャーインデックス][]と一致します。DeletableAccountsを適用しない場合、どのアカウントの`Sequence`番号も1で始まります。
+
+トランザクションがレジャーに記録されると、トランザクションの実行が成功したか[`tec`クラスのエラーコード](../../references/protocol/transactions/transaction-results/tec-codes.md)で失敗したかを問わず、シーケンス番号が1つ消費されます。トランザクションのその他の失敗についてはレジャーに記録されないため、送金元のシーケンス番号は変更されません（その他の影響もありません）。
+
+レジャー内では、[アドレス][]とシーケンス番号を一緒に使用して、その送金元とシーケンス番号を持つ検証済みトランザクションによって作成されたオブジェクトが識別されることがあります。この方法で識別されたオブジェクトの例として、[Escrow](../../concepts/payment-types/escrow.md)と[オファー](../../concepts/tokens/decentralized-exchange/offers.md)が挙げられます。
+
+複数の未確定のトランザクションが、同じ送金元と同じシーケンス番号を持つことが可能です。そのようなトランザクションは互いに排他的であり、検証済みレジャーに記録されるのはいずれか一方のみです。（それ以外は最終的に影響ありません。）
--- a/@l10n/ja/docs/_snippets/data_types/address.md
+++ b/@l10n/ja/docs/_snippets/data_types/address.md
@@ -0,0 +1,13 @@
+XRP Ledgerのアカウントは、XRP Ledgerの[base58][]フォーマットのアドレスで識別されます。このアドレスはアカウントのマスター[公開鍵](https://en.wikipedia.org/wiki/Public-key_cryptography)から生成され、マスター公開鍵は秘密鍵から生成されます。アドレスはJSON文字列で記述され、以下の特徴があります。
+
+* 長さは25から35文字
+* 文字`r`から始まる
+* 数字"`0`"、大文字"`O`"、大文字"`I`"、小文字"`l`"を除く英数字
+* 大文字と小文字を区別
+* 4バイトのチェックサムが含まれており、ランダムな文字から有効なアドレスが生成される確率はおよそ2<sup>32</sup>分の1
+
+{% admonition type="info" name="注記" %}
+[宛先タグ](../../concepts/transactions/source-and-destination-tags.md)をアドレスに「組み込む」**X**アドレス形式もあります。これらのアドレスは`X`（メインネット用）または`T`（[テストネットワーク](../../concepts/networks-and-servers/parallel-networks.md)用）で始まります。取引所とウォレットは、顧客が知る必要のあるすべてのデータを1つの値で表すためにXアドレスを使用できます。詳細については、[Xアドレスフォーマットサイト](https://xrpaddress.info/)と[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)をご覧ください
+
+XRP Ledgerプロトコルは「クラシック」アドレスのみをネイティブにサポートしていますが、多くの[クライアントライブラリ](../../references/client-libraries.md)はXアドレスもサポートしています。
+{% /admonition %}
--- a/@l10n/ja/docs/_snippets/data_types/currency_code.md
+++ b/@l10n/ja/docs/_snippets/data_types/currency_code.md
@@ -0,0 +1,6 @@
+[HTTP / WebSocket API](../../references/http-websocket-apis/index.md)は、2種類の通貨コードをサポートしています。
+
+- **[標準通貨コード](../../references/protocol/data-types/currency-formats.md#標準通貨コード):** `"EUR"`や`"USD"`のような3文字の文字列
+- **[非標準通貨コード](../../references/protocol/data-types/currency-formats.md#非標準通貨コード):** `"0158415500000000C1F76FFF6ECB0BAC600000000"`のような160ビットの16進数の文字列。これは一般的ではありません。
+
+同じコードを持つトークンは、接続されたトラストラインを越えて[rippling(波及)](../../concepts/tokens/fungible-tokens/rippling.md)することができます。通貨コードには、XRP Ledgerに組み込まれた他の動作はありません。
--- a/@l10n/ja/docs/_snippets/data_types/hash.md
+++ b/@l10n/ja/docs/_snippets/data_types/hash.md
@@ -0,0 +1,9 @@
+XRP Ledger内の多くのオブジェクト、特にトランザクションとレジャーは、256ビットのハッシュ値で一意に識別されます。通常、この値は「SHA-512ハーフ」として算出されます。SHA-512ハーフは、あるコンテンツから[SHA-512](http://dx.doi.org/10.6028/NIST.FIPS.180-4)ハッシュを計算し、出力の前半を取得したものです。（これは256ビット、つまり32バイトで、16進数表記では64文字です。）オブジェクトのハッシュは、極めて競合の発生しにくい方法でコンテンツから生成されるため、2つのオブジェクトが同じハッシュを持つ場合、それらのオブジェクトは同じものと見なされます。
+
+XRP Ledgerのハッシュ値には、以下の特徴があります。
+
+* 長さは64文字ちょうどです
+* [16進数](https://en.wikipedia.org/wiki/Hexadecimal)の文字セット: 0-9およびA-Fです。
+* 通常は大文字で記述されます。
+
+{% admonition type="info" name="注記" %}SHA-512ハーフは、公式に定義されている _SHA-512/256_ ハッシュ関数とほぼ同等のセキュリティーを持ちます。しかし、XRP LedgerはSHA-512/256より前から利用されているため、既存のSHA-512関数上に実装することも容易にできます。（この記事の時点で、暗号ライブラリーでのSHA-512のサポートはSHA-512/256よりはるかに一般的です。）{% /admonition %}
--- a/@l10n/ja/docs/_snippets/data_types/ledger_index.md
+++ b/@l10n/ja/docs/_snippets/data_types/ledger_index.md
@@ -0,0 +1,7 @@
+レジャーインデックスは、32ビットの符号なし整数であり、レジャーを識別するために使用します。レジャーインデックスは、レジャーの _シーケンス番号_ と呼ばれることもあります。（[アカウントシーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)とは異なります。）一番最初のレジャーでは、レジャーインデックスは1でした。新しいレジャーのレジャーインデックスは、その直前のレジャーのレジャーインデックスに1を加算した値になります。
+
+レジャーインデックスがレジャーの順番を示すのに対し、[ハッシュ][]値はレジャーの正確なコンテンツを示します。2つのレジャーが同じハッシュ値を持つ場合、それらは必ず同じものです。検証済みレジャーでは、ハッシュ値とレジャーインデックスは等しく有効で、1:1の関係です。しかし、進行中のレジャーに対しては、以下の理由によりその限りでありません。
+
+* ネットワーク全体でのトランザクションの伝搬遅延が原因で、2つの異なる`rippled`サーバで、同じレジャーインデックスを持つ現行レジャーに対するコンテンツが異なる場合があります。
+* 決済済みレジャーバージョンが複数あり、コンセンサスによる検証が競合している場合があります。このようなレジャーバージョンでは、レジャーインデックスは同じですが、コンテンツは異なります（ハッシュも異なります）。これらの決済済みレジャーのうち、検証済みになるのは1つだけです。
+* 現行のオープンレジャーのハッシュは計算されません。これは、現行レジャーのレジャーインデックスは同じままであっても、コンテンツは時間とともに変化し、ハッシュが変わる可能性があるためです。レジャーのハッシュは、レジャーが閉鎖されるときにのみ計算されます。
--- a/@l10n/ja/docs/_snippets/data_types/public_key.md
+++ b/@l10n/ja/docs/_snippets/data_types/public_key.md
@@ -0,0 +1,13 @@
+XRP Ledgerは、以下のようなさまざまな状況で暗号署名を検証するために、公開鍵を使用します。
+
+* トランザクションを承認するため。トランザクションに公開鍵が添付されます。公開鍵は、送信元のXRP Ledgerのアドレスか送信者のレギュラーキーアドレスに数学的に関連付けられている必要があります。
+* `rippled`サーバ間のピアツーピア通信の安全を確保するため。これには、データベースが空の状態でサーバが起動する場合に、サーバがランダムに生成する「ノード公開鍵」が使用されます。
+* コンセンサスプロセスの一環として検証投票に署名するため。これには、サーバの運用者が[設定ファイルに定義](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)した「バリデータ公開鍵」が使用されます。
+
+バリデータ公開鍵とノード公開鍵は、まったく同じフォーマットを使用します。
+
+公開鍵は、16進数かbase-58で表すことができます。16進数では、公開鍵は3種類すべて、長さが33バイト（66文字）です。
+
+base-58フォーマットでは、バリデータ公開鍵とノード公開鍵は必ず文字`n`から始まり、その後に文字`9`が続くのが一般的です。base-58フォーマットのバリデータ公開鍵は、最長で53文字にできます。ノード公開鍵の例を以下に示します。`n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG`。
+
+XRP Ledgerのアドレスは、公開鍵に数学的に関連付けられます。この公開鍵がbase-58でエンコードされることはめったにありませんが、その場合は文字`a`から始まります。
--- a/@l10n/ja/docs/_snippets/etl-source-object.md
+++ b/@l10n/ja/docs/_snippets/etl-source-object.md
@@ -0,0 +1,13 @@
+### ETLソースオブジェクト
+<!-- このネストされたオブジェクトの定義は、server_stateとserver_infoで共通です。 -->
+
+レポートモードサーバでは、`etl_sources`フィールドの各メンバは以下のフィールドを持つオブジェクトです。
+
+| フィールド                    | 型    | 説明         |
+|-----------------------------|-------|-------------|
+| `connected`                 | 真偽値 | `true`の場合、レポートモードサーバがこのP2Pモードサーバに接続していることを示します。`false`の場合、サーバに接続していないことを示します。これは設定ミスやネットワーク障害によるものか、P2Pモードサーバが停止している可能性があります。 |
+| `grpc_port`                 | 文字列 | このレポート モードサーバが接続し、gRPCを介してレジャーデータを取得するように設定されている P2P モード サーバのポート番号。 |
+| `ip`                        | 文字列 | P2PモードサーバのIPアドレス（IPv4またはIPv6）。 |
+| `last_message_arrival_time` | 文字列 | レポートモードサーバがこのP2Pサーバからメッセージを受信した最新の時刻を示すISO 8601タイムスタンプ。 |
+| `validated_ledgers_range`   | 文字列 | `complete_ledgers`と同じ形式で、このP2Pモードサーバが利用可能であると報告する、有効なレジャーのバージョンの範囲。 |
+| `websocket_port`            | 文字列 | このレポートモードサーバが、レポートモードから直接提供できないWebSocketリクエストを転送するように設定されているP2Pサーバのポート番号。 |
--- a/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md
+++ b/@l10n/ja/docs/_snippets/interactive-tutorials/connect-step.md
@@ -0,0 +1,17 @@
+<!-- Interactive tutorials are hard-coded to Testnet for now due to Redocly 
+     limitations. They'll be replaced with new-style tutorials next anyway.
+     Localized step names don't currently work due to problems with unicode
+     in regexes. -->
+
+{% interactive-block label=default($label, "Connect") steps=$frontmatter.steps %}
+
+<button id="connect-button" class="btn btn-primary" data-wsurl="wss://s.altnet.rippletest.net:51233" data-explorer="https://testnet.xrpl.org">Testnetに接続する</button>
+<div>
+  <strong>接続ステータス：</strong>
+  <span id="connection-status">接続されていません</span>
+
+  {% loading-icon /%}
+
+</div>
+
+{% /interactive-block %}
--- a/@l10n/ja/docs/_snippets/interactive-tutorials/generate-step.md
+++ b/@l10n/ja/docs/_snippets/interactive-tutorials/generate-step.md
@@ -0,0 +1,9 @@
+{% interactive-block label=default($label, "Generate") steps=$frontmatter.steps %}
+
+<button id="generate-creds-button" class="btn btn-primary" data-fauceturl="https://faucet.altnet.rippletest.net/accounts">Testnetの暗号鍵を作成する</button>
+{% loading-icon message="暗号鍵を作成しています…" /%}
+<div class="output-area"></div>
+
+{% /interactive-block %}
+
+{% admonition type="warning" name="注意" %}Rippleは[TestnetとDevnet](../../concepts/networks-and-servers/parallel-networks.md)をテストの目的でのみ運用しており、その状態とすべての残高を定期的にリセットしています。予防措置として、Testnet、DevnetとMainnetで同じアドレスを使用**しない**ことをお勧めします。{% /admonition %}
--- a/@l10n/ja/docs/_snippets/interactive-tutorials/wait-step.md
+++ b/@l10n/ja/docs/_snippets/interactive-tutorials/wait-step.md
@@ -0,0 +1,23 @@
+{% interactive-block label=default($label, "Wait") steps=$frontmatter.steps %}
+
+<table class="wait-step" data-explorerurl="https://testnet.xrpl.org">
+  <tr>
+    <th>トランザクションのID:</th>
+    <td class="waiting-for-tx">(無）</td>
+  <tr>
+    <th>最新の検証レジャーインデックス：</th>
+    <td class="validated-ledger-version">接続されていません</td>
+  </tr>
+  <tr>
+    <th>送信時のレジャーインデックス：</th>
+    <td class="earliest-ledger-version">（まだ送信されません）</td>
+  </tr>
+  <tr>
+    <th>トランザクションの<code>LastLedgerSequence</code>:</th>
+    <td class="lastledgersequence">(準備されません）</td>
+  </tr>
+  <tr class="tx-validation-status">
+  </tr>
+</table>
+
+{% /interactive-block %}
--- a/@l10n/ja/docs/_snippets/issuing-and-operational-addresses-intro.md
+++ b/@l10n/ja/docs/_snippets/issuing-and-operational-addresses-intro.md
@@ -0,0 +1,5 @@
+XRP Ledgerでは、金融機関は秘密鍵の漏えいに関連するリスクを最小限に抑えるために、複数のXRP Ledgerアドレスを使用するのが一般的です。業界標準では、以下のような役割分担をしています。
+
+* 1つの**発行アドレス**。「コールドウォレット」とも呼ばれます。このアドレスは、レジャーでの金融機関の会計上の関係の中心となるものですが、トランザクションの送信は可能な限り少なく抑えます。
+* 1つ以上の**運用アドレス**。「ホットウォレット」とも呼ばれます。インターネットに接続した自動システムが、これらのアドレスへの秘密鍵を使用して、顧客やパートナーへの送金といった日常業務を実施します。
+* オプションの**待機アドレス**。「ウォームウォレット」とも呼ばれます。信頼できる人間のオペレーターが、これらのアドレスを使用して運用アドレスに送金します。
--- a/@l10n/ja/docs/_snippets/ledger-objects-intro.md
+++ b/@l10n/ja/docs/_snippets/ledger-objects-intro.md
@@ -0,0 +1,3 @@
+各[レジャー](../concepts/ledgers/index.md)の状態ツリーは**レジャーオブジェクト**のセットで構成されており、それらが総合して共有レジャーのすべての設定、残高、関係を表します。
+
+rippledサーバが互いに通信するために使用する[ピアプロトコル](../concepts/networks-and-servers/peer-protocol.md)では、レジャーオブジェクトは生[バイナリーフォーマット](../references/protocol/binary-format.md)で表されます。rippled APIでは、レジャーオブジェクトはJSONオブジェクトとして表されます。
--- a/@l10n/ja/docs/_snippets/no-cli-syntax.md
+++ b/@l10n/ja/docs/_snippets/no-cli-syntax.md
@@ -0,0 +1,3 @@
+{% admonition type="info" name="注記" %}
+このメソッドにはコマンドライン構文がありません。代わりに[jsonメソッド][]を使って、コマンドラインからこのメソッドにアクセスすることができます。
+{% /admonition %}
--- a/@l10n/ja/docs/_snippets/peer_reservation_object.md
+++ b/@l10n/ja/docs/_snippets/peer_reservation_object.md
@@ -0,0 +1,4 @@
+| `Field`       | 型     | 説明                                                |
+|:--------------|:-------|:----------------------------------------------------|
+| `node`        | 文字列  | この予約の対象となるピアサーバの[ノード公開鍵][]（[base58][]）。 |
+| `description` | 文字列  | _（省略される場合があります）_ このピアリザベーションの説明（ある場合）。 |
--- a/@l10n/ja/docs/_snippets/port-descriptor-object.md
+++ b/@l10n/ja/docs/_snippets/port-descriptor-object.md
@@ -0,0 +1,11 @@
+### ポート記述子オブジェクト
+<!-- このネストされたオブジェクトの定義は、server_stateとserver_infoで共通です。 -->
+
+`ports`配列の各メンバーは以下のフィールドを持つオブジェクトです。
+
+| フィールド   | 値          | 説明         |
+|------------|-------------|-------------|
+| `port`     | 文字列 - 数値 | サーバがリッスンしているポート番号。 |
+| `protocol` | 文字列の配列  | このポートに接続されているプロトコルの一覧。有効なプロトコルには、JSON-RPCの`http`または`https`、WebSocketの`ws`、`ws2`、`wss`、`wss2`、[gRPC](../infrastructure/configuration/configure-grpc.md)の`grpc`、[XRP Ledgerピアプロトコル](../concepts/networks-and-servers/peer-protocol.md)の`peer`があります。 |
+
+{% admonition type="info" name="注記" %}ネットワークインフラによっては、ここで報告されるポートやプロトコルが、外部のネットワークからサーバに到達する方法と一致しないことがあります。例えば、TLSがロードバランサやプロキシで終了する場合、サーバはあるポートで`http`と報告するかもしれませんが、外部からはポート443の`https`でしか到達できないかもしれません。{% /admonition %}
--- a/@l10n/ja/docs/_snippets/post-rippled-install.md
+++ b/@l10n/ja/docs/_snippets/post-rippled-install.md
@@ -0,0 +1,33 @@
+`rippled`が残りのネットワークと同期されるまでには数分かかることがあります。その間、レジャーがない旨を知らせる警告が出力されます。
+
+`rippled`ログメッセージの詳細は、[ログメッセージについて](../infrastructure/troubleshooting/understanding-log-messages.md)をご覧ください。
+
+`rippled`が残りのネットワークと同期されたら、ストック`rippled`サーバが完全に機能するようになります。このサーバを、ローカル署名やXRP LedgerへのAPIアクセスに使用できます。`rippled`サーバがネットワークと同期されているかどうかを判別するには、[`rippled`サーバの状況](../references/http-websocket-apis/api-conventions/rippled-server-states.md)を使用します。[`rippled`のコマンドラインインターフェイス](../tutorials/http-websocket-apis/build-apps/get-started.md#コマンドライン)を使用すれば、これを迅速にテストできます。
+
+```sh
+rippled server_info
+```
+
+rippled APIを使用した`rippled`サーバとの通信について詳しくは、[rippled API reference](../references/http-websocket-apis/index.md)をご覧ください。
+
+ストック`rippled`サーバを実行できたら、次に検証サーバとして実行してみましょう。検証サーバについて、そして検証サーバを実行する理由については、[バリデータとしてのrippledの実行](../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。
+
+`rippled`サーバの起動でお困りですか? [rippledサーバが起動しない](../infrastructure/troubleshooting/server-wont-start.md)をご覧ください。
+
+### その他の構成
+
+`rippled`は、デフォルト構成でXRP Ledgerに接続する必要があります。ただし、`rippled.cfg`ファイルを編集すれば、設定を変更できます。推奨される構成設定については、[容量の計画](../infrastructure/installation/capacity-planning.md)をご覧ください。
+
+{% partial file="/@l10n/ja/docs/_snippets/conf-file-location.md" /%}
+
+すべての構成オプションの説明については、[`rippled` GitHubリポジトリー](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)をご覧ください。
+
+構成の変更を有効にするには、`rippled`を再起動する必要があります。
+
+`[debug_logfile]`セクションまたは`[database_path]`セクションを変更すると、`rippled`を実行するユーザに、新しく構成したパスの所有権を付与する必要が生じる場合があります。
+
+### 更新
+
+`rippled`を定期的に更新して、残りのXRP Ledgerネットワークと同期させておく必要があります。[rippledのGoogleグループ](https://groups.google.com/forum/#!forum/ripple-server)をサブスクライブすれば、`rippled`の新しいリリースに関する通知を受け取ることができます。
+
+`rippled`のパッケージには、[Linuxでの自動更新を有効にする](../infrastructure/installation/update-rippled-automatically-on-linux.md)ために使用できるスクリプトが含まれています。その他のプラットフォームでは、手動での更新が必要です。
--- a/@l10n/ja/docs/_snippets/pseudo-tx-fields-intro.md
+++ b/@l10n/ja/docs/_snippets/pseudo-tx-fields-intro.md
@@ -0,0 +1,3 @@
+## {% $frontmatter.seo.title %} フィールド
+
+[共通フィールド][../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md]に加えて、{% $frontmatter.seo.title %}擬似トランザクションは以下のフィールドを使用します。
--- a/@l10n/ja/docs/_snippets/public-signing-note.md
+++ b/@l10n/ja/docs/_snippets/public-signing-note.md
@@ -0,0 +1 @@
+_デフォルトでは、このメソッドは[管理者専用](../references/http-websocket-apis/admin-api-methods/index.md)です。サーバ管理者が[パブリック署名を有効にしている](../infrastructure/configuration/enable-public-signing.md)場合、パブリックメソッドとして使用できます_。
--- a/@l10n/ja/docs/_snippets/secret-key-warning.md
+++ b/@l10n/ja/docs/_snippets/secret-key-warning.md
@@ -0,0 +1,3 @@
+{% admonition type="warning" name="注意" %}
+自分が管理していないサーバに秘密鍵を送信しないでください。暗号化されていない秘密鍵をネットワーク経由で送信しないでください。
+{% /admonition %}
--- a/@l10n/ja/docs/_snippets/setfee_uniqueness_note.md
+++ b/@l10n/ja/docs/_snippets/setfee_uniqueness_note.md
@@ -0,0 +1,3 @@
+{% admonition type="info" name="注記" %}
+XRP Ledgerの全履歴では、トランザクションハッシュは一意であるというルールに例外があります。初期の2つの[SetFee疑似トランザクション][]にはまったく同じフィールドがあったため、ハッシュが同じ`1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B`になっています。これらのトランザクションのうち1つ目は[レジャー3715073に](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3715073%7D)表示され、2つ目は[レジャー3721729に](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fs2.ripple.com%2F&req=%7B%22id%22%3A%22setfee_nonunique_hash_1%22%2C%22command%22%3A%22transaction_entry%22%2C%22tx_hash%22%3A%221C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B%22%2C%22ledger_index%22%3A3721729%7D)表示されます。新しい[SetFee疑似トランザクション][]には`LedgerSequence`フィールドが含まれるため、ハッシュは一意であることが保証されています。
+{% /admonition %}
--- a/@l10n/ja/docs/_snippets/string-number-formatting.md
+++ b/@l10n/ja/docs/_snippets/string-number-formatting.md
@@ -0,0 +1,8 @@
+XRP LedgerのAPIでは、[XRP](../introduction/what-is-xrp.md)と[トークン](../concepts/tokens/index.md)の両方で、通貨の金額を数値で表現するために、JSONのネイティブの数値ではなく文字列を使用します。これは、JSONパーサーが自動的にすべてのJSON数値を浮動小数点形式で表現しようとする可能性がある場合に、精度の低下を防ぐためです。String値の中では、数値はネイティブのJSON数値と同じ方法で処理されます。
+
+* 10進数
+* ゼロの接頭辞なし
+* 小数点として`.`を含むことができます。例えば、½は`0.5`と表されます
+* 負の金額は`-`から始まります
+* `E`または`e`は10の累乗（科学的記数法）を表します。例えば`1.2E5`は1.2×10<sup>5</sup>つまり`120000`と同じです。負の指数も可能です。
+* カンマ(`,`)は使用しません。
--- a/@l10n/ja/docs/_snippets/tutorial-sign-step.md
+++ b/@l10n/ja/docs/_snippets/tutorial-sign-step.md
@@ -0,0 +1,3 @@
+トランザクションに署名する最も安全な方法は、[クライアントライブラリ](../references/client-libraries.md)を使用してローカルで署名することです。[signメソッド](../references/http-websocket-apis/admin-api-methods/signing-methods/sign.md)を使用してトランザクションに署名することもできますが、その場合は信頼できる暗号化された接続を使用するか、ローカル接続を使用して、自分が管理しているサーバに対してのみに行うようにしてください。
+
+いずれの場合も、後のために、署名したトランザクションの識別用ハッシュを書き留めておいてください。
--- a/@l10n/ja/docs/_snippets/tutorial-submit-step.md
+++ b/@l10n/ja/docs/_snippets/tutorial-submit-step.md
@@ -0,0 +1,3 @@
+前のステップで署名したトランザクションblobを`rippled`サーバに送信します。これは`rippled`サーバを実行していなくても安全にできます。レスポンスには仮の結果が含まれ、それは`tesSUCCESS`であるべきですが、この結果は[通常は最終的なものではありません](../concepts/transactions/finality-of-results/index.md)。[キューに入れられたトランザクション](../concepts/transactions/transaction-cost.md#queued-transactions)は通常、次のオープンレジャーのバージョンに含まれるからです(通常、送信から約10秒後となります)。
+
+{% admonition type="success" name="ヒント" %}仮の結果が `tefMAX_LEDGER` であった場合、そのトランザクションの`LastLedgerSequence`パラメータが現在のレジャー番号よりも低いため、そのトランザクションが失敗しています。これは、トランザクション情報を準備してから送信するまでに、予想されるレジャーのバージョン数よりも長くかかった場合に起こります。このような場合は、`LastLedgerSequence`の値を大きくしてステップ1からやり直してください。{% /admonition %}
--- a/@l10n/ja/docs/_snippets/tx-fields-intro.md
+++ b/@l10n/ja/docs/_snippets/tx-fields-intro.md
@@ -0,0 +1,3 @@
+## {% $frontmatter.seo.title %} フィールド
+
+[共通フィールド][]に加えて、{% $frontmatter.seo.title %}トランザクションは以下のフィールドを使用します。
--- a/@l10n/ja/docs/_snippets/tx-metadata-field-table.md
+++ b/@l10n/ja/docs/_snippets/tx-metadata-field-table.md
@@ -0,0 +1,7 @@
+| フィールド                                 | 値               | 説明    |
+|:--------------------------------------|:--------------------|:---------------|
+| `AffectedNodes`                       | 配列               | このトランザクションで作成、削除、または修正された[レジャーオブジェクト](../references/protocol/ledger-data/ledger-entry-types/index.md)のリストと、個々のオブジェクトに対する具体的な変更内容。 |
+| `DeliveredAmount`                     | [通貨額](../references/protocol/data-types/basic-data-types.md#通貨額の指定) | **廃止予定。**`delivered_amount`で置き換えられます。Partial Paymentsでない場合は省略されます。 |
+| `TransactionIndex`                    | 符号なし整数    | トランザクションが記録されているレジャーでのトランザクションの位置。この配列は0から始まります。（例えば、値が`2`の場合、そのレジャーの3番目のトランザクションであったことを意味します）。 |
+| `TransactionResult`                   | 文字列              | トランザクションが成功したか、どのような理由で失敗したかを示す[結果コード](../references/protocol/transactions/transaction-results/index.md)。 |
+| [`delivered_amount`](../references/protocol/transactions/metadata.md#delivered_amount) | [通貨額](../references/protocol/data-types/basic-data-types.md#通貨額の指定) | `Destination`アカウントが実際に受取った通貨額。このフィールドは、トランザクションが[Partial Payments](../concepts/payment-types/partial-payments.md)であるかどうかにかかわらず、送金された金額を特定するために使用します。 |
--- a/@l10n/ja/docs/_snippets/unsynced_warning_logs.md
+++ b/@l10n/ja/docs/_snippets/unsynced_warning_logs.md
@@ -0,0 +1 @@
+サーバ起動後の最初の5～15分間に、サーバがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバ起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、ネットワーク接続の信頼性が低いことや、[ハードウェアのスペック](../infrastructure/installation/system-requirements.md)が不十分であることが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
--- a/@l10n/ja/docs/_snippets/wait-for-validation.md
+++ b/@l10n/ja/docs/_snippets/wait-for-validation.md
@@ -0,0 +1,3 @@
+本番環境のネットワークやTestnetでは、レジャーが自動的に閉鎖するまでに4～7秒かかる場合があります。
+
+スタンドアロンモードで`rippled`を実行している場合は、[ledger_acceptメソッド][]を使用してレジャーを手動で閉鎖します。
--- a/@l10n/ja/docs/concepts/accounts/account-types.md
+++ b/@l10n/ja/docs/concepts/accounts/account-types.md
@@ -0,0 +1,83 @@
+---
+html: account-types.html
+parent: accounts.html
+seo:
+    description: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。
+labels:
+  - トークン
+  - セキュリティ
+---
+# アカウントの種類
+
+{% partial file="/@l10n/ja/docs/_snippets/issuing-and-operational-addresses-intro.md" /%}
+
+
+## 資金のライフサイクル
+
+トークン発行者がこのような役割を分担すると、以下の図のように資金が一方向に流れるようになります。
+
+[{% inline-svg file="/docs/img/issued-currency-funds-flow.ja.svg" /%}](/docs/img/issued-currency-funds-flow.ja.svg "図: 発行アドレスから待機アドレス、運用アドレス、顧客アドレスおよびパートナーアドレスに移動し、最後に発行アドレスに戻る資金フロー")
+
+発行アドレスは、待機アドレスに支払いを送信することでトークンを作成します。これらのトークンは(多くの場合)債務を表すため、発行アドレスの観点からはマイナスの価値を持ちます。同じトークンは、待機アドレスの観点も含めると、他の観点からはプラスの価値を持ちます。
+
+待機アドレスは、実際の人間によって操作され、トークンを運用アドレスに送信します。このステップにより、発行アドレスはこの時点以降、可能な限り使用されることなく、同時に少なくとも一定のトークンを待機状態にすることができます。
+
+自動化されたシステムにより運用される運用アドレスは、流動性プロバイダー、パートナー、その他の顧客など、他のカウンターパーティに資金を送ります。これらのカウンターパーティは、資金を自由に複数回送金することができます。
+
+いつものように、トークンの支払いはトラストラインを通じて発行者を「波及」しなければなりません。
+
+最終的に、誰かがトークンを発行者に送り返します。これによってトークンはバーンされ、XRP Ledgerにおける発行者の債務は減少します。トークンがステーブルコインであれば、これはトークンを対応するオフレジャー資産と交換する最初のステップです。
+
+## 発行アドレス
+
+発行アドレスは金庫に似ています。パートナーアドレス、顧客アドレス、運用アドレスは、発行アドレスにトラストラインを作成しますが、このアドレスは可能な限りトランザクションを送信しません。人間のオペレーターが定期的に、発行アドレスからトランザクションを作成、署名し、待機アドレスまたは運用アドレスの残高を補充します。理想的には、これらのトランザクションに署名するために使用される秘密鍵は、インターネットに接続されたコンピュータから決してアクセスできないようにする必要があります。
+
+金庫とは異なり、発行アドレスは顧客またはパートナーからの支払いを直接受領できます。XRP Ledgerのトランザクションは全て公開されているため、自動化されたシステムは秘密鍵を必要とせずに発行アドレスへの支払いを監視することができます。
+
+### 発行アドレスの漏えい
+
+悪意のある第三者が金融機関の発行アドレスの秘密鍵を知った場合、その第三者は新しいトークンを発行し、ユーザに送ったり、分散型取引所で取引したりすることができます。これにより、ステーブルコインの発行者は支払不能に陥る可能性があります。金融機関が合法的に入手したトークンを区別し、公正に換金することが困難になる可能性があります。金融機関が発行アドレスのコントロールを失った場合、金融機関は新しい発行アドレスを作成しなければならず、古い発行アドレスにトラストラインを持つすべてのユーザは、新しいアドレスで新しいトラストラインを作成しなければなりません。
+
+### 複数の発行アドレス
+
+金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行することができます。ただし、[送金手数料](../tokens/transfer-fees.md)のパーセンテージや[Global Freeze](../tokens/fungible-tokens/freezes.md)の状態など、1つのアドレスから発行される全ての(代替可能)トークンに等しく適用される設定もあります。トークンの種類ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
+
+
+## 運用アドレス
+
+運用アドレスはレジに似ています。イシュアンスを顧客とパートナーに送信して、金融機関に代わって支払いを行います。トランザクションに自動的に署名するには、運用アドレスの秘密鍵をインターネットに接続されたサーバに保管する必要があります。(秘密鍵は暗号化して保管できますが、サーバがトランザクションに署名する際に秘密鍵を復号化する必要があります。)顧客やパートナーは、運用アドレスへのトラストラインを作成しませんし、作成すべきではありません。
+
+各運用アドレスのトークンとXRPの残高は限られています。運用アドレスの残高が少なくなると、金融機関は発行アドレスまたは待機アドレスから支払いを送ることで残高を補充します。
+
+### 運用アドレスの漏えい
+
+不正使用者が運用アドレスのシークレットキーを入手した場合に金融機関が失う可能性のある通貨額は、最大でも運用アドレスが保有している額までです。金融機関は、顧客やパートナーからのアクションなしに、新しい運用アドレスに切り替えることができます。
+悪意のある第三者が運用アドレスの秘密鍵を知ってしまった場合、金融機関が失うのはその運用アドレスが持つ分の金額のみです。金融機関は、顧客やパートナーが何もしなくても、新しい運用アドレスに切り替えることができます。
+
+## 待機アドレス
+
+金融機関がリスクと利便性のバランスのために取ることができるもう一つの手段として、発行アドレスと運用アドレスの中間地点として「待機アドレス」を使用することです。金融機関は、待機アドレスとして追加のXRP Ledgerアドレスに資金を供給することができ、その鍵は常時オンラインのサーバでは利用できませんが、別の信頼できるユーザに委託されます。
+
+運用アドレスの資金(トークンまたはXRP)が不足した場合、信頼できるユーザは待機アドレスを使って運用アドレスの残高を補充することができます。待機アドレスの資金が不足した場合、金融機関は発行アドレスを使用して、単一のトランザクションでより多くの資金を待機アドレスに送ることができ、待機アドレスは必要に応じてそれらの資金を自分たちの間で分配することができます。これにより、発行アドレスのセキュリティが向上し、単一の自動化システムの管理下に多くの資金を残すことなく、トランザクションの総数を少なくすることができます。
+
+運用アドレスと同様に、待機アドレスは、顧客やパートナーではなく、発行アドレスとトラストラインを設定しなければなりません。運用アドレスに適用されるすべての注意事項は、待機アドレスにも適用されます。
+
+### 待機アドレスの漏えい
+
+待機アドレスの秘密鍵が漏えいした場合、その影響は運用アドレスの場合と同じです。悪意のある第三者は、待機アドレスが保有するすべての残高を盗むことができ、金融機関は顧客やパートナーが何もしなくても、新しい待機アドレスに切り替えることができます。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [アカウント](index.md)
+    - [暗号鍵](cryptographic-keys.md)
+- **チュートリアル:**
+    - [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+    - [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+- **リファレンス:**
+    - [account_infoメソッド][]
+    - [SetRegularKeyトランザクション][]
+    - [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/addresses.md
+++ b/@l10n/ja/docs/concepts/accounts/addresses.md
@@ -0,0 +1,95 @@
+---
+html: addresses.html
+parent: accounts.html
+seo:
+    description: アドレスは、base58フォーマットを使用して、XRP Ledgerのアカウントを一意に識別します。
+labels:
+  - アカウント
+---
+# アドレス
+
+{% partial file="/@l10n/ja/docs/_snippets/data_types/address.md" /%}
+
+有効なアドレスであれば、資金を入金することで[XRP Ledgerのアカウントになる](index.md#creating-accounts)ことができます。また、[レギュラーキー](cryptographic-keys.md)や[署名者リスト](multi-signing.md)のメンバーとして、資金提供されていないアドレスを使用することもできます。資金を供給されたアカウントだけがトランザクションの送信者になることができます。
+
+キーペアの生成を始めとする有効なアドレスの作成は、厳密には数学的な作業です。キーペアの生成とアドレスの計算は、XRP Ledgerや他のいかなる第三者とも通信することなく、完全にオフラインで行うことができます。公開鍵からアドレスへの変換には一方向ハッシュ関数が使用されるため、公開鍵とアドレスの一致を確認することは可能ですが、アドレスのみから公開鍵を導き出すことは不可能です。(これが署名付きトランザクションに公開鍵と送信者のアドレスを含める理由の一部です)。
+
+
+## 特別なアドレス
+
+XRP Ledgerでは、特別な意味や歴史的な役割を持つアドレスがあります。多くの場合、これらは"ブラックホール"アドレスであり、そのアドレスは既知の秘密鍵に由来するものではありません。アドレスから秘密鍵を推測することは事実上不可能であるため、ブラックホールアドレスが保有するXRPは永遠に失われます。
+
+| アドレス                       | 名称 | 意味 | ブラック ホール? |
+|-------------------------------|-----|-----|----------------|
+| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | 値0を[base58][]形式にエンコードしたXRP Ledgerのアドレス。ピアツーピア通信では、このアドレスは、XRPの発行者として`rippled`で使用されます。 | はい |
+| `rrrrrrrrrrrrrrrrrrrrBZbvji`  | ACCOUNT\_ONE | 値1を[base58][]形式にエンコードしたXRP Ledgerのアドレス。レジャーの[RippleStateエントリ](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)では、このアドレスは、トラストライン残高の発行者のプレースホルダーとして使用されます。 | はい |
+| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | ジェネシスアカウント | `rippled`で(スタンドアロンモードなど)新しいジェネシスレジャーが一から開始される場合、このアカウントはすべてのXRPを保持します。このアドレスは、シード値`masterpassphrase`から生成されており、この値は[ハードコーディング](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ |
+| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Namesの登録用ブラックホール | 以前、Ripple社は、Ripple Namesを登録するために、このアカウントにXRPを送金するようユーザに求めていました。| はい |
+| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaNアドレス | 以前のバージョンの[ripple-lib](https://github.com/XRPLF/xrpl.js)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。 | はい |
+
+
+## アドレスのエンコード
+
+{% admonition type="success" name="ヒント" %}これらの技術的な詳細は、XRP Ledgerとの互換性を保つために低レベルのライブラリソフトウェアを構築しているユーザのみを対象としています!{% /admonition %}
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "ソース")
+
+XRP Ledgerのアドレスは、[base58][]形式の _ディクショナリ_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`を使用してエンコードされています。XRP Ledgerはbase58でいくつかのタイプのキーをエンコードするため、それらを区別するためにエンコードされたデータの前に1バイトの「タイプ接頭辞」（「バージョン接頭辞」とも呼ばれます）を付けます。タイプ接頭辞によりアドレスは通常、base58形式の異なる文字で始まります。
+
+次の図は、キーとアドレスの関係を示しています
+
+[{% inline-svg file="/docs/img/address-encoding.ja.svg" /%}](/docs/img/address-encoding.ja.svg "マスター公開鍵 + タイプ接頭辞 → アカウントID + チェックサム → アドレス")
+
+公開鍵からXRP Ledgerアドレスを計算する式は次の通りです。完全なサンプルコードついては、[`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/_code-samples/address_encoding/js/encode_address.js)をご覧ください。パスフレーズまたはシード値から公開鍵を導出するプロセスについては、[鍵の導出](cryptographic-keys.md#鍵導出)をご覧ください。
+
+1. 次の必須アルゴリズムをインポートします。SHA-256、RIPEMD160、base58。base58のディクショナリを設定します。
+
+    ```
+    'use strict';
+    const assert = require('assert');
+    const crypto = require('crypto');
+    const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
+    const base58 = require('base-x')(R_B58_DICT);
+
+    assert(crypto.getHashes().includes('sha256'));
+    assert(crypto.getHashes().includes('ripemd160'));
+    ```
+
+2. 33バイトのECDSA secp256k1公開鍵、または32バイトのEd25519公開鍵で始めます。Ed25519キーの場合は、キーの前にバイト文字`0xED`を付与します。
+
+    ```
+    const pubkey_hex =
+      'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
+    const pubkey = Buffer.from(pubkey_hex, 'hex');
+    assert(pubkey.length == 33);
+    ```
+
+3. 公開鍵のSHA-256ハッシュの[RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD)ハッシュを計算します。この値は「Account ID」です。
+
+    ```
+    const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
+    const pubkey_outer_hash = crypto.createHash('ripemd160');
+    pubkey_outer_hash.update(pubkey_inner_hash.digest());
+    const account_id = pubkey_outer_hash.digest();
+    ```
+
+4. アカウントIDのSHA-256ハッシュのSHA-256ハッシュを計算します。最初の4バイトを使用します。この値が「チェックサム」です。
+
+    ```
+    const address_type_prefix = Buffer.from([0x00]);
+    const payload = Buffer.concat([address_type_prefix, account_id]);
+    const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
+    const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
+    const checksum =  chksum_hash2.slice(0,4);
+    ```
+
+5. ペイロードとチェックサムを連結します。連結バッファーのbase58値を計算します。この結果が、アドレスになります。
+
+    ```
+    const dataToEncode = Buffer.concat([payload, checksum]);
+    const address = base58.encode(dataToEncode);
+    console.log(address);
+    // rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
+    ```
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/cryptographic-keys.md
+++ b/@l10n/ja/docs/concepts/accounts/cryptographic-keys.md
@@ -0,0 +1,259 @@
+---
+html: cryptographic-keys.html
+parent: accounts.html
+seo:
+    description: 暗号鍵を使用してトランザクションを承認し、XRP Ledgerがトランザクションを実行できるようにします。
+labels:
+  - セキュリティ
+  - スマートコントラクト
+---
+# 暗号鍵
+
+XRP Ledgerでは、[トランザクション](../transactions/index.md)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
+
+すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.md)のメンバーとして使用できます。
+
+{% admonition type="danger" name="警告" %}秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。お使いのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。{% /admonition %}
+
+
+## キーの生成
+
+多くの[クライアントライブラリ](../../references/client-libraries.md)やアプリケーションは、XRP Ledgerでの使用に合わせてキーペアを生成できます。もちろん、信頼できるデバイスやソフトウェアで生成されたキーペアのみを使用する必要があります。悪意のあるアプリケーションは、あなたの秘密情報を悪意のあるユーザに公開する可能性があり、そのユーザはあなたのアカウントから後でトランザクションを送信することができます。
+
+## キーの構成要素
+
+暗号鍵ペアは、鍵の導出プロセスを通じて数学的に関連づけられる**秘密鍵**と**公開鍵**のことです。秘密鍵は、強力なランダム性によって決定されなければなりません。[暗号化署名アルゴリズム](#署名アルゴリズム)は、鍵の導出プロセスを定義し、暗号鍵となり得る数値の制限を設定します。
+
+XRP Ledgerを扱う場合、パスフレーズ、シード、アカウントID、アドレスなど、いくつかの関連する値を使用することもあります。
+
+[{% inline-svg file="/docs/img/cryptographic-keys.ja.svg" /%}](/docs/img/cryptographic-keys.ja.svg "Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス")
+_図: 暗号鍵の値の関係を簡略化した図_
+
+パスフレーズ、シード、秘密鍵は**秘密**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。
+
+公開鍵、アカウントID、アドレスは公開情報です。一時的に公開鍵を秘密にするような状況もありますが、最終的にはトランザクションの一部として公開し、XRP Ledgerが署名を検証してトランザクションを処理できるようにすることが必要です。
+
+鍵の導出の仕組みの技術的な詳細については、[鍵の導出](#鍵導出)をご覧ください。
+
+### パスフレーズ
+
+オプションとして、パスフレーズやその他の情報を、シードや秘密鍵の決定方法として使用することができます。これは、完全にランダムにシードや秘密鍵を選択するよりも安全性が低いですが、これを行いたいレアケースもあります。(例えば、2018年に「XRPuzzler」が最初に[パズルを解いた人](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/)にXRPをプレゼントしました。彼はパズルの解答を、賞品のXRPを保有するアカウントへのパスフレーズとして使用しました)
+
+パスフレーズは秘密情報であるため、厳重に保管する必要があります。アドレスのパスフレーズを知った人は、そのアドレスを実質的に完全にコントロールすることができます。
+
+### シード
+
+_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[wallet_proposeメソッド][]のレスポンスでは、`master_key`,`master_seed`,`master_seed_hex`はすべて同一のシード値を様々な形式で表現します。これらの形式はいずれも、[`rippled` API](../../references/http-websocket-apis/index.md)やいくつかの[他のXRP Ledgerソフトウェア](../../introduction/software-ecosystem.md)で[トランザクションの署名](../transactions/index.md#トランザクションへの署名とトランザクションの送信)に使用することができます。`master_`という接頭辞がついていますが、このシードが表す鍵は必ずしもアカウントのマスターキーではありません。この鍵ペアはレギュラーキーとして、あるいはマルチシグリストのメンバーとして使用することもできます。
+
+シード値は秘密情報であるため、非常に厳重に保管する必要があります。あるアドレスのシード値を知っている人は、そのアドレスを実質的に完全にコントロールすることができます。
+
+### 秘密鍵
+
+_秘密鍵_ は、デジタル署名を作成するために使用される値です。ほとんどのXRP Ledgerソフトウェアは、秘密鍵を明示的に表示せず、必要に応じてシード値から[秘密鍵の導出](#鍵導出)を行っています。シードの代わりに秘密鍵を保存し、それを使ってトランザクションに直接署名することは技術的には可能ですが、この使い方はレアケースです。
+
+シードと同様、秘密鍵は秘密情報であるため、厳重に保管する必要があります。あるアドレスの秘密鍵を知っている人は、そのアドレスを事実上完全にコントロールすることができます。
+
+### 公開鍵
+
+公開鍵は、電子署名の正当性を検証するために使用される値です。公開鍵は、鍵の導出の一部として秘密鍵から導出されます。[wallet_proposeメソッド][]のレスポンスでは、`public_key`と`public_key_hex`は両方とも同じ公開鍵の値を表します。
+
+XRP Ledgerのトランザクションには、ネットワークがトランザクションの署名を検証できるように、公開鍵が含まれている必要があります。公開鍵は有効な署名を作成するために使用することはできないので、公開しても問題はありません。
+
+
+### アカウントIDとアドレス
+
+**アカウントID**は、[アカウント](index.md)またはキーペアの中核となる識別子です。これは公開鍵から派生します。XRP Ledgerのプロトコルでは、アカウントIDは20バイトのバイナリデータです。ほとんどのXRP Ledger APIは、アカウントIDをアドレスとして表現し、次の2つのフォーマットのうちの1つで表現します。
+
+- 「クラシックアドレス」は、[base58][]にチェックサム付きでアカウントIDを書きます。[wallet_proposeメソッド][]のレスポンスでは、これが`account_id`の値となります。
+- 「X-Address」は、アカウントIDと[宛先タグ](../transactions/source-and-destination-tags.md)を組み合わせ、チェックサムとともに[base58][]にその値を書き込みます。
+
+どちらの形式でもチェックサムがあるため、わずかな変更でアドレスが無効になり、他の有効なアカウントと入れ替わる可能性はありません。これにより、タイプミスや送信エラーが発生しても、間違った場所に送金されることはありません。
+
+すべてのアカウントID（またはアドレス）が台帳のアカウントを参照しているわけではないことを知っておくことが重要です。キーとアドレスの導出は、純粋に数学的な操作です。アカウントがXRP Ledgerに情報を持つには、[XRPの支払いを受け](index.md#creating-accounts)、[準備金](reserves.md)を満たす必要があります。アカウントは、資金が供給されるまでトランザクションを送信することはできません。
+
+アカウントIDやアドレスが資金提供されたアカウントを指していない場合でも、そのアカウントIDやアドレスを使用して、[レギュラーキーペア](#レギュラーキーペア)や[署名者リストのメンバー](multi-signing.md)を表すことはできます。
+
+### キーの種類
+
+XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズム)をサポートしています。任意のキーペアは、特定の暗号化署名アルゴリズムに対してのみ有効です。いくつかの秘密鍵は、技術的には複数のアルゴリズムに対して有効な鍵として適格かもしれませんが、それらの秘密鍵は各アルゴリズムに対して異なる公開鍵を持つことになり、いずれにしても秘密鍵を再利用すべきではありません。
+
+[wallet_proposeメソッド][]の`key_type`フィールドは、使用する暗号化署名アルゴリズムを指します。
+
+
+## マスターキーペア
+
+マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](addresses.md#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
+
+[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからのレスポンスには、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](../transactions/secure-signing.md)をご覧ください。
+
+{% admonition type="warning" name="注意" %}悪意のある行為者があなたのマスター秘密鍵（またはシード）を知った場合、マスター鍵ペアが無効化されていない限り、彼らはあなたのアカウントを完全にコントロールすることができます。彼らはあなたのアカウントが保持している全ての資金を盗み、その他の回復不能な損害を与えることができます。秘密鍵は慎重に扱ってください！{% /admonition %}
+
+マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](../../tutorials/how-tos/manage-account-settings/offline-account-setup.md)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
+
+マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所に秘密情報(パスフレーズ、シード、秘密鍵)を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
+
+
+
+### 特殊な権限
+
+**マスターキーペア**のみが、ある特定の処理を行うトランザクションを承認することができます。
+
+- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](../transactions/index.md#トランザクションの承認)して初期化することができないからです。
+
+- マスターキーペアを無効化する。
+
+- [凍結](../tokens/fungible-tokens/freezes.md#no-freeze)の機能を永久に放棄する。
+
+- トランザクションコスト0XRPの特別な[キーリセットトランザクション](../transactions/transaction-cost.md#key-resetトランザクション)を送信する。
+
+レギュラーキーや[マルチシグ](multi-signing.md)は、マスターキーペアと同じようにその他の処理を行うことができます。特に、マスターキーペアを無効にした後、レギュラーキーペアやマルチシグを使用して再び有効にすることができます。また、削除の条件を満たしていれば、[アカウントの削除](deleting-accounts.md)を行うことも可能です。
+
+
+## レギュラーキーペア
+
+XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセカンダリキーペアを許可することができます。そうすると、[マスターキーペア](#マスターキーペア)とレギュラーキーのどちらかを使ってトランザクションを承認することができるようになります。レギュラーキーペアは、アカウントの他の部分を変更することなく、いつでも削除または変更することができます。
+
+レギュラーキーペアは、マスターキーペアと同じ種類のトランザクションのほとんどを承認することができますが、[特定の例外](#特殊な権限)があります。例えば、レギュラーキーペアは、レギュラーキーペアを変更するトランザクションを _承認_ することができます。
+
+マスター秘密鍵はオフラインの場所に保存し、ほとんどの時間、レギュラーキーペアを使用することがセキュリティ上推奨されます。万一の備えとして、レギュラーキーペアを定期的に変更するのもよいでしょう。悪意のあるユーザにレギュラーの秘密鍵を知られてしまった場合、マスターキーペアをオフラインで保存し、それを使ってレギュラーキーペアを変更または削除することができます。こうすることで、アカウントの制御を取り戻すことができます。悪意のあるユーザにお金を盗まれるのを阻止するほどのスピードがなかったとしても、少なくとも、新しいアカウントに移行して、すべての設定や人間関係を一から作り直す必要はありません。
+
+レギュラーキーペアは、マスターキーペアと同じ形式です。生成方法も同じです（例えば、[wallet_proposeメソッド][]を使用します）。唯一の違いは、レギュラーキーペアは、トランザクションに署名するアカウントと本質的に結びついていないことです。あるアカウントのマスターキーペアを別のアカウントの通常キーペアとして使用することは可能です（ただし、推奨されるものではありません）。
+
+[SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)をご覧ください
+
+
+## 署名アルゴリズム
+
+暗号鍵ペアは常に特定の署名アルゴリズムに関連付けられています。署名アルゴリズムは、秘密鍵と公開鍵の間の数学的関係を定義します。暗号化署名アルゴリズムには、現在の暗号技術では、秘密鍵を使用して対応する公開鍵を「簡単に」計算できるものの、公開鍵から対応する秘密鍵を計算することは実質的に不可能であるという特性があります。
+
+XRP Ledgerでは次の暗号化署名アルゴリズムがサポートされています。
+
+| キータイプ | アルゴリズム | 説明 |
+|-------------|-----------|---|
+| `secp256k1` | 楕円曲線[secp256k1](https://en.bitcoin.it/wiki/Secp256k1)を使用する[ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) | これはBitcoinで使用されているスキームです。XRP Ledgerではデフォルトでこのキータイプが使用されます。 |
+| `ed25519` | 楕円曲線[Ed25519](https://ed25519.cr.yp.to/)を使用する[EdDSA](https://tools.ietf.org/html/rfc8032) | パフォーマンスに優れ、その他の便利な特性を備えた新しいアルゴリズムです。Ed25519公開鍵はsecp256k1鍵よりも1バイト短いため、`rippled`ではEd25519公開鍵の先頭に`0xED`バイトが追加されます。これにより、両方の公開鍵タイプは33バイトになります。 |
+
+[wallet_proposeメソッド][]を使用してキーペアを生成するときには、キーの生成に使用する暗号化署名アルゴリズムを選択するため`key_type`を指定できます。デフォルト以外のキータイプを生成した場合は、トランザクションに署名する際に`key_type`も指定する必要があります。
+
+XRP Ledgerでは、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](addresses.md#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
+
+
+### 将来のアルゴリズム
+
+今後、暗号技術の発展に対応するため、XRP Ledgerには新しい暗号化署名アルゴリズムが必要になるでしょう。例えば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピュータの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合、XRP Ledger開発者は容易に解読できない暗号化署名アルゴリズムを追加できます。2019年半ばの時点で、確実な第一選択肢となる「耐量子」署名アルゴリズムはなく、量子コンピュータはまだ脅威となるほど実用的ではないため、現時点では特定のアルゴリズムを追加する予定はありません。
+
+
+## 鍵導出
+
+キーペアを導出するプロセスは、署名アルゴリズムによって異なります。いずれの場合も、キーは長さが16バイト（128ビット）の _シード_ 値から生成されます。シード値は完全にランダムにする（推奨）か、[SHA-512ハッシュ][ハッシュ]を取得して最初の16バイトを保持することで特定のパスフレーズから導出することができます（[SHA-512ハーフ][]と同様ですが、出力の256ビットではなく128ビットのみを保持します）。
+
+### サンプルコード
+
+ここで説明する鍵導出プロセスは、さまざまなプログラミング言語で複数の場所に実装されています。
+
+- C++: `rippled`コードベース:
+    - [シード定義](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
+    - [汎用キー & Ed25519鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+    - [secp256k1鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
+- Python 3: {% repo-link path="_code-samples/key-derivation/py/key_derivation.py" %}このリポジトリのコードサンプルセクション{% /repo-link %}
+- JavaScript: [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs)パッケージ
+
+### Ed25519鍵導出
+[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
+
+[{% inline-svg file="/docs/img/key-derivation-ed25519.ja.svg" /%}](/docs/img/key-derivation-ed25519.ja.svg "パスフレーズ → シード → 秘密鍵 → プレフィクス + 公開鍵")
+
+1. シード値の[SHA-512ハーフ][]を計算します。32バイトの秘密鍵が導出されます。
+
+    {% admonition type="success" name="ヒント" %}32バイトの数値はすべて、有効なEd25519秘密鍵です。ただし、秘密鍵として使用する上で安全なのは、十分ランダムに選択された数値のみです。{% /admonition %}
+
+2. Ed25519公開鍵を計算するには、[Ed25519](https://ed25519.cr.yp.to/software.html)の標準公開鍵を導出して、32バイトの公開鍵を導出します。
+
+    {% admonition type="warning" name="注意" %}暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519やsecp256k1が実装されています。{% /admonition %}
+
+3. Ed25519公開鍵を示すには、32バイトの公開鍵の前にシングルバイトのプレフィクス`0xED`を付加し、33バイトにします。
+
+    トランザクションに署名するコードを実装している場合は、プレフィクス`0xED`を削除し、実際の署名プロセスに32バイトキーを使用します。
+
+4. アカウントの公開鍵を[base58][]にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。
+
+    バリデータの一時キーにEd25519を使用することはできません。
+
+### secp256k1鍵導出
+[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
+
+[{% inline-svg file="/docs/img/key-derivation-secp256k1.ja.svg" /%}](/docs/img/key-derivation-secp256k1.ja.svg "パスフレーズ → シード → ルートキーペア → 仲介銀行（機関）キーペア → マスターキーペア")
+
+XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よりも多くの手順が含まれる理由は次のとおりです。
+
+- 32バイトの数値がすべて、有効なsecp256k1秘密鍵であるとは限りません。
+- XRP Ledgerのリファレンス実装には、単一のシード値からキーペアのファミリーを導出するための、未使用の不完全なフレームワークがあります。
+
+シード値からXRP Ledgerのsecp256k1アカウントキーペアを導出する手順は次のとおりです。
+
+1. 次のように、シード値から「ルートキーペア」を計算します。
+
+    1. 以下を順番に連結して、合計20バイトにします。
+        - シード値（16バイト）
+        - 「ルートシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。ルートシーケンスの開始値として0を使用します。
+
+    2. 連結された（シード+ルートシーケンス）値の[SHA-512ハーフ][]を計算します。
+
+    3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
+
+        有効なsecp256k1鍵は0であってはならず、 _secp256k1グループ_ の数値順よりも低くなければなりません。secp256k1グループの順序は、定数`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。
+
+    4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、ルート公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
+
+    {% admonition type="success" name="ヒント" %}バリデータではこのルートキーペアを使用します。バリデータのキーペアを計算する場合は、ここで停止できます。この2つのタイプの公開鍵を区別するには、バリデータの公開鍵の[base58][]シリアル化でプレフィクス`0x1c`を使用します。{% /admonition %}
+
+2. ルート公開鍵を33バイトの圧縮形式に変換します。
+
+    ECDSA公開鍵の非圧縮形式は、32バイト整数のペア（X座標とY座標）で構成されます。圧縮形式は、X座標と1バイトのプレフィクスのみで構成されます。Y座標が偶数の場合は`0x02`、Y座標が奇数の場合は`0x03`です。
+
+   非圧縮形式の公開鍵を圧縮形式に変換するには、`openssl`コマンドラインツールを使用します。例えば、非圧縮の公開鍵がファイル`ec-pub.pem`にある場合は、次のような圧縮形式を出力できます。
+
+    ```
+    $ openssl ec -in ec-pub.pem -pubin -text -noout -conv_form compressed
+    ```
+
+3. 次のように、圧縮されたルート公開鍵から「仲介銀行（機関）キーペア」を導出します。
+
+    1. 以下を順番に連結して、合計40バイトにします。
+        - 圧縮されたルート公開鍵（33バイト）
+        - `0x00000000000000000000000000000000`(4バイトのゼロ)（この値は、同じファミリーの異なるメンバーの導出に使用することを目的としていましたが、実際には値0のみが使用されます。）
+        - 「キーシーケンス」値（4バイト）。ビッグエンディアンの符号なし整数。キーシーケンスの開始値として0を使用します。
+
+    2. 連結された値の[SHA-512ハーフ][]を計算します。
+
+    3. 結果が有効なsecp256k1秘密鍵でない場合は、キーシーケンスを1増やし、アカウントの仲介銀行（機関）キーペアの導出をやり直します。
+
+    4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、仲介銀行（機関）公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。）
+
+4. 仲介銀行（機関）公開鍵をルート公開鍵に追加して、マスター公開鍵ペアを導出します。同様に、仲介銀行（機関）秘密鍵をルート秘密鍵に追加して秘密鍵を導出します。
+
+    - ECDSA秘密鍵は非常に大きな整数値であるため、secp256k1グループ順序を法として2つの秘密鍵を合計することで、2つの秘密鍵の合計を計算できます。
+
+    - ECDSA公開鍵は楕円曲線上の点であるため、楕円曲線の数値を使用して点の合計値を計算する必要があります。
+
+5. 以前と同様に、マスター公開鍵を33バイトの圧縮形式に変換します。
+
+6. アカウントの公開鍵を[base58][]形式にシリアル化する場合は、アカウントの公開鍵プレフィクス`0x23`を使用します。
+
+    アカウントの公開鍵からそのアドレスに変換するための情報とサンプルコードについては、[アドレスのエンコード](addresses.md#アドレスのエンコード)をご覧ください。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [発行アドレスと運用アドレス](account-types.md)
+- **チュートリアル:**
+    - [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+    - [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+- **リファレンス:**
+    - [SetRegularKeyトランザクション][]
+    - [AccountRootレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+    - [wallet_proposeメソッド][]
+    - [account_infoメソッド][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/decentralized-identifiers.md
+++ b/@l10n/ja/docs/concepts/accounts/decentralized-identifiers.md
@@ -0,0 +1,78 @@
+---
+html: decentralized-identifiers.html
+parent: accounts.html
+seo:
+    description: 分散型IDは、検証可能な分散型デジタルIDを可能にします。
+status: not_enabled
+labels:
+  - DID
+---
+# 分散型ID
+
+_([DID Amendment][] {% not-enabled /%} が必要です。)_
+
+分散型ID(DID)は、検証可能なデジタルIDを可能にするWorld Wide Web Consortium(W3C)によって定義された新しいタイプの識別子です。DIDはDID所有者の完全な管理下にあり、中央管理レジストリ、IDプロバイダ、認証局から独立しています。
+
+DIDの主な基本原則は以下の通りです。
+
+- **分散型:** 中央の発行機関がDIDを管理することがないため、所有者はDIDを更新、解決、または無効化することができます。また、DIDは通常ブロックチェーン上に保存され、常に確認が可能なため、あなたの本人確認も非常に利用しやすくなります。
+
+- **検証可能な資格情報(Verifiable Credentials):** 誰でもDIDを作成し、その情報を偽造することができます。DIDの真正性を証明するために、ユーザは暗号的に安全で改ざんできない検証可能な資格情報(Verifiable Credentials/VC)を提供しなければなりません。
+
+    DIDエコシステムには3つの当事者がいます。_ユーザ_、_発行者_、_検証者_ です。ユーザはDIDを管理しますが、オフラインで情報を検証するには信頼できる _発行者_ が必要です。_発行者_ は検証可能な資格情報を提供し、ユーザはそれをユーザの身元を確認する必要がある _検証者_ に渡します。DIDエコシステムの詳細については、こちらをご覧ください。[エコシステムの概要](https://www.w3.org/TR/vc-data-model/#ecosystem-overview)
+
+- **相互運用性:** DIDは、W3CのDID規格を認識するあらゆるソリューションに対してオープンです。つまり、DIDは様々なデジタルトランザクションやインタラクションの認証や信頼の確立に使用することができます。
+
+{% admonition type="info" name="注記" %}XRP LedgerにおけるDIDの実装は、[DID v1.0仕様](https://www.w3.org/TR/did-core/)の仕様に準拠しています。{% /admonition %}
+
+
+## 仕組み
+
+1. XRPLアカウント保有者は、アカウントによって管理されるDIDを生成します。
+2. DIDはW3C仕様で定義されたDIDドキュメントと関連付けられます。
+3. ユーザは、デジタル上のタスクのために、自分のDIDとVCを検証者に提供します。
+4. 検証者はDIDをそのドキュメントに変換し、VCを使用してその真正性を検証します。
+
+
+## DIDドキュメント
+
+DIDドキュメントには、記述された対象の身元を暗号的に検証するために必要な情報が含まれます。サブジェクトは、人、組織、または物であってもかまいません。たとえば、DIDドキュメントには、DIDサブジェクトが自身を認証し、DIDの関連を証明するために使用できる暗号化公開鍵を含めることができます。
+
+{% admonition type="info" name="Note" %}DIDドキュメントは通常、JSONまたはJSON-LDのフォーマットにシリアライズされます。{% /admonition %}
+
+XRP Ledgerでは、DIDをDIDドキュメントに関連付ける方法がいくつか存在します。
+
+1. IPFSやSTORJのような他の分散ストレージネットワークに保存されているドキュメントを指す`DID`オブジェクトの`URI`フィールドにドキュメントへの参照を保存します。
+2. 最小限のDIDドキュメントを`DID`オブジェクトの`DIDDocument`フィールドに格納します。
+3. DIDとその他の利用可能な公開情報から生成された最小限の _暗黙的な_ DIDドキュメントを使用します。
+    {% admonition type="info" name="注記" %}より単純なユースケースでは、署名と単純な認証トークンのみが必要な場合があります。レジャー上に明示的にDIDドキュメントが存在しない場合、代わりに暗黙的なドキュメントが使用されます。たとえば、`did:xrpl:1：0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020`の暗黙のDIDドキュメントでは、単一のキー`0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020`だけでDIDドキュメントの変更を承認したり、DIDの名前で署名に署名したりできます。{% /admonition %}
+
+
+### XRPL DIDドキュメントの例
+
+```json
+{
+    "@context": "https://w3id.org/did/v1",
+    "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+    "publicKey": [
+        {
+            "id": "did:xrpl:1:rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn#keys-1",
+            "type": ["CryptographicKey", "EcdsaKoblitzPublicKey"],
+            "curve": "secp256k1",
+            "expires": 15674657,
+            "publicKeyHex": "04f42987b7faee8b95e2c3a3345224f00e00dfc67ba882..."
+        }
+    ]
+}
+```
+
+DIDドキュメントの主要なプロパティの詳細については[Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/#core-properties)をご覧ください。
+
+
+## プライバシーとセキュリティの懸念
+
+- XRPLアカウントの秘密鍵を管理する人は誰でも、DIDとそれが解決するDIDドキュメントへの参照を管理します。秘密鍵が漏洩しないように注意してください。
+- DIDドキュメントにはどのような内容でも含めることができますが、検証方法とサービスポイントに限定すべきです。XRPL上のDIDは公開情報であるので、個人情報を含めるべきではありません。
+- IPFSは誰でも分散ネットワークのノードにコンテンツを保存できます。よくある誤解は、誰でもそのコンテンツを編集できるということです。しかし、IPFSのコンテンツアドレス指定可能性は、編集されたコンテンツがオリジナルとは異なるアドレスを持つことを意味します。どんなエンティティでもXRPLアカウントの`DIDDocument`または`URI`フィールドでアンカーされたDIDドキュメントをコピーすることはできますが、対応する`DID`オブジェクトを作成した秘密鍵をコントロールしない限り、ドキュメント自体を変更することはできません。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/deleting-accounts.md
+++ b/@l10n/ja/docs/concepts/accounts/deleting-accounts.md
@@ -0,0 +1,40 @@
+---
+html: deleting-accounts.html
+parent: accounts.html
+seo:
+    description: XRP Ledgerのアカウントの削除について。
+labels:
+  - アカウント
+---
+# アカウントの削除
+
+アカウントの所有者は[AccountDeleteトランザクション][]を送信することで、レジャーからアカウントと関連するエントリを削除し、アカウントの残りのXRP残高のほとんどを別のアカウントに送ることができます。アカウントの無駄な作成と削除を抑止するため、アカウントの削除には[トランザクションコスト](../transactions/transaction-cost.md)として通常よりも多くのXRPをバーンする必要があります。
+
+いくつかの種類のレジャーエントリを保有している場合、アカウントの削除がブロックされます。たとえば、(代替可能)トークンの発行者は、そのトークンの発行残高がゼロでなければ、削除することはできません。
+アカウントは削除した後、通常の[アカウントの作成方法](index.md#creating-accounts)によって再作成できます。削除後に再作成されたアカウントと、初めて作成されたアカウントに違いはありません。
+
+
+
+## 要件
+
+アカウントを削除するには、次の条件を満たす必要があります。
+
+- アカウントの`Sequence`番号に256を加えた値が、現在の[レジャーインデックス][]未満であること。
+- アカウントが次の[レジャーエントリ](../../references/protocol/ledger-data/ledger-entry-types/index.md)のいずれも(送金元または受取人として)保有していないこと。
+    - `Escrow`
+    - `PayChannel`
+    - `RippleState`
+    - `Check`
+- アカウントがレジャー内に所有するオブジェクトが1000個未満であること。
+- トランザクションの送信時、少なくとも1つ分の[所有者準備金](reserves.md)(現在2XRP)に相当する特別な[トランザクションコスト][]を支払う必要があります。
+
+
+## 削除コスト
+
+{% admonition type="warning" name="注意" %}アカウントの削除要件を満たしていないためにトランザクションが失敗した場合でも、[AccountDeleteトランザクション][]のトランザクションコストは、トランザクションが検証済みレジャーに含まれる場合常に発生します。アカウントを削除できなかった場合に高いトランザクションコストを支払う可能性を減らすには、AccountDeleteトランザクションを送信するときに`fail_hard`オプションを使用してください。{% /admonition %}
+
+ビットコインや他の多くの暗号通貨とは異なり、XRP Ledgerの公開レジャーチェーンのそれぞれの新しいレジャーバージョンは、レジャーの完全な状態を含んでおり、新しいアカウントが増えるごとにサイズが増加します。そのため、必要な場合を除き、新しいXRP Ledgerアカウントを作成すべきではありません。アカウントを削除することで、アカウントの10XRPの[準備金](reserves.md)の一部を回復することができますが、そのためには少なくとも2XRPを破棄する必要があります。
+
+取引所など、多くのユーザのために価値の送受信を行う組織は、[**送信元タグ**と**宛先タグ**](../transactions/source-and-destination-tags.md)を使用することで、XRP Ledgerのアカウントを1つだけ(または少数)使用するだけで、ユーザの支払いを区別することができます。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/depositauth.md
+++ b/@l10n/ja/docs/concepts/accounts/depositauth.md
@@ -0,0 +1,123 @@
+---
+html: depositauth.html
+parent: accounts.html
+seo:
+    description: DepositAuth設定をすると、アカウントは着信ペイメントをデフォルトでブロックします。
+labels:
+  - セキュリティ
+  - 支払い
+outdated_translation: true　
+---
+# Deposit Authorization
+
+_（[DepositAuth Amendment][]により追加されました。）_
+
+Deposit Authorizationは、XRP Ledgerの[アカウント](index.md)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。Deposit Authorizationのアカウントは、次の2つの方法でのみ入金することができます。
+
+- [事前承認](#事前承認)されたアカウントから。
+- トランザクションを送信して資金を受け取ることにより。例えば、Deposit Authorizationが設定されたアカウントは、他のアカウントによって開始された[エスクロー](../payment-types/escrow.md)を完了することができます。
+
+デフォルトでは、新しいアカウントではDepositAuthが無効になっています。
+
+## 背景
+
+金融サービスの規制やライセンスによっては、企業や組織に対して、受領するすべてのトランザクションの送信者を把握するよう義務付けています。これは、自由に生成できる偽名で参加者を識別し、デフォルトですべてのアドレスからあらゆる宛先への支払いを可能とするXRP Ledgerのような分散型システムとっては課題となります。
+
+Deposit Authorizationフラグにより、XRP Ledgerを使用するユーザが分散型レジャーの基本的な特性を変えずにこのような規制に準拠するためのオプションを採用しました。Deposit Authorizationが有効な場合、アカウントはトランザクションを送信することで明示的に承認した資金のみを受領できます。Deposit Authorizationを使用するアカウントの所有者は、アカウントに資金を入金するトランザクションを送信する _前に_ 、資金の送金元の確認に必要なデューディリジェンス（確認調査）を実施できます。
+
+Deposit Authorizationを有効にすると、[Checks](/resources/known-amendments.md#checks)、[Escrow](../payment-types/escrow.md)、および[Payment Channel](/resources/known-amendments.md#paychan)から資金を受領できます。このような「二段階」トランザクションモデルでは、最初に送金元は資金の送金を承認するトランザクションを送信し、次に送金先は資金受領を承認するトランザクションを送信します。
+
+Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。_（[DepositPreauth Amendment][]により追加されました。）_
+
+## 推奨される使い方
+
+Deposit Authorizationを最大限に活用するため、以下の実施を推奨します。
+
+- XRP残高が常に最低[必要準備金](reserves.md)を上回るようにする。
+- DefaultRippleフラグをデフォルトの状態（無効）にしておく。トラストラインに対して[Rippling](../tokens/fungible-tokens/rippling.md)を有効にしない。TrustSetトランザクションを送信するときには常に[`tfSetNoRipple`フラグ](../../references/protocol/transactions/types/trustset.md)を使用する。
+- [オファー](../../references/protocol/transactions/types/offercreate.md)を行わない。このようなトランザクションの実行にあたり、消費される一致オファーを事前に把握することは不可能です。
+
+## 詳細なセマンティクス
+
+Deposit Authorizationが有効化されているアカウントの特徴は次のとおりです。
+
+- [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
+    - 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。_（[DepositPreauth Amendment][]により追加されました。）_
+    - アカウントのXRP残高がアカウントの最低[必要準備金](reserves.md)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では10XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
+- **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
+    - PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
+    - PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]により追加されました。）_
+- **以下に該当する場合にのみ**[EscrowFinishトランザクション][]からXRPを受領できます。
+    - EscrowFinishトランザクションの送金元がEscrowの送金先である場合。
+    - EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]により追加されました。）_
+- [CheckCash][]トランザクションを送信してXRPまたはトークンを受領**できます**。 _（[Checks Amendment][]により追加されました。）_
+- [OfferCreateトランザクション][]を送信してXRPまたはトークンを受領**できます**。
+    - 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPとトークンのリマインダーを受信する**ことがあります**。
+- アカウントが[NoRippleフラグ](../tokens/fungible-tokens/rippling.md)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインのトークンを受領**できます**。このようなトランザクションの送金先にすることはできません。
+- 一般的に、以下のすべての条件に該当する場合は、XRP LedgerのアカウントはXRP LedgerでXRP以外の通貨を受領**できません**。（このルールは、DepositAuthフラグに特有のものではありません。）
+    - アカウントにより、ゼロ以外の限度を指定したトラストラインが作成されていない。
+    - アカウントが、その他のアカウントにより作成されたトラストラインで通貨を発行していない。
+    - アカウントがまだオファーを出していない。
+
+以下の表に、トランザクションタイプ別にDepositAuthが有効または無効な状態での入金の可否をまとめました。
+
+<!-- TODO: translate -->
+<!-- {% partial file="/@l10n/ja/docs/_snippets/depositauth-semantics-table.md" /%} -->
+
+{% partial file="/docs/_snippets/depositauth-semantics-table.md" /%}
+
+
+
+## Deposit Authorizationの有効化または無効化
+
+アカウントのDeposit Authorizationを有効にするには、`SetFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。アカウントのDeposit Authorizationを無効にするには、`ClearFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。AccountSetフラグについての詳細は、[AccountSetフラグ](../../references/protocol/transactions/types/accountset.md)をご覧ください。
+
+## AccountのDepositAuthの有効化の確認
+
+アカウントのDeposit Authorizationの有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)と比較します。
+
+`Flags`値と`lsfDepositAuth`フラグ値（0x01000000）のビット単位のANDの結果がゼロ以外の場合、アカウントではDepositAuthが有効になっています。結果がゼロの場合、アカウントではDepositAuthが無効になっています。
+
+## 事前承認
+
+_（[DepositPreauth Amendment][]により追加されました。）_
+
+DepositAuthが有効なアカウントは、特定の送金元を _事前承認_ することにより、DepositAuthが有効になっていても、これらの送金元からの支払を受領することができます。これにより、特定の送金元からの資金の直接送金が可能となり、受取人はトランザクションごとに個別にアクションを実行する必要がなくなります。事前承認はDepositAuthの使用にあたり必須の要件ではありませんが、事前承認により特定の操作を実行しやすくなります。
+
+事前承認は通貨に依存しません。特定の通貨のみについてアカウントを事前承認することはできません。
+
+特定の送金元を事前承認するには、`Authorize`フィールドに事前承認する別のアカウントのアドレスを指定した[DepositPreauthトランザクション][]を送信します。事前承認を取り消すには、当該アカウントのアドレスを`Unauthorize`フィールドに指定します。通常どおり、`Account`フィールドには自分自身のアドレスを指定します。現在DepositAuthを有効にしていない場合でも、アカウントを事前承認または承認解除できます。他のアカウントに設定した事前認証ステータスは保存されますが、DepositAuthを有効にしない限り、このステータスの影響はありません。アカウントがアカウント自体を事前認証することはできません。事前認証は一方向であり、反対方向の支払には影響しません。
+
+別のアカウントを事前認証すると、レジャーに[DepositPreauthオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md)が追加されます。これにより、認証を提供するアカウントの[所有者準備金](reserves.md#所有者準備金)が増加します。アカウントで事前承認が取り消されると、オブジェクトが削除され、準備金はこれに伴い減少します。
+
+DepositPreauthトランザクションの処理が完了すると、承認済みアカウントからあなたのアカウントに資金を送金できるようになります。これは、以下のトランザクションタイプのいずれかを使用してDepositAuthを有効にしている場合にも該当します。
+
+- [Payment][]
+- [EscrowFinish][]
+- [PaymentChannelClaim][]
+
+事前承認は、DepositAuthが有効なアカウントへのその他の送金方法には影響しません。詳しいルールについては、[詳細なセマンティクス](#詳細なセマンティクス)をご覧ください。
+
+### 承認の確認
+
+[deposit_authorizedメソッド][]を使用して、特定のアカウントに対し別のアカウントへの入金が許可されているかどうかを確認できます。このメソッドは次の2点を確認します。
+
+- 送金先アカウントがDeposit Authorizationを必要としているかどうか。（承認を必要としていない場合は、すべての送金元アカウントが承認済みとみなされます。）
+- 送金元アカウントに対し、送金先への送金が事前承認されているかどうか。
+
+
+## 関連項目
+
+- [DepositPreauthトランザクション][]リファレンス。
+- [DepositPreauthレジャーオブジェクトタイプ](../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md)。
+- [`rippled` API](../../references/http-websocket-apis/index.md)の[deposit_authorizedメソッド][]。
+- [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
+- `DisallowXRP`フラグは、アカウントがXRPを受領してはならないことを示します。これはDeposit Authorizationよりもソフトな保護機能であり、XRP Ledgerにより強制されません。（クライアントアプリケーションはこのフラグに従うか、または少なくともこのフラグについて警告します。）
+- 送信トランザクションが[Destinationタグ](../transactions/source-and-destination-tags.md)を指定している場合には、`RequireDest`フラグは、アカウントが通貨額のみを受領できることを示します。これにより、ユーザが支払の目的を指定し忘れることがなくなりますが、恣意的な送金先タグを作成できる不明な送金元から受取人が保護されるわけではありません。
+- [Partial Payment](../payment-types/partial-payments.md)により、アカウントは不要な支払を返金できます。この際、[送金手数料](../tokens/transfer-fees.md)と為替レートは送金額には追加されず、送金された金額から差し引かれます。
+<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
+
+
+[DepositPreauth Amendment]: /resources/known-amendments.md#depositpreauth
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/index.md
+++ b/@l10n/ja/docs/concepts/accounts/index.md
@@ -0,0 +1,69 @@
+---
+html: accounts.html
+parent: concepts.html
+seo:
+    description: XRP Ledgerのアカウントについて説明します。アカウントはトランザクションを送信でき、XRPを保有できます。
+labels:
+  - アカウント
+  - 支払い
+---
+# アカウント
+
+XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクション]アカウントの主な要素は次のとおりです。
+
+アカウントは、アドレス、XRPの残高、シーケンス番号、トランザクション履歴から構成されます。トランザクションを送信するためには、所有者はアカウントに紐付く1つ以上の暗号鍵ペアを必要とします。
+
+
+## アカウントの構成
+
+アカウントの種等な構成要素は次の通りです。
+
+- 識別用の**アドレス**。例えば、`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`。
+- **XRPの残高**。XRP残高の一部は、[準備金](reserves.md)用に確保されています。
+- **シーケンス番号**。このアカウントから送信されるトランザクションがすべて、正しい順序で、それぞれ1回のみ適用されるようにします。トランザクションを実行するには、トランザクションのシーケンス番号と送金元のシーケンス番号が一致する必要があります。その後も、トランザクションが適用されている限り、アカウントのシーケンス番号は1ずつ増加します。（関連項目: [基本的なデータタイプ: アカウントシーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)）
+- このアカウントと残高に影響を及ぼした**トランザクションの履歴**。
+- [トランザクションの承認](../transactions/index.md#トランザクションの承認)方法。
+    - アカウント固有のマスターキーのペア。（無効にできますが、変更はできません。）
+    - ローテーションして使用できる「レギュラー」キーペア。
+    - [マルチシグ](multi-signing.md)の署名者のリスト。(アカウントのコアデータとは別に保存されます。)
+
+アカウントのコアデータは、[AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)レジャーエントリに保存されます。アカウントは、他の複数のタイプのレジャーエントリの所有者(または部分的な所有者)になることもできます。
+
+{% admonition type="success" name="ヒント" %}XRP Ledgerの「アカウント」は、財務上の用途（例:「銀行口座」）やコンピュータ上の用途（例:「UNIXアカウント」）で使用されます。XRP以外の通貨および資産はXRP Ledgerアカウント自体には保存されません。そのような資産はそれぞれ、両当事者を結ぶ「トラストライン」と呼ばれる会計関係に保存されます。{% /admonition %}
+
+
+### アカウントの作成
+
+「アカウント作成」専用のトランザクションはありません。Paymentトランザクションでまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.md)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントへの _資金提供_ と呼ばれ、レジャーに[AccountRootエントリ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
+
+{% admonition type="warning" name="注意" %}アカウントへ資金提供をすることは、そのアカウントに対して特別な権限を持つことには**なりません**。アカウントのアドレスに対応する秘密鍵を持っている人なら誰でも、アカウントとそれに含まれるすべてのXRPの完全制御権を持っています。一部のアドレスでは、誰も秘密鍵を持っていない場合があります。その場合、アカウントは[ブラックホール](addresses.md#特別なアドレス)になり、XRPは永久に失われます。{% /admonition %}
+
+XRP Ledgerでアカウントを取得する一般的な方法は次のとおりです。
+
+1. ランダム性の強いソースからキーペアを生成し、そのキーペアのアドレスを計算します。（例えば、[wallet_proposeメソッド][]を使用して計算することができます。）
+
+2. XRP Ledgerにアカウントをすでに持っているユーザに、生成したアドレスにXRPを送信してもらいます。
+
+    - 例えば、一般的な取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを出金することができます。
+
+        {% admonition type="warning" name="注意" %}自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.md)（現在は10XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。{% /admonition %}
+
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [準備金](reserves.md)
+    - [暗号鍵](cryptographic-keys.md)
+   - [発行アドレスと運用アドレス](account-types.md)
+- **リファレンス:**
+    - [account_infoメソッド][]
+    - [wallet_proposeメソッド][]
+   - [AccountSetトランザクション][]
+    - [Paymentトランザクション][]
+  - [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+- **チュートリアル:**
+    - [アカウント設定の管理（カテゴリ）](../../tutorials/how-tos/manage-account-settings/index.md)
+    - [WebSocketを使用した着信ペイメントの監視](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/multi-signing.md
+++ b/@l10n/ja/docs/concepts/accounts/multi-signing.md
@@ -0,0 +1,86 @@
+---
+html: multi-signing.html
+parent: accounts.html
+seo:
+    description: マルチシグを使用することで、トランザクション送信時のセキュリティが強化されます。
+labels:
+  - スマートコントラクト
+  - セキュリティ
+---
+# マルチシグ
+
+マルチシグは、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](../transactions/index.md#トランザクションの承認)手法です。アドレスで有効な承認手法（マルチシグ、[マスターキーペア](cryptographic-keys.md#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.md#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
+
+マルチシグには次のメリットがあります。
+
+* 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
+* 複数のユーザ間で1つのアドレスの管理を共有できます。この場合、各ユーザが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
+* あなたのアドレスからトランザクションを送信できる権限を、複数ユーザのグループに委任できます。委任を受けた各ユーザは、あなたが通常の方法で署名できない場合にあなたのアドレスを制御できます。
+* その他のメリットもあります。
+
+## 署名者リスト
+
+マルチシグを使用するには、あなたの代理として署名できるアドレスのリストを作成する必要があります。
+
+[SignerListSetトランザクション][]は、_署名者リスト_（自分のアドレスからのトランザクションを承認できるアドレスのセット）を定義します。署名者リストには、1～32のアドレスを含めることができます。このリストには、自分のアドレスを含めることはできず、重複して登録することはできません。リストの _Signer Weight_ と _Quorum_ の設定を使用することで、どのような組み合わせでどれだけの署名が必要かを制御することができます。
+
+_([ExpandedSignerList amendment][]により更新されました。)_
+
+### Signer Weight
+
+リスト内の各署名者にウェイトを割り当てます。ウェイトは、リスト上の他の署名者と比較して、その署名者の相対的な権限を表します。値が高いほど、より多くの権限を持つことになります。個々のウェイト値は、2<sup>16</sup>-1を超えることはできません。
+
+### Quorum
+
+リストの定足数(quorum)の値は、トランザクションを承認するために必要な最小のウェイト合計です。クォーラムは0より大きく、署名者リストのウェイト値の合計以下でなければならない。つまり、与えられた署名者のウェイトでクォーラムを達成することが可能でなければなりません。
+
+### Wallet Locator
+
+また、リスト内の各署名者のエントリに最大256ビットの任意のデータを追加することができます。このデータはネットワークで必要とされたり使用されたりすることはありませんが、スマートコントラクトや他のアプリケーションが署名者に関する他のデータを特定したり確認したりするために使用することができます。
+
+_([ExpandedSignerList amendment][]により追加されました。)_
+
+### Signer WeightとQuorumの使用例
+
+ウェイトと定足数により、アカウントを管理する責任ある参加者への相対的な信頼と権限に基づき、トランザクションごとに適切なレベルの監視を設定することができます。
+
+共有アカウントのユースケースの場合、定足数1のリストを作成し、すべての参加者に1のウェイトを与えることができます。
+
+非常に重要なアカウントの場合、定足数を3に設定し、重みを1とする3人の参加者を設定することができます。すべての参加者がトランザクションごとに同意して承認する必要があります。
+
+CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人のウェイトを各1に割り当てたとする。このアカウントのトランザクションを承認するには、取締役3名全員（合計ウェイト3）、副社長1名と取締役1名（合計ウェイト3）、副社長2名（合計ウェイト4）、またはCEO（合計ウェイト3）の承認が必要となります。
+
+先の3つのユースケースでは、レギュラーキーを設定せずにマスターキーを無効にすることで、マルチシグが唯一の[トランザクションの承認](../transactions/index.md#トランザクションの承認)の方法となるようにします。
+
+"バックアッププラン"としてマルチシグリストを作成するシナリオがあるかもしれません。アカウント所有者は、通常、トランザクションにレギュラーキー(マルチシグではない)を使用します。もしアカウント所有者が秘密鍵を紛失した場合、通常の鍵に代わるトランザクションにマルチシグするよう友人に依頼することができます。
+
+## マルチシグトランザクションの送信
+
+マルチシグトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
+
+* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を所有する必要があります。この方法については、[マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)をご覧ください。
+* トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
+* トランザクションに、署名の配列が指定されている[`Signers`フィールド](../../references/protocol/transactions/common-fields.md#signersフィールド)を含める必要があります。
+* `Signers`配列に含まれている署名は、`SignerList`で定義されている署名と一致している必要があります。
+* 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、`SignerList`の`quorum`以上である必要があります。
+* [トランザクションコスト](../transactions/transaction-cost.md)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
+* トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](../../references/protocol/transactions/common-fields.md#自動入力可能なフィールド)は実行できません。
+* `Signers`配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][]がこの処理を自動的に実行します。）
+
+詳細は、[マルチシグの設定](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)をご覧ください。
+
+## 関連項目
+
+- **チュートリアル:**
+    - [マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
+    - [マルチシグトランザクションを送信する](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
+- **コンセプト:**
+    - [暗号鍵](cryptographic-keys.md)
+    - [マルチシグトランザクションの特別なトランザクションコスト](../transactions/transaction-cost.md#特別なトランザクションコスト)
+- **リファレンス:**
+    - [SignerListSetトランザクション][]
+    - [SignerListオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)
+    - [sign_forメソッド][]
+    - [submit_multisignedメソッド][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/reserves.md
+++ b/@l10n/ja/docs/concepts/accounts/reserves.md
@@ -0,0 +1,81 @@
+---
+html: reserves.html
+parent: accounts.html
+seo:
+    description: XRP Ledgerのアカウントでは、レジャーデータ内のスパムを減らすためにXRPの準備金が必要です。
+labels:
+  - 手数料
+  - アカウント
+top_nav_grouping: 人気ページ
+---
+# 準備金
+
+XRP Ledgerでは、スパムや悪意のある使用によって、共有グローバル台帳(レジャー)が過度に大きくならないように、XRPを用いた _準備金_ の仕組みを採用しています。現在一般に市販されているのマシンで、処理中の現行レジャーを常にRAMに保存でき、全履歴がディスクに収まるように、技術の向上に合わせて台帳サイズが大きくなるのを制限することが目的です。
+
+取引(トランザクション)を送信するには、各アドレスが共有グローバル台帳内に少量のXRPを保有している必要があります。このXRPを他のアドレスに送信することはできません。新しいアドレスに資金供給するには、必要となる準備金を満たすのに十分なXRPを送信する必要があります。
+
+準備金要件は、バリデータが新しい準備金設定に合意する[手数料の投票](../consensus-protocol/fee-voting.md)プロセスにより、随時変更されます。
+
+## 基本準備金と所有者準備金
+
+準備金は2つの部分に分けられます。
+
+* **基本準備金**は、レジャーの各アドレスに必要なXRPの最小額です。
+* **所有者準備金**は、アドレスがレジャーに所有しているオブジェクトごとに必要な準備金の増加額です。アイテムごとのコストは「増分準備金」とも呼ばれます。
+
+メインネットにおける現在の準備金要件は次の通りです。
+
+- 基本準備金 **10 XRP**
+- 所有者準備金 アイテムにつき**2 XRP**
+
+他のネットワークでの準備金は異なる場合があります。
+
+### 所有者準備金
+
+レジャー内の多くのオブジェクト(レジャーエントリ)は、特定のアカウントが所有しています。通常、所有者はオブジェクトを作成したアカウントです。各オブジェクトは、所有者の合計必要準備金を所有者準備金によって増加させます。オブジェクトがレジャーから削除されると、所有者の必要準備金にカウントされなくなります。
+
+所有者の必要準備金にカウントされるオブジェクトには次のものが含まれます。[Check](../payment-types/checks.md), [入金の事前承認](depositauth.md#事前承認), [エスクロー](../payment-types/escrow.md), [NFTのオファー](../tokens/nfts/trading.md), [NFTのページ](../tokens/nfts/index.md), [オファー](../../references/protocol/ledger-data/ledger-entry-types/offer.md), [ペイメントチャネル](../payment-types/payment-channels.md), [マルチシグの署名者リスト](multi-signing.md), [Ticket](tickets.md), そして[トラストライン](../tokens/fungible-tokens/index.md).
+
+次のようないくつかの特殊なケースが存在します。
+
+- 非代替性トークン(NFT)は、それぞれ最大32個のNFTを含むページにグループ化され、所有者準備金はNFTごとではなくページごとに適用されます。ページの分割と結合の仕組みにより、実際に保存されるNFTの数はページごとに異なります。[NFTokenPageオブジェクトの準備金](../../references/protocol/ledger-data/ledger-entry-types/nftokenpage.md#nftokenpage-オブジェクトの準備金)もご覧ください。
+- トラストライン(`RippleState`エントリ)は2つのアカウント間で共有されます。所有者準備金はどちらか一方、または両方に適用できます。多くの場合、トークン所有者は準備金を負担し、発行者は負担しません。[RippleState: 所有者準備金への資金提供](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#所有者の準備金への資金供給)もご覧ください。
+- 2019年4月に有効化された[MultiSignReserve amendment][]以前に作成された署名者リストは、複数のオブジェクトとしてカウントされます。[署名者リストと準備金](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md#signerlistと準備金)もご覧ください。
+- [所有者ディレクトリ](../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)は、アカウントが所有するすべてのオブジェクトを含む、アカウントに関連するすべてのオブジェクトをリストしたレジャーエントリです。ただし、所有者ディレクトリ自体は準備金にカウントされません。
+
+### 準備金の確認
+
+アプリケーションは、[server_infoメソッド][]または[server_stateメソッド][]を使用して、現在の基本準備金と増分準備金の値を調べることができます。
+
+| メソッド                 | 単位          | 基本準備金のフィールド                  | 増分準備金のフィールド                |
+|-------------------------|--------------|-------------------------------------|------------------------------------|
+| [server_infoメソッド][]  | 10進数のXRP値  | `validated_ledger.reserve_base_xrp` | `validated_ledger.reserve_inc_xrp` |
+| [server_stateメソッド][] | 整数のdrop値   | `validated_ledger.reserve_base`     | `validated_ledger.reserve_inc`     |
+
+アカウントの所有者準備金を決定するには、増分準備金にアカウントが所有するオブジェクトの数を掛けます。アカウントが所有しているオブジェクトの数を調べるには、[account_infoメソッド][]を呼び出し、`account_data.OwnerCount`を取得します。
+
+アドレスの必要となる合計準備金を計算するには、`OwnerCount`に`reserve_inc_xrp`を掛け、次に`reserve_base_xrp`を加えます。[この計算をPythonで行うデモ](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#codeblock-17)があります。
+
+
+## 必要準備金を下回る
+
+トランザクション処理中、[トランザクションコスト](../transactions/transaction-cost.md)によって、送信元アドレスのXRP残高の一部がバーンされます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
+
+アドレスが保持しているXRPが、現在の必要準備金を下回ると、XRPを他のアドレスに送信するトランザクションを送信したり、自身の準備金を増やしたりできなくなります。このような場合でも、そのアドレスはレジャー内に存在し、トランザクションコストを支払うのに十分なXRPを持っている限り、その他のトランザクションを送信することができます。必要準備金を満たすために十分なXRPを受け取った場合、またはそのアドレスのXRP保有額よりも[準備金の必要額が減少した](#準備金要件の変更)場合、そのアドレスはすべてのタイプのトランザクションを再度送信できるようになります。
+
+{% admonition type="success" name="ヒント" %}アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)や[レジャー内のオファーエントリ](../../references/protocol/ledger-data/ledger-entry-types/offer.md)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。{% /admonition %}
+
+
+## 準備金要件の変更
+
+XRP Ledgerには、準備金要件を調整する仕組みがあります。このような調整は、例えばXRPの価値の長期的な変化、汎用レベルのハードウェアの性能の向上、サーバソフトウェアの実装の効率化などを考慮することができます。いかなる変更も、コンセンサスプロセスによる合意が必要です。詳細は[手数料の投票](../consensus-protocol/fee-voting.md)をご覧ください。
+
+## 関連項目
+
+- [account_objectsメソッド][]
+- [AccountRootオブジェクト][]
+- [手数料の投票](../consensus-protocol/fee-voting.md)
+- [SetFee疑似トランザクション][]疑似トランザクション
+- [チュートリアル: 必要準備金の計算と表示（Python）](../../tutorials/python/build-apps/build-a-desktop-wallet-in-python.md#3-display-an-account)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/accounts/tickets.md
+++ b/@l10n/ja/docs/concepts/accounts/tickets.md
@@ -0,0 +1,73 @@
+---
+html: tickets.html
+parent: accounts.html
+seo:
+    description: トランザクションを非連続的な順序で送信する
+labels:
+  - アカウント
+  - トランザクション送信
+---
+# Ticket
+
+_([TicketBatch amendment][]により追加されました。)_
+
+XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][Sequence Number]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.md)などが挙げられます。
+
+## 背景
+
+[トランザクション](../transactions/index.md)にはシーケンス番号が付いているので、任意のトランザクションを2回以上実行することはできません。シーケンス番号はまた、任意のトランザクションが一意であることを保証します。全く同じ金額を同じ人に複数回送信する場合、シーケンス番号は毎回異なることが保証される1つの詳細です。最後に、シーケンス番号は、ネットワーク全体に送信される際に一部のトランザクションが順不同で届いたとしても、トランザクションを一貫した順序で並べるためのエレガントな方法を提供します。
+
+しかし、シーケンス番号では限界がある場合もあります。たとえば、次のような場合です。
+
+- 2人以上のユーザがアカウントへのアクセスを共有し、それぞれが独立してトランザクションを送信することができる状態。これらのユーザが事前に調整することなく同時期に取引を送信しようとすると、それぞれが同じシーケンス番号を異なる取引に使用しようとする可能性があり、成功するのは1人だけです。
+- トランザクションを事前に準備して署名し、安全な場所に保存しておいて、特定のイベントが発生したときにいつでも実行できるようにしておきたい場合があります。しかし、その間も通常通りにアカウントを使用したい場合、準備しておくトランザクションに使用するシーケンス番号がわかりません。 <!-- STYLE_OVERRIDE: will -->
+- トランザクションを有効にするために[複数人が署名しなければならない](multi-signing.md)場合、一度に複数のトランザクションを計画するのは難しいでしょう。トランザクションに別々のシーケンス番号をつけると、全員が前のトランザクションに署名するまで、後の番号のトランザクションを送信することができません。しかし、保留中のトランザクションに同じシーケンス番号を使用すると、1つのトランザクションのみ成功します。
+
+チケットでは、これらの問題を解決するために、通常の順番とは別に、後からでも（ただし、それぞれ1回まで）使用可能なシーケンス番号を用意しています。
+
+
+## チケットは予約済みのシーケンス番号
+
+チケットとは、あるシーケンス番号が後に使用されるために確保されたという記録です。アカウントは、まず[TicketCreate トランザクション][]を送信して、1つまたは複数のシーケンス番号をチケットとして確保します。これにより、[台帳の状態データ](../ledgers/index.md)に、予約された各シーケンス番号について[Ticket オブジェクト][]の形で記録が残されます。
+
+チケットには、チケット作成時に設定されたシーケンス番号が使用されます。例えば、あなたのアカウントの現在のシーケンス番号が101で、3枚のチケットを作成した場合、それらのチケットにはチケットシーケンス番号102、103、104が付けられます。これにより、あなたのアカウントのシーケンス番号は105になります。
+
+[{% inline-svg file="/docs/img/ticket-creation.ja.svg" /%}](/docs/img/ticket-creation.ja.svg "図: 3つのTicketの作成")
+
+後から、シーケンス番号の代わりに特定のチケットを使用してトランザクションを送信することができます。これにより、元帳の状態データから対応するチケットが削除され、アカウントの通常のシーケンス番号は変更されません。また、チケットを使用せずに、通常のシーケンス番号を使用してトランザクションを送信することもできます。利用可能なチケットは、いつでもどのような順番でも使用できますが、各チケットは1回しか使用できません。
+
+[{% inline-svg file="/docs/img/ticket-usage.ja.svg" /%}](/docs/img/ticket-usage.ja.svg "図: 103のTicketを利用")
+
+上記の例では、シーケンス番号105または作成した3つのチケットのいずれかを使用してトランザクションを送信できます。チケット103を使ってトランザクションを送信すると、それによってチケット103は元帳から削除されます。その後の次のトランザクションでは、シーケンス番号105、チケット102、またはチケット104を使用できます。
+
+{% admonition type="warning" name="注意" %}チケットは1枚ごとに[所有者準備金](reserves.md#所有者準備金)としてカウントされますので、チケット1枚につき2XRPを確保する必要があります。 (このXRPは、チケットを使用した後に再び使用可能になります）一度に多くのチケットを作成すると、このコストはすぐに膨れ上がります。{% /admonition %}
+
+シーケンス番号と同様に、トランザクションの送信は、そのトランザクションが[コンセンサス](../consensus-protocol/index.md)によって確認された場合にのみ、チケットを使用します。しかし、意図した通りにならなかった取引でも、[`tec`クラスの結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を用いてコンセンサスで確認することができます。
+
+あるアカウントで利用可能なチケットを調べるには、[account_objects メソッド][]を使用します。
+
+## 制約事項
+
+どのアカウントでも、どのような種類の取引でもチケットを作成し、使用することができます。ただし、いくつかの制限があります。
+
+- 各チケットは一度しか使用できません。同じチケットシーケンスを使用する複数の異なるトランザクション候補があることは可能ですが、コンセンサスで検証できるのはそのうちの1つだけです。
+- 各アカウントでは、一度に250枚以上のチケットをレジャーに登録することはできません。また、一度に250枚以上のチケットを作成することもできません。
+- チケットを使って別のチケットを作ることは _できます_。その場合、使用したチケットは、一度に所持できるチケットの合計数にはカウントされません。
+- 各チケットは[所有者準備金](reserves.md#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき2XRPを確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
+- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでTicketを使用する複数のトランザクションを持つ場合、それらのTicketは最も低いTicket Sequenceから最も高いTicket Sequenceの順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントをご覧ください)。
+- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでチケットを使用する複数のトランザクションを持つ場合、それらのチケットは最も低いチケット シーケンス番号から最も高いチケット シーケンス番号の順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントをご覧ください)。
+
+## 関連項目
+
+
+- **Concepts:**
+    - [マルチシグ](multi-signing.md)
+- **Tutorials:**
+    - [チケットを使用する](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
+- **References:**
+    - [TicketCreate トランザクション][]
+    - [トランザクションの共通フィールド](../../references/protocol/transactions/common-fields.md)
+    - [Ticket オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ticket.md)
+    - [account_objects メソッド][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-principles-and-rules.md
@@ -0,0 +1,112 @@
+---
+html: consensus-principles-and-rules.html
+parent: consensus.html
+seo:
+    description: XRP Ledgerは世界規模の決済システムで、ユーザはメールを送るときのようにスムーズに国境を越えて送金することができます。
+labels:
+  - ブロックチェーン
+---
+# コンセンサスの原理とルール
+
+XRP Ledgerは世界規模の決済システムで、ユーザはメールを送るときのようにスムーズに国境を越えて送金することができます。Bitcoinなどの他のピアツーピア決済ネットワークと同様に、XRP Ledgerでは分散型コンピュータネットワークを介したピアツーピア取引の決済が可能です。他のデジタル通貨プロトコルとは異なり、XRP LedgerではXRP（XRP Ledgerのネイティブ資産）の他にユーザが選択した通貨（法定通貨、デジタル通貨、その他の価値形態など）建てでトランザクションを実行できます。
+
+XRP Ledgerのテクノロジーにより、ほぼリアルタイムでの決済（3～6秒）が可能です。また、その分散型取引所により自動的に最も安価な通貨取引注文を決済に適用して通貨をブリッジングすることができます。
+
+# 背景
+
+## 仕組み
+
+根本的には、XRP Ledgerはアカウント、残高、および資産取引オファーなどの情報を記録する共有データベースです。「トランザクション」と呼ばれる署名付きの指示により、アカウントの作成、支払いの実行、資産の取引などの変更が行われます。
+
+暗号化システムであるため、XRP Ledgerアカウントの所有者は _暗号ID_ により識別されます。暗号IDは、公開鍵/秘密鍵のペアに相当します。トランザクションは、暗号IDに一致する暗号署名によって承認されます。すべてのサーバでは、同一の確定的な既知のルールに基づいてすべてのトランザクションが処理されます。最終的な目標は、ネットワーク内のすべてのサーバがまったく同じレジャー状態の完全なコピーを保有できるようにし、1つの中央機関がトランザクションを調停する必要がないようにすることです。
+
+
+## 二重支払いの問題
+
+「二重支払い」の問題は、どのような決済システムの運用においても根本的な課題となります。この問題は、ある場所でお金を支払うときに、別の場所ではそのお金を支払うことができないという要件に起因しています。一般的には、2つのトランザクションがあり、いずれかのトランザクションが有効で、両方が同時に有効になることがない場合にこの問題が発生します。
+
+たとえば、Alice、Bob、Charlieが決済システムを使用しており、Aliceの残高が$10であるとします。この決済システムが機能するためには、Aliceはこの$10をBobまたはCharlieに送金できる必要があります。ただしAliceがBobに$10を送金し、同時にCharlieにも$10を送金しようとすると、二重支払いの問題が発生します。
+
+Aliceが「同じ」$10をCharlieとBobの両方に送金できてしまう場合、この決済システムは正しく機能したとはいえなくなります。決済システムでは、発生したトランザクションについてすべての参加者が合意できるように、成功すべきトランザクションと失敗すべきトランザクションを選択する手段が必要です。これら2つのトランザクションはいずれも、トランザクションとしては同じく有効です。ただし、どのトランザクションが最初に発生したかについては、決済システムの参加者によって見方が異なります。
+
+従来、決済システムでは中央機関がトランザクションを追跡、承認することで、この二重支払いの問題が解決されてきました。たとえば銀行は唯一の管理人として、保有する小切手振出人の預金残高に基づいて小切手を決済します。このようなシステムでは、すべての参加者が中央機関の決定に従う必要があります。
+
+XRP Ledgerなどの分散型台帳技術では中央機関が存在せず、二重支払いの問題を他の方法で解決する必要があります。
+
+
+# コンセンサスの仕組み
+
+## 問題の単純化
+
+二重支払いの問題のほとんどは、既知のルール（アカウントが保有していない資金を利用することを禁止するなど）により解決できます。実際に、二重支払いの問題はトランザクションを順に整理することで削減できます。
+
+BobとCharlieの両方に同じ$10を送金しようとしたAliceの例で説明します。Bobへの支払いが最初であることが判明している場合は、AliceにはBobに支払う資金があることで全員が合意できます。Charlieへの支払いが2番目であることが判明している場合は、資金はすでにBobに送金されたため、Charlieには資金を送金できないことで全員が合意できます。
+
+また、確定的なルールに基づいてトランザクションを順に並べることもできます。トランザクションはデジタル情報の集合であるため、コンピュータで簡単にソートできます。
+
+中央機関なしに二重支払いの問題を解決するにはこれで十分ですが、トランザクションの結果を確認する前に、発生するすべてのトランザクションを把握し、ソートする必要があります。これは明らかに非現実的です。 <!-- STYLE_OVERRIDE: obviously -->
+
+トランザクションをグループにまとめ、グループ単位で合意できる場合には、グループ内でトランザクションをソートできます。ひとまとめで処理するトランザクションについて参加者全員が合意している限り、中央機関を必要とすることなく、確定的なルールに基づいて二重支払いの問題を解決できます。各参加者がトランザクションをソートし、既知のルールに従い確定的な方法でそれらのトランザクションを適用します。XRP Ledgerでは、二重支払いの問題をこの方法で解決します。
+
+XRP Ledgerでは、合意されたグループに複数の競合するトランザクションを含めることができます。トランザクションのグループは確定的なルールに従って実行されるので、ソートルールに基づいて最初に発生したトランザクションが成功し、2番目に発生した競合するトランザクションは失敗します。
+
+## コンセンサスルール
+
+コンセンサスの主な役割は、プロセスの参加者が、二重支払いの問題を解決するためグループ単位で処理するトランザクションについて合意を形成できるようにすることです。次の4つの理由により、この合意の形成は予想以上に容易です。
+
+1. トランザクションをトランザクショングループに含めてはならない理由が特にない場合、すべての公正な参加者はそのトランザクションをグループに含めることで合意します。すべての参加者がすでに合意している場合、コンセンサスが果たす役割はありません。
+2. トランザクションをトランザクショングループに含めてはならない何らかの理由がある場合、すべての公正な参加者はそのトランザクションの除外を希望します。トランザクションがまだ有効であり、次のラウンドに含めてはならない理由が特にない場合は、そのトランザクションを次のラウンドに含めることで全員が合意します。
+3. トランザクションをグループ化する方法に参加者が特に関心を示すことは極めてまれです。合意の形成は、参加者全員がこれを最優先と認識している場合は最も容易になされ、参加者の関心が異なる場合に限り難しくなります。
+4. 確定的なルールはグループ編成時にも使用でき、エッジケースについてのみ不合意を形成します。たとえば、ラウンドに2つの競合するトランザクションがある場合、確定的なルールを使用して次のラウンドに含めるトランザクションを決定できます。
+
+すべての参加者は正確さを最も重視します。共有レジャーの整合性を損なわないようにするため、最初にこれらのルールを適用する必要があります。たとえば、適切な署名がないトランザクションは（他の参加者が処理を希望する場合でも）処理されることはありません。ただし、公正な参加者全員が2番目に重視するのは合意です。二重支払いが発生する可能性のあるネットワークはまったく役に立ちません。公正な参加者全員が正確さの次に重視するのが合意であるという事実により、合意が促進されます。
+
+## コンセンサスラウンド
+
+コンセンサスラウンドとは、トランザクションのグループについての合意形成に向けた取り組みで、これによりトランザクションの処理を可能とします。コンセンサスラウンドでは、合意形成を希望する各参加者が最初の見解を表明します。これは、参加者が確認した有効なトランザクションセットです。
+
+次に、合意に向けて、参加者の見解が「次々に寄せられます」。特定のトランザクションが過半数の支持を得られない場合、参加者はそのトランザクションの保留に合意します。特定のトランザクションが過半数の支持を得ている場合、参加者はそのトランザクションを追加することに合意します。このように、支持が過半数をわずかに上回れば即座に全面的に支持され、過半数をわずかに下回れば即座に現行ラウンドでは全面的に却下されることになります。
+
+コンセンサスが50%前後で行き詰まることを防ぎ、確実な合意を形成する上で必要となる重複を低減するため、トランザクションの追加に関する所定のしきい値は時間の経過とともに増加します。最初は、50%以上の他の参加者が合意していれば、参加者はトランザクションの追加についての合意の継続を支持します。参加者が合意しない場合、このしきい値が増加します。最初は60%に増加し、その後は問題のトランザクションが現行セットから削除されるまで増加し続けます。このようにして除外されたトランザクションはすべて次のレジャーバージョンに繰り越されます。
+
+次に処理するトランザクションセットについて圧倒的多数が合意し、参加者がこれを確認した場合は、コンセンサスに達したと宣言します。
+
+## コンセンサス失敗の可能性
+
+完全なコンセンサスの達成に失敗することがないコンセンサスアルゴリズムの開発は非現実的です。その理由を理解するため、コンセンサスプロセスがどのように終了するかについて説明します。各参加者はある時点で、コンセンサスに達し、特定のトランザクションセットがそのコンセンサスプロセスの結果であると宣言する必要があります。この宣言により参加者は、特定のトランザクションセットがコンセンサスプロセスの結果であると取り消し不能の表明をすることになります。
+
+いずれかの参加者がこの宣言を最初に行う必要があります。この宣言を行なう参加者がいなければ、合意に達することができません。次に、この宣言を最初に行う参加者について説明します。最初に宣言を行う参加者が、コンセンサスは完了したと判断した時点では、他の参加者はまだそのような判断に至っていません。もし他の参加者が各自の視点をもとに合意済のセットを変更できないのであれば、最初の宣言が行われた時点で、他の参加者はコンセンサスは完了したと判断していたでしょう。したがって、参加者は合意済のセットを変更できるはずです。 <!-- STYLE_OVERRIDE: will -->
+
+つまり、コンセンサスプロセスを完了するには、その他のすべての参加者が合意済のトランザクションセットを理論的に変更できる場合でも、特定の参加者がトランザクションセットについてコンセンサスに達したことを宣言する必要があります。
+
+たとえば、あるグループが部屋の中でどのドアから外に出るかについて合意しようとしている場合を考えてください。参加者がどれほど話し合っても、ある時点で _誰か_ が最初にドアから外に出なければなりません。これは、その後に続く人々が考えを変えて別のドアから外に出ることができるとしてもです。
+
+このような失敗が生じる確率を低く抑えることはできますが、ゼロにすることはできません。技術上のトレードオフとして、この確率を1000分の1未満に抑えると、コンセンサスにかかる時間が非常に長くなり、ネットワークとエンドポイントの障害に対する耐性が低くなります。
+
+## XRP Ledgerでのコンセンサス失敗の処理
+
+コンセンサスラウンドが完了したら、各参加者は、合意に達したと各自が理解しているトランザクションのセットを適用します。その結果、レジャーの次の段階と各自が想定しているものが生成されます。
+
+バリデータでもある参加者が、次のレジャーの暗号フィンガープリントを公開します。このフィンガープリントを「検証投票」と呼びます。コンセンサスラウンドが成功した場合、公正なバリデータの過半数が同じフィンガープリントを公開します。
+
+次に参加者がこれらの検証投票を収集します。検証投票から、参加者は前のコンセンサスラウンドの結果、参加者の圧倒的多数がトランザクションセットについて合意しているか否かを確認できます。
+
+参加者は次の3つのいずれかの状況になります（確率の高い順）。
+
+1. 圧倒的多数が合意したレジャーと同じレジャーを構築します。この場合、参加者はそのレジャーが完全に検証済みであると見なし、その内容を信頼できます。
+2. 圧倒的多数が合意したレジャーとは異なるレジャーを構築します。この場合、参加者は圧倒的多数が合意したレジャーを構築して受け入れる必要があります。これは通常、参加者が早期にコンセンサスを宣言した後、他の多くの参加者が考えを変えたことを意味します。圧倒的多数が合意したレジャーに「ジャンプ」して操作を再開する必要があります。
+3. 受信した検証からは圧倒的多数が明確ではありません。この場合、前のコンセンサスラウンドが無駄となったため、いずれかのレジャーが検証される前に新しいラウンドが発生する必要があります。
+
+ケース1が最も一般的に発生する状況です。ケース2はネットワークに一切悪影響を及ぼしません。ごく少数の参加者は、あらゆるラウンドでケース2の状況になることがありますが、ネットワークは特に問題なく動作します。このような参加者も、構築したレジャーが圧倒的多数が支持するレジャーと同じでなかったことを認識できるので、圧倒的多数との合意に達するまでは、その結果を最終結果として報告してはならないことを理解しています。
+
+ケース3では、ネットワークは数秒間遅滞する結果となります。この間に処理を進められる可能性はありますが、非常にまれです。このケースでは、意見の相違はコンセンサスプロセスで解決され、未解決のまま残っている意見の相違のみが失敗の原因となるため、次のコンセンサスラウンドが失敗する可能性は大幅に低下します。
+
+まれに、ネットワーク全体が数秒間にわって処理を進めることができないことがあります。その代わり、トランザクションの平均確認時間は短くなります。
+
+# 理念
+
+信頼性の1つの要素として、一部のコンポーネントで障害が発生している、悪意のある参加者がいるなどの状況でも結果を提供できるというシステムの能力があげられます。この点は重要ですが、暗号決済システムに関してはこれよりもさらに重要なもう1つの信頼性の要素があります。それは、信頼できる結果を提供するシステムの能力です。つまり、システムが結果を信頼できるものとして報告する場合、その結果を信頼できなければなりません。
+
+ただし実際のシステムは、この両方の信頼性が損なわれる可能性のある運用状況に直面します。このような状況には、ハードウェア障害、通信障害、不正な参加者などがあります。XRP Ledgerの設計理念の1つとして、信頼してはならない結果を提供するのではなく、結果の信頼性が損なわれている状況を検知し、報告することを掲げています。
+
+XRP Ledgerのコンセンサスアルゴリズムは、プルーフオブワークシステムに代わる堅牢な仕組みで、コンピューティングリソースを不必要に消費することはありません。ビザンチン障害が発生する可能性があり、また実際に発生することがありますが、その影響はわずかな遅延にとどまります。どのケースでも、XRP Ledgerのコンセンサスアルゴリズムは、結果が実際に信頼できるものである場合にのみ、信頼できる結果として報告します。
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-protections.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-protections.md
@@ -0,0 +1,75 @@
+---
+html: consensus-protections.html
+parent: consensus.html
+seo:
+    description: Learn how the XRP Ledger Consensus Protocol is protected against various problems and attacks that may occur in a decentralized financial system. #TODO: translate
+labels:
+  - ブロックチェーン
+---
+# 攻撃および障害モードに対するコンセンサスの保護
+
+XRP Ledgerコンセンサスプロトコルは、 _ビザンチンフォールトトレラント性_ のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。
+
+[ネットワークに求められる特性](index.md#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
+
+このページでは、XRP Ledgerコンセンサスプロトコルのいくつかの課題のタイプとその対処について説明します。
+
+## 個々のバリデータの不適切な動作
+
+_バリデータ_ とは、新しいレジャーバージョンの決定プロセスにアクティブに参加するサーバです。バリデータは、そのバリデータを信用するように設定されているサーバにのみ影響を与えます（間接的な影響を含む）。一部バリデータの動作が不適切であってもコンセンサスを継続できます。このような不適切な動作には、以下のさまざまなケースがあります。
+
+- 使用できないかまたは過負荷状態である。
+- ネットワークから部分的に切断されており、メッセージが遅延なしで届くのは一部の参加者に限られる。
+- 他のサーバを欺くかまたはネットワークを停止する目的で意図的に動作している。
+- 外部要因（抑圧的な政府からの脅威など）からのプレッシャーによって不正に動作している。
+- バグまたは古いソフトウェアが原因で、わかりにくいメッセージまたは誤った形式のメッセージが偶発的に送信される。
+
+一般に、信頼できるバリデータのうち、不適切に動作しているバリデータがごくわずか（約20%未満）である限り、特に問題なくコンセンサスを継続できます。（正確な割合とその計算については、最新の[コンセンサスに関する研究](consensus-research.md)をご覧ください。）
+
+バリデータの約20%以上がアクセス不能であるか適切に動作していない場合、ネットワークはコンセンサスに達することができません。この間、新しいトランザクションを暫定的に処理できますが、新しいレジャーバージョンを検証できないため、これらのトランザクションの最終結果は未確定になります。このような状況では、XRP Ledgerが正常ではないことがただちに明らかになるため、待機するか、または信頼できるバリデータのセットを再設定するかを決定できる参加者からの人的介入が促されます。
+
+無効なトランザクションを承認する唯一の方法は、80%以上の信頼できるバリデータがそのトランザクションを承認し、その結果に合意することです。（無効なトランザクションには、すでに使用された資金を送金するトランザクションや、ネットワークのルールに違反するトランザクションなどがあります。）つまり、信頼できるバリデータの過半数が _共謀する_ 必要があります。多数の信頼できるバリデータが世界各地域で異なる人々や企業により運用されている状況では、意図的にこれを達成することは非常に困難です。
+
+
+## ソフトウェアの脆弱性
+
+あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。XRP Ledgerの開発者はこのような脅威に対処するため、次のようなさまざまな対策を導入しています。
+
+- [オープンソースコードベース](https://github.com/XRPLF/rippled/)。これにより、一般のユーザが関連ソフトウェアをレビュー、コンパイルし、個別にテストできます。
+- 公式XRP Ledgerリポジトリのあらゆる変更のための綿密で堅固なコードレビュープロセス。
+- 著名な開発者によるすべてのリリースと公式ソフトウェアパッケージへのデジタル署名付与。
+- セキュリティの脆弱性と不安定さに関する定期的に委託された専門家レビュー。
+- 責任を持って脆弱性を公開したセキュリティ研究者に報奨金を授与する[Bug Bountyプログラム](https://ripple.com/bug-bounty/)。
+
+
+## シビル攻撃
+
+_[シビル攻撃](https://en.wikipedia.org/wiki/Sybil_attack)_ とは、大量の偽IDを使ってネットワークのコントロールを試みる攻撃です。XRP Ledgerでは、シビル攻撃は多数のバリデータを操作して、他のバリデータにこれらのバリデータを信頼するように仕向ける形で攻撃をしかける可能性があります。このような攻撃は理論上は可能ですが、バリデータが信頼を得るには人間による介入が必要であるため、実際には非常に困難です。
+
+攻撃者が操作する検証サーバの数に関係なく、既存の参加者が攻撃者のバリデータを信頼しない限りは、これらの参加者が何を検証済みと判断するかについて、このようなサーバが影響を及ぼすことはできません。その他のサーバは、バリデータリストまたは明示的な設定によって信頼できると設定されたバリデータのみを信頼します。（デフォルトのバリデータリストの仕組みの概要については、[バリデータ重複要件](#バリデータ重複要件)をご覧ください。）
+
+この信頼は自動的に形成されるものではありません。したがってシビル攻撃を成功させるには、ターゲットとなる人物や企業が、攻撃者のバリデータを信頼してXRP Ledgerサーバを再設定するように仕向けるという難しい作業をこなさなければなりません。ある人物または企業がだまされてXRP Ledgerサーバを再設定したとしても、自らの設定を変更していない他の人物や企業に対する影響は最小限となります。
+
+
+## 51%攻撃
+
+「51%攻撃」とは、特定の当事者が全採掘能力または投票能力の50%を超える割合を支配しているブロックチェーンに対する攻撃です。（厳密には、50%を _わずかでも_ 超えていれば十分であるため、この攻撃の名前は多少間違っています。）XRP Ledgerは、コンセンサスメカニズムに採掘を採用していないため、51%攻撃に対し脆弱ではありません。これに最も類似するXRP Ledgerへの攻撃には[シビル攻撃](#シビル攻撃)がありますが、この攻撃を実際に実施することは困難です。
+
+
+## バリデータ重複要件
+
+XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。そのため、業界やコミュニティによって運営されている信頼できる、よくメンテナンスされたサーバを含むことを意味する、推奨バリデータの署名されたリストがあります。
+
+デフォルトでは、XRP LedgerサーバはXRPL財団やRippleが運用するバリデータリストサイトを使用するように設定されています。各サイトでは定期的に更新する推奨バリデータリスト（推奨 _ユニークノードリスト_ （UNL））が公開されています。このように設定されているサーバは、最新バージョンのリストに含まれているすべてのバリデータを信頼します。これにより、同じリストを使用する他のサーバと100%重複することが保証されます。デフォルトの設定には、サイトのコンテンツの真正性を検証する公開鍵が含まれています。サイトがダウンした場合、XRP Ledgerのピアツーピアネットワーク内のサーバ間でリストに対する署名済みの更新を直接中継できます。
+
+技術的には、サーバを実行している場合、各自のリストサイトを設定するかまたは信頼できるバリデータを個別に明示的に選択することができますが、これらを行うことは推奨されません。選択したバリデータ群と他のサーバとの重複が十分ではない場合、サーバはネットワークの他の部分と不一致になる可能性があり、サーバが不一致の状態でアクションを実行すると資金を失う可能性があります。
+
+コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、[コンセンサスの研究](consensus-research.md)ページをご覧ください。
+
+
+## 関連項目
+
+- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](index.md)をご覧ください。
+- コンセンサスプロトコルの**詳細な説明**については、[コンセンサス](index.md)をご覧ください。
+- コンセンサスプロトコルの**設計に関する決定と背景**については、[コンセンサスの原理とルール](consensus-principles-and-rules.md)をご覧ください。
+- コンセンサスプロトコルの特性と制約に関する**学術研究**については、[コンセンサスの研究](consensus-research.md)をご覧ください。
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-research.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-research.md
@@ -0,0 +1,17 @@
+---
+html: consensus-research.html
+parent: consensus.html
+seo:
+    description: コンセンサスアルゴリズムに関する学術論文と関連研究。
+labels:
+  - ブロックチェーン
+---
+# コンセンサスの研究
+
+Rippleでは、XRP Ledgerのコンセンサスプロトコルの理論上の制限と実際の制限の両方についての研究を進め、この分野にてさまざまなアイデアを探究しています。以下の表に、Rippleが発表した学術論文の一覧を示します。
+
+| 日付 | タイトル | 著者 | 概要 |
+|---|---|---|---|
+| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | コンセンサスUNLの柔軟性を高める新しいアトミックブロードキャストアルゴリズム、Cobaltの紹介。 |
+| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | XRP Ledgerのコンセンサスアルゴリズムとその安全性および活性の特性に関する最新の詳細な分析。 |
+| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | XRP Ledgerで採用されているコンセンサスアルゴリズムの紹介。 |
--- a/@l10n/ja/docs/concepts/consensus-protocol/consensus-structure.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/consensus-structure.md
@@ -0,0 +1,216 @@
+---
+html: consensus-structure.html
+parent: consensus.html
+seo:
+    description: XRP Ledgerにおけるコンセンサスの役割について理解を深めましょう。
+labels:
+  - ブロックチェーン
+---
+# コンセンサス
+
+_著者: Dave Cohen、David Schwartz、Arthur Britto_
+
+この記事では、XRP Ledgerの概要や格納される情報、[トランザクション](../../references/protocol/transactions/index.md)によってレジャー（台帳）が変化する様子について説明します。
+
+XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger APIの動作や、その動作によってもたされる影響を知っておくために、このプロセスを理解することが重要です。
+
+
+## まえがき
+
+ピアツーピアサーバのXRP Ledgerネットワークは世界で共有されている台帳であり、ここから、アプリケーションはこの台帳の内容の状態に関して信頼できる情報を得ることができます。この状態に関する情報には以下の内容が含まれます。
+
+- 各[アカウント](../accounts/index.md)の設定
+- XRPおよび[トークン](../tokens/index.md)の残高
+- 分散型取引所でのオファー（注文）
+- ネットワーク設定（例: [トランザクションコスト](../transactions/transaction-cost.md)と[準備金](../accounts/reserves.md)の金額）
+- タイムスタンプ
+
+レジャーバージョンに含まれるデータの詳細な技術説明については、[レジャーフォーマットのリファレンス](../../references/protocol/ledger-data/index.md)をご覧ください。
+
+[![図1: XRP Ledgerの要素](/docs/img/anatomy-of-a-ledger-complete.ja.png)](/docs/img/anatomy-of-a-ledger-complete.ja.png)
+
+_図1: XRP Ledgerの要素_
+
+XRP Ledgerでは、数秒ごとに新しいレジャーバージョンが作成されます。あるレジャーバージョンの内容にネットワークが同意すると、そのレジャーバージョンは _検証済み_ となり、その内容が変更されることはありません。それ以前の検証済みのレジャーバージョンによって、レジャー履歴が形成されます。検証済みの最新のレジャーも、少し前の時点のネットワークの状態を表しており、履歴の一部となります。現時点で、ネットワークは次のレジャーバージョンに適用されてファイナライズされる可能性のあるトランザクションを評価しています。この評価が行われている間、ネットワークには、検証前のレジャーバージョン候補が存在します。
+
+[![図2: XRP Ledgerの履歴](/docs/img/ledger-history.ja.png)](/docs/img/ledger-history.ja.png)
+
+_図2: XRP Ledgerの履歴_
+
+レジャーバージョンには2つの識別子があります。1つ目の識別子は、そのレジャーバージョンの _レジャーインデックス_ です。レジャーバージョンの番号は1つずつ増加します。例えば、現行のレジャーバージョンのレジャーインデックスが100の場合、1つ前はレジャーインデックス99、1つ後はレジャーインデックスは101です。もう1つの識別子は _レジャーハッシュ_ で、レジャーの内容のデジタル指紋を表します。
+
+サーバがレジャーに適用するトランザクションを提案するときに、内容がわずかに異なる複数の候補レジャーバージョンが作成される場合があります。このような候補レジャーバージョンでは、レジャーインデックスは同じですがレジャーハッシュが異なります。多くの候補のうち、検証済みとなるのは1つだけです。それ以外の候補レジャーバージョンはすべて、破棄されます。そのため、履歴内の各レジャーインデックスに対して存在する検証済みのレジャーハッシュは1つのみです。
+
+レジャーに対するユーザレベルの変更は、トランザクションによってなされます。[トランザクション](../../references/protocol/transactions/index.md)の例としては、決済、アカウントの設定またはトラストラインの変更、取引のオファー（注文）などがあります。各トランザクションは、レジャーに対する1つ以上の変更を承認するものであり、アカウント所有者によって暗号署名されます。アカウントの変更を承認したり、レジャーのそれ以外の内容を変更したりするには、トランザクションだけが唯一の方法です。
+
+各レジャーバージョンには、一連のトランザクションと、そのようなトランザクションに関するメタデータも含まれています。それらのトランザクションは、新しいレジャーバージョンを作成するために前のバージョンのレジャーに適用されたものです。メタデータには、レジャーの状態データに対する、トランザクションの影響が正確に記録されています。
+
+[![図3: レジャーバージョンに適用されるトランザクション](/docs/img/ledger-changes.ja.png)](/docs/img/ledger-changes.ja.png)
+
+_図3: レジャーバージョンに適用されるトランザクション_
+
+レジャーインスタンスに含まれる一連のトランザクションはそのレジャーに記録され、XRP Ledger履歴の監査を可能としています。レジャーN+1のアカウント残高がレジャーNのアカウント残高と異なる場合、レジャーN+1にはその変更の原因となったトランザクションが含まれます。
+
+検証済みのレジャー内に出現するトランザクションは、レジャーの変更に成功したか、または要求されたアクションを実行せずに処理された可能性があります。成功したトランザクションには、要求された変更がレジャーに適用されたことを示す**tesSUCCESS** [結果コード](../../references/protocol/transactions/transaction-results/index.md)が含まれます。レジャー内の失敗したトランザクションには、**tec**クラスの結果コードが含まれます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
+
+レジャーに含まれるトランザクションでは必ず、[トランザクションコスト](../transactions/transaction-cost.md)として一部のXRPが消却されます。この場合、**tes**コードまたは**tec**コードが含まれていたかどうかは関係ありません。消却するXRPの正確な量は、署名されたトランザクションの手順で定義されます。
+
+**tes**クラスや**tec**クラスの結果コード以外に、**ter**クラス、**tef**クラス、および**tem**クラスのコードがあります。後者の3つは、APIの呼び出しによって返された暫定的な失敗を示します。レジャーには、**tes**および**tec**のコードのみ表示されます。レジャーに含まれていないトランザクションによって、レジャーの状態（XRP残高を含む）が影響を受けることはありませんが、暫定的に失敗したトランザクションが後で成功する可能性があります。
+
+[`rippled` API](../../references/http-websocket-apis/index.md)を使用する場合、レジャーに含めるように提案された候補トランザクションと、検証済みのレジャーに含まれる検証済みのトランザクションをアプリケーションで区別する必要があります。検証済みのレジャー内にあるトランザクションの結果のみが不変です。検証済みのレジャーには、候補トランザクションが含まれる場合と含まれない場合があります。
+
+重要: 一部の[`rippled` API](../../references/http-websocket-apis/index.md)では、候補トランザクションに基づき暫定的な結果が返されます<a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>。アプリケーションで、トランザクションの最終的な結果を判断する目的で暫定的な結果を使用するのは望ましくありません。最終的にトランザクションが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ、結果コードがtesSUCCESSになるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャー内にあるが、結果コードがそれ以外の場合、トランザクションの失敗を意味します。トランザクションの[`LastLedgerSequence`](../../references/protocol/transactions/common-fields.md)で指定されたレジャーが検証済みにもかかわらず、そのトランザクションがそのレジャーまたはそれ以前の他のレジャー内にない場合、トランザクションは失敗しており、どのレジャーにも表示されません。検証済みのレジャー内に表示されるトランザクションの場合にのみ、結果は最終的なものとなります。それ以外の場合、このドキュメントで後述するように、`LastLedgerSequence`の制限により、表示されることはありません。
+
+## XRP Ledgerプロトコル - コンセンサスと検証
+
+ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバ（通常、[`rippled`](../networks-and-servers/index.md)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバに送信します。サーバは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
+
+[![図4: XRP Ledgerプロトコルの参加者](/docs/img/xrp-ledger-network.ja.png)](/docs/img/xrp-ledger-network.ja.png)
+
+_図4: XRP Ledgerプロトコルの参加者_
+
+トランザクションを受信、中継、処理するサーバは、追跡サーバとバリデータのいずれかです。追跡サーバの主な機能には、クライアントからのトランザクションの分散やレジャーに関する照会へのレスポンスが含まれます。検証サーバは、追跡サーバと同じ機能を実行し、さらにレジャー履歴を進めます<a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>。
+
+クライアントアプリケーションによって送信されたトランザクションを受け入れるときに、各追跡サーバは最後に検証されたレジャーを開始点として使用します。受け入れられたトランザクションは候補トランザクションとなります。サーバから候補トランザクションがそれぞれのピアに中継され、候補トランザクションがネットワーク全体に伝達されます。理想的には、各候補トランザクションはすべてのサーバに伝達される必要があります。その結果、各サーバは最後に検証されたレジャーに同じ一連のトランザクションを適用できる可能性が高くなります。しかし、トランザクションが伝達されるまでには時間がかかるため、サーバは常に同じ候補トランザクションを処理するわけではありません。このことを考慮に入れて、XRP Ledgerでは、コンセンサスと呼ばれるプロセスを使用して、同一のトランザクションが処理され、ピアツーピアのXRP Ledgerネットワーク全体で検証済みのレジャーの一貫性が確保できるようにしています。
+
+### コンセンサス
+
+ネットワーク内のサーバは、候補トランザクションに関する情報を共有します。コンセンサスプロセスを通じて、バリデータは、候補トランザクションの特定のサブセットが次のレジャーで考慮されることに同意します。コンセンサスとは、サーバが提案や一連の候補トランザクションを中継する反復プロセスです。サーバは、選択されたバリデータの圧倒的多数<a href="#footnote_4" id="from_footnote_4"><sup>4</sup></a>が同じ候補トランザクションのセットについて合意するまで、提案の通信と更新を行います。
+
+コンセンサスの間、各サーバは、そのサーバの信頼できるバリデータ（ _ユニークノードリスト（UNL）_ ）と呼ばれる特定のサーバ群からの提案を評価します。<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a>信頼できるバリデータとは、提案を評価するサーバを欺こうと共謀しない、全体として「信頼できる」ネットワークのサブセットを表します。この「信頼」の定義では、選択された個々のバリデータが信頼されている必要はありません。バリデータの選択は、ネットワークに中継されたデータを改ざんする組織的な試みで共謀しないという想定に基づいて行われます<a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a>。 <!-- STYLE_OVERRIDE: will -->
+
+[![図5: バリデータによるトランザクションセットの提案と修正](/docs/img/consensus-rounds.ja.png)](/docs/img/consensus-rounds.ja.png)
+
+_図5: バリデータによるトランザクションセットの提案と修正 - コンセンサスの開始時点で、バリデータ毎に異なるトランザクションセットを持っている可能性があります。後のラウンドで、サーバは現在の提案を信頼できるバリデータの提案と一致するように変更します。このプロセスでは、現在議論しているレジャーバージョンに適用するトランザクションと、それ以降のレジャーバージョンに適用するトランザクションを決定します。_
+
+合意済みの提案に含まれていない候補トランザクションは、その後も候補トランザクションとして残ります。これらは次のレジャーバージョンで再度検討される可能性があります。通常、1つのレジャーバージョンから除外されたトランザクションは、次のレジャーバージョンに含まれます。
+
+状況によっては、いつまでもコンセンサスに達することができないトランザクションもあります。そのような状況として、ネットワークが、必要な[トランザクションコスト](../transactions/transaction-cost.md)を、トランザクションで指定されたものよりも高い値に変更している場合が考えられます。将来のある時点でこの手数料が引き下げられると、そのトランザクションが成功する可能性があります。トランザクションの成功または失敗が一定時間内に確定するように、トランザクションが特定のレジャーインデックスによって一定時間処理されない場合は期限切れになるように設定することができます。詳細は、[信頼できるトランザクションの送信](../transactions/reliable-transaction-submission.md)をご覧ください。
+
+### 検証
+
+検証は、全体のコンセンサスプロセスの第2段階です。このプロセスでは、すべてのサーバで同じ結果が得られたことを確認し、あるレジャーバージョンが最終バージョンとして宣言されます。まれに、第一段階の[コンセンサスプロセスが失敗する場合](consensus-principles-and-rules.md#コンセンサス失敗の可能性)があります。検証によって後で確認が行われるため、サーバは結果を確認し、それに応じて対処することができます。
+
+検証は、大きく分けて次の2つの部分に分かれます。
+
+- 合意済みのトランザクションセットから結果として生じるレジャーバージョンを計算する。
+- 結果を比較し、十分に信頼できるバリデータが同意した場合はレジャーバージョンの検証済みを宣言する。
+
+ネットワーク内の各サーバは、それぞれ個別にローカルに検証を行います。
+
+
+#### 検証の計算と共有
+
+コンセンサスプロセスが完了すると、各サーバは合意済みの一連のトランザクションから新しいレジャーを個別に計算します。各サーバは、同じ規則に従って結果を次のように計算します。
+
+1. 一つ前の検証済みのレジャーから始めます。
+
+2. すべてのサーバが同じ方法で処理できるように、合意済みのトランザクションセットを _正規順序_ で並べ変えます。
+
+   [正規順序](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36)は、トランザクションを受け取った順序ではありません（サーバが同じトランザクションを異なる順序で受け取る可能性があるため）。参加者がトランザクションの順序付けで競合しないように、故意に操作するのが困難な正規順序を使います。
+
+3. 指示に従って、各トランザクションを順番に処理します。それに応じてレジャーの状態データを更新します。
+
+   トランザクションを正常に実行できない場合は、[`tec`クラス結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を持つトランザクションを含めます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
+
+   特定の「再試行可能な」トランザクションの失敗に対しては、同じレジャーバージョンの他のトランザクションが実行された後に再試行されるように、そのトランザクションを正規順序の最後に移動します。
+
+4. 適切なメタデータでレジャーヘッダーを更新します。
+
+   これには、レジャーインデックス、前に検証済みのレジャーの識別ハッシュ（このレジャーの「親」）、このレジャーバージョンの予定終了時刻、このレジャーの内容の暗号化ハッシュなどのデータが含まれます。
+
+5. 新しいレジャーバージョンの識別用ハッシュを計算します。
+
+[![図7: XRP Ledgerサーバでレジャー検証を計算する](/docs/img/consensus-calculate-validation.ja.png)](/docs/img/consensus-calculate-validation.ja.png)
+
+_図7: XRP Ledgerサーバでレジャー検証を計算する - 各サーバは、同意済みのトランザクションを前の検証済みレジャーに適用します。バリデータは結果をネットワーク全体に送信します。_
+
+#### 結果を比較する
+
+バリデータはそれぞれ、計算したレジャーバージョンのハッシュを含む署名付きメッセージの形式で結果を中継します。 _検証_ と呼ばれるこれらのメッセージによって、各サーバで計算したレジャーとそのピアのレジャーを比較することができます。
+
+[![図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが検証される](/docs/img/consensus-declare-validation.ja.png)](/docs/img/consensus-declare-validation.ja.png)
+
+_図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが検証される - 各サーバは、計算されたレジャーを、選択されたバリデータから受け取ったハッシュと比較します。一致しない場合、サーバは正しいレジャーを再計算または取得する必要があります。_
+
+ネットワーク内のサーバは、圧倒的多数のピアが同じ検証ハッシュに署名してそれをブロードキャストしたときに、そのレジャーインスタンスを検証済みと認識します <a href="#footnote_7" id="from_footnote_7"><sup>7</sup></a>。それ以降のトランザクションは、レジャーインデックスN+1の更新および検証済みのこのレジャーに適用されます。
+
+サーバが少数で、ピアと異なるレジャーを計算した場合、計算したレジャーは無視されます<a href="#footnote_8" id="from_footnote_8"><sup>8</sup></a>。正しいレジャーを再計算するか、必要に応じて正しいレジャーを取得します。
+
+ネットワークで、検証に関する圧倒的多数の同意が得られない場合、コンセンサスプロセスで一貫した提案を作成するにはトランザクション量が多すぎるか、ネットワーク遅延が大きすぎることを意味します。この場合、サーバはコンセンサスプロセスを繰り返します。コンセンサスが始まってから時間が経過するにつれて、各コンセンサスラウンドで不一致は減少するため、過半数のサーバが同じ候補トランザクションのセットを受け取った可能性が高くなります。XRP Ledgerは、これらの状況に応じて[トランザクションコスト](../transactions/transaction-cost.md)と、コンセンサスを待つ時間を動的に調整します。
+
+検証について圧倒的多数の合意が得られると、サーバは検証済みの新しいレジャー、レジャーインデックスN+1との作業に入ることができます。最後のラウンドに含まれなかった候補トランザクションと、その間に送信された新しいトランザクションに対して、コンセンサスと検証プロセスが繰り返されます<a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>。
+
+
+## 要点
+
+XRP Ledgerに送信されたトランザクションはすぐには処理されません。一定期間、各トランザクションは候補状態になります。
+
+単一トランザクションのライフサイクルは次のとおりです。
+
+- アカウント所有者によってトランザクションが作成され、署名されます。
+- トランザクションがネットワークに送信されます。
+  - 書式が正しくないトランザクションはその場で拒否される可能性があります。
+  - 書式が正しいトランザクションは暫定的に成功し、その後で失敗する可能性があります。
+  - 書式が正しトランザクションは暫定的に失敗し、その後で成功する可能性があります。
+- コンセンサスの間、トランザクションはレジャーに含まれます。
+  - コンセンサスラウンドが成功すると、レジャーが有効になります。
+  - コンセンサスラウンドが失敗すると、成功するまでコンセンサスプロセスが繰り返されます。
+- 検証済みレジャーには、トランザクションとレジャーの状態への反映が含まれます。
+
+アプリケーションでは、候補トランザクションの暫定的な結果ではなく、検証済みのレジャーの情報のみを信頼してください。一部の[`rippled` API](../../references/http-websocket-apis/index.md)では、トランザクションの暫定的な結果が最初に返されます。トランザクションの結果が不変になるのは、そのトランザクションが検証済みレジャーに含まれている場合か、トランザクションに`LastLedgerSequence`が含まれ、そのレジャーインデックス以下の検証済みレジャーに出現しない場合に限られます。
+
+トランザクションを送信するアプリケーションのベストプラクティスは次のとおりです。
+
+- `LastLedgerSequence`パラメーターを使用して、トランザクションが確定的かつ迅速な方法で検証されるか、失敗するようにします。
+- 検証されたレジャーでトランザクションの結果を確認します。
+  - トランザクションを含むレジャーが検証されるか、`LastLedgerSequence`が経過するまで、結果は暫定的です。
+  - 結果コードが**tesSUCCESS**で`"validated": true`のトランザクションは、恒久的に成功しています。
+  - 結果コードがそれ以外の場合で`"validated": true`のトランザクションは、恒久的に失敗しています。
+  - トランザクションの`LastLedgerSequence`によって識別された検証済みレジャーを含め、これまでの検証済みのレジャーに出現しないトランザクションは、恒久的に失敗しています。
+    - このようなケースを検出するために、レジャーの継続的な履歴を有するサーバを使用には注意してください<a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>。
+  - `LastLedgerSequence`で識別されるレジャーが検証されるまで、トランザクションの状態を繰り返し確認する必要がある場合があります。
+
+## 関連項目
+
+- **コンセプト:**
+  - [コンセンサスについて](index.md)
+  - [コンセンサスの研究](consensus-research.md)
+  - [コンセンサスの仕組み(動画)](https://www.youtube.com/watch?v=pj1QVb1vlC0)
+- **チュートリアル:**
+  - [信頼できるトランザクションの送信](../transactions/reliable-transaction-submission.md)
+  - [バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+- **リファレンス:**
+  - [レジャーフォーマットのリファレンス](../../references/protocol/ledger-data/index.md)
+  - [トランザクションフォーマットのリファレンス](../../references/protocol/transactions/index.md)
+  - [Consensus_infoメソッド][]
+  - [Validator_list_sitesメソッド][]
+  - [Validatorsメソッド][]
+
+
+
+
+
+## 脚注
+
+<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – [**tec**結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を持つトランザクションでは、要求されたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPの[トランザクションコスト](../transactions/transaction-cost.md)が消却されます。同じ送信者によって同時刻に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントの[シーケンス番号](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を都度増やしてゆきます。`tec`クラスの結果を持つトランザクションは、期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
+
+<a href="#from_footnote_2" id="footnote_2"><sup>2</sup></a> – 例えば、Aliceが100ドルを持っていて、全額をBobに送信するシナリオを考えてみましょう。アプリケーションは最初にPaymentトランザクションを送信し、Aliceの残高を確認したらすぐにAPIから0ドルが返されます。この値は、候補トランザクションの暫定結果に基づいています。支払いが失敗し、Aliceの残高が100ドルのままになる（または他のトランザクションによって別の金額になる）場合があります。AliceからBobへの支払いが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ結果コードが**tesSUCCESS**になるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャーにあるが、結果コードが異なる場合、支払いは失敗したことを意味します。
+
+<a href="#from_footnote_3" id="footnote_3"><sup>3</sup></a> – 厳密に言えば、バリデータは追跡サーバのサブセットです。同じ機能を提供することに加えて、「検証」メッセージを送信します。追跡サーバは、レジャー履歴全体を保持しているか、部分的なレジャー履歴を保持しているかによって、さらに分類することができます。
+
+<a href="#from_footnote_4" id="footnote_4"><sup>4</sup></a> – トランザクションを認識したピアの割合（%）がしきい値を下回った場合、コンセンサスのラウンドは失敗します。各ラウンドは反復プロセスです。第1ラウンドの開始時には、少なくともピアの50%が同意する必要があります。コンセンサスラウンドの最終的なしきい値は80%の合意です。これらの具体的な値は変更される可能性があります。
+
+<a href="#from_footnote_5" id="footnote_5"><sup>5</sup></a> – 各サーバは独自の信頼できるバリデータを定義しますが、ネットワークの一貫性は、様々なサーバで重複の度合いが高いバリデータのリストが選択されるかどうかにかかっています。このため、Rippleでは推奨するバリデータのリストを公開しています。
+
+<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[シビル攻撃](consensus-protections.md#シビル攻撃)から保護することができます。
+
+<a href="#from_footnote_7" id="footnote_7"><sup>7</sup></a> – 2014年11月の時点で、圧倒的多数を表すしきい値として、少なくともピアの80%が検証すべきレジャーに同意する必要があります。これは、コンセンサスのラウンドで要求される割合と同じです。いずれのしきい値も変更される可能性があり、同じである必要はありません。
+
+<a href="#from_footnote_8" id="footnote_8"><sup>8</sup></a> – 実際には、サーバは自身が少数であることを検知してから、すべてのピアの検証を受け取ります。ピアの20%以上から不一致の検証を受け取ると、その検証がしきい値の80%を満たしていないことが分かります。その時点で、レジャーの再計算を始めることができます。
+
+<a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – 実際には、効率的に実行できるように、検証の完了前に新しいコンセンサスのラウンドが開始されます。
+
+<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – `rippled`サーバはレジャーの履歴全体がなくてもAPIリクエストにレスポンスすることができます。サービスやネットワーク接続が中断すると、そのサーバのレジャー履歴にレジャーの不足や誤差が生じることがあります。時間の経過とともに、`rippled`によってその誤差は埋まります（そのように設定されている場合）。欠落しているトランザクションを検証する場合は、トランザクションが送信されてからLastLedgerSequenceまでの連続した完全なレジャーを持つサーバに照らして検証することが重要です。特定のサーバで利用できるcomplete_ledgersを判断するには、RPCサーバの状態を使用します。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/consensus-protocol/fee-voting.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/fee-voting.md
@@ -0,0 +1,49 @@
+---
+html: fee-voting.html
+parent: consensus.html
+seo:
+    description: トランザクションコストと必要準備金の変更投票について。
+labels:
+  - 手数料
+  - XRP
+---
+# 手数料投票
+
+バリデータは、基本の[トランザクションコスト](../transactions/transaction-cost.md)と[必要準備金](../accounts/reserves.md)の変更について投票できます。バリデータの構成の設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に公開します。定数のバリデータが変更に合意すると、変更を適用できるようになり、以後この変更が有効になります。バリデータはさまざまな理由から（特にXRPの価値の長期的な変化に適応するために）、この処理を行います。
+
+[`rippled`バリデータ](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)のオペレーターは、`rippled.cfg`ファイルの`[voting]`スタンザでトランザクションコストと必要準備金の設定を指定できます。
+
+{% admonition type="warning" name="注意" %}信頼できるバリデータの合意により不十分な必要準備金が採用された場合、XRP Ledgerピアツーピアネットワークがサービス拒否（DoS）攻撃を受ける可能性があります。{% /admonition %}
+
+設定できるパラメーターは次の通りです。
+
+| パラメーター | 説明 | 推奨される値 |
+|-----------|-------------|-------------------|
+| `reference_fee` | リファレンストランザクション（最も安価なトランザクション）を送信するときに消却する必要があるXRPの額（ _drop_ 単位）。（1 XRP = 100万drop）実際のトランザクションコストはこの値の数倍であり、個々のサーバの負荷に基づいて動的に調整されます。 | `10` （0.00001 XRP） |
+| `account_reserve` | アカウントの準備金に必要なXRPの最小額（ _drop_ 単位）。これは、レジャーの新しいアカウントへの資金供給のために送金できる最小額です。 | `10000000` （10 XRP） |
+| `owner_reserve` | アドレスがレジャーで所有するオブジェクト _ごと_ に必要なXRPの額（ _drop_ 単位）。 | `2000000` （2 XRP） |
+
+## 投票プロセス
+
+256番目の各レジャーは「フラグ」レジャーと呼ばれます。（フラグレジャーは`ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256`が`0`になるように定義されています。）フラグレジャーの直前のレジャーでは、アカウント準備金またはトランザクションコストの設定が現行のネットワーク設定と異なる各バリデータは、そのレジャー検証とともに「投票」メッセージを配信し、バリデータが希望する値を示します。
+
+フラグレジャー自体では何も起こりませんが、バリデータは信頼する他のバリデータからの投票を受信して記録します。
+
+他のバリデータの投票を集計した後、各バリデータは自身の設定と信頼する過半数のバリデータの設定の間で妥協点を探ります。（たとえば、あるバリデータが最小トランザクションコストを10から100に引き上げることを望む一方で、ほとんどのバリデータは10から20に引き上げることを望んでいる場合、そのバリデータは当該のコストを20に引き上げることにします。ただし、そのバリデータは10未満の値または100を超える値にすることはありません。）妥協できる場合、バリデータはフラグレジャーの直後のレジャーに対する提案に[SetFee疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/setfee.md)を挿入します。同じ変更を求める他のバリデータは、同じレジャーに対する各自の提案に同じSetFee疑似トランザクションを挿入します。（設定が既存のネットワーク設定と一致している場合、バリデータは何も行いません。）SetFee疑似トランザクションがコンセンサスプロセスを通過し、検証済みレジャーに追加される場合、SetFee疑似トランザクションで設定された新しいトランザクションコストと準備金の設定がその次のレジャーから有効になります。
+
+まとめ:
+
+* **フラグレジャー-1**: バリデータが投票を送信します。
+* **フラグレジャー**: バリデータが投票を集計し、どのSetFeeの内容を含めるか決定します（存在する場合）。
+* **フラグレジャー+1**: バリデータは、SetFee疑似トランザクションを各自の提案レジャーに挿入します。
+* **フラグレジャー+2**: SetFee疑似トランザクションがコンセンサスに達すると、新しい設定が有効になります。
+
+## 手数料の最大値
+
+手数料の最大可能値は、[FeeSettingsレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)に保管されている内部データ型により制限されます。これらの値は次のとおりです。
+
+| パラメーター | 最大値（drop） | 最大値（XRP）
+|-----------|-----------------------|----|
+| `reference_fee` | 2**64 | （これまでに存在したXRP総額よりも大きい） |
+| `account_reserve` | 2^32 drop | 約4294 XRP |
+| `owner_reserve` | 2^32 drop | 約4294 XRP |
--- a/@l10n/ja/docs/concepts/consensus-protocol/index.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/index.md
@@ -0,0 +1,70 @@
+---
+html: consensus.html
+parent: concepts.html
+seo:
+    description: XRP Ledgerのコンセンサスメカニズムについて基本的な理解を深めましょう。
+labels:
+  - ブロックチェーン
+top_nav_grouping: 人気ページ
+---
+# コンセンサスプロトコル
+
+ _コンセンサス_ は、分散型決済システムの最も重要な特性です。従来の中央集権型決済システムでは、権限のある1人の管理者が決済の方法とタイミングについて最終的な決定権を持ちます。分散型システムでは、その名が示すとおり、そのような管理者は存在しません。その代わりに、XRP Ledgerのような分散型システムでは、参加者は定められた一連のルールに従うことになっているため、同じ一連のイベントとその結果についていつでも合意することができます。この一連のルールは、 _コンセンサスプロトコル_ と呼ばれます。
+
+
+## コンセンサスプロトコルの特性
+
+従来のデジタル資産と異なり、XRP Ledgerでは、コンセンサスプロトコルを使用します。このプロトコルは、XRP Ledger コンセンサスプロトコルと呼ばれ、次の重要な特性を持つように設計されています。
+
+- XRP Ledgerを使用するユーザは誰でも、最新の台帳や、どのような取引がどのような順番で発生したかについて同意することができます。
+- 中央のオペレーター無しに、有効な取引を処理することができます。また、障害が1か所に集中することもありません。
+- 一部の参加者が不適切に参加、退去、または行動した場合でも、取引の処理は続行します。
+- 多数の参加者がアクセスできない場合や、多数が不適切に行動している場合は、無効な取引を分離したり確認したりする代わりに、ネットワークは処理を停止します。
+- 取引の確認のために、リソースを無駄に使ったり取り合う必要もありません。この点は、他の一般的なブロックチェーンシステムとは異なります。
+
+これらの特性は、次の3原則としてまとめられます。優先順位の高い順に示します。**正確さ、合意、処理の継続**
+
+このプロトコルはまだ発展段階にあり、その限界と起こり得る障害についての知識もまだ蓄積中です。プロトコル自体に関する学術研究については、[コンセンサスリサーチ](consensus-research.md)をご覧ください。
+
+## 背景
+
+コンセンサスプロトコルは、_二重支払いの問題_、つまり同じデジタルマネーを2回使用することを防ぐという課題に対する解決策です。この問題において最も困難なのは、取引を順序立てる点です。中央管理者がいない中で、同時に複数の相互排他的取引が送信されたときに、先に到着したのはどの取引なのかという紛争を解決するのは困難です。二重支払いの問題や、XRP Ledger コンセンサスプロトコルでこの問題を解決する方法、およびそれに伴うトレードオフと制限事項の詳細な分析については、[コンセンサスの原理とルール](consensus-principles-and-rules.md)をご覧ください。
+
+
+## レジャー（台帳）履歴
+
+XRP Ledgerは、「レジャーバージョン」、または略して「レジャー」と呼ばれるブロックで取引を処理します。レジャーの各バージョンには、次の3つの部分が含まれています。
+
+- レジャーに保存されているすべての残高とオブジェクトの現在の状態。
+- このレジャーにつながる、以前のレジャーに適用された一連の取引。
+- レジャーインデックスや、その内容を一意に識別する[暗号化ハッシュ](https://en.wikipedia.org/wiki/Cryptographic_hash_function)、およびこのレジャーを構築するための基盤として使用された親レジャーに関する情報など、現行のレジャーバージョンに関するメタデータ。
+
+[![図1: レジャーバージョンの構造（取引、状態、およびメタデータを含む）](/docs/img/anatomy-of-a-ledger-simplified.ja.png)](/docs/img/anatomy-of-a-ledger-simplified.ja.png)
+<!--{# Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/ #}-->
+
+レジャーの各バージョンには _レジャーインデックス_ としての番号が付けられており、インデックスが1つ前のレジャーバージョンを基に新たな情報を追加する形で作成されています。一番最初まで遡ると、レジャーインデックスが1の _ジェネシスレジャー_ と呼ばれる出発点に戻ります。[¹](#footnote-1)これにより、Bitcoinや他のブロックチェーン技術と同様に、すべての取引とその結果についての公開履歴が形成されます。多くのブロックチェーン技術とは異なり、XRP Ledgerの新しい「ブロック」には現在の状態がすべて含まれているため、現在起こっている内容を把握するために履歴全体を収集する必要はありません。[²](#footnote-2)
+
+XRP Ledger コンセンサスプロトコルの主な役割は、前のレジャーに適用する一連の新しい取引に合意し、それらを明確に定義された順序で適用した上で、全員が同じ結果を得たことを確認することです。これが正常に行われると、レジャーバージョンは _検証済み_ 、および確定したとみなされます。続いて、次のレジャーバージョンが構築されます。
+
+
+## 信頼に基づく検証
+
+XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな効果を生み出すという基本的な原理に支えられています。ネットワークの各参加者は、一連の _バリデータ_ （検証者）を選択します。バリデータは常に誠実に行動することが期待されるさまざまな当事者によって運営されており、[コンセンサスにアクティブに参加するように特別に設定されたサーバ](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)上に存在します。さらに重要なことは、選択された一連のバリデータが互いに共謀して同じ方法を使ってルールを破ることはないということです。この一連バリデータのリストは、_ユニークノードリスト_（UNL）とも呼ばれます。
+
+ネットワークが更新する中で、各サーバは信頼できるバリデータ[³](#footnote-3)をモニターします。十分な数のバリデータが、一連の取引の発生を確認し、特定のレジャーにその結果が反映されたことに同意した場合、サーバによってコンセンサスが宣言されます。バリデータ間で同意が得られない場合、バリデータは信頼する他のバリデータとの間での意見の一致に向けて提案を修正します。このプロセスは、コンセンサスに達するまで何度か繰り返されます。
+
+[![図2: コンセンサスラウンドバリデータは信頼する他のバリデータとの間での意見の一致に向けて提案を修正します。](/docs/img/consensus-rounds.ja.png)](/docs/img/consensus-rounds.ja.png)
+
+常に正しく行動しないバリデータが一部存在しても問題ありません。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%未満である場合は、制限なくコンセンサスは継続します。また、無効な取引を確認するには、信頼できるバリデータの80%以上が合意する必要があります。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%以上80%未満である場合、ネットワークは停止します。
+
+XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.md)をご覧ください。
+
+----
+
+## 脚注
+
+1. <a id="footnote-1"></a>XRP Ledgerの運用開始当初に起きた事故により、[1～32569番目までのレジャーが失われました](http://web.archive.org/web/20171211225452/https://forum.ripple.com/viewtopic.php?f=2&t=3613)。（この損失はレジャー履歴の第1週目に発生しています。）このため、現存する一番最初のレジャーは番号32570のレジャーです。XRP Ledgerの状態はすべてのレジャーバージョンに記録されるため、履歴がなくても継続することができます。新しいテストネットワークでは、レジャーインデックス1から始まります。
+
+2. <a id="footnote-2"></a>Bitcoinでは、現在の状態は「UTXO」（Unspent Transaction Outputの略）と呼ばれることもあります。XRP Ledgerとは異なり、BitcoinサーバではすべてのUTXOを把握し、新しい取引を処理できるように、トランザクション（取引）履歴全体をダウンロードする必要があります。2018年現在、Bitcoinの新しいサーバでこれを行う必要がないように、最新のUTXOのサマリーを定期的に提供するようコンセンサスメカニズムを修正する提案がいくつかあります。EthereumはXRP Ledgerと類似したアプローチを使用しており、各ブロックには、 _状態ルート_ と呼ばれる現在の状態のサマリーがありますが、Ethereumは巨大な状態データを蓄積しているため同期するにはXRP Ledgerよりもより多くの時間を要します。
+
+3. <a id="footnote-3"></a>信頼できるバリデータをモニターするにあたり、サーバが直接それに接続する必要はありません。XRP Ledgerのピアツーピアネットワークでは、サーバが公開鍵によって互いを識別し、他のサーバからのデジタル署名付きメッセージを中継する _ゴシッププロトコル_ によってモニターします。
--- a/@l10n/ja/docs/concepts/consensus-protocol/invariant-checking.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/invariant-checking.md
@@ -0,0 +1,152 @@
+---
+html: invariant-checking.html
+parent: consensus.html
+seo:
+    description: 不変性チェックとは何か、なぜ存在するのか、どのように機能するのか、どのような不変性チェックが有効なのかを理解することができます。
+labels:
+  - ブロックチェーン
+  - セキュリティ
+---
+# 不変性チェック
+
+不変性チェックは、XRP Ledgerの安全機能です。これは、通常のトランザクション処理とは別に、すべての取引において特定の「不変量」が真であることを保証する一連のチェックで構成されています。
+
+多くの安全機能がそうであるように、私たちは不変性チェックが実際に何もする必要がないことを望んでいます。しかし、XRP Ledger の不変量は XRP Ledger のトランザクション処理に対するハードリミットを定義しているため、それを理解することは有用であり、万が一不変量チェックに違反したためにトランザクションが失敗した場合に問題を認識するために有用です。
+
+不変性はトリガーされるべきではありませんが、まだ発見されていない、あるいは作成されてもいないバグからXRP Ledgerの整合性を確保するものです。
+
+
+## なぜ存在するのか
+
+- XRP Ledgerのソースコードは複雑かつ膨大であり、コードが誤って実行される可能性が高いです。
+- トランザクションを誤って実行した場合のコストは高く、どのような基準でも許容されるものではありません。
+
+具体的には、不正なトランザクションの実行により、無効または破損したデータが作成され、後にネットワーク上のサーバを「動作不可能」な状態にすることで一貫してクラッシュさせ、ネットワーク全体を停止させる可能性があります。
+
+不正なトランザクションの処理は、XRP Ledgerの信頼という価値を損なうことになります。不変性チェックは、信頼性という機能を付加するため、XRP Ledger 全体に価値を提供します。
+
+
+
+## 仕組み
+
+不変性チェッカーは、各トランザクションの後にリアルタイムで自動的に実行される第2層のコードです。トランザクションの結果がレジャーにコミットされる前に、不変性チェッカーはそれらの変更が正しいかどうかを検証します。もしトランザクションの結果がXRP Ledgerの厳格なルールに沿わない場合、不変性チェッカーはそのトランザクションを拒否します。このように拒否されたトランザクションは結果コード `tecINVARIANT_FAILED` を持ち、何の効果もなくレジャーに含まれます。
+
+トランザクションを `tec` クラスのコードでレジャーに含めるには、何らかの最小限の処理が必要です。この最小限の処理でも不変条件に沿わない場合、トランザクションは `tefINVARIANT_FAILED` というコードで失敗し、レジャーには一切含まれません。
+
+
+## 有効な不変条件
+
+XRP Ledgerは、各トランザクションについて、以下のすべての不変条件をチェックします。
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "ソース")
+
+- [トランザクション手数料チェック](#トランザクション手数料チェック)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "ソース")
+
+- [XRPは作成されません](#xrpは作成されません)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "ソース")
+
+- [アカウントルートが削除されていない](#アカウントルートが削除されていない)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "ソース")
+
+- [XRPの残高確認](#xrpの残高確認)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "ソース")
+
+- [レジャーエントリ形式の一致](#レジャーエントリ形式の一致)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "ソース")
+
+- [XRPのトラストラインはありません](#xrpのトラストラインはありません)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "ソース")
+
+- [不正なオファーでない](#不正なオファーでない)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "ソース")
+
+- [0のエスクローでない](#0のエスクローでない)
+
+[[ソース]](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "ソース")
+
+- [有効な新規アカウントルート](#有効な新規アカウントルート)
+
+
+### トランザクション手数料チェック
+
+- **不変条件:**
+    - [トランザクションコスト](../transactions/transaction-cost.md)の金額は決してマイナスになってはならず、またトランザクションで指定されたコストより大きくなってはいけません。
+
+
+### XRPは作成されません
+
+- **不変条件:**
+    - トランザクションはXRPを生成してはならず、XRPを破棄するのみです[トランザクションコスト](../transactions/transaction-cost.md)。
+
+
+### アカウントルートが削除されていない
+
+- **不変条件:**
+    - [アカウント](../accounts/index.md)は、[AccountDeleteトランザクション][]によってのみレジャーから削除することができます。
+    - AccountDelete が成功すると、常にちょうど1つのアカウントが削除されます。
+
+
+### XRPの残高確認
+
+- **不変条件:**
+    - アカウントのXRP残高はXRPの形式である必要があり、0未満または1000億XRPを超えることはできません。
+
+
+### レジャーエントリ形式の一致
+
+- **不変条件:**
+    - 変更されたレジャーの項目は形式が一致し、追加された項目は[有効なタイプ](../../references/protocol/ledger-data/ledger-entry-types/index.md)である必要があります。
+
+
+### XRPのトラストラインはありません
+
+- **不変条件:**
+    - XRPを使用した[トラストライン](../tokens/fungible-tokens/index.md)は作成できません。
+
+
+### 不正なオファーでない
+
+- **不変条件:**
+    - [オファー](../../references/protocol/ledger-data/ledger-entry-types/offer.md)は負でない金額でなければならず、XRP同士であってはいけません。
+
+
+### 0のエスクローでない
+
+- **不変条件:**
+    - [エスクロー](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)エントリは、0XRP以上1000億XRP未満を保有している必要があります。
+
+
+### 有効な新規アカウントルート
+
+- **不変条件:**
+    - 新しい[アカウントルート](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)は、支払いの結果でなければなりません。
+    - 新しいアカウントルートは、正しい開始[シーケンス](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を持たなければなりません。
+    - 1つのトランザクションで複数の新しい[アカウント](../accounts/index.md)を作成してはいけません。
+
+
+## 関連項目
+
+- **ブログ:**
+    - [レジャーの保護: 不変性チェック](https://xrpl.org/blog/2017/invariant-checking.html)
+
+- **リポジトリ:**
+    - [Invariant Check.h](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
+    - [Invariant Check.cpp](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
+    - [System Parameters](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
+    - [XRP Amount](https://github.com/XRPLF/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
+    - [Ledger Formats](https://github.com/XRPLF/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
+
+
+- **その他:**
+    - [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md)
+    - [トランザクションの残高変化の計算](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/consensus-protocol/negative-unl.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/negative-unl.md
@@ -0,0 +1,177 @@
+---
+html: negative-unl.html
+parent: consensus.html
+seo:
+    description: ネガティブUNLが部分的な停止時に台帳の耐障害性を向上させることを理解する。
+labels:
+  - ブロックチェーン
+---
+# ネガティブUNL
+
+_([NegativeUNL Amendment](/resources/known-amendments.md#negativeunl)によって追加されました。)_
+
+ネガティブUNLは、XRP Ledgerの[コンセンサスプロトコル](index.md)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい[レジャーバージョン](../ledgers/index.md) を _validated_ と宣言することができるようになるのです。
+
+ネガティブUNLは、部分的な停止中に結果を確定するネットワークの能力を向上させる以外、ネットワークのトランザクション処理方法やトランザクションの結果に影響を与えることはありません。
+
+## 背景
+
+XRP Ledgerプロトコルの各サーバは、UNL（Unique Node List）と呼ばれる、共謀しないよう信頼できるバリデータのリストを持ち、各サーバは、信頼できるバリデータが十分に新しいレジャーバージョンに合意したときのコンセンサスに基づいて、レジャーバージョンの検証を独自に決定しています。(デフォルトの構成では、リップル社が十分にユニークで信頼性が高く、独立性が高いと考えるバリデータからなる、リップル社が署名した推奨UNLを使用しています)。標準的な定足数要件は、信頼できるバリデータの少なくとも80%が合意することである。
+
+信頼できるバリデータの20%超がオフラインになるか、ネットワークの残りの部分と通信できなくなると、ネットワークは定足数に達しないため、新しいレジャーの検証を停止する。これは、取引の結果が確定した後に変更されないようにするための設計上の選択である。このような状況では、残りのサーバはまだオンラインであり、過去および暫定的なトランザクションデータを提供できるが、新しいトランザクションの最終的で不変の結果を確認することはできない。
+
+しかしこれは、広く信頼されているバリデータがいくつかオフラインになった場合、ネットワークが前進しなくなる可能性があることを意味する。2020-10-06現在、リップル社が推奨するUNLには34人のバリデータがいるので、そのうち7人以上がオフラインになると、ネットワークの前進が止まってしまうことになります。さらに、1人または2人のバリデータが長期間オフラインになると、ネットワークは残りのバリデータ間の不一致の余地が少なくなり、コンセンサスの達成に時間がかかる可能性があります。
+
+## 要約
+
+ハードウェアのメンテナンス、ソフトウェアのアップグレード、インターネット接続の問題、標的型攻撃、人為的ミス、ハードウェアの故障、自然災害などの外部環境など、多くの原因でバリデータは一時的に利用できなくなる可能性があるため、多様なバリデータのセットで100%の稼働時間を維持を期待することは合理的ではありません。
+
+「ネガティブUNL」とは、**オフラインまたは故障していると思われる信頼できるバリデータのリスト**であり、残存バリデータの総意として宣言されるものである。ネガティブUNLに含まれるバリデータは、新しいレジャーのバージョンがコンセンサスを得たかどうかを判断する際には無視される。
+
+ネガティブUNL上のバリデータがオンラインに復帰し、一貫性のある検証投票を送信すると、残りのバリデータはしばらくしてそのバリデータをネガティブUNLから削除します。
+
+バリデータが一度に1つか2つオフラインになった場合、残りのバリデータはネガティブUNLを使用して、徐々に有効UNLを調整し、ネットワークが定足数を達成するのに _オンライン_ バリデータの80%しか必要としないようにすることができる。ネットワークが分断されるのを防ぐため、定足数はバリデータ _全体_ の60%以上というハードな最低値を持つ。
+
+20%以上のバリデータが突然一度にオフラインになった場合、残りのサーバは新しいレジャーを検証するのに必要な定足数を達成できないため、新しいレジャーを検証することができない。しかし、そのようなサーバでも、コンセンサスラウンドを重ねることで暫定的な前進は可能である。時間が経つにつれて、残りのバリデータは暫定的なレジャーにネガティブUNLの変更を適用し、有効なUNLを調整し続ける。最終的に、この状況が続けば、ネットワークは暫定的なレジャーのバージョンから調整後のネガティブUNLを使用して、レジャーの検証を完全に再開することが可能である。
+
+スタンドアロンモードでは、サーバはコンセンサスを使用しないので、ネガティブUNLは[スタンドアロンモード](../networks-and-servers/rippled-server-modes.md)に影響を及ぼさない。
+
+## 仕組み
+
+ネガティブUNLは[コンセンサスプロセス](index.md)と密接に関連し、不利な状況下でもネットワークの継続性と信頼性を維持できるように安全策をとって設計されたものである。すべての信頼できるバリデータが正常に動作している場合、ネガティブUNLは使用されず、何の効果もない。一部のバリデータがオフラインまたは同期していないように見えるとき、ネガティブUNLルールは有効になる。
+
+ネガティブUNLは意図的にゆっくりとした速度で変化するように設計されており、あるバージョンのレジャーの合意形成プロセスにおいて、どのネガティブUNLを適用すべきかという時間ベースの不一致を回避するためである。
+
+
+### 信頼性評価
+
+ネットワーク上の各サーバは、共謀しないように信頼するバリデータのリストであるUNLを持っています。(デフォルトでは、サーバの正確なUNLはリップル社が公表している推奨バリデータリストに基づいて暗黙的に設定されます)。各サーバは、信頼できるバリデータの「信頼性」を1つの指標で追跡します。それは、直近256件のレジャーのうち、バリデータの検証投票がサーバの考えるコンセンサスと一致した割合です。言い換えれば
+
+> 信頼性 = V<sub>a</sub> ÷ 256
+
+V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去256のレジャーに対して、1人のバリデータから受け取った検証票の総数である。
+
+この信頼性指標は、バリデータの可用性 _及び_ バリデータの挙動を測定するものである。バリデータがネットワークの他の部分と同期しており、採点サーバと同じプロトコル規則に従っている場合、そのバリデータの信頼性スコアは高くなるはずである。バリデータの信頼性スコアは、以下のような理由で低下することがある。
+
+- バリデータ間のネットワーク接続が悪いため、バリデータの検証票がサーバに届かない。
+- バリデータが動作を停止したり、過負荷になっている。
+- 様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に[異なるネットワーク](../networks-and-servers/parallel-networks.md)に従っている、または悪意ある行動などが考えられます。
+
+バリデータの信頼性が**50%**である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が**80%超**でなければならない。
+
+バリデータを含む各サーバは、信頼できるバリデータ全員について独自に信頼性スコアを算出している。あるバリデータの信頼性について、サーバが異なると結論が異なることがある。それは、そのバリデータの投票が一方のサーバに届いて他方のサーバに届かなかったり、特定のレジャーについて意見が異なることが多かったり少なかったりするためである。あるバリデータをネガティブUNLに追加または削除するには、信頼できるバリデータの総意として、あるバリデータが信頼性の閾値を超えるか下回るかに合意する必要がある。
+
+{% admonition type="success" name="ヒント" %}バリデータは自分自身の信頼性を追跡するが、自分自身をネガティブUNLに加えることは提案しない。バリデータの信頼性測定は、バリデータの投票がネットワークを通じてどの程度うまく伝わるかを考慮できないので、外部のサーバからの測定値よりも信頼性が低い。{% /admonition %}
+
+
+
+### ネガティブUNLの変更
+
+レジャーバージョンが256で均等に割り切れる場合、_フラグレジャー_ とみなされます。ネガティブUNLはフラグレジャーでのみ変更可能です。(フラグレジャーは、XRP Ledgerメインネットで約15分に1回発生します。トランザクション量の少ないテストネットワークでは、もっと低頻度な場合があります)
+
+各フラグレジャーは、以下の全ての変更が適用されます。
+
+1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
+
+    {% admonition type="info" name="注記" %}これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)を行わずにレジャーの状態データを変更する唯一の機会です。{% /admonition %}
+
+2. ネガティブUNLが満杯でない場合、各サーバは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
+3. ネガティブUNLが空でない場合、各サーバはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
+    - バリデータの信頼度が80%を超えている。
+    - 自身のUNLにそのバリデータを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
+4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
+
+ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。
+
+ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)に追跡される。
+
+
+### ネガティブUNLの制限
+
+ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバはネガティブUNL上のバリデータ数がサーバの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが"満杯"になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。
+
+
+### 複数のバリデータ候補から選択する
+
+信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバはどのバリデータを追加するかを選択しなければならない。複数の候補がある場合、サーバは以下のメカニズムでどの候補を提案するかを選択する。
+
+1. 親レジャーバージョンのレジャーハッシュを取得する。
+0. 各バリデータ候補の公開鍵を取得する。
+0. 候補のバリデータと親レジャーのハッシュの排他的論理和(XOR)を計算する。
+0. XOR演算の結果のうち、数値が最も小さいバリデータを提案する。
+
+あるフラグレジャーのネガティブUNLから削除される候補が複数ある場合、サーバは同じメカニズムでそれらの中から選択します。
+
+このメカニズムには、いくつかの有用な特性があります。
+
+- すべてのサーバが容易に入手でき、かつ迅速に計算できる情報を使用する。
+- 信頼できるバリデータのスコアが多少異なっていても、ほとんどのサーバは同じ候補を選択する。これは、どのバリデータの信頼度が「最低」なのか「最高」なのかについて、 サーバ間で見解の相違があったとしても同様である。これは、あるバリデータが信頼性の閾値より上か下かについて、各サーバが意見を異にしている場合でさえも同様である。したがって、ネットワークは、どのバリデータを追加または削除するかについて、合意が得られる可能性が高い。
+- レジャーバージョンごとに同じ結果が出るとは限りません。もしネガティブUNLへのある変更案が合意に至らなかったとしても、ネットワークは毎回その1つのバリデータの追加や削除を試みて失敗し続けることはない。ネットワークは、後のフラグ付きレジャーで別の候補をネガティブUNLに追加・削除することを試みることができる。
+
+
+### 検証のフィルタリング
+
+[コンセンサスプロセスの検証ステップ](consensus-structure.md#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
+
+{% admonition type="info" name="注記" %}ネガティブUNLは、定足数を直接計算するのではなく、定足数の計算元となる信頼できるバリデータの合計を調整するものです。定足数はパーセンテージですが、投票数は整数であるため、信頼できるバリデータの合計を減らしても、定足数に達するために必要な投票数が変わるとは限りません。たとえば、総バリデータが15人である場合、80%はちょうど12人のバリデータである。これを14人に減らすと、80%は11.2人となり、定足数に達するには依然として12人の有効投票者が必要である。{% /admonition %}
+
+ネガティブUNLは、提案されたトランザクションセットにどのトランザクションを含めるかを選択するなど、コンセンサスプロセスの他の部分には影響を与えない。これらのステップは常に設定されたUNLに依存し、その閾値は何人の信頼できるバリデータがコンセンサスラウンドに積極的に参加しているかに基づいている。ネガティブUNLにあるバリデータもコンセンサスプロセスに参加することができる。
+
+### 例
+
+次の例は、ネガティブUNLが合意形成プロセスにどのような影響を与えるかを示している。
+
+1. サーバのUNLが38人の信頼できるバリデータで構成されているとすると、80%の定足数は38人のうち少なくとも31人の信頼できるバリデータである。
+
+[{% inline-svg file="/docs/img/negative-unl-01.ja.svg" /%}](/docs/img/negative-unl-01.ja.svg "Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。")
+
+2. MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。)レジャー _N_ の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデータのうち少なくとも31人の定足数で可決され、レジャー _N_ はUnsteadyBを無効化する予定で有効になった。
+
+[{% inline-svg file="/docs/img/negative-unl-02.ja.svg" /%}](/docs/img/negative-unl-02.ja.svg "Diagram: UnsteadyBは無効になる予定。")
+
+
+3. レジャー _N+1_ から _N+256_ については、コンセンサスプロセスをそのまま継続する。
+
+4. 次のフラグレジャー _N+256_ では、UnsteadyBはレジャーの「予定」から「無効」リストへ自動的に移動する。また、MissingAがまだオフラインであるため、検証者の総意として、次のフラグレジャーでMissingAを無効化する予定とする。
+
+[{% inline-svg file="/docs/img/negative-unl-04.ja.svg" /%}](/docs/img/negative-unl-04.ja.svg "UnsteadyBが無効化され、MissingAも無効化される予定。")
+
+5. レジャー _N+257_ から _N+512_ について、定足数は37名中30名となった。
+
+6. UnsteadyBがレジャー _N+270_ でオンラインに復帰。レジャー _N+270_ から _N+511_ に対してネットワークの他の部分と一致する検証票を送信し、信頼性スコアが80%以上となる。
+
+[{% inline-svg file="/docs/img/negative-unl-06.ja.svg" /%}](/docs/img/negative-unl-06.ja.svg "Diagram: UnsteadyBがオンラインに戻るが、まだ無効化されている。")
+
+7. 次のフラグレジャー _N+256_ では、予定通りMissingAが自動的に無効リストに移される。一方、UnsteadyBは信頼性スコアが向上したため、検証者の総意としてネガティブUNLから削除される予定である。
+
+[{% inline-svg file="/docs/img/negative-unl-07.ja.svg" /%}](/docs/img/negative-unl-07.ja.svg "Diagram: MissingAを無効化し、UnsteadyBを再有効化する予定。")
+
+8. レジャー _N+513_ から _N+768_ の場合、定足数は36人中29人である。MissingAがオフラインの間、UnsteadyBは安定的に検証結果を送り続ける。
+
+9. フラグレジャー _N+768_ では、予定通りUnsteadyBが無効リストから自動的に削除されています。
+
+[{% inline-svg file="/docs/img/negative-unl-09.ja.svg" /%}](/docs/img/negative-unl-09.ja.svg "Diagram: UnsteadyBを無効リストから削除。")
+
+10. 最終的に、あなたはMissingAがおそらく戻ってこないと判断し、あなたのサーバの設定されたUNLからそれを削除します。あなたのサーバはそれ以降、各フラグレジャーからMissingAをネガティブUNLから削除することを提案し始める。
+
+[{% inline-svg file="/docs/img/negative-unl-10.ja.svg" /%}](/docs/img/negative-unl-10.ja.svg "Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。　")
+
+11. バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者はネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。
+
+[{% inline-svg file="/docs/img/negative-unl-11.ja.svg" /%}](/docs/img/negative-unl-11.ja.svg "Diagram: MissingAをネガティブUNLから削除。")
+
+
+### 関連項目
+
+- **コンセンサス:**
+    - [コンセンサスプロトコル](index.md)
+- **チュートリアル:**
+    - [Testnetや別の並列ネットワークへ接続する](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
+    - [バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+- **リファレンス:**
+    - [negativeUNL オブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)
+    - [UNLModify pseudo-transaction][]
+    - [ledger_entry メソッド][]
+    - [consensus_info メソッド][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/consensus-protocol/unl.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/unl.md
@@ -0,0 +1,36 @@
+# UNL (Unique Node List)
+
+UNL(_Unique Node List_)は、サーバが共謀しないと信頼するバリデータのリストです。すべてのXRP Ledgerサーバは、UNLを設定しており、これにより、どのバリデータによる投票を監視対象とするか、どの投票をコンセンサスプロセス中に破棄するかが決まります。設計上、UNL内の各エントリは独立したエンティティを表す必要があります。これらのエンティティは、企業や大学、他の種類の組織、または個人である可能性があります。各エントリが別々のエンティティであることにより、誰もがネットワークを正常に維持するための最小限の責任しか負いません。
+
+バリデータは公平であることが意図されており、技術の制約内で可能な限り早くすべてのトランザクションを処理することが求められます。バリデータは、任意の理由でいくつかのトランザクションをブロックしたり検閲したりしてはいけません。なぜなら、それはネットワークが合意に達するのを妨げるからです。さらに重要なのは、バリデータが可能な限りオンラインで稼働していることです。ただし、XRP Ledgerは、ネットワークやバリデータ自体の欠陥を許容するように設計されています。一部のバリデータがオフラインであったり誤った設定、バグが存在、または明らかに悪意のある場合でも、大多数のバリデータが正常に動作していればネットワークは進行できるように設計されており、超多数(80％超)が同意しない限りネットワークは過去の履歴やルールと矛盾するトランザクションを受け入れることはありません。これらの点が考慮され、UNL内のバリデータは、多くのバリデータが同じ方法で同時に失敗する可能性を最小限に抑えるために選択されます。
+
+## UNLの重複
+
+各サーバの運用者は、どのバリデータが自分のUNLに設定されるかを完全にコントロールできます。しかし、2つのサーバが全く異なるUNLで動作している場合、台帳（およびその中のトランザクション）がどのように検証されるかについて、異なる結論に達する可能性があります。フォークが起きると、異なる立場の当事者は何が起きたかについて相互に合意することができず、互いに取引することができなくなります。フォークを回避するために、XRP Ledgerのサーバは、互いに重複度の高いUNLで構成される必要があります。
+
+当初は、2つのサーバ間に60％の重複があれば、それらのサーバがフォークするのを防ぐのに十分であると信じられていました。しかし、[さらなる研究](./consensus-research.md)では最悪の場合、フォークを防ぐには90％の重なりが必要であることを示しました。他の人が使っているUNLとの重複が少ないほど、フォークする可能性が高くなります。
+
+## 推奨バリデータリスト
+
+他のバリデータと重複の少ない、多様で信頼できるバリデータリストを簡単に入手するために、XRP Ledgerは推奨バリデータリストの方式を採用しています。あるサーバは、_発行者_ から推奨リストをダウンロードし、そのリストをUNLとして使用するように設定することができます。つまり、サーバのUNLは、公開されているリストのいずれかに登録されているすべてのバリデータで構成されます。同一バリデータが複数のリストに登録されている場合でも、サーバのUNLには一度しか登録されません。
+
+推奨リストはその発行者の公開鍵によって証明されます。通常、推奨リストはダウンロード可能なウェブサイトに関連付けられていますが、ウェブサイトへのアクセスに問題がある場合に備えて、ピアツーピアネットワークを介してリストを中継することもできます。
+
+現在、XRP Ledgerサーバのデフォルト設定では、XRP Ledger Foundationが公開するリストとRippleが公開するリストの2つを使用しています。通常、これらのリストは互いに非常に似ているか、あるいは同一です。_デフォルトUNL_ (dUNLと略されることもあります)という用語は、デフォルト設定で指定された単一または複数のリストに含まれるバリデータのセットを指します。
+
+誰でも署名付きバリデータリストを適切な形式で公開することができます。これは、署名付きバイナリデータを含むJSONドキュメントです。推奨されるリストの形式についての詳細は、[Validator Listメソッド](/ja/docs/references/http-websocket-apis/peer-port-methods/validator-list/)をご覧ください。
+
+推奨バリデータリストは時間の経過とともに更新する必要があり、より質の高いバリデータを追加したり、信頼性の低いバリデータや撤退するバリデータを削除したりします。通常、推奨バリデータリストには有効期限があり、その期限までに更新が行われることが期待されています。リストにはシーケンス番号もあり、最も高いシーケンス番号がそのリストの最新のバージョンとなり、古いバージョンは無効になります。また、サーバがいつ新しいバージョンに切り替えるかを指定し、更新されたリストがそれを使うすべてのサーバに伝搬する時間を確保できるように、有効日を設定することができます。
+
+発行者は日常的な新しいトランザクションの検証には関与しませんが、どのバリデータが広く信頼されるかを選択する上で大きな力を行使します。サーバ運用者は、どのバリデータリスト発行者を選択するかを慎重に決めるべきです。発行者の不注意が、そのリストを使用するサーバの信頼性に影響を与える可能性があるからです。
+
+## バリデーターを推奨リストに登録する方法
+
+それぞれの発行者は掲載されるための独自の基準を定義できます。しかし、通常、バリデータが発行者の推奨リストに追加されるためには次のような基準があります。
+
+- 少なくとも1年間の稼働率が高く、他のネットワークと高い整合性を持つ
+- [ドメイン検証](/ja/docs/references/xrp-ledger-toml/#domain-verification)を行なっている
+- 既にバリデータを運営している会社の従業員などではなく、XRP Ledgerのコミュニティにおいて独立し認知された存在である
+- 他のバリデータと物理的に独立した場所で運用されている(例えば、1つのデータセンターで障害が発生した場合に、多くのバリデータがダウンすることが無いように)
+
+バリデータリストの運用者は、推奨リストに掲載する候補者と面談を行い、その候補者がこれらの要件およびその他の要件を満たしていること、また、将来にわたってサーバの運用を継続することを保証できることを確認することができます。
--- a/@l10n/ja/docs/concepts/index.md
+++ b/@l10n/ja/docs/concepts/index.md
@@ -0,0 +1,13 @@
+---
+html: concepts.html
+parent: docs.html
+top_nav_grouping: カテゴリ
+metadata:
+  indexPage: true
+---
+# コンセプト
+
+XRP Ledgerの基本的な部分の背景に「何があるか」、「なぜなのか」を学びましょう。
+
+
+{% child-pages /%}
--- a/@l10n/ja/docs/concepts/ledgers/index.md
+++ b/@l10n/ja/docs/concepts/ledgers/index.md
@@ -0,0 +1,35 @@
+---
+html: ledgers.html
+parent: concepts.html
+seo:
+    description: XRP Ledgerは、rippledによって内部データベースに保持されている一連の個別レジャー(レジャーバージョン)で構成されています。これらのレジャーの構造と内容について説明します。
+labels:
+  - ブロックチェーン
+  - データ保持
+---
+# レジャー
+
+XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャー)です。個々の参加者は、単一の機関に台帳の管理を任せることなく、台帳の正当性を信頼することができます。XRP Ledgerプロトコルは、非常に特殊なルールに従ってのみ更新可能な台帳データベースを管理することで、これを実現しています。ピアツーピアネットワークのサーバは台帳データベースの完全なコピーを保持し、ネットワークは候補となるトランザクションを配信し、[コンセンサスプロセス](../consensus-protocol/index.md)に従ってブロック単位で適用されます。
+
+[{% inline-svg file="/docs/img/ledger-changes.svg" /%}](/docs/img/ledger-changes.svg "図: 各レジャーは、その前のレジャーバージョンにトランザクションを適用して生成されます")
+
+共有グローバル台帳は、レジャーバージョンまたは単に _レジャー_ と呼ばれる一連のブロックから構成されます。すべてのレジャーバージョンには、台帳の正しい順序を識別する[レジャーインデックス][]があります。永続的にクローズされる各台帳には、固有の識別ハッシュ値も存在します。
+
+各XRP Ledgerサーバは常に、進行中の _オープン_ レジャー、保留中の _閉鎖済み_ レジャー、そして確定済みの _検証済み_ レジャーの履歴を持っており、これらは変更不可(immutable)です。
+
+1つのレジャーバージョンはいくつかの要素から構成されています。
+
+[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "レジャーにはトランザクション、状態ツリー、閉鎖時刻、検証情報を含むヘッダーが含まれています。")
+
+* **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
+* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](../../references/protocol/transactions/index.md)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
+* **状態ツリー** - このレジャーの設定、残高などを含むすべての[レジャーエントリ](../../references/protocol/ledger-data/ledger-entry-types/index.md)。
+
+
+
+## 関連項目
+
+- レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプの詳細については、[レジャーのデータ型](../../references/protocol/ledger-data/index.md)をご覧ください。
+- レジャーの状態の変更履歴を追跡する方法については、[レジャーの履歴](../networks-and-servers/ledger-history.md)をご覧ください。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/ledgers/ledger-close-times.md
+++ b/@l10n/ja/docs/concepts/ledgers/ledger-close-times.md
@@ -0,0 +1,41 @@
+---
+html: ledger-close-times.html
+parent: ledgers.html
+seo:
+    description: XRP Ledgerが、レジャーバージョンごとに一意の閉鎖時刻を計算する方法。
+labels:
+  - ブロックチェーン
+---
+# レジャーの閉鎖時刻
+
+レジャーバージョンの閉鎖時刻は、[レジャーヘッダー](../../references/protocol/ledger-data/ledger-header.md)の`close_time`フィールドに記録されます。ネットワークの正確な閉鎖時刻についてコンセンサスを得やすくするため、この値は閉鎖時刻の精度に基づく秒数に丸められます(現在は10秒)。丸めによってレジャーの閉鎖時刻が親レジャーの閉鎖時刻と同じになる(または早くなる)場合、子レジャーの閉鎖時刻は親レジャーの閉鎖時刻に1を足した時刻に設定されます。これにより、有効なレジャーの閉鎖時刻が確実に増加することが保証されます。
+
+通常、新しいレジャーバージョンは約3～5秒ごとに閉鎖するため、これらのルールの結果、レジャーの閉鎖時刻は、:00、:01、:02、:10、:11、:20、:21、...で終わるような、あいまいなパターンになります。2で終わることはあまりなく、3で終わることは非常にまれですが、どちらも、より多くのレジャーが10秒の時間内にランダムに閉鎖した場合にランダムに発生します。
+
+一般的に、レジャーは閉鎖時刻よりも正確な時刻計測を行うことはできません。例えば、あるオブジェクトが有効期限を過ぎているかどうかを確認するには、親レジャーの閉鎖時刻と比較するルールになっています。(レジャーの閉鎖時刻は、そのレジャーに登録されるトランザクションの実行時点では確定していません)。これは、例えば[Escrow](../payment-types/escrow.md)が、Escrowオブジェクトで指定された時間ベースの有効期限より最大で約10秒遅い実世界の時刻に終了する可能性があることを意味します。
+
+### 例
+
+以下の例は、バリデータの観点から、レジャーの閉鎖時刻**12:00:00**の丸め動作を示しています。
+
+**現在のコンセンサスラウンド**
+
+1. バリデータは、レジャーが閉鎖してコンセンサスに達したのが**12:00:03**であったことを記録します。バリデータはこの閉鎖時刻を自分の提案に含めます。
+2. バリデータは、(そのUNL上の)大多数のバリデータが閉鎖時刻を12:00:02と提案し、 残りのバリデータが閉鎖時刻を12:00:03と提案したことを確認します。そのバリデータは、提案された閉鎖時刻をコンセンサスの**12:00:02**に合わせます。
+3. バリデータはこの値を最も近い時間に丸め、**12:00:00** とします。
+4. 12:00:00は前のレジャーの閉鎖時刻より大きくないので、バリデータは閉鎖時刻を前のレジャーの閉鎖時刻のちょうど1秒後に調整します。その結果、調整後の閉鎖時刻は **12:00:01** となります。
+5. バリデータはこれらの詳細情報を使ってレジャーを作成し、ハッシュを計算します。
+
+検証を行わないサーバは、記録した閉鎖時刻をネットワークの他のサーバに提案しないことを除いて、すべて同じ手順を踏みます。
+
+**次のコンセンサスラウンド**
+
+1. 大多数のバリデータによると、次のレジャーは**12:00:04**にコンセンサスに入ります。
+2. 閉鎖時刻は再び切り捨てられ、**12:00:00**となります。
+3. これは前のレジャーの閉鎖時刻12:00:01より大きくないため、調整後の閉鎖時刻は**12:00:02**となります。
+
+**その次のコンセンサスラウンド**
+
+1. 大多数のバリデータによると、この次のレジャーは**12:00:05**にコンセンサスに入ります。
+2. これは、閉鎖時刻の制度に基づいて、**12:00:10**に切り上げられます。
+3. この値は前のレジャーの閉鎖時刻より大きいので、調整する必要はありません。**12:00:10**が正式な閉鎖時刻となります。
--- a/@l10n/ja/docs/concepts/ledgers/ledger-structure.md
+++ b/@l10n/ja/docs/concepts/ledgers/ledger-structure.md
@@ -0,0 +1,69 @@
+---
+html: ledger-structure.html
+parent: ledgers.html
+seo:
+    description: 個別のレジャーブロックの要素を詳しく見てみましょう。
+---
+# レジャーの構成要素
+
+XRP Ledgerはブロックチェーンであり、データブロックの履歴を順番に並べたものです。XRP Ledgerブロックチェーンのブロックは、 _レジャーバージョン_ または略して _レジャー_ と呼ばれます。
+
+コンセンサスプロトコルは、以前のレジャーバージョンを起点として、次に適用するトランザクションのセットについてバリデータ間の合意を形成し、それらのトランザクションを適用することで全員が同じ結果を得たことを確認します。これが成功すると、結果として新しいレジャーバージョンが作成されます。そこから、次のレジャーバージョンを構築するプロセスが繰り返されます。
+
+各レジャーバージョンには、 _状態データ_ 、 _トランザクションセット_ 、メタデータを含む _ヘッダー_ が含まれます。
+
+[{% inline-svg file="/docs/img/ledger.svg" /%}](/docs/img/ledger.svg "図: レジャーはヘッダー、トランザクションセット、状態データから構成されます。")
+
+
+## 状態データ
+
+[{% inline-svg file="/docs/img/ledger-state-data.svg" /%}](/docs/img/ledger-state-data.svg "図: レジャーの状態データは、さまざまなオブジェクトで構成され、グラフのようにリンクされていることもあります。")
+
+_状態データ_ とは、そのレジャーバージョンにおけるすべてのアカウント、残高、設定、その他の情報のスナップショットを表します。サーバがネットワークに接続すると、最初に行うことの1つは、新しいトランザクションを処理し、現在の状態に関するクエリに答えることができるように、現在の状態データの完全なセットをダウンロードすることです。ネットワーク内のすべてのサーバが状態データの完全なコピーを持っているため、すべてのデータは公開され、どのコピーも同じように有効です。
+
+状態データは _レジャーエントリ_ と呼ばれる個別のオブジェクトで構成され、ツリー形式で保存されます。各レジャーエントリには一意の256ビットのIDがあり、それを使用して状態ツリーから検索することができます。
+
+## トランザクションセット
+
+[{% inline-svg file="/docs/img/ledger-transaction-set.svg" /%}](/docs/img/ledger-transaction-set.svg "図: レジャーのトランザクションセット、正規の順序で並べられたトランザクションのグループ")
+
+レジャーに加えられたすべての変更は、トランザクションの結果です。各レジャーバージョンには、特定の順序で新たに適用されたトランザクションのグループである _トランザクションセット_ が含まれています。あるレジャーのトランザクションセットを前のレジャーバージョンの状態データに適用すると、結果としてそのレジャーの状態データが得られます。
+
+レジャーのトランザクションセット内のすべてのトランザクションは、以下の両方の要素を持ちます。
+
+- 送信者がレジャーに何を指示したかを示す _トランザクションの内容_ 。
+- トランザクションがどのように処理され、レジャーの状態データにどのような影響を与えたかを正確に示す _トランザクションのメタデータ_ 。
+
+
+## レジャーヘッダー
+
+_レジャーヘッダー_ は、レジャーバージョンの概略を示すデータのブロックです。レポートの表紙のように、レジャーバージョンを一意に識別し、その内容を記載し、他の注意事項とともに作成時刻を表しています。レジャーヘッダーには以下の情報が含まれます。
+
+<!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->
+
+- [{% inline-svg file="/docs/img/ledger-index-icon.svg" /%}](/docs/img/ledger-index-icon.svg "") チェーン内でのレジャーの位置を示す _レジャーインデックス_ 。レジャーは、1つ小さいインデックスを持つレジャーの上に構築され、 _ジェネシスレジャー_ として知られるスタート地点に戻ります。これは、すべてのトランザクションと結果の公開履歴を形成します。
+- [{% inline-svg file="/docs/img/ledger-hash-icon.svg" /%}](/docs/img/ledger-hash-icon.svg "") レジャーの内容を一意に識別する _レジャーハッシュ_ 。ハッシュは、レジャーバージョンの内容が変更された場合、ハッシュが完全に異なるものになるように計算されます。これは、レジャーのデータが消失、変更、破損していないことを示すチェックサムのようなものでもあります。
+- [{% inline-svg file="/docs/img/ledger-parent-icon.svg" /%}](/docs/img/ledger-parent-icon.svg "") 親レジャーのハッシュ。レジャーバージョンは、その前の _親レジャー_ との違いによって定義されることが多く、ヘッダーには親レジャーの一意なハッシュも含まれます。
+- [{% inline-svg file="/docs/img/ledger-timestamp-icon.svg" /%}](/docs/img/ledger-timestamp-icon.svg "") このレジャーの内容が確定した正式なタイムスタンプとなる _閉鎖時刻_ 。この数値は秒数(一の位)が四捨五入され、通常は10です。
+- [{% inline-svg file="/docs/img/ledger-state-data-hash-icon.svg" /%}](/docs/img/ledger-state-data-hash-icon.svg "") このレジャーの状態データのチェックサムとして機能する _状態データのハッシュ_ 。
+- [{% inline-svg file="/docs/img/ledger-tx-set-hash-icon.svg" /%}](/docs/img/ledger-tx-set-hash-icon.svg "") このレジャーのトランザクションセットのデータのチェックサムとして機能する _トランザクションセットのハッシュ_。
+- [{% inline-svg file="/docs/img/ledger-notes-icon.svg" /%}](/docs/img/ledger-notes-icon.svg "") その他、存在するXRPの総量や、閉鎖時刻が四捨五入された値など、いくつかのメモがあります。
+
+レジャーのトランザクションセットと状態データのサイズは無制限ですが、レジャーヘッダーは常に固定サイズです。レジャーヘッダーの正確なデータとバイナリ形式については、[レジャーヘッダー](../../references/protocol/ledger-data/ledger-header.md)をご覧ください。
+
+
+## バリデーションの状況
+
+[{% inline-svg file="/docs/img/ledger-validated-mark.svg" /%}](/docs/img/ledger-validated-mark.svg "Diagram: レジャーのバリデーション(検証)状況。レジャーの上に追加され、レジャー自体の一部ではありません。")
+
+サーバの Unique Node List のバリデータのコンセンサスがレジャーバージョンの内容に合意すると、そのレジャーバージョンは検証済みであり、変更不可であるとみなされます。レジャーの内容は、後続のトランザクションが新しいレジャーバージョンを作成し、チェーンを更新することによってのみ変更できます。
+
+レジャーバージョンが新しく作成された時点では、まだ未検証です。候補となるトランザクションが異なるサーバに到着するタイミングが異なるため、ネットワークはチェーンの次のステップとなる複数の異なるレジャーバージョンを構築し、提案する可能性があります。[コンセンサスプロトコル](../consensus-protocol/index.md)は、そのうちのどれを有効化するかを決定します。(検証済みのレジャーバージョンに存在しなかったトランザクション候補は、通常、次のレジャーバージョンのトランザクションセットに含まれます)。
+
+
+## レジャーインデックスとレジャーハッシュ
+レジャーバージョンを識別する方法には、 _レジャーインデックス_ と _レジャーハッシュ_ の2種類があります。この2つのフィールドはどちらもレジャーを識別しますが、その目的は異なります。レジャーインデックスはチェーン内でのレジャーの位置を表し、レジャーハッシュはレジャーの内容を表します。
+
+異なるチェーンのレジャーは、レジャーインデックスは同じでもハッシュが異なることがあります。また、検証されていないレジャーバージョンを扱う場合、インデックスが同じでも内容が異なるため、ハッシュが異なる複数のレジャー候補が存在する可能性があります。
+
+同じレジャーハッシュを持つ2つのレジャーは、常に完全に同一です。
--- a/@l10n/ja/docs/concepts/ledgers/open-closed-validated-ledgers.md
+++ b/@l10n/ja/docs/concepts/ledgers/open-closed-validated-ledgers.md
@@ -0,0 +1,24 @@
+---
+html: open-closed-validated-ledgers.html
+parent: ledgers.html
+seo:
+    description: レジャーオブジェクトには、オープン、閉鎖済み、検証済みの3つの状態があります。
+labels:
+  - ブロックチェーン
+---
+# オープン、閉鎖済み、および検証済みレジャー
+
+`rippled`サーバはレジャーのバージョンを _オープン(open)_、_閉鎖済み(closed)_、_検証済み(validated)_ に区別します。サーバはオープンなレジャーを1つ、閉鎖済みだが未検証のレジャーをいくつでも、そして検証済みレジャーの変更不可能な履歴を持ちます。以下の表はその違いをまとめたものです。
+
+| レジャーの種類:             | オープン        | 閉鎖済み                                     | 検証済み |
+|:--------------------------|:--------------|:--------------------------------------------|:--|
+| **目的:**                 | 一時的な作業領域  | 次の状態の提案                                | 直前の状態の確認 |
+| **使用する数:**             | 1             | 任意の数、通常は0または1                        | レジャーインデックスごとに1つ、時間の経過とともに増加 |
+| **内容は変更可能?**         | はい           | いいえ、ただし、別のレジャーが採用される可能性あり。 | いいえ |
+| **トランザクションの適用方法:** | 受信順          | 正規順序                                     | 正規順序 |
+
+直感に反し、XRP Ledgerはオープンレジャーを「閉鎖」して閉鎖済みレジャーへと変換することはありません。その代わりに、サーバはオープンレジャーを捨て、以前の閉鎖済みレジャーの上にトランザクションを適用して閉鎖済みレジャーを作成し、最新の閉鎖済みレジャーをベースとして新しいオープンレジャーを作成します。これは、[コンセンサスが二重支出問題を解決する方法](../consensus-protocol/consensus-principles-and-rules.md#simplifying-the-problem)の結果と言えます。
+
+オープンレジャーでは、サーバはトランザクションを受信した順番にトランザクションを適用しますが、サーバによってトランザクションが異なる順番で表示されることがあります。実際にどのトランザクションが先だったかを決定するための中心的なタイムキーパーが存在しないため、同じ時刻に送信されたトランザクションの正確な順序について、サーバ間で見解が一致しない可能性があります。したがって、[検証](../consensus-protocol/consensus-structure.md#validation)の対象となる閉鎖済みのレジャーバージョンを計算するプロセスは、提案されたトランザクションを受信順に並べてオープンレジャーを構築するプロセスとは異なります。「閉鎖済み」レジャーを作成するために、各XRP Ledgerサーバは、トランザクションのセットと、以前、つまり「親」レジャーを使用します。サーバはトランザクションを正規順序に並べ、その順序で前のレジャーに適用します。正規順序は、[分散型取引所](../tokens/decentralized-exchange/index.md)におけるオファーのフロントランニングの難易度を高めるために、決定論的で効率的であるが、悪用されにくいように設計されています。
+
+このように、オープンレジャーは一時的な作業領域としてしか使用されないため、トランザクションの[暫定的な結果と最終的な結果が異なる可能性がある](../transactions/finality-of-results/index.md)という大きな特徴があります。
--- a/@l10n/ja/docs/concepts/networks-and-servers/amendments.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/amendments.md
@@ -0,0 +1,90 @@
+---
+html: amendments.html
+parent: networks-and-servers.html
+seo:
+    description: Amendmentはトランザクション処理の新しい機能やその他の変更を指します。バリデータはコンセンサスを通して連携し、XRP Ledgerにこれらのアップグレードを順序正しく適用します。
+labels:
+  - ブロックチェーン
+---
+# Amendment
+
+Amendmentは、トランザクション処理における新機能またはその他の変更を表します。
+
+Amendmentシステムは、XRP Ledger上のトランザクション処理に影響を与える変更を合意形成プロセスを用いて承認します。完全に機能するトランザクション処理の変更は、Amendmentとして提出され、バリデータはその変更について投票します。もしAmendmentが2週間にわたって80%超の支持を得た場合、そのAmendmentは可決され、その後のすべてのレジャーバージョンに変更が恒久的に適用されます。可決されたAmendmentを無効にするには、別の新たなAmendmentが必要です。
+
+{% admonition type="info" name="注記" %}トランザクションプロセスを変更するバグ修正にも、Amendmentが必要です。{% /admonition %}
+
+<!-- Amendmentチュートリアルに移動します。
+すべてのAmendmentには、16進数の一意な短い名前があります。短い名前は読みやすくするためだけのものです。サーバは同じ Amendment IDを表すのに異なる名前を使うことができ、その名前が一意であることは保証されていません。Amendment IDは、Amendmentの短い名前のSHA-512Halfハッシュでなければなりません。
+-->
+
+## Amendmentプロセス
+
+[XRP Ledgerのコードに貢献する](/resources/contribute-code/index.md)のトピックでは、XRP Ledgerのアイデアから有効化までのワークフローを説明しています。
+
+Amendmentのコードがソフトウェアリリースに組み込まれた後、それを有効にするプロセスはXRP Ledgerネットワーク内で行われ、レジャーは _フラグ_ レジャーごとに(通常約15分間隔で)Amendment状況をチェックします。
+
+256番目毎のレジャーは、**フラグ**レジャーと呼ばれます。フラグレジャーは特別な内容を持っているわけではありませんが、フラグレジャーの前後ではAmendment作業が行われます。
+
+1. **フラグレジャー -1:** `rippled`バリデータが検証メッセージを送信するとき、彼らは自身でAmendmentへの投票も送信します。
+2. **フラグレジャー:** サーバは、信頼できるバリデータからの投票を処理します。
+3. **フラグレジャー +1:** サーバは`EnableAmendment`疑似トランザクションを挿入し、発生したと思われることに基づいてフラグを立てます。
+    * `tfGotMajority`フラグは、そのAmendmentが80%超の支持を得ていることを意味します。
+    * `tfLostMajority`フラグはAmendmentへの支持が80%以下になったことを意味します。
+    * フラグなしは、Amendmentが有効であることを意味します。
+
+    {% admonition type="info" name="注記" %}Amendmentが有効化されるために必要な2週間の期間に達したのと同一のレジャーで、80%の支持を失う可能性があります。このような場合、両方のシナリオで `EnableAmendment`擬似トランザクションが追加されますが、最終的にそのAmendmentは有効になります。{% /admonition %}
+
+4. **フラグレジャー +2:** Amendmentが有効になった場合、このレジャー以降のトランザクションに適用されます。
+
+
+## Amendment投票
+
+`rippled`の各バージョンは、[既知のAmendment](/resources/known-amendments.md)のリストとそれらのAmendmentを実装するためのコードでコンパイルされています。`rippled`バリデータのオペレータは、各Amendmentに投票するようにサーバを設定し、いつでも変更することができます。オペレータが投票を選択しない場合、サーバはソースコードで定義されたデフォルトの投票を使用します。
+
+{% admonition type="info" name="注記" %}デフォルトの投票はソフトウェアのリリースごとに変更される可能性があります。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}更新: rippled 1.8.1{% /badge %}{% /admonition %}
+
+Amendmentが有効になるには、信頼できるバリデータの80%超から2週間の支持を得なければなりません。支持率が80%以下となると、そのAmendmentは一時的に却下され、再び2週間の支持が必要となります。Amendmentは、恒久的に有効になるまで、何度でも過半数を獲得したり失ったりすることができます。
+
+有効化されずにソースコードが削除されたAmendmentは、ネットワークによって**撤回**されたとみなされます。
+
+
+### Amendmentブロックされたサーバ
+<a id="amendment-blocked"></a>
+
+AmendmentブロックはXRP Ledgerデータの正確性を守るためのセキュリティ機能です。Amendmentが有効になると、Amendmentのソースコードなしで以前のバージョンの`rippled`を実行しているサーバは、ネットワークのルールを認識できなくなります。レジャーデータを推測して誤って解釈するのではなく、これらのサーバは**Amendmentブロック**された状態になります。Amendmentブロック状態のサーバは次のことが行えません。
+
+* レジャーのバリデータの判断
+* トランザクションの送信または処理
+* 合意プロセスへの参加
+* Amendmentへの投票
+
+`rippled`サーバの投票設定は、そのサーバがAmendmentブロックされることに影響を与えません。`rippled`サーバは常に他のネットワークで有効になっているAmendmentに従うので、ブロックは単にルールの変更を認識するコードを持っているかどうかに基づいています。つまり、異なるAmendmentが有効になっている並列ネットワークにサーバを接続した場合も、Amendmentブロックされる可能性があるということです。例えば、XRP Ledgerの開発ネットでは通常、実験的なAmendmentが有効になっています。最新のプロダクションリリースのコードを使用している場合、あなたのサーバには実験的なAmendmentのコードが存在しない可能性が高いです。
+
+最新バージョンの`rippled`にアップグレードすることで、Amendmentブロックされたサーバのブロックを解除することができます。
+
+
+### AmendmentブロックされたClioサーバ
+<a id="amendment-blocked-clio-servers"></a>
+
+Clioサーバが台帳データのロード中に未知のフィールドに遭遇した場合、Amendmentブロックが発生することがあります。これは、Clioのビルド時に使用された`libxrpl`の依存ファイルにそれらのフィールドが存在しない場合に発生します。Amendmentブロックを解除するには、互換性のある`libxrpl`でビルドされた新しいClioリリースにアップグレードしてください。
+
+## Amendmentの削除
+
+Amendmentを有効にすると、修正前の動作のソースコードは`rippled`に残ります。検証のためにレジャーの結果を再構築するなど、古いコードを保持するユースケースはありますが、Amendmentとレガシーコードの追跡は時間の経過とともに複雑さを増していきます。
+
+[XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19)では、古いレジャーと関連する以前のレジャーのコードを破棄するプロセスを定義しています。メインネット上でAmendmentが2年間有効である場合、古いコードは削除することができます。Amendmentは自動的にコアプロトコルの一部となり、その後は追跡されず、Amendmentとして扱われず、Amendment前のコードはすべて削除されます。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [コンセンサスについて](../consensus-protocol/index.md)
+- **チュートリアル:**
+    - [バリデータとしてrippledを実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)
+    - [Amendment投票機能の設定](../../infrastructure/configuration/configure-amendment-voting.md)
+    - [XRP Ledgerのコードへの貢献](/resources/contribute-code/index.md)
+- **リファレンス:**
+    - [既知のAmendment](/resources/known-amendments.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/clustering.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/clustering.md
@@ -0,0 +1,21 @@
+---
+html: clustering.html
+parent: networks-and-servers.html
+seo:
+    description: 暗号処理の負荷を分散させるためにクラスターでrippledサーバを運用できます。
+labels:
+  - コアサーバ
+---
+# クラスター化
+
+1つのデータセンターで複数の`rippled`サーバを運用している場合は、これらのサーバをクラスターに編成して、効率性を最大化できます。`rippled`サーバをクラスターで運用するメリットは以下のとおりです。
+
+- クラスター化`rippled`サーバは暗号処理を共有します。1台のサーバがメッセージの真正性をすでに検証している場合、クラスターの他のサーバはそのメッセージを信頼し、再検証を行いません。
+- クラスター化サーバは、ネットワークで不適切な活動をしているかまたはネットワークを不正使用しているピアとAPIクライアントに関する情報を共有します。このため、クラスター内のすべてのサーバを同時に攻撃することが難しくなります。
+- クラスター化サーバは、一部のサーバでの現行の負荷ベースのトランザクション手数料にトランザクションが対応していない場合を含め、常にクラスター全体にトランザクションを伝搬します。
+
+バリデータを[プライベートピア](peer-protocol.md#プライベートピア)として実行している場合は、`rippled`サーバのクラスターをプロキシサーバとして使用することが推奨されます。
+
+クラスターでのサーバの設定方法に関するチュートリアルについては、[`rippled`サーバのクラスター化](../../infrastructure/configuration/peering/cluster-rippled-servers.md)をご覧ください。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/index.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/index.md
@@ -0,0 +1,41 @@
+---
+html: networks-and-servers.html
+parent: concepts.html
+seo:
+    description: rippledは、XRP Ledgerを管理するコアとなるピアツーピアサーバです。
+metadata:
+  indexPage: true
+---
+# ネットワークとサーバ
+
+XRP Ledgerを動かすサーバソフトウェアは、主に2種類あります。
+
+- コアサーバである`rippled`は、トランザクションを処理し、その結果についてコンセンサスを得るピアツーピアネットワークを実行します。
+- APIサーバである[Clio](the-clio-server.md)は、台帳からデータをフェッチしたりクエリしたりするための強力なインターフェイスを提供します。
+
+誰でも必要に応じて、これらのタイプのサーバの1つまたは両方のインスタンスを実行することができます。
+
+## 独自サーバを運用する理由
+
+簡単なユースケースや個別のサーバであれば、無料の[公開サーバ][]を利用することも多いでしょう。しかし、XRP Ledgerの利用が本格化すればするほど、独自のインフラを持つことが重要になってきます。
+
+独自のサーバを運用したいと思う理由はたくさんありますが、そのほとんどは、「自分のサーバを信頼できる」「ワークロードをコントロールできる」「いつ、どのようにアクセスできるかを他人の判断に左右されない」ということに集約されます。もちろん、悪意のあるハッカーからサーバを守るために、優れたネットワークセキュリティを実践する必要があります。
+
+利用しているサーバを信頼する必要があります。悪意のあるサーバに接続すると、そのサーバに利用されたり、損害を受けたりする可能性があります。例えば、以下のようなことです。
+
+* 悪意のあるサーバは、支払いを行っていないにもかかわらず、支払いを受けたと報告する可能性があります。
+* 選択的に支払いパスや通貨交換のオファーを表示または非表示にすることができ、最良の取引を提供せず、彼ら自身の利益を確保する可能性があります。
+* もし、アドレスの秘密鍵を送信してしまった場合、サーバの管理者はあなたに代わって任意のトランザクションを実行し、アドレスが保有するすべての資金を転送または破棄する可能性があります。
+
+さらに、独自のサーバを運営することで、[管理者アクセス権限](../../tutorials/http-websocket-apis/build-apps/get-started.md#管理者アクセス権限)が与えられ、重要な管理者専用コマンドや負荷の高いコマンドを実行することができます。共有サーバを使用する場合、同じサーバの他のユーザとサーバの計算能力を共有することを考慮しなければいけません。WebSocket APIのコマンドの多くはサーバに大きな負担をかけるので、サーバには必要なときにレスポンスを縮小するオプションがあります。サーバを他人と共有する場合、常に最良の結果を得られるとは限りません。
+
+最後に、バリデーションサーバを運用する場合、パブリックネットワークへのプロキシとしてストックサーバを使用し、バリデーションサーバをプライベートネットワークに置いて、ストックサーバを通してのみ外部にアクセスできるようにすることができます。これにより、バリデーションサーバに侵入することがより困難になります。
+
+## サーバの機能とトピックス
+
+<!-- provided by the auto-generated table of children -->
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
+
+
+{% child-pages /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/ledger-history.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/ledger-history.md
@@ -0,0 +1,83 @@
+---
+html: ledger-history.html
+parent: networks-and-servers.html
+seo:
+    description: rippledサーバはトランザクションの変動金額と状態の履歴をローカルに保管します。
+labels:
+  - データ保持
+  - ブロックチェーン
+  - コアサーバ
+---
+# レジャー履歴
+
+[コンセンサスプロセス](../consensus-protocol/index.md)により、[検証済みレジャーバージョン](../ledgers/index.md)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](../transactions/index.md)のセットを適用して生成されます。各[`rippled`サーバ](index.md)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバに保管されるトランザクション履歴の量は、サーバがオンラインであった期間と、サーバが取得し、保持する履歴量の設定に応じて異なります。
+
+ピアツーピアのXRP Ledgerネットワーク内のサーバは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバの結果と一致しない場合は、サーバがピアから必要なデータを取得して整合性を維持します。）サーバはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](../../references/protocol/data-types/basic-data-types.md#ハッシュ)を使用した構造となっているため、すべてのサーバがデータの整合性の検証を行えます。
+
+## データベース
+
+サーバはレジャーの状態データとトランザクションを _レジャーストアー_ と呼ばれるkey-valueストアで保持します。また、`rippled`にはいくつかのSQLiteデータベースファイルが維持されているので、トランザクション履歴などへより柔軟にアクセスし、特定の設定変更を追跡できます。
+
+一般に、`rippled`サーバが稼働していないときにはそのサーバのすべてのデータベースファイルを安全に削除できます。（たとえばサーバのストレージ設定を変更する場合や、Test Netから本番環境ネットワークに切り替える場合に、このような削除が必要となることがあります。）
+
+## 利用可能な履歴
+
+設計上、XRP Ledgerのすべてのデータとトランザクションは公開されており、誰でもすべてのデータを検索または照会できます。ただし、サーバが検索できるデータは、そのサーバがローカルで使用できるデータに限られます。サーバで利用できないレジャーバージョンやトランザクションを照会しようとすると、そのデータが見つからないというレスポンスがサーバから返されます。必要な履歴を保持している他のサーバに対して同じ照会を実行すると、正常なレスポンスが返されます。XRP Ledgerデータを使用する企業では、サーバで利用可能な履歴の量に注意してください。
+
+[server_infoメソッド][]は、サーバで利用可能なレジャーバージョンの数を`complete_ledgers`フィールドで報告します。
+
+## 履歴の取得
+
+`rippled`サーバは起動されると、最優先で最新の検証済みレジャーの完全なコピーを取得します。その後、サーバは常にレジャーの進行状況を把握します。レジャー履歴を埋め戻すように設定されているサーバでは、レジャー履歴が設定量に達するまで埋め戻されます。この設定量は、オンライン削除による削除が開始されるカットオフ値以下でなければなりません。
+
+履歴の埋め戻しは、サーバの最も低い優先順位の1つであるため、特にサーバが忙しい場合や、ハードウェアやネットワークのスペックが十分でない場合、不足する履歴を埋めるのに長い時間がかかることがあります。ハードウェアのスペックに関する推奨事項は、[容量計画](../../infrastructure/installation/capacity-planning.md)をご覧ください。また、履歴を埋め戻すには、サーバのダイレクトピアのうち少なくとも1つが該当する履歴を持っていることが必要です。サーバのピアツーピア接続の管理については、[ピアリングの設定](../../infrastructure/configuration/peering/index.md)をご覧ください。
+
+XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](../../references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md)の形式で含まれています。サーバはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
+
+
+<a id="with-advisory-deletion"></a>
+### 履歴の埋め戻し
+{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}新規: rippled 1.6.0{% /badge %}
+
+サーバがダウンロードしようとする履歴の量は、その設定に依存します。サーバは自動的に、**最も古い台帳までの履歴**をダウンロードしてギャップを埋めようとします。`[ledger_history]`設定を使用すると、サーバがそれ以降の履歴を埋め戻すようにすることができます。ただし、[削除](../../infrastructure/configuration/data-retention/online-deletion.md)が予定されている台帳は、サーバがダウンロードすることはありません。
+
+`[ledger_history]`設定は、現在有効な台帳の前から蓄積する台帳の最小数を定義します。ネットワークの[完全な履歴](#すべての履歴)をダウンロードするには、特別な値`full`を使用します。`[ledger_history]`設定を使用して、サーバに _より少ない_ 履歴をダウンロードさせることはできません。サーバが保存する履歴の量を減らすには、代わりに[オンライン削除](../../infrastructure/configuration/data-retention/online-deletion.md)設定を変更してください。
+
+## すべての履歴
+
+XRP Ledgerネットワーク内の一部のサーバは、「すべての履歴が記録される」サーバとして設定されています。これらのサーバは、使用可能なすべてのXRP Ledgerの履歴を収集しますが、**オンライン削除は使用しません**。このため他の追跡サーバよりもかなり多くのディスク容量が必要です。
+
+XRP Ledger財団は、コミュニティメンバーが運営する一連の全履歴サーバへのアクセスを提供しています（詳細は[xrplcluster.com](https://xrplcluster.com)を参照）。
+また、Ripple社は公開サービスとして、`s2.ripple.com`に一連の公開全履歴サーバを提供しています。
+
+{% admonition type="success" name="ヒント" %}一部の暗号資産ネットワークとは異なり、XRP Ledgerのサーバは、現在の状態を認識して最新のトランザクションを把握するのにすべての履歴を必要としません。{% /admonition %}
+
+すべての履歴の設定については、[完全な履歴の設定](../../infrastructure/configuration/data-retention/configure-full-history.md)をご覧ください。
+
+## 履歴シャーディング
+
+XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](../../infrastructure/configuration/data-retention/history-sharding.md)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータがリクエストされると、サーバはレジャーストアーまたはシャードストアーのデータを使用してレスポンスできます。
+
+オンライン削除ではシャードストアーのデータは削除**されません**。ただし、32768個以上のレジャーバージョンをサーバのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
+
+詳細は、[履歴シャーディングの設定](../../infrastructure/configuration/data-retention/configure-history-sharding.md)をご覧ください。
+
+## 関連項目
+
+- **コンセプト:**
+    - [レジャー](../ledgers/index.md)
+    - [コンセンサス](../consensus-protocol/index.md)
+- **チュートリアル:**
+    - [`rippled`の設定](../../infrastructure/configuration/index.md)
+        - [オンライン削除の設定](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
+        - [指示による削除の設定](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
+        - [履歴シャーディングの設定](../../infrastructure/configuration/data-retention/configure-history-sharding.md)
+        - [全履歴の設定](../../infrastructure/configuration/data-retention/configure-full-history.md)
+- **リファレンス:**
+    - [ledgerメソッド][]
+    - [server_infoメソッド][]
+    - [ledger_requestメソッド][]
+    - [can_deleteメソッド][]
+    - [ledger_cleanerメソッド][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/parallel-networks.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/parallel-networks.md
@@ -0,0 +1,52 @@
+---
+html: parallel-networks.html
+parent: networks-and-servers.html
+seo:
+    description: テストネットワークおよび代替レジャーチェーンと本番環境のXRP Ledgerとの関係について説明します。
+labels:
+  - ブロックチェーン
+---
+# 並列ネットワーク
+
+XRP Ledgerにはピアツーピアの本番環境のネットワークが1つ存在し、XRP Ledger上で行われるすべての取引はその本番環境のネットワーク、すなわちMainnet内で発生します。
+
+XRP Ledgerコミュニティのメンバーが、メインネットに影響を与えることなくXRP Ledgerとやり取りできるように、テストネットをはじめとするいくつかの代替ネットワークが用意されています。ここでは、いくつかのネットワークを紹介します。
+
+| ネットワーク | アップグレード頻度 | 説明                                          |
+|:-----------|:----------------|:---------------------------------------------|
+| Mainnet    | 安定版リリース    | ピアツーピアサーバのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](../../introduction/what-is-xrp.md)の土台となる[XRP Ledger](/about/)です。 |
+| Testnet    | 安定版リリース    | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワークです。本番環境のXRP Ledgerユーザに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](/resources/known-amendments.md)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
+| Devnet     | ベータ版リリース  | 次期リリースのプレビューネットワークです。XRP Ledgerのコアソフトウェアへの不安定な変更がテストされます。このAltNetを使用すると、開発者はまだMainnetで有効になっていないXRPLの計画段階の新機能やAmendmentを操作したり学習したりすることができます。 |
+| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Hooksサーバ](https://github.com/XRPL-Labs/xrpld-hooks) | [Hooks](https://xrpl-hooks.readme.io/)を使用したオンチェーン・スマートコントラクト機能のプレビューネットワークです。 |
+| Sidechain-Devnet | ベータ版リリース | クロスチェーンブリッジ機能をテストするためのサイドチェーンです。<br>ライブラリのサポート:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**注記**: また、[`xbridge-cli`](https://github.com/XRPLF/xbridge-cli)コマンドラインツールを使用して、ローカルマシンにクロスチェーンブリッジをセットアップすることもできます。 |
+
+テスト用XRPは、XRP Ledgerの実験やアプリケーションの開発、統合に興味のある人々に[無償で提供](/resources/dev-tools/xrp-faucets)されています。テスト用のXRPは実際には価値を持たず、ネットワークがリセットされると失われます。
+
+{% admonition type="warning" name="注意" %}XRP Ledgerメインネットとは異なり、テストネットワークは通常「中央集権型」であり、これらのネットワークの安定性や可用性については保証されていません。これらのネットワークは、サーバ構成、ネットワークトポロジー、ネットワークパフォーマンスのさまざまな特性をテストする目的でこれまで使用され、またこれからも同様に使用されます。{% /admonition %}
+
+
+## 並列ネットワークとコンセンサス
+
+使用するネットワークを定義する`rippled`の設定はありません。その代わり、信頼するバリデータのコンセンサスに基づいてどのレジャーを正しいレジャーとして受け入れるかを把握します。`rippled`インスタンスからなる異なるコンセンサスグループが、同じグループの他のメンバーだけを信頼する場合、各グループは引き続き並列ネットワークとして機能します。悪意のあるコンピュータや不適切に動作するコンピュータが両方のネットワークに接続している場合でも、各ネットワークのメンバーが、定数設定を超えて別のネットワークのメンバーを信頼するように設定されていない限り、コンセンサスプロセスに混乱は生じません。
+
+Ripple社は、TestnetとDevnetでメインサーバを運用しています。[独自の`rippled`サーバをTestnetに接続](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)することも可能です。TestnetとDevnetでは、多様で検閲耐性のあるバリデータのセットは使用されていません。そのため、Ripple社はTestnetやDevnetを定期的にリセットできます。
+
+
+## 関連項目
+
+- **ツール:**
+  - [XRP Testnet Faucet](/resources/dev-tools/xrp-faucets)
+- **コンセプト:**
+  - [コンセンサスについて](../consensus-protocol/index.md)
+  - [Amendment](amendments.md)
+- **チュートリアル:**
+  - [XRP Testnetへの`rippled`の接続](../../infrastructure/configuration/connect-your-rippled-to-the-xrp-test-net.md)
+  - [スタンドアロンモードでのrippledの使用](../../infrastructure/testing-and-auditing/index.md)
+- **リファレンス:**
+  - [Server_infoメソッド][]
+  - [Consensus_infoメソッド][]
+  - [Validator_list_sitesメソッド][]
+  - [Validatorsメソッド][]
+  - [デーモンモードのオプション](../../infrastructure/commandline-usage.md#デーモンモードのオプション)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md
@@ -0,0 +1,174 @@
+---
+html: peer-protocol.html
+parent: networks-and-servers.html
+seo:
+    description: ピアプロトコルは、rippledサーバが互いに通信する言語を指定します。
+labels:
+  - コアサーバ
+  - ブロックチェーン
+---
+# ピアプロトコル
+
+XRP Ledgerのサーバは、XRP Ledgerピアプロトコル（RTXP）を使用して相互に通信します。
+
+ピアプロトコルは、XRP Ledgerのサーバ間のメイン通信モードです。XRP Ledgerの動作、進捗状況、接続に関するすべての情報がピアプロトコルを通じて伝達されます。ピアツーピア通信の例を以下に示します。
+
+- ピアツーピアネットワーク内の他のサーバへの接続のリクエスト、または接続スロットの使用可能性についてのアドバタイズ。
+- ネットワークのその他の部分との候補トランザクションの共有。
+- 履歴レジャーへのレジャーデータのリクエスト、またはレジャーデータの提供。
+- コンセンサスのための一連のトランザクションの提示、またはコンセンサストランザクションセットの適用に関する算出結果の共有。
+
+ピアツーピア接続を確立するには、サーバどうしをHTTPSで接続し、一方のサーバはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)をリクエストします。（詳細は、[`rippled`リポジトリ](https://github.com/ripple/rippled)の[Overlay Network](https://github.com/XRPLF/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)をご覧ください。）
+
+## ピアの検出
+
+XRP Ledgerでは、「ゴシップ」プロトコルを使用して、XRP Ledgerネットワーク内でサーバが互いを識別できるようにします。サーバは、起動するたびに、以前に接続したその他のあらゆるピアに再接続します。フォールバックとして、[ハードコーディングされた公開ハブ](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525)を使用します。サーバがピアに正常に接続されると、ピアを探している他のXRP Ledgerサーバの接続情報（通常はIPアドレスとポート）をそのピアにリクエストします。その後、サーバはそれらのサーバに接続し、ピア接続するXRP Ledgerサーバの接続情報をさらにリクエストできます。このプロセスにより、サーバは十分なピア接続を確立し、単一のピアへの接続が失われた場合でも、ネットワークの残りの部分にその後も接続されます。
+
+通常、サーバが公開ハブに接続する必要があるのは1回のみです。他のピアを見つけるために、短時間のみ接続します。そうすることで、ネットワーク接続の安定性、ハブのビジー状態、およびサーバが検出する他の高品質ピアの数に応じて、ハブにサーバを引き続き接続するかどうかが異なります。サーバでは、これらの他のピアのアドレスを保存するため、ネットワークの停止後または再起動後、それらのピアへの直接再接続を試行できます。
+
+[peersメソッド][]は、サーバが現在接続しているピアのリストを示します。
+
+価値の高いサーバ（重要な[バリデータ](rippled-server-modes.md#rippledサーバのモード)など）によっては、ピア検出プロセスを通じて、サーバを信頼性の低いピアに接続しないようにする場合があります。この場合、[プライベートピア](#プライベートピア)のみを使用するようにサーバを構成できます。
+
+
+## ピアプロトコルポート
+
+XRP Ledgerに参加するため、`rippled`サーバはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバで[クラスター化されている](clustering.md)場合を除き、信頼できないものとして扱われます。）
+
+サーバがピアポートで接続を送信 _かつ_ 受信できることが理想的です。`rippled`サーバに、[ファイアウォール経由でピアプロトコルに使用するポートを転送する](../../infrastructure/configuration/peering/forward-ports-for-peering.md)必要があります。
+
+[デフォルトの`rippled`構成ファイル](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスにおいて、ポート51235で着信ピアプロトコル接続をリッスンします。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。
+
+例:
+
+```
+[port_peer]
+port = 51235
+ip = 0.0.0.0
+protocol = peer
+```
+
+ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)も処理します。
+
+## ノードキーペア
+
+サーバを初めて起動すると、ピアプロトコル通信でサーバ自体を識別するための _ノードキーペア_ が生成されます。サーバはこのキーを使用して、ピアプロトコル通信のすべてに署名します。これにより、ピアツーピアネットワーク内の別のサーバからのメッセージの整合性を、信頼できる方法で識別、検証できます。これは、そのサーバのメッセージが信頼できないピアにより中継される場合も同様です。
+
+ノードキーペアはデータベースに保存され、サーバの再起動時に再利用されます。サーバのデータベースを削除すると、新しいノードキーペアが作成され、異なるアイデンティティでオンラインになります。データベースが削除されても同じキーペアを再利用するには、`[node_seed]`スタンザを使用してサーバを設定できます。`[node_seed]`スタンザでの使用に適した値を生成するには、[validation_createメソッド][]を使用します。
+
+また、ノードキーペアは、[ピアスロットの](#固定ピアとピアリザベーション)[クラスタリング](clustering.md)または[確保](#固定ピアとピアリザベーション)のために他のサーバも識別します。サーバクラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバのクラスター化](../../infrastructure/configuration/peering/cluster-rippled-servers.md)をご覧ください。
+
+
+## 固定ピアとピアリザベーション
+
+通常、`rippled`サーバでは多数のピアを維持するよう試みるため、信頼性の低いピアの最大数まで自動接続されます。特定のピアサーバへの接続を維持するように`rippled`サーバを構成するには、いくつかの方法があります。
+
+- **固定ピア**を使用して、IPアドレスに基づき特定の他のピアへの接続を維持します。これは、ピアのIPアドレスが固定されている場合にのみ機能します。固定ピアを構成するには、構成スタンザ`[ips_fixed]`を使用します。これは、[クラスタリング](clustering.md)または[プライベートピア](#プライベートピア)の重要な部分です。固定ピアは構成ファイルで定義されているため、変更を適用するにはサーバを再起動する必要があります。サーバが同じユーザまたは組織によって実行されている場合、固定ピアは、サーバの接続状態を維持するのに最も有益です。
+- **ピアリザベーション**を使用して、特定のピアに優先順位を付けます。サーバに特定のピアのピアリザベーションがある場合、既に最大数のピアに接続されていても、サーバは常にそのピアからの接続リクエストを受け入れます。（これにより、サーバでのピアの最大接続数を*超える*可能性があります。）[ノードキーペア](#ノードキーペア)によって確保済みピアを識別するため、可変IPアドレスを持つピアに対してもこれを行うことができます。ピアリザベーションは、管理コマンドを使用して構成され、サーバデータベースに保存されるため、サーバがオンラインの場合に調整することができ、再起動後も保存されます。ピアリザベーションは、さまざまなユーザや組織が運営するサーバを接続するのに最も有益です。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.4.0" %}新規: rippled 1.4.0{% /badge %}
+
+次の場合、`rippled`サーバは、信頼性の低いピアには接続されません。
+
+- [プライベートピア](#プライベートピア)として構成されている場合、サーバは固定ピアに _のみ_ 接続されます。
+- [スタンドアロンモード](rippled-server-modes.md#スタンドアロンモード)で実行されている場合、サーバは _どの_ ピアにも接続されません。
+
+
+## プライベートピア
+
+`rippled`サーバが「プライベート」サーバとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバは1つ以上の非プライベートサーバに接続するように設定されている必要があります。この非プライベートサーバにより、メッセージがネットワークのその他の部分へ中継されます。
+
+{% admonition type="warning" name="注意" %}[固定ピア](#固定ピアとピアリザベーション)を使用せずにプライベートサーバを構成すると、サーバはネットワークに接続できないため、ネットワークの状態を認識したり、トランザクションをブロードキャストしたり、コンセンサスプロセスに参加したりすることができません。{% /admonition %}
+
+サーバをプライベートサーバとして設定すると次のさまざまな影響が生じます。
+
+- サーバがピアツーピアネットワーク内の他のサーバに接続するように明示的に設定されていない場合、サーバは他のサーバに発信接続しません。
+- サーバは、他のサーバからの接続を受け入れるように明示的に設定されていない場合、他のサーバからの着信接続を受け入れません。
+- サーバはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPIレスポンス](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)を含む）の中ではサーバのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peersメソッド]などの信頼できる通信には影響しません。
+
+  プライベートサーバの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}新規: rippled 1.2.1{% /badge %}
+
+  {% admonition type="warning" name="注意" %}サーバのソースコードを改ざんして、サーバがこのリクエストを無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバを、このように改ざんされていないことが確認されているサーバにのみ接続するように設定してください。{% /admonition %}
+
+### ピア接続設定のメリットとデメリット
+
+XRP Ledgerで使用できるように、`rippled`サーバをピアツーピアのオープンネットワークの残りの部分に接続する必要があります。大まかに言えば、`rippled`サーバがネットワークに接続する方法には、次の3種類の構成があります。
+
+- **検出されたピア**を使用します。サーバは、検出された信頼の低いサーバに接続し、それらのサーバが適切に動作する限り接続を維持します。（たとえば、リクエストするデータはそれほど多くなく、ネットワーク接続は安定しているため、同じ[ネットワーク](parallel-networks.md)をフォローしているように見えます。）デフォルトでは、この構成に設定されています。
+- 同じユーザまたは組織が実行する**プロキシを使用したプライベートサーバ**として使用します。プロキシは、プライベートサーバとの固定ピア接続を維持するストック用の`rippled`サーバです（検出されたピアにも接続されます）。
+- **公開ハブを使用するプライベートサーバ**として使用します。プロキシを使用する構成と似ていますが、サードパーティーによって異なります。
+
+各構成のメリットとデメリットは次のとおりです。
+
+
+<table>
+<thead><tr>
+<th>設定</th> <th>メリット</th> <th>デメリット</th>
+</tr></thead>
+<tbody>
+<tr><th>検出されたピア</th>
+  <td><ul>
+    <li><p>最もシンプルな構成。メンテナンスの負担が抑えられます。</p></li>
+    <li><p>ダイレクトピア接続の機会が多数得られます。ダイレクトピア接続には、いくつかのメリットがあります。サーバは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。同期時と履歴の埋め戻し時のいずれも可能です。履歴は、すべてのピアで完全に保持されているわけではないため、アクセスするピアを増やすことで、幅広い履歴データにアクセスすることもできます。</p></li>
+    <li><p>切断されたピアを新しいピアに置き換えることができるため、サーバがネットワークから切断される可能性を抑えることができます。</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>サーバのピアを選択することはできません。つまり、ピアによって悪意のある動作が行われるかどうかは不明です。「rippled」サーバは悪意のあるピアから保護するように設計されていますが、悪意のあるピアがソフトウェアの欠陥を悪用してサーバに影響を及ぼすリスクは常にあります。</p></li>
+    <li><p>サーバのピアは頻繁に切断または変更される場合があります。</p></li>
+  </ul></td>
+</tr>
+<tr><th>プロキシを使用したプライベートサーバ</th>
+  <td><ul>
+    <li><p>最も安全で信頼できる構成（効率的に実装された場合）。</p></li>
+    <li><p>信頼性と冗長性を実現します。</p></li>
+    <li><p><a href="clustering.html">クラスタリング</a>によって、プライベートサーバのパフォーマンスを最適化できます。</p></li>
+    <li><p>必要な数のダイレクトピア接続を作成できます。プライベートサーバでは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。複数のピアを実行するため、各ピアで保持するレジャー履歴の量も制御します。</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>複数のサーバを実行することで、メンテナンスの負担とコストは高くなります。</p></li>
+    <li><p>ピア接続が停止する可能性が完全に排除されるわけではありません。実行するプロキシの数に関係なく、それらがすべて同じサーバラックに存在する場合は、1つのネットワーク停止または停電によって、すべてのプロキシに影響が及ぶ可能性があります。</p></li>
+  </ul></td>
+</tr>
+<tr><th>公開ハブを使用するプライベートサーバ</th>
+  <td><ul>
+    <li><p>構成がシンプルでメンテナンスの負担を低減できます。</p></li>
+    <li><p>安全なネットワーク接続に簡単にアクセスできます。</p></li>
+    <li><p>プロキシを使用して接続する場合と比較して、同時ピア停止によりプライベートサーバがネットワークから切断される可能性を低減できます。</p></li>
+  </ul></td>
+  <td><ul>
+    <li><p>信頼性を維持できるように、評判の高いサードパーティー製品を使用します。</p></li>
+    <li>
+      <p>使用する公開ハブが混雑している場合、サーバはネットワークから切断される可能性があります。公開ハブの性質上、ユーザ数が多いため、すべてのユーザに安定した接続を確保することが困難な場合があります。</p>
+      <p>この問題を回避するには、使用するハブを増やします。多いほど効果的です。また、デフォルト以外のハブを使用することをお勧めします。ビジー状態になる可能性が低くなります。</p>
+    </li>
+  </ul></td>
+</tr>
+</tbody>
+</table>
+
+### プライベートサーバの設定
+
+サーバをプライベートサーバとして設定するには、設定ファイルの`[peer_private]`を`1`に設定します。詳細な手順については、[プライベートサーバの設定](../../infrastructure/configuration/peering/configure-a-private-server.md)をご覧ください。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [コンセンサス](../consensus-protocol/index.md)
+  - [並列ネットワーク](parallel-networks.md)
+- **チュートリアル:**
+  - [rippledサーバのクラスター化](../../infrastructure/configuration/peering/cluster-rippled-servers.md)
+  - [プライベートサーバの設定](../../infrastructure/configuration/peering/configure-a-private-server.md)
+  - [ピアクローラーの設定](../../infrastructure/configuration/peering/configure-the-peer-crawler.md)
+  - [ピアリングのポート転送](../../infrastructure/configuration/peering/forward-ports-for-peering.md)
+  - [特定のピアへの手動接続](../../infrastructure/configuration/peering/manually-connect-to-a-specific-peer.md)
+  - [ピアの最大数の設定](../../infrastructure/configuration/peering/set-max-number-of-peers.md)
+  - [ピアリザベーション](../../infrastructure/configuration/peering/use-a-peer-reservation.md)
+- **リファレンス:**
+  - [peersメソッド][]
+  - [peer_reservations_addメソッド][]
+  - [peer_reservations_delメソッド][]
+  - [peer_reservations_listメソッド][]
+  - [connectメソッド][]
+  - [fetch_infoメソッド][]
+  - [ピアクローラー](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/rippled-server-modes.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/rippled-server-modes.md
@@ -0,0 +1,95 @@
+---
+html: rippled-server-modes.html
+parent: networks-and-servers.html
+seo:
+    description: ストックサーバ、バリデータサーバ、スタンドアロンモードで運用されるrippledサーバなど、rippledサーバのモードについて説明します。
+labels:
+  - コアサーバ
+---
+# rippledサーバのモード
+
+`rippled`サーバソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。
+
+- [**P2Pモード**](#p2pモード) - ピアツーピアネットワークをフォローし、トランザクションを処理し、ある程度の[レジャー履歴](ledger-history.md)を維持します。このモードは、以下の役割のいずれか、またはすべてを行うように設定することができます。
+    - [**バリデータ**](#バリデータ) - コンセンサスに参加することで、ネットワークの安全確保に貢献します。
+    - [**APIサーバ**](#apiサーバ) - 共有レジャーからデータを読み込んだり、トランザクションを送信したり、レジャーのアクティビティを監視するための[APIアクセス](../../tutorials/http-websocket-apis/build-apps/get-started.md)を提供します。オプションとして、トランザクションやレジャーの履歴を完全に記録する [**全履歴サーバ**](#全履歴サーバ) とすることができます。
+    - [**ハブサーバ**](#公開ハブ) - ピアツーピアネットワークの他の多くのメンバー間のメッセージを中継します。
+- [**レポートモード**](#レポートモード) - リレーショナルデータベースからのAPIリクエストに対応するための専用モードです。ピアツーピアネットワークには参加しないため、P2Pモードサーバを実行し、信頼できるgRPC接続を使用してレポートモードサーバに接続する必要があります。 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}新規: rippled 1.7.0{% /badge %}
+- [**スタンドアロンモード**](#スタンドアロンモード) - テスト用のオフラインモードです。ピアツーピアネットワークに接続せず、コンセンサスも使用しません。
+
+また、[`rippled` API](../../references/http-websocket-apis/index.md)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
+
+各モードで`rippled`を実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](../../infrastructure/commandline-usage.md)をご覧ください。
+
+
+## P2Pモード
+
+P2Pモードは`rippled`サーバのメインかつデフォルトのモードで、サーバが行うべきほぼ全てのことを処理することができます。これらのサーバは、トランザクションを処理し、XRP Ledgerの共有状態を維持するピアツーピア・ネットワークを形成しています。トランザクションを送信したり、レジャーデータを読んだり、その他ネットワークに参加したい場合、リクエストはどこかでP2Pモードのサーバを経由しなければなりません。
+
+P2Pモードのサーバは、追加機能を提供するためにさらに細かく設定することができます。P2Pモードで動作し、設定ファイルを最小限に変更したサーバは、_ストックサーバ_ とも呼ばれます。その他の構成は以下の通りです。
+
+- [バリデータ](#バリデータ)
+- [APIサーバ](#apiサーバ)
+- [公開ハブ](#公開ハブ)
+
+P2Pモードのサーバは、デフォルトで[Mainnet](parallel-networks.md)に接続します。
+
+### APIサーバ
+
+全てのP2Pモードサーバは、トランザクションの送信、残高や設定の確認、サーバの管理などの目的で、[API](../../references/http-websocket-apis/index.md)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバを運営する](index.md#独自サーバを運用する理由)ことが有効でしょう。
+
+#### 全履歴サーバ
+
+他のいくつかのブロックチェーンとは異なり、XRP Ledgerは、現在のステートの把握や新しいトランザクションの処理のために、サーバが完全なトランザクション履歴を持つことを必要としません。サーバの運用者は、一度にどれだけの[レジャー履歴](ledger-history.md)を保存するかを決めることができます。ただし、P2PモードサーバがAPIリクエストに答えられるのは、ローカルで利用可能なレジャー履歴のみです。例えば、6ヶ月分の履歴を保存している場合、サーバは1年前のトランザクションの結果を示すことはできません。[すべての履歴](ledger-history.md#すべての履歴)を持つAPIサーバは、XRP Ledgerの開始以降のすべてのトランザクションと残高を報告できます。
+
+### 公開ハブ
+
+公開ハブは、他のサーバへの[ピアプロトコル接続](peer-protocol.md)が多数あるストックサーバを指します。ストックサーバを _公開ハブ_ として実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。
+
+- 十分な帯域幅。
+
+- 多数の信頼できるピアとの接続。
+
+- メッセージを確実に中継する能力。
+
+サーバをハブとして設定するには、許可される最大ピア数を増やし、ファイアウォールやNAT（ネットワークアドレス変換）ルーターで[適切なポートを転送](../../infrastructure/configuration/peering/forward-ports-for-peering.md)していることを確認する必要があります。
+
+## バリデータ
+
+XRP Ledgerの堅牢性は、他のバリデータが共謀しないことをそれぞれが信頼している、相互接続されたバリデータのネットワークに依存しています。他のP2Pモードサーバと同様に、各トランザクションを処理し、レジャーの状態を計算することに加え、バリデータは[コンセンサスプロトコル](../consensus-protocol/index.md)に積極的に参加しています。もしあなたやあなたの組織がXRP Ledgerにアクセスするのであれば、バリデータとして1台のサーバを稼働させ、コンセンサスプロセスに貢献することが望ましいでしょう。
+
+バリデーションはわずかな計算資源しか使用しませんが、1つの組織や団体が複数のバリデータを運用しても、共謀に対する保護が強化されるわけではないので、あまりメリットはないでしょう。各バリデータは一意の暗号鍵ペアで識別されるので、慎重に管理しなければいけません。複数のバリデータが鍵ペアを共有してはいけません。このような理由から、バリデーションはデフォルトで無効になっています。
+
+他の目的にも使用されているサーバで、安全にバリデーションを有効にすることができます。このような構成は _汎用サーバ_ と呼ばれます。あるいは、他のタスクを実行しない _専用バリデータ_ を、P2Pモードの他の`rippled`サーバと一緒に[クラスタ](clustering.md)で実行することもできます。
+
+バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)をご覧ください。
+
+
+
+## レポートモード
+{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}新規: rippled 1.7.0{% /badge %}
+
+レポートモードは、APIリクエストをより効率的に処理するために特化したモードです。このモードでは、サーバは[gRPC](../../infrastructure/configuration/configure-grpc.md)を介して、P2Pモードで動作する別の`rippled`サーバから最新の検証済みレジャーデータを取得し、そのデータをリレーショナルデータベース([PostgreSQL](https://www.postgresql.org/))にロードします。レポートモードサーバはピアツーピアネットワークに直接参加しませんが、トランザクションの送信などのリクエストを、使用しているP2Pモードサーバに転送することはできます。
+
+複数のレポートモードサーバは、PostgreSQLデータベースと[Apache Cassandra](https://cassandra.apache.org/)クラスタへのアクセスを共有し、各サーバがすべてのデータの冗長コピーを必要とせずに大量の履歴を提供できます。レポートモードサーバは、基礎となるデータの保存方法の違いに対応するため、若干の変更を加えた同じ[`rippled` API](../../references/http-websocket-apis/index.md)を使ってこのデータを提供します。
+
+最も注目すべきは、レポートモードのサーバは、保留中や未検証のレジャーデータまたはトランザクションをレポートしないことです。この制限は、[分散型取引所](../tokens/decentralized-exchange/index.md)での裁定取引の実行など、流動的なデータへの迅速なアクセスに依存する特定の使用事例に関連しています。
+
+
+## スタンドアロンモード
+
+スタンドアロンモードでは、サーバはネットワークに接続せず、コンセンサスプロセスにも参加せずに動作します。コンセンサスプロセスがなければ、手動で台帳を進める必要があり、「closedレジャー」と「validatedレジャー」の区別はありません。しかし、サーバは依然としてAPIアクセスを提供し、トランザクションを同じように処理します。これにより、以下のことが可能になります。
+
+- 分散型ネットワーク上でAmendmentsが有効になる前に、[Amendmentsの影響をテストする](../../infrastructure/testing-and-auditing/test-amendments.md)。
+- [新しいジェネシスレジャー](../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md)を最初から作成する。
+- ディスクから[既存のレジャーバージョンを読み込み](../../infrastructure/testing-and-auditing/load-a-saved-ledger-in-stand-alone-mode.md)、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。
+
+{% admonition type="warning" name="注意" %}スタンドアロンモードでは[レジャーを手動で進める](../../infrastructure/testing-and-auditing/advance-the-ledger-in-stand-alone-mode.md)必要があります。{% /admonition %}
+
+## 関連項目
+
+- **チュートリアル:**
+  - [`rippled`の構成](../../infrastructure/configuration/index.md)
+  - [スタンドアロンモードでのrippledの使用](../../infrastructure/testing-and-auditing/index.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/the-clio-server.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/the-clio-server.md
@@ -0,0 +1,51 @@
+---
+html: the-clio-server.html
+parent: networks-and-servers.html
+seo:
+    description: Clioは、API呼び出しに最適化されたXRP Ledgerサーバです。
+---
+# Clioサーバ
+
+Clioは、検証済みの台帳データに対するWebSocketまたはHTTP API呼び出しに最適化されたXRP Ledger APIサーバです。
+
+ClioサーバはP2Pネットワークに接続しません。代わりに、P2Pネットワークに接続されている指定された`rippled`サーバからデータを抽出します。APIコールを効率的に処理することで、ClioサーバはP2Pモードで動作する`rippled`サーバの負荷を軽減することができます。
+
+Clioは、検証済みの過去の台帳とトランザクションデータをスペース効率の良いフォーマットで保存し、`rippled`に比べて最大4倍少ないスペースで保存できます。ClioはCassandraまたはScyllaDBを使用し、スケーラブルな読み取りスループットを可能にします。複数のClioサーバが同じデータセットへのアクセスを共有できるため、冗長なデータストレージや計算を必要とせず、Clioサーバの高可用性クラスタを構築することが可能です。
+
+Clioは`rippled`サーバにアクセスする必要があり、このサーバはClioと同じマシン上で実行することも、別々に実行することも可能です。
+
+Clioは完全な[HTTP / WebSocket API](../../references/http-websocket-apis/index.md)を提供していますが、デフォルトでは、検証済みのデータのみを返します。P2Pネットワークへのアクセスを必要とするリクエストに対しては、Clioは自動的にP2Pネットワーク上の`rippled`サーバにリクエストを転送し、レスポンスを返します。
+
+## Clioサーバを運用する理由
+
+独自のClioサーバを運用する理由には様々なものがありますが、その多くは、P2Pネットワークに接続している`rippled`サーバの負荷軽減、メモリ使用量とストレージのオーバーヘッドの低減、水平スケーリングの容易さ、APIリクエストのスループットの向上などに集約されるのではないでしょうか。
+
+* `rippled`サーバの負荷軽減 - Clioサーバはピアツーピア・ネットワークに接続しません。P2Pネットワークに接続されている1つ以上の信頼できる`rippled`サーバから検証済みのデータを取得するためにgRPCを使用します。したがって、Clioサーバはリクエストをより効率的に処理し、P2Pモードで動作する`rippled`サーバの負荷を軽減することができます。
+
+* メモリ使用量とストレージのオーバーヘッドの低減 - ClioはデータベースとしてCassandraを使用し、データをスペース効率の良いフォーマットで保存するため、`rippled`に比べて最大4倍少ないスペースで保存できます。
+
+* 容易な水平スケーリング - 複数のClioサーバが同じデータセットへのアクセスを共有できるため、Clioサーバの高可用性クラスターを構築することが可能です。
+
+* APIリクエストのスループットの向上 - Clioサーバは、1つまたは複数の信頼できる`rippled`サーバから検証済みのデータを抽出し、このデータを効率的に保存します。そのため、APIコールを効率的に処理することができ、結果としてスループットが向上し、場合によってはレイテンシーも低下します。
+
+
+## Clioサーバの仕組み
+
+[{% inline-svg file="/docs/img/clio-basic-architecture.svg" /%}](/docs/img/clio-basic-architecture.svg "図1: Clioサーバの仕組み")
+
+Clioサーバは、トランザクションメタデータ、アカウントステート、台帳ヘッダーなどの有効な台帳データを永続的なデータストアに保存します。
+
+ClioサーバはAPIリクエストを受信すると、これらのデータストアからデータを検索します。P2Pネットワークからのデータを必要とするリクエストについては、ClioサーバはリクエストをP2Pサーバに転送し、レスポンスをクライアントに返します。
+
+以下のいずれかが当てはまる場合、Clioは**常に**`rippled`に転送します。
+
+- `ledger_index`に`current`または`closed`を設定している場合
+- `ledger`APIにおいて`accounts`、`queue`または`full`が`true`に設定されている場合
+- `account_info`APIにおいて`queue`に`true`が設定されている場合
+- リクエストAPIメソッド(`"command"`)において`submit`、`submit_multisigned`、`fee`、`ledger_closed`、`ledger_current`、`ripple_path_find`、`manifest`、`channel_authorize`または`channel_verify`が設定されている場合
+
+## 関連項目
+
+- [Clio ソースコード](https://github.com/XRPLF/clio)
+- **チュートリアル:**
+    - [UbuntuにClioサーバをインストールする](../../infrastructure/installation/install-clio-on-ubuntu.md)
--- a/@l10n/ja/docs/concepts/networks-and-servers/transaction-censorship-detection.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/transaction-censorship-detection.md
@@ -0,0 +1,79 @@
+---
+html: transaction-censorship-detection.html
+parent: networks-and-servers.html
+seo:
+    description: XRP Ledgerでは取引検閲の自動検知機能がすべてのrippledサーバで有効になっています。
+labels:
+  - ブロックチェーン
+---
+# 取引検閲の検知
+
+{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}新規: rippled 1.2.0{% /badge %}
+
+XRP Ledgerは、高い検閲耐性を実現できるように設計されています。この設計をサポートするために、XRP Ledgerでは、取引検閲の自動検知機能がすべての`rippled`サーバで有効になっており、検閲によるネットワークへの影響の有無を、すべての参加者が確認できます。
+
+`rippled`サーバがネットワークと同期している間、検知機能は、`rippled`サーバの観点から、[コンセンサス](../consensus-protocol/index.md)の最終ラウンドで受け入れられ、最後に検証されたレジャーに取り込まれるトランザクションをすべて追跡します。検知機能では、数回のコンセンサスラウンド後、検証済みのレジャーに取り込まれていないトランザクションの重大度が高くなるというログメッセージを発行します。
+
+
+
+## 仕組み
+
+取引検閲検知機能の仕組みの概要を以下に示します。
+
+1. 検知機能は、`rippled`サーバの最初のコンセンサス提案のすべてのトランザクションをトラッカーに追加します。
+
+2. コンセンサスラウンドの終了時に、検知機能によって、検証済みのレジャーに取り込まれているトランザクションはすべて、トラッカーから削除されます。
+
+3. 検知機能は、15個のレジャーのトラッカーに残っているトランザクションについて、ログで[警告メッセージ](#警告メッセージの例)を発行し、潜在的に検閲されたトランザクションとして表面化します。この時点でトラッカーにトランザクションが存在する場合は、15ラウンドのコンセンサスの後、検証済みのレジャーに取り込まれていないことを意味します。トランザクションが別の15個のレジャーのトラッカーに残っている場合は、検知機能によって、ログに別の警告メッセージが発行されます。
+
+   トランザクションがトラッカーに残っている限り、最大5つの警告メッセージに対して、検知機能は15個のレジャーごとにログに警告メッセージを発行し続けます。警告メッセージが5回発行されると、検知機能は、ログに最終的な[エラーメッセージ](#エラーメッセージの例)を発行し、警告およびエラーメッセージの発行を停止します。
+
+   `rippled`サーバログにこれらのメッセージが表示される場合、他のサーバでトランザクションを取り込むことができない理由を調査する必要があります。まず、原因が悪意のある検閲よりも[誤検知](#誤検知の可能性)（無害なバグ）である可能性が高いと仮定します。
+
+
+
+## 警告メッセージの例
+
+トランザクションE08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7がレジャー18851530～18851545までの15個のレジャーのトラッカーに残っている場合に、取引検閲検知機能によって発行される警告メッセージの例を次に示します。
+
+```text
+LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
+```
+
+
+## エラーメッセージの例
+
+トランザクションE08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7がレジャー18851530～18851605までの75個のレジャー（15個のレジャーの5セット）のトラッカーに残っている場合に、取引検閲検知機能によって発行されるエラーメッセージの例を以下に示します。
+
+```text
+LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605.Additional warnings suppressed.
+```
+
+
+## 誤検知の可能性
+
+シナリオによっては、取引検閲検知機能で誤検知が発生する場合があります。この場合、誤検知とは、15個以上のレジャーについてトラッカーに残っているトランザクションにフラグが立てられたことを意味しますが、これによる問題はありません。
+
+検知機能で誤検知メッセージが発行される可能性のあるシナリオを次に示します。
+
+- `rippled`サーバでは、ネットワークの他の部分とは異なるコードでビルドを実行しています。そのため、トランザクションは`rippled`サーバ上で別の方法で適用され、結果として誤検知の原因になります。このような誤検知が発生することはほとんどありませんが、一般的に、正しいバージョンの`rippled`を実行することが重要です。
+
+- `rippled`サーバはネットワークと同期されていないため、現時点で認識されていません。
+
+- ネットワーク内の`rippled`サーバ（自身のサーバも含まれる可能性が高い）は、`rippled`サーバがトランザクションをネットワーク内の他の`rippled`サーバに一貫性なく中継するバグのクラスの影響を受けています。
+
+  現在、この予期しない動作の原因となる既知のバグはありません。ただし、バグの疑いがある影響を確認した場合は、[RippleのBug Bounty](https://ripple.com/bug-bounty/)プログラムへのご報告をお願いいたします。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [コンセンサスの原理とルール](../consensus-protocol/consensus-principles-and-rules.md)
+  - [トランザクションキュー](../transactions/transaction-queue.md)
+- **チュートリアル:**
+  - [信頼できるトランザクションの送信](../transactions/reliable-transaction-submission.md)
+  - [ログメッセージについて](../../infrastructure/troubleshooting/understanding-log-messages.md)
+- **リファレンス:**
+  - [トランザクションの結果](../../references/protocol/transactions/transaction-results/index.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/payment-types/bouncing-payments.md
+++ b/@l10n/ja/docs/concepts/payment-types/bouncing-payments.md
@@ -0,0 +1,19 @@
+---
+html: bouncing-payments.html
+parent: payment-types.html
+seo:
+    description: 支払いの目的が不明確な場合は、送り主に返却してください。
+labels:
+  - トークン
+---
+# 不明な入金の返金
+
+アドレスが不明な支払いを受け取った場合、送金者に返金することが推奨されます。これは、資金を保管するよりも手間がかかりますが、顧客に対する誠意を示すことになります。オペレーターが手動で支払いを返金することもできますし、自動的に返金するシステムを構築することもできます。
+
+返金の失敗を防ぐための第一の条件は、[入金を適切に監視する](robustly-monitoring-for-payments.md)ことです。顧客から送られてきた金額以上の金額を誤って返金してしまうことは避けなければなりません！(悪意のあるユーザは、[部分支払い](partial-payments.md#partial-payments-exploit)を送信して、脆弱なシステムを利用します。)
+
+第二に、返金を部分支払い(Partial Payment)として送信することです。第三者はアドレス間のパスのコストを操作することができるので、部分支払いを使えば、XRP Ledger内の取引レートを気にすることなく、支払い金額の全額を手放すことができます。利用規約の一部に、支払い失敗時のポリシーを公表する必要があります。失敗された支払いを、運用中のアドレスまたは待機中のアドレスのいずれかから送信します。
+
+部分支払いを送信するには、トランザクションの[`tfPartialPayment`フラグ](../../references/protocol/transactions/types/payment.md#payment-flags)を有効にします。`Amount`フィールドに受け取った金額を設定し、`SendMax`フィールドは省略します。受信した支払いの`SourceTag`値を、返金する支払いの`DestinationTag`値として使用する必要があります。
+
+2つのシステムで返金が繰り返されるのを防ぐため、送信する返金に新しい送信タグを設定することができます。もしシステムが予期しない支払いを受け取った場合で、その支払いの宛先タグが送信した返金の送信元タグと一致する場合は、その支払いを再び返金させないようにします。
--- a/@l10n/ja/docs/concepts/payment-types/checks.md
+++ b/@l10n/ja/docs/concepts/payment-types/checks.md
@@ -0,0 +1,114 @@
+---
+html: checks.html
+parent: payment-types.html
+seo:
+    description: Checksを使用すると、指定の受取人による取消または換金が可能な後払いの支払いを生成することができます。
+labels:
+  - Checks
+  - 支払い
+  - トークン
+---
+# Checks
+
+_（[Checks Amendment][]が必要です）_
+
+XRP LedgerのChecks機能を使用すると、指定の受取人による取消または換金が可能な後払いの支払いを生成することができます。個人用の紙の小切手と同様に、XRP Ledger Checksでは最初に資金の送金元が金額と受取人を指定するCheckを作成します。受取人はCheckを換金して、送金元のアカウントから受取人のアカウントに資金を移動します。受取人がCheckを換金するまでは、実際の資金移動は発生しません。Checkの作成時には資金は保留されていないことから、受取人が換金する時点で送金元に十分な資金がない場合、従来の小切手同様に換金が失敗します。Checkを換金できなかった場合、送信者はCheckが有効期限切れになるまで再試行できます。
+
+XRP Ledger Checksには有効期限があり、この期限を過ぎると換金できなくなります。受取人が有効期限までにCheckを換金できなかった場合、Checkオブジェクトは誰かに取り消されるまでXRP Ledgerに残ります。有効期限切れになったCheckは誰でも取り消すことができます。有効期限前、あるいはChecksが換金されるまでは、送金元と受取人のみがCheckを取り消すことができます。Checkオブジェクトは、送金元がそのCheckを換金できた時点または誰かが取り消した時点でLedgerから削除されます。
+
+Checksは[Escrow](escrow.md)と[Payment Channel](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)に似ていますが、Checksとこれらの機能の間には重要な相違がいくつかあります。
+
+* Checksではトークンを送金できます。Payment ChannelとEscrowで送金できるのはXRPのみです。
+
+* Checksは資金を凍結しません。Payment ChannelとEscrowでは、送金元が発行したクレームでXRPが清算されるか（Payment Channel）、または有効期限切れまたはCrypto-conditionsによってXRPがリリースされる（Escrow）までは、そのXRPを使用できません。
+
+* EscrowではXRPを自分自身に送金できます。ChecksではXRPを自身に送金することはできません。
+
+
+{% admonition type="info" name="注記" %}[Checks Amendment][] により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](../tokens/decentralized-exchange/offers.md#オファーの有効期限)をご覧ください。{% /admonition %}
+
+
+## Checksを利用する理由
+
+従来の紙の小切手では、実際の通貨を即座にやり取りすることなく残高を送金できます。XRP Ledger Checksを使用すると、銀行業界でよく利用され受け入れられている方法で資金を非同期にやり取りすることができます。
+
+XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。たとえば、ユーザが不審な支払いを拒否したり、支払いの一部のみを受領することを可能にします。これは、コンプライアンス上の理由から支払いの受け入れに慎重に対応する必要がある機関にとっては有用です。
+
+
+### ユースケース: 支払いの承認
+
+**課題:** [BSA、KYC、AML、CFT](../tokens/fungible-tokens/stablecoins/compliance-guidelines.md)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合にはトークンを）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
+
+**解決策:** 金融機関は各自のXRP Ledgerのアカウントで、[`AccountSet`トランザクションの`asfDepositAuth`フラグを設定](../../references/protocol/transactions/types/accountset.md)することにより、[Deposit Authorization](../accounts/depositauth.md)を有効にできます。これにより、アカウントはPaymentトランザクションを受領できなくなります。Deposit Authorizationが有効なアカウントは、Escrow、Payment Channel、またはChecksでのみ資金を受領できます。Deposit Authorizationが有効な場合、Checksが最もシンプルで使いやすく、柔軟な資金移動手段となります。
+
+
+## 使用法
+
+Checksの一般的なライフサイクルを以下で説明します。
+
+<!--{# Diagram source: https://docs.google.com/drawings/d/1Ez8OZVB2TLH-b_kSFOAgfYqXlEQt4KaUBW6F3TJAv_Q/edit #}-->
+
+[![Checkのフローチャート（換金に成功した場合）](/docs/img/checks-happy-path.ja.png)](/docs/img/checks-happy-path.ja.png)
+
+**ステップ1:** Checkを作成するため、送金元が[CheckCreate][]トランザクションを送信し、受取人（`Destination`）、有効期限（`Expiration`）、および送金元アカウントからの引き落とし限度額（`SendMax`）を指定します。
+
+
+**ステップ2:** CheckCreateトランザクションの処理が完了すると、XRP Ledgerに[Checkオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/check.md)が作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたCheckのプロパティーが含まれています。有効期限前にこのオブジェクトを変更できるのは、送金元（[CheckCancel][]トランザクションで取り消す）と受取人（取り消すかまたは換金する）だけです。有効期限の経過後は、誰でもCheckを取り消すことができます。
+
+**ステップ3:** Checkを換金するため、受取人が[CheckCash][]トランザクションを送信します。受取人には次の2つのCheck換金オプションがあります。
+
+* `Amount` — 受取人はこのオプションを使用して換金する正確な額を指定できます。これは、送金元が想定される[送金手数料](../tokens/transfer-fees.md)をCheckの額に上乗せし、受取人は請求書やその他の契約に記載されている指定された額のみ受け取れるようにする場合に役立ちます。
+
+* `DeliverMin` — 受取人はこのオプションを使用してCheckから受領する最小額を指定できます。受取人がこのオプションを使用する場合、`rippled`は可能な限り多くの送金を試み、少なくともこの額以上を送金します。受取人に入金できる額がこの額よりも少ない場合には、このトランザクションは失敗します。
+
+送金元にCheckの裏付けとなる資金が十分あり、有効期限が経過してなければ、資金は送金元のアカウントから引き落とされ、受取人のアカウントに入金され、Checkオブジェクトは消却されます。
+
+
+
+#### 有効期限切れの例
+
+Checksが有効期限切れになった場合のライフサイクルを以下で説明します。
+
+<!--{# Diagram source: https://docs.google.com/drawings/d/11auqa0kVUPonqlc_RaQUfHcSkUI47xneSKpwlLxzSK0/edit #}-->
+
+[![Checkのフローチャート（有効期限切れ）](/docs/img/checks-expiration.ja.png)](/docs/img/checks-expiration.ja.png)
+
+
+Checksはすべて同じ方法で開始されるため、**ステップ1と2**は換金の例と同じです。
+
+**ステップ3a:** 受取人が換金する前にCheckが有効期限切れになると、そのCheckは換金できなくなりますが、レジャーに残ります。
+
+**ステップ4a:** 有効期限切れになったCheckは、[CheckCancel][]トランザクションを送信することで誰でも取り消すことができます。このトランザクションによりレジャーからCheckが削除されます。  
+
+
+
+## Checksの利用可能性
+
+[Checks amendment][]は2020年6月18日にメインネットで有効化されました。Amendmentがどのように有効化され、投票されるかについては、[Amendmentsプロセス](../networks-and-servers/amendments.md#amendmentプロセス)をご覧ください。
+
+Test NetまたはプライベートXRP LedgerネットワークでのAmendmentの状況を確認するには、[featureメソッド][]を使用してください。
+
+
+## 参考情報
+
+XRP LedgerのChecksの詳細は、以下をご覧ください。
+
+- [トランザクションのリファレンス](../../references/protocol/transactions/types/index.md)
+    - [CheckCreate][]
+    - [CheckCash][]
+    - [CheckCancel][]
+- [Checksのチュートリアル](../../tutorials/how-tos/use-specialized-payment-types/use-checks/index.md)
+    - [Checkの送信](../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md)
+    - [Checksの検索](../../tutorials/how-tos/use-specialized-payment-types/use-checks/look-up-checks.md)
+    - [Checkの指定された金額での換金](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-an-exact-amount.md)
+    - [Checkの変動金額での換金](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md)
+    - [Checkの取消し](../../tutorials/how-tos/use-specialized-payment-types/use-checks/cancel-a-check.md)
+- [Checks Amendment][]
+
+関連機能の詳細については、以下をご覧ください。
+
+* [Deposit Authorization](../accounts/depositauth.md)
+* [Escrow](escrow.md)
+* [Payment Channelチュートリアル](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/payment-types/cross-currency-payments.md
+++ b/@l10n/ja/docs/concepts/payment-types/cross-currency-payments.md
@@ -0,0 +1,31 @@
+---
+html: cross-currency-payments.html
+parent: payment-types.html
+seo:
+    description: クロスカレンシー支払いでは、パスとオーダーブックを通じて変換するのとは異なる通貨を自動的にに送金します。
+labels:
+  - クロスカレンシー
+  - 支払い
+---
+# クロスカレンシー支払い
+
+XRP Ledgerでは、1つ以上のトークンとXRP、またはその両方を交換して、クロスカレンシー支払いができます。[XRPによる直接支払い](../../tutorials/how-tos/send-xrp.md)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでのクロスカレンシー支払いは完全にアトミックです。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
+
+デフォルトでは、クロスカレンシー支払いでは宛先に一定額が送金され、支払元が変動コストを負担します。クロスカレンシー支払いが、[Partial Payments](partial-payments.md)で行われ、一定の送金限度内の変動額が宛先に送金される場合もあります。
+
+
+## 前提条件
+
+- 定義上、クロスカレンシー支払いには2種類以上の通貨が関係します。つまり、関係する通貨のうち、少なくとも1種類以上がXRP以外のトークンである必要があります。
+    - 通常は、[XRP Ledgerゲートウェイ](../../use-cases/tokenization/stablecoin-issuer.md)が発行した通貨を1種類以上使用することになります。このような通貨はXRP Ledger外部の資金を担保とし、ゲートウェイを通じて引き出すことができます。
+    - 取引を行う当事者が、XRP Ledger内でのみ発行され、外部の担保がないデジタルトークンを送受信し、何らかの価値を持つ資産として取り扱うことを望む限り、このデジタルトークンを使用することもできます。
+- 送金元と受取人の間に1つ以上の[パス](../tokens/fungible-tokens/paths.md)が確立しており、すべてのパスの総流動性が、支払いを促進するのに十分である必要があります。クロスカレンシー支払いの場合、これは一般に通貨取引[オファー](../tokens/decentralized-exchange/offers.md)を消費することを意味します。
+
+
+## オートブリッジング
+
+2種類のトークンを自動的に交換するクロスカレンシー支払いでは、XRPの使用により支払いコストを抑えられる場合には自動的にXRPが使用されます。この場合、オーダーブックを接続して流動性プールが拡大されます。たとえば、USDからMXNに送金する支払いの場合、USDからXRP、XRPからMXNへの交換にかかるコストが、USDからMXNへの直接交換にかかるコストよりも低い場合には、前者の交換が自動的に実行されます。
+
+詳細は、[オートブリッジング](../tokens/decentralized-exchange/autobridging.md)をご覧ください。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/payment-types/direct-xrp-payments.md
+++ b/@l10n/ja/docs/concepts/payment-types/direct-xrp-payments.md
@@ -0,0 +1,90 @@
+---
+html: direct-xrp-payments.html
+parent: payment-types.html
+seo:
+    description: XRPによる直接支払いは、XRP Ledgerで資産を送金する最も簡単な方法です。
+---
+# XRPによる直接支払い
+
+金融システムの基本は、 _価値の移動_ です。一言で言えば、決済です。XRP Ledgerでの最も簡単な支払いタイプは、XRP間の直接支払いで、XRP Ledgerのあるアカウントから別のアカウントにXRPを直接移動します。
+
+## XRP間の直接支払いについて
+
+一般的に、XRPは、XRP Ledgerのどのアドレスからでも、他のアドレスに直接送金できます。受信側のアドレスは _宛先アドレス_ 、送信側のアドレスは _支払元アドレス_ と呼ばれます。XRPを直接送金するには、送信者は[Paymentトランザクション][]を使用します。これは、次のように簡潔に表すことができます。
+
+```json
+{
+  "TransactionType": "Payment",
+  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+  "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
+  "Amount": "13000000"
+}
+```
+
+上記のトランザクション指示によって、以下のように実行されます。rf1Bi ...からra5nK... にPaymentを送信することで、ちょうど13 XRPが送金されます。トランザクションが正常に処理されると、その内容が正確に実行されます。新しいレジャーバージョンが[検証済み](../consensus-protocol/index.md)になるまでに、通常約4秒かかるため、現在処理中のレジャーの後にレジャーバージョンのキューに入れられても、正常なトランザクションを作成、送信、実行後、8秒以内に最終結果を出すことができます。
+
+{% admonition type="warning" name="注意" %}[Paymentトランザクションタイプ][Payment]は、[通貨間の支払い](cross-currency-payments.md)や[Partial Payment](partial-payments.md)を含む、より特殊な支払いにも使用できます。Partial Paymentの場合、トランザクションで非常に少ない金額しか送金しなかった場合でも、多額のXRPが`Amount`に表示される可能性があります。誤った金額を顧客に入金しないようにする方法については、[Partial Paymentの悪用](partial-payments.md#partial-paymentの悪用)をご覧ください。{% /admonition %}
+
+XRP間の直接支払いではPartial Paymentは使用できませんが、Partial Paymentでは複数の送金元通貨から変換後にXRPを送金できます。
+
+
+## アカウントの資金提供
+
+XRP Ledgerにそのアドレスの記録が事前に存在していなくても、支払いで[口座準備金](../accounts/reserves.md)の最少額を満たすのに十分なXRPが送金されれば、数学的に有効なアドレスで支払いを受け取ることができます。支払いで十分なXRPを送金できない場合は失敗します。
+
+詳細は、[アカウント](../accounts/index.md#アカウントの作成)をご覧ください。
+
+
+## アドレスの再利用
+
+XRP Ledgerでは、支払いを受け取ることができるアドレスは永続的ですが、XRPの重要な[必要準備金](../accounts/reserves.md)は消費できません。つまり、他の一部のブロックチェーンシステムとは異なり、トランザクションごとに異なる使い捨てアドレスを使用することはお勧めできません。XRP Ledgerでは、ベストプラクティスとして、複数のトランザクションに同じアドレスを再利用することをお勧めします。アドレスを定期的に使用する場合（特にインターネット接続サービスによって管理されている場合）は、[レギュラーキー](../accounts/cryptographic-keys.md)を設定し、キーの漏えいのリスクを低減するためにキーを定期的に事前変更する必要があります。
+
+送金元は、目的の受取人が最後に支払いを送信したときと同じアドレスを使用していると仮定しないことが重要です。必然的に、セキュリティの侵害が発生し、ユーザまたは企業はアドレスを変更しなければならない場合があります。送金する前に、現在の受取アドレスを受取人に尋ねてください。これにより、漏えいした古いアドレスを制御している不正ユーザに誤ってお金を送信することはありません。
+
+
+## XRPによる直接支払いの処理方法
+
+大まかに言えば、XRP Ledgerのトランザクション処理エンジンでは、XRPによる直接支払いを次のように適用します。
+
+1. [Paymentトランザクション][]のパラメータを検証します。トランザクションがXRPを送信、送金するように構成されている場合、トランザクション処理エンジンはそのトランザクションをXRP間の直接支払いとして認識します。検証チェックは次のように行います。
+
+   - すべてのフィールドが正しいフォーマットであることを確認します。たとえば、XRPによる直接支払いの場合、`Amount`フィールドは[XRPのdrop数][]でなければなりません。
+   - 送信元アドレスがXRP Ledgerの資金供給された[アカウント](../accounts/index.md)であることを確認します。
+   - 指定された署名がすべて、送信元アドレスに対して有効であることを確認します。
+   - 宛先アドレスと送金元アドレスが異なることを確認します。（[宛先タグ](../transactions/source-and-destination-tags.md)が異なる同一アドレスに送金するだけでは不十分です。）
+   - Paymentを送信するのに十分なXRP残高が送金元にあることを確認します。
+
+   いずれかのチェックに失敗すると、支払いは失敗します。
+
+2. 受取アドレスが、資金供給されたアカウントかどうかを確認します。
+
+   - 受取アドレスに資金が供給されている場合は、[DepositAuth](../accounts/depositauth.md)や[RequireDest](../transactions/source-and-destination-tags.md#タグの必須化)など、支払いの受け取りに関する制限が受取アドレスにあるかどうかを確認します。そのような制限を支払いが満たしていない場合、支払いは失敗します。
+   - 受取アドレスに資金が供給されていない場合は、[必要準備金](../accounts/reserves.md)の最低額を満たすのに十分なXRPが支払いで送金されるかどうかを確認します。十分でない場合、支払いは失敗します。
+
+3. `Amount`フィールドで指定されたXRPの金額と、[トランザクションコスト](../transactions/transaction-cost.md)用に消却されるXRPの金額の合計を送金元アカウントから引き落とし、受取アカウントに同じ金額を送金します。
+
+   必要に応じて、受取アドレス用に新規アカウント([AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)) を作成します。新規アカウントの開始残高は、支払いの`Amount`と同額になります。
+
+   エンジンは、[トランザクションのメタデータ](../../references/protocol/transactions/metadata.md)に`delivered_amount`フィールドを追加して、送金金額を示します。正しい金額のXRPを受け取ったことを確認できるように、必ず`delivered_amount`を使用する必要があります。`Amount`フィールドでは**ありません**。（通貨間の支払「Partial Payment」では、`Amount`フィールドに記載されているよりも少額のXRPが送金される場合があります。）詳細は、[Partial Payments](partial-payments.md)をご覧ください。
+
+
+## 他の支払いタイプとの比較
+
+- **XRPによる直接支払い**は、単一のトランザクションでXRPを送受信する唯一の方法です。この方法は、速度、シンプルさ、低コストの面でバランスが取れています。
+- [通貨間の支払い](cross-currency-payments.md)でも[Payment][]トランザクションタイプを使用しますが、XRPとXRP以外の[トークン](../tokens/index.md)を組み合わせて送金できます。ただし、XRP間の支払いは除きます。また、[Partial Payment](partial-payments.md)でも使用できます。通貨間の支払いは、XRPで指定されていない支払いや、[分散型取引所](../tokens/decentralized-exchange/index.md)で裁定取引の機会を得るのに適しています。
+- [Checks](checks.md)すぐに送金せずに送金元に債務を設定してもらいます。受取人は有効期間内であればいつでも換金できますが、その金額は保証されません。Checksでは、XRPまたはトークンのいずれかを送金できます。Checksは、受取人に支払いを請求する自律性を与えるのに適しています。
+- [Escrow](escrow.md)では、特定の条件が満たされたときに、意図した受取人が要求できるXRPを確保します。XRPの金額は完全に保証されており、Escrowの有効期限が切れない限り、送金元が使用することはできません。Escrowは、巨額のスマートコントラクトに適しています。
+- [Payment Channel](payment-channels.md)では、XRPが確保されます。受取人は、署名による認証を使用して、チャネルから一括でXRPを要求できます。XRP Ledgerの全トランザクションを送信せずに、認証を個々に確認できます。Payment Channelは、極めて大量の小口決済または「ストリーミング」支払いに適しています。
+
+
+## 関連項目
+
+- **チュートリアル:**
+    - [XRPの送金（対話型チュートリアル）](../../tutorials/how-tos/send-xrp.md)
+    - [WebSocketを使用した着信ペイメントの監視](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
+- **リファレンス:**
+    - [Paymentトランザクション][]
+    - [トランザクションの結果](../../references/protocol/transactions/transaction-results/index.md)
+    - [account_infoメソッド][] - XRP残高を確認します。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/payment-types/escrow.md
+++ b/@l10n/ja/docs/concepts/payment-types/escrow.md
@@ -0,0 +1,96 @@
+---
+html: escrow.html
+parent: payment-types.html
+seo:
+    description: XRPはEscrowに預託され、後日特定の条件が満たされた時点で送金されます。Escrowは時間制限、暗号条件、あるいはその両方によって異なる場合があります。
+labels:
+  - Escrow
+---
+# Escrow
+
+従来より、Escrowとは、金融取引を円滑に行うための二者間の契約です。公平な第三者が資金を受領・保管し、契約で指定された条件が満たされた場合にのみ、目的の受取人に資金を提供します。この方法により、両当事者は確実に義務を果たすことができます。
+
+XRP LedgerはEscrowをさらに一歩進め、サードパーティをレジャーに組み込まれた自動システムに置き換えます。EscrowはXRPをロックし、条件が満たされるまで使用も破棄もできません。
+
+## Escrowの種類
+
+XRP Ledgerは3つの種類のEscrowをサポートします。
+
+- **時間ベースのEscrow:** 一定の時間が経過した後資金が利用可能になります。
+- **条件付きEscrow:** このEscrowは、対応する条件(condition)と履行(フルフィルメント)を設定して作成されます。条件は資金をロックする役割を果たし、正しい履行キーが提供されるまで解除されません。
+- **複合Escrow:** このEscrowは、時間ベースEscrowと条件付きEscrowの特徴を兼ね備えています。このEscrowは、指定された時間が経過するまでは全くアクセスすることができず、その後、正しい履行を行うことで資金を解放することができます。
+
+## Escrowのライフサイクル
+
+1. 送信者は`EscrowCreate`トランザクションを用いてEscrowを作成します。このトランザクションは以下を指定します。
+
+    - ロックするXRPの量
+    - XRPをリリースする条件
+    - XRPの受取人
+
+2. トランザクションが処理されると、XRP LedgerはEscrowされたXRPを保持する`Escrow`オブジェクトを作成します。
+
+3. 受取人はXRPを受け渡すために`EscrowFinish`トランザクションを送信します。条件が満たされた場合、`Escrow`オブジェクトは破棄され、XRPは受取人に引き渡されます。
+
+    {% admonition type="info" name="注記" %}Escrowに有効期限があり、それまでに正常に終了しなかった場合、Escrowは期限切れになります。期限切れのEscrowは`EscrowCancel`トランザクションがそれをキャンセルするまで台帳に残り、`Escrow`オブジェクトを破棄してXRPを送信者に返します。{% /admonition %}
+
+## 状態遷移図
+
+次の図は、Escrow実施時の各状態を示します。
+
+[![Escrowの状態がHeld → Ready/Conditionally Ready → Expiredと遷移する様子を示す状態遷移図](/docs/img/escrow-states.ja.png)](/docs/img/escrow-states.ja.png)
+
+この図は、Escrowの「Finish-after」時刻（`FinishAfter`フィールド）、Crypto-condition（`Condition`フィールド）、および有効期限（`CancelAfter`フィールド）の3通りの組み合わせの3つの例を示します。
+
+- **時間ベースのEscrow（左）:** Finish-after時刻のみが設定されているEscrowは、**Held**状態で作成されます。指定の時刻が経過すると**Ready**になり、誰でもこのEscrowを終了できるようになります。Escrowに有効期限が設定されており、その時刻になるまでに誰もEscrowを終了しないと、そのEscrowは**Expired**になります。Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。Escrowに`CancelAfter`フィールドが設定されていない場合、Escrowが期限切れになることがないため、キャンセルできません。
+
+- **複合Escrow（中央）:** EscrowでCrypto-condition（`Condition`フィールド） _および_ 「Finish-after」時刻（`FinishAfter`フィールド）の両方が指定されている場合、Finish-after時刻が経過するまでEscrowは**Held**状態です。その後**Conditionally Ready**になり、Crypto-conditionに対し正しいフルフィルメントを提供すればEscrowを終了できます。Escrowに有効期限（`CancelAfter`フィールド）が設定されており、その時刻になるまでに誰もEscrowを終了しないと、そのEscrowは**Expired**になります。Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。Escrowに`CancelAfter`フィールドが設定されていない場合、Escrowが期限切れになることがないため、キャンセルできません。
+
+- **条件付きEscrow（右）:** EscrowでCrypto-condition（`Condition`フィールド）が指定されており、Finish-after時刻が指定されていない場合、Escrowは作成時点で即時に**Conditionally Ready**になります。この時点では、Crypto-conditionに対する正しいフルフィルメントを提供した人だけがEscrowを終了できます。有効期限（`CancelAfter`フィールド）までに終了されなかったEscrowは**Expired**になります。（Finish-after時刻が設定されていないEscrowには、有効期限が設定されている _必要があります_ 。）Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。
+
+
+## 制約事項
+
+- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
+- 少額での利用はコスト面で難しいかもしれません。
+    - Crypto-conditionを使用する場合、[EscrowFinishトランザクションのコスト](#escrowfinishトランザクションのコスト)が通常よりも高くなります。
+    - エスクローが未成立な間は、`Escrow`オブジェクトの[準備金](../accounts/reserves.md)は送信者の責任となります。
+- Escrowを作成するトランザクションの実行時には、時刻の値が過去の時間であってはなりません。
+- 時限リリースおよび有効期限は、レジャークローズに制約されます。つまり実際には、レジャーの正確なクローズ時刻に基づいて、これらの時刻が約5秒単位で丸められる場合があります。
+- サポートされている唯一の[Crypto-condition][]タイプはPREIMAGE-SHA-256です。
+
+
+## EscrowFinishトランザクションのコスト
+
+Crypto-conditionを使用する場合、Crypto-conditionフルフィルメントの検証に高い処理負荷がかかるため、EscrowFinishトランザクションでは[高額なトランザクションコスト](../transactions/transaction-cost.md#特別なトランザクションコスト)を支払う必要があります。
+
+追加で必要となる取引コストはフルフィルメントのサイズに比例します。トランザクションが[マルチシグ](../accounts/multi-signing.md)の場合、マルチサインのコストはフルフィルメントのコストに追加されます。
+
+必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](../../references/protocol/data-types/basic-data-types.md#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。
+
+{% admonition type="info" name="注記" %}上記の式は、トランザクションのリファレンスコストが10 dropであることを前提としています。{% /admonition %}
+
+[手数料投票](../consensus-protocol/fee-voting.md)により`reference_fee`の値が変更される場合、この式は新しいリファレンスコストに基づいてスケーリングされます。フルフィルメントのあるEscrowFinishトランザクションの公式は次のとおりです。
+
+```
+reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
+```
+
+
+
+## 参考情報
+
+XRP LedgerのEscrowの詳細は、以下をご覧ください:
+
+- [Escrowチュートリアル](../../tutorials/how-tos/use-specialized-payment-types/use-escrows/index.md)
+- [トランザクションのリファレンス](../../references/protocol/transactions/index.md)
+    - [EscrowCreateトランザクション][]
+    - [EscrowFinishトランザクション][]
+    - [EscrowCancelトランザクション][]
+- [レジャーリファレンス](../../references/protocol/ledger-data/index.md)
+    - [Escrowオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
+
+
+Rippleによる550億XRPのロックアップについては、[Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)をご覧ください。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/payment-types/index.md
+++ b/@l10n/ja/docs/concepts/payment-types/index.md
@@ -0,0 +1,15 @@
+---
+html: payment-types.html
+parent: concepts.html
+metadata:
+  indexPage: true
+seo:
+    title: ポイント・ツー・ポイント & 特別な支払いの種類
+    description: XRP Ledgerはポイント・ツー・ポイントのXRPペイメントのほかに、特別な支払いタイプをサポートしています。XRP Ledgerの支払い方法については、こちらをご覧ください。
+---
+# 支払いのタイプ
+
+XRP Ledgerはポイント・ツー・ポイントのXRPペイメントのほかに、特別な支払いタイプをサポートしています。
+
+
+{% child-pages /%}
--- a/@l10n/ja/docs/concepts/payment-types/partial-payments.md
+++ b/@l10n/ja/docs/concepts/payment-types/partial-payments.md
@@ -0,0 +1,120 @@
+---
+html: partial-payments.html
+parent: payment-types.html
+seo:
+    description: Partial Paymentsは送金額から手数料を差し引き、変動額を送金します。Partial Paymentsは、追加コストなしで不審な支払いを返金したい場合に便利です。
+labels:
+  - 支払い
+  - セキュリティ
+---
+# Partial Payment
+
+デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](../tokens/transfer-fees.md)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](../../references/protocol/transactions/types/payment.md#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](bouncing-payments.md)したい場合に便利です。
+
+[トランザクションコスト](../transactions/transaction-cost.md)に使用されるXRPの額は、トランザクションタイプに関わらず常に送金元のアカウントから差し引かれます。
+
+Partial Paymentは、XRP Ledgerとのネイティブ統合を悪用して取引所およびゲートウェイから資金を盗むのに使用される恐れがあります。本書の[Partial Paymentの悪用](#partial-paymentの悪用)セクションで、この悪用の仕組みと防止対策を説明します。
+
+## セマンティクス
+
+### Partial Paymentを使用しない場合
+
+Partial Paymentフラグを使用しないで送金する場合、トランザクションの`Amount`フィールドに実際の送金額を指定し、`SendMax`フィールドに送金上限額と通貨を指定します。`Amount`の額を全額送金すると`SendMax`パラメーターの値を超えてしまう場合や、その他何らかの理由で総額を送金できない場合は、トランザクションは失敗します。トランザクション指示で`SendMax`フィールドが省略されると、`Amount`と同額とみなされます。この場合、手数料の合計が0である場合のみ支払が成功します。
+
+つまり、次の式になります。
+
+```
+Amount+（手数料）=（送金額）≤ SendMax
+```
+
+この式の「手数料」は、[送金手数料](../tokens/transfer-fees.md)と通貨の為替レートを指します。送金額（`Amount`）の通貨は、送金側と受取側で異なる通貨建てにすることができ、XRP Ledgerの分散型取引所でオファーを消費することにより交換されます。
+
+{% admonition type="info" name="注記" %}トランザクションの`Fee`フィールドが参照するXRP[トランザクションコスト](../transactions/transaction-cost.md)は、トランザクションをネットワークに中継するために消却されます。トランザクションコストは、常に指定通りの額が送金元から引き落とされ、あらゆるタイプの支払の手数料計算とは完全に切り離されています。{% /admonition %}
+
+### Partial Paymentを使用する場合
+
+Partial Paymentフラグが有効になっている支払を送金する場合、このトランザクションの`Amount`フィールドには送金限度額を指定します。Partial Paymentでは、制限（手数料、流動性不足、受取アカウントのトラストラインの枠不足など）の有無にかかわらず、指定額の _一部_ を送金できます。
+
+オプションの`DeliverMin`フィールドには、送金下限額を指定します。`SendMax`フィールドは、Partial Payment以外で送金する場合と同様に機能します。Partial Paymentトランザクションは、送金額が`DeliverMin`フィールドの金額以上、`SendMax`の金額未満であれば成功します。`DeliverMin`フィールドに指定のない場合、任意の正の金額の送金であれば、Partial Paymentは成功します。
+
+つまり、次の式になります。
+
+```
+金額 ≥（送金額）= SendMax -（手数料）≥ DeliverMin > 0
+```
+
+### Partial Paymentの制限事項
+
+Partial Paymentには次の制限事項があります。
+
+- Partial Paymentでは、アドレスにXRPにて資金を供給できません。この場合、[結果コード][]`telNO_DST_PARTIAL`が返されます。
+- Partial Paymentでは、XRP間の直接決済はできません。この場合、[結果コード][]`temBAD_SEND_XRP_PARTIAL`が返されます。
+    - ただし、イシュアンスからXRPへの支払またはXRPからイシュアンスへの支払は、Partial Paymentが可能です。
+
+[結果コード]: ../../references/protocol/transactions/transaction-results/index.md
+
+### `delivered_amount`フィールド
+
+Partial Paymentでの実際の送金額を把握できるように、正常に完了したPaymentトランザクションのメタデータには`delivered_amount`フィールドが含まれています。このフィールドには送金額が`Amount`フィールドと[同じフォーマット](../../references/protocol/data-types/basic-data-types.md#通貨額の指定)で示されています。
+
+Partial Payment以外の場合、トランザクションのメタデータの`delivered_amount`フィールドは、トランザクションの`Amount`フィールドと同じです。支払がトークンで行われた場合、丸め方により`delivered_amount`が`Amount`フィールドとやや異なることがあります。
+
+次の**両方**の条件に該当するトランザクションでは、送金額を**使用できません**。
+
+- Partial Paymentである
+- 2014-01-20以前の検証済みレジャーに含まれている
+
+この両方の条件に該当する場合、`delivered_amount`には実際の金額ではなく文字列値`unavailable`が示されます。この状況で実際の送金額を確認する唯一の方法は、トランザクションのメタデータでAffectedNodesを参照することです。トークンを送金するトランザクションで、`Amount`の`issuer`が`Destination`アドレスと同じアカウントである場合、送金額は異なる取引相手へのトラストラインを表す複数の`AffectedNodes`メンバー間で分割できます。
+
+`delivered_amount`フィールドは以下のフィールドに含まれています。
+
+| API | メソッド | フィールド |
+|-----|--------|-------|
+| [JSON-RPC / WebSocket][] | [account_txメソッド][] | `result.transactions` 配列メンバーの `meta.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [txメソッド][] | `result.meta.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [transaction_entryメソッド][] | `result.metadata.delivered_amount` |
+| [JSON-RPC / WebSocket][] | [ledgerメソッド][]（トランザクションが展開されている状態） | `result.ledger.transactions` 配列メンバーの`metaData.delivered_amount` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}新規: rippled 1.2.1{% /badge %} |
+| [WebSocket][] | [トランザクションサブスクリプション](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#トランザクションストリーム) | サブスクリプションメッセージの`meta.delivered_amount` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}新規: rippled 1.2.1{% /badge %} |
+| ripple-lib v1.x | `getTransaction` メソッド | `outcome.deliveredAmount` |
+| ripple-lib v1.x | `getTransactions` メソッド | 配列メンバーの `outcome.deliveredAmount` |
+
+[WebSocket]: ../../references/http-websocket-apis/index.md
+[JSON-RPC / WebSocket]: ../../references/http-websocket-apis/index.md
+
+## Partial Paymentの悪用
+
+金融機関によるXRP Ledgerとの統合が、Paymentの`Amount`フィールドは常に総送金額であると想定して行われる場合、不正使用者がその想定を悪用して、金融機関から資金を盗むことが可能になります。Partial Paymentがゲートウェイ、取引所、または業者のソフトウェアで正しく処理されない限り、これらの機関に対してこのような悪用が行われる可能性があります。
+
+**着信Paymentトランザクションを正しく処理するには、**`Amount`フィールドではなく **[`delivered_amount`メタデータフィールド](#delivered_amountフィールド)を使用します。** これにより、金融機関が _実際の_ 受取金額を間違えることがなくなります。
+
+
+### 悪用シナリオの流れ
+
+脆弱な金融機関を攻撃するため、不正使用者は次のような操作を試みます。
+
+1. 不正使用者がPaymentトランザクションを金融機関に送信します。このトランザクションの`Amount`フィールドの額は高額で、**tfPartialPayment**フラグが有効になっています。
+2. Partial Paymentは成功しますが（結果コード`tesSUCCESS`）、実際には指定通貨でわずかな金額だけが送金されます。
+3. 脆弱な金融機関はトランザクションの`Amount`フィールドを確認しますが、`Flags`フィールドや`delivered_amount`メタデータフィールドは確認しません。
+4. 脆弱な金融機関は、XRP Ledgerへ入金された`delivered_amount`が非常に少額のであるにもかかわらず、外部システム（金融機関独自のレジャーなど）で`Amount`の総額を不正使用者に入金します。
+5. 不正使用者は、脆弱な機関がこの差異に気付く前に、可能な限りの多くの残高を別のシステムに出金します。
+    - ブロックチェーントランザクションは通常不可逆であるため、不正使用者は一般的にBitcoinなどの他の仮想通貨に残高を換金することを好みます。法定通貨システムに出金した場合、金融機関がトランザクションを撤回または取り消せるのは、最初にトランザクションが実行されてから数日後になります。
+    - 取引所の場合、不正使用者はXRPから残高を出金し、直接XRP Ledgerに戻すこともできます。
+
+業者の場合、操作の順序がやや異なりますが、概念は同じです:
+
+1. 不正使用者が大量の商品やサービスの購入を依頼します。
+2. 脆弱な業者が不正使用者に対し、購入された商品やサービスの手数料を請求します。
+3. 不正使用者がPaymentトランザクションを業者に送信します。このトランザクションの`Amount`フィールドの額は高額で、**tfPartialPayment**フラグが有効になっています。
+4. Partial Paymentが成功しますが（結果コード`tesSUCCESS`）、指定通貨でわずかな金額だけが送金されます。
+5. 脆弱な業者はトランザクションの`Amount`フィールドを確認しますが、`Flags`フィールドや`delivered_amount`メタデータフィールドは確認しません。
+6. 脆弱な業者は、XRP Ledgerへの入金された`delivered_amount` が非常に少額であるにもかかわらず、請求を支払済みとして扱い、商品またはサービスを不正使用者に納入します。
+7. 不正使用者は、業者が差異に気付く前に、商品やサービスを使用、再販売または持ち逃げします。
+
+### その他の緩和対策
+
+このような悪用を防ぐには、着信トランザクションの処理で[`delivered_amount`フィールド](#delivered_amountフィールド)を使用すれば十分です。ただし、積極的な取り組みを追加することによっても、このような悪用が発生する可能性を回避または緩和できます。例:
+
+- 出金処理のビジネスロジックにサニティチェックを追加します。XRP Ledgerで保有している残高の合計が、予期されている資産と債務に一致しない場合は、出金を処理をしません。
+- 「顧客確認」のガイドラインに従い、顧客の身元情報を厳密に検証します。不正使用者を事前に認識して阻止したり、システムを悪用した不正使用者に対して法的措置を講じたりすることができます。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/payment-types/payment-channels.md
+++ b/@l10n/ja/docs/concepts/payment-types/payment-channels.md
@@ -0,0 +1,43 @@
+---
+html: payment-channels.html
+parent: payment-types.html
+seo:
+    description: Payment Channelは、少額の単位に分割可能な高速な非同期のXRPペイメントを送信し、後日決済されるようにします。
+labels:
+  - Payment Channel
+  - スマートコントラクト
+---
+# Payment Channel
+
+Payment Channelは、少額の単位に分割可能な「非同期」のXRPペイメントを送信し、後日決済する高度な機能です。
+
+Payment Channel向けのXRPは、指定された期間にわたって留保されます。送金元がチャネルに対する _クレーム_ を作成します。受取人は、XRP Ledgerトランザクションを送信したり、新しいレジャーバージョンが[コンセンサス](../consensus-protocol/index.md)に基づいて承認されるまで待つことなしに、このクレームを検証します。（これは、合意に基づいてトランザクションが承認される通常のパターンとは別に発生する、 _非同期_ のプロセスです。）受取人はいつでもクレームを _清算_ して、このクレームにより承認された額のXRPを受領することができます。このようなクレームを清算するときには、通常の合意プロセスの一部として標準XRP Ledgerトランザクションを使用します。この1回のトランザクションに、少額のクレームにより保証される任意の数のトランザクションを含めることができます。
+
+クレームは個別に検証され、後で一括で清算できるため、Payment Channelでは、クレームのデジタル署名を作成および検証する参加者の能力によってのみ制限されるペースで、トランザクションを行えます。この制限は主に、参加者のハードウェアのスピードと、署名アルゴリズムの複雑さによるものです。最大限の速度を引き出すにはEd25519署名を使用します。これはXRP Ledgerのデフォルトのsecp256k1 ECSDA 署名よりも高速です。研究の結果、2011年のコモディティーハードウェアで[1秒あたりEd25519署名を100,000個以上作成し、1秒あたり70,000個以上を検証できることが実証されました](https://ed25519.cr.yp.to/ed25519-20110926.pdf)。
+
+
+## Payment Channelを使用する理由
+
+Payment Channelを使用するプロセスには常に、支払人と受取人という2名の当事者が関わります。支払人とは、受取人の顧客で、XRP Ledgerを使用している個人または機関です。受取人とは、商品またはサービスの代金としてXRPを受領する個人または事業者です。
+
+Payment Channelでは本来、そこで売買可能なものにいては、一切指定されません。ただし、次の商品やサービスはPayment Channelに適しています。
+
+- デジタルアイテムなど、ほぼ即時に送信できるもの
+- 安価な商品（価格に占めるトランザクション処理コストの割合が大きい）
+- 通常大量購入する商品（正確な希望数量が事前に判明していない）
+
+
+## Payment Channelのライフサイクル
+
+次の図は、Payment Channelのライフサイクルの概要を示します。
+
+[{% inline-svg file="/docs/img/paychan-flow.ja.svg" /%}](/docs/img/paychan-flow.ja.svg "Payment Channelフローチャート")
+
+
+## 関連項目
+
+- [Payment Channelの使用](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md): Payment Channelを使用するプロセスを段階的に説明するチュートリアル。
+
+- [Escrow](escrow.md): 速度が遅い、条件付きの大量XRP決済のための類似機能。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/payment-types/robustly-monitoring-for-payments.md
+++ b/@l10n/ja/docs/concepts/payment-types/robustly-monitoring-for-payments.md
@@ -0,0 +1,27 @@
+---
+html: robustly-monitoring-for-payments.html
+parent: payment-types.html
+seo:
+    description: 不正な入金がないかを監視するための推奨事項を説明します。
+labels:
+  - トークン
+---
+# 入金のモニタリング
+
+入金チェックを確実に行うために、発行者は以下のことを行う必要があります。
+
+* 直近に処理したトランザクションとレジャーを記録しておく。そうすれば、一時的に接続ができなくなったとしても、どこまで遡ればいいのか分かります。
+* 受信したすべての支払いの結果コードを確認する。一部の支払いは、失敗したにもかかわらず、スパム対策料金を請求するためにレジャーに登録されます。結果コード`tesSUCCESS`を持つトランザクションだけが、XRP以外の残高を変更できます。また、検証されたレジャーからのトランザクションのみが確定的なものとなります。
+* [部分支払い](partial-payments.md)に注意してください。partial paymentフラグを有効にした場合、0以上の金額であれば、少額でも「成功」と判断されることがあります。
+    * トランザクションに[`delivered_amount`フィールド](partial-payments.md#the-delivered_amount-field)があるかどうか確認してください。もし存在すれば、そのフィールドは`Destination`アドレスに実際にどれだけの金額が支払われたかを示しています。
+    * xrpl.jsでは、[`xrpl.getBalanceChanges()`メソッド](https://js.xrpl.org/modules.html#getBalanceChanges)を使って、各アドレスがいくら受け取ったかを見ることができます。場合によっては、これを異なるトラストラインで複数回に分けて表示することも可能です
+* トランザクションの中には、アドレスの1つへの直接の支払いやアドレスからの支払いでなくても、残高を変更するものがあります。
+
+顧客の利便性を高めるため、運用アドレスと発行アドレスの両方への支払いを受け付けることをお勧めします。
+
+追加の防止策として、新しいXRP Ledgerの各レジャーバージョンにおいて、発行アドレスの残高と内部会計システムにおける担保資金を比較することをお勧めします。発行アドレスのマイナス残高は、ネットワーク外のXRP Ledgerに割り当てた資産と一致するはずです。もし両者が一致しないのであれば、その不一致を解決するまでXRP Ledgerへの出入りの支払い処理を中断する必要があります。
+
+* 残高を確認するには、`gateway_balances`メソッドを使用します。
+* Transfer Feeが設定されている場合、他のXRP Ledgerアドレスがあなたのトークンを転送するたびに、XRP Ledger内でのあなたの負債はわずかに減少します。
+
+受信したトランザクションの詳細を確認する方法については、[トランザクションの結果の確認](../transactions/finality-of-results/look-up-transaction-results.md)をご覧ください。
--- a/@l10n/ja/docs/concepts/payment-types/sending-payments-to-customers.md
+++ b/@l10n/ja/docs/concepts/payment-types/sending-payments-to-customers.md
@@ -0,0 +1,24 @@
+---
+html: sending-payments-to-customers.html
+parent: payment-types.html
+seo:
+    description: Construct payments carefully to thwart malicious actors.
+labels:
+  - トークン
+---
+# 顧客への送金
+
+顧客のためにXRP Ledgerに支払いを送信する自動化システムを構築する際には、支払いが確実に行われるように注意する必要があります。悪意のある行為者は常に、システムを騙して必要以上の金額を支払わせる方法を見つけようとしています。
+
+一般的に、ステーブルコインを送る場合は[Paymentトランザクション][]を使用します。初めてトークンを発行するのか、ホットウォレットから顧客へ送金するのかによって、細かい点が異なる部分もあります。注意すべき点は以下の通りです。
+
+- トークンの発行元(`issuer`フィールド)には、必ず発行アドレスを指定してください。そうしないと、他のアドレスが発行した同じ通貨を配信するパスを誤って使用してしまう可能性があります。
+- XRP Ledgerに支払いを送信する前に、支払いのコストを再確認してください。あなたの運用アドレスから顧客への支払いは、着金金額とあなたが設定した送金手数料よりも高くなるべきではありません。
+- 発行アドレスから新しいトークンを発行する場合、`SendMax`フィールドを省略する必要があります。そうしないと、悪意のあるユーザは、意図した宛先の`Amount`だけでなく、`SendMax`の全量を発行するように設定を変更することができます。
+- ホットウォレットからトークンを送信する場合、送金手数料がゼロでない場合は`SendMax`を指定する必要があります。この場合、`SendMax`フィールドに`Amount`フィールドで指定した金額と送金手数料を設定します。(計算の精度がXRP Ledgerと正確に一致しない場合に備えて、少し切り上げるとよいでしょう)。例えば、`Amount`フィールドに99.47USDが指定され、送金手数料が0.25%のトランザクションを送信する場合、`SendMax`フィールドを124.3375、または切り上げる場合は124.34USDに設定すべきです。
+- `Paths`フィールドを省略します。このフィールドは、発行元から直接送信する場合や、送信するトークンと受信するトークンの通貨コードと発行元が同じである限り、つまり同じステーブルコインである限り、ホットウォレットから設定する必要はありません。`Paths`フィールドは[クロスカレンシー支払い](cross-currency-payments.md)やより長いマルチホップ(rippling)支払いを対象としています。単純に経路探索を行い、トランザクションにパスを設定すると、直接の経路が利用できない場合、支払いは失敗するのではなく、より高価な遠回りのパスを取るかもしれません。悪意のあるユーザはこれを利用して利益を得る可能性があります。
+- `tecPATH_DRY`の結果コードが表示された場合、通常、必要なトラストラインを顧客がまだ設定していないか、発行者のripplingが正しく設定されていないことを意味します
+
+XRP Ledger上でステーブルコインやその他のトークンを発行するための詳しいチュートリアルは、[代替可能トークンの発行](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md)をご覧ください。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/decentralized-exchange/autobridging.md
+++ b/@l10n/ja/docs/concepts/tokens/decentralized-exchange/autobridging.md
@@ -0,0 +1,29 @@
+---
+html: autobridging.html
+parent: decentralized-exchange.html
+seo:
+    description: オートブリッジングは、コストが下がる場合はXRPを仲介として使用してオーダーブックを自動的に接続します。
+labels:
+  - XRP
+  - 分散型取引所
+---
+# オートブリッジング
+
+XRP Ledgerの[分散型取引所](index.md)で、XRP以外の2種類の通貨を交換する[オファー](offers.md)があった場合、合成されたオーダーブックで[XRP](../../../introduction/what-is-xrp.md)が中間通貨として使用されることがあります。これは _オートブリッジング_ によるものです。この機能は、通貨を直接交換するよりも安く済む場合にXRPを使用し、あらゆる通貨ペアの流動性を向上させる役割を担います。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
+
+例: _AnitaはGBPを売却してBRLを購入するオファーを発行しました。このような一般的ではない通貨マーケットでは、オファーがあまりない場合があります。良いレートのオファーが1件ありますが、Anitaの取引を満たすのに十分な量ではありません。ただしGBPとXRPおよびBRLとXRPの間には、それぞれアクティブで競争力のあるマーケットが存在します。XRP Ledgerのオートブリッジングシステムは、あるトレーダーからXRPをGBPで購入し、そのXRPを別のトレーダーに支払ってBRLを購入することで、Anitaのオファーを履行できる方法を見つけます。AnitaはGBPとBRLを直接交換するマーケットでの少額オファーを、GBP対XRPのオファーとXRP対BRLのオファーをペアリングしてより良い複合レートと組み合わせて、最適なレートを自動的に得ることができます。_
+
+オートブリッジングは、あらゆる[OfferCreateトランザクション][]で自動的に行われます。[Paymentトランザクション](../../../references/protocol/transactions/types/payment.md)ではオートブリッジングはデフォルトでは _行われません_ が、path-findingにより同様の効果のある[パス](../fungible-tokens/paths.md)を検索できます。
+
+[![オートブリッジングによる直接注文と合成注文の組み合わせを示す図](/docs/img/autobridging.png)](/docs/img/autobridging.png)
+
+
+## 関連項目
+
+- [開発者ブログ: オートブリッジング](https://xrpl.org/blog/2014/introducing-offer-autobridging.html)
+
+- [オファーの優先度](offers.md#オファーの優先度)
+
+- [ペイメントパス](../fungible-tokens/paths.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
+++ b/@l10n/ja/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
@@ -0,0 +1,136 @@
+---
+seo:
+    description: 自動マーケットメーカー（AMM）は、資産ペア間の流動性を提供し、分散型取引所のオーダーブックを補完すると同時に、流動性提供者に利益を提供します。
+labels:
+  - XRP
+  - 分散型取引所
+  - AMM
+---
+# 自動マーケットメーカー(AMM)とは?
+
+_([AMM amendment][]により追加されました。)_
+
+自動マーケットメーカー(AMM)は、XRP Ledgerの分散型取引所において流動性を提供します。個々のAMMは2つの資産のプールを保有します。ユーザは数式で定められた取引レートによりその2つの資産間でスワップが可能です。
+
+![自動マーケットメーカー](/docs/img/cpt-amm.png)
+
+資産をAMMに預ける人は、_流動性供給者(LP/Liquidity Provider)_ と呼ばれます。その対価として流動性供給者はAMMからLPトークンを受け取ります。
+
+![流動性提供者によるLPトークンの受け取り](/docs/img/cpt-amm-lp-receiving-lpts.png)
+
+流動性供給者はLPトークンを利用して以下のことが可能になります。
+
+- LPトークンを、AMMのプール内の資産の一部（プールが得た手数料を含む）と交換する。
+- AMMの手数料設定を変更するために投票する。票は、投票者が保有するLPトークンの数に基づいて重み付けされます。
+- AMMの取引手数料の一時的な割引を得るために、LPトークンの一部を入札する。
+
+## AMMの仕組み
+
+AMMは2つの異なる資産を保有します。そのうちの最大1つはXRPとすることができ、そのうちの1つまたは両方が[トークン](../index.md)であることができます。
+任意の資産ペアに対して、レジャーには最大1つのAMMが存在することができます。存在しない場合、誰でもその資産ペアのAMMを作成することができます。また、すでに存在している場合、AMMに預け入れることができます。
+
+分散型取引所で取引を行う場合、[オファー](offers.md)と[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)は、自動的にAMMを使用して取引を成立させることができます。単一の取引は、オファー、AMM、またはその両方の組み合わせによって、よりコストが低い方法で実行されることになります。
+
+![オファーやAMMまたはその両方を利用する1つの取引](/docs/img/cpt-amm-or-offer.png)
+
+{% admonition type="info" name="注記" %}
+
+`Payment`または`OfferCreate`トランザクションがAMMとやり取りしたかどうかは、トランザクションメタデータにある[`RippleState`](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)レジャーエントリを確認することで判断できます。`Flags`値が`16777216`の場合、AMMの流動性が消費されたことを示します。
+
+{% /admonition %}
+
+AMMは、プール内の資産残高に基づき取引レートを設定します。AMMに対して取引を行うと、AMMが保有する資産残高の変動に応じて、取引レートが調整されます。一方の資産の量が減れば、その資産の価格が上がり、他方の資産の量が増えれば、その資産の価格が下がります。
+
+![資産残高が増えると価格が下がり、資産残高が減ると価格が上がる](/docs/img/cpt-amm-balance.png)
+
+AMMは、プール内の資産残高が多いほど、一般的により良い取引レートを提供します。同一取引であればプール内の残高が大きい方がAMMの資産バランスに生じる変化は小さくなるからです。AMMの2つの資産のバランスが崩れれば崩れるほど、交換レートは極端に悪化します。
+
+また、AMMは交換レートに加え、一定割合の取引手数料を徴収しています。
+
+XRP Ledgerの実装は、重みパラメータを0.5とした _幾何平均_ AMMですので、_定積_ マーケットメーカーのように機能します。 _定積_ AMMの公式や一般的なAMMの経済学についての詳しい説明は、[Kris Machowski's Introduction to Automated Market Makers](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/)をご覧ください。
+
+### トークン発行者
+
+発行者が異なるトークンは異なる資産と見なされます。つまり、同じ通貨コードで異なる発行者の2つのトークンに対してAMMを作成することができます。例えば、WayGateによって発行された _FOO_ は、StableFooによって発行された _FOO_ とは異なるトークンです。同様に、トークンは同じ発行者で異なる通貨コードを持つことができます。取引方向は関係ありません。FOO.WayGateからXRPへのAMMは、XRPからFOO.WayGateへのAMMと同じです。
+
+### 資産の制限
+
+資産間の資金の流れが比較的活発でバランスが取れている場合、手数料は流動性供給者に対する受動的な収入源となります。しかし、資産間の相対価格が変動すると、流動性供給者は[通貨リスク](https://www.investopedia.com/terms/c/currencyrisk.asp)による損失を被ることになります。
+
+### 資産の制限 <a id="restrictions-on-assets"></a>
+
+不正利用を防ぐため、AMMで利用できる資産にはいくつかの制限があります。これらの制約を満たさない資産でAMMを作成しようとすると、トランザクションは失敗します。ルールは以下のとおりです。
+
+- 他のAMMのLPTokenをAMMの資産として利用することはできません。
+- 資産が、発行者が[認可トラストライン](../fungible-tokens/authorized-trust-lines.md)を使用しているトークンである場合、AMMの作成者はそれらのトークンを保有する権限がなければなりません。認可されているトラストラインだけが、そのトークンをAMMに預けたり引き出したりすることができます。
+- [Clawback Amendment][] が有効な場合、Clawbackが有効なトークンでAMMを作成することはできません。
+
+## LPトークン
+
+AMMの作成者は、最初の流動性供給者となり、AMMのプール内の資産の100％の所有権を表すLPトークンを受け取ります。LPトークンの一部または全部を交換して、現在のプール残高に比例した資産をAMMから引き出せます。(この比率は、人々がAMMに対して取引を行うにつれて変化します）AMMは、同時に両方の資産を引き出す際に手数料はかかりません。
+
+例えば、5ETHと5USDでAMMを作成し、その後誰かが1.26USDを1ETHに交換したとすると、現在プールには4ETHと6.26USDが入っています。LPトークンの半分を使用して、2ETHと3.13USDを引き出すことができます。
+
+![AMMとの取引とLPトークンの引き出しの例](/docs/img/cpt-amm-lp-tokens.png)
+
+誰でも既存のAMMに資産を預けることができます。預け入れると、その金額に応じて新しいLPトークンを受け取ります。流動性供給者がAMMから引き出すことができる金額は、発行済みのLPトークンの総数に対する流動性提供者のLPトークンの保有割合に基づきます。
+
+LPトークンはXRP Ledgerの他のトークンと同様に、様々な種類の支払いで使用したり、分散型取引所で取引したり、新しいAMMの資産として預けることも可能です。(LPトークンを支払い(Payment)として受け取るには、AMMアカウントを発行元として、限度額が0でない[トラストライン](../fungible-tokens/index.md)を設定する必要があります)。ただし、LPトークンをAMMに直接送る(換金する)には[AMMWithdraw][]トランザクションタイプを使用し、他のタイプの支払いは使用できません。同様に、AMMのプールに資産を送るには、[AMMDeposit][]トランザクションタイプを使用する必要があります。
+
+AMMは、発行済のLPトークンがない場合に限り、AMMの資産プールが空になるように設計されています。こうした状況は、[AMMWithdraw][]トランザクションの結果としてのみ発生し、発生した時点でAMMは自動的に削除されます。
+
+### LPトークンの通貨コード
+
+LPトークンは、160ビットの16進法["非標準"フォーマット](../../../references/protocol/data-types/currency-formats.md#非標準通貨コード)の特別なタイプの通貨コードを使用します。これらのコードの最初の8ビットは`0x03`です。残りのコードは、2つの資産の通貨コードとその発行者のSHA-512ハッシュで、最初の152ビットまで切り捨てたものです。(資産は、数値の低い通貨と発行者のペアを最初にする「正規化された順序」で配置されます。)その結果、LPトークンは、通貨と発行者のペアを最初にする「正規化された順序」で配置されます。その結果、ある資産ペアのAMMのLPトークンは、予測可能で一貫した通貨コードを持っています。
+
+
+## 取引手数料
+
+取引手数料は流動性供給者の収益源であり、プールの資産に対して他者に取引をさせることによる為替リスクを相殺するものであり、取引手数料は流動性提供者に直接支払われずにAMMに支払われます。流動性供給者は自分のLPトークンをAMMのプールの一定割合と交換することができるため、利益を得ることができます。
+
+流動性供給者は、投票によって取引手数料を0％から1％まで、0.001％刻みで設定することが出来ます。流動性供給者は取引手数料を適切に設定するインセンティブがあり、手数料が高すぎる場合、トレーダーはより良いレートを得るために代わりにオーダーブックを使用することになります。手数料が低すぎる場合、流動性供給者はこのプールへの貢献に対してメリットが得られなくなります。
+
+AMMは、流動性プロバイダに対して、保有するLPトークンの数に応じて、手数料に関する投票権を与えます。投票するには、流動性供給者が[AMMVote][]トランザクションを送信します。誰かが新しい票を入れるたびに、AMMは手数料を再計算し、直近の票の平均を、それらの投票者が保有するLPトークンの数で重み付けしたものにします。この方法では、最大8つの流動性供給者の投票がカウントされます。それ以上の流動性供給者が投票しようとすると、上位8つの投票（保有LPトークンの多い順）だけがカウントされます。流動性供給者のLPトークンのシェアは、様々な理由(例えば[オファー](offers.md)を使ったトークンの取引)で急速に変化しますが、取引手数料は誰かが新しい票を入れるたびに再計算されます（その票がトップ8に入っていない場合でも計算されます)。
+
+### オークションスロット
+
+XRP LedgerのAMMの設計には「オークションスロット」が含まれています。流動性プロバイダはLPトークンを落札に利用してオークションスロットを獲得し、24時間取引手数料の割引を受けることができます。落札に利用されたLPトークンはAMMに回収されます。
+
+AMMの資産価格が外部市場で大きく変動すると、トレーダーはAMMから利益を得るために裁定取引を行うことができます。これは流動性プロバイダに損失をもたらします。オークションメカニズムは、その価値の一部を流動性プロバイダに返し、AMMの価格をより迅速に外部市場とバランスを取ることを意図しています。
+
+一度に複数のアカウントがオークションスロットを保持することはできませんが、落札者は割引を受けるために追加で最大4つのアカウントを指定することができます。スロットが現在使用中の場合、現在のスロット保持者を追い出すために落札する必要があります。追い出された場合、残り時間に応じて一部の落札金額が返却されます。アクティブなオークションスロットを保持している間は、そのAMMに対して取引を行う際に、通常の取引手数料の1/10（10分の1）の割引が適用されます。
+
+オークションスロットの最小入札額は、空または期限切れの場合、現在のLPトークンの総数に取引手数料を掛けたものを25で割ったものです。(擬似コードで表すと、`MinBid = LPTokens * TradingFee / 25`です。) オークションスロットが占有されている場合、現在のスロット保持者が支払った金額の105%までの最小入札額を支払う必要があります。
+
+
+## 台帳上の表示
+
+台帳の状態データでは、AMMは複数の[レジャーエントリのタイプ](../../../references/protocol/ledger-data/ledger-entry-types/index.md)で構成されています。
+
+- 自動マーケットメーカー自体を記述した[AMMエントリ][]
+
+- AMMのLPトークンを発行し、AMMのXRP（保有している場合）を保有する特別な[AccountRootエントリ][]
+
+    このAccountRootのアドレスは、AMMの作成時にランダムに選ばれ、AMMを削除して再作成した場合にも異なるアドレスが選ばれます。これは、AMMのアカウントにユーザが事前にXRPで資金を供給することを防止するためです。
+
+- AMMのプールにあるトークンのAMM専用アカウントへの[トラストライン](../fungible-tokens/index.md)
+
+これらのレジャーエントリはどのアカウントにも所有されていないため、[準備金要件](../../accounts/reserves.md)は適用されません。ただし、スパムを防ぐため、AMMを作成するための取引には特別な[トランザクションコスト](../../transactions/transaction-cost.md)があり、通常よりも多くのXRPを消費する必要があります。
+
+
+## 削除
+
+AMMは、[AMMWithdrawトランザクション][]がそのプールから全てのアセットを引き出すと削除されます。これは、AMMのすべての発行済みLPトークンを償還することによってのみ発生します。AMMの削除には、以下のようなAMMに関連するすべてのレジャーエントリの削除も含まれます。
+
+- AMM
+- AccountRoot
+- AMMのLPトークンのトラストライン。これらのトラストラインは残高が0ですが、限度額など他の詳細がデフォルト以外の値に設定されている可能性があります。
+- AMMのプールに存在するトークンのトラストライン。
+
+AMMアカウントが削除されるときに、512を超えるトラストラインが設定されていた場合、出金は成功し、可能な限り多くのトラストラインを削除します。
+
+AMMのプールに資産がない間は、誰でも[AMMDeleteトランザクション][]を送信してAMMを削除することができます。別の方法として、誰でも[特別な入金](../../../references/protocol/transactions/types/ammdeposit.md#空のammの場合の特殊なケース)を行うことで、AMMにあたかも新規であるかのように入金することができます。資産プールが空のAMMに対しては、他の操作は無効です。
+
+空のAMMを削除することによる払い戻しやインセンティブはありません。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/decentralized-exchange/index.md
+++ b/@l10n/ja/docs/concepts/tokens/decentralized-exchange/index.md
@@ -0,0 +1,72 @@
+---
+html: decentralized-exchange.html
+parent: tokens.html
+metadata:
+  indexPage: true
+seo:
+    description: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザはトークンをXRPに、あるいはXRPをトークンにに交換できます。
+---
+# 分散型取引所
+
+XRP Ledgerには、世界でおそらく最も古い _分散型取引所_ (「DEX」と略されることもあります)があり、2012年のXRP Ledgerのローンチ以来、現在まで稼働し続けています。この取引所では、ユーザが[トークン](../index.md)をXRPや他のトークンと売買することができ、ネットワーク自体に課される[手数料](../../transactions/fees.md)はごく僅かです。(いかなる当事者にも支払われることはありません)
+
+{% admonition type="warning" name="注意" %}誰でも好きな通貨コードやティッカーシンボルで[トークンを発行](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md)して、分散型取引所で販売することができます。トークンを購入する前に必ずデューデリジェンスを行い、発行者に注意を払うようにしてください。さもなければ、価値あるものを手放し、それと引き換えに価値のないトークンを受け取ることになるかもしれません。{% /admonition %}
+
+## 構造
+
+XRP Ledgerの分散型取引所は、無制限の通貨ペアで構成されており、ユーザが取引を行う際にオンデマンドで追跡されます。通貨ペアは、XRPとトークン、または2つの異なるトークンから構成されます。トークンは常に、発行者と通貨コードの組み合わせによって識別されます。同じ通貨コードで異なる発行者のトークン同士、または同じ発行者で異なる通貨コードのトークン同士の取引も可能です。
+
+XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](../../transactions/index.md)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.md)と呼ばれています。オファーは事実上、ある通貨(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オブジェクトとなります。その後、他のオファーや[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)がオファーにマッチし、約定する可能性があります。このため、Offerは最初に注文したときは指定した取引レートよりも高いレートで約定し、後で注文したときは指定した取引レートと全く同じレートで約定することがあります。（端数処理のためのわずかな差は除きます）
+
+オファーは、発注後、手動または自動でキャンセルすることができます。この機能およびその他の機能については、[オファー](offers.md)をご覧ください。
+
+2つのトークンを取引する際、トークンとトークンを直接取引するよりも、トークンとXRP、XRPとトークンを取引した方が安くなる場合、[オートブリッジ](autobridging.md)によって自動的に取引レートと流動性を向上させることができます。
+
+### 取引の例
+
+[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.ja.svg" /%}](/docs/img/decentralized-exchange-example-trade.ja.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の[トラストライン](../fungible-tokens/index.md)に送られます。(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がキャンセルするまで、その一部または全額を約定することができます。
+
+{% admonition type="info" name="注記" %}元帳がクローズされ、検証される際の取引の実行順序は、取引が送信された順序と同じではありません。複数のトランザクションが同じ台帳の同じオーダーブックに影響を与える場合、それらのトランザクションの最終結果は、トランザクション送信時に計算された暫定的な結果とは大きく異なる可能性があります。取引結果が確定する場合、確定しない場合の詳細については、[結果のファイナリティー](../../transactions/finality-of-results/index.md)をご覧ください。{% /admonition %}
+
+
+## 制限事項
+
+分散型取引所は、以下のような制限を設けて設計されています。
+
+取引は新しい台帳がクローズするたびに（約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/index.md)の背後にいる実際の人々や組織に関する情報を一切持っていません。また、ユーザや発行者は、様々な種類の裏付け資産を表すトークンの取引を規制するために、関連する法律に従う必要があります。[凍結](../fungible-tokens/freezes.md)や[認可トラストライン](../fungible-tokens/authorized-trust-lines.md)などの機能は、発行者が関連法規を順守できるよう意図しています。
+
+## 関連項目
+
+- **コンセプト:**
+    - [Offers](offers.md): XRP Ledgerでのトレードの仕組みについて
+    - [トークン](../index.md): XRP Ledgerで様々な種類の価値を表現する方法の概要について
+- **リファレンス:**
+    - [account_offersメソッド][]: アカウントから注文されたオファーを検索
+    - [book_offersメソッド][]: 指定された通貨ペアの売買のオファーを検索
+    - [OfferCreateトランザクション][]: 新規オファーを発注や既存のオファーの置き換え
+    - [OfferCancelトランザクション][]: 既存のオファーをキャンセル
+    - [Offerオブジェクト][] 台帳のオファーのデータ構造
+    - [DirectoryNodeオブジェクト][]: 特定の通貨ペアと取引レートのすべてのオファーを追跡するデータ構造
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
+
+
+{% child-pages /%}
--- a/@l10n/ja/docs/concepts/tokens/decentralized-exchange/offers.md
+++ b/@l10n/ja/docs/concepts/tokens/decentralized-exchange/offers.md
@@ -0,0 +1,109 @@
+---
+html: offers.html
+parent: decentralized-exchange.html
+seo:
+    description: オファーはXRP Ledgerの通貨取引に関する機能の一つです。オファーのライフサイクルと特性について説明します。
+labels:
+  - 分散型取引所
+---
+# オファー
+
+XRP Ledgerの[分散型取引所](index.md)では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと[トークン](../index.md)の取引、またはトークン間の取引（同一通貨コードだが発行者が異なるトークンを含む）を行うことができます。（同一通貨コードで発行者が異なる通貨は、[rippling](../fungible-tokens/rippling.md)によって取引することもできます。）
+
+- オファーを作成するには、[OfferCreateトランザクション][]を送信します。
+- 即時に約定されないオファーはレジャーデータの[Offerオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは約定されます。
+- [クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)はオファーを約定して流動性を提供します。
+
+
+## オファーのライフサイクル
+
+[OfferCreate トランザクション][]は、2つのトークン、またはトークンとXRPの間で取引を行なうための命令です。それぞれのトランザクションは購入額（`TakerPays`）と売却額（`TakerGets`）を含みます。トランザクションが処理されると、自動的に約定またはクロスするオファーが可能な限り約定されます。その結果、新しいオファーを完全に約定しきれない場合、残りは台帳上のOfferオブジェクトとなります。
+
+Offerオブジェクトは、他のオファーやクロスカレンシー決済で完全に約定されるまで、台帳に保存されます。オファーを作成したアカウントは、そのオファーの所有者と呼ばれます。自分が作成したオファーは、専用の[OfferCancelトランザクション][]、または[OfferCreateトランザクション][]のオプションとして、いつでもキャンセルすることが可能です。
+
+台帳にOfferオブジェクトがある間は、あなたのXRPの一部が[所有者準備金](../../accounts/reserves.md)として設定されます。何らかの理由でOfferオブジェクトが削除されると、そのXRPは再び使えるようになります。
+
+### 必要となる資金
+
+オファーを作成する際、その取引で売却する資産の一部でも保有していない場合、取引は「資金不足」として拒否されます。
+
+具体的には
+
+**トークンを売却する** には、以下のいずれかが必要です。
+
+- そのトークンの任意の正の量を保持する、_または_
+- そのトークンの発行者になる。
+
+ただし、オファーで指定された全額を保有する必要はありません。オファーを作成することで資金が拘束されるわけではないので、同じトークン（またはXRP）を売却するために複数のオファーを作成したり、オファーを作成した後で十分なトークンまたはXRPを調達することも可能です。
+
+**XRPを売却する** には、Offerオブジェクトを台帳に保存するための準備金と、購入するトークンを保存するためのトラストラインの準備金を含む、必要な[準備金](../../accounts/reserves.md)を確保する必要があります。準備金を確保した後にXRPが残っていれば、Offerオブジェクトを作成することができます。
+
+他のオファーと自身のオファーがマッチした場合、両方のオファーが、その時点における所有者の資金の範囲内で実行されます。マッチングしたオファーがあり、自分のオファーが完全に約定される前に資金が尽きてしまった場合、残りのオファーはキャンセルされます。トークンの発行者でない限り、オファーによってトークンの残高がマイナスになることはありません。(発行者であれば、オファーを使って、オファーで指定された合計金額まで新しいトークンを発行できます。発行したトークンは、発行者の立場からはマイナス残高として表示されます)。
+
+台帳に存在する自身のオファーと重なるオファーを作成した場合、金額にかかわらず、重なった古いオファーは自動的にキャンセルされます。
+
+次のような場合には、オファーが一時的または長期に渡って「資金不足」になる可能性があります。
+
+- 所有者が売却する資産を一切保有しなくなった場合。
+    - オーナーがその資産を再度取得すると、オファーに資金が供給されるようになります。
+- 売却する資産が[凍結されたトラストライン](../fungible-tokens/freezes.md)に含まれるトークンである場合。
+    - トラストラインが凍結解除されると、オファーは再び資金が供給されるようになります。
+- オファーが新しいトラストラインを作成する必要があるが、オーナーがその[準備金](../../accounts/reserves.md)の増加に伴う十分なXRPを持っていない場合。
+    - オーナーが追加のXRPを調達するか、準備金の必要量が減少すると、オファーは自動的に使用可能になります。
+- オファーが失効した場合。([オファーの有効期限](#オファーの有効期限)を参照)
+
+資金不足のOfferオブジェクトは、トランザクションによって削除されるまで、台帳に残ります。台帳からOfferオブジェクトを削除するには、以下の方法があります。
+
+
+- 約定するオファーまたは[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)によってオファーが全額約定される。
+- 所有者が明示的にオファーをキャンセルする。
+- 所有者が交差する新しいオファーを作成することにより、暗黙のうちにオファーをキャンセルする。
+- トランザクション処理中にオファーが資金不足または期限切れであることが判明する。
+    - これには、オファーが支払うことができる残額がゼロになる場合も含まれます。
+
+### 資金不足のオファーの追跡
+
+すべてのオファーの資金状況の追跡は、コンピュータにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金状況に影響することがあります。このため、XRP Ledgerでは資金不足や期限切れのオファーの検出と削除を _積極的には_ 行なっていません。
+
+クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初に[book_offersメソッド][]を使用してオーダーブックを取得し、次にオファーの`taker_gets_funded`フィールドを調べます。次に`transactions`ストリームを[サブスクライブ](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md)し、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。
+
+
+## オファーとトラスト
+
+トラストラインの限度額（[TrustSet](../../../references/protocol/transactions/types/trustset.md)を参照）はオファーに影響しません。つまり、オファーを使用して、発行者に対して設定したトラストラインの限度額を上回る額を取得できます。
+
+ただし、トークンを保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが約定されると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。[アカウントが保有する必要のある準備金はトラストラインによって増加する](../../accounts/reserves.md)ため、新しいトラストラインを必要とするオファーがある場合、アカウントはそのトラストラインの準備金として十分なXRPを保有している必要があります。
+
+トラストラインの制限は、あなたの希望以上のトークンを受け取ることを防ぐためのものです。オファーとは、トークンをどれだけ欲しいかを明示的に示すものであるため、この制限を超えることができます。
+
+
+## オファーの優先度
+
+台帳内のOfferオブジェクトは取引レートによってグループにまとめられます。取引レートは、`TakerGets`と`TakerPays`の比率として計算されます。取引レートが高いOfferオブジェクトが優先的に処理されます。（つまり、オファーを約定する人は、支払われる通貨額に対して可能な限り多くの額を受領します。）同じ取引レートのオファーは、オファーの作成タイミングを基準にして処理されます。
+
+同じ取引レートのOfferオブジェクトが同じ台帳ブロックに記録されている場合、オファーの処理順序は[レジャーへトランザクションを適用する](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source Code: Applying transactions")ための[正規順序](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source Code: Transaction ordering")によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。
+
+
+## オファーの有効期限
+
+オファーを設定する際、オプションで有効期限を追加することができます。デフォルトでは、オファーに有効期限はありません。すでに有効期限切れのオファーを新たに作成することはできません。
+
+有効期限は秒単位で指定できますが、オファーが期限切れとなる時刻は、実際には正確ではありません。オファーが期限切れとなるのは、期限切れ時刻が直前の台帳のクローズ時刻より前か等しい場合です。それ以外の場合は、現実の時刻がオファー期限よりも後でも、オファーが約定する可能性があります。言い換えると、有効期限が最新の有効な台帳のクローズ時刻よりも遅ければ、実際の時計がどうであろうと、オファーはまだ「有効」なのです。
+
+これは、ネットワークのコンセンサス形成の仕組みによるものです。ピアツーピアネットワーク全体が合意に達するには、トランザクションを実行する際に、すべてのサーバがどのオファーが期限切れであるかに合意する必要があります。個々のサーバはシステム時刻の設定にわずかな違いがあるため、各サーバが「現在」時刻を使用した場合、どのオファーが期限切れであるかについて同じ結論に達しない可能性があります。台帳のクローズ時刻は、その台帳のトランザクションが実行されるまで分からないため、サーバは「前の台帳」の正式なクローズ時刻を代わりに使用します。[台帳のクローズ時刻は丸められます](../../ledgers/ledger-close-times.md)。このため、オファーが期限切れかどうかを判断するための時刻と実世界の時刻の差が生じる場合があるのです。
+
+{% admonition type="info" name="注記" %}期限切れのOfferオブジェクトは、トランザクションによって削除されるまで、台帳内に残ります。それまでは、APIから取得したデータ（[ledger_entryメソッド][]などを使用）に表示され続ける可能性があります。トランザクションは、有効期限が切れたOfferオブジェクトや資金不足のOfferオブジェクトを見つけると自動的に削除します。通常、オファーやクロスカレンシー決済を実行すると、そのOfferオブジェクトはマッチングまたはキャンセルされます。Offerオブジェクトに対応する所有者準備金は、Offerオブジェクトが実際に削除されたときにのみ再び利用可能になります。{% /admonition %}
+
+## 関連項目
+
+- **コンセプト:**
+    - [トークン](../index.md)
+    - [パス](../fungible-tokens/paths.md)
+- **リファレンス:**
+    - [account_offersメソッド][]
+    - [book_offersメソッド][]
+    - [OfferCreateトランザクション][]
+    - [OfferCancelトランザクション][]
+    - [Offerオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/decentralized-exchange/ticksize.md
+++ b/@l10n/ja/docs/concepts/tokens/decentralized-exchange/ticksize.md
@@ -0,0 +1,28 @@
+---
+html: ticksize.html
+parent: decentralized-exchange.html
+seo:
+    description: 発行者は、為替レートのごくわずかな差を超えて、頻繁な取引を抑制するためにオーダーブックで通貨のカスタムチックサイズを設定することができます。
+labels:
+  - 分散型取引所
+  - トークン
+---
+# ティックサイズ
+
+_（[TickSize Amendment][]により追加されました。）_
+
+オファーがオーダーブックに対して発行されると、そのオファーに関係する通貨の発行者によって設定された`TickSize`の値に基づいて、為替レートが切り捨てられます。トレーダーがXRPとトークンを交換するオファーを出した場合は、そのトークンの発行者からの`TickSize`が適用されます。トレーダーが2種類のトークンを交換するオファーを出した場合は、小さい方の`TickSize`の値（有効数字の桁数が少ない値）がこのオファーに適用されます。いずれの通貨にも`TickSize`が設定されていない場合、デフォルトが適用されます。
+
+オーダーブックにオファーが発行されると、`TickSize` によりオファーの為替レートの _有効数字_ の桁数が切り捨てられます。発行者は[AccountSetトランザクション][]を使用して`TickSize`を`3`～`15`の整数に設定できます。為替レートは有効数字と指数で表されますが、`TickSize`は指数には影響しません。これにより、XRP Ledgerでは価値が大きく異なる資産（ハイパーインフレ通貨と希少通貨など）間の為替レートを表せます。発行者が設定する`TickSize`が小さいほど、トレーダーはより多くの増分をオファーして、既存のオファーよりも高い為替レートと見えるようにする必要があります。
+
+`TickSize`は、オファーの即時に実行可能な部分には影響しません。（この理由から、`tfImmediateOrCancel`が指定されたOfferCreateトランザクションは`TickSize` の値の影響を受けません。）オファーを完全に実行できない場合、トランザクション処理エンジンは`TickSize`に基づいて為替レートを計算して切り捨てを行います。次にエンジンは、切り捨てた後の為替レートに一致するように、「重要性が低い」側からのオファーの残額を丸めます。デフォルトのOfferCreateトランザクション（「買い」オファー）の場合、`TakerPays`の額（購入額）が丸められます。`tfSell`フラグが有効な場合（「売り」オファー）`TakerGets`の額（売却額）が丸められます。
+
+発行者が`TickSize`を有効化、無効化、または変更する場合、以前の設定で発行されたオファーはその影響を受けません。
+
+## 参照項目
+
+- [Dev Blog: Introducing the TickSize Amendment](https://ripple.com/dev-blog/ticksize-amendment-open-voting/#ticksize-amendment-overview)
+
+- [AccountSetトランザクション][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/authorized-trust-lines.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/authorized-trust-lines.md
@@ -0,0 +1,128 @@
+---
+html: authorized-trust-lines.html
+parent: trust-lines-and-issuing.html
+seo:
+    description: 認可トラストラインとは、トークンを保有できる人を制限するための設定です。
+labels:
+  - トークン
+  - セキュリティ
+---
+# 認可トラストライン
+
+XRP Ledgerの認可トラストライン機能により、発行者は、発行者が許可したアカウントのみが保有できるトークンを作成することができます。認可トラストライン機能はトークンにのみ適用され、XRPには影響しません。
+
+認可トラストライン機能を使用するには、発行アドレスで**RequireAuth**フラグを有効にします。その後、他のアカウントは、あなたがそのアカウントのトラストラインをあなたの発行アカウントに承認した場合にのみ、あなたが発行したトークンを保持することができます。
+
+発行アドレスから[TrustSetトランザクション][]を送信し、自分のアカウントと認可するアカウントとの間のトラストラインを設定することで、トラストラインを認可することができます。トラストラインを認可した後、その認可を取り消すことはできません。(ただし、必要に応じてトラストラインを[凍結](freezes.md)することは可能です)。
+
+トラストラインを認可するためのトランザクションは、発行アドレスの署名が必要であり、残念ながらそのアドレスのリスクエクスポージャーが増加することを意味します。
+
+{% admonition type="warning" name="注意" %}Require Authを有効にできるのは、アカウントにトラストラインがなく、XRP LedgerにOffersがない場合だけなので、トークンの発行前に使用するかどうかを決定する必要があります。{% /admonition %}
+
+## ステーブルコインの発行
+
+XRP Ledger上のステーブルコインと認可トラストラインの使用により、新規顧客の獲得プロセスは以下のようなものになります。
+
+1. 顧客は、ステーブルコイン発行会社のシステムに登録し、身元を証明する情報（「Know Your Customer」（KYC）情報とも呼ばれる）を送信します。
+2. 顧客とステーブルコイン発行者は、お互いのXRP Ledgerアドレスを提示し合います。
+3. 顧客は[TrustSetトランザクション][]を送信し、発行者のアドレスにトラストラインを作成し、正のリミットを設定します。
+4. 発行者はTrustSetトランザクションを送信し、顧客のトラストラインを認可します。
+
+{% admonition type="success" name="ヒント" %}2つのTrustSetトランザクション（ステップ3および4）は、どちらの順序で発生しても構いません。発行者がトラストラインを先に認可した場合、これにより限度額が0に設定されたトラストラインが作成され、顧客のTrustSetトランザクションは、事前に認可されたトラストラインの限度額を設定することになります。([TrustSetAuth amendment][]により追加されました。)_{% /admonition %}
+## 注意事項
+
+認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](../../accounts/account-types.md)のRequire Auth設定を有効にし、これらのアカウントにトラストラインを認可させないようにすることができます。これは、これらのアカウントが誤ってトークンを発行することを防止します（たとえば、ユーザが誤って間違ったアドレスをトラストしてしまった場合など）。これはあくまで予防措置であり、運用アカウントと予備アカウントが意図したとおりに _発行者の_ トークンを転送することを止めるものではありません。
+
+## 技術情報
+<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
+
+### RequireAuthの有効化
+
+以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使って、`asfRequireAuth`フラグを使ってRequire Authを有効にする[AccountSetトランザクション][]を送信する例です。（このメソッドは、アドレスが発行アドレス、運用アドレス、待機アドレスのいずれであっても同様に機能します。）
+
+リクエスト:
+
+```json
+POST http://localhost:5005/
+{
+   "method": "submit",
+   "params": [
+       {
+           "secret": "s████████████████████████████",
+           "tx_json": {
+               "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
+               "Fee": "15000",
+               "Flags": 0,
+               "SetFlag": 2,
+               "TransactionType": "AccountSet"
+           }
+       }
+   ]
+}
+```
+
+{% partial file="/@l10n/ja/docs/_snippets/secret-key-warning.md" /%}
+
+
+## アカウントのRequireAuthの有効化の確認
+
+アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)と比較します。
+
+`Flags`値と`lsfRequireAuth`フラグ値（`0x00040000`）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
+
+## トラストラインの認可
+
+認可トラストライン機能を使用している場合、他のアカウントからのトラストラインを認可しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数のトークンを発行する場合には、各通貨のトラストラインを個別に認可する必要があります。
+
+トラストラインを認可するには、`LimitAmount`の`issuer`として信頼するユーザを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](../../../references/protocol/transactions/types/trustset.md#trustsetのフラグ)フラグを有効にします。
+
+以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`がアドレス`rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`で発行したUSDを持つことを認可するTrustSetトランザクションを送信する例です。
+
+リクエスト:
+
+```json
+POST http://localhost:8088/
+{
+   "method": "submit",
+   "params": [
+       {
+           "secret": "s████████████████████████████",
+           "tx_json": {
+               "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+               "Fee": "15000",
+               "TransactionType": "TrustSet",
+               "LimitAmount": {
+                   "currency": "USD",
+                   "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                   "value": 0
+               },
+               "Flags": 65536
+           }
+       }
+   ]
+}
+```
+
+{% partial file="/@l10n/ja/docs/_snippets/secret-key-warning.md" /%}
+
+
+## トラストラインの認可状況の確認
+
+トラストラインの認可状況を確認するには、[account_linesメソッド][]を使用してトラストラインを調べます。レスポンスの`account`フィールドに顧客のアドレスを指定し、`peer`フィールドに発行者のアドレスを指定します。
+
+レスポンスの`result.lines`配列で、必要とする通貨のトラストラインを表している`currency`フィールドを持つオブジェクトを見つけます。そのオブジェクトの`peer_authorized`フィールドに値`true`が設定されている場合は、発行者（レスポンスの`peer`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
+
+## 関連項目
+
+- **コンセプト:**
+    - [Deposit Authorization](../../accounts/depositauth.md)
+    - [トークンの凍結](freezes.md)
+- **リファレンス:**
+    - [account_linesメソッド][]
+    - [account_infoメソッド][]
+    - [AccountSetトランザクション][]
+    - [TrustSetトランザクション][]
+    - [AccountRootフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
+    - [RippleState (トラストライン) フラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/clawing-back-tokens.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/clawing-back-tokens.md
@@ -0,0 +1,40 @@
+---
+html: clawing-back-tokens.html
+parent: trust-lines-and-issuing.html
+seo:
+    description: 発行者は、トークンを発行する前にClawback機能を有効にすると、規制遵守の目的でトークンを取り戻すことができます。
+labels:
+  - トークン
+---
+# トークンの回収
+
+{% partial file="/@l10n/ja/docs/_snippets/clawback-disclaimer.md" /%}
+
+規制上の目的から、トークンがアカウントに送信された後にトークンを回収する機能を必要とする発行者が存在します。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を「回収」することができます。
+
+発行者は、発行アカウントで**Allow Clawback**フラグを有効にすることで、トークンを回収する権限を得ることができます。発行者がすでにトークンを発行している場合、このフラグを有効にすることはできません。
+
+{% admonition type="info" name="注記" %}アカウント自身が発行したトークンのみを回収することができます。この方法でXRPを回収することはできません。{% /admonition %}
+
+Clawback機能はデフォルトで無効になっています。使用するには、[AccountSetトランザクション][]を送信して、**Allow Trust Line Clawback**設定を有効にする必要があります。**既存のトークンを持つ発行者はClawback機能を有効にすることはできません**。**Allow Trust Line Clawback**を有効にできるのは、所有者ディレクトリが完全に空の場合のみです。つまり、トラストライン、オファー、エスクロー、ペイメントチャネル、チェック、または署名者リストを設定する前に有効にする必要があります。
+
+`lsfNoFreeze`が設定されているときに`lsfAllowTrustLineClawback`を設定しようとすると、トランザクションは`tecNO_PERMISSION`を返します。
+逆に、`lsfAllowTrustLineClawback`が設定されている時に`lsfNoFreeze`を設定しようとすると、トランザクションは`tecNO_PERMISSION`を返します。
+
+## Clawbackトランザクションの例
+
+```json
+{
+  "TransactionType": "Clawback",
+  "Account": "rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9S",
+  "Amount": {
+      "currency": "FOO",
+      "issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+      "value": "314.159"
+    }
+}
+```
+
+このトランザクションが成功した場合、rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9Sが発行し、rsA2LpzuawewSBQXkiju3YQTMzW13pAAdWが保有する最大314.159FOOを回収することになります。
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/common-misconceptions-about-freezes.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/common-misconceptions-about-freezes.md
@@ -0,0 +1,34 @@
+---
+parent: freezes.html
+html: common-misconceptions-about-freezes.html
+seo:
+    description: XRP Ledgerのフリーズ機能について、よくある誤解を解いていきます。
+labels:
+  - トークン
+---
+# トークンの凍結に関するよくある誤解
+
+PayPalのような中央集権的なサービスがアカウントを停止して資金にアクセスできないようにするのと同様に、Ripple社などがXRPを凍結することができるというのはよくある誤解です。XRP Ledgerには[凍結機能](freezes.md)がありますが、これは発行トークンにのみ使用可能で、XRPには使用できません。 **XRPを凍結することは誰にもできません**。
+
+XRP Ledgerのトークンは、[XRPとは根本的に異なる](../../../references/protocol/data-types/currency-formats.md#comparison)ものです。トークンは常にトラストライン上に存在し、それは凍結される可能性があります。XRPはアカウントに含まれており、凍結されることはありません。
+
+## XRPは単なるRipple社のトークンではないのか？
+
+いいえ、XRPはトークンとは異なります。XRPはXRP Ledger上の唯一のネイティブアセットであり、XRP Ledger上で取引を行うために必要なものです。XRPにはカウンタパーティが存在しません。つまり、誰かがXRPを保有するとき、その人は負債を保有しているのではなく、実際の通貨であるXRPを保有しているのです。この事実により、 _**<u>XRPはいかなる団体や個人によっても凍結することができません</u>**_ 。
+
+## Ripple社またはXRP Ledger財団は私のトークンを凍結することができますか？
+
+XRP Ledgerは分散型であり、Ripple社やXRP Ledger財団、そして他のいかなる存在もそれをコントロールすることはできません。
+
+あるトークンの発行者は、 _そのトークンに限定して_ あなたのトラストラインを凍結することができます。あなたのアカウントの他の部分や、異なる発行者のトークンを凍結することはできませんし、あなたがXRP Ledgerを使うのを止めることもできないのです。
+
+さらに、トークン発行者は、トークンを凍結する能力を自主的かつ永久的に放棄することができます。この["No Freeze"](freezes.md#no-freeze)設定は、他者がトークンの使用を止めることができないという意味で、トークンがより実際の現金のように振る舞うことを想定しています。
+
+
+## しかし、Ripple社がJed McCaleb氏のXRPを凍結したと聞きましたが？
+
+これは、2015年から2016年にかけて実際に起こった事件の誤報です。2013年にRipple社の創業者で同社を退社したJed McCaleb氏は、100万USドル以上のXRPをカストディ取引所であるBitstampで売却しようと試みました。Ripple社の代理人は、この売却はJed氏とRipple社が2014年に締結した契約に違反すると主張しました。Ripple社の要求により、[BitstampはJedのBitstampアカウントを凍結](https://www.coindesk.com/markets/2015/04/02/1-million-legal-fight-ensnares-ripple-bitstamp-and-jed-mccaleb/)し、裁判に持ち込まれました。この裁判は[最終的に和解](https://www.coindesk.com/markets/2016/02/12/ripple-settles-1-million-lawsuit-with-former-executive-and-founder/)となり、双方がその結果に納得したと表明しています。
+
+注目すべきは、この「凍結」はXRP Ledger上で起こったものではなく、XRP Ledgerの凍結機能を使ったものでもないことです。他のカストディアン取引所と同様に、Bitstampはユーザのアカウントを凍結し、特にそれらの資金が法的紛争に巻き込まれている場合、取引や資金の引き出しを停止する権限を持っています。
+
+一方、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)で取引する場合は、自分で資産を管理するので、XRPの取引を止めることは誰にもできないのです。
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/demurrage.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/demurrage.md
@@ -0,0 +1,127 @@
+---
+html: demurrage.html
+parent: trust-lines-and-issuing.html
+seo:
+    description: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。.
+status: removed
+---
+# デマレージ
+
+{% admonition type="warning" name="注意" %}デマレージは非推奨の機能であり、継続的なサポートはありません。このページでは、旧バージョンのXRP Ledgerソフトウェアの過去の動作について説明します。{% /admonition %}
+
+[デマレージ](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%9E%E3%83%AC%E3%83%BC%E3%82%B8) とは、保有資産にかかるマイナスの金利で、その資産を保有するためのコストを表すものです。 XRP Ledgerで発行された通貨のデマレージを表現するために、デマレージレートを示すカスタム[通貨コード](../../../references/protocol/data-types/currency-formats.md#通貨コード) を使って追跡することができます。 これによって、様々なデマレージの量に対応した別々のバージョンの通貨が効果的に作成されます。クライアントアプリケーションは、通貨コードと一緒に年率でデマレージ通貨コードを表現することによって、これをサポートすることができます。例えば、以下のようになります。"XAU (-0.5%pa)".
+
+## 通貨量の表記について
+
+XRP Ledgerのすべての金額を継続的に更新するのではなく、有利子通貨や減耗通貨の金額を2種類の金額に分割する方法です。XRP Ledgerに記録される「レジャー値」と、人に見せる「表示値」の2種類に分けます。「レジャー値」は、ある一定時点、すなわち2000年1月1日午前0時の「リップルエポック」での通貨の価値を表しています。「表示値」は、リップルエポックからその時点までの連続した利息やデマレージを計算した後の時点（通常は現在時刻）での金額を表しています。
+
+{% admonition type="success" name="ヒント" %}デマレージはインフレに似ていると考えることができます。インフレの影響を受けたすべての資産の価値は時間とともに減少しますが、レジャーには常に2000年の値で金額が記録されます。これは実際のインフレを反映しているわけではなく、デマレージはむしろ一定の割合での仮想的なインフレのようなものです。{% /admonition %}
+
+したがって、クライアントソフトウェアは2つの変換を適用する必要があります。
+
+- ある時点の表示値を取り込み、レジャー値に変換して記録すること。
+- レジャー値を、ある時点の表示値に変換すること。
+
+### デマレージの計算
+
+通貨に関するデマレージの完全な計算式は以下の通りです。
+
+```
+D = A × ( e ^ (t ÷ τ) )
+```
+
+- **D** はデマレージ後の金額
+- **A** はグローバルレジャーに記録されたデマレージ前金額です。
+- **e** はオイラー数
+- **t** はリップルエポック（UTC2000年1月1日0時）からの経過秒数
+- **τ** は、e倍加時間の時間（秒）です。この値は［希望する金利から計算］（#e倍加時間の計算）されます。 <!-- SPELLING_IGNORE: τ -->
+
+表示金額とレジャー金額の変換は、以下の手順で行います。
+
+1. `( e ^ (t ÷ τ) )`の値を計算する。この数値を「デマレージ係数」と呼ぶ。デマレージ係数は常に現在時刻など特定の時刻からの相対値である。
+2. 変換する量に適用します。
+    - レジャー値を表示値に変換する場合は、デマレージ係数を乗じる。
+    - 表示値をレジャー値に変換する場合は、デマレージ係数で割ってください。
+3. 必要であれば、結果値が望ましい精度で表現できるように調整する。XRP Ledgerの[発行通貨形式](../../../references/protocol/data-types/currency-formats.md#トークンの精度)により、レジャー値の精度は小数点以下15桁までとされています。
+
+
+## 利子付き通貨コードフォーマット
+
+[標準通貨コード形式](../../../references/protocol/data-types/currency-formats.md#標準通貨コード)ではなく、正の金利や負の金利（Demurrage）を持つ通貨は、以下の形式の160ビット通貨コードを使用します。
+
+![通貨コード形式を削除する](/docs/img/demurrage-currency-code-format.png)
+
+1. 最初の8ビットは `0x01` でなければなりません。
+2. 次の24ビットはASCIIの3文字を表します。
+    これはISO 4217のコードと予想されます。標準フォーマットのASCII文字と同じ文字をサポートしています。
+3. 次の24ビットはすべて「0」でなければなりません。
+4. 次の64ビットは通貨の金利で、IEEE754ダブルフォーマットで「[e-folding time](http://en.wikipedia.org/wiki/E-folding)」と表現される。
+5. 次の24ビットは予約されており，すべて`0`でなければなりません
+
+### e倍加時間の計算
+
+レジャー金額と表示金額の変換や、有利子/不利子通貨の通貨コードの計算には、「e倍加時間」としての金利が必要です。e倍加時間とは、ある数量が _e_（オイラー数）の倍数だけ増加するのにかかる時間のことである。慣例として、e倍加時間は数式では**τ**という文字で表記される。
+
+ある年率パーセントの利息に対するe倍加時間の時間を計算すること。
+
+1. 100%に金利を足すと、年利を適用した後の初期金額に対する割合が算出されます。デマレージには、マイナスの金利を使用します。例えば、0.5%のデマレージは-0.5%の金利となり、**99.5%**の残存率となります。
+2. パーセンテージを小数で表します。例えば、99.5%は**0.995**となります。
+3. その数値の自然対数をとります。例えば、**ln(0.995) = -0.005012541823544286** となります。(この数値は、当初の金利がプラスであればプラス、マイナスであればマイナスになります)。
+4. 1年間の秒数（31536000）を、前のステップの自然対数の結果で割ってください。例えば、**31536000 ÷ -0.005012541823544286 = -6291418827.045599** となります。この結果が、e倍加時間（秒）です。
+
+{% admonition type="info" name="注記" %}XRP Ledgerの利息・デマレージルールでは、慣習上、1年あたりの固定秒数（31536000）が使用されており、閏日や閏秒の調整は行われていません。{% /admonition %}
+
+## クライアントサポート
+
+利息通貨とデマレージ通貨をサポートするために、クライアントアプリケーションはいくつかの機能を実装する必要があります。
+
+- レジャーやトランザクションデータから取得した通貨を減耗して表示する場合、クライアント側でレジャー値から表示値への変換が必要です。(デマレージでは、表示値はレジャー値より小さくなる)。
+
+- デマレージ通貨の入力を受け付ける場合、クライアントは金額を表示形式からレジャー形式に変換する必要があります。(デマレッジの場合、ユーザ入力値よりレジャー値の方が大きい)。クライアントは、支払い、オファー、その他のトランザクションを作成する際に、レジャーの値を使用しなければなりません。
+
+- クライアントは、金利やデマレージが発生する通貨と発生しない通貨、および金利やデマレージの利率が異なる通貨を区別する必要があります。クライアントは、[利子付き通貨コードフォーマット](#利子付き通貨コードフォーマット)を解析して、「XAU (-0.5% pa)」などの表示にできるようにしなければなりません。
+
+### ripple-lib サポート
+
+デマレージは ripple-lib のバージョン **0.7.37** から **0.12.9** まででサポートされていました。デマレージは、最近のほとんどのライブラリでは***サポートされていません***。
+
+以下のコードサンプルは、互換性のあるバージョンのripple-libを使用して、レジャー値と表示値の変換を行う方法を示しています。また、[Ripple Demurrage Calculator](https://ripple.github.io/ripple-demurrage-tool/)もご覧ください。
+
+表示値からレジャー値に変換するには、`Amount.from_human()`を使用する。
+
+```js
+// デマレージ通貨の表示金額を表す Amount オブジェクトを作成し、
+// 現在の日付を表すreference_dateを渡します。
+// (この場合、2017-11-04T00:07:50Zに、年0.5%の脱税で台帳値10 XAU。)。
+var demAmount = ripple.Amount.from_human('10 0158415500000000C1F76FF6ECB0BAC600000000',
+                                  {reference_date:563069270});
+
+// 発行者を設定します
+demAmount.set_issuer("rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh");
+
+// get the JSON format for the ledger amount
+console.log(demAmount.to_json());
+
+// { "value": "10.93625123082769",
+//   "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
+//   "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
+```
+
+レジャー値から表示値へ変換する場合、
+
+```js
+// レジャー値を持つ Amount オブジェクトを作成します。
+ledgerAmount = ripple.Amount.from_json({
+  "currency": "015841551A748AD2C1F76FF6ECB0CCCD00000000",
+  "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
+  "value": "10.93625123082769"})
+
+// 表示金額を得るために現在時刻までの利息を適用する
+var displayAmount = demAmount.applyInterest(new Date());
+
+console.log(displayAmount.to_json());
+
+// { "value": "9.999998874657716",
+//   "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
+//   "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
+```
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/freezes.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/freezes.md
@@ -0,0 +1,101 @@
+---
+html: freezes.html
+parent: trust-lines-and-issuing.html
+seo:
+    description: 発行者はコンプライアンス目的でトークンの取引を停止できます。
+labels:
+  - トークン
+---
+# トークンの凍結
+
+発行者は発行したトークンをXRP Ledgerで凍結することができます。**これはXRP LedgerのネイティブアセットであるXRPには適用されません。**
+
+特定のケースでは、法的要件への準拠や、疑わしい活動の調査のために、取引所またはゲートウェイが、XRP以外のトークンの残高を急きょ凍結することがあります。
+
+{% admonition type="success" name="ヒント" %}誰もXRP LedgerのXRPを凍結することはできません。しかし、カストディアル取引所は、自らの裁量で常に保管資金を凍結することができます。詳しくは、[凍結に関するよくある誤解](common-misconceptions-about-freezes.md)をご覧ください。{% /admonition %}
+
+凍結については、3種類の設定があります。
+
+* [**Individual Freeze(個別の凍結)**](#individual-freeze) - 1件の取引相手を凍結します。
+* [**Global Freeze(全体の凍結)**](#global-freeze) - 取引相手全員を凍結します。
+* [**No Freeze(凍結機能の放棄)**](#no-freeze) - 個々の取引相手の凍結機能と、Global Freeze機能を永久に放棄します。
+
+凍結対象の残高がプラス、マイナスにかかわらず、すべての凍結設定を行うことができます。通貨イシュアーまたは通貨保持者のいずれかがトラストラインを凍結できますが、通貨保持者がイシュアーを凍結しても、その影響はわずかです。
+
+
+## Individual Freeze
+
+**Individual Freeze**機能は、[トラストライン](index.md)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
+
+* 凍結されたトラストラインの両当事者間の直接決済は、凍結後も可能です。
+* そのトラストラインの取引相手は、イシュアーへ直接支払う場合を除き、凍結されたトラストラインの残高を減らすことはできません。取引相手は、凍結されたイシュアンスを直接イシュアーに送信することだけが可能です。
+* 取引相手は、凍結されたトラストライン上で引き続きその他の当事者からの支払を受け取ることができます。
+* 取引相手が凍結されたトラストライン上のトークンの売りオファーを出した場合、[資金不足とみなされます](../decentralized-exchange/offers.md#オファーのライフサイクル)。
+
+再確認: トラストラインではXRPは保持されません。XRPは凍結できません。
+
+金融機関は、疑わしい活動を行う取引相手や、金融機関の利用規約に違反する取引相手にリンクしているトラストラインを凍結できます。金融機関は、同機関が運用する、XRP Ledgerに接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。（凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。）
+
+各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](../../accounts/account-types.md)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
+
+Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
+
+[No Freeze](#no-freeze)設定を有効にしている場合、アドレスはIndividual Freeze設定を有効にできません。
+
+
+## Global Freeze
+
+**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべてのトークンに対して以下のルールが適用されます:
+
+* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](../../accounts/account-types.md)にも影響します。）
+* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
+* 凍結アドレスによるトークンの売りオファーはすべて、[資金不足とみなされます](../decentralized-exchange/offers.md#オファーのライフサイクル)。
+
+再確認: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
+
+運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](../../accounts/account-types.md)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
+
+また、金融機関が新しい[発行アドレス](../../accounts/account-types.md)への移行や、営業の停止を予定している場合にも、Global Freezeを有効にすることが有用です。これにより、特定の時点で資金がロックされるため、ユーザは他の通貨で取引することができなくなります。
+
+Global Freezeは、当該アドレスによって発行および保有されている _すべての_ 通貨に適用されます。1つの通貨のみに対してGlobal Freezeを有効にすることはできません。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
+
+アドレスのGlobal Freeze設定はいつでも有効にできます。ただし、アドレスの[No Freeze](#no-freeze)設定を有効にすると、Global Freezeを _無効にする_ ことはできません。
+
+
+## No Freeze
+
+**No Freeze**機能をアドレスに設定すると、取引相手が発行した通貨を凍結する機能を永久に放棄します。この機能を使用すれば、企業は自社が発行した資金を「物理的なお金のように」扱うことができます。これにより、企業は顧客どうしがその資金を取引することに介入できなくなります。
+
+確認事項: XRPはすでに凍結できません。No Freeze機能は、XRP Ledgerで発行された他の通貨にのみ適用されます。
+
+No Freeze設定には次の2つの効果があります。
+
+* 発行アドレスは、すべての取引相手とのトラストラインに対してIndividual Freezeを有効にできなくなります。
+* 発行アドレスは、Global Freezeを有効にしてグローバル凍結を施行できますが、Global Freezeを _無効にする_ ことはできません。
+
+XRP Ledgerは金融機関に対し、その発行資金が表す債務を履行することを強制できません。このため、Global Freezeを有効にする機能を放棄しても顧客を保護できません。ただし、Global Freezeを _無効にする_ 機能を放棄することで、Global Freeze機能が一部の顧客に対して不当に適用されないようにすることができます。
+
+No Freeze設定は、アドレスに対して発行される通貨と、アドレスから発行される通貨のすべてに適用されます。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
+
+No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](../../../references/protocol/transactions/types/setregularkey.md)または[マルチシグトランザクション](../../accounts/multi-signing.md)を使用してNo Freezeを有効にすることはできません。
+
+
+
+# 関連項目
+
+- [凍結コードの例](https://github.com/XRPLF/xrpl-dev-portal/tree/master/_code-samples/freeze)
+- **コンセプト:**
+    - [トラストラインとトークンの発行](index.md)
+- **Tutorials:**
+    - [No Freezeを有効化](../../../tutorials/how-tos/use-tokens/enable-no-freeze.md)
+    - [Global Freezeの実行](../../../tutorials/how-tos/use-tokens/enact-global-freeze.md)
+    - [トラストラインの凍結](../../../tutorials/how-tos/use-tokens/freeze-a-trust-line.md)
+- **References:**
+    - [account_linesメソッド][]
+    - [account_infoメソッド][]
+    - [AccountSetトランザクション][]
+    - [TrustSetトランザクション][]
+    - [AccountRootフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
+    - [RippleState(trust line)フラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/index.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/index.md
@@ -0,0 +1,94 @@
+---
+html: trust-lines-and-issuing.html
+parent: tokens.html
+seo:
+    description: トラストラインの特性と根本原理について説明します。
+labels:
+  - トークン
+---
+# 代替可能トークン
+
+非公式な"借用書"から、法定通貨を担保とするステーブルコイン、純粋なデジタルファンジブルトークンやセミファンジブルトークンなど、誰でもXRP Ledger上で代替可能なトークンを発行することができます。
+
+代替可能トークンは交換可能で、互いに区別がつきません。トークンは交換可能で、同等の価値を持つ他のトークンと置き換えることができます。交換可能なトークンを作成するには、2つのアカウント間で会計関係の一種である「トラストライン」を設定し、それらのアカウント間で支払いを送信します。ほとんどのユースケースでは、最初に設定する必要がある設定もあります。
+
+## トラストライン
+
+トラストラインとは、XRP Ledgerにおける[トークン](../index.md)を保持するための仕組みを指します。トラストラインは、XRP Ledgerのルールである「不要なトークンを他者に保有させることはできない」という原則を強制するものです。この制限は、XRP Ledgerのユースケースである[コミュニティクレジット](../index.md#コミュニティクレジット)などを実現するために不可欠なものです。
+
+それぞれの「トラストライン」は、以下のような _双方向_ の関係から成り立っています。
+
+- トラストラインが接続する **2つの[アカウント](../../accounts/index.md)** の識別子
+- 一方のアカウントから見てプラス、他方のアカウントから見てマイナスとなる、単一の共有された**残高**
+    - 残高がマイナスのアカウントは、一般的にトークンの「発行者」とみなされます。ただし、[API](../../../references/http-websocket-apis/index.md)では、`issuer`という名称はどちらを指すこともあるようです。
+- 様々な **設定** とメタデータ。2つのアカウントの _それぞれ_ は、トラストライン上の設定を制御することができます。
+    - 最も重要なことは、各サイドがトラストラインに **限度額** を設定できることです。これはデフォルトでは0です。各アカウントの残高は(トラストラインから見て)そのアカウントの上限を超えることはできません。ただし、[アカウント自身の操作](#限度額以上を保有する)を除きます。
+
+各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
+
+トラストラインの残高は、それをどちらの側から見るかによって負または正になります。負の残高を持つ側は「発行者」と呼ばれ、トークンの振る舞いに関するいくつかのプロパティを制御できます。トークンを発行者ではない別のアカウントに送ると、そのトークンは発行者や、おそらく同じ通貨コードを使用している他のアカウントを通じて「ripple(波及)」します。これは便利な場合もありますが、予期しない望ましくない動作を引き起こす場合もあります。トラストラインに[No Rippleフラグ](rippling.md)を使用することで、トラストラインが波及しないようにすることができます。
+
+## 作成
+
+アカウントはいずれも、ゼロでない上限と独自の設定を持つ[TrustSetトランザクション][]を送信することによって、他のアカウントに対して一方的にトークンを「トラスト」することができます。これによって、残高ゼロのトラストラインが作成され、相手側の設定がデフォルトとして設定されます。
+
+トラストラインは、[分散型取引所](../decentralized-exchange/index.md)でトークンを購入するときなど、いくつかのトランザクションによって暗黙的に作成されることがあります。この場合、トラストラインはデフォルト設定をそのまま使用します。
+
+
+## 限度額以上を保有する
+
+トラストラインの限度額よりも _大きい_ 残高を保有できるケースは次の3つがあります。
+
+1. [トレード](../decentralized-exchange/index.md)によって、限度額以上のトークンを取得した場合
+2. プラスの残高があるトラストラインの限度額を減らした場合
+3. [チェックの現金化](../../payment-types/checks.md)によって、トークンを限度額以上取得する場合 (_[CheckCashMakesTrustLine amendment][]により追加されました。_)
+
+
+## トラストラインの設定
+
+アカウントごとに、共通残高のほかに、トラストラインの設定項目があり、その構成は以下のとおりです。
+
+- **Limit**: 0から[トークンの上限量](../../../references/protocol/data-types/currency-formats.md)の範囲内の数字です。支払いや他のアカウントの操作によって、(このアカウントから見た)トラストラインの残高が限度額を超えることはできません。デフォルトは`0`です。
+- **Authorized**: [Authorized Trust Lines](authorized-trust-lines.md)と併用し、このアカウントが発行するトークンを相手側に保持させることを許可するための値(true/false)です。デフォルトは`false`です。一度`true`に設定すると、元に戻すことはできません。
+- **No Ripple**: トークンがこのトラストラインを通過して[ripple](rippling.md)するかどうかを設定するための値(true/false)です。デフォルトはアカウントの"Default Ripple"設定に依存します。新しいアカウントでは"Default Ripple"はoffで、つまり`true`がNo Rippleのデフォルト値となります。通常、発行者はrippleを許可し、非発行者はコミュニティクレジットのためにトラストラインを使用していない限り、rippleを無効にするべきです。
+- **Freeze**: このトラストラインに[個別の凍結](freezes.md#individual-freeze)が適用されているかどうかを示す値(true/false)です。デフォルトは`false です。
+- **Quality In** および **Quality Out**: この設定により、このトラストライン上の他のアカウントで発行されたトークンを額面より少なく（または多く）評価することができます。たとえば、ステーブルコインの発行者が、オフレッジャーにある同等の資産に対してトークンの引き出しに3%の手数料を課している場合、この設定を使用して、それらのトークンを額面の97%で評価することが可能です。デフォルトは`0`で、額面価格を表しています。
+
+
+## 準備金と削除
+
+トラストラインは台帳のスペースを使用するため、[トラストラインはあなたのアカウントが準備金として保持しなければならないXRPを増加させます](../../accounts/reserves.md)。 トラストラインのどちらか、または両方のアカウントにトラストラインの準備金が負担されることがあります。トラストラインの設定がデフォルトでない場合、またはプラス残高を保持している場合、所有者準備金の1つとしてカウントされます。
+
+一般に、トラストラインを作成したアカウントが準備金を負担し、発行者は負担しないという意味です。<!-- STYLE_OVERRIDE: is responsible for -->
+
+トラストラインは、両者の設定がデフォルトの状態で、残高が0であれば自動的に削除されます。つまり、トラストラインを削除するには次の方法があります。
+
+1. 設定した内容をデフォルトに戻すために、[TrustSetトランザクション][]を送信する。
+2. トラストラインにあるプラスの残高をすべて処分します。これは[支払い](../../payment-types/cross-currency-payments.md)によって通貨を送るか、[分散型取引所](../decentralized-exchange/index.md)で通貨を売却することで可能です。
+
+残高がマイナス（あなたが発行者）の場合や、相手側の設定が初期状態でない場合、トラストラインを完全に削除させることはできませんが、同様の手順で所有者準備金にカウントされないようにすることが可能です。
+
+**Authorized** の設定は、一度オンにするとオフにできないため、トラストラインの初期状態にはカウントされません。
+
+## 無料のトラストライン
+[[Source]](https://github.com/XRPLF/rippled/blob/72377e7bf25c4eaee5174186d2db3c6b4210946f/src/ripple/app/tx/impl/SetTrust.cpp#L148-L168)
+
+トラストラインはXRP Ledgerの強力な機能であるため、アカウントの最初の2つのトラストラインを「無料」にする特別な機能が用意されています。
+
+アカウントが新しいトラストラインを作成する際、台帳の中で新しいトラストラインを含む最大2つのオブジェクトを所有している場合、アカウントの所有者準備金は通常の量ではなく、0として扱われます。これにより、アカウントが台帳内のオブジェクトを所有するために必要な準備金の増加分を満たすだけのXRPを保有していない場合でも、取引を成功させることができます。
+
+アカウントが台帳に3つ以上のオブジェクトを所有している場合、所有者準備金が全額適用されます。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [分散型取引所](../decentralized-exchange/index.md)
+    - [リップリング](rippling.md)
+- **リファレンス:**
+    - [account_linesメソッド][] - 指定されたアカウントに関連付けられたトラストラインを確認
+    - [gateway_balancesメソッド][] - 発行者の発行残高を確認
+    - [RippleStateオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) - 台帳の状態データのうち、トラストラインのデータ形式
+    - [TrustSetトランザクション][] - トラストラインを作成・変更するトランザクション
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/paths.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/paths.md
@@ -0,0 +1,116 @@
+---
+html: paths.html
+parent: trust-lines-and-issuing.html
+seo:
+    description: トークンによる支払いは、接続されているユーザのパスとオーダーブックを通す必要があります。
+labels:
+  - 支払い
+  - クロスカレンシー
+---
+# パス
+
+XRP Ledgerでは、[トークン](../index.md)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)の注文と[自動マーケットメーカー](../../../concepts/tokens/decentralized-exchange/automated-market-makers.md)を介して送金元と受取人を結び付けることで、[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
+
+XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
+
+XRPは任意のアドレスに直接送金できるため、[XRP間のトランザクション](../../payment-types/direct-xrp-payments.md)ではパスは使用されません。
+
+## パスのステップ
+
+パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
+
+* 同一通貨の別のアドレスを通じたRippling
+* オーダーブックとAMMでの通貨の取引
+
+別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.md)をご覧ください。
+
+[トークンとXRPの交換](../decentralized-exchange/index.md)は、オーダーブックまたはAMMを介して行われます。トランザクションは、送金元と受取人の間で最も良い交換レートを提供するオーダーブックまたはAMMを見つけるために、パスのステップを使用します。パスのステップは、通貨の変換先を指定しますが、オーダーブックのOfferの状態を記録しません。トランザクションの順序は、レジャーが検証されるまで確定しないため、トランザクションが取引するOfferやAMMを確定することはできません。(ただし、各トランザクションは最終的なレジャーで最良の利用可能な交換レートを取得します。)
+
+いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](../transfer-fees.md)、AMM手数料、トラストライン残高の増減、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
+
+[{% inline-svg file="/docs/img/paths-examples.ja.svg" /%}](/docs/img/paths-examples.ja.svg "3つのパスの例を示す図")
+
+
+
+# 技術詳細
+
+## Pathfinding
+
+`rippled` APIではPathfindingに使用できるメソッドが2つあります。[ripple_path_findメソッド][]は、1回限りのパスセットの検索を実行します。[path_findメソッド][]（WebSocketのみ）は、レジャーが閉鎖するか、またはサーバがより適切なパスを検出するたびに、フォローアップレスポンスによって検索を拡大します。
+
+署名時に`rippled`によりパスが自動的に入力されるようにするには、[signメソッド][]または[`submit`コマンド（署名と送信モード）](../../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)へのリクエストに`build_path`フィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
+
+{% admonition type="warning" name="注意" %}`rippled`は可能な限り低コストのパスを検出するように設計されていますが、常にこのようなパスを検出できるわけではありません。信頼できない`rippled`インスタンスが改ざんされ、利益目的でこの動作が変更される可能性もあります。パスに沿った支払いの実行にかかる実際のコストは、送信時とトランザクション実行時で異なることがあります。{% /admonition %}
+
+パスの検出は、新しいレジャーが検証されるたびに数秒ごとに変化する非常に難しい課題であるため、`rippled`は完全に最適なパスを検出するようには設計されていません。ただし、いくつかの有効なパスを検出し、特定額の送金コストを推定することができます。
+
+
+## 暗黙のステップ
+
+規約として、パスのステップのいくつかは[Paymentトランザクションのフィールド](../../../references/protocol/transactions/types/payment.md)により黙示的に示されます。これらのフィールドは、`Account`（送金元）、`Destination`（受取人）、`Amount`（通貨と納入額）、`SendMax`（通貨と送金額（指定されている場合））です。暗黙のステップは次のとおりです。
+
+* パスの1番目のステップは、トランザクションの`Account`フィールドに定義されるとおり、トランザクションの送信者であると常に黙示されます。
+* トランザクションに、そのトランザクションの送信者ではない`issuer`が指定されている`SendMax`フィールドが含まれている場合、そのイシュアーはパスの2番目のパスとして黙示されます。
+  * `SendMax`の`issuer`が送信側アドレス _である_ 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、[SendMaxおよびAmountの特殊な値](../../../references/protocol/transactions/types/payment.md#sendmaxおよびamountで使用する特殊なissuerの値)をご覧ください。
+* トランザクションの`Amount`フィールドに、トランザクションの`Destination`とは異なる`issuer`が指定されている場合、そのイシュアーはパスの最後から2番目のステップであると黙示されます。
+* 最後に、トランザクションの`Destination`フィールドに定義されるとおり、パスの最終ステップはトランザクションの受信者であることが常に黙示されます。
+
+
+## デフォルトパス
+
+明示的に指定されたパスの他に、トランザクションは _デフォルトパス_ に沿って実行できます。デフォルトパスは、トランザクションの[暗黙のステップ](#暗黙のステップ)を接続する最も簡単な方法です。
+
+デフォルトパスは次のいずれかになります。
+
+* トランザクションで（イシュアーに関係なく）1種類の通貨のみが使用される場合、デフォルトパスでは支払いが、関連するアドレスを通じてRipplingされると想定されます。このパスは、これらのアドレスがトラストラインで接続されている場合にのみ機能します。
+  * `SendMax`が省略されているか、または`SendMax`の`issuer`が送金元の場合、デフォルトパスが機能するためには送金元`Account`から宛先`Amount`の`issuer`へのトラストラインが必要です。
+  * `SendMax`と`Amount`に異なる`issuer`値が指定されており、そのいずれも送金元または受取人ではない場合、これらの2つのイシュアー間のトラストラインでRipplingが必要となるため、デフォルトパスは有用ではない可能性があります。一般にイシュアーが互いに直接信頼し合うことはお勧めしません。
+* クロスカレンシー支払いの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックやAMMを使用します。
+
+有効なすべてのデフォルトパスを次の図に示します。
+[{% inline-svg file="/docs/img/default-paths.ja.svg" /%}](/docs/img/default-paths.ja.svg "デフォルトパスの図")
+
+デフォルトパスを無効にするには[`tfNoDirectRipple`フラグ](../../../references/protocol/transactions/types/payment.md#paymentのフラグ)を使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
+
+
+## パスの仕様
+
+パスセットは配列です。パスセットの各要素は、個々の _パス_ を表す別の配列です。パスの各要素は、ステップを指定するオブジェクトです。ステップのフィールドを次に示します。
+
+| フィールド  | 値                     | 説明                                   |
+|:-----------|:-----------------------|:---------------------------------------|
+| `account`  | 文字列 - アドレス       | _（省略可）_ 指定されている場合、このパスステップは指定されたアドレスを通じたRipplingを表します。このステップに`currency`フィールドまたは`issuer`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
+| `currency` | 文字列 - 通貨コード | _（省略可）_ 指定されている場合、このパスステップはオーダーブックやAMMを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
+| `issuer`   | 文字列 - アドレス       | _（省略可）_ 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨の発行者を定義します。XRP以外の`currency`のステップでこのフィールドが省略されている場合、パスの直前のステップが発行者を定義します。`currency`が省略され、このフィールドが指定されている場合、発行者が異なる同名の通貨間でオーダーブックやAMMを使用するパスステップを示します。`currency`がXRPの場合は省略する必要があります。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
+| `type`     | 整数                | **廃止予定**_（省略可）_ 他にどのフィールドが指定されているかを示します。 |
+| `type_hex` | 文字列                 | **廃止予定**: _（省略可）_`type`フィールドの16進数表現です。 |
+
+要約すると、以下のフィールドの組み合わせが有効であり、またオプションで`type`、`type_hex`のいずれかまたは両方を指定できます。
+
+- `account`のみ
+- `currency`のみ
+- `currency`と`issuer`（`currency`がXRP以外の場合）
+- `issuer`のみ
+
+パスステップで`account`、`currency`、`issuer`の各フィールドを上記以外の方法で指定することは無効です。
+
+パスセットのバイナリシリアル化に使用される`type`フィールドは、実際には1つの整数上でビット演算により作成されます。ビットの定義は次のとおりです。
+
+| 値（16進数） | 値（10進数）     | 説明        |
+|-------------|-----------------|-------------|
+| 0x01        | 1               | アドレスの変更（Rippling）:`account`フィールドが指定されています。 |
+| 0x10        | 16              | 通貨の変更:`currency`フィールドが指定されています。 |
+| 0x20        | 32              | イシュアーの変更:`issuer`フィールドが指定されています。 |
+
+## 関連項目
+
+- **コンセプト:**
+  - [クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)
+  - [分散型取引所](../decentralized-exchange/index.md)
+  - [Partial Payments](../../payment-types/partial-payments.md)
+- **リファレンス:**
+  - [Paymentトランザクション][]
+  - [path_findメソッド][]（WebSocketのみ）
+  - [ripple_path_findメソッド][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/rippling.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/rippling.md
@@ -0,0 +1,99 @@
+---
+html: rippling.html
+parent: trust-lines-and-issuing.html
+seo:
+    description: Ripplingは、複数当事者間でのトークン残高の自動ネット決済です。
+labels:
+  - トークン
+  - クロスカレンシー
+---
+# Rippling
+
+XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](index.md)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingはトークンの基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](../decentralized-exchange/offers.md)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
+
+Ripplingは、支払[パス](paths.md)でのみ発生します。[XRP間の直接決済](../../payment-types/direct-xrp-payments.md)にはRipplingは使用されません。
+
+発行アカウント以外のアカウントでは、Ripplingが望ましくない場合があります。Ripplingを使えば、他のユーザが同一通貨のイシュアー間で債権債務を移動できるようになるためです。このため、アカウントの[DefaultRippleフラグ](#defaultrippleフラグ)を有効にして、アカウントがデフォルトでRipplingを有効にしない限り、デフォルトでは[NoRippleフラグ](#norippleフラグ)により着信トラストラインでのRipplingが無効になっています。
+
+{% admonition type="warning" name="注意" %}別のアドレスへのトラストラインを作成する場合、そのトラストラインのあなたの側でRipplingをブロックするには、tfSetNoRippleフラグを明示的に有効にする必要があります。{% /admonition %}
+
+## Ripplingの例
+
+「Rippling」は、支払いを行うために複数のトラストラインが調整されたときに発生します。たとえば、AliceがCharlieにお金を借りており、さらにAliceはBobからもお金を借りている場合、XRP Ledgerではトラストラインは次のようになります:
+
+[{% inline-svg file="/docs/img/noripple-01.svg" /%}](/docs/img/noripple-01.svg "Charlie --($10)-- Alice -- ($20) -- Bob")
+
+BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、君に貸しているお金の中から$3をCharlieに支払ってくれ。」と言えます。AliceはBobに借りているお金の一部をCharlieに送金します。最終的にはトラストラインは次のようになります。
+
+[{% inline-svg file="/docs/img/noripple-02.svg" /%}](/docs/img/noripple-02.svg "Charlie --($13)-- Alice --($17)-- Bob")
+
+2つのアドレスが、アドレス間のトラストライン上の残高を調整することで相互に支払うこのプロセスを「Rippling」と呼びます。これはXRP Ledgerの有用で重要な機能です。Ripplingは、同一の[通貨コード][]を使用するトラストラインによってアドレスがリンクされている場合に起こります。イシュアーが同一でなくてもかまいません。実際、大規模なチェーンでは常にイシュアーが変更されます。
+
+## NoRippleフラグ
+
+発行アカウント以外のアカウント、特に手数料やポリシーが異なる複数のイシュアーの残高を保有している流動性プロバイダーは、一般的に残高がRipplingされることを望みません。
+
+「NoRipple」フラグは、トラストライン上の設定です。2つのトラストラインの両方で、同じアドレスによってNoRippleが有効に設定されている場合、第三者からの支払を、これらのトラストラインでこのアドレスを通じて「Rippling」することはできません。これにより、同一通貨の複数イシュアー間で流動性プロバイダーの残高が予期せず移動されるのを防ぎます。
+
+アカウントは1つのトラストラインでNoRippleを無効にできます。これにより、そのトラストラインを含む任意のペアを通じてのRipplingが可能になります。アカウントにてデフォルトでRipplingを有効にするには、[DefaultRippleフラグ](#defaultrippleフラグ)を有効にします。
+
+たとえば、Emilyが2つの異なる金融機関から発行されたお金を保有しているとします。
+
+[{% inline-svg file="/docs/img/noripple-03.svg" /%}](/docs/img/noripple-03.svg "Charlie --（$10）-- 金融機関A --（$1）-- Emily --（$100）-- 金融機関B --（$2）-- Daniel")
+
+CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingします。たとえば、CharlieがDanielに$10を支払うとします:
+
+[{% inline-svg file="/docs/img/noripple-04.svg" /%}](/docs/img/noripple-04.svg "Charlie --（$0）-- 金融機関A --（$11）-- Emily --（$90）-- 金融機関B --（$12）-- Daniel")
+
+この場合、CharlieやDanielと面識のないEmilyは驚く可能性があります。さらに、金融機関Aが金融機関Bよりも高い出金手数料をEmilyに請求した場合、Emilyがコストを負担することになる可能性があります。NoRippleフラグはこの状況を回避するためのフラグです。Emilyが両方のトラストラインでNoRippleフラグを設定していれば、この2つのトラストラインを使用しているEmilyのアドレスを通じて、支払がRipplingされることはありません。
+
+例:
+
+[{% inline-svg file="/docs/img/noripple-05.svg" /%}](/docs/img/noripple-05.svg "Charlie --（$10）-- 金融機関A --（$1、NoRipple）-- Emily --（$100、NoRipple）-- 金融機関B --（$2）-- Daniel")
+
+このように、CharlieがEmilyのアドレスを通じてRipplingし、Danielに支払うという上記のシナリオは、不可能になります。
+
+### 詳細
+
+NoRippleフラグにより特定のパスが無効になり、無効になったパスは支払に使用できなくなります。パスが無効であると見なされるのは、パスが、あるアドレスに対してNoRippleが有効となっているトラストラインを通じて、そのアドレスノードに入り**かつ**そのノードから出た場合に限られます。
+
+[{% inline-svg file="/docs/img/noripple-06.ja.svg" /%}](/docs/img/noripple-06.ja.svg "処理を行うためには同一アドレスによって両方のトラストラインにNoRippleが設定されている必要があることを示す図")
+
+
+## DefaultRippleフラグ
+
+DefaultRippleフラグは、デフォルトで着信トラストラインでのRipplingを有効にするアカウント設定です。ゲートウェイやその他の通貨イシュアーは、顧客が通貨を相互に送金できるようにするには、このフラグを有効にする必要があります。
+
+アカウントのDefaultRipple設定は、他者があなたに対してオープンしたトラストラインにのみ影響し、あなたが作成するトラストラインには影響しません。アカウントのDefaultRipple設定を変更する場合、変更前に作成したトラストラインでは既存のNoRipple設定が維持されます。アドレスの新しいデフォルトに合わせてトラストラインのNoRipple設定を変更するには、[TrustSetトランザクション][]を使用します。
+
+
+## NoRippleを使用する
+<!--{# TODO: move these things into their own tutorials #}-->
+
+### NoRippleを有効/無効にする
+
+トラストライン上のNoRippleフラグは、トラストライン上のアドレスの残高がプラスまたはゼロの場合に限り、有効にできます。これにより、この機能を悪用してトラストラインの残高に示される債務を不履行にすることができなくなります。（ただし、アドレスを放棄すれば債務を不履行にできます。）
+
+[`rippled` API](../../../references/http-websocket-apis/index.md)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
+
+
+### NoRippleステータスの確認
+
+相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
+
+[`rippled` API](../../../references/http-websocket-apis/index.md)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [パス](paths.md)
+- **リファレンス:**
+  - [account_linesメソッド][]
+  - [account_infoメソッド][]
+  - [AccountSetトランザクション][]
+  - [TrustSetトランザクション][]
+  - [AccountRootのフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
+  - [RippleState（トラストライン）のフラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/compliance-guidelines.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/compliance-guidelines.md
@@ -0,0 +1,125 @@
+---
+html: stablecoin-compliance-guidelines.html
+parent: stablecoins.html
+seo:
+    description: ステーブルコインの発行者は、現地の規制を遵守し、適切な機関に報告する責任があります。
+labels:
+  - トークン
+---
+# ステーブルコインのコンプライアンス指針
+
+トークン発行者は、各国の規制を遵守し、適切な機関に報告する責任があります。規制は国や州によって異なりますが、以下のセクションで説明する報告やコンプライアンスの要件が含まれる場合があります。トークンを発行する前に、管轄区域やユースケースの要件について、専門家の法的助言を求める必要があります。以下のリソースは、背景情報として参考になる可能性があります。
+
+### Know Your Customer (KYC)
+
+KYC(Know Your Customer)とは、金融機関が犯罪行為に利用されるのを防ぐために、顧客の身元を特定し確認するために行うデューデリジェンス活動のことです。金融用語でいう犯罪行為には、マネーロンダリング、テロ資金調達、金融詐欺、個人情報盗難などが含まれます。顧客は、個人、仲介者、企業のいずれもあり得ます。
+
+KYCプロセスは、一般的に次のことを目的としています。
+
+- 顧客(組織や企業の場合は、実質的な所有者)の特定
+
+- 取引関係の目的および意図された事項の理解
+
+- 想定される取引活動の把握
+
+KYCは、金融機関や関連企業にとって、リスク、特に法的リスクや風評リスクを軽減するために重要です。KYCプログラムが不十分であったり、存在しなかったりすると、金融機関や従業員個人に対して民事上・刑事上の罰則が科される可能性があります。
+
+関連項目:
+
+- [(米国）銀行秘密保護法／マネーロンダリング防止審査マニュアル](https://bsaaml.ffiec.gov/manual/Introduction/01)
+
+- [金融活動作業部会(FATF)が定めたKYCに関する米国以外の基準について](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+
+
+
+### マネーロンダリング対策(AML)およびテロ資金供与防止対策(CFT)
+
+マネーロンダリングとは、合法的な金融ルートや信頼できる機関を通じて合法的に資金を入手または分配できるように、資金源、性質、所有者を偽装することによって違法な資金を移動させるプロセスのことです。つまり、「汚いお金」を「きれいなお金」に変えることです。アンチマネーロンダリング（AML）とは、マネーロンダリングの発生を阻止するために設計された法律と手続きを指します。
+
+テロ資金供与とは、テロ活動に従事する組織、またはテロやその拡散を支援する組織に対する資金の勧誘、収集、提供のことを指します。。テロ資金供与防止対策(CFT)とは、テロ資金に使われる資金の流れを特定、報告、阻止するプロセスを指します。
+
+関連項目:
+
+- ["マネーロンダリングとテロリズム・拡散の資金調達との闘いに関する国際基準" FATF、2012年](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+
+- ["仮想通貨： 主要な定義と潜在的なAML/CFTリスク". FATF、2014年](http://www.fatf-gafi.org/publications/methodsandtrends/documents/virtual-currency-definitions-aml-cft-risk.html)
+
+
+
+### 資金源
+
+金融機関は、不正な資金がシステムを通過するのを防ぐために、顧客の資金源が犯罪行為と関連しているかどうかを合理的に判断する必要があります。
+
+すべての顧客の正確な資金源を特定することは、管理上実行不可能な場合があります。その結果、規制当局の中には、すべての口座について特定の規制やガイダンスを提供しない場合もある。しかし、特定の場合には、当局は金融機関に対して資金源を特定し報告することを求めることができる。FATFのガイダンスでは、マネーロンダリングやテロ資金供与のリスクが高い場合(一般に「リスクに応じたアプローチ」と呼ばれる)、金融機関は顧客の資金源を特定することを含むがこれに限定されないデューデリジェンスの強化を行うことを勧告しています。
+
+
+
+### 疑わしい取引の報告
+
+金融機関は、資金が犯罪行為に関連している可能性があると疑われる場合、適切な規制当局に疑わしい取引の届出/Suspicious Activity Report (SAR)を提出する必要があります。疑わしい取引を報告しなかった場合、金融機関は罰則を受ける可能性があります。
+
+関連項目:
+
+- [不審行為報告書の概要(米国FFIEC)](https://bsaaml.ffiec.gov/manual/RegulatoryRequirements/04_ep)
+
+- [FATF勧告16：不審な取引の報告およびコンプライアンス](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+
+### トラベルルール
+
+トラベルルールとは、銀行機密保護法(BSA)に基づき、資金送金が米ドル換算で3,000ドル以上の場合、資金送金を行う金融機関に特定の情報を次の金融機関に転送することを義務付けるルールです。送金指示書には、以下の情報を記載する必要があります。
+
+- 送信者の氏名
+- 送信者の口座番号(使用する場合)
+- 送信者の住所
+- 送金者の金融機関の名称
+- 送信指示の金額
+- 送金注文の金額、送金注文の実行日
+- 受取人の金融機関の名称
+
+
+
+関連項目:
+
+- [ファンドの「トラベル」規制について： 質問と回答](https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers)
+
+### 手数料の開示と資金の追跡
+
+- 米国では、Dodd Frank 1073 Electronic Fund Transfer Act (Regulation E)により、銀行は米国発の国際決済について、為替レート、手数料、外国の指定受取人が受け取る金額など、コストと配送条件に関する情報を提供することが義務付けられています。「Pre-payment disclosure」は国際電子決済を依頼する際に消費者に提供され、「Receiption disclosure」は消費者が送金を許可する際に消費者に提供されます。
+
+    関連項目
+
+    - [消費者金融保護局の説明による、銀行に対する規制とその適用範囲について](https://www.consumerfinance.gov/rules-policy/final-rules/electronic-fund-transfers-regulation-e/#rule)
+
+- 欧州連合(EU)では、EU資金移動規制により、マネーロンダリングやテロ資金供与を検知、調査、防止するために、送金元の銀行、受取人の銀行、仲介銀行がトランザクションの詳細に支払人と受取人の特定の情報を含めることが義務付けられています。
+
+    関連項目:
+
+    - [EU規則(EC) No 1781/2006の説明](http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:345:0001:0009:EN:PDF)
+
+    - [2017年6月26日より施行 資金移動に付随する情報に関する規則2015/847号](http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32015R0847)
+
+### 外国資産管理局(OFAC)
+
+外国資産管理局(OFAC)は、米国財務省の機関であり、米国の外交政策および国家安全保障上の目的を支援するために、経済制裁および貿易制裁を管理・執行しています。すべての米国人、米国法人およびその海外支店は、OFACの規制に従う必要があります。OFACの規制では、米国の金融機関は、OFACの許可または法令による明示的な除外がない限り、OFACが管理・執行する制裁または禁輸プログラム下の個人、団体、または国との取引およびその他の取引を行うことが禁止されています。
+
+関連項目:
+
+- [OFAC関連資料の一覧](https://www.treasury.gov/resource-center/faqs/Sanctions/Pages/ques_index.aspx)
+
+
+
+### 暗号資産・マネーサービス事業に関する指針
+
+- 米国:
+
+    - [仮想通貨に関するFinCENのガイダンスと定義(2013年3月18日付)](https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-persons-administering)
+
+    - [FinCEN、仮想通貨のマイナーと投資家に関する2つの裁定を発表 2014年1月30日](https://www.fincen.gov/news/news-releases/fincen-publishes-two-rulings-virtual-currency-miners-and-investors)
+
+- ヨーロッパ:
+
+    - [仮想通貨に関する欧州銀行監督機構意見書(2014年7月4日付)](http://www.eba.europa.eu/documents/10180/657547/EBA-Op-2014-08+Opinion+on+Virtual+Currencies.pdf)
+
+- FATFの金融事業者向けガイダンス:
+
+    - [金融活動作業部会、2009年7月](http://www.fatf-gafi.org/media/fatf/documents/reports/Guidance-RBA-money-value-transfer-services.pdf)
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/configuration.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/configuration.md
@@ -0,0 +1,101 @@
+---
+html: stablecoin-configuration.html
+parent: stablecoins.html
+seo:
+    description: ステーブルコインの設定を行い、ステーブルコインの機能を詳細に調整します。
+labels:
+  - トークン
+---
+# ステーブルコイン発行者の設定
+
+トークンの発行を始める前に、XRP Ledgerアカウントで設定する必要がある項目がいくつかあります。これらの設定の例については、[代替可能トークンの発行](../../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md)をご覧ください。
+
+設定すべき項目は以下の通りです。
+
+
+| 設定                   | 備考 |
+|-----------------------|------|
+| Default Ripple        | 発行者は、このフィールドを**必ず**有効にする必要があります。 |
+| Deposit Authorization | 明示的に承認していないユーザからの入金をすべてブロックします。 |
+| Require Auth          | トークンの保持を、明示的に承認したユーザに限定します。 |
+| Tick Size             | 分散型取引所の取引所為替レートを四捨五入して、より迅速な価格決定を可能にします。 |
+| Transfer Fee          | ユーザ同士がトークンを送信する際に、一定割合の手数料を徴収します。 |
+
+
+## Default Ripple
+
+Default Rippleフラグは、トラストラインの残高をデフォルトで[Ripplingを許可](../rippling.md)するかどうかを制御します。Ripplingは顧客同士のトークンの送信や取引を可能にするものなので、発行者はその発行アドレスへのすべてのトラストラインでのRipplingを許可しなければなりません(MUST)。
+
+顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行者はそのアドレスのDefault Rippleフラグを有効にする必要があります。そうでない場合、発行者は、他のアドレスが作成した各トラストラインのNo Rippleフラグを個別に無効化する必要があります。
+
+運用ウォレットやスタンバイウォレットなど、他のアドレスではDefault Rippleフラグを有効にすべきではありません。
+
+
+## Deposit Authorization
+
+Deposit Authorizationの設定は、以下のいずれかを行わない限り、アカウントへのすべての入金をブロックします。
+
+- 事前に送信者を認可している。
+- 資金を受け取るためにトランザクションを送信します。例えば、他人が作成したエスクローを終了させるなど。
+
+Deposit Authorizationは、不要なXRPの支払いをブロックするのに最も有効です。なぜなら、発行元へのトラストラインを作成しない限り、既にトークンを受け取ることはできないからです。しかし、ステーブルコインの発行者としては、ステーブルコインをレジャー外の価値と交換するために、ユーザからの支払いを受け取ることができる必要があります。顧客を事前認可することはできますが、そうすると、顧客それぞれのアドレスについてレジャーにオブジェクトを格納する必要があり、準備金が大幅に増加します。
+
+したがって、未知または制裁を受けたエンティティからお金を受け取ることに関する規制要件を満たすために必要でない限り、Deposit Authorizationはステーブルコインの発行者に推奨されません。
+
+より詳細な情報は[Deposit Authorization](../../../accounts/depositauth.md)をご覧ください。
+
+
+## Disallow Incoming Trust Line
+
+Disallow Incoming Trust Lineの設定は、他のユーザがアドレスにトラストラインを開くことを防ぎます。予防措置として、運用アドレスと待機アドレスでこの設定を有効にすることで、誤ってこれらのアカウントからトークンを発行できないようにします。発行アドレスではこの設定を有効にしないでください。
+
+この設定を有効にするには、[AccountSetトランザクション](../../../../references/protocol/transactions/types/accountset.md)で`"SetFlag"： 15` (`asfDisallowIncomingTrustline`)を設定します。
+
+
+## Disallow XRP
+
+Disallow XRPの設定は、XRP Ledgerのユーザが誤ってXRPをアドレスに送信することを阻止するために設計されています。これは、XRPの受信と保持を意図していないアドレスからの不必要な返金コストと労力を削減するものです。なぜなら、そうすることでアドレスがXRPを誤って送金した場合に返金されずにXRPを失う可能性があるからです。クライアントアプリケーションは、デフォルトでDisallow XRPフラグを尊重すべきですが、ユーザがそれを無視することを許可する場合もあります。
+
+DisallowXRPフラグは任意ですが、もしあなたが顧客からXRPを受け取るつもりがないのであれば、発行アドレスとすべての運用アドレスでこのフラグを有効にしておくとよいでしょう。
+
+
+## Require Auth
+
+Require Authの設定は、事前にトラストラインを明示的に承認しない限り、発行したトークンをユーザが保持することをブロックします。XRP Ledger内で誰があなたのトークンを保持するかが重要である場合、規制要件を満たすためにこの設定を使用することができます。しかし、この設定は、ユーザへの承認がトークンを使用するためのボトルネックとなるため、トークンの利便性を低下させる可能性があります。
+
+また、トラストラインを認可するたびに発行アドレスを使用する必要があります。多くのトラストラインを認可する必要がある場合、発行アドレスを頻繁に使用することになるため、発行アドレスのセキュリティが損なわれる可能性があります。(発行アドレスの使用頻度が少ない場合は、秘密鍵の保護を強化することができます。使用頻度が高ければ高いほど、その保護は大きな負担となります)。
+
+詳しくは[認可トラストライン](../authorized-trust-lines.md)をご覧ください。
+
+
+## Tick Size
+
+Tick Sizeは、[分散型取引所](../../decentralized-exchange/index.md)で為替レートを計算する際に使用する小数点以下の桁数を制御する設定です。Tick Sizeを大きくすると、より精度が高くなり、さまざまな取引の金額で丸め込みが少なくなります。取引は主に取引レートに基づいてランク付けされるため、トレーダーがリストの上位にわずかな金額を提供することができるため、精度が高すぎると不都合になることがあります。Tick Sizeを小さくすると、オークションの最低入札額と同じような効果があり、無関係な小額を徐々に入札する時間と労力が省けます。しかし、Tick Sizeを小さくすると四捨五入が多くなり、取引コストが高くなります。また、四捨五入前は完全に一致するように見えた2つのオファーが、四捨五入後は一致しなくなるという意外な結果になることもあります。
+
+Tick Sizeはアカウントレベルの設定であり、同じアドレスで発行されたすべてのトークンに適用されます。
+
+Tick Sizeは取引レートの精度を制御するだけで、トークン自体の精度を制御するものではありません。ユーザは、トークンの発行者が設定したTick Sizeに関係なく、非常に大きな金額や非常に小さな金額を送ったり保有したりすることができます。
+
+詳しくは[Tick Size](../../decentralized-exchange/ticksize.md)をご覧ください。
+
+
+## Transfer Fees
+
+Transfer Feesは、ユーザ同士がトークンを送金する際に、一定割合の手数料を請求するものです。送金手数料は、トークンを発行したり、発行アドレスで直接トークンを交換したりする場合には適用されません。(ユーザが発行アドレスに送金するときには適用されません。)同じアドレスから複数のトークンを発行する場合、すべてのトークンに対して同じ送金手数料が適用されます。
+
+ユーザが送金手数料が設定されたトークンを送信すると、送信側から送金先金額に加えて送金手数料の金額が引き落とされますが、受信側には送金先金額のみが入金されます。手数料の金額はXRP Ledgerから「消える」のです。ステーブルコインの発行者としては、XRP Ledgerの外にある準備金にそれだけ自己資本が増える、言い換えれば、ユーザが送金手数料を支払うたびに担保として持っておく必要がある金額が減少することを意味します。
+
+プロトコルレベルでは、送金手数料はアカウント設定の`TransferRate`で定義され、これは10億から20億までの整数で指定されます。
+
+詳しくは[送金手数料](../../transfer-fees.md)をご覧ください。
+
+
+### 運用アドレスと待機アドレスによる送金手数料
+
+運用アドレスや待機アドレスを含むすべてのXRP Ledgerアドレスは、トークンを送信する際に発行者の送金手数料がかかります。送金手数料をゼロ以外に設定した場合、運用アドレスや待機アドレスから支払いを行う際に、(送金手数料を支払うために)余分に送金しなければなりません。つまり、これらのアドレスは、支払いを行うたびに、あなたの発行アドレスが作った残高を少し返金する必要があります。
+
+トランザクションパラメータ`SendMax`を送信先の`Amount`パラメータよりも`TransferRate`設定に基づく割合で高く設定します。
+
+{% admonition type="info" name="注記" %}発行アドレスから、または発行アドレスへ直接トークンを送信する場合、送金手数料は適用されません。発行アドレスは、常にそのトークンをXRP Ledgerの額面価格で受け入れなければなりません。つまり、顧客が発行アドレスに直接支払いを送る場合は送金手数料を支払う必要はありませんが、運用アドレスに送る場合は支払う必要があります。両方のアドレスで支払いを受け付ける場合、顧客が運用アドレスに支払いを送る際に、顧客が支払う送金手数料を補うために、記録システムで顧客に入金する金額を調整する必要がある場合があります。{% /admonition %}
+
+例えば、次のようなものです。ACMEが送金手数料を1％に設定した場合、顧客のアドレスからACMEの発行アドレスに5 EUR.ACMEを届けるためのXRP Ledger支払いは、ちょうど5 EUR.ACMEの費用がかかります。しかし、顧客は5 EUR.ACMEをACMEの運用アドレスに届けるために、5.05 EUR.ACMEを送る必要があります。ACMEの運用アドレスへの支払いを顧客に入金する際、ACMEは運用アドレスに届けられた金額と送金手数料を顧客に入金し、顧客はACMEのシステムで5.05ユーロを受け取ることができます。
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/index.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/index.md
@@ -0,0 +1,38 @@
+---
+html: stablecoins.html
+parent: trust-lines-and-issuing.html
+seo:
+    description: XRP Ledger上で取引される一般的なステーブルコインには5種類あります。
+labels:
+  - XRP
+  - ステーブルコイン
+---
+# ステーブルコイン
+
+ステーブルコインは、XRP Ledgerの外の資産の価値を保持し、レジャー上の同等の価値を表すトークンを発行します。この種類の発行者は、そのサービスを通じてXRP Ledgerの内外に通貨を移動させることができるため、 _ゲートウェイ_ と呼ばれることがあります。もしトークンの裏付けとなる資産が、レジャー上のトークンと同じ金額と額面であれば、そのトークンは"ステーブルコイン"とみなすことができます。
+
+ステーブルコインの発行者は、トークンをXRP Ledgerの外の世界の実際の通貨や資産と交換するために、_入金_ と _出金_ の機能を提供する必要があります。
+
+実際には、XRP Ledgerはコンピュータシステムであり、それ自身の外部にルールを強制することはできないため、XRP Ledger上のステーブルコインはその発行者に依存しています。もしあなたが、そのステーブルコインの発行者があなたのトークンを要求に応じて本物と交換してくれることを期待できないのであれば、そのステーブルコインがその価値を維持することを期待すべきではありません。ユーザとしては、トークンを発行しているのが誰なのか、信頼性があり、合法的で、支払能力があるのか、に気を配る必要があります。そうでない場合は、そのトークンを保有しない方がよいでしょう。
+
+XRP Ledgerで取引される通貨トークンには、一般的に5つの種類があります。
+
+## 法定通貨による担保
+
+法定通貨を担保とするステーブルコインは、EUR、USD、YENなどの既存の通貨に基づいています。取引レートは1:1です。これはシンプルで安定したオプションですが、中央集権的でハッキングの影響を受けやすいという欠点があります。最も厳密な「ステーブルコイン」の定義では、100%法定通貨で担保されたトークンのみが対象となります。
+
+## 暗号資産による担保
+
+暗号通貨を担保とするステーブルコインは、フィアット担保のステーブルコインと似ていますが、一定額の暗号通貨を担保として準備します。非中央集権的で、カストディアンや監査、規制を必要としません。また、ボラティリティが高く、基礎となる暗号通貨の安定性に依存します。
+
+## コモディティによる担保
+
+コモディティを担保とするステーブルコインは、金、不動産、石油、電力などの交換可能な資産に基づいています。コモディティは比較的安定していて流動性がありますが、中央集権的で、その価値を確認するために定期的な監査が必要です。
+
+## 金融商品による担保
+
+ステーブルコインは、債券や株式などの金融商品で裏付けすることができます。
+
+## 担保なし
+
+非担保トークンは、トークンの供給や売却をアルゴリズム生成スマートコントラクトに依存し、中央銀行が通貨を印刷・破棄するアプローチに似ています。トークンの発行に担保は必要ありません。価値は、価格を安定させるアルゴリズムを通じて需要と供給によって制御されます。非担保トークンはボラティリティが高いため、一般的にステーブルコインとはみなされません。
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/precautions.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/precautions.md
@@ -0,0 +1,55 @@
+---
+html: stablecoin-precautions.html
+parent: stablecoins.html
+seo:
+    description: XRPLでステーブルコイン資金の入出金時の注意点を説明します。
+labels:
+  - トークン
+---
+# ステーブルコインに関する注意事項
+
+XRP Ledgerとの間の決済処理には当然リスクが伴いますので、発行者はこれらの処理を実施する際に十分な注意を払う必要があります。ステーブルコインの発行者としては、以下の注意点を考慮する必要があります。
+
+
+## インフラストラクチャ
+
+あなた自身のセキュリティとネットワークの安定性のために、XRP Ledgerを利用する事業者は、1つの[バリデータ](../../../networks-and-servers/rippled-server-modes.md#validators)を含む[独自のXRP Ledgerサーバ](../../../../infrastructure/installation/index.md)を実行すべきです。
+
+
+## ツールのセキュリティ
+
+XRP Ledgerのトランザクションを送信する際には、秘密鍵を使って署名する必要があります。秘密鍵は、あなたのXRP Ledgerアドレスを完全にコントロールします。秘密鍵を他人が運営するサーバに決して送らないでください。自身のサーバを使うか、クライアントライブラリを使ってローカルでトランザクションに署名してください。安全な設定の手順と例については、[安全な署名の設定](../../../transactions/secure-signing.md)をご覧ください。
+
+XRP Ledgerへの接続方法は、ニーズや既存のソフトウェアに応じて、いくつかのインターフェイスを使用することができます。
+
+- [HTTP / WebSocket API](../../../../references/http-websocket-apis/index.md)は、XRP Ledgerのすべてのコア機能への低レベルのインターフェースとして使用することができます。
+- [クライアントライブラリ](../../../../references/client-libraries.md)は、いくつかのプログラミング言語で利用でき、XRP Ledgerにアクセスするための便利なユーティリティを提供します。
+- その他、[xApps](https://xumm.readme.io/docs/xapps)などのツールも利用可能です。
+- サードパーティのウォレットアプリケーションも、特に待機アドレスの担当者には便利かもしれません。
+
+ただし、公式な配布チャネルから信頼できるツールだけを使用するように注意してください。悪意のあるサーバ、ライブラリ、アプリは、攻撃者に秘密鍵を漏らすように設定されている可能性があります。
+
+
+## XRP Ledgerからの送金
+
+XRP Ledgerから送金を受ける際、プロセスや統合ソフトウェアが悪用されることのないよう、いつ送金が確定したかを把握し、正しい金額を顧客にクレジットすることが重要です。詳細とよくある落とし穴については、[入金のモニタリング](../../../payment-types/robustly-monitoring-for-payments.md)をご覧ください。
+
+予期しない、または不要な支払いを受け取った場合の標準的な対応は、送信者にそれを返却することです。追加費用を発生させずにこれを行う方法の詳細については、[不明な入金の返金](../../../payment-types/bouncing-payments.md)をご覧ください。
+
+XRP Ledgerからの支払いを処理する前に、顧客の身元を確認してください。そうすることで、匿名の攻撃者による詐欺が難しくなります。ほとんどのマネーロンダリング対策規制は、いずれにせよこの確認を要求しています。XRP Ledgerから送金するユーザは、XRP Ledgerで最初にお金を受け取ったユーザとは異なる可能性があるため、これは特に重要です。詳しくは、[ステーブルコインのコンプライアンス指針](compliance-guidelines.md)をご覧ください。
+
+
+## XRP Ledgerへの送金
+
+XRP Ledgerに送金を行う際には、手数料の過払いや迂回経路を避けるため、ベストプラクティスに従ってください。詳しくは[顧客への送金](../../../payment-types/sending-payments-to-customers.md)をご覧ください。
+
+銀行預金やクレジット/デビット決済など、外部システムからの支払いを受け入れる場合は、可逆的な入金に注意してください。XRP Ledgerの支払いは不可逆ですが、他の多くのデジタル支払いはそうではありません。詐欺師はこれを悪用し、あなたがすでにXRP Ledgerの支払いを送った後に、XRPL以外の取引をキャンセルすることで、元金を取り戻すことができます。
+
+さらに、停電やネットワーク停止のようなまれな状況でも、XRP Ledgerのトランザクションの最終結果を確実に知ることができるように、[信頼できるトランザクションの送信](../../../transactions/reliable-transaction-submission.md)に従ってください。
+
+
+## その他の注意事項
+
+- XRP Ledger内の債務と残高を追跡し、担保口座の資産と比較してください。両者が一致しない場合は、不一致を解決するまで引き出しと入金の処理を停止してください。
+- 曖昧な状況を避けてください。すべてのアドレスで適切な設定を行うことで、誤って間違ったアドレスからトークンを発行したり、ユーザが間違った場所に送金したりするようなケースを避けることができます。推奨事項については、[ステーブルコインの設定](configuration.md)をご覧ください。
+- 疑わしい行動や不正な行動を監視します。例えば、ユーザがXRP Ledgerに繰り返し資金を出し入れすることで、実質的に運用アドレスの残高を空にするサービス拒否攻撃が可能です。XRP Ledgerの支払いを処理しないことで、そのアドレスが疑わしい行動に関与している顧客を一時停止します。
--- a/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/settings.md
+++ b/@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/settings.md
@@ -0,0 +1,101 @@
+---
+html: stablecoin-settings.html
+parent: stablecoins.html
+seo:
+    description: Settings to configure before issuing your stablecoin.
+labels:
+  - XRP
+  - ステーブルコイン
+---
+# ステーブルコインの設定
+
+新しいステーブルコインを発行する前に、最初にコインを発行すると変更不可能とする設定を行う必要があります。
+
+## 発行および配布アカウントの作成
+
+「コールド」ウォレットと呼ばれることもある、「発行者」として指定する新しいアカウントを作成します。アカウント自体には特別な違いはありません。このアカウントを使ってステーブルコインを発行します。
+
+ほとんどの実装では、"ウォーム"ウォレットとしてスタンバイアカウントを使用します。信頼できる人間のオペレータは、スタンバイアカウントを使用してステーブルコインを運用アカウントに配布します。
+
+<div align="center">
+<img src="img/uc-stablecoin-distribution-flow.png" height="50%" width="50%"></image>
+</div>
+
+運用アカウント、または「ホット」ウォレットは、XRPL上で他のアカウントと取引します。自動化されたインターネット接続システムは、これらのアドレスの秘密鍵を使用して、顧客やパートナーへの送金などの日常業務を行います。
+
+スタンバイアカウントと運用アカウントを使用することで、発行アカウントをハッキング攻撃から守ることができ、またステーブルコインの作成と破棄を監視しやすくなります。
+
+
+## 取引手数料の設定
+
+送金手数料の設定は、アカウント間でトークンを送金する際にパーセンテージの手数料をユーザに請求します。
+
+ユーザが送金手数料ありのトークンを送信すると、送信側からは送信金額に加えて送金手数料が引き落とされ、受信側には送信金額のみが入金されます。送金手数料の金額はXRP Ledgerから「消滅」します。つまり、ユーザが送金手数料を支払うたびに、担保として保持する必要のある金額が減少するのです。
+
+詳しくは[送金手数料](../../transfer-fees.md)をご覧ください。
+
+
+## ティックサイズの設定
+
+ティックサイズは、[分散型取引所](../../decentralized-exchange/index.md)で取引レートを計算する際に使用される小数点以下の桁数を制御します。ティックサイズが大きいほど(小数点以下の桁数が多いほど)精度が高くなり、さまざまな取引金額の四捨五入が少なくなります。ティックサイズが小さいほど、オークションにおける最低入札額と同じように機能し、無駄に小さい金額で徐々に価格を競り上げる時間と労力を節約できます。
+
+ティックサイズはアカウントレベルの設定で、同じアドレスで発行されたすべてのトークンに適用されます。
+
+[ティックサイズ](../../decentralized-exchange/ticksize.md)をご覧ください。
+
+
+## Default Rippleフラグの設定
+
+Default Rippleフラグはトラストラインの残高をデフォルトでRipple(波及)させるかどうかを制御します。Ripplingは顧客間でトークンを送ったり取引したりすることを可能にするものです。発行者はその発行アドレスへの全てのトラストラインでRipplingを許可しなければなりません(MUST)。
+
+顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行アドレスのDefault Rippleフラグを有効にしてください。そうでない場合は、他のアドレスが作成したトラストラインごとに、個別にNo Rippleフラグを無効にする必要があります。
+
+[Rippling](../rippling.md)をご覧ください。
+
+
+## 宛先タグの有効化
+
+ステーブルコインのアプリケーションが複数の顧客の代わりにトランザクションを処理する場合、どのアカウントに入金すべきかがわからないことがあります。宛先タグは、送金者に受取人や送金先を指定させることで、このような状況を回避するのに役立ちます。RequireDestフラグを有効にするには、`AccountSet`トランザクションの`SetFlag`フィールドに`asfRequireDest`値(1)を設定してください。
+
+[送信元と送信先のタグ](../../../transactions/source-and-destination-tags.md)をご覧ください。
+
+## 資産の管理機能
+
+ステーブルコインの作成と配布をコントロールするには、いくつかのオプションがあります。
+
+
+### 認可トラストライン
+
+KYC(Know Your Customer)やAML(Anti-Money Laundering)などのコンプライアンスルールに従う必要がある場合、トラストラインを使用して、ステーブルコインの配布を許可されたプールを作成することができます。これにより、資金が誰に送金されるかを確認することができます。
+
+[認可トラストライン](../authorized-trust-lines.md)をご覧ください。
+
+
+### Freezeフラグ
+
+保有者アカウント内のステーブルコインを凍結することができます。これは、詐欺行為が疑われる場合、または保有を強制する場合に行うことができます。個々のトラストラインを凍結することも、グローバルに凍結することもできます。
+
+逆に、トークンを凍結する能力を永久に放棄する「No Freeze」を設定することもできます。これにより、発行者がトークン同士の取引を妨害でき無くなるという意味で、そのステーブルコインはより現実の通貨に近くなります。
+
+[トークンの凍結](../freezes.md)をご覧ください。
+
+
+### Clawbackフラグ
+
+_([Clawback amendment](/resources/known-amendments.md#clawback) が必要です。)_
+
+Clawbackにより、特定の状況下でトラストラインからステーブルコインを回収(クローバック)することができます。これにより、アカウントへのアクセス不能や悪意のある活動などの課題に対応する能力が追加されます。
+
+[Clawback](../../../../references/protocol/transactions/types/clawback.md)をご覧ください。
+
+
+### 固定供給量
+
+ステーブルコインを固定枚数に制限することで、将来さらにトークンを発行することになっても、ステーブルコインの価値が希釈されないことが保証されます。
+
+固定供給とするためには、
+
+1. 発行するウォレットと同様の設定で配布ウォレットを作成します。
+2. 発行ウォレットと配布ウォレットの間にトラストラインを設定します。
+3. 発行ウォレットから配布ウォレットにすべてのトークンを送信します。
+4. 発行アカウントをブラックホール化します。
--- a/@l10n/ja/docs/concepts/tokens/index.md
+++ b/@l10n/ja/docs/concepts/tokens/index.md
@@ -0,0 +1,78 @@
+---
+parent: concepts.html
+html: tokens.html
+seo:
+    description: XRP Ledger上でデジタルな価値を表すトークンを作成することができます。
+labels:
+  - トークン
+---
+# トークン
+
+XRP以外のすべての資産は、XRP Ledgerでは **トークン** として扱うことができます。通常のトークンは、アカウント間の[トラストライン](fungible-tokens/index.md) と呼ばれる関係で管理されます。すべてのアカウントは、トークンを保有することを許可する他のアカウントにはトークンを発行できますが、トークンを必要としないアカウントに一方的にトークンを配付することはできません。トークンは、台帳の外に存在する資産に裏付けられた「ステーブルコイン」、XRP Ledger上で独自に作成された純粋なデジタルトークン、コミュニティクレジットなど、様々な種類の価値を表すことが出来ます。
+
+{% admonition type="info" name="注記" %}XRP Ledger上のトークンは、過去に「IOUs」（[I-owe-you](https://en.wikipedia.org/wiki/IOU)の略）および「発行済み通貨」とも呼ばれてきました。しかし、これらの呼称は、XRP Ledgerのトークンが表すことのできるデジタル資産の全範囲をカバーしていないため、望ましくないとされています。<!-- STYLE_OVERRIDE: ious -->{% /admonition %}
+
+通常のトークンは代替可能です。つまり、同じトークンはすべて代替可能であり、区別がつきません。非代替トークン(NFT)も可能です。XRP Ledgerでのネイティブ対応の詳細については、[非代替トークン(NFT)](nfts/index.md)をご覧ください。
+
+トークンは[クロスカレンシー支払い](../payment-types/cross-currency-payments.md)に使用でき、[分散型取引所(DEX)](decentralized-exchange/index.md)で取引することができます。
+
+トラストラインの残高は、どちら側から見るかによって、プラスまたはマイナスで表されます。マイナスの残高を持つ側は「発行者」と呼ばれ、そのトークンに関するいくつかの機能を設定することができます。発行者ではない別のアカウントにトークンを送ると、それらのトークンは発行者、場合によっては同じ通貨コードを使用している他のアカウントに「ripple」します。これは便利な場合もありますが、想定外の挙動を引き起こす可能性もあります。トラストラインに[No Ripple flag](fungible-tokens/rippling.md)を使用すると、トラストラインがripplingしないように設定することができます。
+
+## ステーブルコイン
+
+XRP Ledger におけるトークンの代表的なモデルとして、発行者が XRP Ledgerの外部に価値ある資産を保有し、その価値を表すトークンをLedger上で発行するというものがあります。このタイプの発行者は、そのサービスを通じてXRP Ledgerに通貨を送受信できることから、 _ゲートウェイ_ と呼ばれることもあります。トークンの裏付けとなる資産が、台帳上のトークンと同じ金額と額面を使用している場合、そのトークンは「ステーブルコイン」といえるでしょう。なぜなら、そのトークンと台帳外の資産との交換レートは理論上1：1で安定するはずだからです。
+
+ステーブルコインの発行者は、XRP Ledgerの外側において、トークンを実際の通貨や資産と交換するための _入金_ と _出金_ のサービスを提供する必要があります。
+
+実際には、XRP Ledger はただのシステムであり、その外側にいかなるルールも適用することはできません。そのため、XRP Ledger上のステーブルコインは、その発行者を信頼し、その発行者が要求に応じてトークンを現物資産へ交換することができなければ、そのステーブルコインの価値が維持されないと考えるべきでしょう。ユーザは、誰がトークンを発行しているのか、信頼できるのか、合法的なのか、支払能力があるのか、という点について十分に注意をしなければなりません。信頼できない場合は、そのトークンを保有するべきではないでしょう。
+
+[Stablecoin Issuer](../../use-cases/tokenization/stablecoin-issuer.md)をご覧ください。
+
+## コミュニティクレジット
+
+XRP Ledgerのもう一つの利用方法として、「コミュニティクレジット」という、知人同士がXRP Ledgerを利用して、誰が誰にいくら借金があるのかを把握する仕組みがあります。この借金を自動的かつアトミックに活用し、[rippling](fungible-tokens/rippling.md)を通じて支払いを決済できるのが、XRP Ledgerの優れた機能です。
+
+例えば、AsheeshがMarcusに20ドル、MarcusがBharathに50ドルの借金がある場合、BharathはAsheeshのMarcusに対する借金を帳消しにする代わりに、その分のMarcusに対する借金を帳消しすることによってAsheeshに20ドルを「支払う」ことができる。逆もまた可能である。AsheeshはMarcusを通してBharathに支払うことで、それぞれの負債を減らすことができるのです。XRP Ledgerは、このように複雑な連鎖的な取引を、中間にいるアカウントが何もせずとも、単一の取引で決済することができるのです。
+
+このタイプの使用法については、[paths](fungible-tokens/paths.md)をご覧ください。<!--{# TODO: コミュニティクレジットのもっと例示的なページへのリンクができるといいですね。#}-->
+
+## その他のトークン
+
+XRP Ledgerで発行されるトークンには、その他にも使用例があります。例えば、セカンダリアドレスに一定数量の通貨を発行し、発行者に「キーを渡す」ことで、「ICO（Initial Coin Offering）」を行うことができます。
+
+{% admonition type="danger" name="警告" %}ICOは米国では[証券と見なされ、規制対象となる](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings)可能性があります。{% /admonition %}
+
+金融サービスビジネスを始める前に、関連規制を調査されることを強くお勧めします。
+
+## トークンの特性
+
+XRP Ledgerにおけるトークンは、[XRPと異なる性質](../../references/protocol/data-types/currency-formats.md#comparison)を持ちます。トークンは常に _トラストライン内_ に存在し、トークンのすべての移動はトラストラインに沿って行われます。他のアカウントに、トラストラインに設定された上限を超えるトークンを保有させることはできません。(自分のトラストラインを制限以上に増やすことは _可能_ です。例えば、[分散型取引所](decentralized-exchange/index.md)でさらに購入したり、すでにプラスの残高がある状態で上限値を下げたりすることができます。)
+
+トークンは、精度が15桁の10進数（基数10）と指数を用いて、非常に大きな値（最大9999999999999999×10<sup>80</sup>）から、非常に小さな値（最小1.0×10<sup>-81</sup>まで）を表現することができます。
+
+必要なトラストラインが設定されていれば、誰でも[Paymentトランザクション][]を送信することでトークンを発行することができます。トークンを発行者に送り返せば、トークンを「burn」することができます。また、発行者の設定により、[クロスカレンシー支払い](../payment-types/cross-currency-payments.md)やトレードでトークンをさらに生み出せるケースもあります。
+
+発行者は、ユーザがトークンを送金する際に自動で差し引かれる「送金手数料」(transfer-fees.html)を設定することができます。発行者は、自分のトークンを含む取引レートの[ティックサイズ](decentralized-exchange/ticksize.md)を定義することもできます。発行者と一般アカウントのどちらも、トラストラインを[凍結](fungible-tokens/freezes.md)することができ、トラストライン内のトークンの使用方法を制限することができます。( XRPにはこのいずれも適用されません。)
+
+トークン発行の技術的な手順については、[代替可能トークンの発行](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) をご覧ください。
+
+## 関連項目
+
+- **コンセプト:**
+  - [XRP?](../../introduction/what-is-xrp.md)
+  - [クロスカレンシー支払い](../payment-types/cross-currency-payments.md)
+  - [分散型取引所](decentralized-exchange/index.md)
+- **チュートリアル:**
+  - [代替可能トークンの発行](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md)
+  - [XRP Ledgerゲートウェイの開設](../../use-cases/tokenization/stablecoin-issuer.md)
+  - [トランザクションの結果の確認](../transactions/finality-of-results/look-up-transaction-results.md)
+  - [専門化した支払いタイプの使用](../../tutorials/how-tos/use-specialized-payment-types/index.md)
+- **リファレンス:**
+  - [Paymentトランザクション][]
+  - [TrustSetトランザクション][]
+  - [RippleStateオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)
+  - [account_linesメソッド][]
+  - [account_currenciesメソッド][]
+  - [gateway_balancesメソッド][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/tokens/nfts/authorizing-another-minter.md
+++ b/@l10n/ja/docs/concepts/tokens/nfts/authorizing-another-minter.md
@@ -0,0 +1,58 @@
+---
+html: nftoken-authorized-minting.html
+parent: non-fungible-tokens.html
+seo:
+    description: NFTのMintを他のアカウントに代行してもらうことができます。
+labels:
+ - 非代替性トークン, NFT
+---
+# NFT処理を他のアカウントに委任
+
+各アカウントは、自分に代わってNFTをMintすることができる認可されたMinterを最大一人設定することができまます。認可Minter機能を利用することで、クリエイターは別のアカウントにNFTをMintさせることができ、より多くのNFTを作ることに集中することができます。
+
+## 認可Minterの割り当て
+
+認可Minterを`AccountSet`トランザクションで設定します。
+
+```js
+tx_json = {
+  "TransactionType": "AccountSet",
+  "Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
+  "NFTokenMinter": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
+  "SetFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
+}
+```
+
+`NFTokenMinter` 同じXRP Ledgerインスタンス上のアカウントのIDです。`asfAuthorizedNFTokenMinter`フラグは`NFTokenMinter`に指定するアカウントが`Account`の代理としてNFTをMintすることを許可します。
+
+*注記*: `asfAuthorizedNFTokenMinter`フラグは`AccountSet`トランザクションでのみ使用されます。これは、トランザクションがAccountRoot上のNFTokenMinterフィールドの存在または値に影響を与えるかどうかを示します。実際、AccountRootには対応するフラグはありません。
+
+## 認可Minterの割り当て解除
+
+認可Minterを削除するには、`AccountSet`トランザクションを使用して、`asfAuthorizedNFTokenMinter`フラグをクリアしてください。
+
+```js
+tx_json = {
+  "TransactionType": "AccountSet",
+  "Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
+  "ClearFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
+}
+```
+
+## 他のアカウントのNFTをMintする
+
+標準的な `NFTokenMint` トランザクションを使用して、別のアカウントのNFTをMintすることができます。違いは、`Issuer`フィールド、つまりNFTをMintするアカウントのIDを含める必要があることです。
+
+```js
+const transactionBlob = {
+  "TransactionType": "NFTokenMint",
+  "Account": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
+  "URI": xrpl.convertStringToHex("ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"),
+  "Flags": 8,
+  "TransferFee": 5000,
+  "NFTokenTaxon": 0,
+  "Issuer": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m", // 別アカウントでMintする際に必要
+}
+```
+
+NFTの所有者がNFTを売却した場合、取引手数料（売却額に対する割合）が`Issuer`に指定したアカウントに送金されまれます。
--- a/@l10n/ja/docs/concepts/tokens/nfts/batch-minting.md
+++ b/@l10n/ja/docs/concepts/tokens/nfts/batch-minting.md
@@ -0,0 +1,40 @@
+---
+html: nftoken-batch-minting.html
+parent: non-fungible-tokens.html
+seo:
+    description: NFTokenオブジェクトを一括でMintする。
+labels:
+ - 非代替性トークン, NFT
+---
+
+# NFTのバッチMint
+
+NFTokenオブジェクトを一括でMintする方法には、一般的に、オンデマンドでMintする方法とスクリプトでMintする方法の2つがあります。
+
+## オンデマンドMint (遅延Minting)
+
+オンデマンドMintモデルを使用する場合、発行者または潜在的購入者は、XRP LedgerからNFTokenオブジェクトの初期販売に対して購入または売却オファーを出します。初期販売を開始する準備ができたら、トークンをMintして、売却オファーを作成するか、購入オファーを受け入れて、取引を完了させます。
+
+### メリット
+
+* 売れ残りのNFTokenオブジェクトを保有するための準備金が発生しません。
+* 売れると分かった時点でリアルタイムにNFTokenオブジェクトをMintします。 <!-- STYLE_OVERRIDE: will -->
+
+### デメリット
+
+NFTokenオブジェクトの初回販売以前の市場活動は、XRP Ledgerには記録されません。これは、一部のアプリケーションでは問題にならない場合があります。
+
+## スクリプトMinting
+
+プログラムまたはスクリプトを使用して、一度に多数のトークンをMintします。[チケット](../../accounts/tickets.md)を使えば、1度に200件までのトランザクションを並行して処理することができます。
+
+実用例としては、チュートリアルの[JavaScriptでNFTをバッチMint](../../../tutorials/javascript/nfts/batch-mint-nfts.md)をご覧ください
+
+### メリット
+
+* NFToken オブジェクトは事前にMintされます。
+* NFTokenオブジェクトの初回販売の市場活動は台帳に記録されます。
+
+### デメリット
+
+NFTokenオブジェクトをMintする際には、[準備金要件](../../accounts/reserves.md)を満たす必要があります。目安としては、現在の準備金レートで、NFTokenオブジェクトあたりおよそ1/12XRPです。十分なXRPがない場合は、XRPが調達できるまで、Mintトランザクションは失敗します。
--- a/@l10n/ja/docs/concepts/tokens/nfts/collections.md
+++ b/@l10n/ja/docs/concepts/tokens/nfts/collections.md
@@ -0,0 +1,17 @@
+---
+html: nft-collections.html
+parent: non-fungible-tokens.html
+seo:
+    description: NFTのTaxonフィールドを使用して、NFTをコレクションとしてミントすることができます。
+labels:
+ - 非代替性トークン, NFT
+---
+# NFTのコレクション化
+
+`NFTokenTaxon`フィールドを使用すると、NFTをコレクションにグループ化することができます。ミント担当者は、`0x0`から`0xFFFFFFF`までの任意の数値を選択し、NFTを作成する際にそれを割り当てることができます。Taxon(分類群)の定義付けは完全に自由です。
+
+例えば、最初のコレクションでは、`NFTokenTaxon`を`1`に設定します。NFTのコレクションで、Taxonの値が`316`、`420`、`911`であるものがあるかもしれません。NFTの種類を示すために、数字で始まるタクソンを使用することもできます（たとえば、すべての不動産NFTは`2`で始まるTaxonを持っているなど）。
+
+`NFTokenTaxon`フィールドは必須ですが、コレクションを作成するつもりがなければ`0`を設定するのもよいでしょう。
+
+[NFTokenの分類群](../../../references/protocol/data-types/nftoken.md#nftokentaxon分類群)をご覧ください。
--- a/@l10n/ja/docs/concepts/tokens/nfts/guaranteeing-a-fixed-supply.md
+++ b/@l10n/ja/docs/concepts/tokens/nfts/guaranteeing-a-fixed-supply.md
@@ -0,0 +1,23 @@
+---
+html: nft-fixed-supply.html
+parent: non-fungible-tokens.html
+seo:
+    description: 新しいアカウントを使って一定数のNFTをミントし、そのアカウントをブラックホール化します。
+labels:
+  - 非代替性トークン, NFT
+---
+# NFTの固定供給
+
+プロジェクトによっては、発行アカウントから一定数以上のNFTがミントされないことを保証したい場合があります。
+
+一定数のNFTを保証するためには、
+
+1. 新しいアカウント、_発行者_ を作成し、資金を提供します。このアカウントは、コレクション内のトークンの発行者となります。[アカウントの作成](../../accounts/index.md#アカウントの作成)をご覧ください。
+1. `AccountSet`を使用して、自分の運用するウォレットを発行者の認可Minterとして割り当てます。[代理Mint](authorizing-another-minter.md)をご覧ください。
+1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[Mintのバッチ処理](batch-minting.md)をご覧ください
+1. 発行者の認可Minterである自分の運用するウォレットを削除するために、`AccountSet`を使用します。
+1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](../../../tutorials/how-tos/manage-account-settings/disable-master-key-pair.md)をご覧ください。
+
+この時点で、発行者のアドレスを発行アカウントとする新たなトークンのミントは不可能となります。
+
+{% admonition type="warning" name="注意" %}一度、アカウントを「ブラックホール化」すると、あなた自身を含め、誰も将来のNFTの販売に対するロイヤリティを受け取ることができなくなります。{% /admonition %}
--- a/Show More
+++ b/Show More
				`@@ -0,0 +1 @@`
				`_[Clawback amendment](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0039d-clawback)が必要です。_`
				`@@ -0,0 +1 @@`
				[推奨インストール](../infrastructure/installation/index.md)では、デフォルトで`/etc/opt/ripple/rippled.cfg`という設定ファイルを使用します。その他の場所としては、`$HOME/.config/ripple/rippled.cfg`(`$HOME`は`rippled`を実行しているユーザのホームディレクトリです)、`$HOME/.local/ripple/rippled.cfg`または`rippled`を起動した現在の作業ディレクトリがあります。
				`@@ -0,0 +1 @@`
				`_デフォルトでは、このメソッドは[管理者専用](../references/http-websocket-apis/admin-api-methods/index.md)です。サーバ管理者が[パブリック署名を有効にしている](../infrastructure/configuration/enable-public-signing.md)場合、パブリックメソッドとして使用できます_。`
				`@@ -0,0 +1 @@`
				サーバ起動後の最初の5～15分間に、サーバがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバ起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、ネットワーク接続の信頼性が低いことや、[ハードウェアのスペック](../infrastructure/installation/system-requirements.md)が不十分であることが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）