mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 11:55:50 +00:00
@@ -31,16 +31,10 @@ LP tokens enable liquidity providers to:
|
||||
An AMM holds two different assets: at most one of these can be XRP, and one or both of them can be [tokens](../index.md).
|
||||
For any given pair of assets, there can be up to one AMM in the ledger. Anyone can create the AMM for an asset pair if it doesn't exist, or deposit to an AMM if it already exists.
|
||||
|
||||
When you want to trade in the decentralized exchange, your [Offers](offers.md) and [Cross-Currency Payments](../../payment-types/cross-currency-payments.md) can automatically use AMMs to complete the trade. A single transaction might execute by matching Offers, AMMs, or a mix of both, depending on what's cheaper.
|
||||
When you want to trade in the decentralized exchange, your [offers](offers.md) and [cross-currency payments](../../payment-types/cross-currency-payments.md) can automatically use AMMs to complete the trade. A single transaction might execute by matching offers, AMMs, or a mix of both, depending on what's cheaper. You can [read a transaction's metadata](../../transactions/finality-of-results/look-up-transaction-results.md) to see what liquidity it consumed.
|
||||
|
||||

|
||||
|
||||
{% admonition type="info" name="Note" %}
|
||||
|
||||
You can determine if a `Payment` or `OfferCreate` transaction interacted with an AMM by checking for a [`RippleState`](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) ledger entry in the transaction metadata. A `Flags` value of `16777216` indicates AMM liquidity was consumed.
|
||||
|
||||
{% /admonition %}
|
||||
|
||||
An AMM sets its exchange rate based on the balance of assets in the pool. When you trade against an AMM, the exchange rate adjusts based on how much your trade shifts the balance of assets the AMM holds. As its supply of one asset goes down, the price of that asset goes up; as its supply of an asset goes up, the price of that asset goes down.
|
||||
|
||||

|
||||
|
||||
@@ -227,15 +227,15 @@ If the payment contains a `CreatedNode` with `"LedgerEntryType": "AccountRoot"`,
|
||||
|
||||
#### Token Payments
|
||||
|
||||
Payments involving tokens are a bit more complicated.
|
||||
Payments involving [trust line tokens](../../tokens/fungible-tokens/trust-line-tokens.md) are a bit more complicated.
|
||||
|
||||
All changes in token balances are reflected in [RippleState objects](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md), which represent [trust lines](../../tokens/fungible-tokens/index.md). An increase to one party's balance on a trust line is considered to decrease the counterparty's balance by equal amount; in the metadata, this is only recorded as a single change to the shared `Balance` for the RippleState object. Whether this change is recorded as an "increase" or "decrease" depends on which account has the numerically higher address.
|
||||
All changes to trust line token balances are reflected in [RippleState entries](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md), which represent [trust lines](../../tokens/fungible-tokens/index.md). An increase to one party's balance on a trust line is considered to decrease the counterparty's balance by equal amount; transaction metadata records only a single net change to the shared `Balance` of a `RippleState` entry. Whether this change is recorded as an "increase" or "decrease" depends on which account has the numerically higher address.
|
||||
|
||||
A single payment may go across a long [path](../../tokens/fungible-tokens/paths.md) consisting of several trust lines and order books. The process of changing the balances on several trust lines to connect parties indirectly is called [rippling](../../tokens/fungible-tokens/rippling.md). Depending on the `issuer` specified in the transaction's `Amount` field, it is also possible that the amount delivered may be split between several trust lines (`RippleState` accounts) connected to the destination account.
|
||||
A single payment may go across a long [path](../../tokens/fungible-tokens/paths.md) consisting of several trust lines and order books. The process of changing the balances on several trust lines to connect parties indirectly is called [rippling](../../tokens/fungible-tokens/rippling.md). Depending on the `issuer` specified in the transaction's `Amount` field, it is also possible that the amount delivered may be split between several trust lines (separate RippleState entries) connected to the destination account.
|
||||
|
||||
{% admonition type="success" name="Tip" %}The order that modified objects are presented in the metadata does not necessarily match the order those objects were visited while processing a payment. To better understand payment execution, it may help to reorder `AffectedNodes` members to reconstruct the paths the funds took through the ledger.{% /admonition %}
|
||||
|
||||
Cross-currency payments consume [Offers](../../../references/protocol/ledger-data/ledger-entry-types/offer.md) in part or entirely to change between different currency codes and issuers. If a transaction shows `DeletedNode` objects for `Offer` types, that can indicate an Offer that was fully consumed, or an Offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing. If a transaction shows a `ModifiedNode` of type `Offer`, that indicates an Offer that was partially consumed.
|
||||
Cross-currency payments use [offers](../../tokens/decentralized-exchange/offers.md) and [AMMs](../../tokens/decentralized-exchange/automated-market-makers.md) to convert between different currency codes and issuers. Offers can be partially or fully consumed. If a transaction shows `DeletedNode` objects for `Offer` types, that can indicate an offer that was fully consumed, or an offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing. If a transaction shows a `ModifiedNode` of type `Offer`, that indicates an offer that was partially consumed.
|
||||
|
||||
The [`QualityIn` and `QualityOut` settings of trust lines](../../../references/protocol/transactions/types/trustset.md) can affect how one side of a trust line values the token, so that the numeric change in balances is different from how the sender values that token. The `delivered_amount` shows how much was delivered as valued by the recipient.
|
||||
|
||||
@@ -243,9 +243,17 @@ If the amount to be sent or received is outside of the [token precision](../../.
|
||||
|
||||
Depending on the length of the [paths](../../tokens/fungible-tokens/paths.md), the metadata for cross-currency payments can be _long_. For example, [transaction 8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B) delivered 2.788 GCB issued by `rHaaans...`, spending XRP but passing through USD from 2 issuers, paying XRP to 2 accounts, removing an unfunded offer from `r9ZoLsJ...` to trade EUR for ETH, plus bookkeeping for a total of 17 different ledger objects modified. <!-- SPELLING_IGNORE: gcb -->
|
||||
|
||||
#### Using AMM Liquidity
|
||||
|
||||
You can tell if an AMM was involved in a transaction by looking for [RippleState entries](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) that belong to an AMM. Check the `Flags` value of each `RippleState` entry in the `AffectedNodes` array; if the [`lsfAMMNode` flag](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestate-flags) is enabled, then that trust line is connected to an AMM. Flags are combined using bitwise operations. To check if `lsfAMMNode` is enabled, use a bitwise-AND operator, like the following pseudo-code:
|
||||
|
||||
```
|
||||
isEnabled = RippleState.Flags & lsfAMMNode
|
||||
```
|
||||
|
||||
### Offers
|
||||
|
||||
An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with `"LedgerEntryType": "Offer"` to see if the transaction added a new Offer to the ledger's order books. For example:
|
||||
An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with `"LedgerEntryType": "Offer"` to see if the transaction added a new Offer entry to the ledger's order books. For example:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -268,11 +276,11 @@ An [OfferCreate transaction][] may or may not create an object in the ledger, de
|
||||
}
|
||||
```
|
||||
|
||||
A `ModifiedNode` of type `Offer` indicates an Offer that was matched and partially consumed. A single transaction can consume a large number of Offers. An Offer to trade two tokens might also consume Offers to trade XRP because of [auto-bridging](../../tokens/decentralized-exchange/autobridging.md). All or part of an exchange can be auto-bridged.
|
||||
A `ModifiedNode` of type `Offer` indicates an offer that was matched and partially consumed. A single transaction can consume a large number of offers. An offer to trade two tokens might also consume offers to trade XRP because of [auto-bridging](../../tokens/decentralized-exchange/autobridging.md). All or part of an exchange can be auto-bridged. Offers can also use AMMs to convert currency; you can recognize when this happens by [checking for a `RippleState` entry with the `lsfAMMNode` flag](#using-amm-liquidity) in the `AffectedNodes` array.
|
||||
|
||||
A `DeletedNode` of type `Offer` can indicate a matching Offer that was fully consumed, an Offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing, or an Offer that was canceled as part of placing a new Offer. You can recognize a canceled Offer because the `Account` that placed it is the sender of the transaction that deleted it.
|
||||
A `DeletedNode` of type `Offer` can indicate a matching offer that was fully consumed, an offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing, or an offer that was canceled as part of placing a new offer. You can recognize a canceled offer because the `Account` that placed it is the sender of the transaction that deleted it.
|
||||
|
||||
Example of a deleted Offer:
|
||||
Example of a deleted offer:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -300,11 +308,11 @@ Example of a deleted Offer:
|
||||
}
|
||||
```
|
||||
|
||||
Offers can create, delete, and modify both types of [DirectoryNode objects](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md), to keep track of who placed which Offers and which Offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.
|
||||
Offers can create, delete, and modify [DirectoryNode entries](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md), both to keep track of who placed which offers and which offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.
|
||||
|
||||
An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no Offer to delete. Look for a `DeletedNode` of type `Offer` to confirm that the transaction actually deleted an Offer. If not, the Offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
|
||||
An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no offer to delete. Look for a `DeletedNode` of type `Offer` to confirm that the transaction actually deleted an offer. If not, the offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
|
||||
|
||||
If an OfferCreate transaction shows a `CreatedNode` of type `RippleState`, that indicates that [the Offer created a trust line](../../tokens/decentralized-exchange/offers.md#offers-and-trust) to hold a token received in the trade.
|
||||
If an OfferCreate transaction shows a `CreatedNode` of type `RippleState`, that indicates that [the offer created a trust line](../../tokens/decentralized-exchange/offers.md#offers-and-trust) to hold a token received in the trade.
|
||||
|
||||
### Escrows
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
seo:
|
||||
description: A trust line, which tracks the net balance of fungible tokens between two accounts.
|
||||
labels:
|
||||
- Tokens
|
||||
- Tokens
|
||||
---
|
||||
# RippleState
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L277-L289 "Source")
|
||||
@@ -69,19 +69,19 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
|
||||
`RippleState` entries can have the following flags combined into the `Flags` field:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Corresponding [TrustSet Flag](../../transactions/types/trustset.md#trustset-flags) | Description |
|
||||
|-------------------|--------------|---------------|-----------------|---------|
|
||||
| `lsfAMMNode` | `0x01000000` | 16777216 | (None) | This entry consumed AMM liquidity to complete a [`Payment`](../../transactions/types/payment.md) transaction. |
|
||||
| `lsfLowReserve` | `0x00010000` | 65536 | (None) | This entry [contributes to the low account's owner reserve](#ripplestate-reserve). |
|
||||
| `lsfHighReserve` | `0x00020000` | 131072 | (None) | This entry [contributes to the high account's owner reserve](#ripplestate-reserve). |
|
||||
| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | The low account has authorized the high account to hold tokens issued by the low account. |
|
||||
| `lsfHighAuth` | `0x00080000` | 524288 | `tfSetAuth` | The high account has authorized the low account to hold tokens issued by the high account. |
|
||||
| `lsfLowNoRipple` | `0x00100000` | 1048576 | `tfSetNoRipple` | The low account [has disabled rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) from this trust line. |
|
||||
| `lsfHighNoRipple` | `0x00200000` | 2097152 | `tfSetNoRipple` | The high account [has disabled rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) from this trust line. |
|
||||
| `lsfLowFreeze` | `0x00400000` | 4194304 | `tfSetFreeze` | The low account has frozen the trust line, preventing the high account from transferring the asset. |
|
||||
| `lsfHighFreeze` | `0x00800000` | 8388608 | `tfSetFreeze` | The high account has frozen the trust line, preventing the low account from transferring the asset. |
|
||||
| `lsfLowDeepFreeze` | `0x02000000` | 33554432 |`tfSetLowDeepFreeze` | The low account has deep-frozen the trust line, preventing the high account from sending and receiving the asset. |
|
||||
| `lsfHighDeepFreeze` | `0x04000000` | 67108864 | `tfSetHighDeepFreeze` | The high account has deep-frozen the trust line, preventing the low account from sending and receiving the asset. |
|
||||
| Flag Name | Hex Value | Decimal Value | Corresponding [TrustSet Flag](../../transactions/types/trustset.md#trustset-flags) | Description |
|
||||
|---------------------|--------------|---------------|-----------------------|---------|
|
||||
| `lsfLowReserve` | `0x00010000` | 65536 | (None) | This entry [contributes to the low account's owner reserve](#ripplestate-reserve). |
|
||||
| `lsfHighReserve` | `0x00020000` | 131072 | (None) | This entry [contributes to the high account's owner reserve](#ripplestate-reserve). |
|
||||
| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | The low account has authorized the high account to hold tokens issued by the low account. |
|
||||
| `lsfHighAuth` | `0x00080000` | 524288 | `tfSetAuth` | The high account has authorized the low account to hold tokens issued by the high account. |
|
||||
| `lsfLowNoRipple` | `0x00100000` | 1048576 | `tfSetNoRipple` | The low account [has disabled rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) from this trust line. |
|
||||
| `lsfHighNoRipple` | `0x00200000` | 2097152 | `tfSetNoRipple` | The high account [has disabled rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) from this trust line. |
|
||||
| `lsfLowFreeze` | `0x00400000` | 4194304 | `tfSetFreeze` | The low account has frozen the trust line, preventing the high account from transferring the asset. |
|
||||
| `lsfHighFreeze` | `0x00800000` | 8388608 | `tfSetFreeze` | The high account has frozen the trust line, preventing the low account from transferring the asset. |
|
||||
| `lsfAMMNode` | `0x01000000` | 16777216 | (None) | This trust line holds one of the assets in an [Automated Market Maker](../../../../concepts/tokens/decentralized-exchange/automated-market-makers.md)'s pool; one of this trust line's accounts is the AMM, and the other is the issuer of the token. {% amendment-disclaimer name="AMM" /%} |
|
||||
| `lsfLowDeepFreeze` | `0x02000000` | 33554432 |`tfSetLowDeepFreeze` | The low account has deep-frozen the trust line, preventing the high account from sending and receiving the asset. {% amendment-disclaimer name="DeepFreeze" /%} |
|
||||
| `lsfHighDeepFreeze` | `0x04000000` | 67108864 | `tfSetHighDeepFreeze` | The high account has deep-frozen the trust line, preventing the low account from sending and receiving the asset. {% amendment-disclaimer name="DeepFreeze" /%} |
|
||||
|
||||
The two accounts connected by the trust line can each change their own settings with a [TrustSet transaction][].
|
||||
|
||||
|
||||
Reference in New Issue
Block a user