Merge branch 'master' into mpt_concept_and_refs

2025-11-22 12:45:50 +00:00 · 2024-12-18 11:11:21 -08:00
parent f45bfc9cd8 70e3c785a2
commit 33d8bf8283
157 changed files with 1311 additions and 533 deletions
--- a/.env
+++ b/.env
@@ -1,4 +1,4 @@
 PUBLIC_GITHUB_FORK=https://github.com/XRPLF/xrpl-dev-portal
 PUBLIC_GITHUB_BRANCH=master
-PUBLIC_OWNER_RESERVE=2 XRP
-PUBLIC_BASE_RESERVE=10 XRP
+PUBLIC_OWNER_RESERVE=0.2 XRP
+PUBLIC_BASE_RESERVE=1 XRP
--- a/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
+++ b/@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
@@ -24,13 +24,13 @@ Para ser eliminada, una cuenta debe cumplir los siguientes requisitos:
    - `RippleState`
    - `Check`
 - La cuenta debe tener menos de 1000 objetos en el ledger.
- La transacción debe pagar un [coste de transacción][] especial igual al menos a la [reserva de propietario](reserves.md) de un artículo (actualmente 2 XRP).
+- La transacción debe pagar un [coste de transacción][] especial igual al menos a la [reserva de propietario](reserves.md) de un artículo (actualmente {% $env.PUBLIC_OWNER_RESERVE %}).

 ## Coste de eliminación

 **Atención:** El coste de transacción de la [transacción AccountDelete][] siempre aplica cuando la transacción está incluida en un ledger validado, incluso si la transacción falla porque la cuenta no reune los requisitos para ser eliminada. Para reducir las posibilidades de pagar un coste de transacción alto si la cuenta no puede ser eliminada, utiliza la opción `fail_hard` cuando envíes una transacción AccountDelete.

-A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la cadena del ledger público de XRP Ledger contiene el estado completo del ledger, lo cual incrementa en tamaño con cada cuenta nueva. Por esa razón, no deberías crear nuevas cuentas XRP Ledger si no tienes necesidad. Puedes recuperar parte de los 10 XRP de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos 2 XRP haciéndolo.
+A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la cadena del ledger público de XRP Ledger contiene el estado completo del ledger, lo cual incrementa en tamaño con cada cuenta nueva. Por esa razón, no deberías crear nuevas cuentas XRP Ledger si no tienes necesidad. Puedes recuperar parte de los {% $env.PUBLIC_BASE_RESERVE %} de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos {% $env.PUBLIC_OWNER_RESERVE %} haciéndolo.

 Instituciones que reciben y envían valor en nombre de muchos usuarios pueden utilizar [**Source Tags** y **Destination Tags**](../transactions/source-and-destination-tags.md) para distinguir pagos desde y para sus clientes usando una (o un puñado) de cuentas en el XRP Ledger.

--- a/@l10n/es-ES/docs/concepts/accounts/depositauth.md
+++ b/@l10n/es-ES/docs/concepts/accounts/depositauth.md
@@ -42,7 +42,7 @@ Una cuenta con Deposit Authorization activado:

 - **No puede** ser destinatario de [transacciones Payment][], con **las siguientes excepciones**:
    - Si el destinatario tiene [preautorizado](#preautorización) al remitente del pago. _(Añadido con la [enmienda DepositPreauth][])_
-    - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente 10 XRP). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
+    - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente {% $env.PUBLIC_BASE_RESERVE %}). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
 - Puede recibir XRP de [transacciones PaymentChannelClaim][] **únicamente en los siguientes casos**:
    - El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
    - El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_
--- a/@l10n/es-ES/docs/concepts/accounts/index.md
+++ b/@l10n/es-ES/docs/concepts/accounts/index.md
@@ -46,7 +46,7 @@ La forma típica de obtener una cuenta en el XRP Ledger es la siguiente:

    - Por ejemplo, puedes comprar XRP en un exchange privado, después retirar el XRP del exchange a la dirección que especificaste.

-        **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente 10 XRP), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
+        **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente {% $env.PUBLIC_BASE_RESERVE %}), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.



--- a/@l10n/es-ES/docs/concepts/accounts/reserves.md
+++ b/@l10n/es-ES/docs/concepts/accounts/reserves.md
@@ -25,8 +25,8 @@ Los requisito de reserva consta de dos partes:

 Los requerimientos de reserva actuales en Mainnet son:

- Reserva base: **10 XRP**
- Reserva de propietario: **2 XRP** por artículo
+- Reserva base: **{% $env.PUBLIC_BASE_RESERVE %}**
+- Reserva de propietario: **{% $env.PUBLIC_OWNER_RESERVE %}** por artículo

 Reservas en otras redes pueden variar.

--- a/@l10n/es-ES/docs/concepts/accounts/tickets.md
+++ b/@l10n/es-ES/docs/concepts/accounts/tickets.md
@@ -40,7 +40,7 @@ Más tarde, puedes enviar una transacción utilizando un Ticket específico en v

 Continuando con el ejemplo anterior, puedes enviar una transacción utilizando el número de secuencia 105 o cualquiera de los tres Tickets que has creado. Si envías una transacción utilizando el Ticket 103, esto eliminará el Ticket 103 del ledger. Tu próxima transacción despues de esa puede uitlizar el número de secuencia 105, el Ticket 102, o el Ticket 104.

-**Atención:** Cada Ticket cuenta como un objeto separado para la [reserva de propietario](reserves.md), así que debes apartar 2 XRP por cada Ticket. (El XRP vuelve a estar disponible una vez que se haya utilizado el Ticket.) Este coste puede subir rápidamente si creas un grán número de Tickets a la vez.
+**Atención:** Cada Ticket cuenta como un objeto separado para la [reserva de propietario](reserves.md), así que debes apartar {% $env.PUBLIC_OWNER_RESERVE %} por cada Ticket. (El XRP vuelve a estar disponible una vez que se haya utilizado el Ticket.) Este coste puede subir rápidamente si creas un grán número de Tickets a la vez.

 Como con los números de secuencia, enviar una transacción consume el Ticket _si y solo si_ la transacción es confirmada por [consenso](../consensus-protocol/index.md). Sin embargo, las transacciones que fallan en hacer lo que intentaban pueden ser confirmadas por el consenso con los [códigos de resultado de clase`tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).

@@ -53,7 +53,7 @@ Cualquier cuenta puede crear y utilizar Tickets en cualquier tipo de transaccion
 - Cada Ticket puede ser utilizado solo una vez. Es posible tener múltiples transacciones diferentes candidatas que podrían usar el mismo Ticket Secuencia, pero solo uno de esos candidatos será validado por el consenso.
 - Una cuenta no puede tener más de 250 Tickets en el ledger a la vez. No puedes crear más de 250 Tickets a la vez, tampoco.
 - _Puedes_ usar un Ticket para crear más Tickets. Si lo haces, el Ticket utilizado no cuenta para el número total de Tickets que puedes tener a la vez.
- Cada Ticket cuenta para la [reserva de propietario](reserves.md), por lo que debes apartar 2 XRP por cada Ticket que no has usado todavía. El XRP vuelve a estar disponible para ti despues de utilizar el Ticket.
+- Cada Ticket cuenta para la [reserva de propietario](reserves.md), por lo que debes apartar {% $env.PUBLIC_OWNER_RESERVE %} por cada Ticket que no has usado todavía. El XRP vuelve a estar disponible para ti despues de utilizar el Ticket.
 - Dentro de un ledger individual, las transacciones que usan Tickets se ejecutan después que otras transacciones desde el mismo remitente. Si una cuenta tiene múltiples transacciones utilizando Tickets en la misma versión del ledger, esos Tickets se ejecutan en orden desde el Ticket con la secuencia más baja hasta la más alta. (Para más información, ver la documentación del [orden canónico](../consensus-protocol/consensus-structure.md#calculate-and-share-validations) del consenso.)
 - Para "cancelar" un Ticket, usa el Ticket para [realizar una operación no operativa](../transactions/finality-of-results/canceling-a-transaction.md) [transacción AccountSet][]. Esto elimina el Ticket y tu no tienes que cumplir con los requisitos de reserva.

--- a/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
+++ b/@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
@@ -20,8 +20,10 @@ Los parámetros que puedes configurar son los siguientes:
 | Parámetro | Descripción | Valor recomendado |
 |-----------|-------------|-------------------|
 | `reference_fee` | Cantidad de XRP, en _drops_ (1 XRP = 1 millón de drops.), que debe ser destruido para enviar la transacción de referencia, la transacción más barata posible. El coste de una transacción real es un múltiplo de ese valor, escalado dinámicamente basado en la carga de de los servidores individuales. | `10` (0.00001 XRP) |
-| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger. | `10000000` (10 XRP) |
-| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `2000000` (2 XRP) |
+| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger. | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
+| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |
+
+<!-- RESERVES_REMINDER: update recommendations in drops if reserves change -->

 ## Proceso de votación

--- a/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
+++ b/@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
@@ -18,7 +18,7 @@ El protocolo de pares es el modo principal de comunicación entre servidores en
 - Solicitar datos de ledger de ledgers históricos, o proporcionar esos datos.
 - Proponer una conjunto de transacciones para el consenso, o compartir el resultado calculado de aplicar el conjunto de transacciones de consenso.

-Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando HTTPS y solicita una [actualización HTTP](https://tools.ietf.org/html/rfc7230#section-6.7) para cambiar al protocolo `XRPL/2.0` (anteriormente `RTXP/1.2`). (Para más información, consultar el artículo [Red de superposición](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) en el [repositorio `rippled`](https://github.com/ripple/rippled).)
+Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando HTTPS y solicita una [actualización HTTP](https://tools.ietf.org/html/rfc7230#section-6.7) para cambiar al protocolo `XRPL/2.0` (anteriormente `RTXP/1.2`). (Para más información, consultar el artículo [Red de superposición](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) en el [repositorio `rippled`](https://github.com/XRPLF/rippled).)

 ## Descubrimiento de pares

--- a/@l10n/ja/docs/concepts/accounts/cryptographic-keys.md
+++ b/@l10n/ja/docs/concepts/accounts/cryptographic-keys.md
@@ -15,11 +15,13 @@ XRP Ledgerでは、[トランザクション](../transactions/index.md)による

 {% admonition type="danger" name="警告" %}秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。お使いのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。{% /admonition %}

-
 ## キーの生成

 多くの[クライアントライブラリ](../../references/client-libraries.md)やアプリケーションは、XRP Ledgerでの使用に合わせてキーペアを生成できます。もちろん、信頼できるデバイスやソフトウェアで生成されたキーペアのみを使用する必要があります。悪意のあるアプリケーションは、あなたの秘密情報を悪意のあるユーザに公開する可能性があり、そのユーザはあなたのアカウントから後でトランザクションを送信することができます。

+注：ツールによってデフォルト値が異なります。多くのクライアントライブラリ（xrpl.jsなど）は、デフォルトの暗号化アルゴリズムとしてEd25519を使用していますが、rippledの管理者向けRPCコマンドである[wallet_propose](../../references/http-websocket-apis/admin-api-methods/key-generation-methods/wallet_propose.md)は、デフォルトとしてsecp256k1を使用しています。つまり、アルゴリズムを明示的に指定しない限り、同じシードから別のツールを使用してウォレットを生成すると、異なるアドレスが生成される可能性があります。
+
+
 ## キーの構成要素

 暗号鍵ペアは、鍵の導出プロセスを通じて数学的に関連づけられる**秘密鍵**と**公開鍵**のことです。秘密鍵は、強力なランダム性によって決定されなければなりません。[暗号化署名アルゴリズム](#署名アルゴリズム)は、鍵の導出プロセスを定義し、暗号鍵となり得る数値の制限を設定します。
@@ -29,7 +31,7 @@ XRP Ledgerを扱う場合、パスフレーズ、シード、アカウントID
 [{% inline-svg file="/docs/img/cryptographic-keys.ja.svg" /%}](/docs/img/cryptographic-keys.ja.svg "Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス")
 _図: 暗号鍵の値の関係を簡略化した図_

-パスフレーズ、シード、秘密鍵は**秘密**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。
+パスフレーズ、シード、秘密鍵は**秘密情報**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。

 公開鍵、アカウントID、アドレスは公開情報です。一時的に公開鍵を秘密にするような状況もありますが、最終的にはトランザクションの一部として公開し、XRP Ledgerが署名を検証してトランザクションを処理できるようにすることが必要です。

@@ -96,7 +98,7 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ

 ### 特殊な権限

-**マスターキーペア**のみが、ある特定の処理を行うトランザクションを承認することができます。
+**マスターキーペアのみ**が、ある特定の処理を行うトランザクションを承認することができます。

 - アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](../transactions/index.md#トランザクションの承認)して初期化することができないからです。

--- a/@l10n/ja/docs/concepts/accounts/reserves.md
+++ b/@l10n/ja/docs/concepts/accounts/reserves.md
@@ -25,8 +25,8 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ

 メインネットにおける現在の準備金要件は次の通りです。

- 基本準備金 **10 XRP**
- 所有者準備金 アイテムにつき**2 XRP**
+- 基本準備金 **{% $env.PUBLIC_BASE_RESERVE %}**
+- 所有者準備金 アイテムにつき **{% $env.PUBLIC_OWNER_RESERVE %}**

 他のネットワークでの準備金は異なる場合があります。

--- a/@l10n/ja/docs/concepts/consensus-protocol/fee-voting.md
+++ b/@l10n/ja/docs/concepts/consensus-protocol/fee-voting.md
@@ -1,35 +1,46 @@
 ---
-html: fee-voting.html
-parent: consensus.html
 seo:
-    description: トランザクションコストと必要準備金の変更投票について。
+    description: バリデータが手数料(トランザクションコストおよび準備預金)に投票する方法。
 labels:
  - 手数料
  - XRP
 ---
 # 手数料投票

-バリデータは、基本の[トランザクションコスト](../transactions/transaction-cost.md)と[必要準備金](../accounts/reserves.md)の変更について投票できます。バリデータの構成の設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に公開します。定数のバリデータが変更に合意すると、変更を適用できるようになり、以後この変更が有効になります。バリデータはさまざまな理由から（特にXRPの価値の長期的な変化に適応するために）、この処理を行います。
+手数料投票は、XRP Ledgerの使用料、具体的には基本[トランザクションコスト](../transactions/transaction-cost.md)および[準備金要件](../accounts/reserves.md)を調整するためのシステムです。この手数料の目的は、ネットワークをスパムから保護することにあります。そのため、手数料の投票による決定は、より多くのユーザやユースケースにネットワークを利用可能にするという目的と、ネットワークを悪用や過剰利用から保護するという目的の、競合する優先事項を考慮する必要があります。XRPの価値やネットワークノードのコストおよび機能の長期的な変化に適応するために、定期的な変更が必要です。

-[`rippled`バリデータ](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)のオペレーターは、`rippled.cfg`ファイルの`[voting]`スタンザでトランザクションコストと必要準備金の設定を指定できます。
+[バリデータ](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md) の運用者は、`rippled.cfg` ファイルの `[voting]`セクションで、希望する手数料値を設定することができます。各バリデータは、15分に1回程度の頻度で、ネットワークにその設定値を定期的に伝えます。ネットワークは、信頼されているバリデータの希望の中央値に手数料設定を自動的に調整します。

 {% admonition type="warning" name="注意" %}信頼できるバリデータの合意により不十分な必要準備金が採用された場合、XRP Ledgerピアツーピアネットワークがサービス拒否（DoS）攻撃を受ける可能性があります。{% /admonition %}

 設定できるパラメーターは次の通りです。

-| パラメーター | 説明 | 推奨される値 |
-|-----------|-------------|-------------------|
-| `reference_fee` | リファレンストランザクション（最も安価なトランザクション）を送信するときに消却する必要があるXRPの額（ _drop_ 単位）。（1 XRP = 100万drop）実際のトランザクションコストはこの値の数倍であり、個々のサーバの負荷に基づいて動的に調整されます。 | `10` （0.00001 XRP） |
-| `account_reserve` | アカウントの準備金に必要なXRPの最小額（ _drop_ 単位）。これは、レジャーの新しいアカウントへの資金供給のために送金できる最小額です。 | `10000000` （10 XRP） |
-| `owner_reserve` | アドレスがレジャーで所有するオブジェクト _ごと_ に必要なXRPの額（ _drop_ 単位）。 | `2000000` （2 XRP） |
+| パラメーター        | 説明 | 推奨される値 |
+|-------------------|-------------|-------------------|
+| `reference_fee`   | **リファレンストランザクションのコスト**。これは、リファレンストランザクション（最も安価なトランザクション）を送信するためにバーンしなければならないXRPの量（1 XRP = 100万ドロップ）です。実際のトランザクションコストは、個々のサーバの負荷に応じて動的に調整される、この値の倍数です。 | `10` (0.000010 XRP)  |
+| `account_reserve` | **基本アカウント準備金**。これは、アカウントが保持しなければならないXRPの量（1 XRP = 100万ドロップ）です。これは、新しいアカウントを作成するための最小要件でもあります。 | `1000000` （{% $env.PUBLIC_BASE_RESERVE %}） |
+| `owner_reserve`   | **所有者準備金の増加量**。これは、アカウントがレジャー内で所有する各オブジェクトに対して保持しなければならないXRPの量（1 XRP = 100万ドロップ）です。 | `200000` （{% $env.PUBLIC_OWNER_RESERVE %}） |
+
+<!-- RESERVES_REMINDER: update recommendations in drops if reserves change -->
+
+## 注意事項
+
+手数料の設定は慎重に行ってください。不十分な手数料が過半数の信頼できるバリデータによって採用された場合、ネットワークが様々なサービス拒否(DoS)攻撃を受ける可能性があります。より具体的には
+
+- リファレンストランザクションコストは、トランザクションの過剰な _処理および中継_ からネットワークを保護します。これは、ネットワーク上のすべてのノードが個々にすべてのトランザクションを検証および処理し、それらのトランザクションをすべてのノードに中継する必要があるため、重要な設定です。リファレンストランザクションコストが低すぎると、悪意のあるユーザーが大量のトランザクションを送信してネットワークに過剰な負荷をかけることが可能になります。この設定は主に、ノードのCPUと帯域幅の負荷を保護します。
+- 準備金の設定は、過剰な _データストレージの増加_ からネットワークを保護します これは、ネットワーク上のすべてのサーバが、すべてのアカウントやその他のレジャーエントリタイプを含む最新のレジャーステートの完全なコピーを必要とする点から重要となっています。未使用のアカウントやデータは自動的に削除されないため、準備金分のストレージは、ユーザが積極的に使用していないデータを削除するインセンティブを提供します。準備金の負担が低すぎる場合、悪意のあるユーザがレジャーエントリを大量に作成することでネットワークノードに過剰な負荷をかける可能性があります。これらの設定は主に、サーバのRAMとディスクスペースを保護します。
+
+一般的に、準備金要件の引き上げは、引き下げよりも混乱を招くものです。準備金が減少すると、一部のユーザはそれまでロックされていた資金を利用できるようになりますが、準備金が増加すると、一部のユーザは多くの種類のトランザクションを送信するのに十分な資金を持たなくなります。混乱を最小限に抑えるためには、XRP価格の変動に対応するために準備金を積極的に調整するのではなく、準備金を引き下げる際にはより慎重に判断することが一般的に推奨されます。

 ## 投票プロセス

-256番目の各レジャーは「フラグ」レジャーと呼ばれます。（フラグレジャーは`ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256`が`0`になるように定義されています。）フラグレジャーの直前のレジャーでは、アカウント準備金またはトランザクションコストの設定が現行のネットワーク設定と異なる各バリデータは、そのレジャー検証とともに「投票」メッセージを配信し、バリデータが希望する値を示します。
+256番目の各レジャーは「フラグ」レジャーと呼ばれます。（フラグレジャーは`ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256`が`0`になるように定義されています。）通常、レジャーの閉鎖には3～4秒かかるため、通常、15分ごとに新しいフラグレジャーが作成されます。
+
+フラグレジャーの直前のレジャーでは、アカウント準備金またはトランザクションコストの優先設定が現在のネットワーク設定と異なる各バリデータが、そのレジャーの検証と併せて、バリデータが希望する値を示す「投票」メッセージを配信します。

 フラグレジャー自体では何も起こりませんが、バリデータは信頼する他のバリデータからの投票を受信して記録します。

-他のバリデータの投票を集計した後、各バリデータは自身の設定と信頼する過半数のバリデータの設定の間で妥協点を探ります。（たとえば、あるバリデータが最小トランザクションコストを10から100に引き上げることを望む一方で、ほとんどのバリデータは10から20に引き上げることを望んでいる場合、そのバリデータは当該のコストを20に引き上げることにします。ただし、そのバリデータは10未満の値または100を超える値にすることはありません。）妥協できる場合、バリデータはフラグレジャーの直後のレジャーに対する提案に[SetFee疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/setfee.md)を挿入します。同じ変更を求める他のバリデータは、同じレジャーに対する各自の提案に同じSetFee疑似トランザクションを挿入します。（設定が既存のネットワーク設定と一致している場合、バリデータは何も行いません。）SetFee疑似トランザクションがコンセンサスプロセスを通過し、検証済みレジャーに追加される場合、SetFee疑似トランザクションで設定された新しいトランザクションコストと準備金の設定がその次のレジャーから有効になります。
+他のバリデータの票を集計した後、各バリデータは、それぞれの設定値と信頼する（UNLの）バリデータの大半の設定値の妥協点を見つけるために、各設定における中央値の票を取ります。もし中央値が二つの票の間にある場合、現在の設定により近い値を選択します。もし選択された設定がどれか一つでも現在レジャーで定義されているものとは異なっている場合、バリデータは提案に[SetFee擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/setfee.md)をフラグレジャーの後に挿入します。他のバリデータも、各自の設定値やUNLでの投票に基づいて、提案にSetFee擬似トランザクションを挿入します。値が既存のネットワーク設定と一致するバリデータは、何もしません。SetFee擬似トランザクションが過半数を占め、コンセンサスプロセスを生き残ってバリデータによる検証済みのレジャーに組み込まれた場合、新しいトランザクションコストと準備金設定が、次のレジャーから有効になります。

 まとめ:

@@ -40,10 +51,29 @@ labels:

 ## 手数料の最大値

-手数料の最大可能値は、[FeeSettingsレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)に保管されている内部データ型により制限されます。これらの値は次のとおりです。
+[XRPFees amendment][]が有効でないネットワークでは、手数料の設定可能な最大値は、[FeeSettingsレジャーエントリ](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)に保管されている内部データ型により制限されます。これらの値は次のとおりです。

-| パラメーター | 最大値（drop） | 最大値（XRP）
-|-----------|-----------------------|----|
-| `reference_fee` | 2**64 | （これまでに存在したXRP総額よりも大きい） |
-| `account_reserve` | 2^32 drop | 約4294 XRP |
-| `owner_reserve` | 2^32 drop | 約4294 XRP |
+| パラメーター      | 最大値（drop）       | 最大値（XRP）                             |
+| ----------------- | -------------------- | ----------------------------------------- |
+| `reference_fee`   | 2<sup>64</sup>       | （これまでに存在したXRP総額よりも大きい） |
+| `account_reserve` | 2<sup>32</sup> drops | 約4294 XRP                                |
+| `owner_reserve`   | 2<sup>32</sup> drops | 約4294 XRP                                |
+
+メインネットおよびXRPFees Amendmentが有効になっているその他のネットワークでは、3つの手数料すべてを任意の有効なXRPの金額に設定できるようになりました。
+
+## See Also
+
+- **コンセプト:**
+    - [Amendment](../networks-and-servers/amendments.md)
+    - [トランザクションコスト](../transactions/transaction-cost.md)
+    - [準備金](../accounts/reserves.md)
+    - [トランザクションキュー](../transactions/transaction-queue.md)
+- **チュートリアル:**
+    - [rippledの設定](../../infrastructure/configuration/index.md)
+- **リファレンス:**
+    - [feeメソッド][]
+    - [server_infoメソッド][]
+    - [FeeSettingsオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
+    - [SetFee疑似トランザクション][]
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md
+++ b/@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md
@@ -18,7 +18,7 @@ XRP Ledgerのサーバは、XRP Ledgerピアプロトコル（RTXP）を使用
 - 履歴レジャーへのレジャーデータのリクエスト、またはレジャーデータの提供。
 - コンセンサスのための一連のトランザクションの提示、またはコンセンサストランザクションセットの適用に関する算出結果の共有。

-ピアツーピア接続を確立するには、サーバどうしをHTTPSで接続し、一方のサーバはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)をリクエストします。（詳細は、[`rippled`リポジトリ](https://github.com/ripple/rippled)の[Overlay Network](https://github.com/XRPLF/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)をご覧ください。）
+ピアツーピア接続を確立するには、サーバどうしをHTTPSで接続し、一方のサーバはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)をリクエストします。（詳細は、[`rippled`リポジトリ](https://github.com/XRPLF/rippled)の[Overlay Network](https://github.com/XRPLF/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)をご覧ください。）

 ## ピアの検出

--- a/@l10n/ja/docs/concepts/tokens/nfts/reserve-requirements.md
+++ b/@l10n/ja/docs/concepts/tokens/nfts/reserve-requirements.md
@@ -29,10 +29,12 @@ NFTの保有枚数や保有ページ数によって、所有者準備金の総

 | NFTの保有数  | 最良のケース    | 標準的なケース | 最悪のケース |
 |:------------|:----------|:-------------|:-----------|
-| 32以下         | 2 XRP       | 2 XRP          | 2 XRP      |
-| 50            | 4 XRP        | 6 XRP           | 8 XRP      |
-| 200            | 14 XRP      | 18 XRP         | 26 XRP     |
-| 1000          | 64 XRP      | 84 XRP         | 126 XRP    |
+| 32以下       | 0.2 XRP   | 0.2 XRP      | 0.2 XRP    |
+| 50          | 0.4 XRP   | 0.6 XRP      | 0.8 XRP    |
+| 200         | 1.4 XRP   | 1.8 XRP      | 2.6 XRP    |
+| 1000        | 6.4 XRP   | 8.4 XRP      | 12.6 XRP   |
+
+<!-- RESERVES_REMINDER: update math if reserves change -->

 ## `NFTokenOffer`の準備金

@@ -46,11 +48,10 @@ NFTをミントし、保有し、売買のオファーをする場合、必要

 | 準備金の種類          | 準備金の額 |
 |:--------------------|--------:|
-| 基本                 | 10 XRP  |
-| NFTokenページ        | 2 XRP   |
-| NFTokenオファー       | 2 XRP   |
-| 合計                 | 14 XRP  |
-|                     |         |
+| 基本                 | {% $env.PUBLIC_BASE_RESERVE %} |
+| NFTokenページ        | {% $env.PUBLIC_OWNER_RESERVE %} |
+| NFTokenオファー       | {% $env.PUBLIC_OWNER_RESERVE % |
+| 合計                 | 1.4 XRP |

 {% admonition type="info" name="注記" %}準備金要件ではありませんが、ミントと売却のプロセスにおけるトランザクションの些細な手数料（通常12drops、または.000012XRP）を負担するために、少なくとも必要準備金より1XRPより多く用意しておきくべきです。{% /admonition %}

@@ -58,10 +59,9 @@ NFTをミントし、保有し、売買のオファーをする場合、必要

 | 準備金の種類          | 準備金の額 |
 |:--------------------|--------:|
-| 基本                 | 10 XRP  |
-| NFTokenページ        | 26 XRP  |
-| NFTokenオファー      | 400 XRP |
-| 合計                 | 436 XRP |
-|                     |         |
+| 基本                 | {% $env.PUBLIC_BASE_RESERVE %}  |
+| NFTokenページ        | 2.6 XRP |
+| NFTokenオファー      | 40 XRP |
+| 合計                 | 43.6 XRP |

 必要準備金の額が余裕を持って確保できる額を超える場合は、オンデマンドミントモデルを使用して、一度に保有するNFTとオファーの数を減らすことを検討してください。[オンデマンドMint](batch-minting.md#オンデマンドmint-遅延minting)をご覧ください。
--- a/@l10n/ja/docs/concepts/transactions/transaction-queue.md
+++ b/@l10n/ja/docs/concepts/transactions/transaction-queue.md
@@ -40,7 +40,7 @@ labels:
 - `AccountTxnID`フィールドが指定されているトランザクションはキューに入れることができません。
 - 1つの送信側アドレスには、同時に最大10個のトランザクションを入れることができます。
 - トランザクションをキューに入れるには、送信者が以下のすべてを行うのに十分なXRPを保有している必要があります。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}更新: rippled 1.2.0{% /badge %}
-    - キュー内のすべての送信者のトランザクションの`Fee`フィールドに指定されているXRP[トランザクションコスト](transaction-cost.md)の消却。キュー内のトランザクションの合計額は、アカウントの基本準備金（現時点では10 XRP）を超えることはできません。（トランザクションコストの支払いが最小額の0.00001 XRPを大幅に上回るトランザクションは、キューをスキップし、オープンレジャーに直接追加されます。）
+    - キュー内のすべての送信者のトランザクションの`Fee`フィールドに指定されているXRP[トランザクションコスト](transaction-cost.md)の消却。キュー内のトランザクションの合計額は、アカウントの基本準備金（現時点では{% $env.PUBLIC_BASE_RESERVE %}）を超えることはできません。（トランザクションコストの支払いが最小額の0.00001 XRPを大幅に上回るトランザクションは、キューをスキップし、オープンレジャーに直接追加されます。）
    - キュー内のすべての送信者のトランザクションの送金を可能とするXRPの最大合計額の送信。
    - アカウントの[必要準備金](../accounts/reserves.md)を確保するのに十分なXRPの保有。
 - あるトランザクションが、送信側アドレスがトランザクションを承認する方法に影響する場合、同じアドレスからの他のトランザクションをそのトランザクションの後にキューに入れることはできません。{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.32.0" %}新規: rippled 0.32.0{% /badge %}
--- a/@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
+++ b/@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
@@ -96,10 +96,12 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました)_

 | 所有NFTの数  |  最良のケース | 一般 | 最悪のケース |
 |:------------|:----------|:--------|:-----------|
-| 32以下       | 2 XRP     | 2 XRP   | 2 XRP      |
-| 50          | 4 XRP     | 6 XRP   | 8 XRP      |
-| 200         | 14 XRP    | 18 XRP  | 26 XRP     |
-| 1000        | 64 XRP    | 84 XRP  | 126 XRP    |
+| 32以下       | 0.2 XRP   | 0.2 XRP | 0.2 XRP    |
+| 50          | 0.4 XRP   | 0.6 XRP | 0.8 XRP    |
+| 200         | 1.4 XRP   | 1.8 XRP | 2.6 XRP    |
+| 1000        | 6.4 XRP   | 8.4 XRP | 12.6 XRP   |
+
+<!-- RESERVES_REMINDER: update math if reserves change -->

 これらの数字は推定であり、実際の数字とは異なる場合があります。

--- a/@l10n/ja/docs/references/protocol/transactions/types/accountdelete.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/accountdelete.md
@@ -8,7 +8,7 @@ labels:
 ---
 # AccountDelete

-[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/tx/impl/DeleteAccount.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DeleteAccount.cpp "Source")

 _[DeletableAccounts Amendment](/resources/known-amendments.md#deletableaccounts)が必要です_

--- a/@l10n/ja/docs/references/protocol/transactions/types/ammbid.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/ammbid.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMBid
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMBid.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMBid.cpp "Source")

 _([AMM amendment][]により追加されました。)_

--- a/@l10n/ja/docs/references/protocol/transactions/types/ammcreate.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/ammcreate.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMCreate
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMCreate.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMCreate.cpp "Source")

 _([AMM amendment][]により追加されました。)_

--- a/@l10n/ja/docs/references/protocol/transactions/types/ammdelete.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/ammdelete.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMDelete
-[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/tx/impl/AMMDelete.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMDelete.cpp "Source")

 _([AMM amendment][]により追加されました。)_

--- a/@l10n/ja/docs/references/protocol/transactions/types/ammdeposit.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/ammdeposit.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMDeposit
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMDeposit.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMDeposit.cpp "Source")

 _([AMM amendment][]により追加されました。)_

--- a/@l10n/ja/docs/references/protocol/transactions/types/ammvote.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/ammvote.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMVote
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMVote.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMVote.cpp "Source")

 _([AMM amendment][]により追加されました。)_

--- a/@l10n/ja/docs/references/protocol/transactions/types/ammwithdraw.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/ammwithdraw.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMWithdraw
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMWithdraw.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMWithdraw.cpp "Source")

 _([AMM amendment][]により追加されました。)_

--- a/@l10n/ja/docs/references/protocol/transactions/types/checkcancel.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/checkcancel.md
@@ -7,7 +7,7 @@ labels:
  - Checks
 ---
 # CheckCancel
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CancelCheck.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CancelCheck.cpp "Source")

 _（[Checks Amendment][]が必要です）_

--- a/@l10n/ja/docs/references/protocol/transactions/types/checkcash.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/checkcash.md
@@ -7,7 +7,7 @@ labels:
  - Checks
 ---
 # CheckCash
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CashCheck.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CashCheck.cpp "Source")

 _（[Checks Amendment][]が必要です）_

--- a/@l10n/ja/docs/references/protocol/transactions/types/checkcreate.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/checkcreate.md
@@ -7,7 +7,7 @@ labels:
  - Checks
 ---
 # CheckCreate
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CreateCheck.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CreateCheck.cpp "Source")

 _（[Checks Amendment][]が必要です）_

--- a/@l10n/ja/docs/references/protocol/transactions/types/clawback.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/clawback.md
@@ -8,7 +8,7 @@ labels:
 ---
 # Clawback

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Clawback.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Clawback.cpp "ソース")

 {% partial file="/@l10n/ja/docs/_snippets/clawback-disclaimer.md" /%}

--- a/@l10n/ja/docs/references/protocol/transactions/types/depositpreauth.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/depositpreauth.md
@@ -7,7 +7,7 @@ labels:
  - セキュリティ
 ---
 # DepositPreauth
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/DepositPreauth.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DepositPreauth.cpp "Source")

 _[DepositPreauth Amendment][]により追加されました。_

--- a/@l10n/ja/docs/references/protocol/transactions/types/diddelete.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/diddelete.md
@@ -8,7 +8,7 @@ labels:
 ---
 # DIDDelete

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/DID.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DID.cpp "ソース")

 _([DID Amendment][])_

--- a/@l10n/ja/docs/references/protocol/transactions/types/didset.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/didset.md
@@ -8,7 +8,7 @@ labels:
 ---
 # DIDSet

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/DID.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DID.cpp "ソース")

 _([DID Amendment][])_

--- a/@l10n/ja/docs/references/protocol/transactions/types/escrowcancel.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/escrowcancel.md
@@ -8,7 +8,7 @@ labels:
 ---
 # EscrowCancel

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Escrow.cpp "Source")

 _[Escrow Amendment][]により追加されました。_

--- a/@l10n/ja/docs/references/protocol/transactions/types/escrowcreate.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/escrowcreate.md
@@ -8,7 +8,7 @@ labels:
 ---
 # EscrowCreate

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Escrow.cpp "Source")

 _[Escrow Amendment][]により追加されました。_

--- a/@l10n/ja/docs/references/protocol/transactions/types/escrowfinish.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/escrowfinish.md
@@ -8,7 +8,7 @@ labels:
 ---
 # EscrowFinish

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Escrow.cpp "Source")

 _[Escrow Amendment][]により追加されました。_

--- a/@l10n/ja/docs/references/protocol/transactions/types/nftokenacceptoffer.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/nftokenacceptoffer.md
@@ -7,7 +7,7 @@ labels:
  - NFT, 非代替性トークン
 ---
 # NFTokenAcceptOffer
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenAcceptOffer.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp "ソース")

 `NFTokenAcceptOffer`トランザクションは`NFToken`の購入または売却のオファーを受け入れるために使用されます。トランザクションは次のいずれかになります。

--- a/@l10n/ja/docs/references/protocol/transactions/types/nftokencreateoffer.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/nftokencreateoffer.md
@@ -7,7 +7,7 @@ labels:
  - 非代替性トークン, NFT
 ---
 # NFTokenCreateOffer
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenCreateOffer.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenCreateOffer.cpp "ソース")

 トランザクションを送信するアカウントが所有する`NFToken`に対する新しい _売却_ オファー、または別のアカウントが所有する`NFToken`に対する新しい _購入_ オファーを作成します。

--- a/@l10n/ja/docs/references/protocol/transactions/types/nftokenmint.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/nftokenmint.md
@@ -7,7 +7,7 @@ labels:
  - 非代替性トークン, NFT
 ---
 # NFTokenMint
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenMint.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenMint.cpp "Source")

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

@@ -117,4 +117,4 @@ NFTokenMint型のトランザクションでは、以下のように[`Flags`フ
 | `tecINSUFFICIENT_RESERVE`     | トークンを発行した後、オーナーは更新された[準備金要件](../../../../concepts/accounts/reserves.md)を満たせなくなります。新しい`NFToken`は、新しい[NFTokenPageオブジェクト][]を必要とする場合にのみ、オーナーの準備金を増加させることに注意する必要があり、それぞれ最大32NFTを格納することができます。|
 | `tecMAX_SEQUENCE_REACHED`     | `Issuer`の`MintedNFTokens`フィールドはすでに最大値になっています。これは、発行者またはその代理人が合計で2<sup>32</sup>-1つの`NFToken`を発行した場合にのみ発生します。 |

-{% raw-partial file="/docs/_snippets/common-links.md" /%}
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/@l10n/ja/docs/references/protocol/transactions/types/offercancel.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/offercancel.md
@@ -8,7 +8,7 @@ labels:
 ---
 # OfferCancel

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CancelOffer.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CancelOffer.cpp "Source")

 OfferCancelトランザクションは、XRP LedgerからOfferオブジェクトを削除します。

--- a/@l10n/ja/docs/references/protocol/transactions/types/offercreate.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/offercreate.md
@@ -8,7 +8,7 @@ labels:
 ---
 # OfferCreate

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CreateOffer.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CreateOffer.cpp "ソース")

 OfferCreateトランザクションは[分散型取引所](../../../../concepts/tokens/decentralized-exchange/index.md)で[注文](../../../../concepts/tokens/decentralized-exchange/offers.md)を作成します。

--- a/@l10n/ja/docs/references/protocol/transactions/types/oracledelete.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/oracledelete.md
@@ -8,7 +8,7 @@ labels:
 # OracleDelete
 _([PriceOracle Amendment][])_

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/DeleteOracle.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DeleteOracle.cpp "ソース")

 既存の`Oracle`レジャーエントリを削除します。

--- a/@l10n/ja/docs/references/protocol/transactions/types/oracleset.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/oracleset.md
@@ -8,7 +8,7 @@ labels:
 # OracleSet
 _([PriceOracle Amendment][])_

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/SetOracle.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/SetOracle.cpp "ソース")

 Oracle Document ID を使用して、新しい`Oracle`レジャーエントリを作成するか、既存のフィールドを更新します。

--- a/@l10n/ja/docs/references/protocol/transactions/types/paymentchannelclaim.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/paymentchannelclaim.md
@@ -7,7 +7,7 @@ labels:
  - Payment Channel
 ---
 # PaymentChannelClaim
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/PayChan.cpp "Source")

 _[PayChan Amendment][]により追加されました。_

--- a/@l10n/ja/docs/references/protocol/transactions/types/paymentchannelcreate.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/paymentchannelcreate.md
@@ -7,7 +7,7 @@ labels:
  - Payment Channel
 ---
 # PaymentChannelCreate
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp "ソース")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/PayChan.cpp "ソース")

 _[PayChan Amendment][]により追加されました。_

--- a/@l10n/ja/docs/references/protocol/transactions/types/paymentchannelfund.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/paymentchannelfund.md
@@ -7,7 +7,7 @@ labels:
  - Payment Channel
 ---
 # PaymentChannelFund
-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/PayChan.cpp "Source")

 _[PayChan Amendment][]により追加されました。_

--- a/@l10n/ja/docs/references/protocol/transactions/types/ticketcreate.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/ticketcreate.md
@@ -8,7 +8,7 @@ labels:
 ---
 # TicketCreate

-[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/tx/impl/CreateTicket.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CreateTicket.cpp "Source")

 _([TicketBatch amendment][]が必要です)_

--- a/@l10n/ja/docs/references/protocol/transactions/types/trustset.md
+++ b/@l10n/ja/docs/references/protocol/transactions/types/trustset.md
@@ -8,7 +8,7 @@ labels:
 ---
 # TrustSet

-[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/SetTrust.cpp "Source")
+[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/SetTrust.cpp "Source")

 2つのアカウントをリンクする[トラストライン](../../../../concepts/tokens/fungible-tokens/index.md)を作成または変更します。

--- a/@l10n/ja/docs/use-cases/tokenization/nft-mkt-overview.md
+++ b/@l10n/ja/docs/use-cases/tokenization/nft-mkt-overview.md
@@ -77,7 +77,7 @@ NFTokenのURLは、NFTのコンテンツが保存されている場所へのリ

 新しいウォレットをセットアップします。[Xaman](https://xaman.app/)をご覧ください。

-アカウントを作成する際には、10 XRPの基本準備金が必要であることに注意してください。[準備金](../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve)をご覧ください。
+アカウントを作成する際には、{% $env.PUBLIC_BASE_RESERVE %}の基本準備金が必要であることに注意してください。[準備金](../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve)をご覧ください。

 ### NFTの取引

--- a/@l10n/ja/resources/contribute-code/create-custom-transactors.md
+++ b/@l10n/ja/resources/contribute-code/create-custom-transactors.md
@@ -21,8 +21,8 @@ _トランザクタ_ はトランザクションを処理し、XRP Ledgerを変

 このチュートリアルでは、既存の`CreateCheck`トランザクションを例として使用します。ソースファイルはここで確認できます。

- [ヘッダファイル](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CreateCheck.h)
- [CPPファイル](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CreateCheck.cpp)
+- [ヘッダファイル](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CreateCheck.h)
+- [CPPファイル](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CreateCheck.cpp)


 ## ヘッダファイル
--- a/@theme/components/Navbar/AlgoliaSearch.tsx
+++ b/@theme/components/Navbar/AlgoliaSearch.tsx
@@ -0,0 +1,17 @@
+import { DocSearch } from '@docsearch/react';
+import { useThemeHooks } from '@redocly/theme/core/hooks';
+
+export function AlgoliaSearch() {
+    const { useL10n } = useThemeHooks()
+    let { lang } = useL10n()
+    return (
+            <DocSearch
+                appId="R39QY3MZC7"
+                indexName="xrpl"
+                apiKey="3431349deec23b0bc3dcd3424beb9a6e"
+                searchParameters={{
+                    facetFilters: ['lang:'+lang],
+                }}
+            />
+    )
+}
--- a/@theme/components/Navbar/Navbar.tsx
+++ b/@theme/components/Navbar/Navbar.tsx
@@ -5,7 +5,7 @@ import { LanguagePicker } from "@redocly/theme/components/LanguagePicker/Languag
 import { slugify } from "../../helpers";
 import { Link } from "@redocly/theme/components/Link/Link";
 import { ColorModeSwitcher } from "@redocly/theme/components/ColorModeSwitcher/ColorModeSwitcher";
-import { Search } from "@redocly/theme/components/Search/Search";
+import { AlgoliaSearch } from "./AlgoliaSearch";

 // @ts-ignore

@@ -101,7 +101,7 @@ export function Navbar(props) {
          <NavItems>
            {navItems}
            <div id="topnav-search" className="nav-item search">
-              <Search className="topnav-search" />
+              <AlgoliaSearch />
            </div>
            <div id="topnav-language" className="nav-item">
              <LanguagePicker
--- a/_api-examples/ledger_index/jsonrpc-response.json
+++ b/_api-examples/ledger_index/jsonrpc-response.json
@@ -0,0 +1,15 @@
+{
+  "result": {
+    "ledger_index": 3679660,
+    "ledger_hash": "346C9211428A102081A3BFFCCBE1F698E7E56163BBD1DF81B446418B3213DBD7",
+    "closed": "2024-08-28T23:00:00Z",
+    "validated": true,
+    "status": "success"
+  },
+  "warnings": [
+    {
+      "id": 2001,
+      "message": "This is a clio server. clio only serves validated data. If you want to talk to rippled, include 'ledger_index':'current' in your request"
+    }
+  ]
+}
--- a/_api-examples/ledger_index/ws-response.json
+++ b/_api-examples/ledger_index/ws-response.json
@@ -0,0 +1,17 @@
+{
+  "result": {
+    "ledger_index": 3679660,
+    "ledger_hash": "346C9211428A102081A3BFFCCBE1F698E7E56163BBD1DF81B446418B3213DBD7",
+    "closed": "2024-08-28T23:00:00Z",
+    "validated": true
+  },
+  "id": "example_ledger_index",
+  "status": "success",
+  "type": "response",
+  "warnings": [
+    {
+      "id": 2001,
+      "message": "This is a clio server. clio only serves validated data. If you want to talk to rippled, include 'ledger_index':'current' in your request"
+    }
+    ]
+}
--- a/blog/2024/lower-reserves-are-in-effect.md
+++ b/blog/2024/lower-reserves-are-in-effect.md
@@ -0,0 +1,37 @@
+---
+category: 2024
+markdown:
+    editPage:
+        hide: true
+date: 2024-12-12
+labels:
+    - Advisories
+---
+# Lower Reserves Are In Effect
+
+On 2024-12-02, the reserve requirements for using the XRP Ledger blockchain changed by the collective voting of the validators. The new requirements are **1 XRP** base reserve per account (down from 10 XRP), and **0.2 XRP** owner reserve increment per item (down from 2 XRP).
+
+The base cost of sending a transaction (10 drops) remains unchanged.
+
+## Background
+
+The XRP Ledger has [reserves](../../docs/concepts/accounts/reserves.md) and a [transaction cost](../../docs/concepts/transactions/transaction-cost.md) to protect the network from spam. The protocol includes a [fee voting](../../docs/concepts/consensus-protocol/fee-voting.md) process for changing both the reserves and transaction cost, to adjust for external factors like the price of XRP and the costs of operating a network node.
+
+Validators in the decentralized network can configure their fee voting preferences. They need to balance competing priorities of having lower fees to reduce the barrier to entry, but higher fees to protect against overly frivolous or disruptive usage. The network collectively decides on fees based on the votes of trusted validators, with each node advocating for the median of votes from validators it trusts.
+
+The last time fees changed was [in 2021, when reserves dropped from 20 base and 5 per item to 10 base and 2 per item](../2021/reserves-lowered.md).
+
+## Action Recommended
+
+### FeeSettings Format
+
+Due to the [XRPFees amendment](../../resources/known-amendments.md#xrpfees), the format of the `FeeSettings` ledger entry changed when the new reserve settings went into effect. If you have code that reads the `FeeSettings` ledger entry directly, make sure your code is capable of reading the new format.
+
+Code that uses the `fee`, `server_info`, or `server_state` API methods should continue to work as before.
+
+### Fee Volatility
+
+Currently, votes among recommended validators on Mainnet are divided among a few different preferred settings for reserves and the transaction cost. While the numbers are close to 50% one way or another, a validator temporarily going offline could cause the median vote to move, causing the fee settings to change again temporarily; validators changing their votes could also cause further fee movements in the near future. To be prepared for any future possible movements in both the reserve requirements and transaction cost, you should:
+
+- Instead of hard-coding reserve requirements or transaction costs, look up the necessary settings using the [`fee` API method](../../docs/references/http-websocket-apis/public-api-methods/server-info-methods/fee.md).
+- Consider holding more XRP than the minimum, so that your account still meets the requirements if reserves go back up.
--- a/blog/sidebars.yaml
+++ b/blog/sidebars.yaml
@@ -6,7 +6,8 @@
    - group: '2024'
      expanded: false
      items:
-        - page: 2024/a-new-era-for-the-xrp-ledger.md      
+        - page: 2024/lower-reserves-are-in-effect.md
+        - page: 2024/a-new-era-for-the-xrp-ledger.md
        - page: 2024/rippled-2.3.0.md
        - page: 2024/rippled-2.2.3.md
        - page: 2024/rippled-2.2.2.md
--- a/docs/_snippets/common-links.md
+++ b/docs/_snippets/common-links.md
@@ -116,6 +116,11 @@
 [DepositPreauthエントリ]: /docs/references/protocol/transactions/types/depositpreauth.md
 [DepositPreauthオブジェクト]: /docs/references/protocol/transactions/types/depositpreauth.md
 [DepositPreauthトランザクション]: /docs/references/protocol/transactions/types/depositpreauth.md
+[DIDSet transaction]: /docs/references/protocol/transactions/types/didset.md
+[DIDSet transactions]: /docs/references/protocol/transactions/types/didset.md
+[DIDSet トランザクション]: /docs/references/protocol/transactions/types/didset.md
+[DIDSet]: /docs/references/protocol/transactions/types/didset.md
+[DIDSetトランザクション]: /docs/references/protocol/transactions/types/didset.md
 [DirectoryNode entry]: /docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
 [DirectoryNode object]: /docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
 [DirectoryNode エントリ]: /docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
@@ -367,8 +372,23 @@
 [UNLModify pseudo-transactions]: /docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
 [UNLModify]: /docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
 [UNLModify疑似トランザクション]: /docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
+[XChainAddAccountCreateAttestation transaction]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
+[XChainAddAccountCreateAttestation transactions]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
+[XChainAddAccountCreateAttestation トランザクション]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
+[XChainAddAccountCreateAttestation]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
+[XChainAddAccountCreateAttestationトランザクション]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
 [XChainBridge amendment]: /resources/known-amendments.md#xchainbridge
 [XChainBridgeの修正]: /resources/known-amendments.md#xchainbridge
+[XChainCreateBridge transaction]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
+[XChainCreateBridge transactions]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
+[XChainCreateBridge トランザクション]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
+[XChainCreateBridge]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
+[XChainCreateBridgeトランザクション]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
+[XChainCreateClaimID transaction]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
+[XChainCreateClaimID transactions]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
+[XChainCreateClaimID トランザクション]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
+[XChainCreateClaimID]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
+[XChainCreateClaimIDトランザクション]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
 [XRP, in drops]: /docs/references/protocol/data-types/basic-data-types.md#specifying-currency-amounts
 [XRPFees amendment]: /resources/known-amendments.md#xrpfees
 [XRPFeesの修正]: /resources/known-amendments.md#xrpfees
--- a/docs/concepts/accounts/deleting-accounts.md
+++ b/docs/concepts/accounts/deleting-accounts.md
@@ -25,13 +25,13 @@ To be deleted, an account must meet the following requirements:
    - `RippleState`
    - `Check`
 - The account must own fewer than 1000 objects in the ledger.
- The transaction must pay a special [transaction cost][] equal to at least the [owner reserve](reserves.md) for one item (currently 2 XRP).
+- The transaction must pay a special [transaction cost][] equal to at least the [owner reserve](reserves.md) for one item (currently {% $env.PUBLIC_OWNER_RESERVE %}).

 ## Cost of Deleting

 {% admonition type="danger" name="Warning" %}The [AccountDelete transaction][]'s transaction cost always applies when the transaction is included in a validated ledger, even if the transaction failed because the account does not meet the requirements to be deleted. To greatly reduce the chances of paying the high transaction cost if the account cannot be deleted, use the `fail_hard` option when submitting an AccountDelete transaction.{% /admonition %}

-Unlike Bitcoin and many other cryptocurrencies, each new version of the XRP Ledger's public ledger chain contains the full state of the ledger, which increases in size with each new account. For that reason, you should not create new XRP Ledger accounts unless necessary. You can recover some of an account's 10 XRP [reserve](reserves.md) by deleting the account, but you must still destroy at least 2 XRP to do so.
+Unlike Bitcoin and many other cryptocurrencies, each new version of the XRP Ledger's public ledger chain contains the full state of the ledger, which increases in size with each new account. For that reason, you should not create new XRP Ledger accounts unless necessary. You can recover some of an account's {% $env.PUBLIC_BASE_RESERVE %} [reserve](reserves.md) by deleting the account, but you must still destroy at least {% $env.PUBLIC_OWNER_RESERVE %} to do so.

 Institutions who send and receive value on behalf of many users can use [**Source Tags** and **Destination Tags**](../transactions/source-and-destination-tags.md) to distinguish payments from and to their customers while only using one (or a handful) of accounts in the XRP Ledger.

--- a/docs/concepts/accounts/depositauth.md
+++ b/docs/concepts/accounts/depositauth.md
@@ -42,7 +42,7 @@ An account with Deposit Authorization enabled:

 - **Cannot** be the destination of [Payment transactions][], with **the following exceptions**:
    - If the destination has [preauthorized](#preauthorization) the sender of the Payment. _(Added by the [DepositPreauth amendment][])_
-    - If the account's XRP balance is equal to or below the minimum account [reserve requirement](reserves.md), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 10 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
+    - If the account's XRP balance is equal to or below the minimum account [reserve requirement](reserves.md), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently {% $env.PUBLIC_BASE_RESERVE %}). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
 - Can receive XRP from [PaymentChannelClaim transactions][] **only in the following cases**:
    - The sender of the PaymentChannelClaim transaction is the destination of the payment channel.
    - The destination of the PaymentChannelClaim transaction has [preauthorized](#preauthorization) the sender of the PaymentChannelClaim. _(Added by the [DepositPreauth amendment][])_
--- a/docs/concepts/accounts/index.md
+++ b/docs/concepts/accounts/index.md
@@ -46,7 +46,7 @@ The typical way to get an account in the XRP Ledger is as follows:

    - For example, you can buy XRP in a private exchange, then withdraw XRP from the exchange to the address you specified.

-        {% admonition type="warning" name="Caution" %}The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](reserves.md) (currently 10 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price.{% /admonition %}
+        {% admonition type="warning" name="Caution" %}The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](reserves.md) (currently {% $env.PUBLIC_BASE_RESERVE %}), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price.{% /admonition %}



--- a/docs/concepts/accounts/reserves.md
+++ b/docs/concepts/accounts/reserves.md
@@ -27,12 +27,12 @@ The reserve requirement has two parts:

 The current reserve requirements on Mainnet are:

- Base reserve: **10 XRP**
- Owner reserve: **2 XRP** per item
+- Base reserve: **{% $env.PUBLIC_BASE_RESERVE %}**
+- Owner reserve: **{% $env.PUBLIC_OWNER_RESERVE %}** per item

 Reserves on other networks may vary.

-An exception to the owner reserve is that you can create your first two trust lines on the XRPL without the required reserves of 2 XRP per trust line. Create your new account with the 10 XRP base reserve, then create your 2 trust lines and the reserves are not required. If you fund your account with more than 10 XRP, your account will be charged the normal reserve fees for your first two trust lines.
+An exception to the owner reserve is that you can create your first two trust lines on the XRPL with just the base reserve. Create your new account with the {% $env.PUBLIC_BASE_RESERVE %} base reserve, then you can create your 2 trust lines and the reserves are not required. If you fund your account with more than {% $env.PUBLIC_BASE_RESERVE %}, your account will be charged the normal reserve fees for your first two trust lines.

 ## Owner Reserves

--- a/docs/concepts/accounts/tickets.md
+++ b/docs/concepts/accounts/tickets.md
@@ -40,7 +40,7 @@ Later, you can send a transaction using a specific Ticket instead of a sequence

 Continuing the above example, you can send a transaction using sequence number 105 or any of the three Tickets you created. If you send a transaction using Ticket 103, doing so deletes Ticket 103 from the ledger. Your next transaction after that can use sequence number 105, Ticket 102, or Ticket 104.

-{% admonition type="warning" name="Caution" %}Each Ticket counts as a separate item for the [owner reserve](reserves.md), so you must set aside 2 XRP for each Ticket. (The XRP becomes available again after you use the Ticket.) This cost can add up quickly if you create a large number of Tickets at once.{% /admonition %}
+{% admonition type="warning" name="Caution" %}Each Ticket counts as a separate item for the [owner reserve](reserves.md), so you must set aside {% $env.PUBLIC_OWNER_RESERVE %} for each Ticket. (The XRP becomes available again after you use the Ticket.) This cost can add up quickly if you create a large number of Tickets at once.{% /admonition %}

 As with sequence numbers, sending a transaction uses up the Ticket _if and only if_ the transaction is confirmed by [consensus](../consensus-protocol/index.md). However, transactions that fail to do what they were intended to do can still be confirmed by consensus with [`tec`-class result codes](../../references/protocol/transactions/transaction-results/tec-codes.md).

@@ -53,7 +53,7 @@ Any account can create and use Tickets on any type of transaction. However, some
 - Each Ticket can only be used once. It is possible to have multiple different candidate transactions that would use the same Ticket Sequence, but only one of those candidates can be validated by consensus.
 - Each account cannot have more than 250 Tickets in the ledger at a time. You cannot create more than 250 Tickets at a time, either.
 - You _can_ use a Ticket to create more Tickets. If you do, the Ticket you used does not count towards the total number of Tickets you can have at once.
- Each Ticket counts toward the [owner reserve](reserves.md), so you must set aside 2 XRP for each Ticket you have not used yet. The XRP becomes available for you to use again after the Ticket is used.
+- Each Ticket counts toward the [owner reserve](reserves.md), so you must set aside {% $env.PUBLIC_OWNER_RESERVE %} for each Ticket you have not used yet. The XRP becomes available for you to use again after the Ticket is used.
 - Within an individual ledger, transactions that use Tickets execute after other transactions from the same sender. If an account has multiple transactions using Tickets in the same ledger version, those Tickets execute in order from lowest Ticket Sequence to highest. (For more information, see the documentation on consensus's [canonical order](../consensus-protocol/consensus-structure.md#calculate-and-share-validations).)
 - To "cancel" a Ticket, use the Ticket to [perform a no-op](../transactions/finality-of-results/canceling-a-transaction.md) [AccountSet transaction][]. This deletes the Ticket so that you don't have to meet its reserve requirement.

--- a/docs/concepts/consensus-protocol/fee-voting.md
+++ b/docs/concepts/consensus-protocol/fee-voting.md
@@ -18,8 +18,10 @@ The parameters you can set are as follows:
 | Parameter | Description | Recommended Value |
 |-----------|-------------|-------------------|
 | `reference_fee` | The **reference transaction cost.** This is the amount of XRP, in _drops_ (1 XRP = 1 million drops.), that must be destroyed to send the reference transaction, the cheapest possible transaction. The actual transaction cost is a multiple of this value, scaled dynamically based on the load of individual servers. | `10` (0.00001 XRP) |
-| `account_reserve` | The **base account reserve.** This is the minimum amount of XRP, in _drops_, that an account must hold in reserve, which is also the minimum requirement to fund a new account. | `10000000` (10 XRP) |
-| `owner_reserve` | The **owner reserve increment.** This is how much more XRP, in _drops_, that an account must hold for _each_ object it owns in the ledger. | `2000000` (2 XRP) |
+| `account_reserve` | The **base account reserve.** This is the minimum amount of XRP, in _drops_, that an account must hold in reserve, which is also the minimum requirement to fund a new account. | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
+| `owner_reserve` | The **owner reserve increment.** This is how much more XRP, in _drops_, that an account must hold for _each_ object it owns in the ledger. | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |
+
+<!-- RESERVES_REMINDER: update recommendations in drops if reserves change -->

 ## Precautions

--- a/docs/concepts/tokens/fungible-tokens/authorized-trust-lines.md
+++ b/docs/concepts/tokens/fungible-tokens/authorized-trust-lines.md
@@ -21,7 +21,7 @@ The transaction to authorize a trust line must be signed by the issuing address,

 ## Reserves

-Trust lines are ledger objects that require a reserve of 2 XRP each. To help new users get started, the reserve amounts are waived for the first 2 trust lines you create for a new account. Fund your new account with 10 XRP and create your new trust lines. If you have more than 10 XRP in your account, up to 4 XRP are reserved for your first 2 trust lines. If you remove the trust line later, the reserves are freed up for future use.
+Trust lines are ledger objects that require a reserve of {% $env.PUBLIC_OWNER_RESERVE %} each. To help new users get started, the reserve amounts are waived for the first 2 trust lines you create for a new account. Fund your new account with {% $env.PUBLIC_BASE_RESERVE %} and create your new trust lines. If you have more than {% $env.PUBLIC_BASE_RESERVE %} in your account, up to 0.4 XRP are reserved for your first 2 trust lines. If you remove the trust line later, the reserves are freed up for future use.

 ## With Stablecoin Issuing

--- a/docs/concepts/tokens/fungible-tokens/index.md
+++ b/docs/concepts/tokens/fungible-tokens/index.md
@@ -16,7 +16,7 @@ Fungible tokens are interchangeable and indistinguishable from one another. They

 Trust lines are structures in the XRP Ledger for holding fungible [tokens](../index.md). 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](../index.md#community-credit) among other benefits.

-Each "trust line" is a _bidirectional_ relationship consisting of:
+A trust line is defined as a [RippleState](../../references/protocol/ledger-data/ledger-entry-types/ripplestate) object. Each trust line is a _bidirectional_ relationship consisting of:

 - The identifiers for the two [accounts](../../accounts/index.md) that the trust line connects.
 - A single, shared balance, which is positive from the perspective of one account and negative from the other perspective.
--- a/docs/concepts/tokens/nfts/reserve-requirements.md
+++ b/docs/concepts/tokens/nfts/reserve-requirements.md
@@ -12,11 +12,11 @@ Minting, holding, and offering NFTs for sale require XRP held in reserve. The re

 ## Base Reserve

-Your account must set aside a base reserve, currently 10 XRP. The base reserve XRP amount is subject to change. See [Base Reserve and Owner Reserve](../../accounts/reserves.md#base-reserve-and-owner-reserve).
+Your account must set aside a base reserve, currently {% $env.PUBLIC_BASE_RESERVE %}. The base reserve XRP amount is subject to change. See [Base Reserve and Owner Reserve](../../accounts/reserves.md#base-reserve-and-owner-reserve).

 ## Owner Reserve

-For each object you own on the XRP Ledger, there is an owner reserve, currently 2 XRP. This is to discourage users from spamming the ledger with unnecessary data, and to encourage them to clean up any data that is no longer necessary. The owner reserve amount is subject to change. See [Base Reserve and Owner Reserve](../../accounts/reserves.md#base-reserve-and-owner-reserve).
+For each object you own on the XRP Ledger, there is an owner reserve, currently 0.2 XRP. This is to discourage users from spamming the ledger with unnecessary data, and to encourage them to clean up any data that is no longer necessary. The owner reserve amount is subject to change. See [Base Reserve and Owner Reserve](../../accounts/reserves.md#base-reserve-and-owner-reserve).

 For NFTs, the _object_ does not refer to the individual NFTs, but to the `NFTokenPage` objects owned by the account. `NFTokenPage` objects can store up to 32 NFTs.

@@ -27,16 +27,18 @@ Therefore, you can estimate the reserve requirements for minting or owning _N_ N

 The following table provides examples of how much the total owner reserve might be, depending on the number of NFTs owned and the number of pages holding them.

-| NFTs Owned    | Best Case    | Typical Case | Worst Case |
+| NFTs Owned  | Best Case | Typical Case | Worst Case |
 |:------------|:----------|:-------------|:-----------|
-| 32 or fewer |    2 XRP        | 2 XRP           | 2 XRP      |
-| 50            | 4 XRP        | 6 XRP           | 8 XRP      |
-| 200            | 14 XRP      | 18 XRP         | 26 XRP     |
-| 1000          | 64 XRP      | 84 XRP         | 126 XRP    |
+| 32 or fewer | 0.2 XRP   | 0.2 XRP      | 0.2 XRP    |
+| 50          | 0.4 XRP   | 0.6 XRP      | 0.8 XRP    |
+| 200         | 1.4 XRP   | 1.8 XRP      | 2.6 XRP    |
+| 1000        | 6.4 XRP   | 8.4 XRP      | 12.6 XRP   |
+
+<!-- RESERVES_REMINDER: update math if reserves change -->

 ## `NFTokenOffer` Reserve

-Each `NFTokenOffer` object costs the account placing the offer one incremental reserve. As of this writing, the incremental reserve is 2 XRP. The reserve can be recovered by cancelling the offer. The reserve is also recovered if the offer is accepted, which removes the offer from the XRP Ledger.
+Each `NFTokenOffer` object costs the account placing the offer one incremental reserve. As of this writing, the incremental reserve is 0.2 XRP. The reserve can be recovered by cancelling the offer. The reserve is also recovered if the offer is accepted, which removes the offer from the XRP Ledger.

 {% admonition type="success" name="Tip" %}After you sell an NFT, as a courtesy, cancel any stale `NFTokenOffer` objects on behalf of your bidders to give them back their reserve. You can do this with [NFTokenCancelOffer](../../../references/protocol/transactions/types/nftokencanceloffer.md) transactions.{% /admonition %}

@@ -44,26 +46,24 @@ Each `NFTokenOffer` object costs the account placing the offer one incremental r

 When minting, holding, and offering to buy and sell NFTs, the reserve requirements can add up quickly. This can result in your account going below the reserve requirement during a transaction. Going below the requirement can limit your ability to trade on the XRPL. See [Going Below the Reserve Requirement](../../accounts/reserves.md#going-below-the-reserve-requirement).

-If you create a new account, mint an NFT, and create an `NFTokenSellOffer` on the XRP Ledger, that requires a minimum reserve of 14 XRP.
+If you create a new account, mint an NFT, and create an `NFTokenSellOffer` on the XRP Ledger, that requires a minimum reserve of 1.4 XRP.

 | Reserve Type        | Amount  |
 |:--------------------|--------:|
-| Base                | 10 XRP  |
-| NFToken Page        | 2 XRP   |
-| NFToken Offers      | 2 XRP   |
-| Total               | 14 XRP  |
-|                     |         |
+| Base                | 1 XRP   |
+| NFToken Page        | 0.2 XRP |
+| NFToken Offers      | 0.2 XRP |
+| Total               | 1.4 XRP |

 {% admonition type="info" name="Note" %}While not a reserve requirement, keep in mind that you would want to have at least 1 XRP above your reserves to cover the trivial fee for each transaction in the mint and sell process (typically 12 drops, or .000012 XRP).{% /admonition %}

-If you were to mint 200 NFTs and create an `NFTokenSellOffer`for each, that would require as much as 436 XRP held in reserve.
+If you were to mint 200 NFTs and create an `NFTokenSellOffer`for each, that would require as much as 43.6 XRP held in reserve.

 | Reserve Type        | Amount  |
 |:--------------------|--------:|
-| Base                | 10 XRP  |
-| NFToken Pages       | 26 XRP  |
-| NFToken Offers      | 400 XRP |
-| Total               | 436 XRP |
-|                     |         |
+| Base                | 1 XRP   |
+| NFToken Pages       | 2.6 XRP |
+| NFToken Offers      | 40 XRP  |
+| Total               | 43.6 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. For details, see [Batch Minting](batch-minting.md).
--- a/docs/concepts/tokens/nfts/trading.md
+++ b/docs/concepts/tokens/nfts/trading.md
@@ -15,7 +15,7 @@ _(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.
+Every `NFTokenOffer` object requires that your account increase its owner reserve, currently {% $env.PUBLIC_OWNER_RESERVE %} per `NFTokenSellOffer` and {% $env.PUBLIC_OWNER_RESERVE %} per `NFTokenBuyOffer`. This is to prevent accounts from spamming the ledger with offers they don't intend to complete.

 See [NFT Reserve Requirements](reserve-requirements.md).

--- a/docs/concepts/transactions/transaction-queue.md
+++ b/docs/concepts/transactions/transaction-queue.md
@@ -40,7 +40,7 @@ The `rippled` server uses a variety of heuristics to estimate which transactions
 - Transactions with an `AccountTxnID` field cannot be queued.
 - A single sending address can have at most 10 transactions queued at the same time.
 - To queue a transaction, the sender must have enough XRP for all of the following:
-    - Destroying the XRP [transaction cost](transaction-cost.md) as specified in the `Fee` fields of all the sender's queued transactions. The total amount among queued transactions cannot be more than the base account reserve (currently 10 XRP). (Transactions paying significantly more than the minimum transaction cost of 0.00001 XRP typically skip the queue and go straight into the open ledger.)
+    - Destroying the XRP [transaction cost](transaction-cost.md) as specified in the `Fee` fields of all the sender's queued transactions. The total amount among queued transactions cannot be more than the base account reserve (currently {% $env.PUBLIC_BASE_RESERVE %}). (Transactions paying significantly more than the minimum transaction cost of 0.00001 XRP typically skip the queue and go straight into the open ledger.)
    - Sending the maximum sum of XRP that all the sender's queued transactions could send.
    - Keeping enough XRP to meet the account's [reserve requirements](../accounts/reserves.md).
 - If a transaction affects how the sending address authorizes transactions, no other transactions from the same address can be queued behind it.
--- a/docs/img/amm-clob-diagram.png
+++ b/docs/img/amm-clob-diagram.png
--- a/docs/references/http-websocket-apis/public-api-methods/clio-methods/index.md
+++ b/docs/references/http-websocket-apis/public-api-methods/clio-methods/index.md
@@ -0,0 +1,9 @@
+---
+metadata:
+  indexPage: true
+---
+# Clio Methods
+
+These API methods are provided only by the Clio server, not `rippled`.
+
+{% child-pages /%}
--- a/docs/references/http-websocket-apis/public-api-methods/clio-methods/ledger_index.md
+++ b/docs/references/http-websocket-apis/public-api-methods/clio-methods/ledger_index.md
@@ -0,0 +1,88 @@
+---
+seo:
+    description: Look up a ledger by its close time.
+labels:
+  - Blockchain
+---
+# ledger_index
+[[Source]](https://github.com/XRPLF/clio/blob/develop/src/rpc/handlers/LedgerIndex.cpp "Source")
+
+The `ledger_index` command looks up information about the last closed ledger at a given real-world time. This may be useful for correlating events that happened off-chain with historical data in the XRP Ledger. {% badge href="https://github.com/XRPLF/clio/releases/tag/2.3.0" date="TBD" %}New in: Clio v2.3.0{% /badge %}
+
+This method is only available from the Clio server, not `rippled`.
+
+## Request Format
+An example of the request format:
+
+{% tabs %}
+
+{% tab label="WebSocket" %}
+```json
+{
+    "id": "example_ledger_index",
+    "command": "ledger_index",
+    "date": "2024-08-28T22:59:00Z"
+}
+```
+{% /tab %}
+
+{% tab label="JSON-RPC" %}
+```json
+{
+    "method": "ledger_index",
+    "params": [
+        {
+            "date": "2024-08-28T22:59:00Z"
+        }
+    ]
+}
+```
+{% /tab %}
+
+{% /tabs %}
+
+[Try it! >](/resources/dev-tools/websocket-api-tool#ledger_index)
+
+The request can contain the following parameters:
+
+| `Field` | Type   | Required? | Description |
+|:--------|:-------|:----------|-------------|
+| `date`  | String | No        | An ISO 8601 timestamp of the time to look up. Must be formatted without microseconds, and using `Z` as the time zone marker. For example, `2024-08-28T22:59:00Z`. If omitted, use the current time. |
+
+## Response Format
+
+An example of a successful response:
+
+{% tabs %}
+
+{% tab label="WebSocket" %}
+{% code-snippet file="/_api-examples/ledger_index/ws-response.json" language="json" /%}
+{% /tab %}
+
+{% tab label="JSON-RPC" %}
+{% code-snippet file="/_api-examples/ledger_index/jsonrpc-response.json" language="json" prefix="200 OK\n\n" /%}
+{% /tab %}
+
+{% /tabs %}
+
+The response follows the [standard format][], with a successful result containing information about the most recently closed ledger at the requested time, including the following fields:
+
+| Field          | Type    | Description                         |
+|:---------------|:--------|:------------------------------------|
+| `ledger_index` | Number  | The [Ledger Index][] of the most recently closed ledger at the specified time. |
+| `ledger_hash`  | String  | The identifying [Hash][] of the most recently closed ledger at the specified time. |
+| `closed`       | String  | The official close time of the most recently closed ledger at the specified time. |
+| `validated`    | Boolean | If `true`, the ledger has been validated by the consensus process and is immutable. Otherwise, the contents of the ledger are not final and may change. |
+
+{% admonition type="info" name="Note" %}
+Due to the rounding on ledger close times, there may be a difference of up to 10 seconds between the "official" close time of a ledger and the real-world clock time when the ledger was closed. For more details, see [Ledger Close Times](../../../../concepts/ledgers/ledger-close-times.md).
+{% /admonition %}
+
+## Possible Errors
+
+* Any of the [universal error types][].
+* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
+    * For example, this can occur if the specified `date` included a microseconds component.
+* `lgrNotFound` - The server does not have ledger history for the specified point in time.
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/docs/references/http-websocket-apis/public-api-methods/clio-server/index.md
+++ b/docs/references/http-websocket-apis/public-api-methods/clio-server/index.md
@@ -1,12 +0,0 @@
---
-html: clio-methods.html
-parent: public-api-methods.html
-metadata:
-  indexPage: true
---
-# Clio Server
-
-Use these methods to retrieve information using Clio server APIs.
-
-
-{% child-pages /%}
--- a/docs/references/http-websocket-apis/public-api-methods/index.md
+++ b/docs/references/http-websocket-apis/public-api-methods/index.md
@@ -93,7 +93,7 @@ Use these methods to retrieve information about the current state of the `ripple
 * **[`server_state`](server-info-methods/server_state.md)** - Retrieve status of the server in machine-readable format.
 - **[`manifest`](server-info-methods/manifest.md)** - Retrieve the latest ephemeral public key information about a known validator.

-## [Clio Methods](clio-server/index.md)
+## [Clio Methods](clio-methods/index.md)

 Use these methods to retrieve information using Clio server APIs.

--- a/docs/references/protocol/ledger-data/ledger-entry-types/accountroot.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/accountroot.md
@@ -1,6 +1,4 @@
 ---
-html: accountroot.html
-parent: ledger-entry-types.html
 seo:
    description: The settings, XRP balance, and other metadata for one account.
 labels:
@@ -8,9 +6,9 @@ labels:
  - XRP
 ---
 # AccountRoot
-[[Source]](https://github.com/XRPLF/rippled/blob/264280edd79b7f764536e02459f33f66a59c0531/src/ripple/protocol/impl/LedgerFormats.cpp#L36-L60 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L136-L158 "Source")

-An `AccountRoot` ledger entry type describes a single [account](../../../../concepts/accounts/index.md), its settings, and XRP balance.
+An `AccountRoot` ledger entry type describes a single [account](../../../../concepts/accounts/index.md), its settings, and XRP balance. You can create a new account by sending a [Payment transaction][] with enough XRP to a mathematically-valid address.

 ## Example {% $frontmatter.seo.title %} JSON

--- a/docs/references/protocol/ledger-data/ledger-entry-types/amendments.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/amendments.md
@@ -1,13 +1,11 @@
 ---
-html: amendments-object.html #amendments.html is taken by the concept page
-parent: ledger-entry-types.html
 seo:
    description: Singleton ledger entry with status of enabled and pending amendments.
 labels:
  - Blockchain
 ---
 # Amendments
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L138-L144 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L187-L192 "Source")

 The `Amendments` ledger entry type contains a list of [Amendments](../../../../concepts/networks-and-servers/amendments.md) that are currently active. Each ledger version contains **at most one** `Amendments` entry.

--- a/docs/references/protocol/ledger-data/ledger-entry-types/amm.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/amm.md
@@ -1,18 +1,16 @@
 ---
-html: amm.html
-parent: ledger-entry-types.html
 seo:
    description: The definition and details of an Automated Market Maker (AMM) instance.
 labels:
  - AMM
 ---
 # AMM
-[[Source]](https://github.com/XRPLF/rippled/blob/89780c8e4fd4d140fcb912cf2d0c01c1b260539e/src/ripple/protocol/impl/LedgerFormats.cpp#L272-L284 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L369-L380 "Source")
+
+An `AMM` ledger entry describes a single [Automated Market Maker](../../../../concepts/tokens/decentralized-exchange/automated-market-makers.md) (AMM) instance. This is always paired with a [special AccountRoot entry](accountroot.md#special-amm-accountroot-entries). You can create an AMM by sending an [AMMCreate transaction][].

 _(Added by the [AMM amendment][])_

-An `AMM` ledger entry describes a single [Automated Market Maker](../../../../concepts/tokens/decentralized-exchange/automated-market-makers.md) (AMM) instance. This is always paired with a [special AccountRoot entry](accountroot.md#special-amm-accountroot-entries).
-

 ## Example AMM JSON

--- a/docs/references/protocol/ledger-data/ledger-entry-types/bridge.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/bridge.md
@@ -1,6 +1,4 @@
 ---
-html: bridge.html
-parent: ledger-entry-types.html
 seo:
    description: A `bridge` object represents a single cross-chain bridge that connects and enables value to move efficiently between two blockchains. 
 labels:
@@ -8,13 +6,12 @@ labels:
 status: not_enabled
 ---
 # Bridge
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L212-L223 "Source")
+
+The `Bridge` ledger entry represents a single cross-chain bridge that connects the XRP Ledger with another blockchain, such as its sidechain, and enables value in the form of XRP and other tokens (IOUs) to move efficiently between the two blockchains. You can create a bridge by sending an [XChainCreateBridge transaction][].
+
 _(Requires the [XChainBridge amendment][] {% not-enabled /%})_

-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L286-L300 "Source")
-
-The `Bridge` ledger entry represents a single cross-chain bridge that connects the XRP Ledger with another blockchain, such as its sidechain, and enables value in the form of XRP and other tokens (IOUs) to move efficiently between the two blockchains.
-
-
 ## Example Bridge JSON

 ```json
--- a/docs/references/protocol/ledger-data/ledger-entry-types/check.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/check.md
@@ -1,18 +1,16 @@
 ---
-html: check.html
-parent: ledger-entry-types.html
 seo:
    description: A check that can be redeemed for money by its destination.
 labels:
  - Checks
 ---
 # Check
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L50-L63 "Source")
+
+A `Check` entry describes a [check](../../../../concepts/payment-types/checks.md), similar to a paper personal check, which can be cashed by its destination to get money from its sender. You can create a check by sending a [CheckCreate transaction][].

 _(Added by the [Checks amendment][].)_

-A `Check` entry describes a [check](../../../../concepts/payment-types/checks.md), similar to a paper personal check, which can be cashed by its destination to get money from its sender.
-
 ## Example {% $frontmatter.seo.title %} JSON

 ```json
--- a/docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth.md
@@ -1,15 +1,13 @@
 ---
-html: depositpreauth-object.html #depositpreauth.html is taken by the tx type
-parent: ledger-entry-types.html
 seo:
    description: A record of preauthorization for sending payments to an account that requires authorization.
 labels:
  - Security
 ---
 # DepositPreauth
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L172-L178 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L246-L253 "Source")

-A `DepositPreauth` entry tracks a preauthorization from one account to another. [DepositPreauth transactions][] create these entries.
+A `DepositPreauth` entry tracks a preauthorization from one account to another. You can create a preauthorization by sending a [DepositPreauth transaction][].

 This has no effect on processing of transactions unless the account that provided the preauthorization requires [Deposit Authorization](../../../../concepts/accounts/depositauth.md). In that case, the account that was preauthorized can send payments and other transactions directly to the account that provided the preauthorization. Preauthorizations are one-directional, and have no effect on payments going the opposite direction.

--- a/docs/references/protocol/ledger-data/ledger-entry-types/did.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/did.md
@@ -1,18 +1,15 @@
 ---
-html: did.html
-parent: ledger-entry-types.html
 seo:
    description: The definition and details of a Decentralized Identifier (DID).
 labels:
  - DID
 ---
 # DID
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L330-L341 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L69-L77 "Source")

-_(Requires the [DID amendment][])_
-
-A `DID` ledger entry holds references to, or data associated with, a single [DID](../../../../concepts/decentralized-storage/decentralized-identifiers.md).
+A `DID` ledger entry holds references to, or data associated with, a single [Decentralized Identifier (DID)](../../../../concepts/decentralized-storage/decentralized-identifiers.md). You can create or modify a DID by sending a [DIDSet transaction][].

+_(Added by the [DID amendment][])_

 ## Example DID JSON

--- a/docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
@@ -6,7 +6,7 @@ labels:
  - Decentralized Exchange
 ---
 # DirectoryNode
-[[Source]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L165-L179 "Source")

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

@@ -16,6 +16,8 @@ There are three kinds of directory:
 * _Offer directories_ list the offers available in the [decentralized exchange](../../../../concepts/tokens/decentralized-exchange/index.md). A single Offer directory contains all the offers that have the same exchange rate for the same token (currency code and issuer).
 * _NFT Offer directories_ list buy and sell offers for NFTs. Each NFT has up to two directories, one for buy offers, the other for sell offers.

+All types of directories are automatically updated by the protocol as necessary.
+
 ## Example {% $frontmatter.seo.title %} JSON

 {% tabs %}
--- a/docs/references/protocol/ledger-data/ledger-entry-types/escrow.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/escrow.md
@@ -1,18 +1,16 @@
 ---
-html: escrow-object.html #escrow.html is taken by the concept page
-parent: ledger-entry-types.html
 seo:
    description: Contains XRP held for a conditional payment.
 labels:
  - Escrow
 ---
 # Escrow
-[[Source]](https://github.com/XRPLF/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L329-L342 "Source")
+
+An `Escrow` ledger entry represents an [escrow](../../../../concepts/payment-types/escrow.md), which holds XRP until specific conditions are met. You can create an escrow by sending an [EscrowCreate transaction][].

 _(Added by the [Escrow amendment][].)_

-An `Escrow` ledger entry represents an [escrow](../../../../concepts/payment-types/escrow.md), which holds XRP until specific conditions are met.
-
 ## Example {% $frontmatter.seo.title %} JSON

 ```json
--- a/docs/references/protocol/ledger-data/ledger-entry-types/feesettings.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/feesettings.md
@@ -1,13 +1,11 @@
 ---
-html: feesettings.html
-parent: ledger-entry-types.html
 seo:
    description: Singleton object with consensus-approved base transaction cost and reserve requirements.
 labels:
  - Fees
 ---
 # FeeSettings
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L115-L120 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L297-L309 "Source")

 The `FeeSettings` entry contains the current base [transaction cost](../../../../concepts/transactions/transaction-cost.md) and [reserve amounts](../../../../concepts/accounts/reserves.md) as determined by [fee voting](../../../../concepts/consensus-protocol/fee-voting.md). Each ledger version contains **at most one** `FeeSettings` entry.

--- a/docs/references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md
@@ -1,26 +1,24 @@
 ---
-html: ledgerhashes.html
-parent: ledger-entry-types.html
 seo:
    description: Lists of prior ledger versions' hashes for history lookup.
 labels:
  - Blockchain
 ---
 # LedgerHashes
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L104-L108 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L202-L206 "Source")

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

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

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

- Exactly one "recent history" `LedgerHashes` object
- A number of "previous history" `LedgerHashes` objects based on the current ledger index (that is, the length of the ledger history). Specifically, the XRP Ledger adds a new "previous history" object every 65536 ledger versions. <!-- STYLE_OVERRIDE: a number of -->
+- Exactly one "recent history" `LedgerHashes` entry.
+- A number of "previous history" `LedgerHashes` entries based on the current ledger index (that is, the length of the ledger history). Specifically, the XRP Ledger adds a new "previous history" object every 65536 ledger versions.

 {% admonition type="info" name="Note" %}As an exception, a new genesis ledger has no `LedgerHashes` objects at all, because it has no ledger history.{% /admonition %}

-Example `LedgerHashes` object (trimmed for length):
+Example `LedgerHashes` entry (trimmed for length):

 ```json
 {
@@ -54,16 +52,16 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e

 ## Recent History LedgerHashes

-There is exactly one `LedgerHashes` object of the "recent history" sub-type in every ledger after the genesis ledger. This object contains the identifying hashes of the most recent 256 ledger versions (or fewer, if the ledger history has less than 256 ledgers total) in the `Hashes` array. Whenever a new ledger is closed, part of the process of closing it involves updating the "recent history" object with the hash of the previous ledger version this ledger version is derived from (also known as this ledger version's _parent ledger_). When there are more than 256 hashes, the oldest one is removed.
+There is exactly one `LedgerHashes` entry of the "recent history" sub-type in every ledger after the genesis ledger. This entry contains the identifying hashes of the most recent 256 ledger versions (or fewer, if the ledger history has less than 256 ledgers total) in the `Hashes` array. Whenever a new ledger is closed, part of the process of closing it involves updating the "recent history" entry with the hash of the previous ledger version this ledger version is derived from (also known as this ledger version's _parent ledger_). When there are more than 256 hashes, the oldest one is removed.

-Using the "recent history" `LedgerHashes` object of a given ledger, you can get the hash of any ledger index within the 256 ledger versions before the given ledger version.
+Using the "recent history" `LedgerHashes` entry of a given ledger, you can get the hash of any of the 256 ledger versions before it.


 ## Previous History LedgerHashes

-The "previous history" `LedgerHashes` entries collectively contain the hash of every 256th ledger version (also called "flag ledgers") in the full history of the ledger. When the child of a flag ledger closes, the flag ledger's hash is added to the `Hashes` array of the newest "previous history" `LedgerHashes` object. Every 65536 ledgers, `rippled` creates a new `LedgerHashes` object, so that each "previous history" object has the hashes of 256 flag ledgers.
+The "previous history" `LedgerHashes` entries collectively contain the hash of every 256th ledger version (also called "flag ledgers") in the full history of the ledger. When the child of a flag ledger closes, the flag ledger's hash is added to the `Hashes` array of the newest "previous history" `LedgerHashes` entry. Every 65536 ledgers, `rippled` creates a new `LedgerHashes` entry, so that each "previous history" entry has the hashes of 256 flag ledgers.

-{% admonition type="info" name="Note" %}The oldest "previous history" `LedgerHashes` object contains only 255 entries because the genesis ledger has ledger index 1, not 0.{% /admonition %}
+{% admonition type="info" name="Note" %}The oldest "previous history" `LedgerHashes` entry contains only 255 hashes because the genesis ledger has ledger index 1, not 0.{% /admonition %}

 The "previous history" `LedgerHashes` objects act as a [skip list](https://en.wikipedia.org/wiki/Skip_list) so you can get the hash of any historical flag ledger from its index. From there, you can use that flag ledger's "recent history" object to get the hash of any other ledger.

@@ -76,15 +74,15 @@ There are no flags defined for {% code-page-name /%} entries.
 ## LedgerHashes ID Formats
 [[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L26-L42)

-There are two formats for `LedgerHashes` object IDs, depending on whether the object is a "recent history" sub-type or a "previous history" sub-type.
+There are two formats for `LedgerHashes` ledger entry IDs, depending on whether the entry is a "recent history" sub-type or a "previous history" sub-type.

-The **"recent history"** `LedgerHashes` object has an ID that is the [SHA-512Half][] of the `LedgerHashes` space key (`0x0073`). In other words, the "recent history" always has the ID `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`.
+The **"recent history"** `LedgerHashes` entry has an ID that is the [SHA-512Half][] of the `LedgerHashes` space key (`0x0073`). In other words, the "recent history" always has the ID `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`.

-The **"previous history"** `LedgerHashes` objects have an ID that is the [SHA-512Half][] of the following values, concatenated in order:
+Each **"previous history"** `LedgerHashes` entry has an ID that is the [SHA-512Half][] of the following values, concatenated in order:

 - The `LedgerHashes` space key (`0x0073`)
 - The 32-bit [Ledger Index][] of a flag ledger in the object's `Hashes` array, divided by 65536.

-    {% admonition type="success" name="Tip" %}Dividing by 65536 keeps the most significant 16 bits, which are the same for all the flag ledgers listed in a "previous history" object, and only those ledgers. You can use this fact to look up the `LedgerHashes` object that contains the hash of any flag ledger.{% /admonition %}
+    {% admonition type="success" name="Tip" %}Dividing by 65536 keeps the most significant 16 bits, which are the same for all the flag ledgers listed in a "previous history" entry, and only those ledgers. You can use this fact to look up the `LedgerHashes` entry that contains the hash of any flag ledger.{% /admonition %}

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/docs/references/protocol/ledger-data/ledger-entry-types/negativeunl.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/negativeunl.md
@@ -1,12 +1,11 @@
 ---
-html: negativeunl.html
-parent: ledger-entry-types.html
 seo:
    description: List of validators currently believed to be offline.
 labels:
  - Blockchain
 ---
 # NegativeUNL
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L85-L91 "Source")

 _(Added by the [NegativeUNL amendment][].)_

@@ -42,8 +41,8 @@ In addition to the [common fields](../common-fields.md), the {% code-page-name /
 |:----------------------|:----------|:------------------|:----------|:---------------------|
 | `DisabledValidators`  | Array     | Array             | No        | A list of `DisabledValidator` objects (see below), each representing a trusted validator that is currently disabled. |
 | `LedgerEntryType`     | String    | UInt16            | Yes       | The value `0x004E`, mapped to the string `NegativeUNL`, indicates that this entry is the Negative UNL. |
-| `PreviousTxnID`     | String    | Hash256           | No        | The identifying hash of the transaction that most recently modified this entry. _(Added by the [fixPreviousTxnID amendment][].)_ |
-| `PreviousTxnLgrSeq` | Number    | UInt32            | No        | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this entry. _(Added by the [fixPreviousTxnID amendment][].)_ |
+| `PreviousTxnID`       | String    | Hash256           | No        | The identifying hash of the transaction that most recently modified this entry. _(Added by the [fixPreviousTxnID amendment][].)_ |
+| `PreviousTxnLgrSeq`   | Number    | UInt32            | No        | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this entry. _(Added by the [fixPreviousTxnID amendment][].)_ |
 | `ValidatorToDisable`  | String    | Blob              | No        | The public key of a trusted validator that is scheduled to be disabled in the next flag ledger. |
 | `ValidatorToReEnable` | String    | Blob              | No        | The public key of a trusted validator in the Negative UNL that is scheduled to be re-enabled in the next flag ledger. |

--- a/docs/references/protocol/ledger-data/ledger-entry-types/nftokenoffer.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/nftokenoffer.md
@@ -1,14 +1,13 @@
 ---
-html: nftokenoffer.html
-parent: ledger-entry-types.html
 seo:
    description: Create offers to buy or sell NFTs.
 labels:
 - Non-fungible Tokens, NFTs
 ---
 # NFTokenOffer
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L34-L44 "Source")

-An `NFTokenOffer` entry represents an offer to buy, sell or transfer an [NFT](../../../../concepts/tokens/nfts/index.md).
+An `NFTokenOffer` entry represents an offer to buy, sell or transfer an [NFT](../../../../concepts/tokens/nfts/index.md). You can create an NFT buy or sell offer by sending an [NFTokenCreateOffer transaction][].

 _(Added by the [NonFungibleTokensV1_1 amendment][].)_

--- a/docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
@@ -1,14 +1,13 @@
 ---
-html: nftokenpage.html
-parent: ledger-entry-types.html
 seo:
    description: Ledger structure for recording NFTokens.
 labels:
 - Non-fungible Tokens, NFTs
 ---
 # NFTokenPage
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L97-L103 "Source")

-The `NFTokenPage` object represents a collection of [NFTs](../../../../concepts/tokens/nfts/index.md) owned by the same account. An account can have multiple `NFTokenPage` entries, which form a doubly linked list.
+An `NFTokenPage` entry represents a collection of [NFTs](../../../../concepts/tokens/nfts/index.md) owned by the same account. An account can have multiple `NFTokenPage` entries, which form a doubly linked list. NFT directories are automatically updated when an account mints, burns, buys, or sells NFTs.

 _(Added by the [NonFungibleTokensV1_1 amendment][].)_

@@ -92,14 +91,16 @@ Since each page can hold up to 32 entries, the _effective_ reserve cost per NFT

 Because of the way splitting and combining pages works, the actual number of `NFToken` objects per page is somewhat unpredictable and depends on the actual `NFTokenID` values involved. In practice, after minting or receiving a large number of NFTs, each page can have as few as 16 items, or as many as 32, with the typical case being around 24 `NFToken` objects per page.

-Currently, the reserve per item is 2 XRP. The table below shows how much the **total owner reserve** is for various numbers of NFTs owned under various scenarios:
+Currently, the reserve per item is {% $env.PUBLIC_OWNER_RESERVE %}. The table below shows how much the **total owner reserve** is for various numbers of NFTs owned under various scenarios:

 | NFTs Owned  | Best Case | Typical | Worst Case |
 |:------------|:----------|:--------|:-----------|
-| 32 or fewer | 2 XRP     | 2 XRP   | 2 XRP      |
-| 50          | 4 XRP     | 6 XRP   | 8 XRP      |
-| 200         | 14 XRP    | 18 XRP  | 26 XRP     |
-| 1000        | 64 XRP    | 84 XRP  | 126 XRP    |
+| 32 or fewer | 0.2 XRP   | 0.2 XRP | 0.2 XRP    |
+| 50          | 0.4 XRP   | 0.6 XRP | 0.8 XRP    |
+| 200         | 1.4 XRP   | 1.8 XRP | 2.6 XRP    |
+| 1000        | 6.4 XRP   | 8.4 XRP | 12.6 XRP   |
+
+<!-- RESERVES_REMINDER: update math if reserves change -->

 These numbers are estimates; the actual numbers may vary.

--- a/docs/references/protocol/ledger-data/ledger-entry-types/offer.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/offer.md
@@ -1,15 +1,13 @@
 ---
-html: offer.html
-parent: ledger-entry-types.html
 seo:
    description: An order to make a currency trade.
 labels:
  - Decentralized Exchange
 ---
 # Offer
-[[Source]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L57 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L229-L240 "Source")

-The `Offer` ledger entry describes an [Offer](../../../../concepts/tokens/decentralized-exchange/offers.md) to exchange currencies in the XRP Ledger's [decentralized exchange](../../../../concepts/tokens/decentralized-exchange/index.md). (In finance, this is more traditionally known as an _order_.) An [OfferCreate transaction][] only creates an `Offer` entry in the ledger when the Offer cannot be fully executed immediately by consuming other Offers already in the ledger.
+An `Offer` ledger entry describes an [Offer](../../../../concepts/tokens/decentralized-exchange/offers.md) to exchange currencies in the XRP Ledger's [decentralized exchange](../../../../concepts/tokens/decentralized-exchange/index.md). (In finance, this is more traditionally known as an _order_.) You an create a new Offer entry by sending an [OfferCreate transaction][] that is not fully executed immediately.

 An Offer can become unfunded through other activities in the network, while remaining in the ledger. When processing transactions, the network automatically removes any unfunded Offers that those transactions come across. (Otherwise, unfunded Offers remain, because _only_ transactions can change the ledger state.)

--- a/docs/references/protocol/ledger-data/ledger-entry-types/oracle.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/oracle.md
@@ -1,17 +1,15 @@
+---
+seo:
+    description: A ledger entry to publish price information about currency pairs.
+labels:
+  - Decentralized Exchange
+---
 # Oracle
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L385-L395 "Source")

-_(Requires the [PriceOracle amendment][])_
-
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L353-L366 "Source")
-
-An `Oracle` ledger entry holds data associated with a single price oracle object.
-
-{% admonition type="info" name="Note" %}
-
-A price oracle object can store information for up to 10 token pairs.
-
-{% /admonition %}
+An `Oracle` ledger entry holds data associated with a single [price oracle](../../../../concepts/decentralized-storage/price-oracles.md), which can store information on up to 10 asset pairs. You can create or modify a price oracle with an [OracleSet transaction][].

+_(Added by the [PriceOracle amendment][])_

 ## Example Oracle JSON

@@ -42,12 +40,12 @@ A price oracle object can store information for up to 10 token pairs.

 | Field               | JSON Type | Internal Type | Required? | Description |
 |---------------------|-----------|---------------|-----------|-------------|
-| `Owner`             | String    | AccountID     | Yes       | The XRPL account with update and delete privileges for the oracle. It's recommended to set up [multi-signing](../../../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md) on this account. |
-| `Provider`          | String    | Blob          | Yes       | An arbitrary value that identifies an oracle provider, such as Chainlink, Band, or DIA. This field is a string, up to 256 ASCII hex encoded characters (0x20-0x7E). |
-| `PriceDataSeries`   | Array     | Array         | Yes       | An array of up to 10 `PriceData` objects, each representing the price information for a token pair. More than five `PriceData` objects require two owner reserves. |
-| `LastUpdateTime`    | Number    | UInt32        | Yes       | The time the data was last updated, represented in Unix time. |
+| `Owner`             | String    | AccountID     | Yes       | The [account](../../../../concepts/accounts/index.md) with update and delete privileges for the oracle. It's recommended to set up [multi-signing](../../../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md) on this account. |
+| `Provider`          | String    | Blob          | Yes       | An arbitrary value that identifies an oracle provider, such as Chainlink, Band, or DIA. This field is a string, up to 256 ASCII hex encoded characters (`0x20`-`0x7E`). |
+| `PriceDataSeries`   | Array     | Array         | Yes       | An array of up to 10 `PriceData` objects, each representing the price information for an asset pair. More than five `PriceData` objects require two owner reserves. |
+| `LastUpdateTime`    | Number    | UInt32        | Yes       | The time the data was last updated, represented in Unix time. (**Note:** Unlike many other time values on the XRP Ledger, this value does not use the Ripple Epoch.) |
 | `URI`               | String    | Blob          | No        | An optional Universal Resource Identifier to reference price data off-chain. This field is limited to 256 bytes. |
-| `AssetClass`        | String    | Blob          | Yes       | Describes the type of asset, such as "currency", "commodity", or "index". This field is a string, up to 16 ASCII hex encoded characters (0x20-0x7E). |
+| `AssetClass`        | String    | Blob          | Yes       | Arbitrary string to describe the type of asset, such as _currency_, _commodity_, or _index_. Must be formatted as hexadecimal representing ASCII characters (`0x20`-`0x7E`), maximum 16 bytes. |
 | `OwnerNode`         | String    | UInt64        | Yes       | A hint indicating which page of the oracle owner's owner directory links to this entry, in case the directory consists of multiple pages. |
 | `PreviousTxnID`     | String    | UInt256       | Yes       | The hash of the previous transaction that modified this entry. |
 | `PreviousTxnLgrSeq` | String    | UInt32        | Yes       | The ledger index that this object was most recently modified or created in. |
--- a/docs/references/protocol/ledger-data/ledger-entry-types/paychannel.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/paychannel.md
@@ -1,19 +1,16 @@
 ---
-html: paychannel.html
-parent: ledger-entry-types.html
 seo:
    description: A channel for asynchronous XRP payments.
 labels:
  - Payment Channels
 ---
 # PayChannel
-[[Source]](https://github.com/XRPLF/rippled/blob/c0a0b79d2d483b318ce1d82e526bd53df83a4a2c/src/ripple/protocol/impl/LedgerFormats.cpp#L180-L198 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L348-L363 "Source")
+
+A `PayChannel` entry represents a [payment channel](../../../../concepts/payment-types/payment-channels.md). You can create a payment channel with a [PaymentChannelCreate transaction][].

 _(Added by the [PayChan amendment][].)_

-A `PayChannel` entry represents a [payment channel](../../../../concepts/payment-types/payment-channels.md).
-
-
 ## Example {% $frontmatter.seo.title %} JSON

 ```json
--- a/docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md
@@ -1,15 +1,13 @@
 ---
-html: ripplestate.html
-parent: ledger-entry-types.html
 seo:
    description: This entry represents a trust line, tracking the net balance of tokens between them.
 labels:
  - Tokens
 ---
 # RippleState
-[[Source]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L70 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L277-L289 "Source")

-A `RippleState` ledger entry represents a [trust line](../../../../concepts/tokens/fungible-tokens/index.md) between two accounts. Each account can change its own limit and other settings, but the balance is a single shared value. A trust line that is entirely in its default state is considered the same as a trust line that does not exist and is automatically deleted.
+A `RippleState` ledger entry represents a [trust line](../../../../concepts/tokens/fungible-tokens/index.md) between two accounts. Each account can change its own limit and other settings, but the balance is a single shared value. A trust line that is entirely in its default state is considered the same as a trust line that does not exist and is automatically deleted. You can create or modify a trust line with a [TrustSet transaction][].

 ## High vs. Low Account

--- a/docs/references/protocol/ledger-data/ledger-entry-types/signerlist.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/signerlist.md
@@ -1,19 +1,16 @@
 ---
-html: signerlist.html
-parent: ledger-entry-types.html
 seo:
    description: A list of addresses for multi-signing transactions.
 labels:
  - Security
 ---
 # SignerList
-[[Source]](https://github.com/XRPLF/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L111-L118 "Source")
+
+A `SignerList` entry represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account by [multi-signing](../../../../concepts/accounts/multi-signing.md). You can create, replace, or remove a signer list using a [SignerListSet transaction][].

 _(Added by the [MultiSign amendment][].)_

-A `SignerList` entry represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a signer list using a [SignerListSet transaction][].
-
-
 ## Example {% $frontmatter.seo.title %} JSON

 ```json
--- a/docs/references/protocol/ledger-data/ledger-entry-types/ticket.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/ticket.md
@@ -7,12 +7,12 @@ labels:
  - Transaction Sending
 ---
 # Ticket
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L124-L130 "Source")

-[[Source]](https://github.com/XRPLF/rippled/blob/76a6956138c4ecd156c5c408f136ed3d6ab7d0c1/src/ripple/protocol/impl/LedgerFormats.cpp#L155-L164)
+A `Ticket` entry type represents a [Ticket](../../../../concepts/accounts/tickets.md), which tracks an account [sequence number][Sequence Number] that has been set aside for future use. You can create new tickets with a [TicketCreate transaction][].

 _(Added by the [TicketBatch amendment][].)_

-A `Ticket` entry type represents a [Ticket](../../../../concepts/accounts/tickets.md), which tracks an account [sequence number][Sequence Number] that has been set aside for future use. You can create new tickets with a [TicketCreate transaction][].

 ## Example {% $frontmatter.seo.title %} JSON

--- a/docs/references/protocol/ledger-data/ledger-entry-types/xchainownedclaimid.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/xchainownedclaimid.md
@@ -1,6 +1,4 @@
 ---
-html: xchainownedclaimid.html
-parent: ledger-entry-types.html
 seo:
    description: An `XChainOwnedClaimID` object represents *one* cross-chain transfer of value. 
 labels:
@@ -8,16 +6,16 @@ labels:
 status: not_enabled
 ---
 # XChainOwnedClaimID
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L259-L269 "Source")
+
+An `XChainOwnedClaimID` entry represents *one* cross-chain transfer of value and includes information of the account on the source chain that locks or burns the funds on the source chain.
+
+The `XChainOwnedClaimID` entry must be acquired on the destination chain before submitting a `XChainCommit` on the source chain. Its purpose is to prevent transaction replay attacks. It is also used as a place to collect attestations from witness servers.
+
+You can create a new `XChainOwnedClaimID` by sending an [XChainCreateClaimID transaction][]. An `XChainOwnedClaimID` is destroyed when the funds are successfully claimed on the destination chain.
+
 _(Requires the [XChainBridge amendment][] {% not-enabled /%})_

-[[Source]](https://github.com/seelabs/rippled/blob/xbridge/src/ripple/protocol/impl/LedgerFormats.cpp#L281-L293 "Source")
-
-An `XChainOwnedClaimID` object represents *one* cross-chain transfer of value and includes information of the account on the source chain that locks or burns the funds on the source chain.
-
-The `XChainOwnedClaimID` object must be acquired on the destination chain before submitting a `XChainCommit` on the source chain. Its purpose is to prevent transaction replay attacks and is also used as a place to collect attestations from witness servers.
-
-An `XChainCreateClaimID` transaction is used to create a new `XChainOwnedClaimID`. The ledger object is destroyed when the funds are successfully claimed on the destination chain.
-

 ## Example XChainOwnedClaimID JSON

--- a/docs/references/protocol/ledger-data/ledger-entry-types/xchainownedcreateaccountclaimid.md
+++ b/docs/references/protocol/ledger-data/ledger-entry-types/xchainownedcreateaccountclaimid.md
@@ -1,6 +1,4 @@
 ---
-html: xchainownedcreateaccountclaimid.html
-parent: ledger-entry-types.html
 seo:
    description: The `XChainOwnedCreateAccountClaimID` ledger object is used to collect attestations for creating an account via a cross-chain transfer. 
 labels:
@@ -8,16 +6,16 @@ labels:
 status: not_enabled
 ---
 # XChainOwnedCreateAccountClaimID
+[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L315-L323 "Source")
+
+An `XChainOwnedCreateAccountClaimID` ledger entry collects attestations for creating an account via a cross-chain transfer.
+
+You can create a new `XChainOwnedCreateAccountClaimID` entry by sending an [XChainAddAccountCreateAttestation transaction][] with a signed attestation of a relevant transaction occurring on another chain.
+
+An `XChainOwnedCreateAccountClaimID` ledger entry is destroyed when all the attestations have been received and the funds have transferred to the new account.
+
 _(Requires the [XChainBridge amendment][] {% not-enabled /%})_

-[[Source]](https://github.com/seelabs/rippled/blob/xbridge/src/ripple/protocol/impl/LedgerFormats.cpp#L296-L306 "Source")
-
-The `XChainOwnedCreateAccountClaimID` ledger object is used to collect attestations for creating an account via a cross-chain transfer.
-
-It is created when an `XChainAddAccountCreateAttestation` transaction adds a signature attesting to a `XChainAccountCreateCommit` transaction and the `XChainAccountCreateCount` is greater than or equal to the current `XChainAccountClaimCount` on the `Bridge` ledger object.
-
-The ledger object is destroyed when all the attestations have been received and the funds have transferred to the new account.
-

 ## Example XChainOwnedCreateAccountClaimID JSON

--- a/docs/references/protocol/transactions/pseudo-transaction-types/enableamendment.md
+++ b/docs/references/protocol/transactions/pseudo-transaction-types/enableamendment.md
@@ -1,29 +1,19 @@
 ---
-html: enableamendment.html
-parent: pseudo-transaction-types.html
 seo:
    description: Enable a change in transaction processing.
 labels:
  - Blockchain
 ---
 # EnableAmendment
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Change.cpp "Source")

-An `EnableAmendment` pseudo-transaction marks a change in the status of a proposed amendment when it:
+An `EnableAmendment` pseudo-transaction marks a change in the status of a proposed amendment. The possible status changes are:

- Gains supermajority approval from validators.
- Loses supermajority approval.
- Is enabled on the XRP Ledger protocol.
+- The amendment gains supermajority approval from validators.
+- The amendment loses supermajority approval.
+- The amendment becomes enabled.

-<!-- TODO: Move to propose amendments tutorial.
-
-A server only enables amendments when these conditions are met:
-  
- A previous ledger includes an `EnableAmendment` pseudo-transaction with the `tfGotMajority` flag enabled.
- The previous ledger in question is an ancestor of the current ledger.
- The previous ledger in question has a close time that is at least two weeks before the close time of the latest flag ledger.
- There are no `EnableAmendment` pseudo-transactions for this amendment with the `tfLostMajority` flag enabled in the consensus ledgers between the `tfGotMajority` pseudo-transaction and the current ledger.
-
-->
+{% admonition type="info" name="Note" %}You cannot send a pseudo-transaction, but you may find one when processing ledgers.{% /admonition %}

 ## Example {% $frontmatter.seo.title %} JSON

@@ -41,7 +31,6 @@ A server only enables amendments when these conditions are met:


 {% partial file="/docs/_snippets/pseudo-tx-fields-intro.md" /%}
-<!--{# fix md highlighting_ #}-->

 | Field            | JSON Type | [Internal Type][] | Description               |
 |:-----------------|:----------|:------------------|:--------------------------|
--- a/docs/references/protocol/transactions/pseudo-transaction-types/setfee.md
+++ b/docs/references/protocol/transactions/pseudo-transaction-types/setfee.md
@@ -1,12 +1,11 @@
 ---
-html: setfee.html
-parent: pseudo-transaction-types.html
 seo:
    description: Change global reserve and transaction cost settings.
 labels:
  - Fees
 ---
 # SetFee
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Change.cpp "Source")

 A `SetFee` [pseudo-transaction](pseudo-transaction-types.md) marks a change in [transaction cost](../../../../concepts/transactions/transaction-cost.md) or [reserve requirements](../../../../concepts/accounts/reserves.md) as a result of [Fee Voting](../../../../concepts/consensus-protocol/fee-voting.md).

@@ -14,6 +13,28 @@ A `SetFee` [pseudo-transaction](pseudo-transaction-types.md) marks a change in [

 ## Example {% $frontmatter.seo.title %} JSON

+This transaction has two formats, depending on whether the [XRPFees amendment][] was enabled at the time:
+
+{% tabs %}
+{% tab label="Current Format" %}
+```json
+{
+    "Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
+    "BaseFeeDrops": "10",
+    "Fee": "0",
+    "LedgerSequence": 92508417,
+    "ReserveBaseDrops": "1000000",
+    "ReserveIncrementDrops": "200000",
+    "Sequence": 0,
+    "SigningPubKey": "",
+    "TransactionType": "SetFee",
+    "date": 786494751,
+    "ledger_index": 92508417
+}
+```
+{% /tab %}
+
+{% tab label="Legacy Format" %}
 ```json
 {
    "Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp",
@@ -30,28 +51,35 @@ A `SetFee` [pseudo-transaction](pseudo-transaction-types.md) marks a change in [
    "ledger_index": 3721729,
 }
 ```
+{% /tab %}
+{% /tabs %}

 {% partial file="/docs/_snippets/pseudo-tx-fields-intro.md" /%}
-<!--{# fix md highlighting_ #}-->

-| Field               | JSON Type        | [Internal Type][] | Description     |
-|:--------------------|:-----------------|:------------------|:----------------|
-| `BaseFee`           | String           | UInt64            | The charge, in drops of XRP, for the reference transaction, as hex. (This is the [transaction cost](../../../../concepts/transactions/transaction-cost.md) before scaling for load.) |
-| `ReferenceFeeUnits` | Unsigned Integer | UInt32            | The cost, in fee units, of the reference transaction |
-| `ReserveBase`       | Unsigned Integer | UInt32            | The base reserve, in drops |
-| `ReserveIncrement`  | Unsigned Integer | UInt32            | The incremental reserve, in drops |
-| `LedgerSequence`    | Number           | UInt32            | _(Omitted for some historical `SetFee` pseudo-transactions)_ The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
+## {% $frontmatter.seo.title %} Fields

+The fields of a SetFee pseudo-transaction depend on whether the [XRPFees amendment][] was enabled at the time. In addition to the [common fields](./pseudo-transaction-types.md), they can use the following:

-If the _[XRPFees amendment][]_ is enabled, `SetFee` pseudo-transactions use these fields instead:
-
+{% tabs %}
+{% tab label="Current Format" %}
 | Field                   | JSON Type | [Internal Type][] | Description     |
 |:------------------------|:----------|:------------------|:----------------|
 | `BaseFeeDrops`          | String    | Amount            | The charge, in drops of XRP, for the reference transaction. (This is the [transaction cost](../../../../concepts/transactions/transaction-cost.md) before scaling for load.) |
-| `ReserveBaseDrops`      | String    | Amount            | The base reserve, in drops |
-| `ReserveIncrementDrops` | String    | Amount            | The incremental reserve, in drops |
+| `ReserveBaseDrops`      | String    | Amount            | The base reserve, in drops. |
+| `ReserveIncrementDrops` | String    | Amount            | The incremental reserve, in drops. |
 | `LedgerSequence`        | Number    | UInt32            | _(Omitted for some historical `SetFee` pseudo-transactions)_ The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
+{% /tab %}

+{% tab label="Legacy Format" %}
+| Field               | JSON Type | [Internal Type][] | Description     |
+|:--------------------|:----------|:------------------|:----------------|
+| `BaseFee`           | String    | UInt64            | The charge, in drops of XRP, for the reference transaction, as hex. (This is the [transaction cost](../../../../concepts/transactions/transaction-cost.md) before scaling for load.) |
+| `ReferenceFeeUnits` | Number    | UInt32            | The cost, in fee units, of the reference transaction. |
+| `ReserveBase`       | Number    | UInt32            | The base reserve, in drops. |
+| `ReserveIncrement`  | Number    | UInt32            | The incremental reserve, in drops |
+| `LedgerSequence`    | Number    | UInt32            | _(Omitted for some historical `SetFee` pseudo-transactions)_ The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
+{% /tab %}
+{% /tabs %}

 {% raw-partial file="/docs/_snippets/setfee_uniqueness_note.md" /%}

--- a/docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
+++ b/docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
@@ -7,6 +7,7 @@ labels:
  - Blockchain
 ---
 # UNLModify
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Change.cpp "Source")

 _(Added by the [NegativeUNL amendment][].)_

--- a/docs/references/protocol/transactions/types/accountdelete.md
+++ b/docs/references/protocol/transactions/types/accountdelete.md
@@ -1,6 +1,4 @@
 ---
-html: accountdelete.html
-parent: transaction-types.html
 seo:
    description: Delete an account.
 labels:
@@ -8,9 +6,9 @@ labels:
 ---
 # AccountDelete

-[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/tx/impl/DeleteAccount.cpp "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DeleteAccount.cpp "Source")

-_Added by the [DeletableAccounts amendment](/resources/known-amendments.md#deletableaccounts)_
+_Added by the [DeletableAccounts amendment][]_

 An AccountDelete transaction deletes an [account](../../ledger-data/ledger-entry-types/accountroot.md) and any objects it owns in the XRP Ledger, if possible, sending the account's remaining XRP to a specified destination account. See [Deleting Accounts](../../../../concepts/accounts/deleting-accounts.md) for the requirements to delete an account.

@@ -31,16 +29,16 @@ An AccountDelete transaction deletes an [account](../../ledger-data/ledger-entry
 [Query example transaction. >](/resources/dev-tools/websocket-api-tool?server=wss%3A%2F%2Fxrplcluster.com%2F&req=%7B%22id%22%3A%22example_AccountDelete%22%2C%22command%22%3A%22tx%22%2C%22transaction%22%3A%221AF19BF9717DA0B05A3BFC5007873E7743BA54C0311CCCCC60776AAEAC5C4635%22%2C%22binary%22%3Afalse%7D)

 {% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
-<!--{# fix md highlighting_ #}-->

-| Field            | JSON Type        | [Internal Type][] | Description        |
-|:-----------------|:-----------------|:------------------|:-------------------|
-| `Destination`    |  String - [Address][] | AccountID    | The address of an account to receive any leftover XRP after deleting the sending account. Must be a funded account in the ledger, and must not be the sending account. |
-| `DestinationTag` | Number           | UInt32            | _(Optional)_ Arbitrary [destination tag](../../../../concepts/transactions/source-and-destination-tags.md) that identifies a hosted recipient or other information for the recipient of the deleted account's leftover XRP. |
+| Field            | JSON Type        | [Internal Type][] | Required? | Description |
+|:-----------------|:-----------------|:------------------|:----------|:------------|
+| `Destination`    |  String - [Address][] | AccountID    | Yes       | The address of an account to receive any leftover XRP after deleting the sending account. Must be a funded account in the ledger, and must not be the sending account. |
+| `DestinationTag` | Number           | UInt32            | No        | Arbitrary [destination tag](../../../../concepts/transactions/source-and-destination-tags.md) that identifies a hosted recipient or other information for the recipient of the deleted account's leftover XRP. |
+

 ## Special Transaction Cost

-As an additional deterrent against ledger spam, the AccountDelete transaction requires a much higher than usual [transaction cost](../../../../concepts/transactions/transaction-cost.md): instead of the standard minimum of 0.00001 XRP, AccountDelete must destroy at least the owner reserve amount, currently 2 XRP. This discourages excessive creation of new accounts because the [reserve requirement](../../../../concepts/accounts/reserves.md) cannot be fully recouped by deleting the account.
+As an additional deterrent against ledger spam, the AccountDelete transaction requires a much higher than usual [transaction cost](../../../../concepts/transactions/transaction-cost.md): instead of the standard minimum of 0.00001 XRP, AccountDelete must destroy at least the owner reserve amount, currently {% $env.PUBLIC_OWNER_RESERVE %}. This discourages excessive creation of new accounts because the [reserve requirement](../../../../concepts/accounts/reserves.md) cannot be fully recouped by deleting the account.

 The transaction cost always applies when a transaction is included in a validated ledger, even if the transaction fails to delete the account. (See [Error Cases](#error-cases).) To greatly reduce the chances of paying the high transaction cost if the account cannot be deleted, [submit the transaction](../../../http-websocket-apis/public-api-methods/transaction-methods/submit.md) with `fail_hard` enabled.

@@ -57,7 +55,7 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
 | `tecNO_DST` | Occurs if the `Destination` account is not a funded account in the ledger. |
 | `tecNO_PERMISSION` | Occurs if the `Destination` account requires [deposit authorization](../../../../concepts/accounts/depositauth.md) and the sender is not preauthorized. |
 | `tecTOO_SOON` | Occurs if the sender's `Sequence` number is too high. The transaction's `Sequence` number plus 256 must be less than the current [Ledger Index][]. This prevents replay of old transactions if this account is resurrected after it is deleted. |
-| `tecHAS_OBLIGATIONS` | Occurs if the account to be deleted is connected to objects that cannot be deleted in the ledger. (This includes objects created by other accounts, such as [escrows](../../../../concepts/payment-types/escrow.md) and for example [NFT's minted](nftokenmint.md), [even if owned by another account](https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/tx/impl/DeleteAccount.cpp#L197).) |
+| `tecHAS_OBLIGATIONS` | Occurs if the account to be deleted is connected to objects that cannot be deleted in the ledger. (This includes objects created by other accounts, such as [escrows](../../../../concepts/payment-types/escrow.md) and for example [NFT's minted](nftokenmint.md), [even if owned by another account](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DeleteAccount.cpp#L197).) |
 | `tefTOO_BIG` | Occurs if the sending account is linked to more than 1000 objects in the ledger. The transaction could succeed on retry if some of those objects were deleted separately first. |

 {% raw-partial file="/docs/_snippets/common-links.md" /%}
--- a/docs/references/protocol/transactions/types/accountset.md
+++ b/docs/references/protocol/transactions/types/accountset.md
@@ -1,6 +1,4 @@
 ---
-html: accountset.html
-parent: transaction-types.html
 seo:
    description: Set options on an account.
 labels:
@@ -8,7 +6,7 @@ labels:
 ---
 # AccountSet

-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/SetAccount.cpp "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/SetAccount.cpp "Source")

 An AccountSet transaction modifies the properties of an [account in the XRP Ledger](../../ledger-data/ledger-entry-types/accountroot.md).

--- a/docs/references/protocol/transactions/types/ammbid.md
+++ b/docs/references/protocol/transactions/types/ammbid.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMBid
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMBid.cpp "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMBid.cpp "Source")

 _(Added by the [AMM amendment][])_

--- a/docs/references/protocol/transactions/types/ammcreate.md
+++ b/docs/references/protocol/transactions/types/ammcreate.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMCreate
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMCreate.cpp "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMCreate.cpp "Source")

 _(Added by the [AMM amendment][])_

@@ -48,7 +48,7 @@ One or both of `Amount` and `Amount2` can be [tokens](../../../../concepts/token

 ## Special Transaction Cost

-Since each AMM instance involves an AccountRoot ledger entry, an AMM ledger entry, and a trust line for each token in its pool, an AMMCreate transaction requires a much higher than usual [transaction cost][] to deter ledger spam. Instead of the standard minimum of 0.00001 XRP, AMMCreate must destroy at least the incremental owner reserve amount, currently 2 XRP. This is the same special transaction cost as [AccountDelete transactions][].
+Since each AMM instance involves an AccountRoot ledger entry, an AMM ledger entry, and a trust line for each token in its pool, an AMMCreate transaction requires a much higher than usual [transaction cost][] to deter ledger spam. Instead of the standard minimum of 0.00001 XRP, AMMCreate must destroy at least the incremental owner reserve amount, currently {% $env.PUBLIC_OWNER_RESERVE %}. This is the same special transaction cost as [AccountDelete transactions][].

 ## Error Cases

--- a/docs/references/protocol/transactions/types/ammdelete.md
+++ b/docs/references/protocol/transactions/types/ammdelete.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMDelete
-[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/tx/impl/AMMDelete.cpp "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMDelete.cpp "Source")

 _(Added by the [AMM amendment][])_

--- a/docs/references/protocol/transactions/types/ammdeposit.md
+++ b/docs/references/protocol/transactions/types/ammdeposit.md
@@ -7,7 +7,7 @@ labels:
  - AMM
 ---
 # AMMDeposit
-[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMDeposit.cpp "Source")
+[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMDeposit.cpp "Source")

 _(Added by the [AMM amendment][])_

--- a/Show More
+++ b/Show More