Information Architecture v3 (#1934)

* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity. * Cancel escrow: fix notes * Add draft of updated cancel-escrow.js. * Update intro to escrows. * Add Escrow Tutorial * Minor corrections * Fix headings, add HTML * Update escrow docs This commit re-creates f205a92db2 with some adjustments: - Omit the accidentally-created dir full of junk - Fix some typos and one mistake in the Escrow limitations section - Add a table to the EscrowCreate ref to clarify valid combos of fields. * Concept info from send-a-time-held-escrow added to escrow.md * IA: Move "Consensus Network" files This re-creates some work from the original commit 56fffe0b9f * Rewrite escrows article (re-created) This commit re-creates relevant work from the following commits: 9a4a588f2b Update escrow.md context info e1b017dc83 Remove references to using escrow for interledger payments. * IA: Move "XRPL servers" files This re-creates some work from original commit 7611979abf * IA: move "production readiness" files. Re-creates work from the following commit: 692438693a Move tutorials to concepts * New intro articles Original commit: 56fffe0b9f * IA: Reorg account concepts Re-creates some work from original commit 56fffe0b9f * IA: reorg transaction concepts Original commits: 9d4eff9940 WIP - reorg accounts 7611979abf WIP dir. reorg * IA: reorg consensus concepts Original commit: 56fffe0b9f * IA: Reorg ledger docs Original commit: 56fffe0b9f - Rephrased some details of the section * IA: rename issuing/operational addresses page Original commit: 56fffe0b9f * Moving use cases * Fleshing out Use Cases Note, the dactyl-config.yml file has not been fully updated. * Clean up checks conceptual info. * Remove redundant checks use case section Original commit: 3c29e9c05e * IA: move Dex under tokens Original commit: d08b3ba7d7 * Touch up stablecoin issuer use case (#1856) * Consolidate stablecoin use case * Stablecoin issuer: cleanup progress through sending * Stablecoin issuer: reorg second half (Note: the dactyl-config.yml is not fully reconciled yet) * Move rippled and clio tutorials into infrastructure * Remove link to checks amendement. * Add note to account_objects.md about commandline interface type field. * Merge expiration case with lifecycle section. * Interoperability Use Cases * Add graphics to intro * Move escrow use cases to dedicated page. * Update use case page intros and corresponding concept info. * Clarify meaning of direct XRP payments. * Intro link updates * Payment use cases * Remove some unnecessary links in transactions section Original commit: e6fcf4a4dc * Link cleanup in Tokens section Original commit: 9588dd5e70 * Touch up 'Configure Peering' section Original commit: fc8f0990b8 * Clean up links in accounts section Original commit: 3da5fde7a8 * Add NFT mkt use case * p2p payments: edits to Wallets * Clean up payments use cases * Refine history description * IA: use case cleanup * IA: reconcile servers, ledgers sections * IA: reconcile payment types, tx, tokens * IA: reconcile accounts section * IA: reconcile infra * IA: Fix most broken links * Full Docs Index: omit from sidebar * IA: fix up most broken links * fix Absolute path link to internal content * Quick updates to Software Ecosystem * Remove some absolute links to internal resources * Fix remaining broken links in JA target * Contributing: tweak formatting * Tutorials: fix some minor issues * remove interop use cases * remove intro image and personal references to dennis * alphabetize-transaction-nav * Remove unused files * Add QS escrow tutorials * IA: move ledgers, consensus protocol files around * IA: update nav for new page hierarchy * reordering of topics under new networks and servers top-nav * Move "Naming" to "What is XRP?" * Update dactyl-config.yml Remove xrp.md from the TOC. * Update list-xrp-as-an-exchange.md Update link to what-is-xrp * Update list-xrp-as-an-exchange.ja.md Change link to what-is-xrp * Update currency-formats.md Change link to what-is-xrp * Update currency-formats.ja.md Change link to what-is-xrp * Update cancel-an-expired-escrow.md Change link to what-is-xrp * Update paymentchannelfund.md Change link to what-is-xml * Update look-up-escrows.md Change link to what-is-xrp * Update tokens.md change link to what-is-xrp * Update use-payment-channels.md * Update send-a-time-held-escrow.md Update link to what-is-xml * fix broken links * Update parallel-networks.md Change link to what-is-xml * Update parallel-networks.ja.md * Update invariant-checking.md Remove link to xrp.html * Update invariant-checking.ja.md Remove link to xrp.html * Update transaction-cost.md Change link to what-is-xrp * Update transaction-cost.ja.md Change link to what-is-xrp * Update send-a-conditionally-held-escrow.md Change link to what-is-xrp * Update stablecoin-issuer.md Change link to what-is-xrp * Update tokens.ja.md Change link to what-is-xml * Update autobridging.ja.md Change link to what-is-xrp * Update currency-formats.md update text * reorganize infrastructure nav section * Update currency-formats.md Try removing link altogether. * Update currency-formats.ja.md Remove link to what-is-xrp.html * move commandline usage topic to infrastructure * initial intro rewrite * minor update to language * IA.v3: rm Production Readiness * Delete xrp.md * Update xrp link in snippet * Add redirect for old xrp.html URL * Small edits to 'What is XRP?' article * Add missing imgs * XRP - copy edit per @DennisDawson * restructure tutorials nav and pages * fix broken links * more broken link fixes * Algo trading: 1st draft * Algo trading: notes on taxes * Algo trading: edits per review * algo trading: fix broken link * Ledger structure: rewrite for accuracy and clarity * Update links to removed 'tree format' header * Ledger Structure: Update diagrams * Re-gen CSS for ledger structure changes * Ledger structure: edits per review * IA.v3: fix broken NFT links introduced by rebase * Desktop Wallet (py): update little stuff * Update some capacity/storage details * contribute doc nav update * fix image link in create diagram page * IAv3: Fix 'Ledgers' blurb * Update full history requirements with details from community members * add reviewer suggestions * Edits per @trippled review * Apply suggestions from peer review Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> * FH: reword file size limit note per review * Update software ecosystem * updates per review * Minor tweaks to graphics * fixTypos * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * [JA] update AccountDelete cost * custom transactors doc * add doc to dactyl config * [JA] fix NonFungibleTokensV1_1 amendment status * [JA] update NFTokenOffer page * Remove old, unused XRP article (#2039) * add reviewer suggestions * Add tooling to check for file/nav consistency - From the repo top, run tool/check_file_consistency.py to look for Markdown files that exist in the "content/" directory but aren't used in the documentation. - New "enforce_filenames" filter prints a warning to console when building, if a file's path and filename don't match expectations based on its place in the nav and top heading. * File consistency checker: correctly handle filenames starting in _ * Remove unused old 'get started' and associated code * Create Resources section & reorg some files - Rename some files/folders based on their place in the nav - Move a bunch of non-documentation stuff, and docs on contributing code and/or docs to the new "Resources" section. - Known issue: nav spills into a second row on page widths between 993px-1110px. To be fixed in a later CSS update, maybe along with making the Resources dropdown multi-column. * Fix #2078 code tab bug CSS not built yet, to reduce merge conflicts. Won't have any effect until that happens. * fix Transaction JSON * [JA] translate contributing contents * fix contributing-to-documentation parent * fix contribute-code blurb * Top nav: add cols for Resources, fix broken links * CSS: fix top nav overflows * Fix broken link from redirect not in JA target * Top nav: add Infra to article types * Update contrib info & rename intro file * [ja] Update link to suggested first page to translate * [ja] fix contribute docs organization * Run private network with docker tutorial (#2065) * [NO-ISSUE] Run private network with docker tutorial Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker. Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it. * Add minor link fixes and Japanese target * Apply suggestions from code review Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Add link to ripple-docker-testnet setup scripts in See Also section * Update repo URL --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * add intro gfx (#2036) * add intro gfx * Move graphic up * Update some graphics with their revised versions * Add updated version of the custodial vs non-custodial graphic --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com> * Update to reflect current UNL publishers * [ja] update contributing Co-authored-by: tequ <git@tequ.dev> * Incorporate feedback on "What is XRP" page. (#2099) * Add trademark info for XRP * Revert section to previous state * Fix broken link (#2101) --------- Co-authored-by: Oliver Eggert <oeggert@ripple.com> Co-authored-by: ddawson <dennis.s.dawson@gmail.com> Co-authored-by: Maria Shodunke <mshodunke@ripple.com> Co-authored-by: tequ <git@tequ.dev> Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: develoQ <develoQ.jp@gmail.com> Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
2025-11-21 04:05:49 +00:00 · 2023-09-01 12:40:18 -07:00
parent 31a068e6ae
commit b51bcb4ea3
445 changed files with 9020 additions and 4411 deletions
--- a/content/references/protocol-reference/data-types/base58-encodings.md
+++ b/content/references/protocol-reference/data-types/base58-encodings.md
@@ -5,7 +5,7 @@ blurb: Formats for representing cryptographic keys and related data in base58 fo
 ---
 # base58 Encodings

-XRP Ledger APIs often use a "base58" encoding with a checksum (sometimes called "Base58Check") to represent [account addresses](accounts.html#addresses) and other types of values related to cryptographic keys. This encoding is the same as [the one used for Bitcoin addresses](https://en.bitcoin.it/wiki/Base58Check_encoding), except that the XRP Ledger uses the following dictionary: `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`.
+XRP Ledger APIs often use a "base58" encoding with a checksum (sometimes called "Base58Check") to represent [account addresses](addresses.html) and other types of values related to cryptographic keys. This encoding is the same as [the one used for Bitcoin addresses](https://en.bitcoin.it/wiki/Base58Check_encoding), except that the XRP Ledger uses the following dictionary: `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`.

 The XRP Ledger prefixes different types of values with a specific 8-bit number before encoding them to distinguish between different data types. With the arrangement of characters in the XRP Ledger's base58 dictionary, the result is that the base58 representations for different types of encoded values start with specific letters by type.

@@ -24,7 +24,7 @@ The following table lists all the encodings the XRP Ledger uses:

 ## See Also

- [Address Encoding](accounts.html#address-encoding) - detailed information on address encoding
+- [Address Encoding](addresses.html#address-encoding) - detailed information on address encoding
 - [Cryptographic Keys](cryptographic-keys.html) - types of cryptographic keys in the XRP Ledger and how they're used
 - [wallet_propose Reference][wallet_propose method] - API method for generating account keys
 - [validation_create Reference][validation_create method] - API method for generating validator keys
--- a/content/references/protocol-reference/data-types/basic-data-types.md
+++ b/content/references/protocol-reference/data-types/basic-data-types.md
@@ -82,7 +82,7 @@ Many API methods require you to specify an instance of the ledger, with the data

 3. Specify a ledger by one of the following shortcuts, in the `ledger_index` parameter:

-    * `validated` for the most recent ledger that has been [validated by consensus](consensus.html#validation)
+    * `validated` for the most recent ledger that has been [validated by consensus](consensus-structure.html#validation)

            "ledger_index": "validated"

--- a/content/references/protocol-reference/data-types/currency-formats.ja.md
+++ b/content/references/protocol-reference/data-types/currency-formats.ja.md
@@ -8,7 +8,7 @@ labels:
 ---
 # 通貨フォーマット

-XRP Ledgerには2種類の通貨（[XRP](xrp.html)と[発行済み通貨](issued-currencies.html)）があります。XRP Ledgerでは、これらの通貨のフォーマットは異なりますが、いずれの通貨も高精度です。
+XRP Ledgerには2種類の通貨 XRP と[発行済み通貨](issued-currencies.html)）があります。XRP Ledgerでは、これらの通貨のフォーマットは異なりますが、いずれの通貨も高精度です。

 ## 文字列フォーマット

--- a/content/references/protocol-reference/data-types/currency-formats.md
+++ b/content/references/protocol-reference/data-types/currency-formats.md
@@ -8,7 +8,7 @@ label:
 ---
 # Currency Formats

-The XRP Ledger has two kinds of digital asset: [XRP](xrp.html) and [tokens](tokens.html). Both types have high precision, although their formats are different.
+The XRP Ledger has two kinds of digital asset: XRP and [tokens](tokens.html). Both types have high precision, although their formats are different.

 ## Comparison

@@ -27,7 +27,7 @@ The following table summarizes some of the differences between XRP and tokens in
 | No transfer fees; XRP-to-XRP payments are always direct. | Can take indirect [paths](paths.html) with each issuer charging a percentage [transfer fee](transfer-fees.html). |
 | Can be used in [Payment Channels](payment-channels.html) and [Escrow](escrow.html). | Not compatible with Payment Channels or Escrow. |

-For more information, see [XRP](xrp.html) and [Tokens](tokens.html).
+For more information, see [What is XRP?](what-is-xrp.html) and [Tokens](tokens.html).

 ## Specifying Currency Amounts

--- a/content/references/protocol-reference/data-types/nftoken.ja.md
+++ b/content/references/protocol-reference/data-types/nftoken.ja.md
@@ -132,6 +132,6 @@ https://example.com/.well-known/xrpl-nft/{tokenid}
 `NFTokenMint`トランザクションを使用して`NFTtoken`を作成します。`NFTokenBurn`トランザクションを使用して`NFToken`を破棄することもできます。

 <!--{# common link defs #}-->
-{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
 {% include '_snippets/rippled_versions.md' %}
--- a/content/references/protocol-reference/ledger-data/ledger-header.md
+++ b/content/references/protocol-reference/ledger-data/ledger-header.md
@@ -32,7 +32,7 @@ Every [ledger version](ledgers.html) has a unique header that describes the cont

 ## Close Flags

-The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different [close times for the ledger](ledgers.html#ledger-close-times), but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, official `close_time` value of the ledger is 1 second after that of the parent ledger.
+The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different [close times for the ledger](ledger-close-times.html), but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, official `close_time` value of the ledger is 1 second after that of the parent ledger.

 The `closeFlags` field is not included in any JSON representations of a ledger, but is included in the binary representation of a ledger, and is one of the fields that determine the ledger's hash.

--- a/content/references/protocol-reference/ledger-data/ledger-object-types/directorynode.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/directorynode.md
@@ -9,11 +9,11 @@ labels:
 # DirectoryNode
 [[Source]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")

-The `DirectoryNode` object type provides a list of links to other objects in the ledger's state tree. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode objects each containing up to 32 [IDs](ledgers.html#tree-format) of other objects. The first object is called the root of the directory, and all objects other than the root object can be added or deleted as necessary.
+The `DirectoryNode` ledger entry type provides a list of links to other entries in the ledger's state data. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode entries each containing up to 32 [IDs of other entries](ledger-object-ids.html). The first DirectoryNode entry is called the root of the directory, and all entries other than the root can be added or deleted as necessary.

 There are two kinds of Directories:

-* **Owner directories** list other objects owned by an account, such as [`RippleState` (trust line)](ripplestate.html) or [`Offer`](offer.html) objects.
+* **Owner directories** list other entries owned by an account, such as [`RippleState` (trust line)](ripplestate.html) or [`Offer`](offer.html) entries.
 * **Offer directories** list the offers available in the [decentralized exchange](decentralized-exchange.html). A single Offer directory contains all the offers that have the same exchange rate for the same token (currency code and issuer).

 ## Example {{currentpage.name}} JSON
@@ -61,7 +61,7 @@ There are two kinds of Directories:

 | Name                | JSON Type | [Internal Type][] | Required? | Description |
 |:--------------------|:----------|:------------------|:----------|:------------|
-| `ExchangeRate`      | String    | UInt64            | No       | (Offer Directories only) **DEPRECATED**. Do not use. |
+| `ExchangeRate`      | String    | UInt64            | No        | (Offer Directories only) **DEPRECATED**. Do not use. |
 | `Flags`             | Number    | UInt32            | Yes       | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `DirectoryNode` objects. The value is always `0`. |
 | `Indexes`           | Array     | Vector256         | Yes       | The contents of this Directory: an array of IDs of other objects. |
 | `IndexNext`         | Number    | UInt64            | No        | If this Directory consists of multiple pages, this ID links to the next object in the chain, wrapping around at the end. |
--- a/content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md
@@ -10,7 +10,7 @@ labels:

 (Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This section describes the `LedgerHashes` ledger object type.)

-The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
+The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transactions.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.

 There are two kinds of `LedgerHashes` object. Both types have the same fields. Each ledger version contains:

--- a/content/references/protocol-reference/ledger-data/ledger-object-types/nftokenoffer.ja.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/nftokenoffer.ja.md
@@ -7,34 +7,40 @@ labels:
 ---
 # NFTokenOffer

-`lsfTransferable` フラグが設定されているトークンは、オファーを使って 参加者間で転送することができます。`NFTokenOffer` オブジェクトは `NFToken` オブジェクトの購入、売却、または譲渡のオファーを表します。`NFToken` の所有者は `NFTokenCreateOffer` を使用して売買を行うことができます。
+`lsfTransferable`フラグが設定されているトークンは、オファーを使って参加者間で転送することができます。`NFTokenOffer`オブジェクトは`NFToken`オブジェクトの購入、売却、または譲渡のオファーを表します。`NFToken`の所有者は`NFTokenCreateOffer`を使用して売買を行うことができます。

-_([NonFungibleTokensV1_1 amendment][]が必要です)_
+_([NonFungibleTokensV1_1 amendment][]により追加されました)_

+## {{currentpage.name}} JSONの例

-### `NFTokenOfferID`のフォーマット
-
-`NFTokenOffer` オブジェクトのユニーク ID (`NFTokenOfferID`) は、以下の値を順番に結合したものである。
-
-
-
-* `NFTokenOffer` のスペースキー、`0x0074` 
-* オファーを出すアカウントの `AccountID`
-* `NFTokenCreateOffer` トランザクションが生成する `Sequence` (または `Ticket`)
+```json
+{
+    "Amount": "1000000",
+    "Flags": 1,
+    "LedgerEntryType": "NFTokenOffer",
+    "NFTokenID": "00081B5825A08C22787716FA031B432EBBC1B101BB54875F0002D2A400000000",
+    "NFTokenOfferNode": "0",
+    "Owner": "rhRxL3MNvuKEjWjL7TBbZSDacb8PmzAd7m",
+    "OwnerNode": "17",
+    "PreviousTxnID": "BFA9BE27383FA315651E26FDE1FA30815C5A5D0544EE10EC33D3E92532993769",
+    "PreviousTxnLgrSeq": 75443565,
+    "index": "AEBABA4FAC212BF28E0F9A9C3788A47B085557EC5D1429E7A8266FB859C863B3"
+}
+```


 ### `NFTokenOffer`のフィールド

 | 名前                | JSONの型     | [内部の型][]        | 必須？ | 説明        |
 |:--------------------|:------------|:------------------|:------|:-----------|
-| `Amount`            | [通貨額][]   | AMOUNT            | はい   | NFTokenに対して見込まれる、または提示される金額です。トークンに `lsfOnlyXRP` フラグが設定されている場合、金額は XRP で指定する必要があります。XRP 以外の資産を指定する売却オファーは、0 以外の金額を指定する必要があります。XRP を指定する売却オファーは、`無料`にすることができます（つまり、このフィールドは `"0"` とすることができます）。 |
+| `Amount`            | [通貨額][]   | AMOUNT            | はい   | NFTokenに対して見込まれる、または提示される金額です。トークンに`lsfOnlyXRP`フラグが設定されている場合、金額はXRPで指定する必要があります。XRP以外の資産を指定する売却オファーは、0以外の金額を指定する必要があります。XRPを指定する売却オファーは、`無料`にすることができます（つまり、このフィールドは`"0"`とすることができます）。 |
 | `Destination`       | 文字列       | AccountID         | いいえ | このオファーの対象となるAccountID。存在する場合、そのアカウントのみがオファーを受け入れることができます。 |
 | `Expiration`        | 数値         | UInt32            | いいえ | オファーが有効でなくなる時刻。値は、リップルエポックからの秒数です。 |
 | `Flags`             | 数値         | UInt32            | はい   | このオブジェクトに関連付けられたフラグのセットで、様々なオプションや設定を指定するために使用されます。フラグは、以下の表に示すとおりです。 |
 | `LedgerEntryType`   | 文字列       | UInt16            | はい   | レジャーオブジェクトの種類を示します（0x0074）。 |
-| `NFTokenID`         | 文字列       | Hash256           | はい   | このオファーが参照する NFToken オブジェクトの NFTokenID。 |
+| `NFTokenID`         | 文字列       | Hash256           | はい   | このオファーが参照するNFTokenオブジェクトのNFTokenID。 |
 | `NFTokenOfferNode`  | 文字列       | UInt64            | いいえ | トークン購入または売却のオファーディレクトリの中で、このトークンが記録されている内部的な台帳です。このフィールドを使用することで、オファーを効率的に削除することができます。 |
-| `Owner`             | 文字列       | AccountID         | はい   | オファーの作成者であり、所有者であるアカウント。NFToken の現在の所有者のみが NFToken の売却オファーを作成できますが、NFToken の購入オファーはどのアカウントでも作成できます。 |
+| `Owner`             | 文字列       | AccountID         | はい   | オファーの作成者であり、所有者であるアカウント。NFTokenの現在の所有者のみがNFTokenの売却オファーを作成できますが、NFTokenの購入オファーはどのアカウントでも作成できます。 |
 | `OwnerNode`         | 文字列       | UInt64            | いいえ | このトークンが記録されているオーナーディレクトリ内のページを示す、内部的な台帳です。このフィールドを使用することで、オファーを効率的に削除することができます。 |
 | `PreviousTxnID`     | 文字列       | Hash256           | はい   | このオブジェクトを最も最近更新したトランザクションの識別ハッシュ。 |
 | `PreviousTxnLgrSeq` | 数値         | UInt32            | はい   | このオブジェクトを最も最近更新したトランザクションを含むレジャーのインデックス。 |
@@ -43,39 +49,38 @@ _([NonFungibleTokensV1_1 amendment][]が必要です)_

 #### NFTokenOffer フラグ

+|フラグ名            |16進数値      |10進数値|説明     |
+|------------------|--------------|------|---------|
+| `lsfSellNFToken `| `0x00000001` | 1    | 有効な場合、オファーは売却オファーとなります。そうでない場合、オファーは購入オファーとなります。 |

-|フラグ名|フラグ値|説明|
-|---|---|---|
-| `lsfSellNFToken `| `0x00000001` | 有効な場合、オファーは売却オファーとなります。そうでない場合、オファーは購入オファーとなります。 |
+## `NFTokenOffer`トランザクション

-## `NFTokenOffer` トランザクション
+[代替可能トークンに対するOffer](offers.html)とは異なり、`NFTokenOffer`はオーダーブックに保存されず、自動的にマッチングされたり約定されたりすることはありません。買い手は売り手により提示されてた`NFTokenOffer`の受け入れを明示的に選択する必要があります。同様に、売り手は自分が所有する`NFToken`オブジェクトを買いたいと申し出た買い手の`NFTokenOffer`を受け入れることを明示的に選択しなければなりません。

-XRPL上のトークン・オファーは、オーダーブックに品質順に保存され、オンレジャーのメカニズムによって自動的にマッチングされます。`NFTokenOffer`はオーダーブックに保存されず、自動的にマッチングされたり実行されたりすることはありません。
+`NFToken`の取引のためのトランザクションは3つあります。

-購入者は `NFToken` の購入を申し出る `NFTokenOffer` を受け入れるかどうかを明示的に選択しなければなりません。同様に、販売者は自分が所有する `NFToken` オブジェクトの購入を申し出る特定の `NFTokenOffer` を受け入れることを明示的に選択する必要があります。
+- [NFTokenCreateOffer][]
+- [NFTokenCancelOffer][]
+- [NFTokenAcceptOffer][]


-定義されたトランザクションは3つあります。
+### `NFTokenOffer`オブジェクトの検索
+
+各`NFToken`は、2つの[ディレクトリ](directorynode.html)があります。1つはトークンを購入するためのオファー、もう1つはトークンを売却するためのオファーが含まれています。マーケットプレイスやその他のクライアントアプリケーションは、ユーザに対し`NFToken`オブジェクトの取引オファーを提示したり、自動的にマッチングすることができます。


+### `NFTokenOffer`の準備金

-1. `NFTokenCreateOffer`
+各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに1つ分の準備金の増額を要求します。執筆時点では、準備金の増分は2XRPです。この準備金は、オファーをキャンセルすることで取り戻すことができます。


-2. `NFTokenCancelOffer`
+### `NFTokenOfferID`のフォーマット

+`NFTokenOffer`オブジェクトのユニークID(`NFTokenOfferID`)は、以下の値を順番に結合したものです。

-3. `NFTokenAcceptOffer`
-
-
-### `NFTokenOffer` オブジェクトの検索
-
-各トークンには、2つのディレクトリがあります。1 つはトークンを購入するためのオファー、もう 1 つはトークンを売却するためのオファーが含まれています。これにより、特定のトークンの `NFTokenOffer` を簡単に見つけることができます。オフレッジャー システムが、オファーの取得、提示、通知、作成、照会、承認、キャンセルに使用されることが予想されます。たとえば、マーケットプレイスは、ウェブやアプリベースの直感的なインターフェースをユーザに提供することができます。
-
-
-### `NFTokenOffer` の準備金
-
-各NFTokenOfferオブジェクトは、オファーを出すアカウントに準備金の増額を1つ要求します。この記事の執筆時点では、準備金の増分は2 XRPです。この準備金は、オファーをキャンセルすることで 取り戻すことができます。
+* `NFTokenOffer`のスペースキー、`0x0074`
+* オファーを出すアカウントの`AccountID`
+* `NFTokenCreateOffer`トランザクションが生成する`NFTokenCreateOffer`の`Sequence`(または`Ticket`)


 <!--{# common link defs #}-->
--- a/content/references/protocol-reference/ledger-data/ledger-object-types/nftokenpage.ja.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/nftokenpage.ja.md
@@ -9,7 +9,7 @@ labels:

 `NFTokenPage` オブジェクトは、同じアカウントが所有する `NFToken` オブジェクトのコレクションを表します。一つのアカウントは複数の `NFTokenPage` 型のレジャーオブジェクトを持つことができ、それらは双方向リストを形成します。

-_([NonFungibleTokensV1_1 amendment][]が必要です)_
+_([NonFungibleTokensV1_1 amendment][]により追加されました)_


 ## {{currentpage.name}} JSONの例
--- a/content/references/protocol-reference/ledger-data/ledger-object-types/ripplestate.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/ripplestate.md
@@ -12,7 +12,7 @@ The `RippleState` object type connects two accounts in a single currency. Concep

 ## High vs. Low Account

-There can only be one `RippleState` object per currency for any given pair of accounts. Since no account is privileged in the XRP Ledger, a `RippleState` object sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when [decoded](accounts.html#address-encoding) is deemed the "low account" and the other is the "high account". The net balance of the trust line is stored from the low account's perspective.
+There can only be one `RippleState` object per currency for any given pair of accounts. Since no account is privileged in the XRP Ledger, a `RippleState` object sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when [decoded](addresses.html#address-encoding) is deemed the "low account" and the other is the "high account". The net balance of the trust line is stored from the low account's perspective.

 The ["issuer"](trust-lines-and-issuing.html) for the balance in a trust line depends on whether the balance is positive or negative. If a `RippleState` object shows a positive balance, the high account is the issuer. If the balance is negative, the low account is the issuer. Often, the issuer has its limit set to 0 and the other account has a positive limit, but this is not reliable because limits can change without affecting an existing balance.

@@ -52,7 +52,7 @@ A `RippleState` object has the following fields:

 | Name                | JSON Type | Internal Type | Required? | Description |
 |:--------------------|:----------|:--------------|:----------|:------------|
-| `Balance`           | Object    | Amount        | Yes       | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the high account holds tokens issued by the low account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](accounts.html#special-addresses). |
+| `Balance`           | Object    | Amount        | Yes       | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the high account holds tokens issued by the low account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](addresses.html#special-addresses). |
 | `Flags`             | Number    | UInt32        | Yes       | A bit-map of boolean options enabled for this object. |
 | `HighLimit`         | Object    | Amount        | Yes       | The limit that the high account has set on the trust line. The `issuer` is the address of the high account that set this limit. |
 | `HighNode`          | String    | UInt64        | Yes       | (Omitted in some historical ledgers) A hint indicating which page of the high account's owner directory links to this object, in case the directory consists of multiple pages. |
--- a/content/references/protocol-reference/ledger-data/ledger-object-types/ticket.ja.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/ticket.ja.md
@@ -37,7 +37,7 @@ _([TicketBatch amendment][]が必要です)_
 | `Account`           | 文字列     | AccountID     | このチケットを所有する[アカウント](accounts.html)です。 |
 | `Flags`             | Number    | UInt32        | ブール値フラグのビットマップ。Ticketにはフラグが定義されていないため、この値は常に0です。 |
 | `OwnerNode`         | 文字列     | UInt64        | 送金元の所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。注記: このオブジェクトには、オブジェクトを含む所有者ディレクトリへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
-| `PreviousTxnID`     | 文字列     | Hash256       | 最後にこのオブジェクトを変更した[トランザクション](transaction-basics.html)の識別用ハッシュ。 |
+| `PreviousTxnID`     | 文字列     | Hash256       | 最後にこのオブジェクトを変更した[トランザクション](transactions.html)の識別用ハッシュ。 |
 | `PreviousTxnLgrSeq` | 数値       | UInt32        | 最後にこのオブジェクトを変更したトランザクションを含む[レジャーインデックス][Ledger Index]。 |
 | `TicketSequence`    | 数値       | UInt32        | 本チケットが設定する[シーケンス番号][]。 |

--- a/content/references/protocol-reference/ledger-data/ledger-object-types/ticket.md
+++ b/content/references/protocol-reference/ledger-data/ledger-object-types/ticket.md
@@ -37,7 +37,7 @@ A `Ticket` object has the following fields:
 | `Flags`             | Number    | UInt32        | Yes       | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Ticket` objects. The value is always `0`. |
 | `LedgerEntryType`   | String    | UInt16        | Yes       | The value `0x0054`, mapped to the string `Ticket`, indicates that this object is a {{currentpage.name}} object. |
 | `OwnerNode`         | String    | UInt64        | Yes       | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
-| `PreviousTxnID`     | String    | Hash256       | Yes       | The identifying hash of the [transaction](transaction-basics.html) that most recently modified this object. |
+| `PreviousTxnID`     | String    | Hash256       | Yes       | The identifying hash of the [transaction](transactions.html) that most recently modified this object. |
 | `PreviousTxnLgrSeq` | Number    | UInt32        | Yes       | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
 | `TicketSequence`    | Number    | UInt32        | Yes       | The [Sequence Number][] this Ticket sets aside. |

--- a/content/references/protocol-reference/serialization.md
+++ b/content/references/protocol-reference/serialization.md
@@ -209,7 +209,7 @@ In addition to all of the above field types, the following types may appear in o
 ### AccountID Fields
 [AccountID]: #accountid-fields

-Fields of this type contain the 160-bit identifier for an XRP Ledger [account](accounts.html). In JSON, these fields are represented as [base58][] XRP Ledger "addresses", with additional checksum data so that typos are unlikely to result in valid addresses. (This encoding, sometimes called "Base58Check", prevents accidentally sending money to the wrong address.) The binary format for these fields does not contain any checksum data nor does it include the `0x00` "type prefix" used in [address base58 encoding](accounts.html#address-encoding). (However, since the binary format is used mostly for signed transactions, a typo or other error in transcribing a signed transaction would invalidate the signature, preventing it from sending money.)
+Fields of this type contain the 160-bit identifier for an XRP Ledger [account](accounts.html). In JSON, these fields are represented as [base58][] XRP Ledger "addresses", with additional checksum data so that typos are unlikely to result in valid addresses. (This encoding, sometimes called "Base58Check", prevents accidentally sending money to the wrong address.) The binary format for these fields does not contain any checksum data nor does it include the `0x00` "type prefix" used in [address base58 encoding](addresses.html#address-encoding). (However, since the binary format is used mostly for signed transactions, a typo or other error in transcribing a signed transaction would invalidate the signature, preventing it from sending money.)

 AccountIDs that appear as stand-alone fields (such as `Account` and `Destination`) are [length-prefixed](#length-prefixing) despite being a fixed 160 bits in length. As a result, the length indicator for these fields is always the byte `0x14`. AccountIDs that appear as children of special fields ([Amount `issuer`][Amount] and [PathSet `account`][PathSet]) are _not_ length-prefixed.

@@ -229,7 +229,7 @@ The "Amount" type is a special field type that represents an amount of currency,

    1. 64 bits indicating the amount in the [token amount format](#token-amount-format). The first bit is `1` to indicate that this is not XRP.
    2. 160 bits indicating the [currency code](currency-formats.html#currency-codes). The standard API converts 3-character codes such as "USD" into 160-bit codes using the [standard currency code format](currency-formats.html#standard-currency-codes), but custom 160-bit codes are also possible.
-    3. 160 bits indicating the issuer's Account ID. (See also: [Account Address Encoding](accounts.html#address-encoding))
+    3. 160 bits indicating the issuer's Account ID. (See also: [Account Address Encoding](addresses.html#address-encoding))

 You can tell which of the two sub-types it is based on the first bit: `0` for XRP; `1` for tokens.

--- a/content/references/protocol-reference/transactions/pseudo-transaction-types/pseudo-transaction-types.md
+++ b/content/references/protocol-reference/transactions/pseudo-transaction-types/pseudo-transaction-types.md
@@ -16,7 +16,7 @@ Some of the required [common fields][] for normal transactions do not make sense

 | Field           | JSON Type | [Internal Type][] | Value                      |
 |:----------------|:----------|:------------------|:---------------------------|
-| `Account`       | String    | AccountID         | [ACCOUNT_ZERO](accounts.html#special-addresses) |
+| `Account`       | String    | AccountID         | [ACCOUNT_ZERO](addresses.html#special-addresses) |
 | `Fee`           | String    | Amount            | `0`                        |
 | `Sequence`      | Number    | UInt32            | `0`                        |
 | `SigningPubKey` | String    | Blob              | `""` (Empty string)        |
--- a/content/references/protocol-reference/transactions/transaction-metadata.md
+++ b/content/references/protocol-reference/transactions/transaction-metadata.md
@@ -25,13 +25,13 @@ The following JSON object shows the metadata for [a complex cross-currency payme

 ## AffectedNodes

-The `AffectedNodes` array contains a complete list of the [objects in the ledger](ledger-object-types.html) that this transaction modified in some way. Each entry in this array is an object with one top-level field indicating what type it is:
+The `AffectedNodes` array contains a complete list of the [ledger entries](ledger-object-types.html) that this transaction modified in some way. Each item in this array is an object with one top-level field indicating what happened:

- `CreatedNode` indicates that the transaction created a new object in the ledger.
- `DeletedNode` indicates that the transaction removed an object from the ledger.
- `ModifiedNode` indicates that the transaction modified an existing object in the ledger.
+- `CreatedNode` indicates that the transaction created a new ledger entry.
+- `DeletedNode` indicates that the transaction removed a ledger entry
+- `ModifiedNode` indicates that the transaction modified an existing ledger entry.

-The value of each of these fields is a JSON object describing the changes made to the ledger object.
+The value of each of these fields is a JSON object describing the changes made to the ledger entry.

 ### CreatedNode Fields

@@ -39,9 +39,9 @@ A `CreatedNode` object contains the following fields:

 | Field             | Value             | Description                          |
 |:------------------|:------------------|:-------------------------------------|
-| `LedgerEntryType` | String            | The [type of ledger object](ledger-object-types.html) that was created. |
-| `LedgerIndex`     | String - [Hash][] | The [ID of this ledger object](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. |
-| `NewFields`       | Object            | The content fields of the newly-created ledger object. Which fields are present depends on what type of ledger object was created. |
+| `LedgerEntryType` | String            | The [type of ledger entry](ledger-object-types.html) that was created. |
+| `LedgerIndex`     | String - [Hash][] | The [ID of this ledger entry](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. |
+| `NewFields`       | Object            | The content fields of the newly-created ledger entry. Which fields are present depends on what type of ledger entry was created. |

 ### DeletedNode Fields

@@ -49,9 +49,9 @@ A `DeletedNode` object contains the following fields:

 | Field             | Value             | Description                          |
 |:------------------|:------------------|:-------------------------------------|
-| `LedgerEntryType` | String            | The [type of ledger object](ledger-object-types.html) that was deleted. |
-| `LedgerIndex`     | String - [Hash][] | The [ID of this ledger object](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. |
-| `FinalFields`     | Object            | The content fields of the ledger object immediately before it was deleted. Which fields are present depends on what type of ledger object was created. |
+| `LedgerEntryType` | String            | The [type of ledger entry](ledger-object-types.html) that was deleted. |
+| `LedgerIndex`     | String - [Hash][] | The [ID of this ledger entry](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. |
+| `FinalFields`     | Object            | The content fields of the ledger entry immediately before it was deleted. Which fields are present depends on what type of ledger entry was created. |

 ### ModifiedNode Fields

@@ -59,14 +59,14 @@ A `ModifiedNode` object contains the following fields:

 | Field               | Value                     | Description                |
 |:--------------------|:--------------------------|:---------------------------|
-| `LedgerEntryType`   | String                    | The [type of ledger object](ledger-object-types.html) that was deleted. |
-| `LedgerIndex`       | String - [Hash][]         | The [ID of this ledger object](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. |
-| `FinalFields`       | Object                    | The content fields of the ledger object after applying any changes from this transaction. Which fields are present depends on what type of ledger object was created. This omits the `PreviousTxnID` and `PreviousTxnLgrSeq` fields, even though most types of ledger objects have them. |
+| `LedgerEntryType`   | String                    | The [type of ledger entry](ledger-object-types.html) that was deleted. |
+| `LedgerIndex`       | String - [Hash][]         | The [ID of this ledger entry](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. |
+| `FinalFields`       | Object                    | The content fields of the ledger entry after applying any changes from this transaction. Which fields are present depends on what type of ledger entry was created. This omits the `PreviousTxnID` and `PreviousTxnLgrSeq` fields, even though most types of ledger entries have them. |
 | `PreviousFields`    | Object                    | The previous values for all fields of the object that were changed as a result of this transaction. If the transaction _only added_ fields to the object, this field is an empty object. |
-| `PreviousTxnID`     | String - [Hash][]         | _(May be omitted)_ The [identifying hash][] of the previous transaction to modify this ledger object. Omitted for ledger object types that do not have a `PreviousTxnID` field. |
-| `PreviousTxnLgrSeq` | Number - [Ledger Index][] | _(May be omitted)_  The [Ledger Index][] of the ledger version containing the previous transaction to modify this ledger object. Omitted for ledger object types that do not have a `PreviousTxnLgrSeq` field. |
+| `PreviousTxnID`     | String - [Hash][]         | _(May be omitted)_ The [identifying hash][] of the previous transaction to modify this ledger entry. Omitted for ledger entry types that do not have a `PreviousTxnID` field. |
+| `PreviousTxnLgrSeq` | Number - [Ledger Index][] | _(May be omitted)_  The [Ledger Index][] of the ledger version containing the previous transaction to modify this ledger entry. Omitted for ledger entry types that do not have a `PreviousTxnLgrSeq` field. |

-**Note:** If the modified ledger object has `PreviousTxnID` and `PreviousTxnLgrSeq` fields, the transaction always updates them with the transaction's own identifying hash and the index of the ledger version that included the transaction, but these fields' new value is not listed in the `FinalFields` of the `ModifiedNode` object, and their previous values are listed at the top level of the `ModifiedNode` object rather than in the nested `PreviousFields` object.
+**Note:** If the modified ledger entry has `PreviousTxnID` and `PreviousTxnLgrSeq` fields, the transaction always updates them with the transaction's own identifying hash and the index of the ledger version that included the transaction, but these fields' new value is not listed in the `FinalFields` of the `ModifiedNode` object, and their previous values are listed at the top level of the `ModifiedNode` object rather than in the nested `PreviousFields` object.

 ## NFT Fields

--- a/content/references/protocol-reference/transactions/transaction-results/tec-codes.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-results/tec-codes.ja.md
@@ -32,7 +32,7 @@ labels:
 | `tecINVARIANT_FAILED` | 147 | このトランザクションを実行しようとしたところ、不変性チェックが失敗しました。[EnforceInvariants Amendment][]が必要です。このエラーを再現できる場合は、[問題を報告](https://github.com/ripple/rippled/issues)してください。 |
 | `tecKILLED` | 150 | [OfferCreateトランザクション][]がtfFillOrKillフラグを指定しましたが、トランザクションを確定できなかったため、このトランザクションは取り消されました。_（[fix1578 Amendment][]が必要です。）_ |
 | `tecNEED_MASTER_KEY` | 142 | このトランザクションはマスターキーを必要とする変更（[マスターキーの無効化または残高凍結能力の放棄](accountset.html#accountsetのフラグ)など）を試みました。[新規: rippled 0.28.0][] |
-| `tecNO_ALTERNATIVE_KEY` | 130 | トランザクションが唯一の[トランザクション承認](transaction-basics.html#トランザクションの承認)メソッドを削除しようとしました。これは、レギュラーキーを削除する[SetRegularKeyトランザクション][]、SignerListを削除する[SignerListSetトランザクション][]、またはマスターキーを無効にする[AccountSetトランザクション][]である可能性があります。（`rippled` 0.30.0より前のバージョンでは、このトランザクションは`tecMASTER_DISABLED`と呼ばれていました。） |
+| `tecNO_ALTERNATIVE_KEY` | 130 | トランザクションが唯一の[トランザクション承認](transactions.html#トランザクションの承認)メソッドを削除しようとしました。これは、レギュラーキーを削除する[SetRegularKeyトランザクション][]、SignerListを削除する[SignerListSetトランザクション][]、またはマスターキーを無効にする[AccountSetトランザクション][]である可能性があります。（`rippled` 0.30.0より前のバージョンでは、このトランザクションは`tecMASTER_DISABLED`と呼ばれていました。） |
 | `tecNO_AUTH` | 134 | トランザクションはトラストラインの残高を、`lsfRequireAuth`フラグが有効になっているアカウントに追加する必要がありましたが、そのトラストラインが承認されていなかったため、失敗しました。トラストラインが存在しない場合は、代わりに`tecNO_LINE`が発生します。 |
 | `tecNO_DST` | 124 | トランザクションの受信側のアカウントが存在しません。これには、PaymentトランザクションタイプやTrustSetトランザクションタイプがあります。（XRPを十分に受信した場合に作成される可能性があります。） |
 | `tecNO_DST_INSUF_XRP` | 125 | トランザクションの受信側のアカウントが存在しません。トランザクションは、アカウントの作成に十分なXRPを送金していません。 |
@@ -42,7 +42,7 @@ labels:
 | `tecNO_LINE_INSUF_RESERVE` | 126 | 送信側アカウントに、新しいトラストラインを作成するのに十分なXRPがないため、トランザクションが失敗しました。（[準備金](reserves.html)を参照）このエラーは、取引相手がこのアカウントに対する同一通貨のトラストラインを持っていない場合に発生します。（その他のケースについては`tecINSUF_RESERVE_LINE`を参照してください。） |
 | `tecNO_LINE_REDUNDANT` | 127 | トランザクションはトラストラインをデフォルト状態に設定しようと試みましたが、トラストラインが存在していなかったため、失敗しました。 |
 | `tecNO_PERMISSION` | 139 | 送信者にはこの操作を実行する権限がありません。たとえば[EscrowFinishトランザクション][]が`FinishAfter`時刻に達する前に保留中の支払をリリースしようとしたか、送信者が所有していないChannelで誰かが[PaymentChannelFund][]を使用しようとしたか、または[Payment][]が「DepositAuth」フラグが有効になっているアカウントに資金の送金を試みました。 |
-| `tecNO_REGULAR_KEY` | 131 | [AccountSetトランザクション][]がマスターキーを無効にしようとしましたが、アカウントにはマスターキー以外で[トランザクションを承認する](transaction-basics.html#トランザクションの承認)方法がありません。[マルチシグ](multi-signing.html)が有効な場合、このコードは廃止予定であり、代わりに`tecNO_ALTERNATIVE_KEY`が使用されます。 |
+| `tecNO_REGULAR_KEY` | 131 | [AccountSetトランザクション][]がマスターキーを無効にしようとしましたが、アカウントにはマスターキー以外で[トランザクションを承認する](transactions.html#トランザクションの承認)方法がありません。[マルチシグ](multi-signing.html)が有効な場合、このコードは廃止予定であり、代わりに`tecNO_ALTERNATIVE_KEY`が使用されます。 |
 | `tecNO_TARGET` | 138 | トランザクションが参照するEscrowレジャーオブジェクトまたはPayChannelレジャーオブジェクトが存在していません。これらのオブジェクトは、これまでに存在したことがないか、すでに削除されています。（たとえば、別の[EscrowFinishトランザクション][]で保留中の支払がすでに実行されている場合などです。）あるいは、支払先アカウントで`asfDisallowXRP`が設定されているため、このアカウントは[PaymentChannelCreate][]トランザクションまたは[EscrowCreate][]トランザクションの宛先に指定できません。 |
 | `tecOVERSIZE` | 145 | サーバーがこのトランザクションの適用時に大量のメタデータを作成したため、このトランザクションを処理できませんでした。[新規: rippled 0.29.0-hf1][] |
 | `tecOWNERS` | 132 | トランザクションでは、トランザクションを送信するアカウントの「所有者カウント」はゼロ以外である必要があります。このためトランザクションを正常に完了できません。たとえば、トラストラインや使用可能なオファーがあるアカウントでは、[`lsfRequireAuth`](accountset.html#accountsetのフラグ)フラグを有効にできません。 |
--- a/content/references/protocol-reference/transactions/transaction-results/tec-codes.md
+++ b/content/references/protocol-reference/transactions/transaction-results/tec-codes.md
@@ -20,11 +20,11 @@ Transactions with `tec` codes destroy the XRP paid as a [transaction cost](trans
 | `tecCRYPTOCONDITION_ERROR` | 146   | This [EscrowCreate][] or [EscrowFinish][] transaction contained a malformed or mismatched crypto-condition. |
 | `tecDIR_FULL`              | 121   | The transaction tried to add an object (such as a trust line, Check, Escrow, or Payment Channel) to an account's owner directory, but that account cannot own any more objects in the ledger. |
 | `tecDUPLICATE`             | 149   | The transaction tried to create an object (such as a [DepositPreauth][] authorization) that already exists. |
-| `tecDST_TAG_NEEDED`        | 143   | The [Payment transaction][] omitted a [destination tag](source-and-destination-tags.html), but the destination account has the `lsfRequireDestTag` flag enabled. [New in: rippled 0.28.0][] |
+| `tecDST_TAG_NEEDED`        | 143   | The [Payment transaction][] omitted a [destination tag](source-and-destination-tags.html), but the destination account has the `lsfRequireDestTag` flag enabled. |
 | `tecEXPIRED`               | 148   | The transaction tried to create an object (such as an Offer or a Check) whose provided Expiration time has already passed. |
 | `tecFAILED_PROCESSING`     | 105   | An unspecified error occurred when processing the transaction. |
 | `tecFROZEN`                | 137   | The [OfferCreate transaction][] failed because one or both of the assets involved are subject to a [global freeze](freezes.html). |
-| `tecHAS_OBLIGATIONS`       | 151   | The [AccountDelete transaction][] failed because the account to be deleted owns objects that cannot be deleted. See [Deletion of Accounts](accounts.html#deletion-of-accounts) for details. |
+| `tecHAS_OBLIGATIONS`       | 151   | The [AccountDelete transaction][] failed because the account to be deleted owns objects that cannot be deleted. See [Deleting Accounts](deleting-accounts.html) for details. |
 | `tecINSUF_RESERVE_LINE`    | 122   | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty already has a trust line in a non-default state to the sending account for the same currency. (See `tecNO_LINE_INSUF_RESERVE` for the other case.) |
 | `tecINSUF_RESERVE_OFFER`   | 123   | The transaction failed because the sending account does not have enough XRP to create a new Offer. (See: [Reserves](reserves.html)) |
 | `tecINSUFF_FEE`            | 136   | The transaction failed because the sending account does not have enough XRP to pay the [transaction cost](transaction-cost.html) that it specified. (In this case, the transaction processing destroys all of the sender's XRP even though that amount is lower than the specified transaction cost.) This result only occurs if the account's balance decreases _after_ this transaction has been distributed to enough of the network to be included in a consensus set. Otherwise, the transaction fails with [`terINSUF_FEE_B`](ter-codes.html) before being distributed. |
@@ -35,10 +35,10 @@ Transactions with `tec` codes destroy the XRP paid as a [transaction cost](trans
 | `tecINVARIANT_FAILED`      | 147   | An invariant check failed when trying to execute this transaction. Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
 | `tecKILLED`                | 150   | The [OfferCreate transaction][] specified the `tfFillOrKill` flag and could not be filled, so it was killed. _(Added by the [fix1578 amendment][].)_ |
 | `tecMAX_SEQUENCE_REACHED`  | 153   | A sequence number field is already at its maximum. This includes the `MintedNFTokens` field. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
-| `tecNEED_MASTER_KEY`       | 142   | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](accountset.html#accountset-flags). [New in: rippled 0.28.0][] |
+| `tecNEED_MASTER_KEY`       | 142   | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](accountset.html#accountset-flags). |
 | `tecNFTOKEN_BUY_SELL_MISMATCH` | 155 | The [NFTokenAcceptOffer transaction][] attempted to match incompatible offers to buy and sell a non-fungible token. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
 | `tecNFTOKEN_OFFER_TYPE_MISMATCH` | 156 | One or more of the offers specified in the transaction was not the right type of offer. (For example, a buy offer was specified in the `NFTokenSellOffer` field.) _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
-| `tecNO_ALTERNATIVE_KEY`    | 130   | The transaction tried to remove the only available method of [authorizing transactions](transaction-basics.html#authorizing-transactions). This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. (Prior to `rippled` 0.30.0, this was called `tecMASTER_DISABLED`.) |
+| `tecNO_ALTERNATIVE_KEY`    | 130   | The transaction tried to remove the only available method of [authorizing transactions](transactions.html#authorizing-transactions). This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. (Prior to `rippled` 0.30.0, this was called `tecMASTER_DISABLED`.) |
 | `tecNO_AUTH`               | 134   | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, `tecNO_LINE` occurs instead. |
 | `tecNO_DST`                | 124   | The account on the receiving end of the transaction does not exist. This includes Payment and TrustSet transaction types. (It could be created if it received enough XRP.) |
 | `tecNO_DST_INSUF_XRP`      | 125   | The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XRP to create it. |
@@ -48,11 +48,11 @@ Transactions with `tec` codes destroy the XRP paid as a [transaction cost](trans
 | `tecNO_LINE_INSUF_RESERVE` | 126   | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) |
 | `tecNO_LINE_REDUNDANT`     | 127   | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
 | `tecNO_PERMISSION`         | 139   | The sender does not have permission to do this operation. For example, the [EscrowFinish transaction][] tried to release a held payment before its `FinishAfter` time, someone tried to use [PaymentChannelFund][] on a channel the sender does not own, or a [Payment][] tried to deliver funds to an account with the "DepositAuth" flag enabled. |
-| `tecNO_REGULAR_KEY`        | 131   | The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to [authorize transactions](transaction-basics.html#authorizing-transactions). If [multi-signing](multi-signing.html) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. |
+| `tecNO_REGULAR_KEY`        | 131   | The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to [authorize transactions](transactions.html#authorizing-transactions). If [multi-signing](multi-signing.html) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. |
 | `tecNO_SUITABLE_NFTOKEN_PAGE` | 154 | The transaction tried to mint or acquire a non-fungible token but the account receiving the `NFToken` does not have a directory page that can hold it. This situation is rare. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
 | `tecNO_TARGET`             | 138   | The transaction referenced an Escrow or PayChannel ledger object that doesn't exist, either because it never existed or it has already been deleted. (For example, another [EscrowFinish transaction][] has already executed the held payment.) Alternatively, the destination account has `asfDisallowXRP` set so it cannot be the destination of this [PaymentChannelCreate][] or [EscrowCreate][] transaction. |
 | `tecOBJECT_NOT_FOUND`      | 160   | One of the objects specified by this transaction did not exist in the ledger. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
-| `tecOVERSIZE`              | 145   | This transaction could not be processed, because the server created an excessively large amount of [metadata](transaction-metadata.html) when it tried to apply the transaction. [New in: rippled 0.29.0-hf1][] |
+| `tecOVERSIZE`              | 145   | This transaction could not be processed, because the server created an excessively large amount of [metadata](transaction-metadata.html) when it tried to apply the transaction. |
 | `tecOWNERS`                | 132   | The transaction cannot succeed because the sender already owns objects in the ledger. For example, an account cannot enable the [`lsfRequireAuth`](accountset.html#accountset-flags) flag if it has any trust lines or available offers. |
 | `tecPATH_DRY`              | 128   | The transaction failed because the provided [paths](paths.html) did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by [trust lines](trust-lines-and-issuing.html). |
 | `tecPATH_PARTIAL`          | 101   | The transaction failed because the provided [paths](paths.html) did not have enough liquidity to send the full amount. |
--- a/content/references/protocol-reference/transactions/transaction-types/accountdelete.md
+++ b/content/references/protocol-reference/transactions/transaction-types/accountdelete.md
@@ -11,7 +11,7 @@ labels:

 _Added by the [DeletableAccounts amendment](known-amendments.html#deletableaccounts)_

-An AccountDelete transaction deletes an [account](accountroot.html) and any objects it owns in the XRP Ledger, if possible, sending the account's remaining XRP to a specified destination account. See [Deletion of Accounts](accounts.html#deletion-of-accounts) for the requirements to delete an account.
+An AccountDelete transaction deletes an [account](accountroot.html) and any objects it owns in the XRP Ledger, if possible, sending the account's remaining XRP to a specified destination account. See [Deleting Accounts](deleting-accounts.html) for the requirements to delete an account.

 ## Example {{currentpage.name}} JSON

--- a/content/references/protocol-reference/transactions/transaction-types/accountset.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-types/accountset.ja.md
@@ -35,7 +35,7 @@ AccountSetトランザクションは、[XRP Ledgerのアカウント](accountro
 | [`Domain`](#domain)       | 文字列           | Blob              |  _（省略可）_ このアカウントを保有するドメインのASCII小文字を表現する16進文字列。[256バイトを超える長さは使用できません。](https://github.com/XRPLF/rippled/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) |
 | `EmailHash`        | 文字列           | Hash128           |  _（省略可）_ アバターイメージの生成に使用されるメールアドレスのハッシュ。一般的に、クライアントは[Gravatar](http://en.gravatar.com/site/implement/hash/)を使用してこのイメージを表示しています。 |
 | `MessageKey`       | 文字列           | Blob              |  _（省略可）_ 暗号化されたメッセージをこのアカウントに送信するための公開鍵です。キーを設定するには、正確に33バイトである必要があり、最初のバイトはキーの種類を示します。secp256k1鍵の場合は`0x02`または`0x03`、Ed25519鍵の場合は`0xED`です。キーを削除するには、空の値を使用します。 |
-| `NFTokenMinter`  | 文字列           | Blob              | _(省略可)_ あなたのために[NFTokensをミントする](authorize-minter.html)ことができる別のアカウント。 _([NonFungibleTokensV1_1 amendment][]によって追加されました.)_ |
+| `NFTokenMinter`  | 文字列           | Blob              | _(省略可)_ あなたのために[NFTokensをミントする](assign-an-authorized-minter-using-javascript.html)ことができる別のアカウント。 _([NonFungibleTokensV1_1 amendment][]により追加されました.)_ |
 | [`SetFlag`](#accountsetのフラグ)      | 数値           | UInt32            |  _（省略可）_ このアカウントについてオプションを有効にするための整数フラグ。 |
 | [`TransferRate`](#transferrate) | 符号なし整数 | UInt32            |  _（省略可）_ ユーザーがこのアカウントの発行済み通貨を送金するときに請求される手数料。通貨単位の10億分の1で表現されます。手数料なしを意味する特殊なケースの`0`を除いて、`2000000000`より大きくしたり、`1000000000`より小さくしたりすることはできません。 |
 | [`TickSize`](ticksize.html)     | 符号なし整数 | UInt8             | _（省略可）_このアドレスによって発行されている通貨が関係するオファーに使用する為替レートの呼値の単位。それらのオファーの為替レートは、この有効桁数へと丸められます。有効な値は`3`から`15`、または無効にするための`0`です_（[TickSize Amendment][]によって追加されました）。_ |
@@ -72,7 +72,7 @@ AccountSetトランザクションは、[XRP Ledgerのアカウント](accountro
 | フラグの名前                        | 10進値 | 対応するレジャーフラグ               | 説明   |
 |:----------------------------------|:------|:----------------------------------|:--------------|
 | `asfAccountTxnID`                 | 5     | （なし）                           | このアカウントの直近のトランザクションのIDを追跡します。[AccountTxnID](transaction-common-fields.html#accounttxnid)については必須です。 |
-| `asfAuthorizedNFTokenMinter`      | 10    | (なし)                            | このアカウントの代わりに、別のアカウントが非代替性トークン（NFToken）をミントすることを許可するために使用します。認可されたアカウントを[AccountRoot](accountroot.html)オブジェクトの`NFTokenMinter`フィールドで指定します。認可されたアカウントを削除するには、このフラグを有効にして`NFTokenMinter`フィールドを省略します。 _([NonFungibleTokensV1_1 amendment][]によって追加されました。)_ |
+| `asfAuthorizedNFTokenMinter`      | 10    | (なし)                            | このアカウントの代わりに、別のアカウントが非代替性トークン（NFToken）をミントすることを許可するために使用します。認可されたアカウントを[AccountRoot](accountroot.html)オブジェクトの`NFTokenMinter`フィールドで指定します。認可されたアカウントを削除するには、このフラグを有効にして`NFTokenMinter`フィールドを省略します。 _([NonFungibleTokensV1_1 amendment][]により追加されました。)_ |
 | `asfDefaultRipple`                | 8     | `lsfDefaultRipple`                | このアカウントのトラストラインでの[リップリング](rippling.html)をデフォルトで有効にします。 |
 | `asfDepositAuth`                  | 9     | `lsfDepositAuth`                  | このアカウントに対して[Deposit Authorization](depositauth.html)を有効にします _（[DepositAuth Amendment][]によって追加されました）。_  |
 | `asfDisableMaster`                | 4     | `lsfDisableMaster`                | マスターキーペアの使用を禁止します。[レギュラーキー](cryptographic-keys.html)や[署名者リスト](multi-signing.html)など、トランザクションに署名するための別の手段がアカウントで設定されている場合のみ有効にできます。 |
@@ -86,7 +86,7 @@ AccountSetトランザクションは、[XRP Ledgerのアカウント](accountro
 | `asfRequireAuth`                  | 2     | `lsfRequireAuth`                  | このアドレスによって発行された残高をユーザーが保持することについて、承認を要求します。アドレスにトラストラインが接続されていない場合のみ有効にできます。 |
 | `asfRequireDest`                  | 1     | `lsfRequireDestTag`               | トランザクションをこのアカウントに送信するための宛先タグを要求します。 |

-`asfDisableMaster`フラグまたは`asfNoFreeze`フラグを有効にするには、マスターキーペアで署名することによって[トランザクションを承認](transaction-basics.html#トランザクションの承認)する必要があります。レギュラーキーペアやマルチ署名を使用することはできません。レギュラーキーペアまたはマルチ署名を使用すると、`asfDisableMaster`を無効にする（つまり、マスターキーペアを再び有効にする）ことができます。[新規: rippled 0.28.0][]
+`asfDisableMaster`フラグまたは`asfNoFreeze`フラグを有効にするには、マスターキーペアで署名することによって[トランザクションを承認](transactions.html#トランザクションの承認)する必要があります。レギュラーキーペアやマルチ署名を使用することはできません。レギュラーキーペアまたはマルチ署名を使用すると、`asfDisableMaster`を無効にする（つまり、マスターキーペアを再び有効にする）ことができます。[新規: rippled 0.28.0][]

 以下の[トランザクションフラグ](transaction-common-fields.html#flagsフィールド)はAccountSetタイプのトランザクションに固有のもので、同様の目的を果たしますが、使用することはお勧めしません。限られたスペースのため、いくつかの設定には関連する `tf` フラグがありません。また、新しい `tf` フラグは `AccountSet` トランザクションタイプには追加されていません。一つのトランザクションで複数の設定を有効にするには、`tf`フラグと`asf`フラグを組み合わせて使用することができます。

--- a/content/references/protocol-reference/transactions/transaction-types/accountset.md
+++ b/content/references/protocol-reference/transactions/transaction-types/accountset.md
@@ -37,7 +37,7 @@ An AccountSet transaction modifies the properties of an [account in the XRP Ledg
 | [`Domain`](#domain) | String        | Blob              | _(Optional)_ The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. [Cannot be more than 256 bytes in length.](https://github.com/XRPLF/rippled/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) |
 | `EmailHash`      | String           | Hash128           | _(Optional)_ An arbitrary 128-bit value. Conventionally, clients treat this as the md5 hash of an email address to use for displaying a [Gravatar](http://en.gravatar.com/site/implement/hash/) image. |
 | `MessageKey`     | String           | Blob              | _(Optional)_ Public key for sending encrypted messages to this account. To set the key, it must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. To remove the key, use an empty value. |
-| `NFTokenMinter`  | String           | Blob              | _(Optional)_ Another account that can [mint NFTokens for you](authorize-minter.html). _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
+| `NFTokenMinter`  | String           | Blob              | _(Optional)_ Another account that can [mint NFTokens for you](assign-an-authorized-minter-using-javascript.html). _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
 | [`SetFlag`](#accountset-flags) | Number | UInt32        | _(Optional)_ Integer flag to enable for this account. |
 | [`TransferRate`](#transferrate) | Number | UInt32       | _(Optional)_ The fee to charge when users transfer this account's tokens, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
 | [`TickSize`](ticksize.html) | Number | UInt8            | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Added by the [TickSize amendment][])_ |
@@ -88,7 +88,7 @@ The available AccountSet flags are:
 | `asfRequireAuth`                  | 2             | `lsfRequireAuth`                  | Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it. |
 | `asfRequireDest`                  | 1             | `lsfRequireDestTag`               | Require a destination tag to send transactions to this account. |

-To enable the `asfDisableMaster` or `asfNoFreeze` flags, you must [authorize the transaction](transaction-basics.html#authorizing-transactions) by signing it with the master key pair. You cannot use a regular key pair or a multi-signature. You can disable `asfDisableMaster` (that is, re-enable the master key pair) using a regular key pair or multi-signature.
+To enable the `asfDisableMaster` or `asfNoFreeze` flags, you must [authorize the transaction](transactions.html#authorizing-transactions) by signing it with the master key pair. You cannot use a regular key pair or a multi-signature. You can disable `asfDisableMaster` (that is, re-enable the master key pair) using a regular key pair or multi-signature.

 The following [Transaction flags](transaction-common-fields.html#flags-field) (`tf` flags), specific to the AccountSet transaction type, serve the same purpose. Due to limited space, some settings do not have associated `tf` flags, and new `tf` flags are not being added to the `AccountSet` transaction type. You can use a combination of `tf` and `asf` flags to enable multiple settings with a single transaction.

--- a/content/references/protocol-reference/transactions/transaction-types/escrowcreate.md
+++ b/content/references/protocol-reference/transactions/transaction-types/escrowcreate.md
@@ -40,13 +40,23 @@ Sequester XRP until the escrow process either finishes or is canceled.
 | `Amount`         | String    | Amount            | Amount of [XRP, in drops][Currency Amount], to deduct from the sender's balance and escrow. Once escrowed, the XRP can either go to the `Destination` address (after the `FinishAfter` time) or returned to the sender (after the `CancelAfter` time). |
 | `Destination`    | String    | AccountID         | Address to receive escrowed XRP. |
 | `CancelAfter`    | Number    | UInt32            | _(Optional)_ The time, in [seconds since the Ripple Epoch][], when this escrow expires. This value is immutable; the funds can only be returned to the sender after this time. |
-| `FinishAfter`    | Number    | UInt32            | _(Optional)_ The time, in [seconds since the Ripple Epoch][], when the escrowed XRP can be released to the recipient. This value is immutable; the funds cannot move until this time is reached. |
+| `FinishAfter`    | Number    | UInt32            | _(Optional)_ The time, in [seconds since the Ripple Epoch][], when the escrowed XRP can be released to the recipient. This value is immutable, and the funds can't be accessed until this time. |
 | `Condition`      | String    | Blob              | _(Optional)_ Hex value representing a [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1). The funds can only be delivered to the recipient if this condition is fulfilled. |
 | `DestinationTag` | Number    | UInt32            | _(Optional)_ Arbitrary tag to further specify the destination for this escrowed payment, such as a hosted recipient at the destination address. |

-Either `CancelAfter` or `FinishAfter` must be specified. If both are included, the `FinishAfter` time must be before the `CancelAfter` time.
+You must specify one of the following combinations of fields:

-With the [fix1571 amendment][] enabled, you must supply `FinishAfter`, `Condition`, or both. [New in: rippled 1.0.0][]
+| Summary                           | `FinishAfter` | `Condition` | `CancelAfter` |
+|-----------------------------------|---------------|-------------|---------------|
+| Time-based                        | ✅            |             |               |
+| Time-based with expiration        | ✅            |             | ✅            |
+| Timed conditional                 | ✅            | ✅          |               |
+| Timed conditional with expiration | ✅            | ✅          | ✅            |
+| Conditional with expiration       |               | ✅          | ✅            |
+
+It is not possible to create a conditional escrow with no expiration, but you can specify an expiration that is very far in the future.
+
+**Note:** Before the [fix1571 amendment][] became enabled on 2018-06-19, it was possible to create an escrow with `CancelAfter` only. These escrows could be finished by anyone at any time before the specified expiration.


 <!--{# common link defs #}-->
--- a/content/references/protocol-reference/transactions/transaction-types/escrowfinish.md
+++ b/content/references/protocol-reference/transactions/transaction-types/escrowfinish.md
@@ -47,7 +47,7 @@ Any account may submit an EscrowFinish transaction.

 **Note:** The minimum [transaction cost](transaction-cost.html) to submit an EscrowFinish transaction increases if it contains a fulfillment. If the transaction has no fulfillment, the transaction cost is the standard 10 drops. If the transaction contains a fulfillment, the transaction cost is 330 [drops of XRP][] plus another 10 drops for every 16 bytes in size of the preimage.

-In [non-production networks](parallel-networks.html), it may be possible [to delete](accounts.html#deletion-of-accounts) the destination account of a pending escrow. In this case, an attempt to finish the escrow fails with the result `tecNO_TARGET`, but the escrow object remains unless it has expired normally. If another payment re-creates the destination account, the escrow can be finished successfully. The destination account of an escrow can only be deleted if the escrow was created before the [fix1523 amendment](known-amendments.html#fix1523) became enabled. No such escrows exist in the production XRP Ledger, so this edge case is not possible on the production XRP Ledger. This edge case is also not possible in test networks that enable both fix1523 and Escrow amendments at the same time, which is the default when you [start a new genesis ledger](start-a-new-genesis-ledger-in-stand-alone-mode.html).
+In [non-production networks](parallel-networks.html), it may be possible [to delete](deleting-accounts.html) the destination account of a pending escrow. In this case, an attempt to finish the escrow fails with the result `tecNO_TARGET`, but the escrow object remains unless it has expired normally. If another payment re-creates the destination account, the escrow can be finished successfully. The destination account of an escrow can only be deleted if the escrow was created before the [fix1523 amendment](known-amendments.html#fix1523) became enabled. No such escrows exist in the production XRP Ledger, so this edge case is not possible on the production XRP Ledger. This edge case is also not possible in test networks that enable both fix1523 and Escrow amendments at the same time, which is the default when you [start a new genesis ledger](start-a-new-genesis-ledger-in-stand-alone-mode.html).

 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
--- a/content/references/protocol-reference/transactions/transaction-types/nftokenacceptoffer.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-types/nftokenacceptoffer.ja.md
@@ -12,7 +12,7 @@ labels:
 * 1つのオファーを受け入れることを許可する。これは _ダイレクト_ モードと呼ばれます。
 * 2つの異なるオファー、1つは与えられた`NFToken`の購入を提案し、もう1つは同じ`NFToken`の売却を提案し、アトミックに受け入れられることを許可します。これは _ブローカー_ モードと呼ばれます。

-_([NonFungibleTokensV1_1 amendment][]が必要です)_
+_([NonFungibleTokensV1_1 amendment][]により追加されました)_


 ## ブローカー vs. ダイレクト モード
--- a/content/references/protocol-reference/transactions/transaction-types/nftokenburn.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-types/nftokenburn.ja.md
@@ -13,7 +13,7 @@ NFTokenBurnトランザクションは、`NFToken`オブジェクトを保持し

 この操作に成功すると、対応する`NFToken`が削除されます。この操作によって`NFToken`を保持している`NFTokenPage`が空になるか、統合されて`NFTokenPage`が削除されると、所有者準備金が1つ減ります。

-_([NonFungibleTokensV1_1 amendment][]が必要です)_
+_([NonFungibleTokensV1_1 amendment][]により追加されました)_


 ## {{currentpage.name}} JSONの例
--- a/content/references/protocol-reference/transactions/transaction-types/nftokencanceloffer.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-types/nftokencanceloffer.ja.md
@@ -21,7 +21,7 @@ labels:
 }
 ```

-_([NonFungibleTokensV1_1 amendment][]が必要です)_
+_([NonFungibleTokensV1_1 amendment][]により追加されました)_


 ## アクセス権
--- a/content/references/protocol-reference/transactions/transaction-types/nftokencreateoffer.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-types/nftokencreateoffer.ja.md
@@ -12,7 +12,7 @@ labels:

 成功した場合、トランザクションは[NFTokenOfferオブジェクト][]を作成します。各オファーは、オファーを提示したアカウントの[所有者準備金](reserves.html)に関連づけて1つのオブジェクトとしてカウントされます。

-_([NonFungibleTokensV1_1 amendment][]が必要です)_
+_([NonFungibleTokensV1_1 amendment][]により追加されました)_

 ## {{currentpage.name}} JSONの例

--- a/content/references/protocol-reference/transactions/transaction-types/nftokenmint.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-types/nftokenmint.ja.md
@@ -10,7 +10,7 @@ labels:

 `NFTokenMint`トランザクションは非代替性トークンを作成し、`NFTokenMinter`に紐付く[NFTokenPageオブジェクト][]に[NFToken][]オブジェクトとして追加します。このトランザクションの必須パラメータは`Token`フィールドで、実際のトークンを指定します。このトランザクションは`NFTokenMinter`にとって、不変と定義されているトークンフィールド(例えば`Flags`)を設定することができる唯一の方法です。

-_([NonFungibleTokensV1_1 amendment][]が必要です)_
+_([NonFungibleTokensV1_1 amendment][]により追加されました)_


 ## {{currentpage.name}} JSONの例
--- a/content/references/protocol-reference/transactions/transaction-types/payment.ja.md
+++ b/content/references/protocol-reference/transactions/transaction-types/payment.ja.md
@@ -66,7 +66,7 @@ Paymentトランザクションタイプは、いくつかの異なるタイプ

 ## SendMaxおよびAmountで使用する特殊なissuerの値

-ほとんどの場合、XRP以外の[通貨額][]の`issuer`フィールドは、金融機関の[発行アドレス](issuing-and-operational-addresses.html)を示しています。ただし、支払いを記述するにあたって、支払いの`Amount`フィールドと`SendMax`フィールドにある`issuer`フィールドについては、特殊なルールが存在します。
+ほとんどの場合、XRP以外の[通貨額][]の`issuer`フィールドは、金融機関の[発行アドレス](account-types.html)を示しています。ただし、支払いを記述するにあたって、支払いの`Amount`フィールドと`SendMax`フィールドにある`issuer`フィールドについては、特殊なルールが存在します。

 * 2つのアドレス間で、同一の通貨に関して存在する残高は常に1つです。つまり、金額の`issuer`フィールドが実際に表しているのは、イシュアンスを作成したアドレスではなく、イシュアンスを換金する相手方であることがあります。
 * 宛先`Amount`フィールドの`issuer`フィールドが`Destination`アドレスと一致している場合、「宛先が受け入れるあらゆるイシュアー」を意味する特殊なケースとして取り扱われます。これには、他のトラストラインで保持されている宛先によって作成されたイシュアンスに加え、宛先が当該アドレスまでトラストラインを延長しているすべてのアドレスが含まれます。
@@ -105,7 +105,7 @@ Payment型のトランザクションについては、[`Flags`フィールド](

 ## Partial Payments

-Partial Paymentsを利用すると、受取られる金額を減額することによって、支払いを成功させることができます。Partial Paymentsが有用なのは、追加的なコストを発生させずに[支払いを返金](become-an-xrp-ledger-gateway.html#bouncing-payments)する場合です。その一方で、成功したトランザクションの`Amount`フィールドに、送金された金額が常に正しく記述されていることを前提としている環境において、悪用されるおそれもあります。
+Partial Paymentsを利用すると、受取られる金額を減額することによって、支払いを成功させることができます。Partial Paymentsが有用なのは、追加的なコストを発生させずに[支払いを返金](stablecoin-issuer.html#bouncing-payments)する場合です。その一方で、成功したトランザクションの`Amount`フィールドに、送金された金額が常に正しく記述されていることを前提としている環境において、悪用されるおそれもあります。

 Partial Paymentsとは、**tfPartialPayment**フラグが有効になっている[Paymentトランザクション][]です。Partial Paymentsは、`SendMax`値を超える金額を送金することなく、`DeliverMin`フィールド以上の正の金額（`DeliverMin`が指定されていない場合、任意の正の金額）を送金する場合に成功します。

--- a/content/references/protocol-reference/transactions/transaction-types/payment.md
+++ b/content/references/protocol-reference/transactions/transaction-types/payment.md
@@ -51,17 +51,17 @@ Payments are also the only way to [create accounts](#creating-accounts).

 ## Types of Payments

-The Payment transaction type is a general-purpose tool that can represent several different types of abstract actions. You can identify the transaction type based on the transaction's fields, as described in the table below:
+The `Payment` transaction type functions differently depending on how you fill in the `Payment` fields:

 | Payment type | `Amount`  | `SendMax`  | `Paths`   | `Address` = `Destination`? | Description |
 |:-------------|:----------|:-----------|:----------|:---------------------------|:--|
-| [Direct XRP-to-XRP Payment][] | String (XRP) | Omitted | Omitted | No          | Transfers XRP directly from one account to another. Always delivers the exact amount. No fee applies other than the basic [transaction cost](transaction-cost.html). |
+| [Direct XRP Payment][] | String (XRP) | Omitted | Omitted | No          | Transfers XRP directly from one account to another, using one transaction. Always delivers the exact amount. No fee applies other than the basic [transaction cost](transaction-cost.html). |
 | [Creating or redeeming tokens][] | Object | Object (optional) | Optional | No | Increases or decreases the amount of a non-XRP currency or asset tracked in the XRP Ledger. [Transfer fees](transfer-fees.html) and [freezes](freezes.html) do not apply when sending and redeeming directly. |
-| [Cross-currency Payment][] | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Send tokens from one holder to another. The `Amount` or `SendMax` can be XRP or tokens, but they cannot both be XRP. These payments [ripple through](rippling.html) the issuer and can take longer [paths](paths.html) through several intermediaries if the transaction specifies a path set. [Transfer fees](transfer-fees.html) set by the issuer(s) apply to this type of transaction. These transactions consume offers in the [decentralized exchange](decentralized-exchange.html) to connect between different currencies, or possibly even between currencies with the same currency code and different issuers. |
+| [Cross-currency Payment][] | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Send tokens from one holder to another. The `Amount` or `SendMax` can be XRP or tokens, but can't both be XRP. These payments [ripple through](rippling.html) the issuer and can take longer [paths](paths.html) through several intermediaries if the transaction specifies a path set. [Transfer fees](transfer-fees.html) set by the issuer(s) apply to this type of transaction. These transactions consume offers in the [decentralized exchange](decentralized-exchange.html) to connect different currencies, or currencies with the same currency code and different issuers. |
 | [Partial payment][] | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Sends _up to_ a specific amount of any currency. Uses the [`tfPartialPayment` flag](#payment-flags). May include a `DeliverMin` amount specifying the minimum that the transaction must deliver to be successful; if the transaction does not specify `DeliverMin`, it can succeed by delivering _any positive amount_. |
-| Currency conversion | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Required         | Yes | Consumes offers in the [decentralized exchange](decentralized-exchange.html) to convert one currency to another, possibly taking [arbitrage](https://en.wikipedia.org/wiki/Arbitrage) opportunities. The `Amount` and `SendMax` cannot both be XRP. Also called a _circular payment_ because it delivers money to the sender. The [Data API](data-api.html) tracks this type of transaction as an "exchange" and not a "payment". |
+| Currency conversion | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Required         | Yes | Consumes offers in the [decentralized exchange](decentralized-exchange.html) to convert one currency to another, possibly taking [arbitrage](https://en.wikipedia.org/wiki/Arbitrage) opportunities. The `Amount` and `SendMax` cannot both be XRP. Also called a _circular payment_ because it delivers money to the sender. This type of transaction may be classified as an "exchange" and not a "payment". |

-[Direct XRP-to-XRP Payment]: direct-xrp-payments.html
+[Direct XRP Payment]: direct-xrp-payments.html
 [Creating or redeeming tokens]: tokens.html
 [Cross-currency Payment]: cross-currency-payments.html
 [Partial payment]: partial-payments.html
@@ -110,7 +110,7 @@ Transactions of the Payment type support additional values in the [`Flags` field

 ## Partial Payments

-A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for [returning payments](become-an-xrp-ledger-gateway.html#bouncing-payments) without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the `Amount` field of a successful transaction always describes the exact amount delivered.
+A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for [returning payments](stablecoin-issuer.html#bouncing-payments) without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the `Amount` field of a successful transaction always describes the exact amount delivered.

 A partial payment is any [Payment transaction][] with the `tfPartialPayment` flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its `DeliverMin` field (or any positive amount at all if `DeliverMin` is not specified) without sending more than the `SendMax` value.

--- a/content/references/protocol-reference/transactions/transaction-types/paymentchannelclaim.md
+++ b/content/references/protocol-reference/transactions/transaction-types/paymentchannelclaim.md
@@ -56,7 +56,7 @@ The **destination address** of a channel can:
 | `Signature` | String    | Blob              | _(Optional)_ The signature of this claim, as hexadecimal. The signed message contains the channel ID and the amount of the claim. Required unless the sender of the transaction is the source address of the channel. |
 | `PublicKey` | String    | Blob              | _(Optional)_ The public key used for the signature, as hexadecimal. This must match the `PublicKey` stored in the ledger for the channel. Required unless the sender of the transaction is the source address of the channel and the `Signature` field is omitted. (The transaction includes the public key so that `rippled` can check the validity of the signature before trying to apply the transaction to the ledger.) |

-If the payment channel was created before the [fixPayChanRecipientOwnerDir amendment](known-amendments.html#fixpaychanrecipientownerdir) became enabled (on 2020-05-01), it is possible that the destination of the payment channel has been [deleted](accounts.html#deletion-of-accounts) and does not currently exist in the ledger. If the destination has been deleted, the source account cannot send XRP from the channel to the destination; instead, the transaction fails with `tecNO_DST`. (And, of course, the deleted account cannot send any transactions at all.) Other uses of this transaction type are unaffected when the destination account has been deleted, including adjusting the channel expiration, closing a channel with no XRP, or removing a channel that has passed its expiration time.
+If the payment channel was created before the [fixPayChanRecipientOwnerDir amendment](known-amendments.html#fixpaychanrecipientownerdir) became enabled (on 2020-05-01), it is possible that the destination of the payment channel has been [deleted](deleting-accounts.html) and does not currently exist in the ledger. If the destination has been deleted, the source account cannot send XRP from the channel to the destination; instead, the transaction fails with `tecNO_DST`. (And, of course, the deleted account cannot send any transactions at all.) Other uses of this transaction type are unaffected when the destination account has been deleted, including adjusting the channel expiration, closing a channel with no XRP, or removing a channel that has passed its expiration time.


 ## PaymentChannelClaim Flags
--- a/content/references/protocol-reference/transactions/transaction-types/paymentchannelfund.md
+++ b/content/references/protocol-reference/transactions/transaction-types/paymentchannelfund.md
@@ -10,7 +10,7 @@ labels:

 _Added by the [PayChan amendment][]._

-Add additional [XRP](xrp.html) to an open [payment channel](payment-channels.html), and optionally update the expiration time of the channel. Only the source address of the channel can use this transaction.
+Add additional [XRP](what-is-xrp.html) to an open [payment channel](payment-channels.html), and optionally update the expiration time of the channel. Only the source address of the channel can use this transaction.

 Example PaymentChannelFund: