Fix links in Transactions section.

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. |

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.
 
-<!--
+
 ## See Also
 
 - **Concepts:**
@@ -121,11 +121,3 @@ In the response's `result.lines` array, find the object whose `currency` field i
     - [Freezing Issued Currencies](freezes.html)
 - **Tutorials:**
     - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
-- **References:**
-    - [account_lines method][]
-    - [account_info method][]
-    - [AccountSet transaction][]
-    - [TrustSet transaction][]
-    - [AccountRoot Flags](accountroot.html#accountroot-flags)
-    - [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
--->

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'. <!--](become-an-xrp-ledger-gateway.html#default-ripple).-->
 
@@ -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.
+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.
-
-<!-- 
-
-[HTTP / WebSocket APIs](http-websocket-apis.html)
-
-
-
-## See Also
-
-- **Concepts:**
-    - [Paths](paths.html)
-- **Tutorials:**
-    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
-- **References:**
-    - [account_lines method][]
-    - [account_info method][]
-    - [AccountSet transaction][]
-    - [TrustSet transaction][]
-    - [AccountRoot Flags](accountroot.html#accountroot-flags)
-    - [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
-

content/concepts/transactions/finality-of-results.md

@@ -43,8 +43,9 @@ When you initially submit a transaction, the `rippled` server tentatively applie
 
     - If two transactions would each fully consume the same <!-- * -->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  <!-- * -- >Offer in the <!-- * -->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  <!-- * -- >Offer in the <!-- * -->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.
+    

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.
 
 
 <!--{# common link defs #}-->

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.)
 
-<!--
+
 ## See Also
 
 - **Tutorials:**
     - [Set Up Multi-Signing](set-up-multi-signing.html)
     - [Send a Multi-Signed Transaction](send-a-multi-signed-transaction.html)
-- **Concepts:**
-    - [Cryptographic Keys](cryptographic-keys.html)
-    - [Special Transaction Cost for Multi-signed transactions](transaction-cost.html#special-transaction-costs)
-- **References:**
-    - [SignerListSet transaction][]
-    - [SignerList object](signerlist.html)
-    - [sign_for method][]
-    - [submit_multisigned method][]
--->

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.) <!-- STYLE_OVERRIDE: will -->
 
@@ -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. |
 
-<!-- 
+
 ## See Also
 
 - **Concepts:**
     - [Cross-Currency Payments](cross-currency-payments.html)
     - [Decentralized Exchange](decentralized-exchange.html)
-    - [Partial Payments](partial-payments.html)
+    \
-- **References:**
-    - [Payment transaction][]
-    - [path_find method][] (WebSocket only)
-    - [ripple_path_find method][]
--->

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)
+- **Concepts:**
-- [Transaction Cost](transaction-cost.html)
+    - [Transaction Formats](transaction-formats.html)
-- [Transaction Malleability](transaction-malleability.html)
+    - [Transaction Cost](transaction-cost.html)
-- [Overview of XRP Ledger Consensus Process](consensus.html)
+    - [Transaction Malleability](transaction-malleability.html)
-- [Consensus Principles and Rules](consensus-principles-and-rules.html)
+    - [Overview of XRP Ledger Consensus Process](consensus.html)
+    - [Consensus Principles and Rules](consensus-principles-and-rules.html)
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			

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).
+- Run `rippled` locally, or in the same LAN.
-- [Use a client library](#use-a-client-library-with-local-signing) that can do local signing.
+- Use a client library that can do local signing.
-- [Use a dedicated signing device](#use-a-dedicated-signing-device) that supports XRP Ledger signatures.
+- 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.
+- Use a secure VPN to connect to a remote `rippled` machine you trust.
 
 <!-- Source for all diagrams in this article: https://drive.google.com/drive/u/0/folders/1MFkzxtMYpS8tzdm-TjWbLSVgU0zAG9Vh -->
 
@@ -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/)
-
-
 
 
 <!--{# common link defs #}-->

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.
 

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 |
+| Reference Transaction (Most transactions) | 10 drops |
-| [Key Reset Transaction](#key-reset-transaction) | 0 |
+| Key Reset Transaction | 0 |
-| [Multi-signed Transaction](multi-signing.md) | 10 drops × (1 + Number of Signatures Provided) |
+| [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 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](#open-ledger-cost), the server queues the transaction for a later ledger.
+* 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

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).

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.
+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](../accounts/cryptographic-keys.md#signing-algorithms) were never vulnerable to this problem.)
 
+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.
+    

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. |
+| `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. |
+| `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

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 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](#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
-
+- **Concepts:**
-- [Transaction Cost](transaction-cost.html) for information on why the transaction cost exists and how the XRP Ledger enforces it.
+    - [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.
+    - [Consensus](consensus.html) for a detailed description of how the consensus process approves transactions.

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.<!-- See [Transaction Cost][] for details. -->|
+| `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.<!-- See [Transaction Cost][] for details. -->|
-| `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.)_. |
+| `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. <!-- See [Reliable Transaction Submission](reliable-transaction-submission.html) for more details. -->|
@@ -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. <!-- ][identifying 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.
-
-

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 <!--
 
 ## Claimed Cost Justification
 
-Although it might seem unfair to charge a [transaction cost](transaction-cost.md) for a failed transaction, the `tec` class of errors exists for good reasons:
+Although it might seem unfair to charge a [transaction cost](transaction-cost.html) for a failed transaction, the `tec` class of errors exists for good reasons:
 
 * Transactions submitted after the failed one do not have to have their Sequence values renumbered. Incorporating the failed transaction into a ledger uses up the transaction's sequence number, preserving the expected sequence.
 * Distributing the transaction throughout the network increases network load. Enforcing a cost makes it harder for attackers to abuse the network with failed transactions.
@@ -60,7 +60,7 @@ Transactions are authorized by any of the following signature types:
 
 * A single signature from the master private key that is mathematically associated with the sending address. You can disable or enable the master key pair using an `AccountSet` transaction.
 * A single signature that matches the regular private key associated with the address. You can add, remove, or replace a regular key pair using a `SetRegularKey` transaction.
-* A [multi-signature](multi-signing.md) that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a `SignerListSet` transaction.
+* A multi-signature that matches a list of signers owned by the address. You can add, remove, or replace a list of signers using a `SignerListSet` transaction.
 
 Any signature type can authorize any type of transaction, with the following exceptions:
 
@@ -70,32 +70,11 @@ Any signature type can authorize any type of transaction, with the following exc
 
 <!-- [disable the master public key](accountset.html) -->
 
-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).
 
 <!--{# Add this reference after signatures concept doc is published. For more information about signatures, see [Understanding Signatures](concept-signatures.html). #}-->
 
-<!--
-
 ## See Also
 
 - **Concepts:**
     - [Payment Types](payment-types.html)
-    - [Consensus Network](consensus-network.html)
-- **Tutorials:**
-    - [Set Up Secure Signing](set-up-secure-signing.html)
-    - [Send XRP](send-xrp.html)
-    - [Look Up Transaction Results](look-up-transaction-results.html)
-    - [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
-    - [Cancel or Skip a Transaction](cancel-or-skip-a-transaction.html)
-    - [Reliable Transaction Submission](reliable-transaction-submission.html)
-- **References:**
-    - [Transaction Common Fields](transaction-common-fields.html)
-    - [Transaction Types](transaction-types.html)
-    - [Transaction Metadata](transaction-metadata.html)
-    - [account_tx method][]
-    - [tx method][]
-    - [submit method][]
-    - [submit_multisigned method][] 
-    
--->
-    

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<!-- [APIs](http-websocket-apis.md)-->, 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.
+When an account owns 3 or more objects in the ledger, the full owner reserve applies.

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).
 
-<!-- 
-
-## See Also
-
-- **Blog:**
-    - [Protecting the Ledger: Invariant Checking](https://xrpl.org/blog/2017/invariant-checking.html)
-
-- **Repository:**
-    - [Invariant Check.h](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
-    - [Invariant Check.cpp](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
-    - [System Parameters](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
-    - [XRP Amount](https://github.com/ripple/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
-    - [Ledger Formats](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
-
-
-- **Other:**
-    - [Authorized Trust Lines](authorized-trust-lines.html)
-    - [XRP Properties](xrp.html#xrp-properties)
-    - [Calculating Balance Changes for a Transaction](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
- -->
-
-
 
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			

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. |

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_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. [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. |
-| `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_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. [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. |
-| `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_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.                             |