mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-06 17:27:57 +00:00
Migrate old callout syntax
This commit is contained in:
@@ -12,7 +12,7 @@ targets:
|
||||
|
||||
The XRP Ledger has possibly the world's oldest _decentralized exchange_ (sometimes abbreviated "DEX"), operating continuously since the XRP Ledger's launch in 2012. The exchange allows users to buy and sell [tokens](../index.md) for XRP or other tokens, with minimal [fees](../../transactions/fees.md) charged to the network itself (not paid out to any party).
|
||||
|
||||
**Caution:** Anyone can [issue a token](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) with any currency code or ticker symbol they want and sell it in the decentralized exchange. Always perform due diligence before buying a token, and pay attention to the issuer. Otherwise, you might give up something of value and receive worthless tokens in exchange.
|
||||
{% admonition type="warning" name="Caution" %}Anyone can [issue a token](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) with any currency code or ticker symbol they want and sell it in the decentralized exchange. Always perform due diligence before buying a token, and pay attention to the issuer. Otherwise, you might give up something of value and receive worthless tokens in exchange.{% /admonition %}
|
||||
|
||||
## Structure
|
||||
|
||||
@@ -42,7 +42,7 @@ The above diagram shows an example trade in the decentralized exchange. In this
|
||||
|
||||
Later transactions, including ones executed immediately after Tran's in the _same_ ledger, use the updated order books for their trades, so they can consume part or all of Tran's Offer until it's fully filled or Tran cancels it.
|
||||
|
||||
**Note:** The canonical order transactions execute in when a ledger is closed and validated is not the same as the order those transactions were sent. When multiple transactions affect the same order book in the same ledger, the final results of those transactions may be very different than the tentative results calculated at the time of transaction submission. For more details on when transactions' results are or are not final, see [Finality of Results](../../transactions/finality-of-results/index.md).
|
||||
{% admonition type="info" name="Note" %}The canonical order transactions execute in when a ledger is closed and validated is not the same as the order those transactions were sent. When multiple transactions affect the same order book in the same ledger, the final results of those transactions may be very different than the tentative results calculated at the time of transaction submission. For more details on when transactions' results are or are not final, see [Finality of Results](../../transactions/finality-of-results/index.md).{% /admonition %}
|
||||
|
||||
|
||||
## Limitations
|
||||
|
||||
@@ -96,7 +96,7 @@ Expiration times are specified down to the second, but the exact, real-world tim
|
||||
|
||||
This is a consequence of how the network reaches agreement. For the entire peer-to-peer network to reach a consensus, all servers must agree which Offers are expired when executing transactions. Individual servers may have slight differences in their internal clock settings, so they might not reach the same conclusions about which Offers were expired if they each used the "current" time. The close time of a ledger is not known until after the transactions in that ledger have been executed, so servers use the official close time of the _previous_ ledger instead. The [close times of ledgers are rounded](../../ledgers/ledger-close-times.md), which further increases the potential difference between real-world time and the time used to determine if an Offer is expired.
|
||||
|
||||
**Note:** Expired Offers remain in the ledger data until a transaction removes them. Until then, they can continue to appear in data retrieved from the API (for example, using the [ledger_entry method][]). Transactions automatically delete any expired and unfunded Offers they find, usually while executing Offers or cross-currency payments that would have matched or canceled them. The owner reserve associated with an Offer is only made available again when the Offer is actually deleted.
|
||||
{% admonition type="info" name="Note" %}Expired Offers remain in the ledger data until a transaction removes them. Until then, they can continue to appear in data retrieved from the API (for example, using the [ledger_entry method][]). Transactions automatically delete any expired and unfunded Offers they find, usually while executing Offers or cross-currency payments that would have matched or canceled them. The owner reserve associated with an Offer is only made available again when the Offer is actually deleted.{% /admonition %}
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
@@ -17,7 +17,7 @@ You can authorize a trust line by sending a [TrustSet transaction][] from your i
|
||||
|
||||
The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address.
|
||||
|
||||
**Caution:** You can only enable Require Auth if your account has no trust lines and no Offers in the XRP Ledger, so you must decide whether or not to use it _before_ you start issuing tokens.
|
||||
{% admonition type="warning" name="Caution" %}You can only enable Require Auth if your account has no trust lines and no Offers in the XRP Ledger, so you must decide whether or not to use it _before_ you start issuing tokens.{% /admonition %}
|
||||
|
||||
## Reserves
|
||||
|
||||
@@ -32,7 +32,7 @@ With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process
|
||||
3. The customer sends a [TrustSet transaction][] to create a trust line to the issuer's address, with a positive limit.
|
||||
4. The issuer sends a TrustSet transaction to authorize the customer's trust line.
|
||||
|
||||
**Tip:** The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line.
|
||||
{% admonition type="success" name="Tip" %}The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line.{% /admonition %}
|
||||
|
||||
## As a Precaution
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ For regulatory purposes, some issuers need the ability to recover tokens after t
|
||||
|
||||
Issuers can gain the ability to claw back their tokens by enabling the **Allow Clawback** flag on their issuing account. This flag cannot be enabled if the issuer has already issued tokens.
|
||||
|
||||
**Note:** You can only claw back issued tokens created by your account. You cannot claw back XRP in this way.
|
||||
{% admonition type="info" name="Note" %}You can only claw back issued tokens created by your account. You cannot claw back XRP in this way.{% /admonition %}
|
||||
|
||||
Clawback is disabled by default. To use clawback, you must send an [AccountSet transaction][] to enable the **Allow Trust Line Clawback** setting. **An issuer with any existing tokens cannot enable Clawback.** You can only enable **Allow Trust Line Clawback** if you have a completely empty owner directory, meaning you must do so before you set up any trust lines, offers, escrows, payment channels, checks, or signer lists.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ status: removed
|
||||
---
|
||||
# Demurrage
|
||||
|
||||
**Warning:** Demurrage is a deprecated feature with no ongoing support. This page describes historical behavior of older versions of XRP Ledger software.
|
||||
{% admonition type="danger" name="Warning" %}Demurrage is a deprecated feature with no ongoing support. This page describes historical behavior of older versions of XRP Ledger software.{% /admonition %}
|
||||
|
||||
[Demurrage](http://en.wikipedia.org/wiki/Demurrage_%28currency%29) is a negative interest rate on assets held that represents the cost of holding those assets. To represent the demurrage on a token in the XRP Ledger, you can track it using a custom [currency code](../../../references/protocol/data-types/currency-formats.md#currency-codes) that indicates the demurrage rate. This effectively creates separate versions of the token for each varying amount of demurrage. Client applications can support this by representing the demurraging currency code with an annual percentage rate alongside the currency code. For example: "XAU (-0.5%pa)".
|
||||
|
||||
@@ -15,7 +15,7 @@ status: removed
|
||||
|
||||
Rather than continuously update all amounts in the XRP Ledger, this approach divides amounts of interest-bearing or demurraging tokens into two types of amount: "ledger values" recorded in the XRP Ledger, and "display values" shown to people. The "ledger values" represent the value of the currency at a fixed point, namely the "Ripple Epoch" of midnight January 1, 2000. The "display values" represent the amount at a later point in time (usually the current time) after calculating continuous interest or demurrage from the Ripple Epoch until that time.
|
||||
|
||||
**Tip:** You can think of demurrage as similar to inflation, where the value of all assets affected by it decreases over time, but the ledger always holds amounts in year-2000 values. This does not show actual real-world inflation; demurrage is more like hypothetical inflation at a constant rate.
|
||||
{% admonition type="success" name="Tip" %}You can think of demurrage as similar to inflation, where the value of all assets affected by it decreases over time, but the ledger always holds amounts in year-2000 values. This does not show actual real-world inflation; demurrage is more like hypothetical inflation at a constant rate.{% /admonition %}
|
||||
|
||||
Thus, client software must apply two conversions:
|
||||
|
||||
@@ -69,7 +69,7 @@ To calculate an e-folding time for a given rate of annual percent interest:
|
||||
3. Take the natural log of that number. For example, **ln(0.995) = -0.005012541823544286**. (This number is positive if the initial interest rate was positive, and negative if the interest rate was negative.)
|
||||
4. Take the number of seconds in one year (31536000) and divide by the natural log result from the previous step. For example, **31536000 ÷ -0.005012541823544286 = -6291418827.045599**. This result is the e-folding time in seconds.
|
||||
|
||||
**Note:** By convention, the XRP Ledger's interest/demurrage rules use a fixed number of seconds per year (31536000), which is not adjusted for leap days or leap seconds.
|
||||
{% admonition type="info" name="Note" %}By convention, the XRP Ledger's interest/demurrage rules use a fixed number of seconds per year (31536000), which is not adjusted for leap days or leap seconds.{% /admonition %}
|
||||
|
||||
## Client Support
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Issuers can freeze the tokens they issue in the XRP Ledger. **This does not appl
|
||||
|
||||
In certain cases, to meet regulatory requirements, or while investigating suspicious activity, an exchange or gateway may want to freeze token balances.
|
||||
|
||||
**Tip:** No one can freeze XRP in the XRP Ledger. However, custodial exchanges can always freeze the funds they custody at their own discretion. For more details, see [Common Misunderstandings about Freezes](common-misconceptions-about-freezes.md).
|
||||
{% admonition type="success" name="Tip" %}No one can freeze XRP in the XRP Ledger. However, custodial exchanges can always freeze the funds they custody at their own discretion. For more details, see [Common Misunderstandings about Freezes](common-misconceptions-about-freezes.md).{% /admonition %}
|
||||
|
||||
There are three settings related to freezes:
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ The `rippled` API has two methods that can be used for pathfinding. The [ripple_
|
||||
|
||||
You can have `rippled` automatically fill in paths when you sign it, by including the `build_path` field in a request to the [sign method][] or [`submit` command (sign-and-submit mode)](../../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#sign-and-submit-mode). However, we recommend pathfinding separately and confirming the results before signing, to avoid surprises.
|
||||
|
||||
**Caution:** Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit. The actual cost to execute a payment along a path can change between submission and transaction execution.
|
||||
{% admonition type="warning" name="Caution" %}Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit. The actual cost to execute a payment along a path can change between submission and transaction execution.{% /admonition %}
|
||||
|
||||
Finding paths is a very challenging problem that changes slightly every few seconds as new ledgers are validated, so `rippled` is not designed to find the absolute best path. Still, you can find several possible paths and estimate the cost of delivering a particular amount.
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ Rippling only occurs along the [paths](paths.md) of a payment. [Direct XRP-to-XR
|
||||
|
||||
For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between tokens with the same currency code but different issuers. The [No Ripple Flag](#the-no-ripple-flag) disables rippling by default when others open trust lines to your account, unless you enable rippling by default using the [Default Ripple flag](#the-default-ripple-flag).
|
||||
|
||||
**Caution:** When you create a trust line, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line.
|
||||
{% admonition type="warning" name="Caution" %}When you create a trust line, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line.{% /admonition %}
|
||||
|
||||
## Example of Rippling
|
||||
|
||||
|
||||
@@ -95,6 +95,6 @@ All XRP Ledger addresses, including operational and standby addresses, are subje
|
||||
|
||||
Set the `SendMax` transaction parameter higher than the destination `Amount` parameter by a percentage based on the `TransferRate` setting.
|
||||
|
||||
**Note:** Transfer fees do not apply when sending tokens directly from or to the issuing address. The issuing address must always accept its tokens at face value in the XRP Ledger. This means that customers don't have to pay the transfer fee if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the transfer fee the customer pays.
|
||||
{% admonition type="info" name="Note" %}Transfer fees do not apply when sending tokens directly from or to the issuing address. The issuing address must always accept its tokens at face value in the XRP Ledger. This means that customers don't have to pay the transfer fee if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the transfer fee the customer pays.{% /admonition %}
|
||||
|
||||
For example: If ACME sets a transfer fee of 1%, an XRP Ledger payment to deliver 5 EUR.ACME from a customer address to ACME's issuing address would cost exactly 5 EUR.ACME. However, the customer would need to send 5.05 EUR.ACME to deliver 5 EUR.ACME to ACME's operational address. When ACME credits customers for payments to ACME's operational address, ACME credits the customer for the amount delivered to the operational address _and_ the transfer fee, giving the customer €5,05 in ACME's systems.
|
||||
|
||||
@@ -12,7 +12,7 @@ All assets other than XRP can be represented in the XRP Ledger as _tokens_.
|
||||
|
||||
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Tokens can be used for [cross-currency payments](../payment-types/cross-currency-payments.md) and can be traded in the [decentralized exchange](decentralized-exchange/index.md).
|
||||
|
||||
**Note:** Tokens on the XRP Ledger have also been called "IOUs" (as in [I-owe-you](https://en.wikipedia.org/wiki/IOU)) and "issued currencies" in the past. However, these terms are not preferred because they do not cover the full range of digital assets that XRP Ledger tokens can represent. <!-- STYLE_OVERRIDE: ious -->
|
||||
{% admonition type="info" name="Note" %}Tokens on the XRP Ledger have also been called "IOUs" (as in [I-owe-you](https://en.wikipedia.org/wiki/IOU)) and "issued currencies" in the past. However, these terms are not preferred because they do not cover the full range of digital assets that XRP Ledger tokens can represent. <!-- STYLE_OVERRIDE: ious -->{% /admonition %}
|
||||
|
||||
Tokens can also be non-fungible. Non-fungible tokens (NFTs) serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
|
||||
|
||||
@@ -34,7 +34,7 @@ For more on this type of usage, see [paths](fungible-tokens/paths.md). <!--{# TO
|
||||
|
||||
There are other use cases for tokens issued in the XRP Ledger. For example, you can create an "Initial Coin Offering" (ICO) by issuing a fixed amount of currency to a secondary address, then "throwing away the key" to the issuer.
|
||||
|
||||
**Warning:** ICOs might be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. <!-- SPELLING_IGNORE: ico, icos -->
|
||||
{% admonition type="danger" name="Warning" %}ICOs might be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. <!-- SPELLING_IGNORE: ico, icos -->{% /admonition %}
|
||||
|
||||
Be sure to research the relevant regulations before engaging in any financial service business.
|
||||
|
||||
|
||||
@@ -20,4 +20,4 @@ To guarantee a fixed number of NFTs:
|
||||
|
||||
At this point, it is impossible for any new tokens to be minted with the issuer’s address as the issuing account.
|
||||
|
||||
**Caution** Once you "blackhole" the account, no one, including you, receives transfer fees for future sales of the NFTs.
|
||||
{% admonition type="warning" name="Caution" %}Once you "blackhole" the account, no one, including you, receives transfer fees for future sales of the NFTs.{% /admonition %}
|
||||
|
||||
@@ -38,7 +38,7 @@ The following table provides examples of how much the total owner reserve might
|
||||
|
||||
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.
|
||||
|
||||
**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 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 %}
|
||||
|
||||
## Practical Considerations
|
||||
|
||||
@@ -54,7 +54,7 @@ If you create a new account, mint an NFT, and create an `NFTokenSellOffer` on th
|
||||
| Total | 14 XRP |
|
||||
| | |
|
||||
|
||||
**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 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.
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ A token issuer can submit an [AccountSet transaction][] to change the `TransferR
|
||||
|
||||
Anyone can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.
|
||||
|
||||
**Note:** The ledger may contain accounts with a transfer fee larger than the current maximum. The [fix1201 amendment](/resources/known-amendments.md#fix1201), enabled on 2017-11-14, lowered the maximum transfer fee to 100% (a `TransferRate` of `2000000000`) from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). Transfer fees that were already set continue to apply at their stated rate.
|
||||
{% admonition type="info" name="Note" %}The ledger may contain accounts with a transfer fee larger than the current maximum. The [fix1201 amendment](/resources/known-amendments.md#fix1201), enabled on 2017-11-14, lowered the maximum transfer fee to 100% (a `TransferRate` of `2000000000`) from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). Transfer fees that were already set continue to apply at their stated rate.{% /admonition %}
|
||||
|
||||
## Client Library Support
|
||||
|
||||
|
||||
Reference in New Issue
Block a user