Merge pull request #2894 from XRPLF/reserves_update

Update reserves info
This commit is contained in:
Rome Reginelli
2024-12-12 15:44:39 -08:00
committed by GitHub
37 changed files with 145 additions and 97 deletions

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.

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

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

View File

@@ -27,12 +27,12 @@ The reserve requirement has two parts:
The current reserve requirements on Mainnet are:
- Base reserve: **1 XRP**
- Owner reserve: **0.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

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.

View File

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

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

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.
@@ -27,16 +27,18 @@ Therefore, you can estimate the reserve requirements for minting or owning _N_ N
The following table provides examples of how much the total owner reserve might be, depending on the number of NFTs owned and the number of pages holding them.
| NFTs Owned | Best Case | Typical Case | Worst Case |
| NFTs Owned | Best Case | Typical Case | Worst Case |
|:------------|:----------|:-------------|:-----------|
| 32 or fewer | 2 XRP | 2 XRP | 2 XRP |
| 50 | 4 XRP | 6 XRP | 8 XRP |
| 200 | 14 XRP | 18 XRP | 26 XRP |
| 1000 | 64 XRP | 84 XRP | 126 XRP |
| 32 or fewer | 0.2 XRP | 0.2 XRP | 0.2 XRP |
| 50 | 0.4 XRP | 0.6 XRP | 0.8 XRP |
| 200 | 1.4 XRP | 1.8 XRP | 2.6 XRP |
| 1000 | 6.4 XRP | 8.4 XRP | 12.6 XRP |
<!-- RESERVES_REMINDER: update math if reserves change -->
## `NFTokenOffer` Reserve
Each `NFTokenOffer` object costs the account placing the offer one incremental reserve. As of this writing, the incremental reserve is 2 XRP. The reserve can be recovered by cancelling the offer. The reserve is also recovered if the offer is accepted, which removes the offer from the XRP Ledger.
Each `NFTokenOffer` object costs the account placing the offer one incremental reserve. As of this writing, the incremental reserve is 0.2 XRP. The reserve can be recovered by cancelling the offer. The reserve is also recovered if the offer is accepted, which removes the offer from the XRP Ledger.
{% admonition type="success" name="Tip" %}After you sell an NFT, as a courtesy, cancel any stale `NFTokenOffer` objects on behalf of your bidders to give them back their reserve. You can do this with [NFTokenCancelOffer](../../../references/protocol/transactions/types/nftokencanceloffer.md) transactions.{% /admonition %}
@@ -44,26 +46,24 @@ Each `NFTokenOffer` object costs the account placing the offer one incremental r
When minting, holding, and offering to buy and sell NFTs, the reserve requirements can add up quickly. This can result in your account going below the reserve requirement during a transaction. Going below the requirement can limit your ability to trade on the XRPL. See [Going Below the Reserve Requirement](../../accounts/reserves.md#going-below-the-reserve-requirement).
If you create a new account, mint an NFT, and create an `NFTokenSellOffer` on the XRP Ledger, that requires a minimum reserve of 14 XRP.
If you create a new account, mint an NFT, and create an `NFTokenSellOffer` on the XRP Ledger, that requires a minimum reserve of 1.4 XRP.
| Reserve Type | Amount |
|:--------------------|--------:|
| Base | 10 XRP |
| NFToken Page | 2 XRP |
| NFToken Offers | 2 XRP |
| Total | 14 XRP |
| | |
| Base | 1 XRP |
| NFToken Page | 0.2 XRP |
| NFToken Offers | 0.2 XRP |
| Total | 1.4 XRP |
{% admonition type="info" name="Note" %}While not a reserve requirement, keep in mind that you would want to have at least 1 XRP above your reserves to cover the trivial fee for each transaction in the mint and sell process (typically 12 drops, or .000012 XRP).{% /admonition %}
If you were to mint 200 NFTs and create an `NFTokenSellOffer`for each, that would require as much as 436 XRP held in reserve.
If you were to mint 200 NFTs and create an `NFTokenSellOffer`for each, that would require as much as 43.6 XRP held in reserve.
| Reserve Type | Amount |
|:--------------------|--------:|
| Base | 10 XRP |
| NFToken Pages | 26 XRP |
| NFToken Offers | 400 XRP |
| Total | 436 XRP |
| | |
| Base | 1 XRP |
| NFToken Pages | 2.6 XRP |
| NFToken Offers | 40 XRP |
| Total | 43.6 XRP |
If the required reserves exceed the amount you are comfortable setting aside, consider using the mint-on-demand model to reduce the number of NFTs and offers you hold at any one time. For details, see [Batch Minting](batch-minting.md).

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

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.

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.

View File

@@ -40,7 +40,7 @@ An AccountDelete transaction deletes an [account](../../ledger-data/ledger-entry
## 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.

View File

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

View File

@@ -17,7 +17,7 @@ This tutorial demonstrates how to enable multi-signing for an address.
- You must have a funded XRP Ledger [address](../../../concepts/accounts/index.md) with enough spare XRP to send transactions and meet the [reserve requirement](../../../concepts/accounts/reserves.md) of a new signer list.
- With the [MultiSignReserve amendment][] enabled, multi-signing requires 2 XRP for the account reserve, regardless of the number of signers and signatures you use. (The MultiSignReserve amendment has been enabled in the production XRP Ledger since **2019-04-07**.)
- With the [MultiSignReserve amendment][] enabled, multi-signing requires {% $env.PUBLIC_OWNER_RESERVE %} for the account reserve, regardless of the number of signers and signatures you use. (The MultiSignReserve amendment has been enabled in the production XRP Ledger since **2019-04-07**.)
- If you are on a test network that does not have the [MultiSignReserve amendment][] enabled, multi-signing requires more than the usual amount of XRP for the [account reserve](../../../concepts/accounts/reserves.md), increasing with the number of signers in the list.

View File

@@ -244,7 +244,7 @@ If you see any other result, you should check the following:
- Are you using the correct addresses for the sender and destination?
- Did you forget any other fields of the transaction, skip any steps, or make any other typos?
- Do you have enough Test XRP to send the transaction? The amount of XRP you can send is limited by the [reserve requirement](../../concepts/accounts/reserves.md), which is currently 10 XRP with an additional 2 XRP for each "object" you own in the ledger. (If you generated a new address with the Testnet Faucet, you don't own any objects.)
- Do you have enough Test XRP to send the transaction? The amount of XRP you can send is limited by the [reserve requirement](../../concepts/accounts/reserves.md), which is currently {% $env.PUBLIC_BASE_RESERVE %} with an additional {% $env.PUBLIC_OWNER_RESERVE %} for each "object" you own in the ledger. (If you generated a new address with the Testnet Faucet, you don't own any objects.)
- Are you connected to a server on the test network?
See the full list of [transaction results](../../references/protocol/transactions/transaction-results/index.md) for more possibilities.

View File

@@ -67,7 +67,7 @@ Along these lines, there's a good chance that you are following industry best pr
- The payer exchange must have a funded XRP Ledger account to be used to send XRP to the payee exchange.
```
Aside from the [base reserve](../../../../concepts/accounts/reserves.md) (10 XRP) and the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves) of a payment channel (2 XRP), the account must also be able to set aside enough XRP in the payment channel to cover the intended number of transactions.
Aside from the [base reserve](../../../../concepts/accounts/reserves.md) ({% $env.PUBLIC_BASE_RESERVE %}) and the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves) of a payment channel ({% $env.PUBLIC_OWNER_RESERVE %}), the account must also be able to set aside enough XRP in the payment channel to cover the intended number of transactions.
The payer exchange can always top-off the channel using the [PaymentChannelFund](../../../../references/protocol/transactions/types/paymentchannelfund.md) transaction if it runs out of XRP. However, topping-off requires an actual on-ledger transaction and confirmation, so it could take 4-5 seconds of processing time and ~10 drops of XRP to complete the top-off transaction. The more XRP the payer exchange pre-funds, the less often they need to top-off, so they can save some time and money by pre-funding more XRP.
@@ -81,7 +81,7 @@ Along these lines, there's a good chance that you are following industry best pr
- The payee exchange must have a funded XRP Ledger account to be used to redeem (receive) XRP sent by the payer exchange.
```
The account needs at least 11 XRP, which provides the 10 XRP [base reserve](../../../../concepts/accounts/reserves.md), plus enough to pay the transaction costs of redeeming claims, which are trivial. For example, you could redeem thousands of claims for less than 1 XRP in total.
The account needs at least the {% $env.PUBLIC_BASE_RESERVE %} [base reserve](../../../../concepts/accounts/reserves.md), plus enough to pay the transaction costs of redeeming claims, which are trivial. For example, you could redeem thousands of claims for less than 1 XRP in total.
```
[Fund XRP Ledger accounts with enough XRP >](../../../../concepts/accounts/index.md)

View File

@@ -141,7 +141,7 @@ If the AMM does already exist, you should double-check that you specified the ri
Creating an AMM has a special [transaction cost][] to prevent spam: since it creates objects in the ledger that no one owns, you must burn at least one [owner reserve increment](../../../concepts/accounts/reserves.md) of XRP to send the AMMCreate transaction. The exact value can change due to [fee voting](https://xrpl.org/fee-voting.html), so you should look up the current incremental reserve value using the [server_state method][].
It is also a good practice to display this value and give a human operator a chance to stop before you send the transaction. Burning an owner reserve is typically a much higher cost than sending a normal transaction, so you don't want it to be a surprise. (Currently, on both Mainnet and Devnet, the cost of sending a typical transaction is 0.000010 XRP but the cost of AMMCreate is 2 XRP.)
It is also a good practice to display this value and give a human operator a chance to stop before you send the transaction. Burning an owner reserve is typically a much higher cost than sending a normal transaction, so you don't want it to be a surprise. (Currently, on both Mainnet and Devnet, the cost of sending a typical transaction is 0.000010 XRP but the cost of AMMCreate is {% $env.PUBLIC_OWNER_RESERVE %}.)
{% tabs %}

View File

@@ -430,7 +430,7 @@ You can now use your wallet to send XRP! You can even fund an entirely new accou
3. Open your wallet app and provide a **Secret** (seed) value from an already-funded address, such as one you got from the [Testnet Faucet](/resources/dev-tools/xrp-faucets).
4. Send at least the [base reserve](../../../concepts/accounts/reserves.md) (currently 10 XRP) to the brand-new classic address you generated in the Python interpreter.
4. Send at least the [base reserve](../../../concepts/accounts/reserves.md) (currently {% $env.PUBLIC_BASE_RESERVE %}) to the brand-new classic address you generated in the Python interpreter.
5. Wait for the transaction to be confirmed, then close your wallet app.

View File

@@ -55,11 +55,11 @@ You can act as a broker, connecting sellers with bidders, completing the transfe
### Reserve requirements
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of 2 XRP. A NFToken page can store 16-32 NFTs.
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}. A NFToken page can store 16-32 NFTs.
![Reserves](/docs/img/uc-nft-reserves.png)
Each `NFTokenOffer` object requires a reserve of 2 XRP.
Each `NFTokenOffer` object requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}.
When you post the `NFTokenOffer` or sell the NFT, there are trivial transfer fees (roughly 6000 drops, or .006 XRP). When you are selling at a high volume, the trivial amounts can add up quickly, and need to be considered as part of your cost of doing business.

View File

@@ -49,9 +49,9 @@ You can sell your NFTs in an auction format. See [Running an NFT Auction](../../
### Reserve requirements
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of 2 XRP. A NFToken page can store 16-32 NFTs.
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}. A NFToken page can store 16-32 NFTs.
Each `NFTokenOffer` object requires a reserve of 2 XRP.
Each `NFTokenOffer` object requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}.
![Reserves](/docs/img/uc-nft-reserves.png)

View File

@@ -70,7 +70,7 @@ Once the authorized minter has finished creating NFTs for you, you can revoke th
See [Authorized Minter](../../concepts/tokens/nfts/authorizing-another-minter.md).
Minted NFTs are listed on a `NFTokenPage`. There is a reserve requirement of 2 XRP for every `NFTokenPage` on your account. See [NFT Reserve Requirements](../../concepts/tokens/nfts/reserve-requirements.md).
Minted NFTs are listed on a `NFTokenPage`. There is a reserve requirement of {% $env.PUBLIC_OWNER_RESERVE %} for every `NFTokenPage` on your account. See [NFT Reserve Requirements](../../concepts/tokens/nfts/reserve-requirements.md).
Each `NFTokenPage` holds 16-32 NFTs. Minting a large number of NFTs can tie up a great deal of your XRP. You can keep your XRP liquid by minting on demand (or _lazy minting_). For details of different approaches, see [Batch minting](../../concepts/tokens/nfts/batch-minting.md).
@@ -79,7 +79,7 @@ Each `NFTokenPage` holds 16-32 NFTs. Minting a large number of NFTs can tie up a
Set up a new wallet. See [Xaman](https://xaman.app/).
When you set up your account, keep in mind that there is a base reserve requirement of 10 XRP. See [Reserves](../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve).
When you set up your account, keep in mind that there is a base reserve requirement of {% $env.PUBLIC_BASE_RESERVE %}. See [Reserves](../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve).
### Transferring NFTs
@@ -93,9 +93,9 @@ You can act as a broker, connecting sellers with bidders, completing the transfe
#### Reserve requirements
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of 2 XRP. A NFToken page can store 16-32 NFTs.
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}. A NFToken page can store 16-32 NFTs.
Each `NFTokenOffer` object requires a reserve of 2 XRP.
Each `NFTokenOffer` object requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}.
![Reserves](/docs/img/uc-nft-reserves.png)

View File

@@ -43,11 +43,11 @@ You can act as a broker, connecting sellers with bidders, completing the transfe
### Reserve requirements
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of 2 XRP. A NFToken page can store 16-32 NFTs.
There are several XRP reserve requirements when you mint NFTs for sale. Each NFToken page requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}. A NFToken page can store 16-32 NFTs.
![Reserves](/docs/img/uc-nft-reserves.png)
Each `NFTokenOffer` object requires a reserve of 2 XRP.
Each `NFTokenOffer` object requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}.
When you post the `NFTokenOffer` or sell the NFT, there are trivial transfer fees (roughly 6000 drops, or .006 XRP). When you are selling at a high volume, the trivial amounts can add up quickly, and need to be considered as part of your cost of doing business.