mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 03:45:49 +00:00
Fix links in Tokens section.
This commit is contained in:
Oliver Eggert
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# Auto-Bridging
|
||||
|
||||
Any [Offer](offers.html) in the XRP Ledger's [decentralized exchange](decentralized-exchange.html) that would exchange two non-XRP currencies could potentially use [XRP](xrp.html) as an intermediary currency in a synthetic order book. This is because of _auto-bridging_, which serves to improve liquidity across all currency pairs by using XRP when doing so is cheaper than trading those currencies directly. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
|
||||
Any [Offer](offers.html) in the XRP Ledger's [decentralized exchange](decentralized-exchange.html) that would exchange two non-XRP currencies could potentially use XRP as an intermediary currency in a synthetic order book. This is because of _auto-bridging_, which serves to improve liquidity across all currency pairs by using XRP when doing so is cheaper than trading those currencies directly. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
|
||||
|
||||
Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. The XRP Ledger's auto-bridging system finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._ <!-- SPELLING_IGNORE: gbp -->
|
||||
|
||||
@@ -17,10 +17,9 @@ Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment
|
||||
## See Also
|
||||
|
||||
- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) <!-- SPELLING_IGNORE: autobridging -->
|
||||
|
||||
- [Offer Preference](offers.html#offer-preference)
|
||||
|
||||
- [Payment Paths](paths.html)
|
||||
- **Concepts:**
|
||||
- [Offer Preference](offers.html#offer-preference)
|
||||
- [Payment Paths](paths.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -41,9 +41,9 @@ For example, if you created an AMM with 5 ETH and 5 USD, and then someone exchan
|
||||
|
||||
Anyone can deposit assets to an existing AMM. When they do, they receive new LP Tokens based on how much they deposited. The amount that a liquidity provider can withdraw from an AMM is based on the proportion of the AMM's LP Tokens they hold compared to the total number of LP Tokens outstanding.
|
||||
|
||||
LP Tokens are like other tokens in the XRP Ledger, so you can use them in many [types of payments](payment-types.html), trade them in the decentralized exchange, or even deposit them as assets for new AMMs. (To receive LP Tokens as payment, you must set up a [trust line](trust-lines-and-issuing.html) with a nonzero limit with the AMM Account as the issuer.) However, you can _only_ send LP Tokens directly to the AMM (redeeming them) using the [AMMWithdraw][] transaction type, not through other types of payments. Similarly, you can only send assets to the AMM's pool through the [AMMDeposit][] transaction type.
|
||||
LP Tokens are like other tokens in the XRP Ledger, so you can use them in many [types of payments](payment-types.html), trade them in the decentralized exchange, or even deposit them as assets for new AMMs. (To receive LP Tokens as payment, you must set up a [trust line](trust-lines-and-issuing.html) with a nonzero limit with the AMM Account as the issuer.) However, you can _only_ send LP Tokens directly to the AMM (redeeming them) using the `AMMWithdraw` transaction type, not through other types of payments. Similarly, you can only send assets to the AMM's pool through the `AMMDeposit` transaction type.
|
||||
|
||||
The AMM is designed so that an AMM's asset pool is empty if and only if the AMM has no outstanding LP Tokens. This situation can only occur as the result of an [AMMWithdraw][] transaction; when it does, the AMM is automatically deleted.
|
||||
The AMM is designed so that an AMM's asset pool is empty if and only if the AMM has no outstanding LP Tokens. This situation can only occur as the result of an `AMMWithdraw` transaction; when it does, the AMM is automatically deleted.
|
||||
|
||||
### LP Token Currency Codes
|
||||
|
||||
@@ -56,7 +56,7 @@ Trading fees are a source of passive income for liquidity providers, and they of
|
||||
|
||||
Liquidity providers can vote to set the fee from 0% to 1%, in increments of 0.001%. Liquidity providers have an incentive to set trading fees at an appropriate rate: if fees are too high, trades will use order books to get a better rate instead; if fees are too low, liquidity providers don't get any benefit for contributing to the pool. <!-- STYLE_OVERRIDE: will --> Each AMM gives its liquidity providers the power to vote on its fees, in proportion to the amount of LP Tokens those liquidity providers hold.
|
||||
|
||||
To vote, a liquidity provider sends an [AMMVote transaction][]. Whenever anyone places a new vote, the AMM recalculates its fee to be an average of the latest votes weighted by how many LP Tokens those voters hold. Up to 8 liquidity providers' votes can be counted this way; if more liquidity providers try to vote then only the top 8 votes (by most LP Tokens held) are counted. Even though liquidity providers' share of LP Tokens can shift rapidly for many reasons (such as trading those tokens using [Offers](offers.html)), the trading fees are only recalculated whenever someone places a new vote (even if that vote is not one of the top 8).
|
||||
To vote, a liquidity provider sends an `AMMVote` transaction. Whenever anyone places a new vote, the AMM recalculates its fee to be an average of the latest votes weighted by how many LP Tokens those voters hold. Up to 8 liquidity providers' votes can be counted this way; if more liquidity providers try to vote then only the top 8 votes (by most LP Tokens held) are counted. Even though liquidity providers' share of LP Tokens can shift rapidly for many reasons (such as trading those tokens using [Offers](offers.html)), the trading fees are only recalculated whenever someone places a new vote (even if that vote is not one of the top 8).
|
||||
|
||||
### Auction Slot
|
||||
|
||||
@@ -69,9 +69,9 @@ With any AMM, when the price of its assets shifts significantly in external mark
|
||||
|
||||
In the ledger's state data, an AMM consists of multiple [ledger entries](ledger-object-types.html):
|
||||
|
||||
- An [AMM object][] describing the automated market maker itself.
|
||||
- An `AMM` object describing the automated market maker itself.
|
||||
|
||||
- A special [AccountRoot object][] that issues the AMM's LP Tokens, and holds the AMM's XRP (if it has any).
|
||||
- A special `AccountRoot` object that issues the AMM's LP Tokens, and holds the AMM's XRP (if it has any).
|
||||
|
||||
The address of this AccountRoot is chosen somewhat randomly when the AMM is created, and it is different if the AMM is deleted and re-created. This is to prevent people from funding the AMM account with excess XRP in advance.
|
||||
|
||||
|
||||
@@ -80,10 +80,10 @@ Main article: [Issuing and Operational Addresses](issuing-and-operational-addres
|
||||
There are several ways in which an issuer can seek to profit from XRP Ledger integration. These can include:
|
||||
|
||||
* Withdrawal and Deposit fees. Issuers typically charge a small fee (such as 1%) for the service of adding or removing money from the XRP Ledger. You have the power to determine the rate you credit people when they move money onto and off of the XRP Ledger through your tokens.
|
||||
* Transfer fees. You can set a percentage fee to charge automatically when customers send each other tokens that you issued. This amount is debited from the XRP Ledger, decreasing your obligation each time your tokens change hands. See [Transfer Fees](#transfer-fees) for details.
|
||||
* Transfer fees. You can set a percentage fee to charge automatically when customers send each other tokens that you issued. This amount is debited from the XRP Ledger, decreasing your obligation each time your tokens change hands.
|
||||
* Indirect revenue from value added. XRP Ledger integration can provide valuable functionality for your customers that distinguishes your business from your competitors.
|
||||
* Interest on XRP Ledger-backed funds. You can keep the collateral for the funds you issue in XRP Ledger in a bank account that earns interest. Make sure you can always access enough funds to service customer withdrawals.
|
||||
* [Financial Exchange](#liquidity-and-currency-exchange). You also make offers to buy and sell your tokens in the XRP Ledger's decentralized exchange, providing liquidity to cross-currency payments and possibly making a profit. (As with all financial exchange, profits are not guaranteed.)
|
||||
* Financial Exchange. You also make offers to buy and sell your tokens in the XRP Ledger's decentralized exchange, providing liquidity to cross-currency payments and possibly making a profit. (As with all financial exchange, profits are not guaranteed.)
|
||||
|
||||
|
||||
### Choosing Fee Rates
|
||||
@@ -260,14 +260,12 @@ There are several prerequisites that ACME must meet for this to happen:
|
||||
- ACME can store the funds allocated to the XRP Ledger in a separate bank account.
|
||||
- If ACME is a cryptocurrency exchange, ACME can create a separate wallet to hold the funds allocated to the XRP Ledger, as publicly-verifiable proof to customers that the issuer is solvent.
|
||||
- ACME should control two separate XRP Ledger addresses. See [Issuing and Operational Addresses](issuing-and-operational-addresses.html) for details.
|
||||
- ACME must enable the [Default Ripple Flag](#default-ripple) on its issuing address for customers to send and receive its tokens.
|
||||
- ACME must enable the Default Ripple flag on its issuing address for customers to send and receive its tokens.
|
||||
- Alice must create an accounting relationship (trust line) from her XRP Ledger address to ACME's issuing address. She can do this from any XRP Ledger client application as long as she knows ACME's issuing address.
|
||||
- ACME should publicize its issuing address on its website where customers can find it. It can also use an [`xrp-ledger.toml` file](xrp-ledger-toml.html) to publish the issuing address to automated systems.
|
||||
- ACME must create a user interface for Alice to send funds from ACME into the XRP Ledger.
|
||||
- ACME needs to know Alice's XRP Ledger address. ACME can have Alice input her XRP Ledger address as part of the interface, or ACME can require Alice to input and verify her XRP Ledger address in advance.
|
||||
|
||||
See [Sending Payments to Customers](#sending-payments-to-customers) for an example of how to send payments into the XRP Ledger.
|
||||
|
||||
|
||||
## Sending from XRP Ledger
|
||||
|
||||
@@ -282,12 +280,12 @@ Payments going from the XRP Ledger to an issuer can be single-currency or cross-
|
||||
|
||||
### Requirements for Receiving from XRP Ledger
|
||||
|
||||
In addition to the [requirements for sending into the XRP Ledger](#requirements-for-sending-to-xrp-ledger), there are several prerequisites that ACME must meet to process payments coming from the XRP Ledger:
|
||||
In addition to the requirements for sending into the XRP Ledger, there are several prerequisites that ACME must meet to process payments coming from the XRP Ledger:
|
||||
|
||||
- ACME must monitor its XRP Ledger addresses for incoming payments.
|
||||
- ACME must know which user to credit in its system of record for the incoming payments.
|
||||
- We recommend that ACME should [bounce any unrecognized incoming payments](#bouncing-payments) back to their sender.
|
||||
- Typically, the preferred method of recognizing incoming payments is through [destination tags](#source-and-destination-tags).
|
||||
- We recommend that ACME should bounce any unrecognized incoming payments back to their sender.
|
||||
- Typically, the preferred method of recognizing incoming payments is through destination tags.
|
||||
|
||||
|
||||
## Precautions
|
||||
@@ -296,15 +294,15 @@ Processing payments to and from the XRP Ledger naturally comes with some risks,
|
||||
|
||||
- Protect yourself against reversible deposits. XRP Ledger payments are irreversible, but many electronic money systems like credit cards or PayPal are not. Scammers can abuse this to take their fiat money back by canceling a deposit after receiving tokens in the XRP Ledger.
|
||||
- When sending into the XRP Ledger, specify the issuing address as the issuer of the currency. Otherwise, you might accidentally use paths that deliver the same currency issued by other addresses.
|
||||
- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any [transfer fee](#transfer-fees) you have set.
|
||||
- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any transfer fee you have set.
|
||||
- Before processing a payment out of the XRP Ledger, make sure you know the customer's identity. This makes it harder for anonymous attackers to scam you. Most anti-money-laundering regulations require this anyway. This is especially important because the users sending money from the XRP Ledger could be different than the ones that initially received the money in the XRP Ledger.
|
||||
- Follow the guidelines for [reliable transaction submission](#reliable-transaction-submission) when sending XRP Ledger transactions.
|
||||
- [Robustly monitor for incoming payments](#robustly-monitoring-for-payments), and read the correct amount. Don't mistakenly credit someone the full amount if they only sent a [partial payment](partial-payments.html).
|
||||
- Follow the guidelines for reliable transaction submission when sending XRP Ledger transactions.
|
||||
- Robustly monitor for incoming payments, and read the correct amount. Don't mistakenly credit someone the full amount if they only sent a [partial payment](partial-payments.html).
|
||||
- Track your obligations and balances within the XRP Ledger, and compare with the assets in your collateral account. If they do not match up, stop processing withdrawals and deposits until you resolve the discrepancy.
|
||||
- Avoid ambiguous situations. We recommend the following:
|
||||
- Enable the [Disallow XRP flag](#disallow-xrp) for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.)
|
||||
- Enable the `Disallow XRP` flag for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.)
|
||||
- Enable the [`RequireDest` flag](require-destination-tags.html) for the issuing address and all operational addresses, so customers do not accidentally send a payment without the destination tag to indicate who should be credited.
|
||||
- Enable the [`RequireAuth` flag](#require-auth) on all operational addresses so they cannot issue currency by accident.
|
||||
- Enable the `RequireAuth` flag on all operational addresses so they cannot issue currency by accident.
|
||||
- Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments.
|
||||
|
||||
## Trading on the XRP Ledger
|
||||
@@ -313,8 +311,8 @@ After the tokens have been created in the XRP Ledger, they can be freely transfe
|
||||
|
||||
- Anyone can buy/sell EUR.ACME on the XRP Ledger. If ACME issues multiple tokens, a separate trust line is necessary for each.
|
||||
- This includes XRP Ledger users who do not have an account in ACME Exchange's systems. To withdraw the funds successfully from ACME, users still have to register with ACME.
|
||||
- Optionally, ACME uses the [Authorized Trust Lines](#authorized-trust-lines) feature to limit who can hold EUR.ACME in the XRP Ledger.
|
||||
- If ACME determines that a customer has acted in bad faith, ACME can [Freeze](#freeze) that user's accounting relationships to ACME in the XRP Ledger, so that the user can no longer trade in the issuer's tokens.
|
||||
- Optionally, ACME uses the Authorized Trust Lines feature to limit who can hold EUR.ACME in the XRP Ledger.
|
||||
- If ACME determines that a customer has acted in bad faith, ACME can Freeze that user's accounting relationships to ACME in the XRP Ledger, so that the user can no longer trade in the issuer's tokens.
|
||||
- XRP Ledger users trading and sending EUR.ACME to one another requires no intervention by ACME.
|
||||
- All exchanges and balances in the XRP Ledger are publicly viewable.
|
||||
|
||||
@@ -418,14 +416,14 @@ To robustly check for incoming payments, issuers should do the following:
|
||||
* Look out for [Partial Payments](partial-payments.html). Payments with the partial payment flag enabled can be considered "successful" if any non-zero amount is delivered, even minuscule amounts.
|
||||
* Check the transaction for a [`delivered_amount` field](partial-payments.html#the-delivered_amount-field). If present, that field indicates how much money *actually* got delivered to the `Destination` address.
|
||||
* In xrpl.js, you can use the [`xrpl.getBalanceChanges()` method](https://js.xrpl.org/modules.html#getBalanceChanges) to see how much each address received. In some cases, this can be divided into multiple parts on different trust lines.
|
||||
* Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero [transfer fee](#transfer-fees), then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's tokens. See [Transfer Fees](#transfer-fees) for more information.
|
||||
* Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero transfer fee, then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's tokens.
|
||||
|
||||
To make things simpler for your customers, we recommend accepting payments to both your operational address and your issuing addresses.
|
||||
|
||||
As an added precaution, we recommend comparing the balances of your issuing address with the collateral funds in your internal accounting system as of each new XRP Ledger ledger version. The issuing address's negative balances should match the assets you have allocated to XRP Ledger outside the network. If the two do not match up, then you should suspend processing payments into and out of the XRP Ledger until you have resolved the discrepancy.
|
||||
|
||||
* Use the [gateway_balances method][] to check your balances.
|
||||
* If you have a [Transfer Fee](#transfer-fees) set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your tokens among themselves.
|
||||
* Use the `gateway_balances` method to check your balances.
|
||||
* If you have a Transfer Fee set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your tokens among themselves.
|
||||
|
||||
For more details on how to read the details of incoming transactions, see [Look Up Transaction Results](look-up-transaction-results.html).
|
||||
|
||||
@@ -520,18 +518,18 @@ Response:
|
||||
}
|
||||
```
|
||||
|
||||
In particular, note the following features of the [Payment transaction][]:
|
||||
In particular, note the following features of the `Payment` transaction:
|
||||
|
||||
- No `Paths` field. The payment only succeeds if it can use a [default path](paths.html#default-paths), which is preferable. Using less direct paths can become much more expensive.
|
||||
- The `issuer` of both the `SendMax` and the `Amount` is the issuing address. This ensures that the transaction sends and delivers tokens from the intended issuer, and not from another issuer using the same currency code.
|
||||
- The `value` of the `SendMax` amount is slightly higher than the destination `Amount`, to compensate for the [transfer fee](#transfer-fees). In this case, the transfer fee is 0.5%, so the `SendMax` amount is exactly 1.005 times the destination `Amount`.
|
||||
- The `value` of the `SendMax` amount is slightly higher than the destination `Amount`, to compensate for the transfer fee. In this case, the transfer fee is 0.5%, so the `SendMax` amount is exactly 1.005 times the destination `Amount`.
|
||||
|
||||
|
||||
## Bouncing Payments
|
||||
|
||||
When one of your addresses receives a payment whose purpose is unclear, we recommend that you try to return the money to its sender. While this is more work than pocketing the money, it demonstrates good faith towards customers. You can have an operator bounce payments manually, or create a system to do so automatically.
|
||||
|
||||
The first requirement to bouncing payments is [robustly monitoring for incoming payments](#robustly-monitoring-for-payments). You do not want to accidentally refund a customer for more than they sent you! (This is particularly important if your bounce process is automated.) Malicious users can take advantage of a naive integration by sending [partial payments](partial-payments.html#partial-payments-exploit).
|
||||
The first requirement to bouncing payments is robustly monitoring for incoming payments. You do not want to accidentally refund a customer for more than they sent you! (This is particularly important if your bounce process is automated.) Malicious users can take advantage of a naive integration by sending [partial payments](partial-payments.html#partial-payments-exploit).
|
||||
|
||||
Second, you should send bounced payments as Partial Payments. Since third parties can manipulate the cost of pathways between addresses, Partial Payments allow you to divest yourself of the full amount without being concerned about exchange rates within the XRP Ledger. You should publicize your bounced payments policy as part of your terms of use. Send the bounced payment from either an operational address or a standby address.
|
||||
|
||||
@@ -551,7 +549,7 @@ To submit transactions reliably, follow these guidelines:
|
||||
|
||||
* Persist details of the transaction before submitting it.
|
||||
* Use the `LastLedgerSequence` parameter. (Many [client libraries](client-libraries.html) do this by default.)
|
||||
* Resubmit a transaction if it has not appeared in a validated ledger whose [ledger index][] is less than or equal to the transaction's `LastLedgerSequence` parameter.
|
||||
* Resubmit a transaction if it has not appeared in a validated ledger whose ledger index is less than or equal to the transaction's `LastLedgerSequence` parameter.
|
||||
|
||||
For more information, see [Reliable Transaction Submission](reliable-transaction-submission.html).
|
||||
|
||||
@@ -569,22 +567,3 @@ You can publish information about what currencies you issue, and which XRP Ledge
|
||||
- [Tokens](tokens.html)
|
||||
- [Decentralized Exchange](decentralized-exchange.html)
|
||||
- [Source and Destination Tags](source-and-destination-tags.html)
|
||||
- **Tutorials:**
|
||||
- [Install `rippled`](install-rippled.html)
|
||||
- [Set Up Secure Signing](set-up-secure-signing.html)
|
||||
- [Issue a Fungible Token](issue-a-fungible-token.html)
|
||||
- [Enable No Freeze](enable-no-freeze.html)
|
||||
- [Freeze a Trust Line](freeze-a-trust-line.html)
|
||||
- [Enact Global Freeze](enact-global-freeze.html)
|
||||
- **References:**
|
||||
- [Payment transaction][]
|
||||
- [AccountSet transaction][]
|
||||
- [TrustSet transaction][]
|
||||
- [RippleState object](ripplestate.html)
|
||||
- [account_lines method][]
|
||||
- [gateway_balances method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -7,7 +7,7 @@ labels:
|
||||
---
|
||||
# Common Misunderstandings about Freezes
|
||||
|
||||
It is a common misconception that Ripple or others can freeze XRP, similar to how centralized services like PayPal can suspend your account and prevent you from accessing your funds. In reality, while the XRP Ledger does have a [freeze feature](freezing-tokens.md), it can only be used on issued tokens, not on XRP. _No one can freeze XRP.__
|
||||
It is a common misconception that Ripple or others can freeze XRP, similar to how centralized services like PayPal can suspend your account and prevent you from accessing your funds. In reality, while the XRP Ledger does have a freeze feature, it can only be used on issued tokens, not on XRP. _No one can freeze XRP.__
|
||||
|
||||
Tokens in the XRP Ledger are fundamentally different than XRP. Tokens always exist in trust lines, which _can_ be frozen. XRP exists in accounts, which _cannot_ be frozen.
|
||||
|
||||
@@ -21,7 +21,7 @@ The XRP Ledger is decentralized so that no one party has control over it—not R
|
||||
|
||||
The _issuer_ of a token can freeze your trust line for _that token specifically_. They can't freeze the rest of your account, or any tokens from different issuers, and they can't stop you from using the XRP Ledger.
|
||||
|
||||
Furthermore, token issuers can voluntarily and permanently _give up_ their ability to freeze tokens. This ["No Freeze"](freezing-tokens.md#no-freeze) setting is intended to allow tokens to behave more like physical cash, in that third parties can't stop you from using it.
|
||||
Furthermore, token issuers can voluntarily and permanently _give up_ their ability to freeze tokens. This ["No Freeze"](freezing-tokens.html#no-freeze) setting is intended to allow tokens to behave more like physical cash, in that third parties can't stop you from using it.
|
||||
|
||||
|
||||
## But I Heard Ripple Froze Jed McCaleb's XRP?
|
||||
@@ -30,4 +30,4 @@ This is a misrepresentation of events that actually happened in 2015–2016. Jed
|
||||
|
||||
Notably, the "freeze" did not happen on the XRP Ledger and did not involve the XRP Ledger's freeze feature. Like any custodial exchange, Bitstamp has the ability to freeze its users' accounts and stop them from trading or withdrawing funds, especially if those funds are involved in a legal dispute.
|
||||
|
||||
In contrast, when trading in the XRP Ledger's decentralized exchange, you custody your own assets so no one can stop you from dealing in XRP.
|
||||
In contrast, when trading in the XRP Ledger's decentralized exchange, you custody your own assets so no one can stop you from dealing in XRP.
|
||||
|
||||
@@ -55,15 +55,15 @@ As a decentralized system, the XRP Ledger does not have any information on the a
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- See [Offers](offers.html) for details on how trades work in the XRP Ledger.
|
||||
- See [Tokens](tokens.html) for an overview of how various types of value can be represented in the XRP Ledger.
|
||||
- [Offers](offers.html)
|
||||
- [Tokens](tokens.html)
|
||||
- **References:**
|
||||
- [account_offers method][] to look up Offers placed by an account
|
||||
- [book_offers method][] to look up Offers to buy or sell a given currency pair
|
||||
- [OfferCreate transaction][] to place a new Offer or replace an existing Offer
|
||||
- [OfferCancel transaction][] to cancel an existing Offer
|
||||
- [Offer object][] for the data structure of passive Offers in the ledger
|
||||
- [DirectoryNode object][] for the data structure that tracks all the Offers for a given currency pair and exchange rate.
|
||||
- [account_offers method][]
|
||||
- [book_offers method][]
|
||||
- [OfferCreate transaction][]
|
||||
- [OfferCancel transaction][]
|
||||
- [Offer object][]
|
||||
- [DirectoryNode object][]
|
||||
|
||||
<!-- NOTE: There aren't really any tutorials for using the DEX. When there are, add them here. -->
|
||||
|
||||
|
||||
@@ -7,17 +7,17 @@ labels:
|
||||
---
|
||||
# Freezing Tokens
|
||||
|
||||
Issuers can freeze the tokens they issue in the XRP Ledger. _This does not apply to XRP,__ which is the native asset of the XRP Ledger, not an issued token.
|
||||
Issuers can freeze the tokens they issue in the XRP Ledger. _This does not apply to XRP_, which is the native asset of the XRP Ledger, not an issued token.
|
||||
|
||||
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).
|
||||
**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-misunderstandings-about-freezes.html).
|
||||
|
||||
There are three settings related to freezes:
|
||||
|
||||
* [Individual Freeze](#individual-freeze) - Freeze one counterparty.
|
||||
* [Global Freeze](#global-freeze) - Freeze all counterparties.
|
||||
* [No Freeze](#no-freeze) - Permanently give up the ability to freeze individual counterparties, as well as the ability to end a global freeze.
|
||||
* Individual Freeze - Freeze one counterparty.
|
||||
* Global Freeze - Freeze all counterparties.
|
||||
* No Freeze - Permanently give up the ability to freeze individual counterparties, as well as the ability to end a global freeze.
|
||||
|
||||
All freeze settings can be enacted regardless of whether the balance(s) to be frozen are positive or negative. Either the token issuer or the currency holder can freeze a trust line; however, the effect is minimal when a currency holder enacts a freeze.
|
||||
|
||||
@@ -35,30 +35,30 @@ Reminder: Trust lines do not hold XRP. XRP cannot be frozen.
|
||||
|
||||
A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution uses that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.)
|
||||
|
||||
An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other accounts, including [operational accounts](../accounts/account-types.md), from sending that financial institution's tokens to the individual account. This type of individual freeze has no effect on offers.
|
||||
An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other accounts, including [operational accounts](account-types.html), from sending that financial institution's tokens to the individual account. This type of individual freeze has no effect on offers.
|
||||
|
||||
The Individual Freeze applies to a single trust line. To freeze multiple tokens with a particular counterparty, the address must enable Individual Freeze on the trust lines for each separate currency code.
|
||||
|
||||
An address cannot enable the Individual Freeze setting if it has enabled the [No Freeze](#no-freeze) setting.
|
||||
An address cannot enable the Individual Freeze setting if it has enabled the `No Freeze` setting.
|
||||
|
||||
|
||||
## Global Freeze
|
||||
|
||||
The _Global Freeze_ feature is a setting on an account. An account can enable a global freeze only on itself. When an issuer enables the Global Freeze feature, the following rules apply to all tokens they issue:
|
||||
|
||||
* All counterparties of the frozen issuer can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects the issuer's own [operational addresses](../accounts/account-types.md).)
|
||||
* All counterparties of the frozen issuer can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects the issuer's own [operational addresses](account-types.html).)
|
||||
* Counterparties of the frozen issuer can still send and receive payments directly to and from the issuing address.
|
||||
* All offers to sell tokens issued by the frozen address are considered unfunded.
|
||||
|
||||
Reminder: addresses cannot issue XRP. Global freezes do not apply to XRP.
|
||||
|
||||
It can be useful to enable Global Freeze on a financial institution's [issuing account](../accounts/account-types.md) if the issuer's [secret key](.../accounts/cryptographic-keys.html) is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, the issuer should also suspend activities in its outside systems.
|
||||
It can be useful to enable Global Freeze on a financial institution's [issuing account](account-types.html) if the issuer's [secret key](cryptographic-keys.html) is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, the issuer should also suspend activities in its outside systems.
|
||||
|
||||
It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing account](../accounts/account-types.md), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
|
||||
It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing account](account-types.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
|
||||
|
||||
Global Freeze applies to _all_ tokens issued and held by the address. You cannot enable Global Freeze for only one currency code. If you want to have the ability to freeze some tokens and not others, you should use different addresses for each token.
|
||||
|
||||
An address can always enable the Global Freeze setting. However, if the address has enabled the [No Freeze](#no-freeze) setting, it can never _disable_ Global Freeze.
|
||||
An address can always enable the Global Freeze setting. However, if the address has enabled the No Freeze setting, it can never _disable_ Global Freeze.
|
||||
|
||||
|
||||
## No Freeze
|
||||
@@ -79,7 +79,6 @@ The No Freeze setting applies to all tokens issued to and from an address. If yo
|
||||
You can only enable the No Freeze setting with a transaction signed by your address's master key secret. You cannot use a Regular Key or a multi-signed transaction to enable No Freeze.
|
||||
|
||||
|
||||
<!--
|
||||
# See Also
|
||||
|
||||
- [Freeze Code Samples](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
|
||||
@@ -89,11 +88,3 @@ You can only enable the No Freeze setting with a transaction signed by your addr
|
||||
- [Enable No Freeze](enable-no-freeze.html)
|
||||
- [Enact Global Freeze](enact-global-freeze.html)
|
||||
- [Freeze a Trust Line](freeze-a-trust-line.html)
|
||||
- **References:**
|
||||
- [account_lines method][]
|
||||
- [account_info method][]
|
||||
- [AccountSet transaction][]
|
||||
- [TrustSet transaction][]
|
||||
- [AccountRoot Flags](accountroot.html#accountroot-flags)
|
||||
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
|
||||
-->
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
|
||||
You can transfer `NFToken` objects between accounts on the XRP Ledger. You can offer to buy or sell a `NFToken`, or accept offers from other accounts to buy a `NFToken` you own. You can even give away a `NFToken` by offering to sell it at a price of 0. All offers are created using `NFTokenCreateOffer` transaction.
|
||||
|
||||
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
|
||||
_(Added by the [NonFungibleTokensV1_1 amendment](known-amendments.html#nonfungibletokensv1_1).)_
|
||||
|
||||
|
||||
## Sell Offers
|
||||
@@ -65,13 +65,13 @@ Using a broker offers several advantages. For example:
|
||||
In the most straightforward workflow, a creator mints a new `NFToken`. The creator initiates a sell offer, entering the minimum acceptable sale price and setting the broker as the destination. Potential buyers make bids for the `NFToken`, setting the broker as the destination for the bid. The broker selects a winning bid and completes the transaction, taking a broker’s fee. As a best practice, the broker then cancels any remaining buy offers for the `NFToken`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Another potential workflow would give the creator more control over the sale. In this workflow, the creator mints a new `NFToken`. Bidders create their offers, setting the broker as the destination. The broker selects the winning bid, subtracts their broker fee, and uses `NFTokenCreateOffer` to request that the creator sign off on the offer. The creator signs the requested offer, setting the broker as the destination. The broker completes the sale using `NFTokenAcceptOffer`, retaining the broker fee. The broker cancels any remaining bids for the `NFToken` using `NFTokenCancelOffer`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The same workflows can be used when an owner resells a `NFToken` created by another account.
|
||||
The same workflows can be used when an owner resells a `NFToken` created by another account.
|
||||
|
||||
@@ -49,26 +49,3 @@ You destroy an `NFToken` using the `NFTokenBurn` transaction.
|
||||
You create a NFT using the `NFTokenMint` transaction. The `NFToken` lives on the `NFTokenPage` of the issuing account. You can create an `NFTokenOffer` to sell the `NFToken`, creating an entry to the XRP Ledger. Another account can accept the `NFTokenOffer`, transferring the `NFToken` to the accepting account’s `NFTokenPage`. If the `lsfTransferable `flag is set to _true_ (0x000008) when the `NFToken` is minted, the `NFToken` can be traded multiple times between accounts. The `NFToken` can be permanently destroyed by its owner using the `NFTokenBurn` transaction.
|
||||
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
## Reference
|
||||
|
||||
- [NFToken][] data type
|
||||
- Ledger Objects
|
||||
- [NFTokenOffer object][]
|
||||
- [NFTokenPage object][]
|
||||
- Transactions
|
||||
- [NFTokenMint transaction][]
|
||||
- [NFTokenCreateOffer transaction][]
|
||||
- [NFTokenCancelOffer transaction][]
|
||||
- [NFTokenAcceptOffer transaction][]
|
||||
- [NFTokenBurn transaction][]
|
||||
|
||||
|
||||
### API Methods
|
||||
|
||||
* `account_nfts`
|
||||
* `nft_sell_offers`
|
||||
* `nft_buy_offers`
|
||||
-->
|
||||
@@ -50,11 +50,11 @@ It is possible for an Offer to become temporarily or permanently _unfunded_ in t
|
||||
|
||||
- If the owner no longer has any of the sell asset.
|
||||
- The Offer becomes funded again when the owner obtains more of that asset.
|
||||
- If the sell asset is a token in a [frozen trust line](freezes.html).
|
||||
- If the sell asset is a token in a [frozen trust line](freezing-tokens.html).
|
||||
- The Offer becomes funded again when the trust line is no longer frozen.
|
||||
- If the Offer needs to create a new trust line, but the owner does not have enough XRP for the increased [reserve](reserves.html). (See [Offers and Trust](#offers-and-trust).)
|
||||
- If the Offer needs to create a new trust line, but the owner does not have enough XRP for the increased [reserve](reserves.html).
|
||||
- The offer becomes funded again when the owner obtains more XRP, or the reserve requirements decrease.
|
||||
- If the Offer is expired. (See [Offer Expiration](#offer-expiration).)
|
||||
- If the Offer is expired.
|
||||
|
||||
An unfunded Offer stays on the ledger until a transaction removes it. Ways that an Offer can be removed from the ledger include:
|
||||
|
||||
|
||||
@@ -8,8 +8,6 @@ labels:
|
||||
---
|
||||
# Tick Size
|
||||
|
||||
_(Added by the [TickSize amendment][].)_
|
||||
|
||||
When an Offer is placed into an order book, its exchange rate is truncated based on the `TickSize` values set by the issuers of the currencies involved in the Offer. When trading XRP and a token, the `TickSize` from the token's issuer applies. When trading two tokens, the Offer uses the smaller `TickSize` value (that is, the one with fewer significant digits). If neither token has a `TickSize` set, the default behavior applies.
|
||||
|
||||
The `TickSize` value truncates the number of _significant digits_ in the exchange rate of an offer when it gets placed in an order book. Issuers can set `TickSize` to an integer from `3` to `15` using an [AccountSet transaction][]. The exchange rate is represented as significant digits and an exponent; the `TickSize` does not affect the exponent. This allows the XRP Ledger to represent exchange rates between assets that vary greatly in value (for example, a highly inflated currency compared to a rare commodity). The lower the `TickSize` an issuer sets, the larger the increment traders must offer to be considered a higher exchange rate than the existing Offers.
|
||||
@@ -27,7 +25,6 @@ When an issuer enables, disables, or changes the `TickSize`, Offers that were pl
|
||||
- [OfferCreate transaction][]
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -11,7 +11,7 @@ All assets other than XRP can be represented in the XRP Ledger as **tokens**. To
|
||||
|
||||
Any account can issue tokens to other recipients who are willing to hold them, but cannot unilaterally transfer tokens to users who do not want them.
|
||||
|
||||
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible-tokens.html) for details of the XRP Ledger's native support.
|
||||
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible.html) for details of the XRP Ledger's native support.
|
||||
|
||||
Standard tokens are tracked in relationships called [trust lines](trust-lines-and-issuing.html) between accounts.
|
||||
|
||||
@@ -23,10 +23,10 @@ The balance on a trust line is negative or positive, depending on which side you
|
||||
|
||||
## Token Structure
|
||||
|
||||
Tokens in the XRP Ledger are fundamentally different than XRP. Tokens always exist _in trust lines_, and all transfers of tokens move along trust lines. You cannot cause someone else's account to hold more of a token than the _limit_ configured on their trust line. (You _can_ cause your own trust line to go over the limit, for example by buying more of it in the [decentralized exchange](../servers/decentralized-exchange.md) or by decreasing the limit after you already have a positive balance.)
|
||||
Tokens in the XRP Ledger are fundamentally different than XRP. Tokens always exist _in trust lines_, and all transfers of tokens move along trust lines. You cannot cause someone else's account to hold more of a token than the _limit_ configured on their trust line. (You _can_ cause your own trust line to go over the limit, for example by buying more of it in the [decentralized exchange](decentralized-exchange.html) or by decreasing the limit after you already have a positive balance.)
|
||||
|
||||
Tokens use decimal (base-10) math with 15 digits of precision and an exponent that allows them to express very large values (up to 9999999999999999 × 10<sup>80</sup>) and very small values (down to 1.0 × 10<sup>-81</sup>).
|
||||
|
||||
Anyone can issue tokens by sending a `Payment` transaction if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](cross-currency-payments.html) or trades can also create more tokens according to an issuer's settings.
|
||||
|
||||
Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a tick size for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezing-tokens.html) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
|
||||
Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a tick size for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezing-tokens.html) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
|
||||
|
||||
@@ -1,15 +1,19 @@
|
||||
---
|
||||
html: transfer-fees.html
|
||||
parent: non-fungible.html
|
||||
blurb:
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Transfer Fees
|
||||
|
||||
[Token](tokens.html) issuers can charge a _transfer fee_ that applies when users transfer those tokens among themselves. The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee.
|
||||
|
||||
For standard tokens, the tokens paid in the transfer fee are burned, and no longer tracked in the XRP Ledger. If the token is backed by off-ledger assets, this reduces the amount of those assets the issuer has to hold in reserve to meet its obligations in the XRP Ledger. Transfer fees are usually not appropriate for tokens that aren't backed with outside assets.
|
||||
|
||||
Non-fungible tokens can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible-tokens.html).
|
||||
Non-fungible tokens can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible.html).
|
||||
|
||||
The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user.
|
||||
|
||||
[operational address]: issuing-and-operational-addresses.html
|
||||
[issuing address]: issuing-and-operational-addresses.html
|
||||
The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address](issuing-and-operational-addresses.html) to another user.
|
||||
|
||||
XRP never has a transfer fee, because it never has an issuer.
|
||||
|
||||
@@ -45,7 +49,7 @@ In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to de
|
||||
|
||||
# Technical Details
|
||||
|
||||
The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The transfer fee applies to all tokens issued by the same account. If you want to have different transfer fees for different tokens, use multiple [issuing addresses][issuing address].
|
||||
The transfer fee is represented by a setting on the issuing address. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The transfer fee applies to all tokens issued by the same account. If you want to have different transfer fees for different tokens, use multiple issuing addresses(issuing-address.html).
|
||||
|
||||
In the [XRP Ledger protocol](protocol-reference.html), the transfer fee is specified in the `TransferRate` field, as an integer which represents the amount you must send for the recipient to get 1 billion units of the same token. A `TransferRate` of `1005000000` is equivalent to a transfer fee of 0.5%. By default, the `TransferRate` is set to no fee. The value of `TransferRate` cannot be set to less than `1000000000` ("0%" fee) or more than `2000000000` (a "100%" fee). The value `0` is special case for no fee, equivalent to `1000000000`.
|
||||
|
||||
@@ -66,11 +70,4 @@ Some [client libraries](client-libraries.html) have convenience functions for ge
|
||||
- **Concepts:**
|
||||
- [Fees (Disambiguation)](fees.html)
|
||||
- [Transaction Cost](transaction-cost.html)
|
||||
- [Paths](paths.html)
|
||||
- **Tutorials:**
|
||||
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
|
||||
- **References:**
|
||||
- [account_lines method][]
|
||||
- [account_info method][]
|
||||
- [AccountSet transaction][]
|
||||
- [AccountRoot Flags](accountroot.html#accountroot-flags)
|
||||
|
||||
|
||||
@@ -8,7 +8,6 @@ labels:
|
||||
- Broker
|
||||
- XRP
|
||||
---
|
||||
|
||||
# Batch Mint NFTokens
|
||||
|
||||
You can create an application that mints multiple NFTokens at one time. You can use a `for` loop to send one transaction after another.
|
||||
|
||||
Reference in New Issue
Block a user