Reorg tokens & stablecoin use case

wip

fix links

fix 2 links

trim and add topics

Add checklist, rename sc subtopics

Fix internal links

Add DEX/AMM

Add graphics

reorg files

reorg/rename

Fix blurb

Remove old JA files

edits per review

review changes

rename output file name of index files to match the folder name

Update output file and parent filenames

add reusable links snippet

fix broken links

Update Ja file

Move path.md to same location in i18n folder

Revert naming for nft-collections page

Rename to match files in En and Ja

update links to reflect updated file name

Rename nft-auctions under Ja folder and update links throughout

Rename nftoken-authorized-minting and update links throughout

Fix links

Rename the nft-fixed-supply Ja file to match the reorg in English  and update links

Move nft-reserve-requirements file in Ja and update links

Fix some more broken links

Fix more broken links by renaming html files back

Stablecoin reorg: fix various issues

Remove nfts_by_issuer method (unreleased) page

Remove redundant parent: attrs from config file

Fix syntax highlighting of Authorizing Another Minter js

Fix config/frontmatter errors

content/@i18n/ja/concepts/payment-types/partial-payments.md

@@ -8,7 +8,7 @@ labels:
 ---
 # Partial Payment
 
-デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](stablecoin-issuer.html#不明な入金の返金)したい場合に便利です。
+デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](bouncing-payments.html)したい場合に便利です。
 
 [トランザクションコスト](transaction-cost.html)に使用されるXRPの額は、トランザクションタイプに関わらず常に送金元のアカウントから差し引かれます。
 
@@ -113,6 +113,6 @@ Partial Payment以外の場合、トランザクションのメタデータの`d
 - 「顧客確認」のガイドラインに従い、顧客の身元情報を厳密に検証します。不正使用者を事前に認識して阻止したり、システムを悪用した不正使用者に対して法的措置を講じたりすることができます。
 
 <!--{# 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' %}

content/@i18n/ja/concepts/tokens/fungible-tokens/authorized-trust-lines.md

@@ -1,6 +1,6 @@
 ---
 html: authorized-trust-lines.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: 認可トラストラインとは、トークンを保有できる人を制限するための設定です。
 labels:
   - トークン
@@ -125,6 +125,6 @@ POST http://localhost:8088/
     - [RippleState (トラストライン) フラグ](ripplestate.html#ripplestateのフラグ)
 
 <!--{# 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' %}

content/@i18n/ja/concepts/tokens/fungible-tokens/clawing-back-tokens.md

@@ -1,6 +1,6 @@
 ---
 html: clawing-back-tokens.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: 発行者は、トークンを発行する前にClawback機能を有効にすると、規制遵守の目的でトークンを取り戻すことができます。
 labels:
   - トークン
@@ -37,6 +37,6 @@ Clawback機能はデフォルトで無効になっています。使用するに
 このトランザクションが成功した場合、rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9Sが発行し、rsA2LpzuawewSBQXkiju3YQTMzW13pAAdWが保有する最大314.159FOOを回収することになります。
 
 <!--{# 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' %}

content/@i18n/ja/concepts/tokens/fungible-tokens/demurrage.md

@@ -1,6 +1,6 @@
 ---
 html: demurrage.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。.
 status: removed
 ---

content/@i18n/ja/concepts/tokens/fungible-tokens/freezes.md

@@ -1,6 +1,6 @@
 ---
 html: freezes.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: 発行者はコンプライアンス目的でトークンの取引を停止できます。
 labels:
   - トークン
@@ -98,6 +98,6 @@ No Freeze設定は、アドレスのマスターキーのシークレットキ
     - [RippleState(trust line)フラグ](ripplestate.html#ripplestateのフラグ)
 
 <!--{# 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' %}

content/@i18n/ja/concepts/tokens/fungible-tokens/paths.md

@@ -1,6 +1,6 @@
 ---
 html: paths.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: トークンによる支払いは、接続されているユーザーのパスとオーダーブックを通す必要があります。
 labels:
   - 支払い
@@ -113,6 +113,6 @@ XRPは任意のアドレスに直接送金できるため、[XRP間のトラン
   - [ripple_path_findメソッド][]
 
 <!--{# 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' %}

content/@i18n/ja/concepts/tokens/fungible-tokens/rippling.md

@@ -1,6 +1,6 @@
 ---
 html: rippling.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: Ripplingは、複数当事者間でのトークン残高の自動ネット決済です。
 labels:
   - トークン

content/@i18n/ja/concepts/tokens/nfts/authorizing-another-minter.md

@@ -14,7 +14,7 @@ labels:
 
 認可Minterを`AccountSet`トランザクションで設定します。
 
-``` json
+```js
 tx_json = {
   "TransactionType": "AccountSet",
   "Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
@@ -31,7 +31,7 @@ tx_json = {
 
 認可Minterを削除するには、`AccountSet`トランザクションを使用して、`asfAuthorizedNFTokenMinter`フラグをクリアしてください。
 
-``` json
+```js
 tx_json = {
   "TransactionType": "AccountSet",
   "Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
@@ -43,7 +43,7 @@ tx_json = {
 
 標準的な `NFTokenMint` トランザクションを使用して、別のアカウントのNFTをMintすることができます。違いは、`Issuer`フィールド、つまりNFTをMintするアカウントのIDを含める必要があることです。
 
-```json
+```js
 const transactionBlob = {
   "TransactionType": "NFTokenMint",
   "Account": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",

content/@i18n/ja/concepts/tokens/nfts/index.md

@@ -77,6 +77,6 @@ XRP Ledgerでは、容量を節約するために、一つのアカウントで
     - [nft_info メソッド][] (Clioサーバのみ)
 
 <!--{# 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' %}

content/@i18n/ja/concepts/tokens/nfts/trading.md

@@ -79,6 +79,6 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました)_
 
 
 <!--{# 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' %}

content/@i18n/ja/concepts/tokens/transfer-fees.md

@@ -80,6 +80,6 @@ XRPは発行者が存在しないため、送金手数料がかかることは
 
 
 <!--{# 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' %}

content/@i18n/ja/references/protocol/data-types/nftoken.md

@@ -53,7 +53,7 @@ E) 32ビットの（自動生成される）単調増加するのシーケンス
 |:------------------|:-----------|:--------------------------------------------|
 | `lsfBurnable`     | `0x0001`   | 設定されている場合、発行者（または発行者が許可したエンティティ）が`NFToken`を破棄できることを示します。オブジェクトの所有者は常に破棄することができます。 |
 | `lsfOnlyXRP`      | `0x0002`   | 設定されている場合、`NFToken`はXRPに対してのみオファーまたは売却できることを示します。 |
-| `lsfTrustLine`    | `0x0004`   | **廃止予定** 設定されている場合、送金手数料を保持するための[トラストライン](trust-lines-and-issuing.html)を自動的に作成します。設定されていない場合、発行者がそのトークンのトラストラインを持っていない場合、この`NFToken`をそのトークンで売買することは失敗します。[fixRemoveNFTokenAutoTrustLine amendment][]により、このフラグは利用できなくなります。|
+| `lsfTrustLine`    | `0x0004`   | **廃止** 設定されている場合、送金手数料を保持するための[トラストライン](trust-lines-and-issuing.html)を自動的に作成します。設定されていない場合、発行者がそのトークンのトラストラインを持っていない場合、この`NFToken`をそのトークンで売買することは失敗します。[fixRemoveNFTokenAutoTrustLine amendment][]により、このフラグは利用できなくなります。|
 | `lsfTransferable` | `0x0008`   | 設定されている場合、この`NFToken`は所有者から別の所有者に転送することができます。設定されていない場合、所有者は発行者との間でのみ譲渡が可能です。 |
 | `lsfReservedFlag` | `0x8000`   | 将来の使用に備えて確保されています。このフラグを設定しようとすると失敗します。 |
 

content/@i18n/ja/tutorials/manage-account-settings/offline-account-setup.md

@@ -343,6 +343,6 @@ Loading: "/etc/opt/ripple/rippled.cfg"
 
 
 <!--{# 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' %}

content/@i18n/ja/use-cases/tokenization/authorized-minter.md

@@ -74,12 +74,12 @@ NFTを出品する際、オブジェクトのメタデータを使って分類
 
 関連項目:
 
-- [Clioのセットアップ](install-clio-on-ubuntu.html) 
+- [Clioのセットアップ](install-clio-on-ubuntu.html)
 - [XRPL Data API](https://api.xrpldata.com/docs/static/index.html#/)
 - [Bithomp](https://docs.bithomp.com/#nft-xls-20)
 
-<!-- 
-[Clio setup](install-clio-on-ubuntu.html) 
+<!--
+[Clio setup](install-clio-on-ubuntu.html)
 
 [https://api.xrpldata.com/docs/static/index.html#/](https://api.xrpldata.com/docs/static/index.html#/)
 

content/@i18n/ja/use-cases/tokenization/nft-mkt-overview.md

@@ -106,7 +106,7 @@ XRPL NFTの最もシンプルな支払い方法はXRPです。XRPを使ったNFT
 
 他の通貨での取引は、DEXを活用してあらゆる種類の発行通貨を受け入れ、取引することができます。[分散型取引所での取引](trade-in-the-decentralized-exchange.html#trade-in-the-decentralized-exchange)をご覧ください。
 
-<!-- 
+<!--
 
 - Fiat payment ([Cross-currency payments](cross-currency-payments.html))
 - On-chain validation of completing transactions [No link- isn’t this just a cross-currency payment?] (Query after the transaction is completed.]
@@ -118,12 +118,12 @@ NFTを出品する際、オブジェクトのメタデータを使って分類
 
 関連項目:
 
-- [Clioのセットアップ](install-clio-on-ubuntu.html) 
+- [Clioのセットアップ](install-clio-on-ubuntu.html)
 - [XRPL Data API](https://api.xrpldata.com/docs/static/index.html#/)
 - [Bithomp](https://docs.bithomp.com/#nft-xls-20)
 
 
-<!-- 
+<!--
 Sorting and filtering [No link]
     Creator - nft_info (issuer field)
     Price - nft_sell_offer->offers->amount field)
@@ -142,7 +142,7 @@ Supplement Information [No link]
  -->
 
 ## NFTのキャッシュ
-<!-- 
+<!--
 
 Image optimization for web experience [No link]
 
@@ -158,9 +158,9 @@ CloudflareやInfuraをはじめとする多くのプロバイダが、こうし
 
 [NFTのキャッシュ](nftoken.html#nftokenデータとメタデータの取得)をご覧ください。
 
-<!-- 
-You can also consider a solution such as Pinata. [https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing](https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing) 
+<!--
+You can also consider a solution such as Pinata. [https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing](https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing)
 
-We can derive inspiration for the need of caching and point to some of their docs 
-[https://docs.pinata.cloud/gateways](https://docs.pinata.cloud/gateways) 
+We can derive inspiration for the need of caching and point to some of their docs
+[https://docs.pinata.cloud/gateways](https://docs.pinata.cloud/gateways)
  -->

content/@i18n/ja/use-cases/tokenization/nftoken-marketplace.md

@@ -9,7 +9,7 @@ labels:
 
 _NFTokenマーケットプレイスでは、XRPLを利用して、厳選されたNFTokenを消費者に譲渡するためのWeb上のサービスを提供し、ブランド構築と売上に応じた仲介手数料を得ることができるというメリットを得ることができるようになります。_
 
---- 
+---
 
 NFTokenマーケットプレイスは、NFTokenクリエイターとコレクターの仲介役となります。マーケットプレイスの運営は、NFTokenのクリエイターを探し出し、販売するアイテムを集めます。購入者は、あなたのサイトを訪れ、選択されたアイテムを確認し、オファーを提示します。あなたは、クリエイターが設定した最低価格と購入者から提示された最適な価格を照合し、トランザクションを完了させ、仲介手数料を受け取ります。
 
@@ -74,11 +74,11 @@ NFTを出品する際、オブジェクトのメタデータを使って分類
 
 関連項目:
 
-- [Clioのセットアップ](install-clio-on-ubuntu.html) 
+- [Clioのセットアップ](install-clio-on-ubuntu.html)
 - [XRPL Data API](https://api.xrpldata.com/docs/static/index.html#/)
 - [Bithomp](https://docs.bithomp.com/#nft-xls-20)
 
-<!-- 
+<!--
 
 Sorting and filtering [No link]
     Creator - nft_info (issuer field)

content/@i18n/ja/use-cases/tokenization/stablecoin-issuer.md

@@ -44,7 +44,7 @@ XRP Ledgerには分散型取引所があり、どのユーザもXRPとトーク
 
 分散型取引所の詳細については、[分散型取引所](decentralized-exchange.html)をご覧ください。
 
-<!-- TODO: figure out what to do with this 
+<!-- TODO: figure out what to do with this
 Liquidity providers can use the [HTTP / WebSocket APIs](http-websocket-apis.html), [client libraries](client-libraries.html), or another application to access the distributed exchange. It may also help client applications to display information about your business if you provide an [`xrp-ledger.toml` file](xrp-ledger-toml.html).
 -->
 

content/concepts/payment-types/bouncing-payments.md

@@ -0,0 +1,18 @@
+---
+html: bouncing-payments.html
+parent: payment-types.html
+blurb: When the purpose of a payment is unclear, return it to the sender.
+labels:
+  - Tokens
+---
+# Bouncing Payments
+
+When one of your addresses receives a payment whose purpose is unclear, we recommend that you try to return the money to its sender. While this is more work than pocketing the money, it demonstrates good faith towards customers. You can have an operator bounce payments manually, or create a system to do so automatically.
+
+The first requirement to bouncing payments is [robustly monitoring for incoming payments](robustly-monitoring-for-payments.html). You do not want to accidentally refund a customer for more than they sent you! (This is particularly important if your bounce process is automated.) Malicious users can take advantage of a naive integration by sending [partial payments](partial-payments.html#partial-payments-exploit).
+
+Second, you should send bounced payments as Partial Payments. Since third parties can manipulate the cost of pathways between addresses, Partial Payments allow you to divest yourself of the full amount without being concerned about exchange rates within the XRP Ledger. You should publicize your bounced payments policy as part of your terms of use. Send the bounced payment from either an operational address or a standby address.
+
+To send a Partial Payment, enable the [`tfPartialPayment` flag](payment.html#payment-flags) on the transaction. Set the `Amount` field to the amount you received and omit the `SendMax` field. You should use the `SourceTag` value from the incoming payment as the `DestinationTag` value for the return payment.
+
+To prevent two systems from bouncing payments back and forth indefinitely, you can set a new Source Tag for the outgoing return payment. If you receive an unexpected payment whose Destination Tag matches the Source Tag of a return you sent, then do not bounce it back again.

content/concepts/payment-types/partial-payments.md

@@ -10,7 +10,7 @@ labels:
 
 The sender of any [Payment transaction][] can enable the ["Partial Payment" flag](payment.html#payment-flags) and send a payment which delivers less than the `Amount` field indicates. When processing any Payment, use the `delivered_amount` metadata field, not the `Amount` field. The `delivered_amount` is the amount a payment actually delivered.
 
-If a Payment does not enable the Partial Payment flag, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the amount to deliver after charging for exchange rates and [transfer fees](transfer-fees.html). The Partial Payment flag ([`tfPartialPayment`](payment.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](stablecoin-issuer.html#bouncing-payments) without incurring additional costs to oneself.
+If a Payment does not enable the Partial Payment flag, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the amount to deliver after charging for exchange rates and [transfer fees](transfer-fees.html). The Partial Payment flag ([`tfPartialPayment`](payment.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](bouncing-payments.html) without incurring additional costs to oneself.
 
 The amount of XRP used for the [transaction cost](transaction-cost.html) is always deducted from the sender’s account, regardless of the type of transaction. This transaction cost, or fee, is not included in the `Amount`.
 

content/concepts/payment-types/robustly-monitoring-for-payments.md

@@ -0,0 +1,26 @@
+---
+html: robustly-monitoring-for-payments.html
+parent: payment-types.html
+blurb: Recommendations for monitoring incoming payments for a variety of possible irregularities.
+labels:
+  - Tokens
+---
+# Robustly Monitoring for Payments
+
+To robustly check for incoming payments, issuers should do the following:
+
+* Keep a record of the most-recently-processed transaction and ledger. That way, if you temporarily lose connectivity, you know how far to go back.
+* Check the result code of every incoming payment. Some payments go into the ledger to charge an anti-spam fee, even though they failed. Only transactions with the result code `tesSUCCESS` can change non-XRP balances. Only transactions from a validated ledger are final.
+* Look out for [Partial Payments](partial-payments.html). Payments with the partial payment flag enabled can be considered "successful" if any non-zero amount is delivered, even minuscule amounts.
+    * Check the transaction for a [`delivered_amount` field](partial-payments.html#the-delivered_amount-field). If present, that field indicates how much money _actually_ got delivered to the `Destination` address.
+    * In xrpl.js, you can use the [`xrpl.getBalanceChanges()` method](https://js.xrpl.org/modules.html#getBalanceChanges) to see how much each address received. In some cases, this can be divided into multiple parts on different trust lines.
+* Some transactions change your balances without being payments directly to or from one of your addresses.
+
+To make things simpler for your customers, we recommend accepting payments to both your operational address and your issuing addresses.
+
+As an added precaution, we recommend comparing the balances of your issuing address with the collateral funds in your internal accounting system as of each new XRP Ledger ledger version. The issuing address's negative balances should match the assets you have allocated to XRP Ledger outside the network. If the two do not match up, then you should suspend processing payments into and out of the XRP Ledger until you have resolved the discrepancy.
+
+* Use the `gateway_balances` method to check your balances.
+* If you have a Transfer Fee set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your tokens among themselves.
+
+For more details on how to read the details of incoming transactions, see [Look Up Transaction Results](look-up-transaction-results.html).

content/concepts/payment-types/sending-payments-to-customers.md

@@ -0,0 +1,24 @@
+---
+html: sending-payments-to-customers.html
+parent: payment-types.html
+blurb: Construct payments carefully to thwart malicious actors.
+labels:
+  - Tokens
+---
+# Sending Payments to Customers
+
+When you build an automated system to send payments into the XRP Ledger for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find ways to trick a system into paying them more money than it should.
+
+Generally, when sending stablecoins, you use a [Payment transaction][]. Some of the details are different depending on whether you are issuing tokens for the first time or transferring them from a hot wallet to a customer. Things to note include:
+
+- When issuing new tokens from your issuing address, you should omit the `SendMax` field. Otherwise, malicious users can arrange their settings so that you issue the full `SendMax` amount instead of just the intended destination `Amount`.
+- When sending tokens _from a hot wallet_, you must specify `SendMax` if you have a nonzero transfer fee. In this case, set the `SendMax` field to the amount specified in the `Amount` field plus the transfer fee. (You may want to round up slightly, in case the precision of your calculations doesn't exactly match the XRP Ledger's.) For example, if you send a transaction whose `Amount` field specifies 99.47 USD, and your transfer fee is 0.25%, you should set the `SendMax` field to 124.3375, or 124.34 USD if you round up.
+- Omit the `Paths` field. This field is unnecessary when sending directly from the issuer, or from a hot wallet as long as the tokens being sent and the tokens being received have the same currency code and issuer—that is, they're the same stablecoin. The `Paths` field is intended for [Cross-Currency Payments](cross-currency-payments.html) and longer multi-hop (rippling) payments. If you naively perform pathfinding and attach the paths to your transaction, your payment may take a more expensive indirect route rather than failing if the direct path is not available; malicious users can even set this up to 
+- If you get a `tecPATH_DRY` result code, this usually indicates that either the customer doesn't have the necessary trust line set up already, or your issuer's rippling settings aren't configured correctly.
+
+For a detailed tutorial on issuing a token on the XRP Ledger, whether a stablecoin or otherwise, see [Issue a Fungible Token](issue-a-fungible-token.html).
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/decentralized-exchange/index.md

@@ -2,7 +2,7 @@
 html: decentralized-exchange.html
 parent: tokens.html
 template: pagetype-category.html.jinja
-blurb: The XRP Ledger contains a fully-functional exchange where users can trade tokens for XRP or each other.
+blurb: The XRP Ledger contains a fully functional exchange where users can trade tokens for XRP or each other.
 targets:
   - en
 ---

content/concepts/tokens/fungible-tokens/authorized-trust-lines.md

@@ -1,6 +1,6 @@
 ---
 html: authorized-trust-lines.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: Authorized trust lines is a setting to limit who can hold a token.
 labels:
   - Tokens
@@ -129,6 +129,6 @@ In the response's `result.lines` array, find the object whose `currency` field i
     - [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
 
 <!--{# 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' %}

content/concepts/tokens/fungible-tokens/clawing-back-tokens.md

@@ -1,6 +1,6 @@
 ---
 html: clawing-back-tokens.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: Issuers can claw back their tokens for compliance purposes if they enable the Clawback feature before issuing tokens.
 labels:
   - Tokens
@@ -17,7 +17,7 @@ Issuers can gain the ability to claw back their tokens by enabling the **Allow C
 
 Clawback is disabled by default. To use clawback, you must send an [AccountSet transaction][] to enable the **Allow Trust Line Clawback** setting. **An issuer with any existing tokens cannot enable Clawback.** You can only enable **Allow Trust Line Clawback** if you have a completely empty owner directory, meaning you must do so before you set up any trust lines, offers, escrows, payment channels, checks, or signer lists.
 
-If you attempt to set `lsfAllowTrustLineClawback` while `lsfNoFreeze` is set, the transaction returns `tecNO_PERMISSION`, because clawback cannot be enabled on an account that has already disclaimed the ability to freeze trust lines. 
+If you attempt to set `lsfAllowTrustLineClawback` while `lsfNoFreeze` is set, the transaction returns `tecNO_PERMISSION`, because clawback cannot be enabled on an account that has already disclaimed the ability to freeze trust lines.
 Conversely, if you try to set `lsfNoFreeze` while `lsfAllowTrustLineClawback` is set, the transaction also returns `tecNO_PERMISSION`.
 
 ## Example Clawback Transaction
@@ -37,6 +37,6 @@ Conversely, if you try to set `lsfNoFreeze` while `lsfAllowTrustLineClawback` is
 If successful, this transaction would claw back at most 314.159 FOO issued by rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9S and held by rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW.
 
 <!--{# common link defs #}-->
-{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}			
-{% include '_snippets/rippled_versions.md' %}
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/fungible-tokens/demurrage.md

@@ -1,6 +1,6 @@
 ---
 html: demurrage.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: (Obsolete) Some older XRP Ledger tools used to support currency codes with built-in interest and negative interest rates.
 status: removed
 ---

content/concepts/tokens/fungible-tokens/freezes.md

@@ -1,6 +1,6 @@
 ---
 html: freezes.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: Issuers can freeze their issued tokens for compliance purposes.
 labels:
   - Tokens
@@ -98,6 +98,6 @@ You can only enable the No Freeze setting with a transaction signed by your addr
     - [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
 
 <!--{# 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' %}

content/concepts/tokens/fungible-tokens/index.md

@@ -5,20 +5,27 @@ blurb: Learn about the properties and rationale of trust lines.
 labels:
   - Tokens
 ---
-# Trust Lines and Issuing
+# Fungible Tokens
 
-Trust lines are structures in the XRP Ledger for holding [tokens](tokens.html). Trust lines enforce the XRP Ledger's rule that you cannot cause someone else to hold a token they don't want. This precaution is necessary to enable the XRP Ledger's use case for [community credit](tokens.html#community-credit) among other benefits.
+Anyone can issue fungible tokens on the XRP Ledger, ranging from informal "IOUs" to fiat-backed stablecoins, purely digital fungible and semi-fungible tokens, and more.
+
+Fungible tokens are interchangeable and indistinguishable from one another. They can be swapped and substituted for other tokens of equivalent value. To create fungible tokens, you set up a _trust line_, a form of accounting relationship, between two accounts, then send payments between them. For most use cases, there are also some settings you should configure first.
+
+## Trust Lines
+
+Trust lines are structures in the XRP Ledger for holding fungible [tokens](tokens.html). Trust lines enforce the XRP Ledger's rule that you cannot cause someone else to hold a token they don't want. This precaution is necessary to enable the XRP Ledger's use case for [community credit](tokens.html#community-credit) among other benefits.
 
 Each "trust line" is a _bidirectional_ relationship consisting of:
 
-- The identifiers for the **two [accounts](accounts.html)** that the trust line connects.
-- A single, shared **balance**, which is positive from the perspective of one account and negative from the other perspective.
+- The identifiers for the two [accounts](accounts.html) that the trust line connects.
+- A single, shared balance, which is positive from the perspective of one account and negative from the other perspective.
     - The account with a negative balance is generally considered the "issuer" of the tokens. However, in the [APIs](http-websocket-apis.html), the name `issuer` can refer to either side.
-- Various **settings** and metadata. _Each_ of the two accounts can control its own settings on the trust line.
-    - Most importantly, each side sets a **limit** on the trust line, which is 0 by default. Each account's balance (from its perspective on the trust line) can't go above that account's limit, except [through that account's own actions](#going-above-the-limit).
+- Various settings and metadata. _Each_ of the two accounts can control its own settings on the trust line.
+    - Most importantly, each side sets a limit on the trust line, which is 0 by default. Each account's balance (from its perspective on the trust line) can't go above that account's limit, except [through that account's own actions](#going-above-the-limit).
 
 Each trust line is specific to a given [currency code][]. Two accounts can have any number of trust lines between them for different currency codes, but only one shared trust line for any particular currency code.
 
+The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html) on trust lines to prevent those trust lines from rippling.
 
 ## Creation
 

content/concepts/tokens/fungible-tokens/paths.md

@@ -1,6 +1,6 @@
 ---
 html: paths.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: Payments of tokens must traverse paths of connected users and order books.
 labels:
   - Payments
@@ -116,6 +116,6 @@ The `type` field, used for the binary serialization of a path set, is actually c
 
 
 <!--{# 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' %}

content/concepts/tokens/fungible-tokens/rippling.md

@@ -1,6 +1,6 @@
 ---
 html: rippling.html
-parent: tokens.html
+parent: trust-lines-and-issuing.html
 blurb: Rippling is automatic multi-party net settlement of token balances.
 labels:
   - Tokens

content/concepts/tokens/fungible-tokens/stablecoins/compliance-guidelines.md

@@ -0,0 +1,124 @@
+---
+html: stablecoin-compliance-guidelines.html
+parent: stablecoins.html
+blurb: Stablecoin issuers are responsible for complying with local regulations and reporting to appropriate agencies.
+labels:
+  - Tokens
+---
+# Stablecoin Compliance Guidelines
+
+Stablecoin issuers are responsible for complying with local regulations and reporting to the appropriate agencies. Regulations vary by country and state, but may include the reporting and compliance requirements described in the following sections. Before issuing a token, you should seek professional legal advice on the requirements for your jurisdiction and use case. The following resources may be useful background reading.
+
+### Know Your Customer (KYC)
+
+Know Your Customer (KYC) refers to due diligence activities conducted by a financial institution to determine and verify the identity of its customers to prevent use of the institution for criminal activity. Criminal activity in financial terms may include money laundering, terrorist financing, financial fraud, and identity theft. Customers may be individuals, intermediaries, or businesses.
+
+The KYC process generally aims to:
+
+- Identify the customer (and, in the case of organizations and businesses, any beneficial owners)
+
+- Understand the purpose and intended nature of the business relationship
+
+- Understand the expected transaction activity.
+
+KYC is critical for financial institutions and related businesses to mitigate risk, especially legal and reputational risk. Having an inadequate or nonexistent KYC program may result in civil and criminal penalties for the institution or individual employees.
+
+See also:
+
+- [(USA) Bank Secrecy Act / Anti-Money Laundering Examination Manual](https://bsaaml.ffiec.gov/manual/Introduction/01)
+
+- [The Non-US Standard on KYC set by the Financial Action Task Force (FATF)](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+
+<!-- SPELLING_IGNORE: ffiec -->
+
+### Anti-Money Laundering (AML) and Combating the Financing of Terrorism (CFT)
+
+Money laundering is the process of moving illegal funds by disguising the source, nature or ownership so that funds can be legally accessed or distributed via legitimate financial channels and credible institutions. In short, it is converting “dirty money” into “clean money.” Anti-Money Laundering (AML) refers to the laws and procedures designed to stop money laundering from occurring.
+
+Terrorist financing is the solicitation, collection, or provision of funds to organizations engaged in terrorist activity or organizations that support terrorism and its proliferation. Combating the Financing of Terrorism (CFT) refers to the process of identifying, reporting, and blocking flows of funds used to finance terrorism.
+
+See also:
+
+- [“International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation.” FATF, 2012](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+
+- [“Virtual Currencies: Key Definitions and Potential AML/CFT Risks.” FATF, 2014](http://www.fatf-gafi.org/publications/methodsandtrends/documents/virtual-currency-definitions-aml-cft-risk.html)
+
+<!-- SPELLING_IGNORE: fatf, cft -->
+
+### Source of Funds
+
+To prevent illicit funds from passing through their systems, financial institutions must be able to determine within reason if the source of a customer’s funds is linked to criminal activity.
+
+Determining the exact source of funds for every customer may not be administratively feasible. As a result, some regulatory authorities may not provide specific regulation or guidance for all accounts. In specific cases, however, authorities may require financial institutions to identify and report the source of funds. Guidance by the FATF recommends that where the risks of money laundering or terrorist financing are higher (commonly referred to as a “risk-based approach”), financial institutions conduct enhanced due diligence, including but not limited to determining the customer’s source of funds.
+
+<!-- STYLE_OVERRIDE: feasible -->
+
+### Suspicious Activity Reporting
+
+If a financial institution suspects that funds may be related to criminal activity, the institution must file a Suspicious Activity Report (SAR) with the appropriate regulatory authority. Failure to report suspicious activity may result in in penalties for the institution.
+
+See also:
+
+- [Suspicious Activity Reporting Overview (USA FFIEC)](https://bsaaml.ffiec.gov/manual/RegulatoryRequirements/04_ep)
+
+- [FATF Recommendation 16: Reporting of suspicious transactions and compliance](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+
+### Travel Rule
+
+The Travel Rule is a Bank Secrecy Act (BSA) rule requiring funds-transmitting financial institutions to forward certain information to the next financial institution if the funds transmittal equals or exceeds the USD equivalent of $3,000. The following information must be included in the transmittal order:
+
+- The name of the transmittor,
+- The account number of the transmittor, if used,
+- The address of the transmittor,
+- The identity of the transmittor's financial institution,
+- The amount of the transmittal order,
+- The execution date of the transmittal order, and
+- The identity of the recipient's financial institution.
+
+<!-- SPELLING_IGNORE: transmittor -->
+
+See also:
+
+- [Funds “Travel” Regulations: Questions & Answers ](https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers)
+
+### Fee Disclosure and Tracing Funds
+
+- In the United States, Dodd Frank 1073 Electronic Fund Transfer Act (Regulation E) requires banks to provide information on cost and delivery terms for international payments originating in the US including exchange rate, fees, and the amount to be received by the designated recipient in the foreign country. "Pre-payment disclosure" is provided to a consumer when requesting an international electronic payment and “receipt disclosure” is provided to a consumer at the time consumer authorizes the transfer.
+
+    See also:
+
+    - [The Consumer Financial Protection Bureau description of the regulation and extensions for banks](https://www.consumerfinance.gov/rules-policy/final-rules/electronic-fund-transfers-regulation-e/#rule)
+
+- In the European Union, EU Funds Transfer Regulation requires that the originator’s bank, the beneficiary’s bank, and any intermediary banks include certain details of the payer and payee in transaction details to detect, investigate, and prevent money laundering and terrorist financing.
+
+    See also:
+
+    - [EU Regulation (EC) No 1781/2006 description](http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:345:0001:0009:EN:PDF)
+
+    - [Effective June 26, 2017: Regulation 2015/847 on information accompanying transfers of funds](http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32015R0847)
+
+### Office of Foreign Assets Control (OFAC)
+
+The Office of Foreign Assets Control (OFAC) is an agency of the US Department of Treasury that administers and enforces economic and trade sanctions in support of U.S. foreign policy and national security objectives. All U.S. persons and U.S. incorporated entities and their foreign branches must follow OFAC regulations. Under OFAC regulations, U.S. financial institutions are prohibited—unless authorized by OFAC or expressly exempted by statute—from conducting transactions and other dealings with individuals, entities, or countries under sanctions or embargo programs administered and enforced by OFAC.
+
+See also:
+
+- [A list of OFAC resources](https://www.treasury.gov/resource-center/faqs/Sanctions/Pages/ques_index.aspx)
+
+<!-- SPELLING_IGNORE: ofac -->
+
+### Guidance on Virtual Currency and Money Service Business
+
+- United States:
+
+    - [FinCEN Guidance and Definitions around Virtual Currency, March 18, 2013](https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-persons-administering)
+
+    - [FinCEN Publishes Two Rulings on Virtual Currency Miners and Investors, January 30, 2014](https://www.fincen.gov/news/news-releases/fincen-publishes-two-rulings-virtual-currency-miners-and-investors)
+
+- Europe:
+
+    - [European Banking Authority Opinion on Virtual Currencies, July 4, 2014](http://www.eba.europa.eu/documents/10180/657547/EBA-Op-2014-08+Opinion+on+Virtual+Currencies.pdf)
+
+- FATF Guidance for Money Service Businesses:
+
+    - [Financial Action Task Force, July 2009](http://www.fatf-gafi.org/media/fatf/documents/reports/Guidance-RBA-money-value-transfer-services.pdf)

content/concepts/tokens/fungible-tokens/stablecoins/configuration.md

@@ -0,0 +1,91 @@
+---
+html: stablecoin-configuration.html
+parent: stablecoins.html
+blurb: Configure your stablecoin to fine tune its capabilities.
+labels:
+  - Tokens
+---
+# Stablecoin Configuration
+
+There are some settings you must configure on your XRP Ledger account before you start issuing tokens. For examples of how to configure these settings, see [Issue a Fungible Token](issue-a-fungible-token.html).
+
+Settings you might want to configure include:
+
+| Setting | Notes |
+|---------|-------|
+| Default Ripple | Issuers must enable this field. |
+| Deposit Authorization | Block all incoming payments from users you haven't explicitly approved. |
+| Require Auth | Restrict your tokens to being held by users you've explicitly approved. |
+| Tick Size | Round off exchange rates in the decentralized exchange to facilitate faster price discovery. |
+| Transfer Fee | Charge a percentage fee when users send your token to each other. |
+
+
+## Default Ripple
+
+The Default Ripple flag controls whether the balances on a trust line are allowed to _ripple_ by default. Rippling is what allows customers to send and trade tokens among themselves, so an issuer MUST allow rippling on all the trust lines to its issuing address. See [Rippling](rippling.html).
+
+Before asking customers to create trust lines to its issuing address, an issuer should enable the Default Ripple flag on that address. Otherwise, the issuer must individually disable the No Ripple flag for each trust line that other addresses have created.
+
+
+## Deposit Authorization
+
+The Deposit Authorization setting blocks all incoming payments to your account, unless either:
+
+- You have previously preauthorized the sender.
+- You send a transaction to receive the funds. For example, you could finish an Escrow that was initiated by a stranger.
+
+Deposit Authorization is most useful for blocking unwanted XRP payments, because you already can't receive tokens unless you've created a trust line to their issuer. However, as a stablecoin issuer, you need to be able to receive payments from users in order for them to redeem the stablecoin for its off-ledger value; you can preauthorize your customers but doing so requires storing an object in the ledger for each custom address, increasing your reserve requirement substantially.
+
+Therefore, Deposit Authorization is not recommended for stablecoin issuers unless you need it to meet regulatory requirements about receiving money from unknown or sanctioned entities.
+
+For more information, see [Deposit Authorization](depositauth.html).
+
+
+## Disallow XRP
+
+The Disallow XRP setting is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments from addresses that aren't intended to receive and hold XRP. The Disallow XRP flag is not enforced at the protocol level, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the Disallow XRP flag by default, but may allow users to ignore it.
+
+The Disallow XRP flag is optional, but if you don't intend to receive XRP from customers you may want to enable it on your issuing address and all your operational addresses.
+
+
+## Require Auth
+
+The Require Auth setting blocks users from holding the tokens you issue unless you explicitly approve their trust lines first. You can use this setting to meet regulatory requirements if it matters who holds your tokens within the XRP Ledger. However, this can reduce the utility of your tokens since your approval becomes a bottleneck for users to use them.
+
+Also, you must use your issuing address each time you authorize a trust line; if you must authorize a lot of trust lines, this can undermine the security of your issuing address because you have to use it so often. (If you only need to use the issuing address sparingly, you can put greater protections on its secret keys. The more often you use it, the more of a burden those protections become.)
+
+For more information, see [Authorized Trust Lines](authorized-trust-lines.html).
+
+
+## Tick Size
+
+The Tick Size setting controls how many decimal places are used when calculating exchange rates in the [Decentralized Exchange](decentralized-exchange.html). A higher Tick Size means more precision and less rounding in the amounts of various trades. Too much precision can be inconvenient because trades are ranked primarily based on exchange rate, so a trader can offer a minuscule amount more to the top of the list. A smaller Tick Size works similar to the minimum bid increment at an auction, saving everyone the time and effort of gradually bidding up a price by irrelevantly small amounts. However, a smaller Tick Size results in more rounding, which can increase the costs of trading, and sometimes has surprising results because two Offers that seemed like an exact match before rounding no longer match after rounding.
+
+The Tick Size is an account-level setting and applies to all tokens issued by the same address.
+
+Tick Size only controls the precision of _exchange rates_, not the precision of the token itself. Users can send and hold very large or very small amounts regardless of the Tick Size set by the token's issuer.
+
+For more information, see [Tick Size](ticksize.html).
+
+
+## Transfer Fees
+
+A transfer fee setting charges users a percentage fee when sending your tokens to each other. The transfer fee does not apply when issuing tokens or redeeming them directly with the issuing address. (It _does_ apply when users send payments to your hot wallet.) If you issue multiple tokens from the same address, the same transfer fee applies to all of them.
+
+When users send a token with a transfer fee, the amount of the transfer fee is debited from the sending side in addition to the destination amount, but only the destination amount is credited to the recipient. The amount of the fee "vanishes" from the XRP Ledger. As a stablecoin issuer, this means that you gain that much equity in your reserves outside of the XRP Ledger—or, in other words, the amount you need to keep as collateral decreases each time users pay a transfer fee.
+
+At a protocol level, the transfer fee is defined by the `TransferRate` account setting, which is an integer from 1 billion to 2 billion.
+
+For more information, see [Transfer Fees](transfer-fees.html).
+
+
+### Transfer Fees with Operational and Standby Addresses
+
+All XRP Ledger addresses, including operational and standby addresses, are subject to the issuer's transfer fees when sending tokens. If you set a nonzero transfer fee, then you must send extra (to pay the transfer fee) when making payments from your operational address or standby address. In other words, your addresses must pay back a little of the balance your issuing address created, each time you make a payment.
+
+Set the `SendMax` transaction parameter higher than the destination `Amount` parameter by a percentage based on the `TransferRate` setting.
+
+**Note:** Transfer fees do not apply when sending tokens directly from or to the issuing address. The issuing address must always accept its tokens at face value in the XRP Ledger. This means that customers don't have to pay the transfer fee if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the transfer fee the customer pays.
+
+For example: If ACME sets a transfer fee of 1%, an XRP Ledger payment to deliver 5 EUR.ACME from a customer address to ACME's issuing address would cost exactly 5 EUR.ACME. However, the customer would need to send 5.05 EUR.ACME to deliver 5 EUR.ACME to ACME's operational address. When ACME credits customers for payments to ACME's operational address, ACME credits the customer for the amount delivered to the operational address _and_ the transfer fee, giving the customer €5,05 in ACME's systems.
+

content/concepts/tokens/fungible-tokens/stablecoins/index.md

@@ -0,0 +1,37 @@
+---
+html: stablecoins.html
+parent: trust-lines-and-issuing.html
+blurb: There are five common types of stablecoin traded on the XRP Ledger.
+labels:
+  - XRP
+  - Stablecoin
+---
+# Stablecoins
+
+A Stablecoin holds assets of value outside of the XRP Ledger and issues tokens representing the equivalent value on the ledger. This type of issuer is sometimes called a _gateway_, because currency can move into and out of the XRP Ledger through their service. If the assets that back a token use the same amounts and denomination as the tokens in the ledger, that token can be considered a "stablecoin" because – in theory – the exchange rate between that token and its off-ledger representation should be stable at 1:1.
+
+A stablecoin issuer should offer _deposits_ and _withdrawals_ to exchange the tokens for the actual currency or asset in the world outside the XRP Ledger.
+
+In practice, the XRP Ledger is a computer system that cannot enforce any rules outside of itself, so stablecoins on the XRP Ledger depend on their issuer's integrity. If you can't count on the stablecoin's issuer to redeem your tokens for the real thing on demand, then you shouldn't expect the stablecoin to hold its value. As a user, you should be mindful of who's issuing the tokens: are they reliable, lawful, and solvent? If not, it's probably best not to hold those tokens.
+
+There are five common types of currency token traded on the XRP Ledger.
+
+## Fiat Backed
+
+Fiat-backed stablecoins are based on an existing currency such as EUR, USD, YEN, and so on. They are backed at an exchange rate of 1:1. It is a simple, stable option, but it is more centralized and susceptible to hacking. In the strictest definition of a "stablecoin", only 100% fiat-backed tokens qualify.
+
+## Crypto Backed
+
+Crypto-backed stablecoins are similar to fiat-backed stablecoins, but set aside a certain amount of cryptocurrency as collateral. It's decentralized, doesn't require a custodian or audits and regulation. It's also more volatile, and reliant on the stability of the underlying cryptocurrency.
+
+## Commodity Backed
+
+Commodity-backed stablecoins are based on a fungible asset such as gold, real estate, oil,  or electricity. Commodities are relatively stable and liquid, but are centralized and require regular audits to verify their value.
+
+## Financial Instrument Backed
+
+A stablecoin can be backed by financial instruments such as bonds or equity shares.
+
+## Non-collateralized
+
+A non-collateralized token relies on algorithm-generated smart contracts to supply or sell tokens, similar to a central bank's approach to printing and destroying currency. No collateral is required to mint tokens. Value is controlled by supply and demand through algorithms that stabilize the price. Non-collateralized tokens are typically not considered stablecoins, due to their volatility.

content/concepts/tokens/fungible-tokens/stablecoins/precautions.md

@@ -0,0 +1,23 @@
+---
+html: stablecoin-precautions.html
+parent: stablecoins.html
+blurb: Precautions to consider when transferring stablecoin funds in and out of the XRPL.
+labels:
+  - Tokens
+---
+# Stablecoin Precautions
+
+Processing payments to and from the XRP Ledger naturally comes with some risks, so an issuer should be sure to take care in implementing these processes. As a stablecoin issuer, you should consider the following precautions:
+
+- Protect yourself against reversible deposits. XRP Ledger payments are irreversible, but many digital payments are not. Scammers can abuse this to take their fiat money back by canceling a deposit after receiving tokens in the XRP Ledger.
+- When sending into the XRP Ledger, always specify your issuing address as the issuer of the token. Otherwise, you might accidentally use paths that deliver the same currency issued by other addresses.
+- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any transfer fee you have set.
+- Before processing a payment out of the XRP Ledger, make sure you know the customer's identity. This makes it harder for anonymous attackers to scam you. Most anti-money-laundering regulations require this anyway. This is especially important because the users sending money from the XRP Ledger could be different than the ones that initially received the money in the XRP Ledger.
+- Follow the guidelines for reliable transaction submission when sending XRP Ledger transactions.
+- Robustly monitor for incoming payments, and read the correct amount. Don't mistakenly credit someone the full amount if they only sent a [partial payment](partial-payments.html). See [Robustly monitoring for payments](robustly-monitoring-for-payments.html).
+- Track your obligations and balances within the XRP Ledger, and compare with the assets in your collateral account. If they do not match up, stop processing withdrawals and deposits until you resolve the discrepancy.
+- Avoid ambiguous situations. We recommend the following:
+    - Enable the `Disallow XRP` flag for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.)
+    - Enable the [`RequireDest` flag](require-destination-tags.html) for the issuing address and all operational addresses, so customers do not accidentally send a payment without the destination tag to indicate who should be credited.
+    - Enable the `RequireAuth` flag on all operational addresses so they cannot issue tokens by accident.
+- Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments.

content/concepts/tokens/fungible-tokens/stablecoins/settings.md

@@ -0,0 +1,98 @@
+---
+html: stablecoin-settings.html
+parent: stablecoins.html
+blurb: Settings to configure before issuing your stablecoin.
+labels:
+  - XRP
+  - Stablecoin
+---
+# Stablecoin Settings
+
+Before you mint your new stablecoin, you need to configure settings, some of which are immutable once you issue the first coin.
+
+## Create Your Issuing and Distribution Accounts
+
+Create a new account that you designate as the _issuer_, sometimes called the "cold" wallet. There is nothing different or special about the account itself, only the way you use it. Use the account to mint your stablecoins.
+
+Many implementations use a _standby_ account as a "warm" wallet. Trusted human operators use the standby account to distribute stablecoins to _operational_ accounts.
+
+<div align="center">
+<img src="img/uc-stablecoin-distribution-flow.png" height="50%" width="50%"></image>
+</div>
+
+Operational accounts, or "hot" wallets, trade with other accounts on the XRPL. Automated, internet-connected systems use the secret keys to these addresses to conduct day-to-day business like transfers to customers and partners.
+
+Using standby and operational accounts helps to insulate the issuing account against hacking attacks, and also makes it easier to monitor the creation and destruction of your stablecoins.
+
+
+## Set Your Transfer Fee
+
+A transfer fee setting charges users a percentage fee when transferring tokens between accounts.
+
+When users send a token with a transfer fee, the amount of the transfer fee is debited from the sending side in addition to the destination amount, but only the destination amount is credited to the recipient. The amount of the fee "vanishes" from the XRP Ledger. As a stablecoin issuer, this means that you gain that much equity in your reserves outside of the XRP Ledger—or, in other words, the amount you need to keep as collateral decreases each time users pay a transfer fee.
+
+For more information, see [Transfer Fees](transfer-fees.html).
+
+
+## Set Your Tick Size
+
+The Tick Size setting controls how many decimal places are used when calculating exchange rates in the [Decentralized Exchange](decentralized-exchange.html). A higher Tick Size (more decimal places) means more precision and less rounding in the amounts of various trades. A smaller Tick Size works similar to the minimum bid increment at an auction, saving everyone the time and effort of gradually bidding up a price by unreasonably small amounts.
+
+The Tick Size is an account-level setting and applies to all tokens issued by the same address.
+
+See [Tick Size](ticksize.html).
+
+
+## Set the Default Ripple Flag
+
+The Default Ripple flag controls whether the balances on a trust line are allowed to _ripple_ by default. Rippling is what allows customers to send and trade tokens among themselves. An issuer MUST allow rippling on all the trust lines to its issuing address.
+
+Before asking customers to create trust lines to your issuing address, enable the Default Ripple flag on that address. Otherwise, you must individually disable the No Ripple flag for each trust line that other addresses have created.
+
+See [Rippling](rippling.html).
+
+
+## Enable Destination Tags
+
+If your stablecoin application handles transactions on behalf of several customers, it might not be immediately obvious to which account you should credit. Destination tags help to avoid this situation by requiring the sender to specify the beneficiary or destination for a payment. To enable the `RequireDest` flag, set the `asfRequireDest` value (1) in the `SetFlag` field of an `AccountSet` transaction. See [Source and Destination Tags](source-and-destination-tags.html).
+
+## Asset Control Features
+
+You have several options for controlling the creation and distribution of your stablecoins.
+
+
+### Authorized Trust Lines
+
+When you need to follow compliance rules such as Know Your Customer (KYC) and Anti-Money Laundering (AML), you can use trust lines to create permissioned pools for the distribution of your stablecoin. This allows you to be certain to whom the funds are transferred.
+
+See [Authorized Trust Lines](authorized-trust-lines.html).
+
+
+### Freeze Flags
+
+You have the ability to freeze your stablecoins in your holder accounts. You might do this when you suspect fraudulent activity, or to enforce holds. You can freeze individual trust lines, or enact a global freeze of all activity.
+
+Conversely, you can set the No Freeze feature, which permanently gives up the ability to freeze tokens. This makes your stablecoin more like fiat currency, in the sense that you cannot interfere with counterparties trading the tokens among themselves.
+
+See [Freezing Tokens](freezes.html).
+
+
+### Clawback Flags
+
+_(Requires the [Clawback amendment](known-amendments.html#clawback) :not_enabled:)_
+
+Clawback allows you to retrieve, or _clawback_, stablecoins from a trust line under specific circumstances. This gives you added ability to respond to challenges such as lost account access or malicious activity.
+
+See [Clawback](clawback.html).
+
+
+### Fixed Supply
+
+Restricting your stablecoins to a fixed number guarantees that stablecoin value will not be diluted in the future if you decide to issue more tokens.
+
+To create a fixed supply:
+
+1. Create a distribution wallet with settings similar to your issuing wallet.
+2. Set up a trust line between the issuing wallet and the distribution wallet.
+3. Send all tokens from the issuing wallet to the distribution wallet.
+4. Black hole the issuing account.

content/concepts/tokens/fungible-tokens/stablecoins/technical-details.md

@@ -0,0 +1,105 @@
+---
+html: stablecoin-technical-details.html
+parent: stablecoins.html
+blurb: Issue your own stablecoin, based on assets of equal value outside of the XRP Ledger.
+labels:
+  - Tokens
+---
+
+# Stablecoin Technical Details
+
+## Infrastructure
+
+For your own security as well as the stability of the network, each XRP Ledger business should [run its own XRP Ledger servers](install-rippled.html), including one [validator](rippled-server-modes.html#validators).
+
+
+### APIs and Middleware
+
+There are several interfaces you can use to connect to the XRP Ledger, depending on your needs and your existing software:
+
+- [HTTP / WebSocket APIs](http-websocket-apis.html) can be used as a low-level interface to all core XRP Ledger functionality.
+- [Client Libraries](client-libraries.html) are available in several programming languages to provide convenient utilities for accessing the XRP Ledger.
+- Other tools such as [xApps](https://xumm.readme.io/docs/xapps) are also available.
+- Third party wallet applications might also be useful, especially for humans in charge of standby addresses.
+
+
+## Tool Security
+
+Any time you submit an XRP Ledger transaction, it must be signed using your secret key. The secret key gives full control over your XRP Ledger address. Never send your secret key to a server run by someone else. Either use your own server, or sign the transactions locally using a client library.
+
+For instructions and examples of secure configurations, see [Set Up Secure Signing](secure-signing.html).
+
+
+## Robustly Monitoring for Payments
+
+To robustly check for incoming payments, issuers should do the following:
+
+* Keep a record of the most-recently-processed transaction and ledger. That way, if you temporarily lose connectivity, you know how far to go back.
+* Check the result code of every incoming payment. Some payments go into the ledger to charge an anti-spam fee, even though they failed. Only transactions with the result code `tesSUCCESS` can change non-XRP balances. Only transactions from a validated ledger are final.
+* Look out for [Partial Payments](partial-payments.html). Payments with the partial payment flag enabled can be considered "successful" if any non-zero amount is delivered, even minuscule amounts.
+    * Check the transaction for a [`delivered_amount` field](partial-payments.html#the-delivered_amount-field). If present, that field indicates how much money *actually* got delivered to the `Destination` address.
+    * In xrpl.js, you can use the [`xrpl.getBalanceChanges()` method](https://js.xrpl.org/modules.html#getBalanceChanges) to see how much each address received. In some cases, this can be divided into multiple parts on different trust lines.
+* Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero transfer fee, then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's tokens.
+
+To make things simpler for your customers, we recommend accepting payments to both your operational address and your issuing addresses.
+
+As an added precaution, we recommend comparing the balances of your issuing address with the collateral funds in your internal accounting system as of each new ledger version. The issuing address's negative balances should match the assets you have allocated to XRP Ledger outside the network. If the two do not match up, then you should suspend processing payments into and out of the XRP Ledger until you have resolved the discrepancy.
+
+* Use the `gateway_balances` method to check your balances.
+* If you have a Transfer Fee set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your tokens among themselves.
+
+For more details on how to read the details of incoming transactions, see [Look Up Transaction Results](look-up-transaction-results.html).
+
+
+## Sending Payments to Customers
+
+When you build an automated system to send payments into the XRP Ledger for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find ways to trick a system into paying them more money than it should.
+
+Generally, when sending stablecoins, you use a Payment transaction. Some of the details are different depending on whether you are issuing tokens for the first time or transferring them from a hot wallet to a customer. Things to note include:
+
+- When issuing new tokens from your issuing address, you should omit the `SendMax` field. Otherwise, malicious users can arrange their settings so that you issue the full `SendMax` amount instead of just the intended destination `Amount`.
+- When sending tokens from a hot wallet, you must specify `SendMax` if you have a nonzero transfer fee. In this case, set the `SendMax` field to the amount specified in the `Amount` field plus the transfer fee. (You may want to round up slightly, in case the precision of your calculations doesn't exactly match the XRP Ledger's. For example, if you send a transaction whose `Amount` field specifies 99.47 USD, and your transfer fee is 0.25%, you should set the `SendMax` field to 124.3375, or 124.34 USD, if you round up.)
+- Omit the `Paths` field. This field is unnecessary when sending directly from the issuer, or from a hot wallet as long as the tokens being sent and the tokens being received have the same currency code and issuer—that is, they're the same stablecoin. The `Paths` field is intended for cross-currency payments and longer multi-hop (rippling) payments. If you  perform pathfinding and attach the paths to your transaction, your payment might take a more expensive indirect route rather than failing if the direct path is not available; malicious users can even set this up to fail.
+- If you get a `tecPATH_DRY` result code, this usually indicates that either the customer doesn't have the necessary trust line set up already, or your issuer's rippling settings aren't configured correctly.
+
+For a detailed tutorial on issuing a token on the XRP Ledger, whether a stablecoin or otherwise, see [Issue a Fungible Token](issue-a-fungible-token.html).
+
+
+## Bouncing Payments
+
+When one of your addresses receives a payment where the purpose is unclear, we recommend that you try to return the money to its sender. While this is more work than pocketing the money, it demonstrates good faith towards customers. You can have an operator bounce payments manually, or create a system to do so automatically.
+
+The first requirement to bouncing payments is [robustly monitoring for incoming payments](#robustly-monitoring-for-payments). You do not want to accidentally refund a customer for more than they sent you! (This is particularly important if your bounce process is automated.) Malicious users can take advantage of a naive integration by sending [partial payments](partial-payments.html#partial-payments-exploit).
+
+Second, you should send bounced payments as Partial Payments. Since third parties can manipulate the cost of pathways between addresses, Partial Payments allow you to divest yourself of the full amount without being concerned about exchange rates within the XRP Ledger. You should publicize your bounced payments policy as part of your terms of use. Send the bounced payment from either an operational address or a standby address.
+
+To send a Partial Payment, enable the [`tfPartialPayment` flag](payment.html#payment-flags) on the transaction. Set the `Amount` field to the amount you received and omit the `SendMax` field. You should use the `SourceTag` value from the incoming payment as the `DestinationTag` value for the return payment.
+
+To prevent two systems from bouncing payments back and forth indefinitely, you can set a new Source Tag for the outgoing return payment. If you receive an unexpected payment whose Destination Tag matches the Source Tag of a return you sent, then do not bounce it back again.
+
+
+## Reliable Transaction Submission
+
+The goal of reliably submitting transactions is to achieve the following two properties in a finite amount of time:
+
+* Idempotency - Transactions should be processed once and only once, or not at all.
+* Verifiability - Applications can determine the final result of a transaction.
+
+To submit transactions reliably, follow these guidelines:
+
+* Persist details of the transaction before submitting it.
+* Use the `LastLedgerSequence` parameter. (Many [client libraries](client-libraries.html) do this by default.)
+* Resubmit a transaction if it has not appeared in a validated ledger whose [ledger index][] is less than or equal to the transaction's `LastLedgerSequence` parameter.
+
+For more information, see [Reliable Transaction Submission](reliable-transaction-submission.html).
+
+
+## xrp-ledger.toml File
+
+You can publish information about what currencies you issue, and which XRP Ledger addresses you control, to protect against impostors or confusion, using an [`xrp-ledger.toml` file](xrp-ledger-toml.html). This machine-readable format is convenient for client applications to process. If you run an XRP Ledger validator, you can also publish the key in the same file.
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/index.md

@@ -0,0 +1,53 @@
+---
+html: tokens.html
+parent: concepts.html
+blurb: Anyone can make tokens representing digital value on the XRP Ledger.
+labels:
+  - Tokens
+---
+# Tokens
+
+All assets other than XRP can be represented in the XRP Ledger as _tokens_.
+
+Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Tokens can be used for [cross-currency payments](cross-currency-payments.html) and can be traded in the [decentralized exchange](decentralized-exchange.html).
+
+**Note:** Tokens on the XRP Ledger have also been called "IOUs" (as in [I-owe-you](https://en.wikipedia.org/wiki/IOU)) and "issued currencies" in the past. However, these terms are not preferred because they do not cover the full range of digital assets that XRP Ledger tokens can represent. <!-- STYLE_OVERRIDE: ious -->
+
+Tokens can also be non-fungible. Non-fungible tokens (NFTs) serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
+
+See [Fungible Tokens](trust-lines-and-issuing.html) and [Non-fungible Tokens](non-fungible-tokens.html).
+
+## Stablecoins
+
+Stablecoins are a common model for tokens in the XRP Ledger. The issuer holds assets of  value outside of the XRP Ledger, and issues tokens representing the equivalent value on the ledger.
+
+See [Stablecoins](stablecoins.html).
+
+## Community Credit
+
+Another way you can use the XRP Ledger is for "community credit", a system where individuals who know each other can use the XRP Ledger to track who owes whom how much money. One feature of the XRP Ledger is that it can automatically and atomically use these debts to settle payments through [rippling](rippling.html).
+
+For more on this type of usage, see [paths](paths.html). <!--{# TODO: It would be nice to be able to link to a page with more illustrative examples of community credit. #}-->
+
+## Other Tokens
+
+There are other use cases for tokens issued in the XRP Ledger. For example, you can create an "Initial Coin Offering" (ICO) by issuing a fixed amount of currency to a secondary address, then "throwing away the key" to the issuer.
+
+**Warning:** ICOs might be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. <!-- SPELLING_IGNORE: ico, icos -->
+
+Be sure to research the relevant regulations before engaging in any financial service business.
+
+## Token Properties
+
+Tokens in the XRP Ledger are fundamentally different than XRP. Tokens always exist in _trust lines_, and all transfers of tokens move along trust lines. You cannot cause someone else's account to hold more of a token than the _limit_ configured on their trust line. (You _can_ cause your own trust line to go over the limit, for example by buying more of it in the decentralized exchange or by decreasing the limit after you already have a positive balance.)
+
+Anyone can issue tokens by sending a [Payment transaction][] if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, cross-currency payments or trades can also create more tokens according to an issuer's settings.
+
+Issuers have options with tokens that are not available with XRP. Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a [tick size](ticksize.html) for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezes.html) trust lines, which limits how the tokens in those trust lines can be used.
+
+Tokens use decimal (base-10) math with 15 digits of precision and an exponent that allows them to express very large values (up to 9999999999999999 × 10<sup>80</sup>) and very small values (down to 1.0 × 10<sup>-81</sup>).
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/nftoken-batch-minting.md

@@ -1,39 +0,0 @@
----
-html: nftoken-batch-minting.html
-parent: non-fungible-tokens.html
-blurb: Minting NFToken objects in batches.
-labels:
- - Non-fungible Tokens, NFTs
----
-
-# Batch minting
-
-There are two common approaches to minting NFToken objects in batches: mint on demand and scripted minting.
-
-## Mint On Demand (Lazy Minting)
-
-When using a mint on demand model, you and potential customers make buy or sell offers for initial sales of a NFToken object off the XRP Ledger. When you are ready to start the initial sale, you mint the token, create a sell offer or accept a buy offer, then complete the transaction.
-
-### Benefits
-
-* There is no reserve requirement for holding unsold NFToken objects.
-* You mint NFToken objects in real time when you know that it will sell. <!-- STYLE_OVERRIDE: will -->
-
-### Downside
-
-Any market activity before the initial sale of the NFToken object is not recorded on the XRP Ledger. This might not be an issue for some applications.
-
-## Scripted Minting
-
-Use a program or script to mint many tokens at once. You might find that [Tickets](tickets.html) help you submit transactions in parallel, up to a current limit of 200 transactions in one group.
-
-For a practical example, see the [Batch Mint NFTs Using JavaScript](batch-mint-nfts-using-javascript.html) tutorial.
-
-### Benefits
-
-* NFToken objects are minted ahead of time
-* Market activity for the initial sale of the NFToken object is captured on the ledger
-
-### Downside
-
-You need to meet the [reserve requirement](reserves.html) for all of the `NFToken` objects you mint. As a rule of thumb, this is roughly 1/12th XRP per NFToken object at the current reserve rate. In the event that you do not have enough XRP in reserve, your mint transactions fail until you get more XRP.

content/concepts/tokens/nfts/authorizing-another-minter.md

@@ -5,7 +5,7 @@ blurb: You can assign another account to mint NFTs in your stead.
 labels:
  - Non-fungible Tokens, NFTs
 ---
-# Authorizing Another Account to Mint Your NFTs
+# Authorizing Another Minter
 
 Each account can have 0 or 1 authorized minter that can mint NFTs on its behalf. By authorizing a minter, a creator can allow a different account to mint NFTs for them, which allows them to focus on making more NFTs.
 
@@ -13,9 +13,9 @@ Each account can have 0 or 1 authorized minter that can mint NFTs on its behalf.
 
 You set the authorized minter with an `AccountSet` transaction.
 
-``` json
+```js
 tx_json = {
-  "TransactionType": "AccountSet",    
+  "TransactionType": "AccountSet",
   "Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
   "NFTokenMinter": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
   "SetFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
@@ -30,7 +30,7 @@ tx_json = {
 
 To remove an authorized minter, use the `AccountSet` transaction and clear the `asfAuthorizedNFTokenMinter` flag.
 
-``` json
+```js
 tx_json = {
   "TransactionType": "AccountSet",
   "Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
@@ -42,7 +42,7 @@ tx_json = {
 
 You mint tokens for another account using the standard `NFTokenMint` transaction. The difference is that you must include the `Issuer` field, the account ID of the account for which you are minting the NFT.
 
-```json
+```js
 const transactionBlob = {
   "TransactionType": "NFTokenMint",
   "Account": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",

content/concepts/tokens/nfts/batch-minting.md

@@ -0,0 +1,39 @@
+---
+html: nftoken-batch-minting.html
+parent: non-fungible-tokens.html
+blurb: Minting NFTs in batches.
+labels:
+ - Non-fungible Tokens, NFTs
+---
+
+# Batch Minting
+
+There are two common approaches to minting NFTs in batches: mint on demand and scripted minting.
+
+## Mint On Demand (Lazy Minting)
+
+When using a mint on demand model, you and potential customers make buy or sell offers for initial sales of an NFT off the XRP Ledger. When you are ready to start the initial sale, you mint the token, create a sell offer or accept a buy offer, then complete the transaction.
+
+### Benefits
+
+* There is no reserve requirement for holding unsold NFTs.
+* You mint NFTs in real time when you know that it will sell. <!-- STYLE_OVERRIDE: will -->
+
+### Downside
+
+Any market activity before the initial sale of the NFT is not recorded on the XRP Ledger. This might not be an issue for some applications.
+
+## Scripted Minting
+
+Use a program or script to mint many tokens at once. You might find that [Tickets](tickets.html) help you submit transactions in parallel, up to a current limit of 200 transactions in one group.
+
+For a practical example, see the [Batch Mint NFTs Using JavaScript](batch-mint-nfts-using-javascript.html) tutorial.
+
+### Benefits
+
+* NFTs are minted ahead of time.
+* Market activity for the initial sale of the NFT is captured on the ledger.
+
+### Downside
+
+You need to meet the [reserve requirement](reserves.html) for all of the NFTs you mint. As a rule of thumb, this is roughly 1/12th XRP per NFT at the current reserve rate. In the event that you do not have enough XRP in reserve, your mint transactions fail until you get more XRP.

content/concepts/tokens/nfts/index.md

@@ -0,0 +1,46 @@
+---
+html: non-fungible-tokens.html
+parent: tokens.html
+blurb: Introduction to XRPL NFTs.
+labels:
+ - Non-fungible Tokens, NFTs
+---
+
+# Non-Fungible Tokens
+
+The XRP Ledger natively supports non-fungible tokens (NFTs, or “nifties” in the vernacular).  Non-fungible tokens serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
+
+_(Added by the [NonFungibleTokensV1_1 amendment][].)_
+
+To represent digital assets similar to these, use the XRP Ledger's Non-Fungible Tokens feature (sometimes referred to by its standards draft number, [XLS-20](https://github.com/XRPLF/XRPL-Standards/discussions/46)).
+
+## NFTs on the XRP Ledger
+
+On the XRP Ledger, an NFT is represented as a [NFToken][] object. An NFT is a unique, indivisible unit that is not used for payments. Users can mint (create), hold, buy, sell, and burn (destroy) NFTs.
+
+The ledger stores up to 32 NFTa owned by the same account in a single [NFTokenPage object][] to save space. As a result, the owner's [reserve requirement](reserves.html) for NFTs only increases when the ledger needs to make a new page to store additional tokens.
+
+Accounts can also name a _Broker_ or an _Authorized Minter_ who can sell or mint NFTs on their behalf.
+
+NFTs have several immutable settings that are defined when the token is minted. These include:
+
+- Identifying data that uniquely defines the token.
+- Whether the issuer can burn the token, regardless of who currently holds it.
+- Whether the holder of the token can transfer it to others. (An NFT can always be sent to or from the issuer directly.)
+- If transfers are allowed, the issuer can charge a transfer fee as a percentage of the sale price.
+- Whether the holder can sell the NFT for [fungible token](trust-lines-and-issuing.html) amounts, or only for XRP.
+
+## NFT Lifecycle
+
+Anyone can create a new NFT using the [NFTokenMint transaction][]. The NFT lives on the [NFTokenPage object][] of the issuing account. Either the owner or an interested party can send a [NFTokenCreateOffer transaction][] to propose buying or selling the NFT; the ledger tracks the proposed transfer as a [NFTokenOffer object][], and deletes the `NFTokenOffer` when either side accepts or cancels the offer. If the NFT is transferable, it can be traded multiple times between accounts.
+
+You can destroy an NFT you own using the [NFTokenBurn transaction][]. If the issuer minted the token with the `tfBurnable` flag enabled, the issuer can also burn the token, regardless of the current owner. (This could be useful, for example, for a token that represents a ticket to an event that is used up at some point.)
+
+![The NFT Lifecycle](img/nft-lifecycle.png "NFT Lifecycle Image")
+
+For more info about transferring NFTs, see [Trading NFTs on the XRP Ledger](non-fungible-token-transfers.html).
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/nfts/nft-apis.md

@@ -9,12 +9,12 @@ labels:
 
 This page lists the transactions and requests associated with NFTs as a handy reference.
 
-## NFT Objects
+## NFT Ledger Entries
 
 - [NFToken][] data type - The NFT object stored on the ledger.
-- Ledger Objects
-    - [NFTokenOffer object][] - An offer to buy or sell an NFT.
-    - [NFTokenPage object][] - An NFT page holds a maximum of 32 NFT objects. In practice, each NFT page typically holds 16-24 NFTs.
+- Ledger Entries
+    - [NFTokenOffer entry][] - An offer to buy or sell an NFT.
+    - [NFTokenPage entry][] - An NFT page holds a maximum of 32 NFTs. In practice, each NFT page typically holds 16-24 NFTs.
 
 ## NFT Transactions
 
@@ -38,20 +38,14 @@ This page lists the transactions and requests associated with NFTs as a handy re
 
 ## Clio
 
-Clio servers enhance overall network performance by handling requests for information based on cached information, freeing up validators on the XRP Ledger to focus on processing transactions. In addition to all of the common XRP Ledger request types, the Clio server handles additional request types that provide more detailed responses.
-
-### Clio-specific NFT requests
+[Clio servers](the-clio-server.html) also provide the following APIs related to NFTs:
 
 - [nft_info](nft_info.html) - Get current status information about the specified NFT.
 - [nft_history](nft_history.html) - Get past transaction metadata for the specified NFT.
 
-<!-- 
-[nfts_by_issuer](nfts_by_issuer.html) - Get a list of all NFTs created by the specified issuer.
--->
-
 You can access a public Clio server by sending a request to its URL and Clio port (typically 51233). Public Clio API servers come with no SLAs nor any responsibility to be fixed on priority. If your business use case requires continual monitoring and information requests, consider setting up your own Clio server instance. See [install-clio-on-ubuntu](install-clio-on-ubuntu.html).
 
 <!--{# common link defs #}-->
-{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}			
-{% include '_snippets/rippled_versions.md' %}
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/nfts/reserve-requirements.md

@@ -65,4 +65,4 @@ If you were to mint 200 NFTs and create an `NFTokenSellOffer`for each, that woul
 | Total               | 436 XRP |
 |                     |         |
 
-If the required reserves exceed the amount you are comfortable setting aside, consider using the mint-on-demand model to reduce the number of NFTs and offers you hold at any one time. See [Mint on Demand](nftoken-batch-minting.html#mint-on-demand-lazy-minting).
+If the required reserves exceed the amount you are comfortable setting aside, consider using the mint-on-demand model to reduce the number of NFTs and offers you hold at any one time. For details, see [Batch Minting](nftoken-batch-minting.html).

content/concepts/tokens/nfts/running-an-nft-auction.md

@@ -15,7 +15,7 @@ This flow is the most straightforward. Note that the `NFTokenOffer` objects can
 
 1. Store your bids in a private database.
 2. You take a cut of the winning bid.
-3. Send the buyer/seller the XRPL transaction to complete the purchase. 
+3. Send the buyer/seller the XRPL transaction to complete the purchase.
 
 ## Run the Auction in Brokered Mode, with a Reserve
 
@@ -39,7 +39,7 @@ Run the auction in brokered mode, as an auction with a reserve.
 
 A major mitigating factor of this downside is that if this behavior were to happen, brokers would lose their entire market share, which sellers should understand.
 
-## Run the Auction in Brokered Mode, without a Reserve. 
+## Run the Auction in Brokered Mode, without a Reserve.
 
 This is the most complex workflow of the three.
 

content/concepts/tokens/nfts/trading.md

@@ -0,0 +1,76 @@
+---
+html: non-fungible-token-transfers.html
+parent: non-fungible-tokens.html
+blurb: Trading NFTs in direct or brokered mode.
+labels:
+ - Non-fungible Tokens, NFTs
+---
+
+# Trading NFTs
+
+You can transfer NFTs between accounts on the XRP Ledger. You can offer to buy or sell an NFT, or accept offers from other accounts to buy an NFT you own. You can even give away an NFT by offering to sell it at a price of 0.  All offers are created using [NFTokenCreateOffer transaction][].
+
+_(Added by the [NonFungibleTokensV1_1 amendment][].)_
+
+## Reserve Requirements
+
+Every `NFTokenOffer` object requires that your account increase its owner reserve, currently 2 XRP per `NFTokenSellOffer` and 2 XRP per `NFTokenBuyOffer`. This is to prevent accounts from spamming the ledger with offers they don't intend to complete.
+
+See [NFT Reserve Requirements](nft-reserve-requirements.html).
+
+## Sell Offers
+
+### Create a Sell Offer
+
+As the owner of an NFT, you can create a sell offer using a [NFTokenCreateOffer transaction][] with the `tfSellToken` flag. You provide the `NFTokenID` and the `Amount` you are willing to accept in payment. You can optionally specify an `Expiration` date, after which the offer is no longer valid, and a `Destination` account, which is the only account that is allowed to buy the NFT.
+
+### Accept a Sell Offer
+
+To buy an NFT that is offered for sale, you use a `NFTokenAcceptOffer` transaction. You provide the owner account and specify the `NFTokenOfferID` of the `NFTokenOffer` object you choose to accept.
+
+## Buy Offers
+
+### Create a Buy Offer
+
+Any account can offer to buy an NFT. You can create a buy offer using [NFTokenCreateOffer][] _without_ the `tfSellToken` flag. You provide the `Owner` account, `NFTokenID`, and the `Amount` of your offer.
+
+### Accept a Buy Offer
+
+Use the `NFTokenAcceptOffer` transaction to transfer an NFT. Provide the `NFTokenOfferID` and the owner account to complete the transaction.
+
+## Trading Modes
+
+When trading an NFT, you can choose between a _direct_ transaction between a buyer and seller or a _brokered_ transaction, where a third party account matches a sell and buy offer to arrange the trade.
+
+Trading in direct mode gives the seller control over the transfer. The seller can either post an NFT for sale so that anyone can buy it, or sell an NFT to a specific account. The seller receives the entire price for the NFT.
+
+In brokered mode, the seller allows a third party account to broker the sale of the NFT. The broker account collects a broker fee for the transfer at an agreed upon rate. This happens as one transaction, paying the broker and seller from the buyer’s funds without requiring an up front investment by the broker.
+
+### When to Use Brokered Mode
+
+If an NFT creator has the time and patience to seek out the right buyers, the creator keeps all proceeds from the sale. This works fine for a creator who sells few NFTs at variable prices.
+
+On the other hand, creators might not want to spend their time selling their creations when they could spend the time creating. Instead of handling each individual sale, the sales work can be turned over to a third-party broker account.
+
+Using a broker offers several advantages. For example:
+
+* The broker can act as an agent, working to maximize the selling price of the NFT. If the broker is paid a percentage of the sale price, the higher the price, the more the broker earns.
+* The broker can act as a curator, organizing NFTs based on a niche market, price point, or other criteria. This can attract groups of buyers who might not otherwise discover a creator’s work.
+* The broker can act as a marketplace, similar to Opensea.io, to handle the auction process at the application layer.
+
+### Brokered Sale Workflows
+
+In the most straightforward workflow, a creator mints a new NFT. The creator initiates a sell offer, entering the minimum acceptable sale price and setting the broker as the destination. Potential buyers make bids for the NFT, setting the broker as the destination for the bid. The broker selects a winning bid and completes the transaction, taking a broker’s fee. As a best practice, the broker then cancels any remaining buy offers for the NFT.
+
+![Brokered Mode with Reserve](img/nft-brokered-mode-with-reserve.png)
+
+Another potential workflow would give the creator more control over the sale. In this workflow, the creator mints a new NFT. Bidders create their offers, setting the broker as the destination. The broker selects the winning bid, subtracts their broker fee, and uses `NFTokenCreateOffer` to request that the creator sign off on the offer. The creator signs the requested offer, setting the broker as the destination. The broker completes the sale using `NFTokenAcceptOffer`, retaining the broker fee. The broker cancels any remaining bids for the NFT using `NFTokenCancelOffer`.
+
+![Brokered Mode without Reserve](img/nft-brokered-mode-without-reserve.png)
+
+The same workflows can be used when an owner resells an NFT created by another account.
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/non-fungible-token-transfers.md

@@ -1,76 +0,0 @@
----
-html: non-fungible-token-transfers.html
-parent: non-fungible-tokens.html
-blurb: Trading NFTokens in direct or brokered mode.
-labels:
- - Non-fungible Tokens, NFTs
----
-
-# Trading NFTokens on the XRP Ledger
-
-You can transfer `NFToken` objects between accounts on the XRP Ledger. You can offer to buy or sell a `NFToken`, or accept offers from other accounts to buy a `NFToken` you own. You can even give away a `NFToken` by offering to sell it at a price of 0.  All offers are created using [NFTokenCreateOffer transaction][].
-
-_(Added by the [NonFungibleTokensV1_1 amendment][].)_
-
-## Reserve Requirements
-
-Every NFTokenOffer object requires that your account increase its owner reserve, currently 2 XRP per `NFTokenSellOffer` and 2 XRP per `NFTokenBuyOffer`. This is to prevent accounts from spamming the ledger with offers they don't intend to complete.
-
-See [NFT Reserve Requirements](nft-reserve-requirements.html).
-
-## Sell Offers
-
-### Create a Sell Offer
-
-As the owner of a `NFToken` object, you can create a sell offer using a [NFTokenCreateOffer transaction][] with the `tfSellToken` flag. You provide the `NFTokenID` and the `Amount` you are willing to accept in payment. You can optionally specify an `Expiration` date, after which the offer is no longer valid, and a `Destination` account, which is the only account that is allowed to buy the `NFToken`.
-
-### Accept a Sell Offer
-
-To buy a `NFToken` that is offered for sale, you use a `NFTokenAcceptOffer` transaction. You provide the owner account and specify the `NFTokenOfferID` of the `NFTokenOffer` object you choose to accept.
-
-## Buy Offers
-
-### Create a Buy Offer
-
-Any account can offer to buy a `NFToken`. You can create a buy offer using [NFTokenCreateOffer][] _without_ the `tfSellToken` flag. You provide the `Owner` account, `NFTokenID`, and the `Amount` of your offer.
-
-### Accept a Buy Offer
-
-Use the `NFTokenAcceptOffer` transaction to transfer a `NFToken`. Provide the `NFTokenOfferID` and the owner account to complete the transaction.
-
-## Trading Modes
-
-When trading a `NFToken`, you can choose between a _direct_ transaction between a buyer and seller or a _brokered_ transaction, where a third party account matches a sell and buy offer to arrange the trade.
-
-Trading in direct mode gives the seller control over the transfer. The seller can either post a `NFToken` for sale so that anyone can buy it, or sell a `NFToken` to a specific account. The seller receives the entire price for the `NFToken`.
-
-In brokered mode, the seller allows a third party account to broker the sale of the `NFToken`. The broker account collects a broker fee for the transfer at an agreed upon rate. This happens as one transaction, paying the broker and seller from the buyer’s funds without requiring an up front investment by the broker.
-
-### When to Use Brokered Mode
-
-If a `NFToken` creator has the time and patience to seek out the right buyers, the creator keeps all proceeds from the sale. This works fine for a creator who sells few `NFToken` objects at variable prices.
-
-On the other hand, creators might not want to spend their time selling their creations when they could spend the time creating. Instead of handling each individual sale, the sales work can be turned over to a third-party broker account.
-
-Using a broker offers several advantages. For example:
-
-* The broker can act as an agent, working to maximize the selling price of the `NFToken`. If the broker is paid a percentage of the sale price, the higher the price, the more the broker earns.
-* The broker can act as a curator, organizing `NFToken` objects based on a niche market, price point, or other criteria. This can attract groups of buyers who might not otherwise discover a creator’s work.
-* The broker can act as a marketplace, similar to Opensea.io, to handle the auction process at the application layer.
-
-### Brokered Sale Workflows
-
-In the most straightforward workflow, a creator mints a new `NFToken`. The creator initiates a sell offer, entering the minimum acceptable sale price and setting the broker as the destination. Potential buyers make bids for the `NFToken`, setting the broker as the destination for the bid. The broker selects a winning bid and completes the transaction, taking a broker’s fee. As a best practice, the broker then cancels any remaining buy offers for the `NFToken`.
-
-![Brokered Mode with Reserve](img/nft-brokered-mode-with-reserve.png)
-
-Another potential workflow would give the creator more control over the sale. In this workflow, the creator mints a new `NFToken`. Bidders create their offers, setting the broker as the destination. The broker selects the winning bid, subtracts their broker fee, and uses `NFTokenCreateOffer` to request that the creator sign off on the offer. The creator signs the requested offer, setting the broker as the destination. The broker completes the sale using `NFTokenAcceptOffer`, retaining the broker fee. The broker cancels any remaining bids for the `NFToken` using `NFTokenCancelOffer`.
-
-![Brokered Mode without Reserve](img/nft-brokered-mode-without-reserve.png)
-
-The same workflows can be used when an owner resells a `NFToken` created by another account.
-
-<!--{# common link defs #}-->
-{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}			
-{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/non-fungible-tokens.md

@@ -1,70 +0,0 @@
----
-html: non-fungible-tokens.html
-parent: tokens.html
-blurb: Introduction to XRPL NFTs.
-labels:
- - Non-fungible Tokens, NFTs
----
-
-# Non-Fungible Tokens
-
-The XRP Ledger natively supports non-fungible tokens (NFTs, or “nifties” in the vernacular).  Non-fungible tokens serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
-
-_(Added by the [NonFungibleTokensV1_1 amendment][].)_
-
-
-## Background
-
-The XRP Ledger offers support for [tokens](tokens.html). Such assets are, primarily, fungible.
-
-> Fun·gi·ble /´fənjəbəl/ (adj) <!-- SPELLING_IGNORE: fənjəbəl -->
->
-> 1. able to replace or be replaced by another identical item; mutually interchangeable. <!-- STYLE_OVERRIDE: identical -->
-
-Fungible tokens can be traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
-
-
-A good example of a fungible item might be a postage stamp. If you are standing around in 1919 and need to send a letter by airmail, you would buy a 24-cent stamp and affix it to your envelope. If you lost that stamp, you could use a different 24-cent stamp or use 2 10-cent stamps and 2 2-cent stamps. Very fungible.
-
-![Jenny Stamps](img/nft-concepts1.png "Jenny Stamps")
-
-But since you are standing around in 1919, you might be offered 24-cent airmail stamps where the aeroplane on the stamp is accidentally printed upside down. These are the world famous “Inverted Jenny” stamps. Only 100 were circulated on a single sheet of stamps, making them extremely rare and sought after. The current value of each mint condition stamp is appraised at over $1.5 million dollars.
-
-![Jenny Stamps](img/nft-concepts2.png "Jenny Stamps")
-
-Those stamps cannot be replaced by an ordinary 24-cent stamp. They have become _non-fungible_.
-
-To represent digital assets similar to these, use the XRP Ledger's Non-Fungible Tokens feature (sometimes referred to by its standards draft number, [XLS-20](https://github.com/XRPLF/XRPL-Standards/discussions/46)).
-
-
-## NFTs on the XRP Ledger
-
-On the XRP Ledger, a non-fungible token is represented as a [NFToken][] object. A `NFToken` is a unique, indivisible unit that is not used for payments. Users can mint (create), hold, buy, sell, and burn (destroy) such tokens.
-
-The ledger stores up to 32 `NFToken` objects owned by the same account in a single [NFTokenPage object][] to save space. As a result, the owner's [reserve requirement](reserves.html) for `NFToken` objects only increases when the ledger needs to make a new page to store additional tokens.
-
-Accounts can also name a broker, or "Authorized Minter", who can mint and sell `NFToken` objects on their behalf.
-
-`NFToken` objects have several settings that are defined when the token is minted and cannot be changed later. These include:
-
-- Various identifying data that uniquely defines the token.
-- Whether the issuer can burn the token regardless of who currently holds it.
-- Whether the holder of the token can transfer it to others. (The `NFToken` can always be sent to or from the issuer directly.)
-    - If transfers are allowed, the issuer can charge a transfer fee as a percentage of the sale price.
-- Whether the holder can sell the `NFToken` for [fungible token](tokens.html) amounts, or only for XRP.
-
-
-## `NFToken` Lifecycle
-
-Anyone can create a new `NFToken` using the [NFTokenMint transaction][] type. The `NFToken` lives on the [NFTokenPage object][] of the issuing account. Either the owner or an interested party can send a [NFTokenCreateOffer transaction][] to propose buying or selling the `NFToken`; the ledger tracks the proposed transfer as a [NFTokenOffer object][], and deletes the `NFTokenOffer` when either side accepts or cancels the offer. If the `NFToken` is transferable, it can be traded multiple times between accounts.
-
-You can destroy a `NFToken` you own using the [NFTokenBurn transaction][]. If the issuer minted the token with `tfBurnable` flag enabled, the issuer can also burn the token regardless of the current owner. (This could be useful, for example, for a token that represents a ticket to an event which is used up at some point.)
-
-![The NFT Lifecycle](img/nft-lifecycle.png "NFT Lifecycle Image")
-
-For more info about transferring `NFToken` objects, see [Trading NFTokens on the XRP Ledger](non-fungible-token-transfers.html).
-
-<!--{# common link defs #}-->
-{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}			
-{% include '_snippets/rippled_versions.md' %}

content/concepts/tokens/tokens.md

@@ -1,83 +0,0 @@
----
-parent: concepts.html
-blurb: Anyone can make tokens representing digital value on the XRP Ledger.
-labels:
-  - Tokens
----
-# Tokens
-
-All assets other than XRP can be represented in the XRP Ledger as **tokens**. Standard tokens are tracked in relationships called [trust lines](trust-lines-and-issuing.html) between accounts. Any account can issue tokens to other recipients who are willing to hold them, but you cannot unilaterally give tokens away to users who don't want them. Tokens can represent any type of value, including "stablecoins" backed by assets that exist outside of the ledger, purely digital tokens created specifically on the XRP Ledger, community credit, and more.
-
-**Note:** Tokens on the XRP Ledger have also been called "IOUs" (as in [I-owe-you](https://en.wikipedia.org/wiki/IOU)) and "issued currencies" in the past. However, these terms are not preferred because they do not cover the full range of digital assets that XRP Ledger tokens can represent. <!-- STYLE_OVERRIDE: ious -->
-
-Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible-tokens.html) for details of the XRP Ledger's native support.
-
-Tokens can used for [cross-currency payments](cross-currency-payments.html) and can be traded in the [decentralized exchange](decentralized-exchange.html).
-
-The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html) on trust lines to prevent those trust lines from rippling.
-
-
-## Stablecoins
-
-A common model for tokens in the XRP Ledger is that an issuer holds assets of equivalent value outside of the XRP Ledger, and issues tokens representing that value on the ledger. This type of issuer is sometimes called a _gateway_ because currency can move into and out of the XRP Ledger through their service. If the assets that back a token use the same amounts and denomination as the tokens in the ledger, that token can be considered a "stablecoin" because—in theory—the exchange rate between that token and its off-ledger representation should be stable at 1:1.
-
-A stablecoin issuer should offer _deposits_ and _withdrawals_ to exchange the tokens for the actual currency or asset in the world outside the XRP Ledger.
-
-In practice, the XRP Ledger is a computer system that cannot enforce any rules outside of itself, so stablecoins on the XRP Ledger depend on their issuer's integrity. If you can't count on the stablecoin's issuer to redeem your tokens for the real thing on demand, then you shouldn't expect the stablecoin to hold its value. As a user, you should be mindful of who's issuing the tokens: are they reliable, lawful, and solvent? If not, it's probably best not to hold those tokens.
-
-For more information, see [Stablecoin Issuer](stablecoin-issuer.html).
-
-
-## Community Credit
-
-Another way you can use the XRP Ledger is for "community credit", a system where individuals who know each other can use the XRP Ledger to track who owes who else how much money. A powerful feature of the XRP Ledger is that it can automatically and atomically use these debts to settle payments through [rippling](rippling.html).
-
-For example, if Asheesh owes Marcus $20, and Marcus owes Bharath $50, Bharath can "pay" Asheesh $20 by canceling that much of Marcus's debt to him in exchange for canceling Asheesh's debt to Marcus. The reverse is also possible: Asheesh can pay Bharath through Marcus by increasing their respective debts. The XRP Ledger can settle complex chains of exchanges like this in a single transaction without the accounts in the middle needing to do anything manually.
-
-For more on this type of usage, see [paths](paths.html). <!--{# TODO: It would be nice to be able to link to a page with more illustrative examples of community credit. #}-->
-
-
-## Other Tokens
-
-There are other use cases for tokens issued in the XRP Ledger. For example, you can create an "Initial Coin Offering" (ICO) by issuing a fixed amount of currency to a secondary address, then "throwing away the key" to the issuer.
-
-**Warning:** ICOs may be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. <!-- SPELLING_IGNORE: ico, icos -->
-
-Be sure to research the relevant regulations before engaging in any financial service business.
-
-
-## Token Properties
-
-Tokens in the XRP Ledger are [fundamentally different than XRP](currency-formats.html#comparison). Tokens always exist _in trust lines_, and all transfers of tokens move along trust lines. You cannot cause someone else's account to hold more of a token than the _limit_ configured on their trust line. (You _can_ cause your own trust line to go over the limit, for example by buying more of it in the [decentralized exchange](decentralized-exchange.html) or by decreasing the limit after you already have a positive balance.)
-
-Tokens use decimal (base-10) math with 15 digits of precision and an exponent that allows them to express very large values (up to 9999999999999999 × 10<sup>80</sup>) and very small values (down to 1.0 × 10<sup>-81</sup>).
-
-Anyone can issue tokens by sending a [Payment transaction][] if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](cross-currency-payments.html) or trades can also create more tokens according to an issuer's settings.
-
-Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a [tick size](ticksize.html) for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezes.html) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
-
-For a tutorial of the technical steps involved in issuing a token, see [Issue a Fungible Token](issue-a-fungible-token.html).
-
-
-## See Also
-
-- **Concepts:**
-    - [What is XRP?](what-is-xrp.html)
-    - [Cross-Currency Payments](cross-currency-payments.html)
-    - [Decentralized Exchange](decentralized-exchange.html)
-- **Tutorials:**
-    - [Issue a Fungible Token](issue-a-fungible-token.html)
-    - [Look Up Transaction Results](look-up-transaction-results.html)
-    - [Use Specialized Payment Types](use-specialized-payment-types.html)
-- **References:**
-    - [Payment transaction][]
-    - [TrustSet transaction][]
-    - [RippleState object](ripplestate.html)
-    - [account_lines method][]
-    - [account_currencies method][]
-    - [gateway_balances method][]
-
-<!--{# common link defs #}-->
-{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}			
-{% include '_snippets/rippled_versions.md' %}

content/references/protocol/data-types/nftoken.md

@@ -132,6 +132,6 @@ https://example.com/.well-known/xrpl-nft/{nftokenid}
 You create `NFToken` objects using the `NFTokenMint` transaction. You can optionally destroy `NFToken` objects using the `NFTokenBurn` transaction.
 
 <!--{# 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' %}

content/references/protocol/transactions/types/payment.md

@@ -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](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 allows a payment to succeed by reducing the amount received. Partial payments are useful for [returning payments](bouncing-payments.html) 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.
 

content/tutorials/manage-account-settings/offline-account-setup.md

@@ -345,6 +345,6 @@ Then adjust and sign any replacement transactions for transactions that failed i
 
 
 <!--{# 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' %}

content/tutorials/use-tokens/enable-no-freeze.md

@@ -179,7 +179,7 @@ Response:
 
 - **Concepts:**
     - [Freezing Issued Currencies](freezes.html)
-    - [Trust Lines and Issuing](trust-lines-and-issuing.html)
+    - [Trust Lines](trust-lines-and-issuing.html)
 - **Tutorials:**
     - [Enact Global Freeze](enact-global-freeze.html)
     - [Freeze a Trust Line](freeze-a-trust-line.html)
@@ -193,6 +193,6 @@ Response:
 
 
 <!--{# 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' %}

content/tutorials/use-tokens/enact-global-freeze.md

@@ -255,7 +255,7 @@ After the transaction is validated, you can confirm the status of the Global Fre
 
 - **Concepts:**
     - [Freezing Issued Currencies](freezes.html)
-    - [Trust Lines and Issuing](trust-lines-and-issuing.html)
+    - [Trust Lines](trust-lines-and-issuing.html)
 - **Tutorials:**
     - [Enable No Freeze](enable-no-freeze.html)
     - [Freeze a Trust Line](freeze-a-trust-line.html)
@@ -270,6 +270,6 @@ After the transaction is validated, you can confirm the status of the Global Fre
 
 
 <!--{# 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' %}

content/tutorials/use-tokens/freeze-a-trust-line.md

@@ -331,7 +331,7 @@ As before, wait for the transaction to be validated by consensus.
 
 - **Concepts:**
     - [Freezing Issued Currencies](freezes.html)
-    - [Trust Lines and Issuing](trust-lines-and-issuing.html)
+    - [Trust Lines](trust-lines-and-issuing.html)
 - **Tutorials:**
     - [Enable No Freeze](enable-no-freeze.html)
     - [Enact Global Freeze](enact-global-freeze.html)
@@ -346,6 +346,6 @@ As before, wait for the transaction to be validated by consensus.
 
 
 <!--{# 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' %}

content/use-cases/defi/list-xrp-as-an-exchange.md

@@ -7,7 +7,7 @@ labels:
 ---
 # List XRP as an Exchange
 
-This document describes the steps that an exchange needs to take to list XRP. These steps are targeted at _custodial exchanges_ that holds fund on behalf of users, and allows users to deposit, withdraw, and trade other digital assets, fiat currencies, or other types of assets.
+This document describes the steps that an exchange needs to take to list XRP. These steps are targeted at _custodial exchanges_ that hold funds on behalf of users, and allows users to deposit, withdraw, and trade other digital assets, fiat currencies, or other types of asset.
 
 ## Alpha Exchange
 
@@ -41,17 +41,19 @@ To support XRP, Alpha Exchange must:
 
 See also:
 
-* [Compliance Guidelines](stablecoin-issuer.html#compliance-guidelines) — Token issuers and exchanges are different, but exchanges should also ensure that they are complying with local regulations and reporting to the appropriate agencies.
+* [Compliance Guidelines](stablecoin-compliance-guidelines.html) — Token issuers and exchanges are different, but exchanges should also ensure that they are complying with local regulations and reporting to the appropriate agencies.
 
+<!-- These sections need to be topics of their own, without the story.
 * [Requirements for Sending to XRP Ledger](stablecoin-issuer.html#requirements-for-sending-to-xrp-ledger)
 
 * [Requirements for Receiving from XRP Ledger](stablecoin-issuer.html#requirements-for-receiving-from-xrp-ledger)
+-->
 
-* [Precautions](stablecoin-issuer.html#precautions)
+* [Precautions](stablecoin-precautions.html)
 
 ### Partial Payments
 
-Before integrating, exchanges should be aware of the [partial payments](partial-payments.html) feature. This feature allows XRP Ledger users to send successful payments that reduce the amount received instead of increasing the `SendMax`. This feature can be useful for [returning payments](stablecoin-issuer.html#bouncing-payments) without incurring additional cost as the sender.
+Before integrating, exchanges should be aware of the [partial payments](partial-payments.html) feature. This feature allows XRP Ledger users to send successful payments that reduce the amount received instead of increasing the `SendMax`. This feature can be useful for [returning payments](bouncing-payments.html) without incurring additional cost as the sender.
 
 #### Partial Payments Warning
 

content/use-cases/tokenization/authorized-minter.md

@@ -11,7 +11,7 @@ _As an authorized minter, I want to mint tokens for a token issuer at an agreed
 
 You can act as an authorized minter for token issuers. When you do this, you own the NFToken, but royalties flow to the NFToken issuer. When you make a sale of that NFToken, the proceeds of the initial sale go to you. You can have an agreement with your issuer to pay them some or all of your portion of the initial sale amount.
 
-You can learn more in the tutorial [Assign an Authorized Minter](assign-an-authorized-minter-using-javascript.html). 
+You can learn more in the tutorial [Assign an Authorized Minter](assign-an-authorized-minter-using-javascript.html).
 
 [![Authorized Minter Flow](img/nft-mkt-auth-minter.png "Authorized Minter Flow")](img/nft-mkt-auth-minter.png)
 
@@ -40,7 +40,7 @@ The NFToken URL is a link to the location where the content of the NFT is stored
 Considerations that might be most interesting to you:
 
 * [Minting NFTs into Collections](nft-collections.html)
-Use the TokenTaxon field to gather a set of NFTs centered around a specific theme or purpose. 
+Use the TokenTaxon field to gather a set of NFTs centered around a specific theme or purpose.
 * [Guaranteeing a Fixed Supply of NFTs](nft-fixed-supply.html)
 You can assure scarcity of NFTs you create by creating them with what might be characterized as a “burner” account that you use to mint a set number of NFTs for another account, then delete the account you used to mint the NFTs. See [Guaranteeing a Fixed Supply of NFTs](nft-fixed-supply.html).
 
@@ -84,12 +84,12 @@ When listing NFTs for sale, it can be useful to use object metadata to organize
 
 See:
 
-- [Clio setup](install-clio-on-ubuntu.html) 
+- [Clio setup](install-clio-on-ubuntu.html)
 - [XRPL Data API](https://api.xrpldata.com/docs/static/index.html#/)
 - [Bithomp](https://docs.bithomp.com/#nft-xls-20)
 
-<!-- 
-[Clio setup](install-clio-on-ubuntu.html) 
+<!--
+[Clio setup](install-clio-on-ubuntu.html)
 
 [https://api.xrpldata.com/docs/static/index.html#/](https://api.xrpldata.com/docs/static/index.html#/)
 

content/use-cases/tokenization/digital-artist.md

@@ -17,7 +17,7 @@ As a digital artist, you’re focused on creating NFTs, presumably to sell on th
 
 You can create NFTokens using an app such as the [Xumm app](https://xumm.app).
 
-For a more hands-on experience, you can follow the steps in the [Quickstart Tutorial 3 - Mint and Burn NFTokens](mint-and-burn-nfts-using-javascript.html). 
+For a more hands-on experience, you can follow the steps in the [Quickstart Tutorial 3 - Mint and Burn NFTokens](mint-and-burn-nfts-using-javascript.html).
 
 [![Digital Artist Flow](img/nft-mkt-digital-artist.png "Digital Artist Flow")](img/nft-mkt-digital-artist.png)
 
@@ -79,7 +79,7 @@ When listing NFTs for sale, it can be useful to use object metadata to organize
 
 See:
 
-- [Clio setup](install-clio-on-ubuntu.html) 
+- [Clio setup](install-clio-on-ubuntu.html)
 - [XRPL Data API](https://api.xrpldata.com/docs/static/index.html#/)
 - [Bithomp](https://docs.bithomp.com/#nft-xls-20)
 
@@ -90,4 +90,4 @@ There are some workflows where it makes sense for the issuer to retain the right
 
 ![Burning NFTs](img/uc-nft-burn.png)
 
-Another example might be burning an in-game asset that is lost by a player after losing a life in the game. You might also burn an NFT ticket after successful redemption to prevent it from being used again.
+Another example might be burning an in-game asset that is lost by a player after losing a life in the game. You might also burn an NFT ticket after successful redemption to prevent it from being used again.

content/use-cases/tokenization/nft-mkt-overview.md

@@ -71,7 +71,7 @@ See [Authorized Minter](nftoken-authorized-minting.html).
 
 Minted NFTs are listed on a `NFTokenPage`. There is a reserve requirement of 2 XRP for every `NFTokenPage` on your account. See [NFT Reserve Requirements](nft-reserve-requirements.html).
 
-Each `NFTokenPage` holds 16-32 NFTs. Minting a large number of NFTs can tie up a great deal of your XRP. You can keep your XRP liquid by minting on demand (or _lazy minting_). See [Lazy minting](nftoken-batch-minting.html#mint-on-demand-lazy-minting) vs [Scripted minting](nftoken-batch-minting.html#scripted-minting).
+Each `NFTokenPage` holds 16-32 NFTs. Minting a large number of NFTs can tie up a great deal of your XRP. You can keep your XRP liquid by minting on demand (or _lazy minting_). For details of different approaches, see [Batch minting](nftoken-batch-minting.html).
 
 
 ### Setting up a wallet
@@ -114,7 +114,7 @@ The most straightforward payment for XRPL NFTs is XRP. For examples of selling a
 
 For trade in other currencies, you can leverage the DEX to accept and convert issued currencies of all kinds. See [Trade in the Decentralized Exchange](trade-in-the-decentralized-exchange.html#trade-in-the-decentralized-exchange).
 
-<!-- 
+<!--
 
 - Fiat payment ([Cross-currency payments](cross-currency-payments.html))
 - On-chain validation of completing transactions [No link- isn’t this just a cross-currency payment?] (Query after the transaction is completed.]
@@ -122,7 +122,7 @@ For trade in other currencies, you can leverage the DEX to accept and convert is
 
 ## Indexing NFTs
 
-When listing NFTs for sale, it can be useful to use object metadata to organize them. 
+When listing NFTs for sale, it can be useful to use object metadata to organize them.
 
 ![Indexing NFTs](img/uc-nft-indexing.png)
 
@@ -130,12 +130,12 @@ You can use queries in the XRPL libraries, the Clio server, and extensions in th
 
 See:
 
-- [Clio setup](install-clio-on-ubuntu.html) 
+- [Clio setup](install-clio-on-ubuntu.html)
 - [XRPL Data API](https://api.xrpldata.com/docs/static/index.html#/)
 - [Bithomp](https://docs.bithomp.com/#nft-xls-20)
 
 
-<!-- 
+<!--
 Sorting and filtering [No link]
     Creator - nft_info (issuer field)
     Price - nft_sell_offer->offers->amount field)
@@ -154,7 +154,7 @@ Supplement Information [No link]
  -->
 
 ## NFT Caching
-<!-- 
+<!--
 
 Image optimization for web experience [No link]
 
@@ -170,11 +170,11 @@ Cloudflare, Infura, and many other providers are increasingly focusing on storin
 
 See [NFT Caching](nftoken.html#retrieving-nftoken-data-and-metadata).
 
-<!-- 
-You can also consider a solution such as Pinata. [https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing](https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing) 
+<!--
+You can also consider a solution such as Pinata. [https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing](https://drive.google.com/file/d/14wuulkvjVjtGlUJj0ppaJ4Sziyp5WFGA/view?usp=sharing)
 
-We can derive inspiration for the need of caching and point to some of their docs 
-[https://docs.pinata.cloud/gateways](https://docs.pinata.cloud/gateways) 
+We can derive inspiration for the need of caching and point to some of their docs
+[https://docs.pinata.cloud/gateways](https://docs.pinata.cloud/gateways)
  -->
 
 

content/use-cases/tokenization/nftoken-marketplace.md

@@ -9,7 +9,7 @@ labels:
 
 _In my NFToken Marketplace, I want to use the XRPL to create a web presence where I can arrange transfer of a curated selection of NFTokens to consumers, with the benefit that I can build a brand and earn broker fees based on sales._
 
---- 
+---
 
 NFToken Marketplaces act as intermediaries between NFToken creators and collectors. As a marketplace curator, you seek out NFToken creators and assemble a collection of items to sell. Buyers come to your site to review your selections and post offers. You match the minimum prices set by the creators with the optimal offers from the buyers, complete the transaction, and collect a broker fee.
 
@@ -60,7 +60,7 @@ You can learn more about brokered sales in the topic [Trading Tokens on the XRP
 
 Learn more about token transfer fees in the topic [Transfer Fees](transfer-fees.html).
 
-You can get started building a brokered sales marketplace by following the steps in the [Broker a NFToken Sale](broker-an-nft-sale-using-javascript.html). 
+You can get started building a brokered sales marketplace by following the steps in the [Broker a NFToken Sale](broker-an-nft-sale-using-javascript.html).
 
 ### Checkout
 
@@ -78,11 +78,11 @@ When listing NFTs for sale, it can be useful to use object metadata to organize
 
 See:
 
-- [Clio setup](install-clio-on-ubuntu.html) 
+- [Clio setup](install-clio-on-ubuntu.html)
 - [XRPL Data API](https://api.xrpldata.com/docs/static/index.html#/)
 - [Bithomp](https://docs.bithomp.com/#nft-xls-20)
 
-<!-- 
+<!--
 
 Sorting and filtering [No link]
     Creator - nft_info (issuer field)

content/use-cases/tokenization/stablecoin-issuer.md

@@ -4,504 +4,185 @@ parent: tokenization.html
 blurb: Issue your own stablecoin, based on assets of equal value outside of the XRP Ledger.
 labels:
   - Tokens
+  - Stablecoin
 ---
 # Stablecoin Issuer
 
-**Stablecoin** are [tokens](tokens.html) that are backed by assets in the outside world. Stablecoins allow users to transact in familiar currencies, and provide a convenient way to get funds into and out of the blockchain. In exchange for providing these services, stablecoin issuers can earn revenue in various ways, such as fees on withdrawals or transfers of the stablecoin.
+_As a financial professional, I want to issue a stablecoin so that I can earn revenue by charging fees for withdrawals or transfers of the stablecoin._
 
-While anyone can issue a token with any currency code in the XRP Ledger, stablecoins' value comes from the promise that they can be redeemed for the corresponding assets. Issuing a stablecoin may also involve regulatory obligations, which vary by jurisdiction. For these reasons, issuing a stablecoin generally requires a reputable business.
+Stablecoins are tokens that are backed by assets outside of the XRPL. Stablecoins allow users to transact in familiar currencies, and provide a convenient way to get funds into and out of the XRPL blockchain.
 
-**Note:** Stablecoin issuers on the XRP Ledger were formerly called "gateways".
+The mechanics of issuing a stablecoin are not complicated.
 
-This article provides information you should know before issuing a stablecoin, summarizes the choices involved in setting up a stablecoin issuer, and provides resources for implementing the technical integration with the XRP Ledger.
+1. Decide on the name for your stablecoin (either following the 3-character ISO standard or using a 160-bit hex string. See [Currency Codes](currency-formats.html#currency-codes)).
+2. Create a trust line between the issuing account and a consuming account establishing a maximum number of stablecoins to transfer.
+3. Send a payment of stablecoins to the consumer up to the maximum amount in the trust line.
 
+While anyone can issue a token with any currency code in the XRP Ledger, stablecoin value comes from the promise that it can be redeemed for a corresponding asset. Issuing a stablecoin might involve regulatory obligations, which vary by jurisdiction. For these reasons, an established, reputable business is most likely to succeed in issuing a stablecoin.
 
-## Background Information
+[![Stablecoin Workflow](img/uc-stablecoin-flow.png)](img/uc-stablecoin-flow.png)
 
-### Trust Lines and Tokens
+There are many decisions to make and artifacts to generate as you prepare to release a new stablecoin. You can use the XRPL Foundation's [Self-assessment Questionnaire](https://foundation.xrpl.org/wp-content/uploads/2022/03/self_assessment_questionnaire_140322.pdf) as a starting point to gather and produce the necessary information for a successful launch.
 
-All assets in the XRP Ledger, except for the native cryptocurrency XRP, are represented as _tokens_, which are tied to a specific issuer who defines their meaning. The XRP Ledger has a system of directional accounting relationships, called _trust lines_, to make sure that users can only hold and receive the tokens they want.
+## Choose the Type of Stablecoin
 
-Tokens that are backed by funds in some outside system are sometimes called _stablecoins_. This includes tokens backed by fiat currency in a bank account, by cryptocurrencies on another blockchain, or other types of assets and forms of value. The term "stablecoin" comes from the idea that the exchange rate between the token and the asset it represents should be "stable" at 1:1 (minus fees).
+The first step is to decide the type of stablecoin you want to create. Your choice of stablecoin type might require additional steps, such as signing on financial or audit partners.
 
-For more information, see [Trust Lines and Issuing](trust-lines-and-issuing.html).
+![Stablecoin](img/uc-stablecoin-stable-coin.png)
 
+There are five common types of currency tokens you can create on the XRPL: fiat-backed, crypto-backed, commodity-backed, financial instrument-backed, and non-collateralized. See [Stablecoins](stablecoins.html).
 
-### XRP
+## Set Up Your Node Services
 
-**XRP** is the native cryptocurrency of the XRP Ledger. XRP can be sent directly from any XRP Ledger address to any other. This helps make XRP a convenient bridge currency.
+For lighter use cases and individual servers, you can often rely on free public servers. However, the more serious your use of the XRP Ledger becomes, the more important it becomes to have your own infrastructure.
 
-Token issuers do not need to accumulate or exchange XRP. They must only hold a small balance of XRP to meet the reserve requirement and pay the cost of sending transactions through the network. The XRP equivalent of $10 USD should be enough for at least one year of transaction costs for a busy issuer.
+There are many reasons you might want to run your own servers, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. See [Reasons to Run Your Own Server](networks-and-servers.html#reasons-to-run-your-own-server).
 
-For more information, see [What is XRP?](what-is-xrp.html), [Reserves](reserves.html), and [Transaction Cost](transaction-cost.html)
+Alternatively, you can use an external node service provider like OpenNode. See [OpenNode](https://www.opennodecloud.com/).
 
+## Sandbox Access
 
-### Liquidity and Trading
+![Sandbox](img/uc-stablecoin-sandbox.png)
 
-The XRP Ledger contains a decentralized exchange, where any user can place and fulfill bids to exchange XRP and tokens in any combination. The decentralized exchange also provides the liquidity that makes atomic [cross-currency payments](cross-currency-payments.html) possible.
+For testing purposes, you can implement, deploy, and trade your stablecoin on the XRPL Testnet or Devnet servers. Visit the XRP Faucets page to generate your test network credentials. Use the listed server URIs on that page to connect to and interact with your chosen test network. See [XRP Faucets](xrp-testnet-faucet.html).
 
-Stablecoin issuers aren't required to use the decentralized exchange directly, but all tokens are automatically available for trading. If a token is widely used, users should naturally trade it among themselves, creating liquidity to other popular assets. An issuer _may_ want to provide liquidity to XRP or other popular tokens at a baseline rate, especially when their token is new. If a stablecoin issuer does provide liquidity, a best practice is to **use different addresses for trading and for issuing.**
 
-For more information on the decentralized exchange, see [Decentralized Exchange](decentralized-exchange.html).
+## Stablecoin Settings
 
+Before you mint your new stablecoin, you need to configure settings, some of which are immutable once you issue the first coin.
 
-## Suggested Business Practices
+See [Stablecoin Settings](stablecoin-settings.html).
 
-The value of a stablecoin issuer's tokens in the XRP Ledger comes directly from the trust that customers can redeem the tokens when needed. To reduce the risk of business interruptions, you should follow these best practices:
+For more detail on configuration capbilities, see [Stablecoin Issuer Configuration](stablecoin-configuration.html).
 
-* Use separate [Issuing and Operational Addresses](account-types.html) to limit your risk profile on the network.
-* Follow anti-money-laundering regulations for your jurisdiction, such as the [Bank Secrecy Act](http://en.wikipedia.org/wiki/Bank_Secrecy_Act). This usually includes requirements to collect ["Know-Your-Customer" (KYC) information](http://en.wikipedia.org/wiki/Know_your_customer).
-* Complete the XRP Ledger Foundation's [token issuer self-assessment](https://foundation.xrpl.org/token-assessment-framework/).
-* Publicize all your policies and fees.
-* Provide an [`xrp-ledger.toml` file](xrp-ledger-toml.html) with domain verification so client applications can display relevant details about you.
+## Asset Information
 
+Publish standard information about your stablecoin to enable potential traders to verify the coin's stability.
 
-### Hot and Cold Wallets
 
-{% include '_snippets/issuing-and-operational-addresses-intro.md' %}
+### Asset Nomenclature
 
-Main article: [Issuing and Operational Addresses](account-types.html)
+Choose a 3-character string for your currency code. Per ISO 4217, supranational currency codes begin with the letter _X_ for a currency that is not associated with a country. See [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217#X_currencies_(funds,_precious_metals,_supranationals,_other)).
 
+Currency codes do not have to be unique. For instance, if you're issuing a stablecoin backed by a national fiat currency, it's better to use the official code for that currency, such as _EUR_.
 
-## Fees and Revenue Sources
+### xrp-ledger.toml
 
-A stablecoin issuer can earn revenue in a variety of ways, including:
+You can use the _Currencies_ table in an XRPL TOML file on your website to provide additional information about your stablecoin. This makes the information about your cryptocurrency accessible in an expected place and format, and enhances transparency. See [xrp-ledger.toml File](xrp-ledger-toml.html#currencies).
 
-- Withdrawal or Deposit fees. The issuer can charge a small fee (such as 1%) for the service of moving money into or out of the XRP Ledger. This fee isn't assessed on the XRP Ledger, but in the issuer's own systems when deciding how much to issue or credit users.
-- Transfer fees. The issuer can set a percentage fee to charge when users transfer the stablecoin within the XRP Ledger. This amount is debited from the XRP Ledger whenever users transact, decreasing the total obligation the stablecoin issuer owes to its users in the ledger without decreasing the amount of assets the issuer holds outside of the ledger.
-- Indirect revenue from value added. Stablecoins provide convenient functionality that can ease the adoption of other, adjacent services.
-- Interest on collateral. The issuer can hold the assets backing the stablecoin in an interest-earning account. Of course, they must make sure that they can always access enough funds to serve customer withdrawals.
-- Financial exchange. The business can buy and sell its own stablecoins in the decentralized exchange, providing liquidity to cross-currency payments and possibly making a profit. (As with all financial exchange, profits are not guaranteed.)
 
+## Account and Key Management
 
-### Choosing Fee Rates
+### Multisignature Schemes
 
-Fees on tokens are optional. Higher fees earn more revenue when those tokens are used. On the other hand, high fees discourage customers from using your services. Consider the fees that are charged by other issuers, especially others with tokens backed by the same type of assets, as well as traditional payment systems outside of the XRP Ledger, such as wire fees. Choosing the right fee structure is a matter of balancing your pricing with what the market is willing to pay.
+By using multiple keys and signing weights, issuers and asset holders can distribute trust and responsibility for approving transactions for an account between different users and systems. This gives you the flexibility to gate those signatures using internal processes and controls.
 
+See [Multi-signing](multi-signing.html).
 
-## Compliance Guidelines
+<!--
+### Omnibus Wallets
 
-Token issuers are responsible for complying with local regulations and reporting to the appropriate agencies. Regulations vary by country and state, but may include the reporting and compliance requirements described in the following sections. Before issuing a token, you should seek professional legal advice on the requirements for your jurisdiction and use case. The following resources may be useful background reading.
+For customers who prefer not to take custody of their own wallets, you can create an omnibus account with subaccounts, then assign these accounts to customers.
 
-### Know Your Customer (KYC)
+## Treasury Management
 
-Know Your Customer (KYC) refers to due diligence activities conducted by a financial institution to determine and verify the identity of its customers to prevent use of the institution for criminal activity. Criminal activity in financial terms may include money laundering, terrorist financing, financial fraud, and identity theft. Customers may be individuals, intermediaries, or businesses.
+### Reconciliation
 
-The KYC process generally aims to:
+Periodically audit to verify that distributed stablecoins and stablecoins in escrow equal the total number of stablecoins.
 
-- Identify the customer (and, in the case of organizations and businesses, any beneficial owners)
+### Checking Reserves
 
-- Understand the purpose and intended nature of the business relationship
+How to check reserves.
 
-- Understand the expected transaction activity.
+### Proof of Reserves
 
-KYC is critical for financial institutions and related businesses to mitigate risk, especially legal and reputational risk. Having an inadequate or nonexistent KYC program may result in civil and criminal penalties for the institution or individual employees.
+How to transparently report the current number of stablecoins held in reserve.
+-->
 
-See also:
+## Token Operations
 
-- [(USA) Bank Secrecy Act / Anti-Money Laundering Examination Manual](https://bsaaml.ffiec.gov/manual/Introduction/01)
+### Issue a Stablecoin
 
-- [The Non-US Standard on KYC set by the Financial Action Task Force (FATF)](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+Actually issuing a new stablecoin is straightforward. In practice, there are many considerations when issuing a stablecoin that users will trade with confidence.
 
-<!-- SPELLING_IGNORE: ffiec -->
+Before you issue your stablecoin, download and read the questions in the [Self-assessment Questionnaire](https://foundation.xrpl.org/wp-content/uploads/2022/03/self_assessment_questionnaire_140322.pdf). When you are ready to distribute your stablecoin, complete the public [Token Issuer Self-Assessment Questionnaire](https://foundation.xrpl.org/token-assessment-framework/). This allows full transparency to the XRPL community about your new stablecoin.
 
-### Anti-Money Laundering (AML) and Combating the Financing of Terrorism (CFT)
+For additional considerations, see:
 
-Money laundering is the process of moving illegal funds by disguising the source, nature or ownership so that funds can be legally accessed or distributed via legitimate financial channels and credible institutions. In short, it is converting “dirty money” into “clean money.” Anti-Money Laundering (AML) refers to the laws and procedures designed to stop money laundering from occurring.
+- [Stablecoin Issuer - Precautions](stablecoin-precautions.html)
+- [Stablecoin Issuer - Compliance Guidelines](stablecoin-compliance-guidelines.html)
+- [Issue a Fungible Token](issue-a-fungible-token.html)
 
-Terrorist financing is the solicitation, collection, or provision of funds to organizations engaged in terrorist activity or organizations that support terrorism and its proliferation. Combating the Financing of Terrorism (CFT) refers to the process of identifying, reporting, and blocking flows of funds used to finance terrorism.
+### Create a Trust Line
 
-See also:
+Trust lines are structures in the XRP Ledger for holding tokens. Trust lines enforce the XRP Ledger's rule that you cannot cause someone else to hold a token they don't want. This precaution is necessary to enable the XRP Ledger's use case for community credit, among other benefits.
 
-- [“International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation.” FATF, 2012](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+Each "trust line" is a bidirectional relationship consisting of:
 
-- [“Virtual Currencies: Key Definitions and Potential AML/CFT Risks.” FATF, 2014](http://www.fatf-gafi.org/publications/methodsandtrends/documents/virtual-currency-definitions-aml-cft-risk.html)
+- The identifiers for the two accounts that the trust line connects.
+- A single, shared balance, which is positive from the perspective of one account and negative from the other perspective.
+- Various settings and metadata. Each of the two accounts can control its own settings on the trust line. Each side sets a limit on the trust line.
 
-<!-- SPELLING_IGNORE: fatf, cft -->
+Each trust line is specific to a given currency code. Two accounts can have any number of trust lines between them for different currency codes, but only one shared trust line for any particular currency code.
 
-### Source of Funds
+See [Trust Lines](trust-lines-and-issuing.html#trust-lines).
 
-To prevent illicit funds from passing through their systems, financial institutions must be able to determine within reason if the source of a customer’s funds is linked to criminal activity.
+### Authorized Trust Lines
 
-Determining the exact source of funds for every customer may not be administratively feasible. As a result, some regulatory authorities may not provide specific regulation or guidance for all accounts. In specific cases, however, authorities may require financial institutions to identify and report the source of funds. Guidance by the FATF recommends that where the risks of money laundering or terrorist financing are higher (commonly referred to as a “risk-based approach”), financial institutions conduct enhanced due diligence, including but not limited to determining the customer’s source of funds.
+The Authorized Trust Lines feature enables issuers to create tokens that can only be held by accounts that the issuer specifically authorizes. This feature only applies to tokens, not XRP.
 
-<!-- STYLE_OVERRIDE: feasible -->
+To use the Authorized Trust Lines feature, enable the `Require Auth` flag on your issuing account. While the setting is enabled, other accounts can only hold tokens you issue if you have authorized those accounts' trust lines to your issuing account.
 
-### Suspicious Activity Reporting
+See [Authorized Trust Lines](authorized-trust-lines.html).
 
-If a financial institution suspects that funds may be related to criminal activity, the institution must file a Suspicious Activity Report (SAR) with the appropriate regulatory authority. Failure to report suspicious activity may result in in penalties for the institution.
 
-See also:
+### Freeze a Trust Line
 
-- [Suspicious Activity Reporting Overview (USA FFIEC)](https://bsaaml.ffiec.gov/manual/RegulatoryRequirements/04_ep)
+If you issue tokens in the XRP Ledger, you can enable the _No Freeze_ setting to permanently limit your own ability to use the token freezing features of the XRP Ledger. (As a reminder, this only applies to issued tokens, not XRP.)
 
-- [FATF Recommendation 16: Reporting of suspicious transactions and compliance](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
+If you do not enable the _No Freeze_ setting, when an account shows suspicious activity or violates your institution's terms of use, you have the option of freezing the trust line while you resolve the issue.
 
-### Travel Rule
+See [Freezing Tokens](freezes.html).
 
-The Travel Rule is a Bank Secrecy Act (BSA) rule requiring funds-transmitting financial institutions to forward certain information to the next financial institution if the funds transmittal equals or exceeds the USD equivalent of $3,000. The following information must be included in the transmittal order:
 
-- The name of the transmittor,
-- The account number of the transmittor, if used,
-- The address of the transmittor,
-- The identity of the transmittor's financial institution,
-- The amount of the transmittal order,
-- The execution date of the transmittal order, and
-- The identity of the recipient's financial institution.
+### Global Freeze
 
-<!-- SPELLING_IGNORE: transmittor -->
+If you see signs of suspicious activity, you can enact a global freeze on your account to prevent users from sending your tokens to each other and trading your token in the decentralized exchange.
 
-See also:
+![Global Freeze](img/uc-stablecoin-global-freeze.png)
 
-- [Funds “Travel” Regulations: Questions & Answers ](https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers)
+See [Enact Global Freeze](enact-global-freeze.html)
 
-### Fee Disclosure and Tracing Funds
 
-- In the United States, Dodd Frank 1073 Electronic Fund Transfer Act (Regulation E) requires banks to provide information on cost and delivery terms for international payments originating in the US including exchange rate, fees, and the amount to be received by the designated recipient in the foreign country. "Pre-payment disclosure" is provided to a consumer when requesting an international electronic payment and “receipt disclosure” is provided to a consumer at the time consumer authorizes the transfer.
+### Clawback
 
-    See also:
+_(Requires the [Clawback amendment][] :not_enabled:)_
 
-    - [The Consumer Financial Protection Bureau description of the regulation and extensions for banks](https://www.consumerfinance.gov/rules-policy/final-rules/electronic-fund-transfers-regulation-e/#rule)
+Clawback is an optional setting that you can choose before you begin to distribute your stablecoin. For regulatory purposes, some issuers _must_ have the ability to recover issued tokens after they are distributed to accounts. For example, if an issuer were to discover that tokens were sent to an account sanctioned for illegal activity, the issuer could recover, or _claw back_, the funds.
 
-- In the European Union, EU Funds Transfer Regulation requires that the originator’s bank, the beneficiary’s bank, and any intermediary banks include certain details of the payer and payee in transaction details to detect, investigate, and prevent money laundering and terrorist financing.
+See [Clawback](clawback.html).
 
-    See also:
+![Clawback](img/uc-stablecoin-clawback.png)
 
-    - [EU Regulation (EC) No 1781/2006 description](http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:345:0001:0009:EN:PDF)
+### Partial Payments
 
-    - [Effective June 26, 2017: Regulation 2015/847 on information accompanying transfers of funds](http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32015R0847)
+Look out for partial payments. Payments with the partial payment flag enabled can be considered "successful" if any non-zero amount is delivered, even minuscule amounts.
+* Check the transaction for a `delivered_amount` field. If present, that field indicates how much money _actually_ got delivered to the `Destination` address.
+* In xrpl.js, you can use the [`xrpl.getBalanceChanges()` method](https://js.xrpl.org/modules.html#getBalanceChanges) to see how much each address received. In some cases, this can be divided into multiple parts on different trust lines.
 
-### Office of Foreign Assets Control (OFAC)
+See [Partial Payments](partial-payments.html).
 
-The Office of Foreign Assets Control (OFAC) is an agency of the US Department of Treasury that administers and enforces economic and trade sanctions in support of U.S. foreign policy and national security objectives. All U.S. persons and U.S. incorporated entities and their foreign branches must follow OFAC regulations. Under OFAC regulations, U.S. financial institutions are prohibited—unless authorized by OFAC or expressly exempted by statute—from conducting transactions and other dealings with individuals, entities, or countries under sanctions or embargo programs administered and enforced by OFAC.
+### Burn
 
-See also:
+One way to manage the value of a token is to destroy, or _burn_ tokens, which reduces the number of tokens in circulation. On the XRP Ledger, fungible tokens are automatically "burned" when they are sent to the issuing address. However, the issuer can freely create more tokens.
 
-- [A list of OFAC resources](https://www.treasury.gov/resource-center/faqs/Sanctions/Pages/ques_index.aspx)
+To ensure a limited supply, you can "black hole" the issuer after issuing tokens, by setting its regular key to an address like `rrrrrrrrrrrrrrrrrrrrrhoLvTp` for which no one knows the private key, and disabling the master key pair.
 
-<!-- SPELLING_IGNORE: ofac -->
+**Warning:** A black hole account has no way to send transactions of any kind, so you cannot update any settings or do any maintenance on the account afterwards!
 
-### Guidance on Virtual Currency and Money Service Business
+See [Disable Master Key Pair](disable-master-key-pair.html).
 
-- United States:
-
-    - [FinCEN Guidance and Definitions around Virtual Currency, March 18, 2013](https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-persons-administering)
-
-    - [FinCEN Publishes Two Rulings on Virtual Currency Miners and Investors, January 30, 2014](https://www.fincen.gov/news/news-releases/fincen-publishes-two-rulings-virtual-currency-miners-and-investors)
-
-- Europe:
-
-    - [European Banking Authority Opinion on Virtual Currencies, July 4, 2014](http://www.eba.europa.eu/documents/10180/657547/EBA-Op-2014-08+Opinion+on+Virtual+Currencies.pdf)
-
-- FATF Guidance for Money Service Businesses:
-
-    - [Financial Action Task Force, July 2009](http://www.fatf-gafi.org/media/fatf/documents/reports/Guidance-RBA-money-value-transfer-services.pdf)
-
-
-
-
-# XRP Ledger Integration
-
-This document uses the example of a fictional cryptocurrency exchange called ACME Exchange which decides to issue an EUR stablecoin on the XRP Ledger, to illustrate the overall process and flow of funds for a stablecoin.
-
-## Before Integration
-
-ACME, as a cryptocurrency exchange, already accepts withdrawals and deposits from customers using some system (such as an app or website). ACME has a _system of record_ to track how much each user holds with the exchange in each of several types of assets. Such a system can be modeled with a simple balance sheet, although in practice it probably involves databases, application servers, and various other infrastructure to ensure its reliability, information security, and so on.
-
-In the following diagram, ACME Exchange starts with €5 on hand, including €1 that belongs to Bob, €2 that belongs to Charlie, and an additional €2 of equity that belongs to ACME itself. Alice deposits €5, so ACME adds her to its balance sheet and ends up with €10.
-
-![Diagram: Alice sends €5 to ACME. ACME adds her balance to its balance sheet.](img/e2g-01.png)
-
-**Assumptions:** To integrate with the XRP Ledger, we assume that an exchange such as ACME meets the following assumptions:
-
-* ACME already has a system to accept deposits and withdrawals from some outside payment source.
-* ACME waits for deposits to clear before crediting them in ACME's system of record.
-* ACME always keeps enough funds on-hand to pay withdrawals on demand, subject to their terms and conditions.
-    * ACME can set fees, minimum withdrawals, and delay times for deposits and withdrawals as their business model demands.
-
-## Sending into the XRP Ledger
-
-Sending money _into_ the XRP Ledger involves issuing new stablecoins for an amount that ACME holds on behalf of one of its users. An example flow might look like this:
-
-1. Alice asks to send €3 of her ACME balance into the XRP Ledger.
-2. In its system of record, ACME debits Alice's balance €3.
-3. ACME submits an XRP Ledger transaction, sending €3 to Alice's XRP Ledger address. The €3 is marked in the XRP Ledger as being "issued" by ACME (3 EUR.ACME).
-
-**Assumptions:**
-
-* Alice already has an address in the XRP Ledger separate from her ACME account. Alice manages her XRP Ledger address using a third-party client application (wallet).
-
-![Diagram: ACME issues 3 EUR.ACME to Alice on the XRP Ledger](img/e2g-02.png)
-
-<!--{# Disabled: UMLet version of this diagram.
-{{ include_svg("img/gateway-to-xrpl.svg", "Diagram: ACME issues 3 EUR.ACME to Alice on the XRP Ledger") }}
-#}-->
-
-After this, Alice can send or trade her EUR.ACME to other users in the XRP Ledger at her discretion. At any time, ACME can query the XRP Ledger to see who currently holds its tokens. 
-
-### Requirements for Sending to XRP Ledger
-
-There are several prerequisites that ACME must meet for this to happen:
-
-- ACME sets aside the funds that back its stablecoin. There are several ways ACME may do this:
-    - ACME may create a XRP Ledger collateral account in ACME's system of record.
-    - ACME can store the funds allocated to the XRP Ledger in a separate bank account.
-    - If the stablecoin is backed by cryptocurrency, ACME can create a separate wallet to hold the funds allocated to the XRP Ledger, as publicly-verifiable proof of its reserves.
-- ACME should control two separate XRP Ledger addresses. See [Issuing and Operational Addresses](account-types.html) for details.
-    - ACME must enable the Default Ripple flag on its issuing address for customers to send and receive its tokens.
-- Alice must create an accounting relationship (trust line) from her XRP Ledger address to ACME's issuing address. She can do this from any XRP Ledger client application as long as she knows ACME's issuing address.
-    - ACME should publicize its issuing address on its website where customers can find it. It can also use an [`xrp-ledger.toml` file](xrp-ledger-toml.html) to publish the issuing address to automated systems.
-	- Alternatively, instead of sending a Payment, ACME can write Alice as a Check in the XRP Ledger. This does not move any money right away, but creates both the trust line and the tokens together when Alice cashes the Check.
-- ACME must create a user interface for Alice to request for her funds from ACME to be sent into the XRP Ledger.
-    - ACME needs to know Alice's XRP Ledger address. ACME can have Alice input her XRP Ledger address as part of the interface, or ACME can require Alice to input and verify her XRP Ledger address in advance.
-
-
-## Sending from XRP Ledger
-
-A payment out of the XRP Ledger means the issuer receives a payment in the XRP Ledger, and credits a user in the issuer's system of record.
-
-An example flow of a payment out of the XRP Ledger:
-
-1. Bob sends an XRP Ledger transaction of €1 to ACME's issuing address.
-2. In ACME's system of record, ACME credits Bob's balance €1.
-3. Later, Bob can use ACME's own interface to withdraw the money to a separate account, such as requesting a bank deposit over the SEPA system (Europe) or ACH (United States), receiving a payment on another blockchain, or something else.
-
-XRP Ledger Payments going to an issuer can be single-currency or cross-currency payments, but the amount the issuer receives is typically denominated in the stablecoin it issued.
-
-
-### Requirements for Receiving from XRP Ledger
-
-In addition to the requirements for sending into the XRP Ledger, there are several prerequisites that ACME must meet to process payments coming from the XRP Ledger:
-
-- ACME must monitor its XRP Ledger addresses for incoming payments.
-- ACME must know which user to credit in its system of record for the incoming payments.
-    - ACME should bounce unrecognized incoming payments back to their sender.
-    - Typically, the preferred method of recognizing incoming payments is through [destination tags](source-and-destination-tags.html).
-
-
-## Precautions
-
-Processing payments to and from the XRP Ledger naturally comes with some risks, so an issuer should be sure to take care in implementing these processes. As a stablecoin issuer, you should take the following precautions:
-
-- Protect yourself against reversible deposits. XRP Ledger payments are irreversible, but many digital payments are not. Scammers can abuse this to take their fiat money back by canceling a deposit after receiving tokens in the XRP Ledger.
-- When sending into the XRP Ledger, always specify your issuing address as the issuer of the token. Otherwise, you might accidentally use paths that deliver the same currency issued by other addresses.
-- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any transfer fee you have set.
-- Before processing a payment out of the XRP Ledger, make sure you know the customer's identity. This makes it harder for anonymous attackers to scam you. Most anti-money-laundering regulations require this anyway. This is especially important because the users sending money from the XRP Ledger could be different than the ones that initially received the money in the XRP Ledger.
-- Follow the guidelines for [reliable transaction submission](#reliable-transaction-submission) when sending XRP Ledger transactions.
-- [Robustly monitor for incoming payments](#robustly-monitoring-for-payments), and read the correct amount. Don't mistakenly credit someone the full amount if they only sent a [partial payment](partial-payments.html).
-- Track your obligations and balances within the XRP Ledger, and compare with the assets in your collateral account. If they do not match up, stop processing withdrawals and deposits until you resolve the discrepancy.
-- Avoid ambiguous situations. We recommend the following:
-    - Enable the `Disallow XRP` flag for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.)
-    - Enable the [`RequireDest` flag](require-destination-tags.html) for the issuing address and all operational addresses, so customers do not accidentally send a payment without the destination tag to indicate who should be credited.
-    - Enable the `RequireAuth` flag on all operational addresses so they cannot issue tokens by accident.
-- Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments.
-
-## Trading on the XRP Ledger
-
-After the tokens have been created in the XRP Ledger, they can be freely transferred and traded by XRP Ledger users. There are several consequences of this situation:
-
-- Anyone can buy/sell EUR.ACME on the XRP Ledger. If ACME issues multiple tokens, a separate trust line is necessary for each.
-    - This includes XRP Ledger users who do not have an account in ACME Exchange's systems. To withdraw the funds successfully from ACME, users still have to register with ACME.
-    - Optionally, ACME uses the [Authorized Trust Lines](#authorized-trust-lines) feature to limit who can hold EUR.ACME in the XRP Ledger.
-    - If ACME determines that a customer has acted in bad faith, ACME can [Freeze](#freeze) that user's accounting relationships to ACME in the XRP Ledger, so that the user can no longer trade in the issuer's tokens.
-- XRP Ledger users trading and sending EUR.ACME to one another requires no intervention by ACME.
-- All exchanges and balances in the XRP Ledger are publicly viewable.
-
-The following diagram depicts an XRP Ledger payment sending 2 EUR.ACME from Alice to Charlie. ACME can query the XRP Ledger to see updates to its balances any time after the transaction has occurred:
-
-![Diagram: Alice's sends 2 EUR.ACME from her trust line to Charlie's](img/e2g-03.png)
-
-
-
-## Freeze
-
-An issuer can freeze accounting relationships in the XRP Ledger to meet regulatory requirements:
-
-* Issuers can freeze individual accounting relationships, in case a customer address shows suspicious activity or violates a issuer's terms of use.
-* Issuers can freeze all tokens they issue, in case of a major security compromise or for migrating to a new issuing address.
-* Furthermore, issuers can permanently opt out of their ability to freeze accounting relationships. This allows an issuer to assure its customers that it will continue to provide "physical-money-like" services. <!-- STYLE_OVERRIDE: will -->
-
-For more information, see the [Freeze article](freezes.html).
-
-
-## Authorized Trust Lines
-
-The XRP Ledger's Authorized Trust Lines feature (formerly called "Authorized Accounts") enables an issuer to limit who can hold that issuer's tokens, so that unknown XRP Ledger addresses cannot hold the tokens.
-
-For more information, see [Authorized Trust Lines](authorized-trust-lines.html).
-
-
-## Source and Destination Tags
-
-*Destination Tags* are a feature of XRP Ledger payments can be used to indicate the beneficiary or destination for a payment. For example, an XRP Ledger payment to an issuer may include a destination tag to indicate which customer should be credited for the payment. An issuer should keep a mapping of destination tags to accounts in the issuer's system of record.
-
-Similarly, *Source Tags* indicate the originator or source of a payment. Most commonly, a Source Tag is included so that the recipient of the payment knows where to bounce the payment. When you bounce an incoming payment, use the Source Tag from the incoming payment as the Destination Tag of the outgoing (bounce) payment.
-
-You can generate a destination tag on-demand when a customer intends to send money to you. For greater customer privacy, you should consider that destination tag valid only for that payment with the expected amount, and bounce or ignore any other transactions that reuse the same destination tag.
-
-[Enable the Require Destination Tag setting](require-destination-tags.html) on your issuing and operational addresses so that customers must use a destination tag to indicate where funds should be credited when they send payments to you.
-
-For more information, see [Source and Destination Tags](source-and-destination-tags.html).
-
-
-# Technical Details
-
-## Infrastructure
-
-For your own security as well as the stability of the network, each XRP Ledger business should [run its own XRP Ledger servers](install-rippled.html) including one [validator](rippled-server-modes.html#validators).
-
-
-### APIs and Middleware
-
-There are several interfaces you can use to connect to the XRP Ledger, depending on your needs and your existing software:
-
-- [HTTP / WebSocket APIs](http-websocket-apis.html) can be used as a low-level interface to all core XRP Ledger functionality.
-- [Client Libraries](client-libraries.html) are available in several programming languages to provide convenient utilities for accessing the XRP Ledger.
-- Other tools such as [xApps](https://xumm.readme.io/docs/xapps) are also available.
-- Third party wallet applications may also be useful, especially for humans in charge of standby addresses.
-
-
-## Tool Security
-
-Any time you submit an XRP Ledger transaction, it must be signed using your secret key. The secret key gives full control over your XRP Ledger address. **Never** send your secret key to a server run by someone else. Either use your own server, or sign the transactions locally using a client library.
-
-For instructions and examples of secure configurations, see [Set Up Secure Signing](secure-signing.html).
-
-## Issuer Setup
-
-There are some settings you must configure on your XRP Ledger account before you start issuing tokens. For examples of how to configure these settings, see the [Issue a Fungible Token tutorial](issue-a-fungible-token.html).
-
-Settings you may want to configure include:
-
-| Setting | Notes |
-|---------|-------|
-| Default Ripple | Issuers **must** enable this field. |
-| Deposit Authorization | Block all incoming payments from users you haven't explicitly approved. |
-| Require Auth | Restrict your tokens to being held by users you've explicitly approved. |
-| Tick Size | Round off exchange rates in the decentralized exchange to facilitate faster price discovery. |
-| Transfer Fee | Charge a percentage fee when users send your token to each other. |
-
-
-### Default Ripple
-
-The Default Ripple flag controls whether the balances on a trust line are [allowed to ripple](rippling.html) by default. Rippling is what allows customers to send and trade tokens among themselves, so an issuer MUST allow rippling on all the trust lines to its issuing address.
-
-Before asking customers to create trust lines to its issuing address, an issuer should enable the Default Ripple flag on that address. Otherwise, the issuer must individually disable the No Ripple flag for each trust line that other addresses have created.
-
-
-### Deposit Authorization
-
-The Deposit Authorization setting blocks all incoming payments to your account, unless either:
-
-- You have previously preauthorized the sender.
-- You send a transaction to receive the funds. For example, you could finish an Escrow that was initiated by a stranger.
-
-Deposit Authorization is most useful for blocking unwanted XRP payments, because you already can't receive tokens unless you've created a trust line to their issuer. However, as a stablecoin issuer, you need to be able to receive payments from users in order for them to redeem the stablecoin for its off-ledger value; you can preauthorize your customers but doing so requires storing an object in the ledger for each custom address, increasing your reserve requirement substantially.
-
-Therefore, Deposit Authorization is not recommended for stablecoin issuers unless you need it to meet regulatory requirements about receiving money from unknown or sanctioned entities.
-
-For more information, see [Deposit Authorization](depositauth.html).
-
-
-### Disallow XRP
-
-The Disallow XRP setting is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments from addresses that aren't intended to receive and hold XRP. The Disallow XRP flag is not enforced at the protocol level, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the Disallow XRP flag by default, but may allow users to ignore it.
-
-The Disallow XRP flag is optional, but if you don't intend to receive XRP from customers you may want to enable it on your issuing address and all your operational addresses.
-
-
-### Require Auth
-
-The Require Auth setting blocks users from holding the tokens you issue unless you explicitly approve their trust lines first. You can use this setting to meet regulatory requirements if it matters who holds your tokens within the XRP Ledger. However, this can reduce the utility of your tokens since your approval becomes a bottleneck for users to use them.
-
-Also, you must use your issuing address each time you authorize a trust line; if you must authorize a lot of trust lines, this can undermine the security of your issuing address because you have to use it so often. (If you only need to use the issuing address sparingly, you can put greater protections on its secret keys. The more often you use it, the more of a burden those protections become.)
-
-For more information, see [Authorized Trust Lines](authorized-trust-lines.html).
-
-
-### Tick Size
-
-The Tick Size setting controls how many decimal places are used when calculating exchange rates in the [Decentralized Exchange](decentralized-exchange.html). A higher Tick Size means more precision and less rounding in the amounts of various trades. Too much precision can be inconvenient because trades are ranked primarily based on exchange rate, so a trader can offer a minuscule amount more to the top of the list. A smaller Tick Size works similar to the minimum bid increment at an auction, saving everyone the time and effort of gradually bidding up a price by irrelevantly small amounts. However, a smaller Tick Size results in more rounding, which can increase the costs of trading, and sometimes has surprising results because two Offers that seemed like an exact match before rounding no longer match after rounding.
-
-The Tick Size is an account-level setting and applies to all tokens issued by the same address.
-
-Tick Size only controls the precision of _exchange rates_, not the precision of the token itself. Users can send and hold very large or very small amounts regardless of the Tick Size set by the token's issuer.
-
-For more information, see [Tick Size](ticksize.html).
-
-
-### Transfer Fees
-
-A transfer fee setting charges users a percentage fee when sending your tokens to each other. The transfer fee does not apply when issuing tokens or redeeming them directly with the issuing address. (It _does_ apply when users send payments to your hot wallet.) If you issue multiple tokens from the same address, the same transfer fee applies to all of them.
-
-When users send a token with a transfer fee, the amount of the transfer fee is debited from the sending side in addition to the destination amount, but only the destination amount is credited to the recipient. The amount of the fee "vanishes" from the XRP Ledger. As a stablecoin issuer, this means that you gain that much equity in your reserves outside of the XRP Ledger—or, in other words, the amount you need to keep as collateral decreases each time users pay a transfer fee.
-
-At a protocol level, the transfer fee is defined by the `TransferRate` account setting, which is an integer from 1 billion to 2 billion.
-
-For more information, see [Transfer Fees](transfer-fees.html).
-
-
-### Transfer Fees with Operational and Standby Addresses
-
-All XRP Ledger addresses, including operational and standby addresses, are subject to the issuer's transfer fees when sending tokens. If you set a nonzero transfer fee, then you must send extra (to pay the transfer fee) when making payments from your operational address or standby address. In other words, your addresses must pay back a little of the balance your issuing address created, each time you make a payment.
-
-Set the [`SendMax` transaction parameter][Payment] higher than the destination `Amount` parameter by a percentage based on the `TransferRate` setting.
-
-**Note:** Transfer fees do not apply when sending tokens directly from or to the issuing address. The issuing address must always accept its tokens at face value in the XRP Ledger. This means that customers don't have to pay the transfer fee if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the transfer fee the customer pays.
-
-For example: If ACME sets a transfer fee of 1%, an XRP Ledger payment to deliver 5 EUR.ACME from a customer address to ACME's issuing address would cost exactly 5 EUR.ACME. However, the customer would need to send 5.05 EUR.ACME to deliver 5 EUR.ACME to ACME's operational address. When ACME credits customers for payments to ACME's operational address, ACME credits the customer for the amount delivered to the operational address _and_ the transfer fee, giving the customer €5,05 in ACME's systems.
-
-
-## Robustly Monitoring for Payments
-
-To robustly check for incoming payments, issuers should do the following:
-
-* Keep a record of the most-recently-processed transaction and ledger. That way, if you temporarily lose connectivity, you know how far to go back.
-* Check the result code of every incoming payment. Some payments go into the ledger to charge an anti-spam fee, even though they failed. Only transactions with the result code `tesSUCCESS` can change non-XRP balances. Only transactions from a validated ledger are final.
-* Look out for [Partial Payments](partial-payments.html). Payments with the partial payment flag enabled can be considered "successful" if any non-zero amount is delivered, even minuscule amounts.
-    * Check the transaction for a [`delivered_amount` field](partial-payments.html#the-delivered_amount-field). If present, that field indicates how much money *actually* got delivered to the `Destination` address.
-    * In xrpl.js, you can use the [`xrpl.getBalanceChanges()` method](https://js.xrpl.org/modules.html#getBalanceChanges) to see how much each address received. In some cases, this can be divided into multiple parts on different trust lines.
-* Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero transfer fee, then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's tokens.
-
-To make things simpler for your customers, we recommend accepting payments to both your operational address and your issuing addresses.
-
-As an added precaution, we recommend comparing the balances of your issuing address with the collateral funds in your internal accounting system as of each new XRP Ledger ledger version. The issuing address's negative balances should match the assets you have allocated to XRP Ledger outside the network. If the two do not match up, then you should suspend processing payments into and out of the XRP Ledger until you have resolved the discrepancy.
-
-* Use the `gateway_balances` method to check your balances.
-* If you have a Transfer Fee set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your tokens among themselves.
-
-For more details on how to read the details of incoming transactions, see [Look Up Transaction Results](look-up-transaction-results.html).
-
-
-
-## Sending Payments to Customers
-
-When you build an automated system to send payments into the XRP Ledger for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find ways to trick a system into paying them more money than it should.
-
-Generally, when sending stablecoins, you use a [Payment transaction][]. Some of the details are different depending on whether you are issuing tokens for the first time or transferring them from a hot wallet to a customer. Things to note include:
-
-- When issuing new tokens from your issuing address, you should omit the `SendMax` field. Otherwise, malicious users can arrange their settings so that you issue the full `SendMax` amount instead of just the intended destination `Amount`.
-- When sending tokens _from a hot wallet_, you must specify `SendMax` if you have a nonzero transfer fee. In this case, set the `SendMax` field to the amount specified in the `Amount` field plus the transfer fee. (You may want to round up slightly, in case the precision of your calculations doesn't exactly match the XRP Ledger's.) For example, if you send a transaction whose `Amount` field specifies 99.47 USD, and your transfer fee is 0.25%, you should set the `SendMax` field to 124.3375, or 124.34 USD if you round up.
-- Omit the `Paths` field. This field is unnecessary when sending directly from the issuer, or from a hot wallet as long as the tokens being sent and the tokens being received have the same currency code and issuer—that is, they're the same stablecoin. The `Paths` field is intended for [Cross-Currency Payments](cross-currency-payments.html) and longer multi-hop (rippling) payments. If you naively perform pathfinding and attach the paths to your transaction, your payment may take a more expensive indirect route rather than failing if the direct path is not available; malicious users can even set this up to 
-- If you get a `tecPATH_DRY` result code, this usually indicates that either the customer doesn't have the necessary trust line set up already, or your issuer's rippling settings aren't configured correctly.
-
-For a detailed tutorial on issuing a token on the XRP Ledger, whether a stablecoin or otherwise, see [Issue a Fungible Token](issue-a-fungible-token.html).
-
-
-## Bouncing Payments
-
-When one of your addresses receives a payment whose purpose is unclear, we recommend that you try to return the money to its sender. While this is more work than pocketing the money, it demonstrates good faith towards customers. You can have an operator bounce payments manually, or create a system to do so automatically.
-
-The first requirement to bouncing payments is [robustly monitoring for incoming payments](#robustly-monitoring-for-payments). You do not want to accidentally refund a customer for more than they sent you! (This is particularly important if your bounce process is automated.) Malicious users can take advantage of a naive integration by sending [partial payments](partial-payments.html#partial-payments-exploit).
-
-Second, you should send bounced payments as Partial Payments. Since third parties can manipulate the cost of pathways between addresses, Partial Payments allow you to divest yourself of the full amount without being concerned about exchange rates within the XRP Ledger. You should publicize your bounced payments policy as part of your terms of use. Send the bounced payment from either an operational address or a standby address.
-
-To send a Partial Payment, enable the [`tfPartialPayment` flag](payment.html#payment-flags) on the transaction. Set the `Amount` field to the amount you received and omit the `SendMax` field. You should use the `SourceTag` value from the incoming payment as the `DestinationTag` value for the return payment.
-
-To prevent two systems from bouncing payments back and forth indefinitely, you can set a new Source Tag for the outgoing return payment. If you receive an unexpected payment whose Destination Tag matches the Source Tag of a return you sent, then do not bounce it back again.
-
-
-## Reliable Transaction Submission
+### Reliable Transaction Submission
 
 The goal of reliably submitting transactions is to achieve the following two properties in a finite amount of time:
 
@@ -516,34 +197,19 @@ To submit transactions reliably, follow these guidelines:
 
 For more information, see [Reliable Transaction Submission](reliable-transaction-submission.html).
 
+### List on the XRPL Native DEX
 
-## xrp-ledger.toml File
-
-You can publish information about what currencies you issue, and which XRP Ledger addresses you control, to protect against impostors or confusion, using an [`xrp-ledger.toml` file](xrp-ledger-toml.html). This machine-readable format is convenient for client applications to process. If you run an XRP Ledger validator, you can also publish the key in the same file.
+Decentralized exchanges (DEXes) are integral to the decentralized finance ecosystem. Listing your token on the XRP Ledger's built-in DEX enhances its visibility and accessibility, thereby attracting more liquidity. Begin by placing sell offers using a suitable interface, such as [Sologenic](https://sologenic.org/trade). As a precaution, use a separate account, not your issuing address, to trade.
 
 
-<!-- STYLE_OVERRIDE: gateway, gateways -->
+### List on an AMM
+_(Requires the [AMM amendment][] :not_enabled:)_
 
-## See Also
+Automated Market Makers (AMMs) are smart contracts that provide liquidity in the XRP Ledger's decentralized exchange. Each AMM holds a pool of two assets and enables users to swap between them at an exchange rate set by a formula.
 
-- **Concepts:**
-    - [Tokens](tokens.html)
-    - [Decentralized Exchange](decentralized-exchange.html)
-    - [Source and Destination Tags](source-and-destination-tags.html)
-- **Tutorials:**
-    - [Install `rippled`](install-rippled.html)
-    - [Set Up Secure Signing](secure-signing.html)
-    - [Issue a Fungible Token](issue-a-fungible-token.html)
-    - [Enable No Freeze](enable-no-freeze.html)
-    - [Freeze a Trust Line](freeze-a-trust-line.html)
-    - [Enact Global Freeze](enact-global-freeze.html)
-- **References:**
-    - [Payment transaction][]
-    - [AccountSet transaction][]
-    - [TrustSet transaction][]
-    - [RippleState object](ripplestate.html)
-    - [account_lines method][]
-    - [gateway_balances method][]
+For any given pair of assets, there can be up to one AMM in the ledger. You can create the AMM for an asset pair with your new token if it doesn't exist yet, or deposit to an existing AMM. Those who deposit assets into an AMM are called _liquidity providers_ (LPs) and receive _LP Tokens_ from the AMM.
+
+See [Automated Market Makers](automated-market-makers.html).
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}

dactyl-config.yml

@@ -617,49 +617,40 @@ pages:
             - en
 
     -   md: "@i18n/ja/use-cases/tokenization/stablecoin-issuer.md"
-        parent: tokenization.html
         targets:
             - ja
 
     -   md: use-cases/tokenization/nft-mkt-overview.md
-        parent: tokenization.html
         targets:
             - en
 
     -   md: "@i18n/ja/use-cases/tokenization/nft-mkt-overview.md"
-        parent: tokenization.html
         targets:
             - ja
 
         # TODO: these files aren't nested under "NFT mkt overview" but they are in the nav
     -   md: use-cases/tokenization/nftoken-marketplace.md
-        parent: nft-mkt-overview.html
         targets:
             - en
 
         # TODO: these files aren't nested under "NFT mkt overview" but they are in the nav
     -   md: "@i18n/ja/use-cases/tokenization/nftoken-marketplace.md"
-        parent: nft-mkt-overview.html
         targets:
             - ja
 
     -   md: use-cases/tokenization/authorized-minter.md
-        parent: nft-mkt-overview.html
         targets:
             - en
 
     -   md: "@i18n/ja/use-cases/tokenization/authorized-minter.md"
-        parent: nft-mkt-overview.html
         targets:
             - ja
 
     -   md: use-cases/tokenization/digital-artist.md
-        parent: nft-mkt-overview.html
         targets:
             - en
 
     -   md: "@i18n/ja/use-cases/tokenization/digital-artist.md"
-        parent: nft-mkt-overview.html
         targets:
             - ja
 
@@ -672,22 +663,18 @@ pages:
             - ja
 
     -   md: use-cases/defi/algorithmic-trading.md
-        parent: defi-uc.html
         targets:
             - en
 
     -   md: "@i18n/ja/use-cases/defi/algorithmic-trading.md"
-        parent: defi-uc.html
         targets:
             - ja
 
     -   md: use-cases/defi/list-xrp-as-an-exchange.md
-        parent: defi-uc.html
         targets:
             - en
 
     -   md: "@i18n/ja/use-cases/defi/list-xrp-as-an-exchange.md"
-        parent: defi-uc.html
         targets:
             - ja
 
@@ -1038,147 +1025,203 @@ pages:
         targets:
             - ja
 
+        # TODO: translate
+    -   md: concepts/payment-types/robustly-monitoring-for-payments.md
+        targets:
+            - en
+            - ja
+
+        # TODO: translate
+    -   md: concepts/payment-types/sending-payments-to-customers.md
+        targets:
+            - en
+            - ja
+
+        # TODO: translate
+    -   md: concepts/payment-types/bouncing-payments.md
+        targets:
+            - en
+            - ja
+
     # Tokens ------------------------------------------------------------------
-    -   md: concepts/tokens/tokens.md
+    -   md: concepts/tokens/index.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/tokens.md"
+    -   md: "@i18n/ja/concepts/tokens/index.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/non-fungible-tokens.md
+    -   md: concepts/tokens/fungible-tokens/index.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/non-fungible-tokens.md"
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/index.md"
+        outdated_translation: true
         targets:
             - ja
 
-    -   md: concepts/tokens/nft-storage.md
+    -   md: concepts/tokens/fungible-tokens/authorized-trust-lines.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/nft-storage.md"
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/authorized-trust-lines.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/non-fungible-token-transfers.md
+# TODO - Translate all files under /stablecoins/ directory
+    -   md: concepts/tokens/fungible-tokens/stablecoins/index.md
         targets:
             - en
-
-    -   md: "@i18n/ja/concepts/tokens/non-fungible-token-transfers.md"
-        targets:
             - ja
 
-    -   md: concepts/tokens/nft-reserve-requirements.md
+    -   md: concepts/tokens/fungible-tokens/stablecoins/settings.md
         targets:
             - en
-
-    -   md: "@i18n/ja/concepts/tokens/nft-reserve-requirements.md"
-        targets:
             - ja
 
-    -   md: concepts/tokens/nftoken-batch-minting.md
+    -   md: concepts/tokens/fungible-tokens/stablecoins/configuration.md
         targets:
             - en
-
-    -   md: "@i18n/ja/concepts/tokens/nftoken-batch-minting.md"
-        targets:
             - ja
 
-    -   md: concepts/tokens/nftoken-authorized-minting.md
+    -   md: concepts/tokens/fungible-tokens/stablecoins/precautions.md
         targets:
             - en
-
-    -   md: "@i18n/ja/concepts/tokens/nftoken-authorized-minting.md"
-        targets:
             - ja
 
-    -   md: concepts/tokens/nftoken-auctions.md
+    -   md: concepts/tokens/fungible-tokens/stablecoins/compliance-guidelines.md
         targets:
             - en
-
-    -   md: "@i18n/ja/concepts/tokens/nftoken-auctions.md"
-        targets:
             - ja
 
-    -   md: concepts/tokens/nft-collections.md
+    -   md: concepts/tokens/fungible-tokens/stablecoins/technical-details.md
         targets:
             - en
-
-    -   md: "@i18n/ja/concepts/tokens/nft-collections.md"
-        targets:
             - ja
 
-    -   md: concepts/tokens/nft-fixed-supply.md
-        targets:
-            - en
-
-    -   md: "@i18n/ja/concepts/tokens/nft-fixed-supply.md"
-        targets:
-            - ja
-
-    -   md: concepts/tokens/nft-apis.md
-        targets:
-            - en
-
-    -   md: "@i18n/ja/concepts/tokens/nft-apis.md"
-        targets:
-            - ja
-
-        # TODO: maybe fungible tokens should be in their own folder?
-    -   md: concepts/tokens/trust-lines-and-issuing.md
-        targets:
-            - en
-
-    -   md: "@i18n/ja/concepts/tokens/trust-lines-and-issuing.md"
-        targets:
-            - ja
-
-    -   md: concepts/tokens/authorized-trust-lines.md
-        targets:
-            - en
-
-    -   md: "@i18n/ja/concepts/tokens/authorized-trust-lines.md"
-        targets:
-            - ja
-
-    -   md: concepts/tokens/clawing-back-tokens.md
+    -   md: concepts/tokens/fungible-tokens/clawing-back-tokens.md
         status: not_enabled
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/clawing-back-tokens.md"
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/clawing-back-tokens.md"
         status: not_enabled
         targets:
             - ja
 
-    -   md: concepts/tokens/freezes.md
+    -   md: concepts/tokens/fungible-tokens/freezes.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/freezes.md"
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/freezes.md"
         targets:
             - ja
 
-        # TODO: nest this file appropriately
-    -   md: concepts/tokens/common-misconceptions-about-freezes.md
+    -   md: concepts/tokens/fungible-tokens/common-misconceptions-about-freezes.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/common-misconceptions-about-freezes.md"
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/common-misconceptions-about-freezes.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/rippling.md
+    -   md: concepts/tokens/fungible-tokens/paths.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/rippling.md"
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/paths.md"
         targets:
             - ja
 
+    -   md: concepts/tokens/fungible-tokens/rippling.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/rippling.md"
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/index.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/index.md"
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/payload-storage.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/payload-storage.md"
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/trading.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/trading.md"
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/reserve-requirements.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/reserve-requirements.md"
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/batch-minting.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/batch-minting.md"
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/authorizing-another-minter.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/authorizing-another-minter.md"
+        outdated_translation: true
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/running-an-nft-auction.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/running-an-nft-auction.md"
+        outdated_translation: true
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/collections.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/collections.md"
+        targets:
+            - ja
+
+    -   md: concepts/tokens/nfts/guaranteeing-a-fixed-supply.md
+        targets:
+            - en
+
+    -   md: "@i18n/ja/concepts/tokens/nfts/guaranteeing-a-fixed-supply.md"
+        targets:
+            - ja
+
+        # TODO: translate
+    -   md: concepts/tokens/nfts/nft-apis.md
+        targets:
+            - en
+            - ja
+
     -   md: concepts/tokens/transfer-fees.md
         targets:
             - en
@@ -1187,59 +1230,52 @@ pages:
         targets:
             - ja
 
-    -   md: concepts/tokens/paths.md
+    -   md: concepts/tokens/fungible-tokens/demurrage.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/paths.md"
+    -   md: "@i18n/ja/concepts/tokens/fungible-tokens/demurrage.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/demurrage.md
+    -   md: concepts/tokens/decentralized-exchange/index.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/demurrage.md"
+    -   md: "@i18n/ja/concepts/tokens/decentralized-exchange/index.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/decentralized-exchange.md
+    -   md: concepts/tokens/decentralized-exchange/offers.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/decentralized-exchange.md"
+    -   md: "@i18n/ja/concepts/tokens/decentralized-exchange/offers.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/offers.md
+    -   md: concepts/tokens/decentralized-exchange/autobridging.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/offers.md"
+    -   md: "@i18n/ja/concepts/tokens/decentralized-exchange/autobridging.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/autobridging.md
+    -   md: concepts/tokens/decentralized-exchange/ticksize.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/autobridging.md"
+    -   md: "@i18n/ja/concepts/tokens/decentralized-exchange/ticksize.md"
         targets:
             - ja
 
-    -   md: concepts/tokens/ticksize.md
+    -   md: concepts/tokens/decentralized-exchange/automated-market-makers.md
         targets:
             - en
 
-    -   md: "@i18n/ja/concepts/tokens/ticksize.md"
-        targets:
-            - ja
-
-    -   md: concepts/tokens/automated-market-makers.md
-        targets:
-            - en
-
-    -   md: "@i18n/ja/concepts/tokens/automated-market-makers.md"
+    -   md: "@i18n/ja/concepts/tokens/decentralized-exchange/automated-market-makers.md"
+        outdated_translation: true
         targets:
             - ja
 
@@ -3435,7 +3471,6 @@ pages:
         targets:
             - ja
 
-        # TODO: translate
     -   md: references/http-websocket-apis/public-api-methods/clio-methods/nft_info.md
         targets:
             - en