mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-30 08:35:50 +00:00
Migrate old callout syntax
This commit is contained in:
mDuo13
@@ -52,7 +52,7 @@ Some fields can be automatically filled in before a transaction is signed, eithe
|
||||
|
||||
* `Fee` - Automatically fill in the [Transaction Cost][] based on the network.
|
||||
|
||||
**Note:** When using `rippled`'s [sign command][], you can limit the maximum possible auto-filled value, using the `fee_mult_max` and `fee_div_max` parameters.)
|
||||
{% admonition type="info" name="Note" %}When using `rippled`'s [sign command][], you can limit the maximum possible auto-filled value, using the `fee_mult_max` and `fee_div_max` parameters.){% /admonition %}
|
||||
|
||||
* `Sequence` - Automatically use the next sequence number for the account sending the transaction.
|
||||
|
||||
@@ -81,7 +81,7 @@ The only flag that applies globally to all transactions is as follows:
|
||||
|
||||
When using the [sign method][] (or [submit method][] in "sign-and-submit" mode), `rippled` adds a `Flags` field with `tfFullyCanonicalSig` enabled unless the `Flags` field is already present. The `tfFullyCanonicalSig` flag is not automatically enabled if `Flags` is explicitly specified. The flag is not automatically enabled when using the [sign_for method][] to add a signature to a multi-signed transaction.
|
||||
|
||||
**Note:** The `tfFullyCanonicalSig` flag was used from 2014 until 2020 to protect against [transaction malleability](../../../concepts/transactions/finality-of-results/transaction-malleability.md) while maintaining compatibility with legacy signing software. The [RequireFullyCanonicalSig amendment][] ended compatibility with such legacy software and made the protections the default for all transactions. If you are using a [parallel network](../../../concepts/networks-and-servers/parallel-networks.md) that does not have RequireFullyCanonicalSig enabled, you should always enable the `tfFullyCanonicalSig` flag to protect against transaction malleability.
|
||||
{% admonition type="info" name="Note" %}The `tfFullyCanonicalSig` flag was used from 2014 until 2020 to protect against [transaction malleability](../../../concepts/transactions/finality-of-results/transaction-malleability.md) while maintaining compatibility with legacy signing software. The [RequireFullyCanonicalSig amendment][] ended compatibility with such legacy software and made the protections the default for all transactions. If you are using a [parallel network](../../../concepts/networks-and-servers/parallel-networks.md) that does not have RequireFullyCanonicalSig enabled, you should always enable the `tfFullyCanonicalSig` flag to protect against transaction malleability.{% /admonition %}
|
||||
|
||||
### Flag Ranges
|
||||
|
||||
@@ -93,7 +93,7 @@ A transaction's `Flags` field can contain flags that apply at different levels o
|
||||
| Type-based Flags | `0x00ff0000` | Flags with different meanings depending on the [transaction type](types/index.md) that uses them. |
|
||||
| Reserved Flags | `0x0000ffff` | Flags that are not currently defined. A transaction is only valid if these flags are disabled. |
|
||||
|
||||
**Note:** The [AccountSet transaction][] type has [its own non-bitwise flags](types/accountset.md#accountset-flags), which serve a similar purpose to type-based flags. [Ledger objects](../ledger-data/ledger-entry-types/index.md) also have a `Flags` field with different bitwise flag definitions.
|
||||
{% admonition type="info" name="Note" %}The [AccountSet transaction][] type has [its own non-bitwise flags](types/accountset.md#accountset-flags), which serve a similar purpose to type-based flags. [Ledger objects](../ledger-data/ledger-entry-types/index.md) also have a `Flags` field with different bitwise flag definitions.{% /admonition %}
|
||||
|
||||
|
||||
## Memos Field
|
||||
|
||||
@@ -10,7 +10,7 @@ labels:
|
||||
|
||||
Transaction metadata is a section of data that gets added to a transaction after it is processed. Any transaction that gets included in a ledger has metadata, regardless of whether it is successful. The transaction metadata describes the outcome of the transaction in detail.
|
||||
|
||||
**Warning:** The changes described in transaction metadata are only final if the transaction is in a validated ledger version.
|
||||
{% admonition type="danger" name="Warning" %}The changes described in transaction metadata are only final if the transaction is in a validated ledger version.{% /admonition %}
|
||||
|
||||
Some fields that may appear in transaction metadata include:
|
||||
|
||||
@@ -242,7 +242,7 @@ A `ModifiedNode` object contains the following fields:
|
||||
| `PreviousTxnID` | String - [Hash][] | _(May be omitted)_ The [identifying hash][] of the previous transaction to modify this ledger entry. Omitted for ledger entry types that do not have a `PreviousTxnID` field. |
|
||||
| `PreviousTxnLgrSeq` | Number - [Ledger Index][] | _(May be omitted)_ The [Ledger Index][] of the ledger version containing the previous transaction to modify this ledger entry. Omitted for ledger entry types that do not have a `PreviousTxnLgrSeq` field. |
|
||||
|
||||
**Note:** If the modified ledger entry has `PreviousTxnID` and `PreviousTxnLgrSeq` fields, the transaction always updates them with the transaction's own identifying hash and the index of the ledger version that included the transaction, but these fields' new value is not listed in the `FinalFields` of the `ModifiedNode` object, and their previous values are listed at the top level of the `ModifiedNode` object rather than in the nested `PreviousFields` object.
|
||||
{% admonition type="info" name="Note" %}If the modified ledger entry has `PreviousTxnID` and `PreviousTxnLgrSeq` fields, the transaction always updates them with the transaction's own identifying hash and the index of the ledger version that included the transaction, but these fields' new value is not listed in the `FinalFields` of the `ModifiedNode` object, and their previous values are listed at the top level of the `ModifiedNode` object rather than in the nested `PreviousFields` object.{% /admonition %}
|
||||
|
||||
|
||||
## NFT Fields
|
||||
@@ -267,7 +267,7 @@ The `rippled` server provides a `delivered_amount` field in JSON transaction met
|
||||
|
||||
If both conditions are true, then `delivered_amount` contains the string value `unavailable` instead of an actual amount. If this happens, you can only figure out the actual delivered amount by reading the `AffectedNodes` in the transaction's metadata.
|
||||
|
||||
**Note:** The `delivered_amount` field is generated on-demand for the request, and is not included in the binary format for transaction metadata, nor is it used when calculating the [hash](../data-types/basic-data-types.md#hashes) of the transaction metadata. In contrast, the `DeliveredAmount` field _is_ included in the binary format for partial payment transactions after 2014-01-20.
|
||||
{% admonition type="info" name="Note" %}The `delivered_amount` field is generated on-demand for the request, and is not included in the binary format for transaction metadata, nor is it used when calculating the [hash](../data-types/basic-data-types.md#hashes) of the transaction metadata. In contrast, the `DeliveredAmount` field _is_ included in the binary format for partial payment transactions after 2014-01-20.{% /admonition %}
|
||||
|
||||
See also: [Partial Payments](../../../concepts/payment-types/partial-payments.md)
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ labels:
|
||||
|
||||
A `SetFee` [pseudo-transaction](pseudo-transaction-types.md) marks a change in [transaction cost](../../../../concepts/transactions/transaction-cost.md) or [reserve requirements](../../../../concepts/accounts/reserves.md) as a result of [Fee Voting](../../../../concepts/consensus-protocol/fee-voting.md).
|
||||
|
||||
**Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers.
|
||||
{% admonition type="info" name="Note" %}You cannot send a pseudo-transaction, but you may find one when processing ledgers.{% /admonition %}
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ _(Added by the [NegativeUNL amendment][].)_
|
||||
|
||||
A `UNLModify` [pseudo-transaction](pseudo-transaction-types.md) marks a change to the [Negative UNL](../../../../concepts/consensus-protocol/negative-unl.md), indicating that a trusted validator has gone offline or come back online.
|
||||
|
||||
**Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers.
|
||||
{% admonition type="info" name="Note" %}You cannot send a pseudo-transaction, but you may find one when processing ledgers.{% /admonition %}
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ The `rippled` server summarizes transaction results with result codes, which app
|
||||
|
||||
The `rippled` server automatically retries failed transactions. It is important not to assume that a transaction has completely failed based on a tentative failure result. A transaction may later succeed unless its success or failure is [final](../../../../concepts/transactions/finality-of-results/index.md).
|
||||
|
||||
**Warning:** Transactions' provisional result codes may differ than their final result. Transactions that provisionally succeeded may eventually fail and transactions that provisionally failed may eventually succeed. Transactions that provisionally failed may also eventually fail with a different code. See [finality of results](../../../../concepts/transactions/finality-of-results/index.md) for how to know when a transaction's result is final.
|
||||
{% admonition type="danger" name="Warning" %}Transactions' provisional result codes may differ than their final result. Transactions that provisionally succeeded may eventually fail and transactions that provisionally failed may eventually succeed. Transactions that provisionally failed may also eventually fail with a different code. See [finality of results](../../../../concepts/transactions/finality-of-results/index.md) for how to know when a transaction's result is final.{% /admonition %}
|
||||
|
||||
The distinction between a local error (`tel`) and a malformed transaction (`tem`) is a matter of protocol-level rules. For example, the protocol sets no limit on the maximum number of paths that can be included in a transaction. However, a server may define a finite limit of paths it can process. If two different servers are configured differently, then one of them may return a `tel` error for a transaction with many paths, while the other server could successfully process the transaction. If enough servers are able to process the transaction that it survives consensus, then it can still be included in a validated ledger.
|
||||
|
||||
@@ -50,6 +50,6 @@ If nothing went wrong when submitting and applying the transaction locally, the
|
||||
"engine_result_message": "The transaction was applied. Only final in a validated ledger."
|
||||
```
|
||||
|
||||
**Note:** A successful result at this stage does not indicate that the transaction has completely succeeded; only that it was successfully applied to the provisional version of the ledger kept by the local server. Failed results at this stage are also provisional and may change. See [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) for details.
|
||||
{% admonition type="info" name="Note" %}A successful result at this stage does not indicate that the transaction has completely succeeded; only that it was successfully applied to the provisional version of the ledger kept by the local server. Failed results at this stage are also provisional and may change. See [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) for details.{% /admonition %}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -13,7 +13,7 @@ These codes indicate that the transaction failed, but it was applied to a ledger
|
||||
|
||||
Transactions with `tec` codes destroy the XRP paid as a [transaction cost](../../../../concepts/transactions/transaction-cost.md), and consume a [sequence number](../../data-types/basic-data-types.md#account-sequence). For the most part, the transactions take no other action, but there are some exceptions. For example, a transaction that results in `tecOVERSIZE` still cleans up some [unfunded offers](../../../../concepts/tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer). Always look at the [transaction metadata](../metadata.md) to see precisely what a transaction did.
|
||||
|
||||
**Caution:** A transaction that provisionally failed with a `tec` code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) and [Reliable Transaction Submission](../../../../concepts/transactions/reliable-transaction-submission.md).
|
||||
{% admonition type="warning" name="Caution" %}A transaction that provisionally failed with a `tec` code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) and [Reliable Transaction Submission](../../../../concepts/transactions/reliable-transaction-submission.md).{% /admonition %}
|
||||
|
||||
| Code | Value | Explanation |
|
||||
|:---------------------------|:------|:----------------------------------------|
|
||||
|
||||
@@ -11,7 +11,7 @@ labels:
|
||||
|
||||
These codes indicate that the transaction failed and was not included in a ledger, but the transaction could have succeeded in some theoretical ledger. Typically this means that the transaction can no longer succeed in any future ledger. They have numerical values in the range -199 to -100. The exact code for any given error is subject to change, so don't rely on it.
|
||||
|
||||
**Caution:** Transactions with `tef` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) and [Reliable Transaction Submission](../../../../concepts/transactions/reliable-transaction-submission.md).
|
||||
{% admonition type="warning" name="Caution" %}Transactions with `tef` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) and [Reliable Transaction Submission](../../../../concepts/transactions/reliable-transaction-submission.md).{% /admonition %}
|
||||
|
||||
| Code | Explanation |
|
||||
|:-----------------------|:----------------------------------------------------|
|
||||
|
||||
@@ -10,7 +10,7 @@ labels:
|
||||
|
||||
These codes indicate an error in the local server processing the transaction; it is possible that another server with a different configuration or load level could process the transaction successfully. They have numerical values in the range -399 to -300. The exact code for any given error is subject to change, so don't rely on it.
|
||||
|
||||
**Caution:** Transactions with `tel` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, these transactions may be automatically cached and retried later. Transactions that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) and [Reliable Transaction Submission](../../../../concepts/transactions/reliable-transaction-submission.md).
|
||||
{% admonition type="warning" name="Caution" %}Transactions with `tel` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, these transactions may be automatically cached and retried later. Transactions that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](../../../../concepts/transactions/finality-of-results/index.md) and [Reliable Transaction Submission](../../../../concepts/transactions/reliable-transaction-submission.md).{% /admonition %}
|
||||
|
||||
| Code | Explanation |
|
||||
|:----------------|:------------|
|
||||
|
||||
@@ -10,7 +10,7 @@ labels:
|
||||
|
||||
These codes indicate that the transaction was malformed, and cannot succeed according to the XRP Ledger protocol. They have numerical values in the range -299 to -200. The exact code for any given error is subject to change, so don't rely on it.
|
||||
|
||||
**Tip:** Transactions with `tem` codes are not applied to ledgers, and cannot cause any changes to XRP Ledger state. A `tem` result is final unless the rules for a valid transaction change. (For example, using functionality from an [Amendment](../../../../concepts/networks-and-servers/amendments.md) before that amendment is enabled results in `temDISABLED`; such a transaction could succeed later if it becomes valid when the amendment is enabled.)
|
||||
{% admonition type="success" name="Tip" %}Transactions with `tem` codes are not applied to ledgers, and cannot cause any changes to XRP Ledger state. A `tem` result is final unless the rules for a valid transaction change. (For example, using functionality from an [Amendment](../../../../concepts/networks-and-servers/amendments.md) before that amendment is enabled results in `temDISABLED`; such a transaction could succeed later if it becomes valid when the amendment is enabled.){% /admonition %}
|
||||
|
||||
| Code | Explanation |
|
||||
|:------------------------------|:----------------------------------------------|
|
||||
|
||||
@@ -101,7 +101,7 @@ The following [Transaction flags](../common-fields.md#flags-field) (`tf` flags),
|
||||
| `tfDisallowXRP` | `0x00100000` | 1048576 | `asfDisallowXRP` (`SetFlag`) |
|
||||
| `tfAllowXRP` | `0x00200000` | 2097152 | `asfDisallowXRP` (`ClearFlag`) |
|
||||
|
||||
**Caution:** The numeric values of `tf` and `asf` flags in transactions do not match up with the values they set in the accounts "at rest" in the ledger. To read the flags of an account in the ledger, see [`AccountRoot` flags](../../ledger-data/ledger-entry-types/accountroot.md#accountroot-flags).
|
||||
{% admonition type="warning" name="Caution" %}The numeric values of `tf` and `asf` flags in transactions do not match up with the values they set in the accounts "at rest" in the ledger. To read the flags of an account in the ledger, see [`AccountRoot` flags](../../ledger-data/ledger-entry-types/accountroot.md#accountroot-flags).{% /admonition %}
|
||||
|
||||
|
||||
### Blocking Incoming Transactions
|
||||
|
||||
@@ -15,7 +15,7 @@ Create a new [Automated Market Maker](../../../../concepts/tokens/decentralized-
|
||||
|
||||
Creates both an [AMM entry][] and a [special AccountRoot entry](../../ledger-data/ledger-entry-types/accountroot.md#special-amm-accountroot-entries) to represent the AMM. Also transfers ownership of the starting balance of both assets from the sender to the created `AccountRoot` and issues an initial balance of liquidity provider tokens (LP Tokens) from the AMM account to the sender.
|
||||
|
||||
**Caution:** When you create the AMM, you should fund it with (approximately) equal-value amounts of each asset. Otherwise, other users can profit at your expense by trading with this AMM ([performing arbitrage](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/#price-arbitrage)). The currency risk that liquidity providers take on increases with the volatility (potential for imbalance) of the asset pair. The higher the trading fee, the more it offsets this risk, so it's best to set the trading fee based on the volatility of the asset pair.
|
||||
{% admonition type="warning" name="Caution" %}When you create the AMM, you should fund it with (approximately) equal-value amounts of each asset. Otherwise, other users can profit at your expense by trading with this AMM ([performing arbitrage](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/#price-arbitrage)). The currency risk that liquidity providers take on increases with the volatility (potential for imbalance) of the asset pair. The higher the trading fee, the more it offsets this risk, so it's best to set the trading fee based on the volatility of the asset pair.{% /admonition %}
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@ Withdraw assets from an [Automated Market Maker](../../../../concepts/tokens/dec
|
||||
| `EPrice` | [Currency Amount][] | Amount | No | The minimum effective price, in LP Token returned, to pay per unit of the asset to withdraw. |
|
||||
| `LPTokenIn` | [Currency Amount][] | Amount | No | How many of the AMM's LP Tokens to redeem. |
|
||||
|
||||
**Note:** For a double-asset withdrawal, it is possible for `Asset` to correspond to _either_ `Amount` or `Amount2` as long as `Asset2` corresponds to the other one. It is recommended to match them (that is, `Amount2` is an amount of the asset defined in `Asset2`) because it is less confusing that way.
|
||||
{% admonition type="info" name="Note" %}For a double-asset withdrawal, it is possible for `Asset` to correspond to _either_ `Amount` or `Amount2` as long as `Asset2` corresponds to the other one. It is recommended to match them (that is, `Amount2` is an amount of the asset defined in `Asset2`) because it is less confusing that way.{% /admonition %}
|
||||
|
||||
### AMMWithdraw Modes
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ Clawback is disabled by default. To use clawback, you must send an [AccountSet t
|
||||
|:-------------------|:----------|:------------------|:------------------|
|
||||
| `Amount` | [Currency Amount][] | Amount |Indicates the amount being clawed back, as well as the counterparty from which the amount is being clawed back. The quantity to claw back, in the `value` sub-field, must not be zero. If this is more than the current balance, the transaction claws back the entire balance. The sub-field `issuer` within `Amount` represents the token holder's account ID, rather than the issuer's.|
|
||||
|
||||
**Note:** In the XRP Ledger, the party that created a token is called the _issuer_, but trust lines are bidirectional and, under some configurations, both sides can be seen as the issuer. In this transaction, the token issuer's address is in the `Account` field, and the token holder's address is in the `Amount` field's `issuer` sub-field.
|
||||
{% admonition type="info" name="Note" %}In the XRP Ledger, the party that created a token is called the _issuer_, but trust lines are bidirectional and, under some configurations, both sides can be seen as the issuer. In this transaction, the token issuer's address is in the `Account` field, and the token holder's address is in the `Amount` field's `issuer` sub-field.{% /admonition %}
|
||||
|
||||
|
||||
## Error Cases
|
||||
|
||||
@@ -13,7 +13,7 @@ _Added by the [DepositPreauth amendment][]._
|
||||
|
||||
A DepositPreauth transaction gives another account pre-approval to deliver payments to the sender of this transaction. This is only useful if the sender of this transaction is using (or plans to use) [Deposit Authorization](../../../../concepts/accounts/depositauth.md).
|
||||
|
||||
**Tip:** You can use this transaction to preauthorize certain counterparties before you enable Deposit Authorization. This may be useful to ensure a smooth transition from not requiring deposit authorization to requiring it.
|
||||
{% admonition type="success" name="Tip" %}You can use this transaction to preauthorize certain counterparties before you enable Deposit Authorization. This may be useful to ensure a smooth transition from not requiring deposit authorization to requiring it.{% /admonition %}
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ _(Requires the [DID amendment][] {% not-enabled /%})_
|
||||
|
||||
Delete the [DID ledger entry](../../ledger-data/ledger-entry-types/did.md) associated with the specified `Account` field.
|
||||
|
||||
**Note:** This transaction only uses the [common fields][].
|
||||
{% admonition type="info" name="Note" %}This transaction only uses the [common fields][].{% /admonition %}
|
||||
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
@@ -40,7 +40,7 @@ Creates a new [DID ledger entry](../../ledger-data/ledger-entry-types/did.md) or
|
||||
|
||||
You must include either `Data`, `DIDDocument`, or `URI` when you submit the `DIDSet` transaction. If all three fields are missing, the transaction fails.
|
||||
|
||||
**Note:** To delete the `Data`, `DIDDocument`, or `URI` field from an existing DID ledger entry, add the field as an empty string.
|
||||
{% admonition type="info" name="Note" %}To delete the `Data`, `DIDDocument`, or `URI` field from an existing DID ledger entry, add the field as an empty string.{% /admonition %}
|
||||
|
||||
|
||||
## Error Cases
|
||||
|
||||
@@ -57,6 +57,6 @@ You must specify one of the following combinations of fields:
|
||||
|
||||
It is not possible to create a conditional escrow with no expiration, but you can specify an expiration that is very far in the future.
|
||||
|
||||
**Note:** Before the [fix1571 amendment][] became enabled on 2018-06-19, it was possible to create an escrow with `CancelAfter` only. These escrows could be finished by anyone at any time before the specified expiration.
|
||||
{% admonition type="info" name="Note" %}Before the [fix1571 amendment][] became enabled on 2018-06-19, it was possible to create an escrow with `CancelAfter` only. These escrows could be finished by anyone at any time before the specified expiration.{% /admonition %}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -46,7 +46,7 @@ Any account may submit an EscrowFinish transaction.
|
||||
- If the held payment has a `Condition`, you cannot execute it unless you provide a matching `Fulfillment` for the condition.
|
||||
- You cannot execute a held payment after it has expired. Specifically, if the corresponding [EscrowCreate transaction][] specified a `CancelAfter` time that is before the close time of the most recently-closed ledger, the EscrowFinish transaction fails.
|
||||
|
||||
**Note:** The minimum [transaction cost](../../../../concepts/transactions/transaction-cost.md) to submit an EscrowFinish transaction increases if it contains a fulfillment. If the transaction has no fulfillment, the transaction cost is the standard 10 drops. If the transaction contains a fulfillment, the transaction cost is 330 [drops of XRP][] plus another 10 drops for every 16 bytes in size of the preimage.
|
||||
{% admonition type="info" name="Note" %}The minimum [transaction cost](../../../../concepts/transactions/transaction-cost.md) to submit an EscrowFinish transaction increases if it contains a fulfillment. If the transaction has no fulfillment, the transaction cost is the standard 10 drops. If the transaction contains a fulfillment, the transaction cost is 330 [drops of XRP][] plus another 10 drops for every 16 bytes in size of the preimage.{% /admonition %}
|
||||
|
||||
In [non-production networks](../../../../concepts/networks-and-servers/parallel-networks.md), it may be possible [to delete](../../../../concepts/accounts/deleting-accounts.md) the destination account of a pending escrow. In this case, an attempt to finish the escrow fails with the result `tecNO_TARGET`, but the escrow object remains unless it has expired normally. If another payment re-creates the destination account, the escrow can be finished successfully. The destination account of an escrow can only be deleted if the escrow was created before the [fix1523 amendment](/resources/known-amendments.md#fix1523) became enabled. No such escrows exist in the production XRP Ledger, so this edge case is not possible on the production XRP Ledger. This edge case is also not possible in test networks that enable both fix1523 and Escrow amendments at the same time, which is the default when you [start a new genesis ledger](../../../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md).
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ An OfferCancel transaction removes an Offer object from the XRP Ledger.
|
||||
|:----------------|:----------|:------------------|:-----------------------------|
|
||||
| `OfferSequence` | Number | UInt32 | The sequence number (or [Ticket](../../../../concepts/accounts/tickets.md) number) of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
|
||||
|
||||
*Tip:* To remove an old offer and replace it with a new one, you can use an [OfferCreate transaction][] with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.
|
||||
{% admonition type="success" name="Tip" %}To remove an old offer and replace it with a new one, you can use an [OfferCreate transaction][] with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.{% /admonition %}
|
||||
|
||||
The OfferCancel method returns [`tesSUCCESS`](../transaction-results/tes-success.md) even if it did not find an offer with the matching sequence number.
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ A TicketCreate transaction sets aside one or more [sequence numbers][Sequence Nu
|
||||
|
||||
If the transaction cannot create _all_ of the requested Tickets (either due to the 250-Ticket limit or the [owner reserve](../../../../concepts/accounts/reserves.md)), it fails and creates no Tickets. To look up how many Tickets an account currently owns, use the [account_info method][] and check the `account_data.TicketCount` field.
|
||||
|
||||
**Tip:** This transaction increases the sending account's [sequence number][Sequence Number] by 1 _plus_ the number of tickets created (`TicketCount`). This is the only transaction that increases an account's sequence number by more than 1.
|
||||
{% admonition type="success" name="Tip" %}This transaction increases the sending account's [sequence number][Sequence Number] by 1 _plus_ the number of tickets created (`TicketCount`). This is the only transaction that increases an account's sequence number by more than 1.{% /admonition %}
|
||||
|
||||
## Error Cases
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ This transaction can only be used for XRP-XRP bridges.
|
||||
|
||||
The `XChainAccountCreateCommit` transaction creates a new account for a witness server to submit transactions on an issuing chain.
|
||||
|
||||
**Warning:** This transaction should only be executed if the witness attestations will be reliably delivered to the destination chain. If the signatures aren't delivered, then account creation will be blocked until attestations are received. This can be used maliciously; to disable this transaction on XRP-XRP bridges, omit the bridge's `MinAccountCreateAmount` field.
|
||||
{% admonition type="danger" name="Warning" %}This transaction should only be executed if the witness attestations will be reliably delivered to the destination chain. If the signatures aren't delivered, then account creation will be blocked until attestations are received. This can be used maliciously; to disable this transaction on XRP-XRP bridges, omit the bridge's `MinAccountCreateAmount` field.{% /admonition %}
|
||||
|
||||
|
||||
## Example XChainAccountCreateCommit JSON
|
||||
|
||||
@@ -18,7 +18,7 @@ The signature must be from one of the keys on the door's signer list at the time
|
||||
|
||||
Any account can submit signatures.
|
||||
|
||||
**Note:** The reward is only sent to accounts that have keys on the current list. A quorum of signers need to agree on the `SignatureReward`, the same way they need to agree on the other data. A single witness server can't provide an incorrect value for this in an attempt to collect a larger reward.
|
||||
{% admonition type="info" name="Note" %}The reward is only sent to accounts that have keys on the current list. A quorum of signers need to agree on the `SignatureReward`, the same way they need to agree on the other data. A single witness server can't provide an incorrect value for this in an attempt to collect a larger reward.{% /admonition %}
|
||||
|
||||
|
||||
## Example XChainAddAccountCreateAttestation JSON
|
||||
|
||||
@@ -18,7 +18,7 @@ The signature must be from one of the keys on the door's signer list at the time
|
||||
|
||||
Any account can submit signatures.
|
||||
|
||||
**Note:** The reward is only sent to accounts that have keys on the current list. A quorum of signers need to agree on the `SignatureReward`, the same way they need to agree on the other data. A single witness server can't provide an incorrect value for this in an attempt to collect a larger reward.
|
||||
{% admonition type="info" name="Note" %}The reward is only sent to accounts that have keys on the current list. A quorum of signers need to agree on the `SignatureReward`, the same way they need to agree on the other data. A single witness server can't provide an incorrect value for this in an attempt to collect a larger reward.{% /admonition %}
|
||||
|
||||
|
||||
## Example XChainAddClaimAttestation JSON
|
||||
|
||||
@@ -18,7 +18,7 @@ The transaction must be submitted first by the locking chain door account. To se
|
||||
|
||||
The complete production-grade setup would also include a `SignerListSet` transaction on the two door accounts for the witnesses’ signing keys, as well as disabling the door accounts’ master key. This ensures that the witness servers are truly in control of the funds.
|
||||
|
||||
**Note:** Each door account can only have one bridge. This prevents the creation of duplicate bridges for the same asset, which can cause asset imbalances on either chain.
|
||||
{% admonition type="info" name="Note" %}Each door account can only have one bridge. This prevents the creation of duplicate bridges for the same asset, which can cause asset imbalances on either chain.{% /admonition %}
|
||||
|
||||
|
||||
## Example XChainCreateBridge JSON
|
||||
|
||||
@@ -16,7 +16,7 @@ The `XChainModifyBridge` transaction allows bridge managers to modify the parame
|
||||
|
||||
This transaction must be sent by the door account and requires the entities that control the witness servers to coordinate and provide the signatures for this transaction. This coordination happens outside the ledger.
|
||||
|
||||
**Note:** You can't modify the signer list for the bridge with this transaction. The signer list is on the door account itself and is changed in the same way signer lists are changed on accounts (via a `SignerListSet` transaction).
|
||||
{% admonition type="info" name="Note" %}You can't modify the signer list for the bridge with this transaction. The signer list is on the door account itself and is changed in the same way signer lists are changed on accounts (via a `SignerListSet` transaction).{% /admonition %}
|
||||
|
||||
|
||||
## Example XChainModifyBridge JSON
|
||||
|
||||
Reference in New Issue
Block a user