mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 19:55:54 +00:00
@@ -15,6 +15,8 @@ An offer in the ledger can be fulfilled either by additional OfferCreate transac
|
|||||||
|
|
||||||
You can create an offer so long as you have at least some (any positive, nonzero amount) of the currency specified by the `TakerGets` parameter of the offer. The offer sells as much of the currency as you have, up to the `TakerGets` amount, until the `TakerPays` amount is satisfied. An offer cannot place anyone in debt.
|
You can create an offer so long as you have at least some (any positive, nonzero amount) of the currency specified by the `TakerGets` parameter of the offer. The offer sells as much of the currency as you have, up to the `TakerGets` amount, until the `TakerPays` amount is satisfied. An offer cannot place anyone in debt.
|
||||||
|
|
||||||
|
If you place an offer that crosses any offers you have existing in the ledger, the old offers are automatically canceled regardless of the amounts involved.
|
||||||
|
|
||||||
It is possible for an offer to become temporarily or permanently _unfunded_:
|
It is possible for an offer to become temporarily or permanently _unfunded_:
|
||||||
|
|
||||||
* If the creator no longer has any of the `TakerGets` currency.
|
* If the creator no longer has any of the `TakerGets` currency.
|
||||||
|
|||||||
@@ -4,8 +4,9 @@ In the XRP Ledger, "rippling" describes a process of atomic net settlement betwe
|
|||||||
|
|
||||||
Rippling only occurs along the [paths](paths.html) of a payment.
|
Rippling only occurs along the [paths](paths.html) of a payment.
|
||||||
|
|
||||||
For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [NoRipple Flag](#the-noripple-flag) disables rippling on all trust lines by default, unless the account enables rippling by default by enabling the [DefaultRipple flag](#the-defaultripple-flag).
|
For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [NoRipple Flag](#the-noripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [DefaultRipple flag](#the-defaultripple-flag).
|
||||||
|
|
||||||
|
**Caution:** If you create a trust line to another address, you must explicitly enable the tfSetNoRipple flag to block rippling on your side of that trust line.
|
||||||
|
|
||||||
## Example of Rippling
|
## Example of Rippling
|
||||||
|
|
||||||
@@ -25,7 +26,7 @@ Non-issuing accounts, especially liquidity providers who may hold balances from
|
|||||||
|
|
||||||
The "NoRipple" flag is a setting on a trust line. When two trust lines both have NoRipple enabled by the same address, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers of the same currency.
|
The "NoRipple" flag is a setting on a trust line. When two trust lines both have NoRipple enabled by the same address, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers of the same currency.
|
||||||
|
|
||||||
An account can disable NoRipple on a single trust line, which can allow rippling through any pair that includes that trust line. The account can also enable rippling globally by enabling the [DefaultRipple flag](#the-defaultripple-flag).
|
An account can disable NoRipple on a single trust line, which can allow rippling through any pair that includes that trust line. The account can also enable rippling by default by enabling the [DefaultRipple flag](#the-defaultripple-flag).
|
||||||
|
|
||||||
For example, imagine Emily has money issued by two different financial institutions, like so
|
For example, imagine Emily has money issued by two different financial institutions, like so
|
||||||
|
|
||||||
@@ -52,7 +53,9 @@ The NoRipple flag makes certain paths invalid, so that they cannot be used to ma
|
|||||||
|
|
||||||
## The DefaultRipple Flag
|
## The DefaultRipple Flag
|
||||||
|
|
||||||
The DefaultRipple flag is an account setting that enables rippling on all trust lines by default. Gateways and other currency issuers MUST enable this flag for other addresses to be able to send those the currencies among themselves.
|
The DefaultRipple flag is an account setting that enables rippling on all incoming trust lines by default. Gateways and other currency issuers MUST enable this flag for their customers to be able to send those currencies to each other.
|
||||||
|
|
||||||
|
The DefaultRipple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the DefaultRipple setting of your account, trust lines that were created before the change keep their existing NoRipple settings. You can use a [TrustSet transaction][] to change the NoRipple setting of a trust line to match your address's new default.
|
||||||
|
|
||||||
For more information, see [DefaultRipple in 'Becoming an XRP Ledger Gateway'](become-an-xrp-ledger-gateway.html#defaultripple).
|
For more information, see [DefaultRipple in 'Becoming an XRP Ledger Gateway'](become-an-xrp-ledger-gateway.html#defaultripple).
|
||||||
|
|
||||||
|
|||||||
@@ -27,6 +27,7 @@ For the most part, transactions with `tec` codes take no action other than to de
|
|||||||
| `tecNO_DST_INSUF_XRP` | 125 | The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XRP to create it. |
|
| `tecNO_DST_INSUF_XRP` | 125 | The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XRP to create it. |
|
||||||
| `tecNO_ENTRY` | 140 | Reserved for future use. |
|
| `tecNO_ENTRY` | 140 | Reserved for future use. |
|
||||||
| `tecNO_ISSUER` | 133 | The account specified in the `issuer` field of a currency amount does not exist. |
|
| `tecNO_ISSUER` | 133 | The account specified in the `issuer` field of a currency amount does not exist. |
|
||||||
|
| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the tfFillOrKill flag and could not be filled, so it was killed. _(Requires the [fix1578 amendment](known-amendments.html#fix1578).)_ |
|
||||||
| `tecNO_LINE` | 135 | The `TakerPays` field of the [OfferCreate transaction][] specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, `tecNO_AUTH` occurs instead. |
|
| `tecNO_LINE` | 135 | The `TakerPays` field of the [OfferCreate transaction][] specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, `tecNO_AUTH` occurs instead. |
|
||||||
| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) |
|
| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) |
|
||||||
| `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
|
| `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
|
||||||
|
|||||||
@@ -45,15 +45,19 @@ Transactions of the OfferCreate type support additional values in the [`Flags` f
|
|||||||
| Flag Name | Hex Value | Decimal Value | Description |
|
| Flag Name | Hex Value | Decimal Value | Description |
|
||||||
|:--------------------|:-----------|:--------------|:--------------------------|
|
|:--------------------|:-----------|:--------------|:--------------------------|
|
||||||
| tfPassive | 0x00010000 | 65536 | If enabled, the offer does not consume offers that exactly match it, and instead becomes an Offer object in the ledger. It still consumes offers that cross it. |
|
| tfPassive | 0x00010000 | 65536 | If enabled, the offer does not consume offers that exactly match it, and instead becomes an Offer object in the ledger. It still consumes offers that cross it. |
|
||||||
| tfImmediateOrCancel | 0x00020000 | 131072 | Treat the offer as an [Immediate or Cancel order](http://en.wikipedia.org/wiki/Immediate_or_cancel). If enabled, the offer never becomes a ledger object: it only tries to match existing offers in the ledger. |
|
| tfImmediateOrCancel | 0x00020000 | 131072 | Treat the offer as an [Immediate or Cancel order](http://en.wikipedia.org/wiki/Immediate_or_cancel). If enabled, the offer never becomes a ledger object: it only tries to match existing offers in the ledger. If the offer cannot match any offers immediately, it executes "successfully" without trading any currency. In this case, the transaction has the [result code](transaction-results.html) `tesSUCCESS`, but creates no [Offer objects](offer.html) in the ledger. |
|
||||||
| tfFillOrKill | 0x00040000 | 262144 | Treat the offer as a [Fill or Kill order](http://en.wikipedia.org/wiki/Fill_or_kill). Only try to match existing offers in the ledger, and only do so if the entire `TakerPays` quantity can be obtained. |
|
| tfFillOrKill | 0x00040000 | 262144 | Treat the offer as a [Fill or Kill order](http://en.wikipedia.org/wiki/Fill_or_kill). Only try to match existing offers in the ledger, and only do so if the entire `TakerPays` quantity can be obtained. If the [fix1578 amendment](known-amendments.html#fix1578) is enabled and the offer cannot be executed when placed, the transaction has the [result code](transaction-results.html) `tecKILLED`; otherwise, the transaction uses the result code `tesSUCCESS` even when it was killed without trading any currency. |
|
||||||
| tfSell | 0x00080000 | 524288 | Exchange the entire `TakerGets` amount, even if it means obtaining more than the `TakerPays` amount in exchange. |
|
| tfSell | 0x00080000 | 524288 | Exchange the entire `TakerGets` amount, even if it means obtaining more than the `TakerPays` amount in exchange. |
|
||||||
|
|
||||||
The following invalid flag combination prompts a `temINVALID_FLAG` error:
|
The following invalid flag combination prompts a `temINVALID_FLAG` error:
|
||||||
|
|
||||||
* tfImmediateOrCancel and tfFillOrKill
|
* tfImmediateOrCancel and tfFillOrKill
|
||||||
|
|
||||||
**Note:** When an OfferCreate uses tfImmediateOrCancel or tfFillOrKill and the offer cannot be executed when placed, the transaction may conclude "successfully" without trading any currency or having any effect on the order books. In this case, the transaction has the [result code](transaction-results.html) `tesSUCCESS`, it pays the [transaction cost][] and uses up a `Sequence` number, but has no other effect.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!--{# common link defs #}-->
|
<!--{# common link defs #}-->
|
||||||
{% include '_snippets/rippled-api-links.md' %}
|
{% include '_snippets/rippled-api-links.md' %}
|
||||||
|
|||||||
@@ -42,7 +42,7 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel
|
|||||||
| Flag Name | Hex Value | Decimal Value | Description |
|
| Flag Name | Hex Value | Decimal Value | Description |
|
||||||
|:----------------|:-----------|:--------------|:------------------------------|
|
|:----------------|:-----------|:--------------|:------------------------------|
|
||||||
| tfSetfAuth | 0x00010000 | 65536 | Authorize the other party to hold issuances from this account. (No effect unless using the [*asfRequireAuth* AccountSet flag](accountset.html#accountset-flags).) Cannot be unset. |
|
| tfSetfAuth | 0x00010000 | 65536 | Authorize the other party to hold issuances from this account. (No effect unless using the [*asfRequireAuth* AccountSet flag](accountset.html#accountset-flags).) Cannot be unset. |
|
||||||
| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. (See [No Ripple](rippling.html) for details.) |
|
| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. (See [No Ripple](rippling.html) for details.) If the [fix1578 amendment](known-amendments.html#fix1578) is enabled, a transaction that uses this flag and cannot enable NoRipple fails with the result code `tecNO_PERMISSION`. If the amendment is not enabled, the transaction can result in `tesSUCCESS` (making any other changes it can) even if it cannot enable NoRipple on the trust line. |
|
||||||
| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. (See [NoRipple](rippling.html) for details.) |
|
| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. (See [NoRipple](rippling.html) for details.) |
|
||||||
| tfSetFreeze | 0x00100000 | 1048576 | [Freeze](freezes.html) the trustline. |
|
| tfSetFreeze | 0x00100000 | 1048576 | [Freeze](freezes.html) the trustline. |
|
||||||
| tfClearFreeze | 0x00200000 | 2097152 | [Unfreeze](freezes.html) the trustline. |
|
| tfClearFreeze | 0x00200000 | 2097152 | [Unfreeze](freezes.html) the trustline. |
|
||||||
|
|||||||
Reference in New Issue
Block a user