Checks: clean up TODOs, broken links; tx finality clarifications

content/reference-transaction-format.md

@@ -362,6 +362,9 @@ All transactions have certain fields in common:
 Each transaction type has additional fields relevant to the type of action it causes:
 
 * [AccountSet - Set options on an account](#accountset)
+* [CheckCancel - Cancel a check](#checkcancel)
+* [CheckCash - Redeem a check](#checkcash)
+* [CheckCreate - Create a check](#checkcreate)
 * [EscrowCancel - Reclaim escrowed XRP](#escrowcancel)
 * [EscrowCreate - Create an escrowed XRP payment](#escrowcreate)
 * [EscrowFinish - Deliver escrowed XRP to recipient](#escrowfinish)
@@ -375,11 +378,6 @@ Each transaction type has additional fields relevant to the type of action it ca
 * [SignerListSet - Set multi-signing settings](#signerlistset)
 * [TrustSet - Add or modify a trust line](#trustset)
 
-<!--{# coming soon:
-* [CheckCancel - Cancel a check](#checkcancel)
-* [CheckCash - Redeem a check](#checkcash)
-* [CheckCreate - Create a check](#checkcreate)
-#}-->
 
 _Pseudo-Transactions_ that are not created and submitted in the usual way, but may be added to open ledgers according to ledger rules. They still must be approved by consensus to be included in a validated ledger. Pseudo-transactions have their own unique transaction types:
 
@@ -389,6 +387,12 @@ _Pseudo-Transactions_ that are not created and submitted in the usual way, but m
 
 {% include 'transactions/accountset.md' %}
 
+{% include 'transactions/checkcancel.md' %}
+
+{% include 'transactions/checkcash.md' %}
+
+{% include 'transactions/checkcreate.md' %}
+
 {% include 'transactions/escrowcancel.md' %}
 
 {% include 'transactions/escrowcreate.md' %}
@@ -557,6 +561,8 @@ See also: [Partial Payments](concept-partial-payments.html)
 
 These codes indicate an error in the local server processing the transaction; it is possible that another server with a different configuration or load level could process the transaction successfully. They have numerical values in the range -399 to -300. The exact code for any given error is subject to change, so don't rely on it.
 
+**Caution:** Transactions with `tel` codes are not applied to ledgers and have no effects. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
+
 | Code                  | Explanation                                          |
 |:----------------------|:-----------------------------------------------------|
 | `telBAD_DOMAIN`        | The transaction specified a domain value (for example, the `Domain` field of an [AccountSet transaction][]) that cannot be used, probably because it is too long to store in the ledger. |
@@ -577,6 +583,8 @@ These codes indicate an error in the local server processing the transaction; it
 
 These codes indicate that the transaction was malformed, and cannot succeed according to the XRP Ledger protocol. They have numerical values in the range -299 to -200. The exact code for any given error is subject to change, so don't rely on it.
 
+**Tip:** Transactions are not applied to ledgers with `tem` codes. A `tem` result is final unless the rules for a valid transaction change. (For example, using functionality from an [Amendment](concept-amendments.html) before that amendment is enabled results in `temDISABLED`; such a transaction could succeed later if it becomes valid when the amendment is enabled.)
+
 | Code                         | Explanation                                   |
 |:-----------------------------|:----------------------------------------------|
 | `temBAD_AMOUNT`               | An amount specified by the transaction (for example the destination `Amount` or `SendMax` values of a [Payment](#payment)) was invalid, possibly because it was a negative number. |
@@ -618,6 +626,8 @@ These codes indicate that the transaction was malformed, and cannot succeed acco
 
 These codes indicate that the transaction failed and was not included in a ledger, but the transaction could have succeeded in some theoretical ledger. Typically this means that the transaction can no longer succeed in any future ledger. They have numerical values in the range -199 to -100. The exact code for any given error is subject to change, so don't rely on it.
 
+**Caution:** Transactions with `tef` codes are not applied to ledgers and have no effects. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
+
 | Code                   | Explanation                                         |
 |:-----------------------|:----------------------------------------------------|
 | `tefALREADY`             | The same exact transaction has already been applied. |
@@ -643,6 +653,8 @@ These codes indicate that the transaction failed and was not included in a ledge
 
 These codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. They have numerical values in the range -99 to -1. The exact code for any given error is subject to change, so don't rely on it.
 
+**Caution:** Transactions with `ter` codes are not applied to ledgers and have no effects. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
+
 | Code             | Explanation                                               |
 |:-----------------|:----------------------------------------------------------|
 | `terFUNDS_SPENT`  | **DEPRECATED.**                                           |
@@ -659,7 +671,7 @@ These codes indicate that the transaction failed, but it could apply successfull
 
 ### tes Success
 
-The code `tesSUCCESS` is the only code that indicates a transaction succeeded. This does not always mean it did what it was supposed to do. (For example, an [OfferCancel][] can "succeed" even if there is no offer for it to cancel.) Success uses the numerical value 0.
+The code `tesSUCCESS` is the only code that indicates a transaction succeeded. This does not always mean it did what it was supposed to do. (For example, an [OfferCancel][] can "succeed" even if there is no offer for it to cancel.) The `tesSUCCESS` result uses the numerical value 0.
 
 | Code       | Explanation                                                     |
 |:-----------|:----------------------------------------------------------------|
@@ -667,7 +679,11 @@ The code `tesSUCCESS` is the only code that indicates a transaction succeeded. T
 
 ### tec Codes
 
-These codes indicate that the transaction failed, but it was applied to a ledger to apply the [transaction cost](concept-transaction-cost.html). They have numerical values in the range 100 to 199. The exact codes sometimes appear in ledger data, so they do not change, but we recommend not relying on the numeric value regardless.
+These codes indicate that the transaction failed, but it was applied to a ledger to apply the [transaction cost](concept-transaction-cost.html). They have numerical values in the range 100 to 199. Ripple recommends using the text code, not the numeric value.
+
+For the most part, transactions with `tec` codes take no action other than to destroy the XRP paid as a [transaction cost](concept-transaction-cost.html), but there are some exceptions. For example, a transaction that results in `tecOVERSIZE` still cleans up some [unfunded offers](#lifecycle-of-an-offer), and an [OfferCreate][] that results in `tecEXPIRED` can still cancel a previously-placed Offer. Always look at the [transaction metadata](#understanding-transaction-metadata) to see precisely what a transaction did.
+
+**Caution:** A transaction that provisionally failed with a `tec` code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
 
 | Code                       | Value | Explanation                             |
 |:---------------------------|:------|:----------------------------------------|

content/snippets/tx-type-links.md

@@ -1,5 +1,8 @@
 {% set txtypes = [
     "AccountSet",
+    "CheckCancel",
+    "CheckCash",
+    "CheckCreate",
     "EscrowCancel",
     "EscrowCreate",
     "EscrowFinish",

content/transactions/checkcreate.md

@@ -1,4 +1,4 @@
-## CheckCash
+## CheckCreate
 [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CreateCheck.cpp "Source")
 
 _Requires the [Checks Amendment](reference-amendments.html#checks)._
@@ -37,5 +37,5 @@ In addition to the [common fields](#common-fields), a CheckCancel transaction ha
 - If the `Destination` account has the RequireDest flag enabled but the transaction does not include a `DestinationTag` field, the transaction fails with the result code `tecDST_TAG_NEEDED`.
 - If `SendMax` specifies an issued currency which is [frozen](concept-freeze.html), the transaction fails with the result `tecFROZEN`.
 - If the `Expiration` of the transaction is in the past, the transaction fails with the result `tecEXPIRED`.
-- If the sender does not have enough XRP to meet the [owner reserve](concept-reserves.html#owner-reserve) after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`.
+- If the sender does not have enough XRP to meet the [owner reserve](concept-reserves.html#owner-reserves) after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`.
 - If either the sender or the destination of the Check cannot own more objects in the ledger, the transaction fails with the result `tecDIR_FULL`.

content/transactions/offercreate.md

@@ -96,7 +96,7 @@ You can determine the final disposition of an offer with an `Expiration` as soon
 
 **Note:** Since only new transactions can modify the ledger, an expired offer can stay on the ledger after it becomes inactive. The offer is treated as unfunded and has no effect, but it can continue to appear in results (for example, from the [ledger_entry](reference-rippled.html#ledger-entry) command). Later on, the expired offer can get finally deleted as a result of another transaction (such as another OfferCreate) if the server finds it while processing.
 
-If an OfferCreate transaction has an `Expiration` time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer. The result code of such a transaction depends on whether the [Checks amendment](reference-amendments.html#checks) is enabled. With the Checks amendment enabled, the transaction has the `tecEXPIRED` result code. Otherwise, the transaction has the `tesSUCCESS` transaction code. ***TODO: Confirm whether a tecEXPIRED OfferCreate can still successfully cancel another offer.***
+If an OfferCreate transaction has an `Expiration` time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer. The result code of such a transaction depends on whether the [Checks amendment](reference-amendments.html#checks) is enabled. With the Checks amendment enabled, the transaction has the `tecEXPIRED` result code. Otherwise, the transaction has the `tesSUCCESS` transaction code. In either case, if the OfferCreate transaction includes an `OfferSequence` parameter, it can still successfully cancel a previous offer.
 
 ### Auto-Bridging