diff --git a/content/_snippets/tx-metadata-field-table.md b/content/_snippets/tx-metadata-field-table.md index 82a18169de..53da769d8c 100644 --- a/content/_snippets/tx-metadata-field-table.md +++ b/content/_snippets/tx-metadata-field-table.md @@ -4,4 +4,4 @@ | `DeliveredAmount` | [Currency Amount][] | _(May be omitted)_ For a [partial payment](partial-payments.html), this field records the amount of currency actually delivered to the destination. To avoid errors when reading transactions, instead use the `delivered_amount` field, which is provided for all Payment transactions, partial or not. | | `TransactionIndex` | Unsigned Integer | The transaction's position within the ledger that included it. This is zero-indexed. (For example, the value `2` means it was the 3rd transaction in that ledger.) | | `TransactionResult` | String | A [result code](transaction-results.html) indicating whether the transaction succeeded or how it failed. | -| [`delivered_amount`](transaction-metadata.html#delivered_amount) | [Currency Amount][] | _(Omitted for non-Payment transactions)_ The [Currency Amount][] actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](partial-payments.html). See [this description](transaction-metadata.html#delivered_amount) for details. [New in: rippled 0.27.0][] | +| [`delivered_amount`](transaction-metadata.html#delivered_amount) | [Currency Amount][] | _(Omitted for non-Payment transactions)_ The [Currency Amount][] actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](partial-payments.html). See [this description](transaction-metadata.html#delivered_amount) for details. | diff --git a/content/concepts/tokens/authorized-trust-lines.md b/content/concepts/tokens/authorized-trust-lines.md index f16aab9927..246d88b889 100644 --- a/content/concepts/tokens/authorized-trust-lines.md +++ b/content/concepts/tokens/authorized-trust-lines.md @@ -11,7 +11,7 @@ The Authorized Trust Lines feature enables issuers to create tokens that can onl To use the Authorized Trust Lines feature, enable the `RequireAuth` flag on your issuing account. While the setting is enabled, other accounts can only hold tokens you issue if you have authorized those accounts' trust lines to your issuing account. -You can authorize a trust line by sending a `TrustSet` transaction from your issuing address, configuring the trust line between your account and the account to authorize. After you have authorized a trust line, you can never revoke that authorization. (You can, however, [freeze](freezing-tokens.md) that trust line if you need to.) +You can authorize a trust line by sending a `TrustSet` transaction from your issuing address, configuring the trust line between your account and the account to authorize. After you have authorized a trust line, you can never revoke that authorization. (You can, however, [freeze](freezing-tokens.html) that trust line if you need to.) The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address. @@ -26,11 +26,11 @@ With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process 3. The customer sends a `TrustSet` transaction to create a trust line to the issuer's address, with a positive limit. 4. The issuer sends a `TrustSet` transaction to authorize the customer's trust line. -**Tip:** The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_ +**Tip:** The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line. ## As a Precaution -Even if you don't intend to use Authorized Trust Lines, you can enable the `RequireAuth` setting on [operational and standby accounts](../accounts/account-types.md), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended. +Even if you don't intend to use Authorized Trust Lines, you can enable the `RequireAuth` setting on [operational and standby accounts](account-types.html), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended. ## Technical Details @@ -113,7 +113,7 @@ To see whether a trust line has been authorized, use the `account_lines` method In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line. - \ No newline at end of file diff --git a/content/concepts/tokens/rippling.md b/content/concepts/tokens/rippling.md index f44c2fb2cd..0332243443 100644 --- a/content/concepts/tokens/rippling.md +++ b/content/concepts/tokens/rippling.md @@ -13,7 +13,7 @@ In the XRP Ledger, "rippling" describes a process of atomic net settlement betwe Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling. -For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between tokens with the same currency code but different issuers. The [No Ripple Flag](#the-no-ripple-flag) disables rippling by default when others open trust lines to your account, unless you enable rippling by default using the [Default Ripple flag](#the-default-ripple-flag). +For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between tokens with the same currency code but different issuers. The No Ripple Flag disables rippling by default when others open trust lines to your account, unless you enable rippling by default using the Default Ripple flag. **Caution:** When you create a trust line, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line. @@ -27,7 +27,7 @@ If Bob wants to pay $3 to Charlie, then he could say, "Alice, take $3 of the mon {{ include_svg("img/noripple-02.svg", "Charlie --($13)-- Alice --($17)-- Bob") }} -We call this process, where two addresses pay each other by adjusting the balances of trust lines in between them, "rippling". This is a useful and important feature of the XRP Ledger. Rippling occurs when addresses are linked by trust lines that use the same [currency code][]. The issuer does not need to be the same: in fact, larger chains always involve changing issuers. +We call this process, where two addresses pay each other by adjusting the balances of trust lines in between them, "rippling". This is a useful and important feature of the XRP Ledger. Rippling occurs when addresses are linked by trust lines that use the same currency code. The issuer does not need to be the same: in fact, larger chains always involve changing issuers. ## The No Ripple Flag @@ -35,7 +35,7 @@ Non-issuing accounts, especially liquidity providers who may hold balances from The **No Ripple** flag is a setting on a trust line. When two trust lines both have No Ripple 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 using the same currency code. -An account can disable No Ripple 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 [Default Ripple flag](#the-default-ripple-flag). +An account can disable No Ripple 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 Default Ripple flag. For example, imagine Emily has money issued by two different financial institutions, like so @@ -64,7 +64,7 @@ The No Ripple flag makes certain paths invalid, so that they cannot be used to m The **Default Ripple** flag is an account setting that enables rippling on all _incoming_ trust lines by default. Issuers MUST enable this flag for their customers to be able to send tokens to each other. -The Default Ripple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the Default Ripple setting of your account, trust lines that were created before the change keep their existing No Ripple settings. You can use a [TrustSet transaction][] to change the No Ripple setting of a trust line to match your address's new default. +The Default Ripple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the Default Ripple setting of your account, trust lines that were created before the change keep their existing No Ripple settings. You can use a `TrustSet` transaction to change the No Ripple setting of a trust line to match your address's new default. For more information, see Default Ripple in 'Becoming an XRP Ledger Gateway'. @@ -83,25 +83,4 @@ To enable the No Ripple flag, send a `TrustSet` transaction with the `tfSetNoRip In the case of two accounts that mutually trust each other, the No Ripple flag is tracked separately for each account. -Using the HTTP/WebSocket APIs or your preferred [client library](client-libraries.html), look up trust lines with the `account_lines method`. For each trust line, the `no_ripple` field shows whether the current address has enabled the No Ripple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the No Ripple flag. - -offer] in the decentralized exchange, whichever one comes first succeeds, and the other fails. Since the order in which those transactions apply might change, the one that succeeded can fail and the one that failed can succeed. Since offers can be partially executed, they could also still succeed, but to a greater or lesser extent. - - If a [cross-currency payment](./payments/cross-currency-payments.md) succeeds by consuming an decentralized exchange, but a different transaction consumes or creates offers in the same order book, the cross-currency payment might succeed with a different exchange rate than it had when it executed tentatively. If it was a [partial payment](./payments/partial-payments.md), it could also deliver a different amount. + - If a [cross-currency payment](cross-currency-payments.html) succeeds by consuming an decentralized exchange, but a different transaction consumes or creates offers in the same order book, the cross-currency payment might succeed with a different exchange rate than it had when it executed tentatively. If it was a [partial payment](partial-payments.html), it could also deliver a different amount. - A `Payment` transaction that tentatively failed because the sender did not have enough funds might later succeed because another transaction delivering the necessary funds came first in the canonical order. The reverse is also possible: a transaction that tentatively succeeded might fail because a transaction delivering the necessary funds did not come first after being put into canonical order. **Tip:** For this reason, when running tests against the XRP Ledger, be sure to wait for a ledger close in between transactions if you have several accounts affecting the same data. If you are testing against a server in stand-alone mode, you must manually close the ledger in such cases. + \ No newline at end of file diff --git a/content/concepts/transactions/look-up-transaction-results.md b/content/concepts/transactions/look-up-transaction-results.md index fe29e99322..4c2786e702 100644 --- a/content/concepts/transactions/look-up-transaction-results.md +++ b/content/concepts/transactions/look-up-transaction-results.md @@ -164,7 +164,7 @@ Since the `ModifiedNode` entry for `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`'s accoun Almost any transaction can result in the following types of changes: -- **Sequence and Transaction Cost changes:** [As mentioned, every transaction (excluding pseudo-transactions) modifies the sender's `AccountRoot` object](#2-interpret-metadata) to increase the sender's sequence number and destroy the XRP used to pay the transaction cost. +- **Sequence and Transaction Cost changes:** As mentioned, every transaction (excluding pseudo-transactions) modifies the sender's `AccountRoot` object to increase the sender's sequence number and destroy the XRP used to pay the transaction cost. - **Account Threading:** Some transactions that create objects also modify the [AccountRoot object](accountroot.html) of an intended recipient or destination account to indicate that something relating to that account changed. This technique of "tagging" an account changes only that object's `PreviousTxnID` and `PreviousTxnLgrSeq` fields. This makes it more efficient to look up an account's transaction history by following the "thread" of transactions mentioned in these fields. - **Directory Updates:** Transactions that create or remove ledger objects often make changes to [DirectoryNode objects](directorynode.html) to track which objects exist. Also, when a transaction adds an object that counts towards an account's [owner reserve](reserves.html#owner-reserves), it increases the `OwnerCount` of the owner's [AccountRoot object][]. Removing an object decreases the `OwnerCount`. This is how the XRP Ledger tracks how much owner reserve each account owes at any point in time. @@ -315,7 +315,7 @@ A successful [EscrowFinish transaction][] modifies the `AccountRoot` of the reci Of course, an EscrowFinish can only be successful if it meets the conditions of the escrow, and an EscrowCancel can only be successful if the expiration of the Escrow object is before the close time of the previous ledger. -Escrow transactions also do normal [bookkeeping](#general-purpose-bookkeeping) for adjusting the sender's owner reserve and the directories of the accounts involved. +Escrow transactions also do normal bookkeeping for adjusting the sender's owner reserve and the directories of the accounts involved. In the following excerpt, we see that `r9UUEX...`'s balance increases by 1 billion XRP and its owner count decreases by 1 because an escrow from that account to itself finished successfully. The `Sequence` number does not change because [a third party completed the escrow](https://xrpcharts.ripple.com/#/transactions/C4FE7F5643E20E7C761D92A1B8C98320614DD8B8CD8A04CFD990EBC5A39DDEA2): @@ -391,7 +391,7 @@ There are several ways to request to close a payment channel, aside from the imm ### TrustSet Transactions -TrustSet transactions create, modify, or delete [trust lines](trust-lines-and-issuing.html), which are represented as [`RippleState` objects](ripplestate.html). A single `RippleState` object contains settings for both parties involved, including their limits, [rippling settings](rippling.html), and more. Creating and modifying trust lines can also [adjust the sender's owner reserve and owner directory](#general-purpose-bookkeeping). +TrustSet transactions create, modify, or delete [trust lines](trust-lines-and-issuing.html), which are represented as [`RippleState` objects](ripplestate.html). A single `RippleState` object contains settings for both parties involved, including their limits, [rippling settings](rippling.html), and more. Creating and modifying trust lines can also adjust the sender's owner reserve and owner directory. The following example shows a new trust line, where **`rf1BiG...`** is willing to hold up to 110 USD issued by **`rsA2Lp...`**: @@ -442,14 +442,10 @@ Most other transactions create a specific type of ledger entry and [adjust the s ## See Also - **Concepts:** - - [Finality of Results](finality-of-results.html) - How to know when a transaction's success or failure is final. (Short version: if a transaction is in a validated ledger, its outcome and metadata are final.) + - [Finality of Results](finality-of-results.html) - **Tutorials:** - [Reliable Transaction Submission](reliable-transaction-submission.html) - [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html) -- **References:** - - [Ledger Object Types Reference](ledger-object-types.html) - All possible fields of all types of ledger objects - - [Transaction Metadata](transaction-metadata.html) - Summary of the metadata format and fields that appear in metadata - - [Transaction Results](transaction-results.html) - Tables of all possible result codes for transactions. diff --git a/content/concepts/transactions/multi-signing.md b/content/concepts/transactions/multi-signing.md index 0bd89cd758..0799ca32b8 100644 --- a/content/concepts/transactions/multi-signing.md +++ b/content/concepts/transactions/multi-signing.md @@ -7,22 +7,22 @@ labels: --- # Multi-Signing -Multi-signing in the XRP Ledger is a method of [authorizing transactions](transactions.html#authorizing-transactions) for the XRP Ledger by using a combination of multiple secret keys. You can have any combination of authorization methods enabled for your address, including multi-signing, a [master key pair](../accounts/cryptographic-keys.html#master-key-pair), and a [regular key pair](../accounts/cryptographic-keys.html#regular-key-pair). (The only requirement is that _at least one_ method must be enabled.) +Multi-signing in the XRP Ledger is a method of [authorizing transactions](transactions.html#authorizing-transactions) for the XRP Ledger by using a combination of multiple secret keys. You can have any combination of authorization methods enabled for your address, including multi-signing, a [master key pair](cryptographic-keys.html#master-key-pair), and a [regular key pair](cryptographic-keys.html#regular-key-pair). (The only requirement is that _at least one_ method must be enabled.) Benefits of multi-signing include: * You can require keys from different devices, so that a malicious actor must compromise multiple machines to send transactions on your behalf. * You can share custody of an address between multiple people, each of whom only has one of several keys necessary to send transactions from that address. * You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally. -* ... and more. + ## SignerLists Before you can multi-sign, you must create a list of which addresses can sign for you. -The [SignerListSet transaction][] defines which addresses can authorize transactions from your address. You can include 1 to 32 addresses in a SignerList. The SignerList cannot include the sender's address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the *SignerWeight* and *SignerQuorum* values of the SignerList. +The `SignerListSet` transaction defines which addresses can authorize transactions from your address. You can include 1 to 32 addresses in a SignerList. The SignerList cannot include the sender's address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the *SignerWeight* and *SignerQuorum* values of the SignerList. -_(Updated by the [ExpandedSignerList amendment][].)_ +_(Updated by the [ExpandedSignerList amendment](known-amendments.html#expandedsignerlist).)_ ### Signer Weight @@ -36,7 +36,7 @@ The quorum value is the minimum weight total required to authorize a transaction You can also add up to 256 bits of arbitrary data to each signer's entry in the list. This data is not required or used by the network, but can be used by smart contracts or other applications to identify or confirm other data about the signers. -_(Added by the [ExpandedSignerList amendment][].)_ +_(Added by the [ExpandedSignerList amendment](known-amendments.html#expandedsignerlist).)_ ### Examples Using Signer Weight and Signer Quorum @@ -65,22 +65,13 @@ For instructions on how to do this, see [Set Up Multi-Signing](set-up-multi-sign * The transaction must include a `Signers` field containing an array of signatures. * The signatures present in the `Signers` array must match signers defined in the SignerList. * For the provided signatures, the total weight associated with those signers must be equal or greater than the quorum for the SignerList. -* The [transaction cost](transaction-cost.md) (specified in the `Fee` field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided. +* The [transaction cost](transaction-cost.html) (specified in the `Fee` field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided. * All fields of the transaction must be defined before collecting signatures. You cannot auto fill any fields. * If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the `submit_multisigned` method handles this automatically.) - \ No newline at end of file diff --git a/content/concepts/transactions/paths.md b/content/concepts/transactions/paths.md index 8c183f7f45..8f15ef24e4 100644 --- a/content/concepts/transactions/paths.md +++ b/content/concepts/transactions/paths.md @@ -20,7 +20,7 @@ A path is made of steps that connect the sender to the receiver of the payment. * Rippling through another address with the same currency * Trading tokens or XRP using an order book -[Rippling](rippling.md) is the process of exchanging equivalent tokens using the same currency code. In the typical case, rippling through an issuer involves reducing the tokens issued to one party and increasing the tokens issued to another party by an equal amount. The path step specifies which account to ripple through. +[Rippling](rippling.html) is the process of exchanging equivalent tokens using the same currency code. In the typical case, rippling through an issuer involves reducing the tokens issued to one party and increasing the tokens issued to another party by an equal amount. The path step specifies which account to ripple through. Trading tokens and possibly XRP involves going to an order book and finding the best exchange rate between the assets involved for the amount being sent. The path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) @@ -56,7 +56,7 @@ By convention, several steps of a path are implied by the [fields of the Payment ## Default Paths -In addition to explicitly specified paths, a transaction can execute along the _default path_. The default path is the simplest possible way to connect the [implied steps](#implied-steps) of the transaction. +In addition to explicitly specified paths, a transaction can execute along the _default path_. The default path is the simplest possible way to connect the implied steps of the transaction. The default path could be any of the following: @@ -101,15 +101,10 @@ The `type` field, used for the binary serialization of a path set, is actually c | `0x10` | 16 | A change of currency: the `currency` field is present. | | `0x20` | 32 | A change of issuer: the `issuer` field is present. | - + \ \ No newline at end of file diff --git a/content/concepts/transactions/reliable-transaction-submission.md b/content/concepts/transactions/reliable-transaction-submission.md index f6ad3b9391..9ecc8feed8 100644 --- a/content/concepts/transactions/reliable-transaction-submission.md +++ b/content/concepts/transactions/reliable-transaction-submission.md @@ -32,8 +32,6 @@ Well-formed transactions submitted to trusted XRP Ledger servers are usually val If a power or network outage occurs, applications face more challenges finding the status of submitted transactions. Applications must take care both to properly submit a transaction and later to properly get authoritative results. - - ### Transaction Timeline When you submit a transaction to the XRP Ledger, regardless of whether you used [HTTP API](http-websocket-apis.html), a [client library](client-libraries.html), or some other app, process of applying the transaction to the ledger is the same. That process goes like this: @@ -539,13 +537,14 @@ The server may report a last validated ledger index less than the specified `Las Finally the server may show one or more gaps in the transaction history. The `completed_ledgers` field shown in the response above indicates that ledgers 10256383 through 10256411 are missing from this rippled instance. Our example transaction can only appear in ledgers 10268597 - 10268600 (based on when it was submitted and `LastLedgerSequence`), so the gap shown here is not relevant. However, if the gap indicated a ledger in that range was missing, then an application would need to query another rippled server (or wait for this one to retrieve the missing ledgers) to determine that a `txnNotFound` result is immutable. -## Additional Resources +## See Also -- [Transaction Formats](transaction-formats.html) -- [Transaction Cost](transaction-cost.html) -- [Transaction Malleability](transaction-malleability.html) -- [Overview of XRP Ledger Consensus Process](consensus.html) -- [Consensus Principles and Rules](consensus-principles-and-rules.html) +- **Concepts:** + - [Transaction Formats](transaction-formats.html) + - [Transaction Cost](transaction-cost.html) + - [Transaction Malleability](transaction-malleability.html) + - [Overview of XRP Ledger Consensus Process](consensus.html) + - [Consensus Principles and Rules](consensus-principles-and-rules.html) {% include '_snippets/rippled-api-links.md' %} diff --git a/content/concepts/transactions/secure-signing.md b/content/concepts/transactions/secure-signing.md index a3b3d756b0..e6de78403a 100644 --- a/content/concepts/transactions/secure-signing.md +++ b/content/concepts/transactions/secure-signing.md @@ -14,10 +14,10 @@ To submit [transactions](transaction-basics.html) to the XRP Ledger, you need a There are several configurations with varying levels of security that may be acceptable for your situation. Choose one of the following that best fits your needs: -- [Run `rippled` locally](#run-rippled-locally), or [in the same LAN](#run-rippled-on-the-same-lan). -- [Use a client library](#use-a-client-library-with-local-signing) that can do local signing. -- [Use a dedicated signing device](#use-a-dedicated-signing-device) that supports XRP Ledger signatures. -- [Use a secure VPN to connect to a remote `rippled` machine](#use-a-secure-vpn-with-a-remote-rippled-server) you trust. +- Run `rippled` locally, or in the same LAN. +- Use a client library that can do local signing. +- Use a dedicated signing device that supports XRP Ledger signatures. +- Use a secure VPN to connect to a remote `rippled` machine you trust. @@ -134,7 +134,7 @@ Setting up this configuration depends on the specific device. You may need to ru This configuration uses a `rippled` server hosted remotely, such as in a colocation facility or a distant datacenter, but connects to it securely using an encrypted VPN. -To use this configuration, follow the steps for [running `rippled` on a private LAN](#run-rippled-on-the-same-lan), but use a VPN to connect to the LAN of the remote `rippled` server. Instructions for setting up the VPN are specific to your environment and are not described in this guide. +To use this configuration, follow the steps for running `rippled` on a private LAN, but use a VPN to connect to the LAN of the remote `rippled` server. Instructions for setting up the VPN are specific to your environment and are not described in this guide. ## See Also @@ -143,18 +143,11 @@ To use this configuration, follow the steps for [running `rippled` on a private - [Cryptographic Keys](cryptographic-keys.html) - [Multi-Signing](multi-signing.html) - **Tutorials:** - - [Install rippled](install-rippled.html) - [Assign a Regular Key Pair](assign-a-regular-key-pair.html) - - [Reliable Transaction Submission](reliable-transaction-submission.html) - [Enable Public Signing](enable-public-signing.html) - **References:** - [sign method][] - [submit method][] - - [xrpl.js Reference](https://js.xrpl.org/) - - [`xrpl-py` Reference](https://xrpl-py.readthedocs.io/en/latest/index.html) - - [`xrpl4j` Reference](https://javadoc.io/doc/org.xrpl/) - - diff --git a/content/concepts/transactions/source-and-destination-tags.md b/content/concepts/transactions/source-and-destination-tags.md index 5661769604..53b4d7be23 100644 --- a/content/concepts/transactions/source-and-destination-tags.md +++ b/content/concepts/transactions/source-and-destination-tags.md @@ -1,6 +1,13 @@ +--- +html: source-and-destination-tags.html +parent: transactions.html +blurb: +labels: + - Transactions +--- # Source and Destination Tags -_Source tags_ and _destination tags_ are a feature of XRP Ledger [payments](../payments/payment-types.html) that can indicate specific purposes for payments from and to multi-purpose addresses. Source and destination tags do not have direct on-ledger functionality; source and destination tags merely provide information about how off-ledger systems should process a payment. In transactions, both source and destination tags are formatted as 32-bit unsigned integers. +_Source tags_ and _destination tags_ are a feature of XRP Ledger [payments](payment-types.html) that can indicate specific purposes for payments from and to multi-purpose addresses. Source and destination tags do not have direct on-ledger functionality; source and destination tags merely provide information about how off-ledger systems should process a payment. In transactions, both source and destination tags are formatted as 32-bit unsigned integers. Destination tags indicate the beneficiary or destination for a payment. For example, a payment to an exchange or gateway address can use a destination tag to indicate which customer to credit for the amount of the payment in that business's own systems. A payment to a merchant could indicate what item or cart the payment is buying. diff --git a/content/concepts/transactions/transaction-cost.md b/content/concepts/transactions/transaction-cost.md index a7d19a060a..c93e395866 100644 --- a/content/concepts/transactions/transaction-cost.md +++ b/content/concepts/transactions/transaction-cost.md @@ -9,14 +9,14 @@ labels: To protect the XRP Ledger from being disrupted by spam and denial-of-service attacks, each transaction must destroy a small amount of [XRP](what-is-xrp.html). This _transaction cost_ is designed to increase along with the load on the network, making it very expensive to deliberately or inadvertently overload the network. -Every transaction must [specify how much XRP to destroy](#specifying-the-transaction-cost) to pay the transaction cost. +Every transaction must specify how much XRP to destroy to pay the transaction cost. ## Current Transaction Cost The current minimum transaction cost required by the network for a standard transaction is **0.00001 XRP** (10 drops). It sometimes increases due to higher than usual load. -You can also [query `rippled` for the current transaction cost](#querying-the-transaction-cost). +You can also query `rippled` for the current transaction cost. ### Special Transaction Costs @@ -24,9 +24,9 @@ Some transactions have different transaction costs: | Transaction | Cost Before Load Scaling | |-----------------------|--------------------------| -| [Reference Transaction](#reference-transaction-cost) (Most transactions) | 10 drops | -| [Key Reset Transaction](#key-reset-transaction) | 0 | -| [Multi-signed Transaction](multi-signing.md) | 10 drops × (1 + Number of Signatures Provided) | +| Reference Transaction (Most transactions) | 10 drops | +| Key Reset Transaction | 0 | +| [Multi-signed Transaction](multi-signing.html) | 10 drops × (1 + Number of Signatures Provided) | | EscrowFinish Transaction with Fulfillment | 10 drops × (33 + (Fulfillment size in bytes ÷ 16)) | | [AccountDelete Transaction](accounts.html#deletion-of-accounts) | 2,000,000 drops | @@ -38,36 +38,36 @@ The transaction cost is not paid to any party: the XRP is irrevocably destroyed. When the `FeeEscalation` amendment is enabled, there are two thresholds for the transaction cost: -* If the transaction cost does not meet a `rippled` server's [load-based transaction cost threshold](#local-load-cost), the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.) -* If the transaction cost does not meet a `rippled` server's [open ledger cost threshold](#open-ledger-cost), the server queues the transaction for a later ledger. +* If the transaction cost does not meet a `rippled` server's load-based transaction cost threshold, the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.) +* If the transaction cost does not meet a `rippled` server's open ledger cost threshold, the server queues the transaction for a later ledger. This divides transactions into roughly three categories: * Transactions that specify a transaction cost so low that they get rejected by the load-based transaction cost. * Transactions that specify a transaction cost high enough to be included in the current open ledger. -* Transactions in between, which get [queued for a later ledger version](#queued-transactions). +* Transactions in between, which get queued for a later ledger version. ## Local Load Cost -Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an admin connection, the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive [the consensus process](../xrpl/consensus.md) unless its `Fee` value meets the requirements of a majority of servers. +Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an admin connection, the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive [the consensus process](consensus.html) unless its `Fee` value meets the requirements of a majority of servers. ## Open Ledger Cost -The `rippled` server has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost may be [queued for a following ledger](#queued-transactions) instead. +The `rippled` server has a second mechanism for enforcing the transaction cost, called the _open ledger cost_. A transaction can only be included in the open ledger if it meets the open ledger cost requirement in XRP. Transactions that do not meet the open ledger cost may be queued for a following ledger instead. For each new ledger version, the server picks a soft limit on the number of transactions to be included in the open ledger, based on the number of transactions in the previous ledger. The open ledger cost is equal to the minimum un-scaled transaction cost until the number of transactions in the open ledger is equal to the soft limit. After that, the open ledger cost increases exponentially for each transaction included in the open ledger. For the next ledger, the server increases the soft limit if the current ledger contained more transactions than the soft limit, and decreases the soft limit if the consensus process takes more than 5 seconds. -The open ledger cost requirement is [proportional to the normal cost of the transaction](#fee-levels), not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as [multi-signed transactions](multi-signing.html) must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements. +The open ledger cost requirement is proportional to the normal cost of the transaction, not the absolute transaction cost. Transaction types that have a higher-than-normal requirement, such as [multi-signed transactions](multi-signing.html) must pay more to meet the open ledger cost than transactions which have minimum transaction cost requirements. See also: [Fee Escalation explanation in `rippled` repository](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md). ### Queued Transactions -When `rippled` receives a transaction that meets the server's local load cost but not the [open ledger cost](#open-ledger-cost), the server estimates whether the transaction is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries to minimize the amount of network load caused by transactions that would not pay a transaction cost, since [the transaction cost only applies when a transaction is included in a validated ledger](#transaction-costs-and-failed-transactions). +When `rippled` receives a transaction that meets the server's local load cost but not the open ledger cost, the server estimates whether the transaction is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries to minimize the amount of network load caused by transactions that would not pay a transaction cost, since the transaction cost only applies when a transaction is included in a validated ledger. -For more information on queued transactions, see [Transaction Queue](../server/transaction-queue.html). +For more information on queued transactions, see [Transaction Queue](transaction-queue.html). ## Reference Transaction Cost @@ -75,7 +75,7 @@ The "Reference Transaction" is the cheapest (non-free) transaction, in terms of ### Fee Levels -_Fee levels_ represent the proportional difference between the minimum cost and the actual cost of a transaction. The [Open Ledger Cost](#open-ledger-cost) is measured in fee levels instead of absolute cost. See the following table for a comparison: +_Fee levels_ represent the proportional difference between the minimum cost and the actual cost of a transaction. The Open Ledger Cost is measured in fee levels instead of absolute cost. See the following table for a comparison: | Transaction | Minimum cost in drops | Minimum cost in Fee levels | Double cost in drops | Double cost in fee levels | |-------------|-----------------------|----------------------------|----------------------|---------------------------| @@ -111,7 +111,7 @@ Every signed transaction must include the transaction cost in the [`Fee` field]( As a rule, the XRP Ledger executes transactions _exactly_ as they are signed. (To do anything else would be difficult to coordinate across a decentralized consensus network, at the least.) As a consequence of this, every transaction destroys the exact amount of XRP specified by the `Fee` field, even if the specified amount is much more than the current minimum transaction cost for any part of the network. The transaction cost can even destroy XRP that would otherwise be set aside for an account's [reserve requirement](reserves.html). -Before signing a transaction, we recommend [looking up the current load-based transaction cost](#querying-the-transaction-cost). If the transaction cost is high due to load scaling, you may want to wait for it to decrease. If you do not plan on submitting the transaction immediately, we recommend specifying a slightly higher transaction cost to account for future load-based fluctuations in the transaction cost. +Before signing a transaction, we recommend looking up the current load-based transaction cost. If the transaction cost is high due to load scaling, you may want to wait for it to decrease. If you do not plan on submitting the transaction immediately, we recommend specifying a slightly higher transaction cost to account for future load-based fluctuations in the transaction cost. ### Automatically Specifying the Transaction Cost diff --git a/content/concepts/transactions/transaction-history.md b/content/concepts/transactions/transaction-history.md index d7ed81eb4f..1938acd45c 100644 --- a/content/concepts/transactions/transaction-history.md +++ b/content/concepts/transactions/transaction-history.md @@ -21,4 +21,4 @@ The _conceptual_ transaction history of an account also includes transactions th - `Escrow` objects, representing held payments to or from the account that are locked by time or a crypto-condition. - `SignerList` objects, representing lists of addresses that can authorize transactions for the account by multi-signing. -For more information on each of these objects, see the Ledger Format Reference. +For more information on each of these objects, see: [Ledger Data Formats](ledger-data-formats.html). diff --git a/content/concepts/transactions/transaction-malleability.md b/content/concepts/transactions/transaction-malleability.md index 172f003b76..5ecf422da2 100644 --- a/content/concepts/transactions/transaction-malleability.md +++ b/content/concepts/transactions/transaction-malleability.md @@ -11,10 +11,9 @@ A transaction is "malleable" if it can be changed in any way after being signed, If vulnerable software submits malleable transactions and assumes they can only execute under the original hash, it may lose track of transactions. In the worst case, malicious actors could take advantage of this to steal money from the vulnerable system. -On the XRP Ledger mainnet, only _multi-signed_ transactions can be malleable, if they have more signatures than necessary, or if an authorized signer provides an additional signature beyond what is necessary. Good operational security can protect against these problems. See [Mitigations for Multi-Signature Malleability](#mitigations-for-multi-signature-malleability) for guidelines. - -Before 2014, single-signed transactions could be malleable due to properties of the default signing algorithm, ECDSA with the secp256k1 curve. For compatibility with legacy signing tools, it was possible to create and submit malleable single-signed transactions until the RequireFullyCanonicalSig amendment became enabled on 2020-07-03. (Transactions [signed with Ed25519 keys](../accounts/cryptographic-keys.md#signing-algorithms) were never vulnerable to this problem.) +On the XRP Ledger mainnet, only _multi-signed_ transactions can be malleable, if they have more signatures than necessary, or if an authorized signer provides an additional signature beyond what is necessary. Good operational security can protect against these problems. See Mitigations for Multi-Signature Malleability for guidelines. +Before 2014, single-signed transactions could be malleable due to properties of the default signing algorithm, ECDSA with the secp256k1 curve. For compatibility with legacy signing tools, it was possible to create and submit malleable single-signed transactions until the RequireFullyCanonicalSig amendment became enabled on 2020-07-03. (Transactions [signed with Ed25519 keys](cryptographic-keys.html#signing-algorithms) were never vulnerable to this problem.) ## Background @@ -128,3 +127,4 @@ The process to exploit a vulnerable system follows a series of steps like the fo For example, it may refund (or not debit) a customer's balance in its own system, to account for the funds that it thinks have not been sent in the XRP Ledger. Worse, the vulnerable system might construct a new transaction to replace the transaction, picking new `Sequence`, `LastLedgerSequence`, and `Fee` parameters based on the current state of the network, but keeping the rest of the transaction the same as the original. If this new transaction is also malleable, the system could be exploited in the same way an indefinite number of times. + \ No newline at end of file diff --git a/content/concepts/transactions/transaction-metadata-concept.md b/content/concepts/transactions/transaction-metadata-concept.md index bd98dec019..659a6b0500 100644 --- a/content/concepts/transactions/transaction-metadata-concept.md +++ b/content/concepts/transactions/transaction-metadata-concept.md @@ -508,7 +508,7 @@ The following JSON object shows the metadata for [a complex cross-currency payme ## AffectedNodes -The `AffectedNodes` array contains a complete list of the [objects in the ledger][] that this transaction modified in some way. Each entry in this array is an object with one top-level field indicating what type it is: +The `AffectedNodes` array contains a complete list of the objects in the ledger that this transaction modified in some way. Each entry in this array is an object with one top-level field indicating what type it is: - `CreatedNode` indicates that the transaction created a new object in the ledger. - `DeletedNode` indicates that the transaction removed an object from the ledger. @@ -532,8 +532,8 @@ A `DeletedNode` object contains the following fields: | Field | Value | Description | |:------------------|:------------------|:-------------------------------------| -| `LedgerEntryType` | String | The [type of ledger object][] that was deleted. | -| `LedgerIndex` | String - [Hash][] | The [ID of this ledger object](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. | +| `LedgerEntryType` | String | The type of ledger object that was deleted. | +| `LedgerIndex` | String - Hash | The [ID of this ledger object](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. | | `FinalFields` | Object | The content fields of the ledger object immediately before it was deleted. Which fields are present depends on what type of ledger object was created. | ### ModifiedNode Fields diff --git a/content/concepts/transactions/transaction-queue.md b/content/concepts/transactions/transaction-queue.md index 604b7f7849..50eee9c184 100644 --- a/content/concepts/transactions/transaction-queue.md +++ b/content/concepts/transactions/transaction-queue.md @@ -39,18 +39,16 @@ The `rippled` server uses a variety of heuristics to estimate which transactions - Transactions must be properly-formed and [authorized](transaction-basics.html#authorizing-transactions) with valid signatures. - Transactions with an `AccountTxnID` field cannot be queued. - A single sending address can have at most 10 transactions queued at the same time. -- To queue a transaction, the sender must have enough XRP for all of the following: [Updated in: rippled 1.2.0][] +- To queue a transaction, the sender must have enough XRP for all of the following: - Destroying the XRP [transaction cost](transaction-cost.html) as specified in the `Fee` fields of all the sender's queued transactions. The total amount among queued transactions cannot be more than the base account reserve (currently 10 XRP). (Transactions paying significantly more than the minimum transaction cost of 0.00001 XRP typically skip the queue and go straight into the open ledger.) - Sending the maximum sum of XRP that all the sender's queued transactions could send. - Keeping enough XRP to meet the account's [reserve requirements](reserves.html). -- If a transaction affects how the sending address authorizes transactions, no other transactions from the same address can be queued behind it. [New in: rippled 0.32.0][] +- If a transaction affects how the sending address authorizes transactions, no other transactions from the same address can be queued behind it. - If a transaction includes a `LastLedgerSequence` field, the value of that field must be at least **the current ledger index + 2**. ### Fee Averaging -[New in: rippled 0.33.0][] - -If a sending address has one or more transactions queued, that sender can "push" the existing queued transactions into the open ledger by submitting a new transaction with a high enough transaction cost to pay for all of them. Specifically, the new transaction must pay a high enough transaction cost to cover the [open ledger cost](transaction-cost.html#open-ledger-cost) of itself and each other transaction from the same sender before it in the queue. (Keep in mind that the open ledger cost increases exponentially each time a transaction pays it.) The transactions must still follow the other [queuing restrictions](#queuing-restrictions) and the sending address must have enough XRP to pay the transaction costs of all the queued transactions. +If a sending address has one or more transactions queued, that sender can "push" the existing queued transactions into the open ledger by submitting a new transaction with a high enough transaction cost to pay for all of them. Specifically, the new transaction must pay a high enough transaction cost to cover the [open ledger cost](transaction-cost.html#open-ledger-cost) of itself and each other transaction from the same sender before it in the queue. (Keep in mind that the open ledger cost increases exponentially each time a transaction pays it.) The transactions must still follow the other queuing restrictions and the sending address must have enough XRP to pay the transaction costs of all the queued transactions. This feature helps you work around a particular situation. If you submitted one or more transactions with a low cost that were queued, you cannot send new transactions from the same address unless you do one of the following: @@ -70,6 +68,6 @@ The precise order of transactions in the queue decides which transactions get ad ## See Also - -- [Transaction Cost](transaction-cost.html) for information on why the transaction cost exists and how the XRP Ledger enforces it. -- [Consensus](consensus.html) for a detailed description of how the consensus process approves transactions. +- **Concepts:** + - [Transaction Cost](transaction-cost.html) for information on why the transaction cost exists and how the XRP Ledger enforces it. + - [Consensus](consensus.html) for a detailed description of how the consensus process approves transactions. diff --git a/content/concepts/transactions/transaction-structure.md b/content/concepts/transactions/transaction-structure.md index a08118cd5b..cc421207b0 100644 --- a/content/concepts/transactions/transaction-structure.md +++ b/content/concepts/transactions/transaction-structure.md @@ -17,12 +17,12 @@ Each transaction type has a set of common fields, coupled with additional fields Every transaction has the same set of common fields, plus additional fields based on the transaction type. Field names are case-sensitive. The common fields for all transactions are: -| Field | JSON Type | [Internal Type][] | Description | +| Field | JSON Type | Internal Type | Description | |:---------------------|:-----------------|:------------------|:-----------------| -| `Account` | String | AccountID | _(Required)_ The unique address of the [account](../accounts/accounts.md) that initiated the transaction. | +| `Account` | String | AccountID | _(Required)_ The unique address of the account that initiated the transaction. | | `TransactionType` | String | UInt16 | _(Required)_ The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, `AccountDelete`, `SetRegularKey`, `SignerListSet`, `EscrowCreate`, `EscrowFinish`, `EscrowCancel`, `PaymentChannelCreate`, `PaymentChannelFund`, `PaymentChannelClaim`, and `DepositPreauth`. | -| `Fee` | String | Amount | _(Required; [auto-fillable][])_ Integer amount of XRP, in drops, to be destroyed as a cost for distributing this transaction to the network. Some transaction types have different minimum requirements.| -| `Sequence` | Number | UInt32 | _(Required; [auto-fillable][])_ The [sequence number](../../../../references/protocol-reference/data-types/basic-data-types.html#account-sequence) of the account sending the transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the previous transaction from the same account. The special case `0` means the transaction is using a [Ticket](tickets.html) instead _(Added by the TicketBatch amendment.)_. | +| `Fee` | String | Amount | _(Required; auto-fillable])_ Integer amount of XRP, in drops, to be destroyed as a cost for distributing this transaction to the network. Some transaction types have different minimum requirements.| +| `Sequence` | Number | UInt32 | _(Required; auto-fillable)_ The [sequence number](basic-data-types.html#account-sequence) of the account sending the transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the previous transaction from the same account. The special case `0` means the transaction is using a [Ticket](tickets.html) instead _(Added by the TicketBatch amendment.)_. | | [`AccountTxnID`](#accounttxnid) | String | Hash256 | _(Optional)_ Hash value identifying another transaction. If provided, this transaction is only valid if the sending account's previously-sent transaction matches the provided hash. | | [`Flags`](#flags-field) | Number | UInt32 | _(Optional)_ Set of bit-flags for this transaction. | | `LastLedgerSequence` | Number | UInt32 | _(Optional; strongly recommended)_ Highest ledger index this transaction can appear in. Specifying this field places a strict upper limit on how long the transaction can wait to be validated or rejected. | @@ -35,7 +35,7 @@ Every transaction has the same set of common fields, plus additional fields base [auto-fillable]: #auto-fillable-fields -Removed in: rippled 0.28.0: The `PreviousTxnID` field of transactions was replaced by the [`AccountTxnID`](#accounttxnid) field. This String / Hash256 field is present in some historical transactions. This is unrelated to the field also named `PreviousTxnID` in some [ledger objects](../../../../references/protocol-reference/ledger-data/ledger-data-formats.md). +Removed in: rippled 0.28.0: The `PreviousTxnID` field of transactions was replaced by the [`AccountTxnID`](#accounttxnid) field. This String / Hash256 field is present in some historical transactions. This is unrelated to the field also named `PreviousTxnID` in some [ledger objects](ledger-data-formats.html). ### Example Unsigned Transaction @@ -163,15 +163,15 @@ Example response from the `tx` command: The `AccountTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous transaction sent from the same account has a specific transaction hash. -Unlike the `PreviousTxnID` field, which tracks the last transaction to _modify_ an account (regardless of sender), the `AccountTxnID` tracks the last transaction _sent by_ an account. To use `AccountTxnID`, you must first enable the [`asfAccountTxnID`](../../../../references/protocol-reference/transactions/transaction-types/accountset.md#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction. (`PreviousTxnID`, by comparison, is always tracked.) +Unlike the `PreviousTxnID` field, which tracks the last transaction to _modify_ an account (regardless of sender), the `AccountTxnID` tracks the last transaction _sent by_ an account. To use `AccountTxnID`, you must first enable the [`asfAccountTxnID`](accountset.html#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction. (`PreviousTxnID`, by comparison, is always tracked.) One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially have serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `AccountTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time. -The `AccountTxnID` field cannot be used on transactions that use [Tickets](tickets.html). Transactions that use `AccountTxnID` cannot be placed in the [transaction queue](../server/transaction-queue.html). +The `AccountTxnID` field cannot be used on transactions that use [Tickets](tickets.html). Transactions that use `AccountTxnID` cannot be placed in the [transaction queue](transaction-queue.html). ## Auto-fillable Fields -Some fields can be automatically filled in before a transaction is signed, either by a `rippled` server or by a [client library](../../../references/client-libraries.md). Auto-filling values requires an active connection to the XRP Ledger to get the latest state, so it cannot be done offline. The details can vary by library, but auto-filling always provides suitable values for at least the following fields: +Some fields can be automatically filled in before a transaction is signed, either by a `rippled` server or by a [client library](client-libraries.html). Auto-filling values requires an active connection to the XRP Ledger to get the latest state, so it cannot be done offline. The details can vary by library, but auto-filling always provides suitable values for at least the following fields: * `Fee` - Automatically fill in the `Transaction Cost` based on the network. @@ -181,7 +181,7 @@ Some fields can be automatically filled in before a transaction is signed, eithe For a production system, we recommend _not_ leaving these fields to be filled by the server. For example, if transaction costs become high due to a temporary spike in network load, you may want to wait for the cost to decrease before sending some transactions, instead of paying the temporarily-high cost. -The [`Paths` field](../../../../references/protocol-reference/transactions/transaction-types/payment.md#paths) of the `Payment` transaction type can also be automatically filled in. +The [`Paths` field](payment.html#paths) of the `Payment` transaction type can also be automatically filled in. ## Flags Field @@ -199,11 +199,11 @@ The only flag that applies globally to all transactions is as follows: | Flag Name | Hex Value | Decimal Value | Description | |:----------------------|:-----------|:--------------|:--------------------------| -| `tfFullyCanonicalSig` | `0x80000000` | 2147483648 | **DEPRECATED** No effect. (If the RequireFullyCanonicalSig amendment is not enabled, this flag enforces a [fully-canonical signature](transaction-malleability.md#alternate-secp256k1-signatures).) | +| `tfFullyCanonicalSig` | `0x80000000` | 2147483648 | **DEPRECATED** No effect. (If the RequireFullyCanonicalSig amendment is not enabled, this flag enforces a [fully-canonical signature](transaction-malleability.html#alternate-secp256k1-signatures).) | 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](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](../networks/parallel-networks.md) that does not have RequireFullyCanonicalSig enabled, you should always enable the `tfFullyCanonicalSig` flag to protect against transaction malleability. +**Note:** The `tfFullyCanonicalSig` flag was used from 2014 until 2020 to protect against transaction malleability 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](parallel-networks.html) that does not have RequireFullyCanonicalSig enabled, you should always enable the `tfFullyCanonicalSig` flag to protect against transaction malleability. ### Flag Ranges @@ -212,17 +212,17 @@ A transaction's `Flags` field can contain flags that apply at different levels o | Range Name | Bit Mask | Description | |:-----------------|:-------------|:-------------------------------------------| | Universal Flags | `0xff000000` | Flags that apply equally to all transaction types. | -| Type-based Flags | `0x00ff0000` | Flags with different meanings depending on the [transaction type](transaction-types.md) that uses them. | +| Type-based Flags | `0x00ff0000` | Flags with different meanings depending on the [transaction type](transaction-types.html) 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](../../../../references/protocol-reference/transactions/transaction-types/accountset.html#accountset-flags), which serve a similar purpose to type-based flags. [Ledger objects](../../../../references/protocol-reference/ledger-data/ledger-object-types/ledger-object-types.md) also have a `Flags` field with different bitwise flag definitions. +**Note:** The `AccountSet` transaction type has [its own non-bitwise flags](accountset.html#accountset-flags), which serve a similar purpose to type-based flags. [Ledger objects](ledger-object-types.html) also have a `Flags` field with different bitwise flag definitions. ## Memos Field The `Memos` field includes arbitrary messaging data with the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields: -| Field | Type | [Internal Type][] | Description | +| Field | Type | Internal Type | Description | |:-------------|:-------|:------------------|:---------------------------------| | `MemoData` | String | Blob | Arbitrary hex value, conventionally containing the content of the memo. | | `MemoFormat` | String | Blob | Hex value representing characters allowed in URLs. Conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml). | @@ -261,8 +261,6 @@ The `Signers` field contains a [multi-signature](multi-signing.html), which has | `TxnSignature` | String | Blob | A signature for this transaction, verifiable using the `SigningPubKey`. | | `SigningPubKey` | String | Blob | The public key used to create this signature. | -The `SigningPubKey` must be a key that is associated with the `Account` address. If the referenced `Account` is a funded account in the ledger, then the `SigningPubKey` can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the [`lsfDisableMaster`](/accountroot.html#accountroot-flags) flag is enabled. If the referenced `Account` address is not a funded account in the ledger, then the `SigningPubKey` must be the master key associated with that address. +The `SigningPubKey` must be a key that is associated with the `Account` address. If the referenced `Account` is a funded account in the ledger, then the `SigningPubKey` can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the [`lsfDisableMaster`](accountroot.html#accountroot-flags) flag is enabled. If the referenced `Account` address is not a funded account in the ledger, then the `SigningPubKey` must be the master key associated with that address. Because signature verification is a compute-intensive task, multi-signed transactions cost additional XRP to relay to the network. Each signature included in the multi-signature increases the [transaction cost](transaction-cost.html) required for the transaction. For example, if the current minimum transaction cost to relay a transaction to the network is `10000` drops, then a multi-signed transaction with 3 entries in the `Signers` array would need a `Fee` value of at least `40000` drops to relay. - - diff --git a/content/concepts/transactions/transactions.md b/content/concepts/transactions/transactions.md index ae27e72b77..64377e5dcf 100644 --- a/content/concepts/transactions/transactions.md +++ b/content/concepts/transactions/transactions.md @@ -16,7 +16,7 @@ Transactions can do more than transfer currency. In addition to supporting vario Sending a transaction to the XRP Ledger involves several steps: 1. Create an [unsigned transaction in JSON format](transaction-structure.html#example-unsigned-transaction). -2. Use one or more signatures to [authorize the transaction](#authorizing-transactions). +2. Use one or more signatures to authorize the transaction. 3. Submit a transaction to an XRP Ledger server. 4. The [consensus process](consensus.html) determines which provisional transactions get included in the next validated ledger. 5. The servers apply those transactions to the previous ledger in a canonical order and share their results. @@ -46,7 +46,7 @@ The transaction hash can be used as a "proof of payment," since anyone can -For more information about master and regular key pairs, see [Cryptographic Keys](../accounts/cryptographic-keys.md). +For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html). - - diff --git a/content/concepts/transactions/trust-lines-and-issuing.md b/content/concepts/transactions/trust-lines-and-issuing.md index a51c4fc8db..8491d78ab8 100644 --- a/content/concepts/transactions/trust-lines-and-issuing.md +++ b/content/concepts/transactions/trust-lines-and-issuing.md @@ -5,18 +5,17 @@ blurb: Transactions allow accounts to modify the XRP Ledger. labels: - Transactions --- - # Trust Lines and Issuing -Trust lines are structures in the XRP Ledger for holding [tokens](../tokens/tokens.md). Trust lines enforce the XRP Ledger's rule that you cannot cause someone else to hold a token they do not want. This precaution is necessary to enable the XRP Ledger's use case for [community credit](../tokens/tokens.md#community-credit) among other benefits. +Trust lines are structures in the XRP Ledger for holding [tokens](tokens.html). Trust lines enforce the XRP Ledger's rule that you cannot cause someone else to hold a token they do not want. This precaution is necessary to enable the XRP Ledger's use case for [community credit](tokens.html#community-credit) among other benefits. Each trust line is a _bidirectional_ relationship consisting of: -- The identifiers for the **two [accounts](../accounts/accounts.md)** that the trust line connects. +- The identifiers for the **two [accounts](accounts.html)** that the trust line connects. - A single, shared **balance**, which is positive from the perspective of one account and negative from the other perspective. - The account with a negative balance is generally considered the "issuer" of the tokens. However, in the APIs, the name `issuer` can refer to either side. - Various **settings** and metadata. _Each_ of the two accounts can control its own settings on the trust line. - - Most importantly, each side sets a **limit** on the trust line, which is 0 by default. Each account's balance (from its perspective on the trust line) can't go above that account's limit, except [through that account's own actions](#going-below-the-limit). + - Most importantly, each side sets a **limit** on the trust line, which is 0 by default. Each account's balance (from its perspective on the trust line) can't go above that account's limit, except through that account's own actions. Each trust line is specific to a given currency code. Two accounts can have any number of trust lines between them for different currency codes, but only one shared trust line for any particular currency code. @@ -70,4 +69,4 @@ Since trust lines are a powerful feature of the XRP Ledger, there is a special f When an account creates a new trust line, if the account owns at most 2 items in the ledger including the new line, the account's owner reserve is treated as zero instead of the normal amount. This allows the transaction to succeed even if the account does not hold enough XRP to meet the increased reserve requirement for owning objects in the ledger. -When an account owns 3 or more objects in the ledger, the full owner reserve applies. \ No newline at end of file +When an account owns 3 or more objects in the ledger, the full owner reserve applies. diff --git a/content/concepts/xrpl/invariant-checking.md b/content/concepts/xrpl/invariant-checking.md index ebecc398a0..20d7e5ab14 100644 --- a/content/concepts/xrpl/invariant-checking.md +++ b/content/concepts/xrpl/invariant-checking.md @@ -39,39 +39,39 @@ The XRP Ledger checks all the following invariants on each transaction: [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "Source") -- [Transaction Fee Check](#transaction-fee-check) +- Transaction Fee Check [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "Source") -- [XRP Not Created](#xrp-not-created) +- XRP Not Created [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "Source") -- [Account Roots Not Deleted](#account-roots-not-deleted) +- Account Roots Not Deleted [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "Source") -- [XRP Balance Checks](#xrp-balance-checks) +- XRP Balance Checks [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "Source") -- [Ledger Entry Types Match](#ledger-entry-types-match) +- Ledger Entry Types Match [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "Source") -- [No XRP Trust Lines](#no-xrp-trust-lines) +- No XRP Trust Lines [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "Source") -- [No Bad Offers](#no-bad-offers) +- No Bad Offers [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "Source") -- [No Zero Escrow](#no-zero-escrow) +- No Zero Escrow [[Source]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "Source") -- [Valid New Account Root](#valid-new-account-root) +- Valid New Account Root ### Transaction Fee Check @@ -89,7 +89,7 @@ The XRP Ledger checks all the following invariants on each transaction: ### Account Roots Not Deleted - **Invariant Condition(s):** - - An [account](accounts.html) cannot be deleted from the ledger except by an [AccountDelete transaction][]. + - An [account](accounts.html) cannot be deleted from the ledger except by an `AccountDelete` transaction. - A successful AccountDelete transaction always deletes exactly 1 account. @@ -130,28 +130,6 @@ The XRP Ledger checks all the following invariants on each transaction: - A new account root must have the right starting [sequence](basic-data-types.html#account-sequence). - A transaction must not create more than one new [account](accounts.html). - - - {% include '_snippets/rippled-api-links.md' %} diff --git a/content/references/protocol-reference/transactions/transaction-results/tec-codes.md b/content/references/protocol-reference/transactions/transaction-results/tec-codes.md index 4701d00553..2b2e080aa9 100644 --- a/content/references/protocol-reference/transactions/transaction-results/tec-codes.md +++ b/content/references/protocol-reference/transactions/transaction-results/tec-codes.md @@ -20,7 +20,7 @@ For the most part, transactions with `tec` codes take no action other than to de | `tecCRYPTOCONDITION_ERROR` | 146 | This [EscrowCreate][] or [EscrowFinish][] transaction contained a malformed or mismatched crypto-condition. | | `tecDIR_FULL` | 121 | The transaction tried to add an object (such as a trust line, Check, Escrow, or Payment Channel) to an account's owner directory, but that account cannot own any more objects in the ledger. | | `tecDUPLICATE` | 149 | The transaction tried to create an object (such as a [DepositPreauth][] authorization) that already exists. | -| `tecDST_TAG_NEEDED` | 143 | The [Payment transaction][] omitted a [destination tag](source-and-destination-tags.html), but the destination account has the `lsfRequireDestTag` flag enabled. [New in: rippled 0.28.0][] | +| `tecDST_TAG_NEEDED` | 143 | The [Payment transaction][] omitted a [destination tag](source-and-destination-tags.html), but the destination account has the `lsfRequireDestTag` flag enabled. | | `tecEXPIRED` | 148 | The transaction tried to create an object (such as an Offer or a Check) whose provided Expiration time has already passed. | | `tecFAILED_PROCESSING` | 105 | An unspecified error occurred when processing the transaction. | | `tecFROZEN` | 137 | The [OfferCreate transaction][] failed because one or both of the assets involved are subject to a [global freeze](freezes.html). | @@ -33,12 +33,12 @@ For the most part, transactions with `tec` codes take no action other than to de | `tecINSUFFICIENT_RESERVE` | 141 | The transaction would increase the [reserve requirement](reserves.html) higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. See [Signer Lists and Reserves](signerlist.html#signer-lists-and-reserves) for more information. | | `tecINTERNAL` | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | | `tecINVARIANT_FAILED` | 147 | An invariant check failed when trying to execute this transaction. Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | -| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the `tfFillOrKill` flag and could not be filled, so it was killed. _(Added by the [fix1578 amendment][].)_ | +| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the `tfFillOrKill` flag and could not be filled, so it was killed. | | `tecMAX_SEQUENCE_REACHED` | 153 | A sequence number field is already at its maximum. This includes the `MintedNFTokens` field. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ | -| `tecNEED_MASTER_KEY` | 142 | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](accountset.html#accountset-flags). [New in: rippled 0.28.0][] | +| `tecNEED_MASTER_KEY` | 142 | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](accountset.html#accountset-flags). | | `tecNFTOKEN_BUY_SELL_MISMATCH` | 155 | The [NFTokenAcceptOffer transaction][] attempted to match incompatible offers to buy and sell a non-fungible token. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ | | `tecNFTOKEN_OFFER_TYPE_MISMATCH` | 156 | One or more of the offers specified in the transaction was not the right type of offer. (For example, a buy offer was specified in the `NFTokenSellOffer` field.) _(Added by the [NonFungibleTokensV1_1 amendment][].)_ | -| `tecNO_ALTERNATIVE_KEY` | 130 | The transaction tried to remove the only available method of [authorizing transactions](transaction-basics.html#authorizing-transactions). This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. (Prior to `rippled` 0.30.0, this was called `tecMASTER_DISABLED`.) | +| `tecNO_ALTERNATIVE_KEY` | 130 | The transaction tried to remove the only available method of [authorizing transactions](transaction-basics.html#authorizing-transactions). This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. | | `tecNO_AUTH` | 134 | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, `tecNO_LINE` occurs instead. | | `tecNO_DST` | 124 | The account on the receiving end of the transaction does not exist. This includes Payment and TrustSet transaction types. (It could be created if it received enough XRP.) | | `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. | @@ -52,7 +52,7 @@ For the most part, transactions with `tec` codes take no action other than to de | `tecNO_SUITABLE_NFTOKEN_PAGE` | 154 | The transaction tried to mint or acquire a non-fungible token but the account receiving the `NFToken` does not have a directory page that can hold it. This situation is rare. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ | | `tecNO_TARGET` | 138 | The transaction referenced an Escrow or PayChannel ledger object that doesn't exist, either because it never existed or it has already been deleted. (For example, another [EscrowFinish transaction][] has already executed the held payment.) Alternatively, the destination account has `asfDisallowXRP` set so it cannot be the destination of this [PaymentChannelCreate][] or [EscrowCreate][] transaction. | | `tecOBJECT_NOT_FOUND` | 160 | One of the objects specified by this transaction did not exist in the ledger. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ | -| `tecOVERSIZE` | 145 | This transaction could not be processed, because the server created an excessively large amount of [metadata](transaction-metadata.html) when it tried to apply the transaction. [New in: rippled 0.29.0-hf1][] | +| `tecOVERSIZE` | 145 | This transaction could not be processed, because the server created an excessively large amount of [metadata](transaction-metadata.html) when it tried to apply the transaction. | | `tecOWNERS` | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](accountset.html#accountset-flags) flag if it has any trust lines or available offers. | | `tecPATH_DRY` | 128 | The transaction failed because the provided [paths](paths.html) did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by [trust lines](trust-lines-and-issuing.html). | | `tecPATH_PARTIAL` | 101 | The transaction failed because the provided [paths](paths.html) did not have enough liquidity to send the full amount. | diff --git a/content/references/protocol-reference/transactions/transaction-results/tel-codes.md b/content/references/protocol-reference/transactions/transaction-results/tel-codes.md index 24c8270dfb..ebc52c86cd 100644 --- a/content/references/protocol-reference/transactions/transaction-results/tel-codes.md +++ b/content/references/protocol-reference/transactions/transaction-results/tel-codes.md @@ -17,11 +17,11 @@ These codes indicate an error in the local server processing the transaction; it | `telBAD_PATH_COUNT` | The transaction contains too many paths for the local server to process. | | `telBAD_PUBLIC_KEY` | The transaction specified a public key value (for example, as the `MessageKey` field of an [AccountSet transaction][]) that cannot be used, probably because it is not the right length. | | `telCAN_NOT_QUEUE` | The transaction did not meet the [open ledger cost](transaction-cost.html), but this server did not queue this transaction because it did not meet the [queuing restrictions](transaction-queue.html#queuing-restrictions). For example, a transaction returns this code when the sender already has 10 other transactions in the queue. You can try again later or sign and submit a replacement transaction with a higher transaction cost in the `Fee` field. | -| `telCAN_NOT_QUEUE_BALANCE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because the sum of potential XRP costs of already-queued transactions is greater than the expected balance of the account. You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_BLOCKS` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This transaction could not replace an existing transaction in the queue because it would block already-queued transactions from the same sender by changing authorization methods. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the `RequireAuth`/`OptionalAuth`, `DisableMaster`, or `AccountTxnID` flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_BLOCKED` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because a transaction queued ahead of it from the same sender blocks it. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the `RequireAuth`/`OptionalAuth`, `DisableMaster`, or `AccountTxnID` flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_FEE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This code occurs when a transaction with the same sender and sequence number already exists in the queue and the new one does not pay a large enough transaction cost to replace the existing transaction. To replace a transaction in the queue, the new transaction must have a `Fee` value that is at least 25% more, as measured in [fee levels](transaction-cost.html#fee-levels). You can increase the `Fee` and try again, send this with a higher `Sequence` number so it doesn't replace an existing transaction, or try sending to another server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_FULL` | The transaction did not meet the [open ledger cost](transaction-cost.html) and the server did not queue this transaction because this server's transaction queue is full. You could increase the `Fee` and try again, try again later, or try submitting to a different server. The new transaction must have a higher transaction cost, as measured in [fee levels](transaction-cost.html#fee-levels), than the transaction in the queue with the smallest transaction cost. [New in: rippled 0.70.2][] | +| `telCAN_NOT_QUEUE_BALANCE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because the sum of potential XRP costs of already-queued transactions is greater than the expected balance of the account. You can try again later, or try submitting to a different server. | +| `telCAN_NOT_QUEUE_BLOCKS` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This transaction could not replace an existing transaction in the queue because it would block already-queued transactions from the same sender by changing authorization methods. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the `RequireAuth`/`OptionalAuth`, `DisableMaster`, or `AccountTxnID` flags.) You can try again later, or try submitting to a different server. | +| `telCAN_NOT_QUEUE_BLOCKED` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because a transaction queued ahead of it from the same sender blocks it. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the `RequireAuth`/`OptionalAuth`, `DisableMaster`, or `AccountTxnID` flags.) You can try again later, or try submitting to a different server. | +| `telCAN_NOT_QUEUE_FEE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This code occurs when a transaction with the same sender and sequence number already exists in the queue and the new one does not pay a large enough transaction cost to replace the existing transaction. To replace a transaction in the queue, the new transaction must have a `Fee` value that is at least 25% more, as measured in [fee levels](transaction-cost.html#fee-levels). You can increase the `Fee` and try again, send this with a higher `Sequence` number so it doesn't replace an existing transaction, or try sending to another server. | +| `telCAN_NOT_QUEUE_FULL` | The transaction did not meet the [open ledger cost](transaction-cost.html) and the server did not queue this transaction because this server's transaction queue is full. You could increase the `Fee` and try again, try again later, or try submitting to a different server. The new transaction must have a higher transaction cost, as measured in [fee levels](transaction-cost.html#fee-levels), than the transaction in the queue with the smallest transaction cost. | | `telFAILED_PROCESSING` | An unspecified error occurred when processing the transaction. | | `telINSUF_FEE_P` | The `Fee` from the transaction is not high enough to meet the server's current [transaction cost](transaction-cost.html) requirement, which is derived from its load level and network-level requirements. If the individual server is too busy to process your transaction right now, it may cache the transaction and automatically retry later. | | `telLOCAL_ERROR` | Unspecified local error. |