ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-21 12:15:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge commit '2a838803d7179c32d174e104421d575b82b2f5ce' into ja-usecases-rwa

Browse Source
This commit is contained in:
tequ
2024-12-15 17:48:02 +09:00
parent a1438b8056 2a838803d7
commit b0a854bab9
141 changed files with 1390 additions and 529 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.env
View File

@@ -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

4
@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md
View File

@@ -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.

2
@l10n/es-ES/docs/concepts/accounts/depositauth.md
View File

@@ -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][])_

2
@l10n/es-ES/docs/concepts/accounts/index.md
View File

@@ -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.

4
@l10n/es-ES/docs/concepts/accounts/reserves.md
View File

@@ -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.

4
@l10n/es-ES/docs/concepts/accounts/tickets.md
View File

@@ -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.

6
@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md
View File

@@ -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

2
@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md
View File

@@ -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

8
@l10n/ja/docs/concepts/accounts/cryptographic-keys.md
View File

@@ -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#トランザクションの承認)して初期化することができないからです。

4
@l10n/ja/docs/concepts/accounts/reserves.md
View File

@@ -25,8 +25,8 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ
メインネットにおける現在の準備金要件は次の通りです。
- 基本準備金 **10 XRP**
- 所有者準備金 アイテムにつき**2 XRP**
- 基本準備金 **{% $env.PUBLIC_BASE_RESERVE %}**
- 所有者準備金 アイテムにつき **{% $env.PUBLIC_OWNER_RESERVE %}**
他のネットワークでの準備金は異なる場合があります。

64
@l10n/ja/docs/concepts/consensus-protocol/fee-voting.md
View File

@@ -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" /%}

2
@l10n/ja/docs/concepts/networks-and-servers/peer-protocol.md
View File

@@ -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)をご覧ください。）
## ピアの検出

8
@l10n/ja/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
View File

@@ -57,6 +57,14 @@ XRP Ledgerの実装は、重みパラメータを0.5とした _幾何平均_ AMM
資産間の資金の流れが比較的活発でバランスが取れている場合、手数料は流動性供給者に対する受動的な収入源となります。しかし、資産間の相対価格が変動すると、流動性供給者は[通貨リスク](https://www.investopedia.com/terms/c/currencyrisk.asp)による損失を被ることになります。
### DEXの相互性
XRP LedgerのAMMは、Central Limit Order Book(CLOB/オーダーブック)ベースの分散型取引所と統合することで分散型取引所全体の流動性を高めています。オファーと支払いは、流動性プール内でのスワップ、オーダーブックを通じたスワップ、またはその両方が最良のレートを提供し、それに応じて約定されるかを自動的に最適化します。この相互性により、これらの取引は、分散型取引所のオファーやAMMプールの一方またはその両方を通じた取引の最も効率的な経路を使用して約定されます。
以下の図は、オファーが分散型取引所の他のオファーとAMMの流動性との相互作用を示しています。
![DEXのオファーの経路](/docs/img/amm-clob-diagram.png)
### 資産の制限 <a id="restrictions-on-assets"></a>
不正利用を防ぐため、AMMで利用できる資産にはいくつかの制限があります。これらの制約を満たさない資産でAMMを作成しようとすると、トランザクションは失敗します。ルールは以下のとおりです。

28
@l10n/ja/docs/concepts/tokens/nfts/reserve-requirements.md
View File

@@ -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)をご覧ください。

2
@l10n/ja/docs/concepts/transactions/transaction-queue.md
View File

@@ -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 %}

10
@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
View File

@@ -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 -->
これらの数字は推定であり、実際の数字とは異なる場合があります。

2
@l10n/ja/docs/references/protocol/transactions/types/accountdelete.md
View File

@@ -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)が必要です_

2
@l10n/ja/docs/references/protocol/transactions/types/ammbid.md
View File

@@ -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][]により追加されました。)_

2
@l10n/ja/docs/references/protocol/transactions/types/ammcreate.md
View File

@@ -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][]により追加されました。)_

2
@l10n/ja/docs/references/protocol/transactions/types/ammdelete.md
View File

@@ -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][]により追加されました。)_

2
@l10n/ja/docs/references/protocol/transactions/types/ammdeposit.md
View File

@@ -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][]により追加されました。)_

2
@l10n/ja/docs/references/protocol/transactions/types/ammvote.md
View File

@@ -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][]により追加されました。)_

2
@l10n/ja/docs/references/protocol/transactions/types/ammwithdraw.md
View File

@@ -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][]により追加されました。)_

2
@l10n/ja/docs/references/protocol/transactions/types/checkcancel.md
View File

@@ -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][]が必要です）_

2
@l10n/ja/docs/references/protocol/transactions/types/checkcash.md
View File

@@ -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][]が必要です）_

2
@l10n/ja/docs/references/protocol/transactions/types/checkcreate.md
View File

@@ -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][]が必要です）_

2
@l10n/ja/docs/references/protocol/transactions/types/clawback.md
View File

@@ -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" /%}

2
@l10n/ja/docs/references/protocol/transactions/types/depositpreauth.md
View File

@@ -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][]により追加されました。_

2
@l10n/ja/docs/references/protocol/transactions/types/diddelete.md
View File

@@ -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][])_

2
@l10n/ja/docs/references/protocol/transactions/types/didset.md
View File

@@ -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][])_

2
@l10n/ja/docs/references/protocol/transactions/types/escrowcancel.md
View File

@@ -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][]により追加されました。_

2
@l10n/ja/docs/references/protocol/transactions/types/escrowcreate.md
View File

@@ -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][]により追加されました。_

2
@l10n/ja/docs/references/protocol/transactions/types/escrowfinish.md
View File

@@ -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][]により追加されました。_

2
@l10n/ja/docs/references/protocol/transactions/types/nftokenacceptoffer.md
View File

@@ -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`の購入または売却のオファーを受け入れるために使用されます。トランザクションは次のいずれかになります。

2
@l10n/ja/docs/references/protocol/transactions/types/nftokencreateoffer.md
View File

@@ -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`に対する新しい _購入_ オファーを作成します。

7
@l10n/ja/docs/references/protocol/transactions/types/nftokenmint.md
View File

@@ -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`)を設定することができる唯一の方法です。
@@ -48,8 +48,9 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました)_
| `Issuer` | 文字列 | AccountID | _(省略可)_ 送信元アカウントが他のアカウントの代理としてトークンを発行する場合における、トークンの発行者。トランザクションを送信するアカウントが `NFToken` の発行者である場合、このフィールドは指定してはいけません。指定される場合、発行者の[AccountRootオブジェクト][]には `NFTokenMinter` フィールドが、このトランザクションの送信者(このトランザクションの`Account`フィールド)に設定されていなければなりません。 |
| `TransferFee` | 数値 | UInt16 | _(省略可)_ この値は、`NFToken`の二次販売が許可されている場合に、発行者が徴収する手数料を指定します。このフィールドの有効な値は0から50000の間で、0.001刻みで0.00%から50.00%の送金手数料を設定することができます。このフィールドが設定されている場合、トランザクションは[`tfTransferable`フラグ](#nftokenmintのフラグ) を有効にしなければなりません。 |
| `URI` | 文字列 | Blob | _(省略可)_ 最大256バイトの任意のデータ。JSONでは、16進数の文字列としてエンコードされる必要があります。URIを16進数に変換するために、[`xrpl.convertStringToHex`](https://js.xrpl.org/modules.html#convertStringToHex)ユーティリティを使用することができます。これは、NFTに関連するデータまたはメタデータを指し示すURIであることを想定しています。コンテンツは、HTTPまたはHTTPS URL、IPFS URI、マグネットリンク、[RFC2379 "data" URL](https://datatracker.ietf.org/doc/html/rfc2397) としてエンコードされた即値データ、あるいは発行者固有のエンコーディングにデコードされていることがあります。URIの有効性はチェックされません。 |
| `Amount` | [Currency Amount][] | Amount | _(Optional)_ Indicates the amount expected or offered for the corresponding `NFToken`. The amount must be non-zero, except where this is an offer to sell and the asset is XRP; then, it is legal to specify an amount of zero, which means that the current owner of the token is giving it away, gratis, either to anyone at all, or to the account identified by the `Destination` field. |
| `Expiration` | Number | UInt32 | _(Optional)_ Time after which the offer is no longer active, in [seconds since the Ripple Epoch][]. Results in an error if the `Amount` field is not specified. |
| `Destination` | String | AccountID | _(Optional)_ If present, indicates that this offer may only be accepted by the specified account. Attempts by other accounts to accept this offer MUST fail. Results in an error if the `Amount` field is not specified. |
## NFTokenMintのフラグ

2
@l10n/ja/docs/references/protocol/transactions/types/offercancel.md
View File

@@ -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オブジェクトを削除します。

2
@l10n/ja/docs/references/protocol/transactions/types/offercreate.md
View File

@@ -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)を作成します。

2
@l10n/ja/docs/references/protocol/transactions/types/oracledelete.md
View File

@@ -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`レジャーエントリを削除します。

2
@l10n/ja/docs/references/protocol/transactions/types/oracleset.md
View File

@@ -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`レジャーエントリを作成するか、既存のフィールドを更新します。

2
@l10n/ja/docs/references/protocol/transactions/types/paymentchannelclaim.md
View File

@@ -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][]により追加されました。_

2
@l10n/ja/docs/references/protocol/transactions/types/paymentchannelcreate.md
View File

@@ -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][]により追加されました。_

2
@l10n/ja/docs/references/protocol/transactions/types/paymentchannelfund.md
View File

@@ -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][]により追加されました。_

2
@l10n/ja/docs/references/protocol/transactions/types/ticketcreate.md
View File

@@ -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][]が必要です)_

2
@l10n/ja/docs/references/protocol/transactions/types/trustset.md
View File

@@ -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)を作成または変更します。

18
@l10n/ja/docs/tutorials/how-tos/use-specialized-payment-types/use-checks/use-checks.md
View File

@@ -1,18 +0,0 @@
---
html: use-checks.html
parent: use-specialized-payment-types.html
seo:
description: XRP LedgerのCheckは、紙の小切手と同じように、別のアカウントに資金を振り込ませることができます。
metadata:
indexPage: true
labels:
- Checks
---
# Checkの使用
XRP LedgerのChecksでは、別のアカウントが後で支払いを請求することが認められていており、個人用の紙の小切手の仕組みと似ています。
{% raw-partial file="/docs/_snippets/common-links.md" /%}
{% child-pages /%}

2
@l10n/ja/docs/use-cases/tokenization/nft-mkt-overview.md
View File

@@ -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の取引

4
@l10n/ja/resources/contribute-code/create-custom-transactors.md
View File

@@ -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)
## ヘッダファイル

19
@l10n/ja/translations.yaml
View File

@@ -602,25 +602,24 @@ Past Events: 過去のイベント
# community/ambassadors.page.tsx
Become an XRP Ledger Campus Ambassador: XRP Ledgerキャンパスアンバサダーになる
Join the Student Cohort: 学生コミュニティに参加
The XRPL Campus Ambassador program engages, supports, connects, and recognizes a group of student champions of the XRPL and empowers them to further advance engagement on the ledger.: XRPLキャンパスアンバサダープログラムは、XRPLの学生による代表者を参加させ、支援し、繋いで、表彰し、彼らがコミュニティ/エコシステムへの関与をさらに進めるように支援するものです。
# Apply for Fall 2023: 2023年秋の申し込み #old
Empowering Students: 学生を支援
XRPL Campus Ambassadors: XRPLキャンパスアンバサダー
Current Students: 現役学生
The XRPL Campus Ambassador program aims to elevate the impact of college students who are passionate about blockchain technology. In their role, Campus Ambassadors help educate other students about crypto and how to start building on the XRPL.: XRPLキャンパスアンバサダープログラムは、ブロックチェーン技術に情熱を持つ大学生の影響力を高めることを目指しています。彼らの役割として、キャンパスアンバサダーは他の学生に暗号通貨について教育し、XRPL上での開発を始める方法を教えます。
The XRPL Campus Ambassador program aims to elevate the impact of college students who are passionate about blockchain technology.: XRPLキャンパスアンバサダープログラムは、ブロックチェーン技術に情熱を持つ大学生の影響力を高めることを目指しています。
Apply for Fall 2024: 2024年秋の申し込み
Why become an XRPL Campus Ambassador?: XRPLキャンパスアンバサダーになる理由
Join a global cohort of students empowering others to build on the XRPL.: XRPLをベースに他の人に力を与える、世界的な学生グループに参加しましょう
Exclusive Opportunities: 特別な機会
Get access and invitations to Ambassador-only events, conferences, and opportunities: アンバサダー限定のイベント、カンファレンス、チャンスの情報を入手できます
Get access and invitations to Ambassador-only events and opportunities: アンバサダー限定のイベントや機会の情報を入手できます
Education: 学習
Tutorials and workshops from leading XRPL and blockchain developers: トップクラスのXRPLおよびブロックチェーン開発者によるチュートリアルとワークショップを提供します
Swag: グッズ
New XRPL swag for Ambassadors and swag to share with other students: アンバサダー用の特別なXRPLグッズと他の学生と共有できるグッズを提供します
Mentorship: メンター
Serve as an advocate and receive support from notable members of the community: アドボケートの役割を果たし、コミュニティの主要メンバーからのサポートが提供されます
Meet with and learn from influential builders and leaders across the XRPL community: XRPLコミュニティの主要なビルダーとリーダーとの会話を通じて、学ぶことができます
Career Acceleration: キャリア促進
Gain hands-on experience building communities and grow your professional network in the blockchain industry: ブロックチェーン業界におけるコミュニティ構築の経験を積み、プロフェッショナルなネットワークを広げることができます
Stipend: 奨学金
Receive a stipend to fund your ideas and initiatives that fuel XRPL growth on your campus: キャンパスでのXRPLの成長を促進するアイデアやイニシアチブの資金となる奨学金を受け取ることができます
Receive a stipend to fund your ideas and initiatives that fuel XRPL growth in your community: コミュニティでのXRPLの成長を促進するアイデアやイニシアチブの資金となる奨学金を受け取ることができます
Should You Apply?: 応募すべきでしょうか？
Eligibility for XRPL Campus Ambassadors: XRPLキャンパスアンバサダーの応募資格
Students currently enrolled in an undergraduate or postgraduate program at an accredited college or university are eligible to apply.: 現在、認定された大学の学部または大学院に在籍している学生が応募可能です。
@@ -633,7 +632,7 @@ Eager to learn more about technical blockchain topics and the XRPL: ブロック
Passionate: 情熱的
Passionate about increasing XRPL education and awareness through events, content, and classroom engagement: イベント、コンテンツ、授業への参加を通じて、XRPLの教育と認知度を高めることに情熱を持っている
Creative: クリエイティブ
Ability to think outside the box to grow the XRPL student community: 既成概念にとらわれず、XRPLの学生コミュニティを成長させる思考力がある
Ability to think outside the box and have an impact in the XRPL student community: 既成概念にとらわれず、XRPLの学生コミュニティに影響を与える思考力がある
Process to become a Campus Ambassador: キャンパスアンバサダー就任までの流れ
How it Works: 手続き
Apply now to become an XRPL Campus Ambassador.: XRPLキャンパスアンバサダーになりたい方は今すぐ応募しましょう。
@@ -647,8 +646,8 @@ Learn: 学習
Participate in personalized learning and training sessions for Ambassadors on the XRPL and blockchain technology.: XRPLおよびブロックチェーン技術に関するアンバサダー向けの個別学習およびトレーニングセッションへ参加しましょう。
Join a global cohort of Student Ambassadors: 学生アンバサダーのグローバルなコミュニティに参加する
Global Community: グローバルコミュニティ
Stay connected to the XRPL Campus Ambassadors: XRPLキャンパスアンバサダーとの繋がりを持つ
"To stay up-to-date on the latest activity, meetups, and events of the XRPL Campus Ambassadors be sure to follow these channels:": XRPL キャンパスアンバサダーの最新の活動、ミートアップ、イベントに関する最新情報を得るには、次のチャンネルをフォローしましょう。
Stay connected to the XRPL Community: XRPLコミュニティとの繋がりを持つ
"To stay up-to-date on the latest activity, meetups, and events of the XRPL Community be sure to follow these channels:": XRPLコミュニティの最新の活動、ミートアップ、イベントに関する最新情報を得るには、次のチャンネルをフォローしましょう。
MeetUp: ミートアップ
Attend an XRPL Meetup in your local area: 近隣のXRPLミートアップに参加しましょう
Dev.to Blog: Dev.to ブログ

17
@theme/components/Navbar/AlgoliaSearch.tsx Normal file
View File

@@ -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],
}}
/>
)
}

4
@theme/components/Navbar/Navbar.tsx
View File

@@ -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

15
_api-examples/ledger_index/jsonrpc-response.json Normal file
View File

@@ -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"
}
]
}

17
_api-examples/ledger_index/ws-response.json Normal file
View File

@@ -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"
}
]
}

37
blog/2024/lower-reserves-are-in-effect.md Normal file
View File

@@ -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.

1
blog/sidebars.yaml
View File

@@ -6,6 +6,7 @@
- group: '2024'
expanded: false
items:
- 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

1
community/ambassadors.page.tsx
View File

@@ -23,6 +23,7 @@ export default function Ambassadors() {
<img alt="background purple waves" src={require("../static/img/backgrounds/ambassador-purple.svg")} className="position-absolute" style={{top: 0, right: 0}} />
</div>
<section className="container-new py-26 text-lg-center">
{/* For translater: This section could change dynamically based on the time of year */}
<div className="p-0 col-lg-8 mx-lg-auto">
<div className="d-flex flex-column-reverse">
<h1 className="mb-0">{translate("Become an XRP Ledger Campus Ambassador")}</h1>

25
community/events.page.tsx
View File

@@ -15,6 +15,7 @@ const infoSession2 = require("../static/img/events/xrpl-builder-office-hours-02.
const infoSession3 = require("../static/img/events/xrpl-builder-office-hours-03.png");
const infoSession4 = require("../static/img/events/xrpl-builder-office-hours-04.png");
const decarb = require('../static/img/events/xrpl-decarb.png')
const townHall = require('../static/img/events/town-hall-meetup.png')
export const frontmatter = {
seo: {
title: "Events",
@@ -872,7 +873,7 @@ const events = [
link: "https://www.eventbrite.fr/e/xrpl-town-hall-meeting-tickets-959615815737",
location: "Virtual",
date: "September 16, 2024",
image: require('../static/img/events/town-hall-meetup.png'),
image: townHall,
end_date: "September 16, 2024",
},
{
@@ -1007,6 +1008,28 @@ const events = [
image: require('../static/img/events/new-york.jpeg'),
end_date: "November 19, 2024",
},
{
name: "XRPL Webinar - Crypto for Good Fund",
description:
"Join Mercy Corps Ventures, Ripple Impact and XRPL Commons for a webinar focused on supporting emerging market startups building on XRPL.",
type: "info",
link: "https://xrpl.at/XRPL-Webinar-CryptoForGoodFund",
location: "Virtual",
date: "December 3, 2024",
image: infoSession,
end_date: "December 3, 2024",
},
{
name: "XRPL Town Hall Meeting #2",
description:
"Join Us for the Second XRPL Town Hall Meeting! These recurring meeting are designed to bring our community together, provide updates, and offer a platform to address your most pressing questions.",
type: "info",
link: "https://xrpl.at/XRPL-TownHall-meeting2",
location: "Virtual",
date: "December 11, 2024",
image: townHall,
end_date: "December 11, 2024",
},
];

76
community/index.page.tsx
View File

@@ -1,4 +1,4 @@
import React, { useState } from "react";
import React, { useEffect, useState } from "react";
import { useThemeHooks } from "@redocly/theme/core/hooks";
import moment from "moment";
import { Link } from "@redocly/theme/components/Link/Link";
@@ -17,29 +17,9 @@ const hackathon = require("../static/img/events/Hackathons.png");
const conference = require("../static/img/events/Conference.png");
const zone = require("../static/img/events/XRPLZone.png");
const brazil = require("../static/img/events/event-meetup-brazil.png");
const korea = require("../static/img/events/SouthKoreaMeetup.png");
const infoSession2 = require("../static/img/events/xrpl-builder-office-hours-02.png");
const infoSession3 = require("../static/img/events/xrpl-builder-office-hours-03.png");
const infoSession4 = require("../static/img/events/xrpl-builder-office-hours-04.png");
const findNearestUpcomingEvent = (events) => {
let nearestEvent = null;
let nearestDateDiff = Infinity;
let index;
events.forEach((event, i) => {
const eventStartDate = moment(event.start_date, "MMMM DD, YYYY");
const currentDate = moment();
const diff = eventStartDate.diff(currentDate, "days");
if (diff >= 0 && diff < nearestDateDiff) {
nearestEvent = event;
nearestDateDiff = diff;
index = i
}
});
return { nearestEvent, nearestDateDiff, index };
};
const events = [
{
name: "New Horizon: Innovate Without Limits: New Horizons Await",
@@ -354,11 +334,46 @@ const events = [
end_date: "November 22, 2024",
},
];
const { nearestDateDiff, nearestEvent, index } = findNearestUpcomingEvent(events);
const findNearestUpcomingEvent = (events) => {
let nearestEvent = null;
let nearestDateDiff = Infinity;
let index = 0;
events.forEach((event, i) => {
const eventStartDate = moment(event.start_date, "MMMM DD, YYYY");
const currentDate = moment();
const diff = eventStartDate.diff(currentDate, "days");
if (diff >= 0 && diff < nearestDateDiff) {
nearestEvent = event;
nearestDateDiff = diff;
index = i;
}
});
return { nearestEvent, nearestDateDiff, index };
};
const XrplEventsAndCarouselSection = ({ events }) => {
const { useTranslate } = useThemeHooks();
const { translate } = useTranslate();
const [currentIndex, setCurrentIndex] = useState(index); // use nearest event's index as init state
// State variables for the nearest event
const [nearestEventInfo, setNearestEventInfo] = useState({
nearestEvent: null,
nearestDateDiff: null,
index: 0,
});
// State for the current index in the carousel
const [currentIndex, setCurrentIndex] = useState(0);
useEffect(() => {
const { nearestEvent, nearestDateDiff, index } = findNearestUpcomingEvent(events);
setNearestEventInfo({ nearestEvent, nearestDateDiff, index });
setCurrentIndex(index);
}, [events]);
const updateCarousel = () => {
const prevEvent = events[currentIndex - 1] || null;
const currentEvent = events[currentIndex];
@@ -373,17 +388,18 @@ const XrplEventsAndCarouselSection = ({ events }) => {
const handlePrev = () => {
if (currentIndex > 0) {
setCurrentIndex(currentIndex - 1);
setCurrentIndex((prevIndex) => prevIndex - 1);
}
};
const handleNext = () => {
if (currentIndex < events.length - 1) {
setCurrentIndex(currentIndex + 1);
setCurrentIndex((prevIndex) => prevIndex + 1);
}
};
const { prevEvent, currentEvent, nextEvent } = updateCarousel();
return (
<>
<section className="xrpl-events-section">
@@ -415,24 +431,24 @@ const XrplEventsAndCarouselSection = ({ events }) => {
{translate("View All Events")}
</Link>
</div>
{!!nearestEvent && (
{!!nearestEventInfo.nearestEvent && (
<div className="upcoming-event" id="upcoming-events-section">
<p className="upcoming-label">{translate("UPCOMING EVENT")}</p>
<div id="days-count" className="days-count">
{nearestDateDiff}
{nearestEventInfo.nearestDateDiff}
</div>
<div className="days-word">{translate("days")}</div>
<div className="num-separator"></div>
<h5 id="upcoming-event-name" className="event-name">
{translate(nearestEvent?.name)}
{translate(nearestEventInfo.nearestEvent?.name)}
</h5>
<p className="mb-2 event-details d-flex icon">
<span className="icon-location"></span>
<span id="upcoming-event-date">{nearestEvent?.date}</span>
<span id="upcoming-event-date">{nearestEventInfo.nearestEvent?.date}</span>
</p>
<p className="event-location d-flex icon">
<span className="icon-date" id="upcoming-event-location"></span>
<span id="location-tag">{nearestEvent?.location}</span>
<span id="location-tag">{nearestEventInfo.nearestEvent?.location}</span>
</p>
</div>
)}

13
community/report-a-scam.md
View File

@@ -11,21 +11,14 @@ If you think you've been scammed, make sure to collect as much information as yo
{% admonition type="warning" name="Caution" %}Please be aware that _no one_ can freeze accounts or revert transactions on the XRP Ledger. This is due to the decentralized design of the XRP Ledger blockchain.{% /admonition %}
1. Submit the scammer's wallet address to [Xrplorer's forensics team](https://xrplorer.com/forensics/submit).
1. Report your case to your local law enforcement. If the scammer is caught, you may be able to get your money back.
This helps to flag accounts used for illicit activity and include them in additional monitoring, auto-tracing, and warnings for other users, wallets, and exchanges.
2. Report your case to your local law enforcement. If the scammer is caught, you may be able to get your money back.
3. If the scammer sent XRP to an exchange, be sure to contact the exchange's support team. The exchange can freeze the scammer's account at the exchange. Here are support links for a few popular exchanges:
2. If the scammer sent XRP to an exchange, be sure to contact the exchange's support team. The exchange can freeze the scammer's account at the exchange. Here are support links for a few popular exchanges:
- [Binance](https://www.binance.com/en/support)
- [Coinbase](https://help.coinbase.com/)
- [Uphold](https://support.uphold.com/hc/en-us/requests/new)
- [Bitrue](https://www.bitrue.com/exchange-web/footer/contactus.html)
4. If the scammer exchanged XRP for another token on the XRP Ledger, contact the token's issuer. The issuer may be able to [freeze the scammer's trust line](../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md) to prevent the scammer from sending those tokens to others.
3. If the scammer exchanged XRP for another token on the XRP Ledger, contact the token's issuer. The issuer may be able to [freeze the scammer's trust line](../docs/tutorials/how-tos/use-tokens/freeze-a-trust-line.md) to prevent the scammer from sending those tokens to others.
For more details on reporting scammers, see [Xrplorer Forensics Help](https://xrplorer.com/forensics/help).
For help from the XRP Ledger community, you can also try the [XRPChat forum](https://xrpchat.com).

4
docs/concepts/accounts/deleting-accounts.md
View File

@@ -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.

2
docs/concepts/accounts/depositauth.md
View File

@@ -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][])_

2
docs/concepts/accounts/index.md
View File

@@ -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 %}

6
docs/concepts/accounts/reserves.md
View File

@@ -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

4
docs/concepts/accounts/tickets.md
View File

@@ -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.

32
docs/concepts/consensus-protocol/fee-voting.md
View File

@@ -1,6 +1,4 @@
---
html: fee-voting.html
parent: consensus.html
seo:
description: How validators vote on fees (transaction cost and reserve requirements).
labels:
@@ -9,9 +7,9 @@ labels:
---
# Fee Voting
Validators can vote for changes to basic [transaction cost](../transactions/transaction-cost.md) as well as [reserve requirements](../accounts/reserves.md). If the preferences in a validator's configuration are different than the network's current settings, the validator expresses its preferences to the network periodically. If a quorum of validators agrees on a change, they can apply a change that takes effect thereafter. Validators may do this for various reasons, especially to adjust to long-term changes in the value of XRP.
Fee voting is a system for adjusting the fees of using the XRP Ledger, specifically the base [transaction cost](../transactions/transaction-cost.md) and [reserve requirements](../accounts/reserves.md). The purpose of the fees is to protect the network from spam, so fee voting decisions must weigh competing priorities of making the network accessible to more users and use cases versus protecting the network from misuse or overuse. Changes must be made periodically to adjust to long-term changes in the value of XRP and the costs and capabilities of network nodes.
Operators of [`rippled` validators](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md) can set their preferences for the transaction cost and reserve requirements in the `[voting]` stanza of the `rippled.cfg` file.
[Validator](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md) operators can set their preferred fee settings in the `[voting]` stanza of the `rippled.cfg` file. Each validator periodically expresses its preferences to the network, about once every 15 minutes. The network automatically adjusts the fee settings to the median of trusted validators' preferences.
{% admonition type="warning" name="Caution" %}Insufficient requirements, if adopted by a consensus of trusted validators (>50%), could expose the XRP Ledger peer-to-peer network to denial-of-service attacks.{% /admonition %}
@@ -19,17 +17,30 @@ The parameters you can set are as follows:
| Parameter | Description | Recommended Value |
|-----------|-------------|-------------------|
| `reference_fee` | 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` | Minimum amount of XRP, in _drops_, that an account must have on reserve. This is the smallest amount that can be sent to fund a new account in the ledger. | `10000000` (10 XRP) |
| `owner_reserve` | How much more XRP, in _drops_, that an address must hold for _each_ object it owns in the ledger. | `2000000` (2 XRP) |
| `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. | `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
Fee preferences should be set carefully. Insufficient fees, if adopted by more than half of trusted validators, could expose the ledger to various denial-of-service attacks. More specifically:
- The reference transaction cost protects the network from excessive _processing and relaying_ of transactions. This is important because every server in the network independently verifies and processes every transaction, and those transactions need to be relayed to every server. If the reference transaction cost is too low, malicious users can overload the network by spamming it with too many transactions. This setting mostly protects servers' CPU and bandwidth usage.
- The reserve settings protect the network from excessive _data storage_. This is important because every server in the network needs a full copy of the most recent ledger state, including all accounts and other ledger entry types. Unused accounts and data cannot be automatically pruned, so the reserves provide an incentive for users to delete data they are not actively using. If the reserves are too low, malicious users can overload the network by creating too many ledger entries. These settings mostly protect servers' RAM and disk space.
Generally speaking, raising the reserve requirements is more disruptive than lowering them. When reserves go down, some users have access to money that was previous locked up; when reserves go up, some users no longer have enough money to send many types of transactions. To minimize disruption, it's generally recommended to be conservative about lowering reserves, instead of aggressively adjusting the settings to respond to volatility in the price of XRP.
## Voting Process
Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such that the `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` is equal to `0`.) In the ledger immediately before the flag ledger, each validator whose account reserve or transaction cost preferences are different than the current network setting distributes a "vote" message alongside its ledger validation, indicating the values that validator prefers.
Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such that the `ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256` is equal to `0`.) Since ledgers typically take 3-4 seconds to close, there is usually a new flag ledger every 15 minutes.
In the ledger immediately before the flag ledger, each validator whose account reserve or transaction cost preferences are different than the current network setting distributes a "vote" message alongside its ledger validation, indicating the values that validator prefers.
In the flag ledger itself, nothing happens, but validators receive and take note of the votes from other validators they trust.
After counting the votes of other validators, each validator attempts to compromise between its own preferences and the preferences of a majority of validators it trusts. (For example, if one validator wants to raise the minimum transaction cost from 10 to 100, but most validators only want to raise it from 10 to 20, the one validator settles on the change to raise the cost to 20. However, the one validator never settles on a value lower than 10 or higher than 100.) If a compromise is possible, the validator inserts a [SetFee pseudo-transaction](../../references/protocol/transactions/pseudo-transaction-types/setfee.md) into its proposal for the ledger following the flag ledger. Other validators who want the same change insert the same SetFee pseudo-transaction into their proposals for the same ledger. (Validators whose preferences match the existing network settings do nothing.) If a SetFee pseudo-transaction survives the consensus process to be included in a validated ledger, then the new transaction cost and reserve settings denoted by the SetFee pseudo-transaction take effect starting with the following ledger.
After counting the votes of other validators, each validator attempts to compromise between its own preferences and the preferences of a majority of validators it trusts (the members of its UNL) by taking the median vote for each setting. If the median is _between_ two votes, it chooses the option that is closer to the current setting. If any of the chosen settings are different than what is currently defined in the ledger, the validator inserts a [SetFee pseudo-transaction](../../references/protocol/transactions/pseudo-transaction-types/setfee.md) into its proposal for the ledger following the flag ledger. Other validators also insert a SetFee pseudo-transaction into their proposals based on their preferences and the votes in their UNLs. Validators whose preferences match the existing network settings do nothing. If any SetFee pseudo-transaction has a majority and survives the consensus process to be included in a validated ledger, then the new transaction cost and reserve settings take effect starting with the following ledger.
In short:
@@ -40,7 +51,7 @@ In short:
## Maximum Fee Values
The maximum possible values for the fees are limited by the internal data types stored in the [FeeSettings ledger object](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md). These values are as follows:
Before the [XRPFees amendment][], the maximum possible values for the fees was limited based on the internal data type of the legacy [FeeSettings ledger entry](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md) format. These values are as follows:
| Parameter | Maximum Value (drops) | Maximum Value (XRP)
|-----------|-----------------------|----|
@@ -48,6 +59,7 @@ The maximum possible values for the fees are limited by the internal data types
| `account_reserve` | 2<sup>32</sup> drops | Approximately 4294 XRP |
| `owner_reserve` | 2<sup>32</sup> drops | Approximately 4294 XRP |
On Mainnet and any other networks with the XRPFees amendment enabled, all three fees can now be set to any valid amount of XRP.
## See Also

2
docs/concepts/tokens/fungible-tokens/authorized-trust-lines.md
View File

@@ -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

38
docs/concepts/tokens/nfts/reserve-requirements.md
View File

@@ -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.
@@ -29,14 +29,16 @@ The following table provides examples of how much the total owner reserve might
| 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).

2
docs/concepts/tokens/nfts/trading.md
View File

@@ -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).

2
docs/concepts/transactions/transaction-queue.md
View File

@@ -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.

BIN
docs/img/amm-clob-diagram.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 55 KiB

After

Width:  |  Height:  |  Size: 61 KiB

9
docs/references/http-websocket-apis/public-api-methods/clio-methods/index.md Normal file
View File

@@ -0,0 +1,9 @@
---
metadata:
indexPage: true
---
# Clio Methods
These API methods are provided only by the Clio server, not `rippled`.
{% child-pages /%}

88
docs/references/http-websocket-apis/public-api-methods/clio-methods/ledger_index.md Normal file
View File

@@ -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" /%}

12
docs/references/http-websocket-apis/public-api-methods/clio-server/index.md
View File

@@ -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 /%}

12
docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md
View File

@@ -92,14 +92,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.

23
docs/references/protocol/transactions/pseudo-transaction-types/enableamendment.md
View File

@@ -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 |
|:-----------------|:----------|:------------------|:--------------------------|

56
docs/references/protocol/transactions/pseudo-transaction-types/setfee.md
View File

@@ -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" /%}

1
docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
View File

@@ -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][].)_

20
docs/references/protocol/transactions/types/accountdelete.md
View File

@@ -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" /%}

4
docs/references/protocol/transactions/types/accountset.md
View File

@@ -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).

2
docs/references/protocol/transactions/types/ammbid.md
View File

@@ -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][])_

4
docs/references/protocol/transactions/types/ammcreate.md
View File

@@ -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

2
docs/references/protocol/transactions/types/ammdelete.md
View File

@@ -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][])_

2
docs/references/protocol/transactions/types/ammdeposit.md
View File

@@ -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][])_

2
docs/references/protocol/transactions/types/ammvote.md
View File

@@ -7,7 +7,7 @@ labels:
- AMM
---
# AMMVote
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMVote.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMVote.cpp "Source")
_(Added by the [AMM amendment][])_

2
docs/references/protocol/transactions/types/ammwithdraw.md
View File

@@ -7,7 +7,7 @@ labels:
- AMM
---
# AMMWithdraw
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/AMMWithdraw.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMWithdraw.cpp "Source")
_(Added by the [AMM amendment][])_

2
docs/references/protocol/transactions/types/checkcancel.md
View File

@@ -7,7 +7,7 @@ labels:
- Checks
---
# CheckCancel
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CancelCheck.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CancelCheck.cpp "Source")
_(Added by the [Checks amendment][].)_

2
docs/references/protocol/transactions/types/checkcash.md
View File

@@ -7,7 +7,7 @@ labels:
- Checks
---
# CheckCash
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CashCheck.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CashCheck.cpp "Source")
_(Added by the [Checks amendment][].)_

2
docs/references/protocol/transactions/types/checkcreate.md
View File

@@ -7,7 +7,7 @@ labels:
- Checks
---
# CheckCreate
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/CreateCheck.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/CreateCheck.cpp "Source")
_(Added by the [Checks amendment][].)_

2
docs/references/protocol/transactions/types/clawback.md
View File

@@ -8,7 +8,7 @@ labels:
---
# Clawback
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Clawback.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Clawback.cpp "Source")
{% partial file="/docs/_snippets/clawback-disclaimer.md" /%}

2
docs/references/protocol/transactions/types/depositpreauth.md
View File

@@ -7,7 +7,7 @@ labels:
- Security
---
# DepositPreauth
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/DepositPreauth.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DepositPreauth.cpp "Source")
_Added by the [DepositPreauth amendment][]._

2
docs/references/protocol/transactions/types/diddelete.md
View File

@@ -8,7 +8,7 @@ labels:
---
# DIDDelete
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/DID.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DID.cpp "Source")
_(Requires the [DID amendment][])_

2
docs/references/protocol/transactions/types/didset.md
View File

@@ -8,7 +8,7 @@ labels:
---
# DIDSet
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/DID.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DID.cpp "Source")
_(Requires the [DID amendment][])_

2
docs/references/protocol/transactions/types/escrowcancel.md
View File

@@ -8,7 +8,7 @@ labels:
---
# EscrowCancel
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Escrow.cpp "Source")
_Added by the [Escrow amendment][]._

2
docs/references/protocol/transactions/types/escrowcreate.md
View File

@@ -8,7 +8,7 @@ labels:
---
# EscrowCreate
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Escrow.cpp "Source")
_Added by the [Escrow amendment][]._

2
docs/references/protocol/transactions/types/escrowfinish.md
View File

@@ -8,7 +8,7 @@ labels:
---
# EscrowFinish
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Escrow.cpp "Source")
_Added by the [Escrow amendment][]._

2
docs/references/protocol/transactions/types/nftokenacceptoffer.md
View File

@@ -7,7 +7,7 @@ labels:
- NFTs, Non-fungible Tokens
---
# NFTokenAcceptOffer
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenAcceptOffer.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenAcceptOffer.cpp "Source")
The `NFTokenAcceptOffer` transaction is used to accept offers to `buy` or `sell` an `NFToken`. It can either:

2
docs/references/protocol/transactions/types/nftokenburn.md
View File

@@ -7,7 +7,7 @@ labels:
- Non-fungible Tokens, NFTs
---
# NFTokenBurn
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenBurn.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenBurn.cpp "Source")
The `NFTokenBurn` transaction is used to remove a `NFToken` object from the `NFTokenPage` in which it is being held, effectively removing the token from the ledger (_burning_ it).

2
docs/references/protocol/transactions/types/nftokencanceloffer.md
View File

@@ -7,7 +7,7 @@ labels:
- NFTs, Non-fungible Tokens
---
# NFTokenCancelOffer
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenCancelOffer.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenCancelOffer.cpp "Source")
The `NFTokenCancelOffer` transaction can be used to cancel existing token offers created using `NFTokenCreateOffer`.

2
docs/references/protocol/transactions/types/nftokencreateoffer.md
View File

@@ -7,7 +7,7 @@ labels:
- Non-fungible Tokens, NFTs
---
# NFTokenCreateOffer
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenCreateOffer.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenCreateOffer.cpp "Source")
Creates either a new _Sell_ offer for an `NFToken` owned by the account executing the transaction, or a new _Buy_ offer for an `NFToken` owned by another account.

7
docs/references/protocol/transactions/types/nftokenmint.md
View File

@@ -7,7 +7,7 @@ labels:
- Non-fungible Tokens, NFTs
---
# NFTokenMint
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenMint.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenMint.cpp "Source")
The `NFTokenMint` transaction creates a non-fungible token and adds it to the relevant [NFTokenPage object][] of the `NFTokenMinter` as an [NFToken][] object. This transaction is the only opportunity the `NFTokenMinter` has to specify any token fields that are defined as immutable (for example, the `TokenFlags`).
@@ -48,8 +48,9 @@ _(Added by the [NonFungibleTokensV1_1 amendment][].)_
| `Issuer` | String | AccountID | _(Optional)_ The issuer of the token, if the sender of the account is issuing it on behalf of another account. This field must be omitted if the account sending the transaction is the issuer of the `NFToken`. If provided, the issuer's [AccountRoot object][] must have the `NFTokenMinter` field set to the sender of this transaction (this transaction's `Account` field). |
| `TransferFee` | Number | UInt16 | _(Optional)_ The value specifies the fee charged by the issuer for secondary sales of the `NFToken`, if such sales are allowed. Valid values for this field are between 0 and 50000 inclusive, allowing transfer rates of between 0.00% and 50.00% in increments of 0.001. If this field is provided, the transaction MUST have the [`tfTransferable` flag](#nftokenmint-flags) enabled. |
| `URI` | String | Blob | _(Optional)_ Up to 256 bytes of arbitrary data. In JSON, this should be encoded as a string of hexadecimal. You can use the [`xrpl.convertStringToHex`](https://js.xrpl.org/modules.html#convertStringToHex) utility to convert a URI to its hexadecimal equivalent. This is intended to be a URI that points to the data or metadata associated with the NFT. The contents could decode to an HTTP or HTTPS URL, an IPFS URI, a magnet link, immediate data encoded as an [RFC 2379 "data" URL](https://datatracker.ietf.org/doc/html/rfc2397), or even an issuer-specific encoding. The URI is NOT checked for validity. |
| `Amount` | [Currency Amount][] | Amount | _(Optional)_ Indicates the amount expected or offered for the corresponding `NFToken`. The amount must be non-zero, except where this is an offer to sell and the asset is XRP; then, it is legal to specify an amount of zero, which means that the current owner of the token is giving it away, gratis, either to anyone at all, or to the account identified by the `Destination` field. |
| `Expiration` | Number | UInt32 | _(Optional)_ Time after which the offer is no longer active, in [seconds since the Ripple Epoch][]. Results in an error if the `Amount` field is not specified. |
| `Destination` | String | AccountID | _(Optional)_ If present, indicates that this offer may only be accepted by the specified account. Attempts by other accounts to accept this offer MUST fail. Results in an error if the `Amount` field is not specified. |
## NFTokenMint Flags

Some files were not shown because too many files have changed in this diff Show More