mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Merge pull request #358 from mDuo13/doc-1545
Reorg Decentralized Exchange concept category
This commit is contained in:
13
content/concepts/decentralized-exchange/autobridging.md
Normal file
13
content/concepts/decentralized-exchange/autobridging.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Auto-Bridging
|
||||
|
||||
Any OfferCreate 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 as a vehicle currency. 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. Auto-bridging software 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._
|
||||
|
||||
Auto-bridging happens automatically on any OfferCreate transaction. [Payment transactions](#payment) _do not_ autobridge by default, but path-finding can find paths that have the same effect.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Dev Blog: Introducing Autobridging](https://ripple.com/dev-blog/introducing-offer-autobridging/)
|
||||
|
||||
- [Offer Preference](offers.html#offer-preference)
|
||||
@@ -1,3 +0,0 @@
|
||||
# Decentralized Exchange
|
||||
|
||||
The XRP Ledger contains a fully-functional exchange where users can trade issued currencies for XRP or each other.
|
||||
@@ -6,6 +6,7 @@ In the XRP Ledger's decentralized exchange, orders to trade currency are called
|
||||
- Offers that aren't fully filled immediately become [Offer objects](offer.html) in the ledger data. Later Offers and Payments can consume the Offer object from the ledger.
|
||||
- [Cross-currency payments](cross-currency-payments.html) consume offers to provide liquidity.
|
||||
|
||||
|
||||
## Lifecycle of an Offer
|
||||
|
||||
When an OfferCreate transaction is processed, it automatically consumes matching or crossing offers to the extent possible. (If existing offers provide a better rate than requested, the offer creator could pay less than the full `TakerGets` amount to receive the entire `TakerPays` amount.) If that does not completely fulfill the `TakerPays` amount, then the offer becomes an Offer object in the ledger. (You can use [OfferCreate Flags](offercreate.html#offercreate-flags) to modify this behavior.)
|
||||
@@ -47,26 +48,15 @@ However, holding non-XRP balances still requires a trust line to the address iss
|
||||
|
||||
A trust line indicates an issuer you trust enough to accept their issuances as payment, within limits. Offers are explicit instructions to acquire certain issuances, so they are allowed to go beyond those limits.
|
||||
|
||||
|
||||
## Offer Preference
|
||||
|
||||
Existing offers are grouped by exchange rate (sometimes called "offer quality"), which is measured as the ratio between `TakerGets` and `TakerPays`. Offers with a higher exchange rate are taken preferentially. (That is, the person accepting the offer receives as much as possible for the amount of currency they pay out.) Offers with the same exchange rate are taken on the basis of which offer was placed in the earliest ledger version.
|
||||
|
||||
When offers of the same exchange rate are placed in the same ledger version, the order in which they are taken is determined by the [canonical order](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering") in which the transactions were [applied to the ledger](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source: Applying transactions"). This behavior is designed to be deterministic, efficient, and hard to game.
|
||||
|
||||
### TickSize
|
||||
|
||||
_Requires the [TickSize amendment](reference-amendments.html#ticksize)._
|
||||
|
||||
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 a trader offers to exchange XRP and an issued currency, the `TickSize` from the issuer of the currency applies. When a trader offers to exchange two issued currencies, the offer uses the smaller `TickSize` value (that is, the one with fewer significant digits). If neither currency 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 hyperinflated 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.
|
||||
|
||||
The `TickSize` does not affect the part of an Offer that can be executed immediately. (For that reason, OfferCreate transactions with `tfImmediateOrCancel` are unaffected by `TickSize` values.) If the Offer cannot be fully executed, the transaction processing engine calculates the exchange rate and truncates it based on `TickSize`. Then, the engine rounds the remaining amount of the Offer from the "less important" side to match the truncated exchange rate. For a default OfferCreate transaction (a "buy" Offer), the `TakerPays` amount (the amount being bought) gets rounded. If the `tfSell` flag is enabled (a "sell" Offer) the `TakerGets` amount (the amount being sold) gets rounded.
|
||||
|
||||
When an issuer enables, disables, or changes the `TickSize`, Offers that were placed under the previous setting are unaffected.
|
||||
|
||||
|
||||
## Expiration
|
||||
## Offer Expiration
|
||||
|
||||
Since transactions can take time to propagate and confirm, the timestamp of a ledger is used to determine offer validity. An offer only expires when its Expiration time is before the most-recently validated ledger. In other words, an offer with an `Expiration` field is still considered "active" if its expiration time is later than the timestamp of the most-recently validated ledger, regardless of what your local clock says.
|
||||
|
||||
@@ -76,10 +66,8 @@ You can determine the final disposition of an offer with an `Expiration` as soon
|
||||
|
||||
If an OfferCreate transaction has an `Expiration` time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer. The result code of such a transaction depends on whether the [Checks amendment](reference-amendments.html#checks) is enabled. With the Checks amendment enabled, the transaction has the `tecEXPIRED` result code. Otherwise, the transaction has the `tesSUCCESS` transaction code. In either case, the transaction has no effect except to destroy the XRP paid as a [transaction cost](concept-transaction-cost.html).
|
||||
|
||||
## Auto-Bridging
|
||||
|
||||
Any OfferCreate 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 as a vehicle currency. 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. Auto-bridging software 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._
|
||||
|
||||
Auto-bridging happens automatically on any OfferCreate transaction. [Payment transactions](#payment) _do not_ autobridge by default, but path-finding can find paths that have the same effect.
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
23
content/concepts/decentralized-exchange/ticksize.md
Normal file
23
content/concepts/decentralized-exchange/ticksize.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Tick Size
|
||||
|
||||
_Requires the [TickSize amendment](reference-amendments.html#ticksize)._
|
||||
|
||||
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 a trader offers to exchange XRP and an issued currency, the `TickSize` from the issuer of the currency applies. When a trader offers to exchange two issued currencies, the offer uses the smaller `TickSize` value (that is, the one with fewer significant digits). If neither currency 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 hyperinflated 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.
|
||||
|
||||
The `TickSize` does not affect the part of an Offer that can be executed immediately. (For that reason, OfferCreate transactions with `tfImmediateOrCancel` are unaffected by `TickSize` values.) If the Offer cannot be fully executed, the transaction processing engine calculates the exchange rate and truncates it based on `TickSize`. Then, the engine rounds the remaining amount of the Offer from the "less important" side to match the truncated exchange rate. For a default OfferCreate transaction (a "buy" Offer), the `TakerPays` amount (the amount being bought) gets rounded. If the `tfSell` flag is enabled (a "sell" Offer) the `TakerGets` amount (the amount being sold) gets rounded.
|
||||
|
||||
When an issuer enables, disables, or changes the `TickSize`, Offers that were placed under the previous setting are unaffected.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Dev Blog: Introducing the TickSize Amendment](https://ripple.com/dev-blog/ticksize-amendment-open-voting/#ticksize-amendment-overview)
|
||||
|
||||
- [AccountSet transaction][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -249,7 +249,7 @@ pages:
|
||||
|
||||
# TODO: Freezes, Rippling, Transfer Fees, Paths, Demurrage
|
||||
|
||||
- md: concepts/decentralized-exchange/decentralized-exchange.md
|
||||
- name: Decentralized Exchange
|
||||
html: decentralized-exchange.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
@@ -259,7 +259,32 @@ pages:
|
||||
targets:
|
||||
- local
|
||||
|
||||
# TODO: Offers, Tick Size, Autobridging, Offer Preference (all compiled from different sources)
|
||||
- md: concepts/decentralized-exchange/offers.md
|
||||
html: offers.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Decentralized Exchange
|
||||
blurb: Offers are the XRP Ledger's form of currency trading orders. Understand their lifecycle and properties.
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: concepts/decentralized-exchange/autobridging.md
|
||||
html: autobridging.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Decentralized Exchange
|
||||
blurb: Autobriding automatically connects order books using XRP as an intermediary when it reduces costs.
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: concepts/decentralized-exchange/ticksize.md
|
||||
html: ticksize.html
|
||||
funnel: Docs
|
||||
doc_type: Concepts
|
||||
category: Decentralized Exchange
|
||||
blurb: Issuers can set custom tick sizes for currencies to reduce churn in order books over miniscule differences in exchange rates.
|
||||
targets:
|
||||
- local
|
||||
|
||||
- name: Consensus Network
|
||||
html: consensus-network.html
|
||||
|
||||
Reference in New Issue
Block a user