Checks enabled

content/tutorials/get-started/look-up-transaction-results.md

@@ -353,7 +353,7 @@ In the following excerpt, we see that r9UUEX...'s balance increases by 1 billion
 
 Look for a `CreatedNode` of LedgerEntryType `PayChannel` when creating a payment channel. You should also find a `ModifiedNode` of LedgerEntryType `AccountRoot` showing the decrease in the sender's balance. Look for an `Account` field in the `FinalFields` to confirm that the address matches the sender, and look at the difference in the `Balance` fields to see the change in XRP balance.
 
-If the [fixPayChanRecipientOwnerDir amendment](known-amendments.html#fixpaychanrecipientownerdir) :not_enabled: is enabled, the metadata should also change the destination account's [owner directory](directorynode.html) to list the newly-created payment channel. This prevents an account from [being deleted](accounts.html#deletion-of-accounts) if it is the receiver of an open payment channel. (If the payment channel was created before the fixPayChanRecipientOwnerDir amendment became enabled, the account can be deleted.)
+The metadata also lists the newly-created payment channel in the destination's [owner directory](directorynode.html). This prevents an account from [being deleted](accounts.html#deletion-of-accounts) if it is the destination of an open payment channel. (This behavior was added by the [fixPayChanRecipientOwnerDir amendment](known-amendments.html#fixpaychanrecipientownerdir).)
 
 There are several ways to request to close a payment channel, aside from the immutable `CancelAfter` time of the channel (which is only set on creation). If a transaction schedules a channel to close, there is  a `ModifiedNode` entry of LedgerEntryType `PayChannel` for the channel, with the newly-added close time in the `Expiration` field of the `FinalFields`. The following example shows the changes to a `PayChannel` in a case where the sender requested to close the channel without redeeming a claim:
 

content/tutorials/get-started/monitor-incoming-payments-with-websocket.md

@@ -337,7 +337,7 @@ When you subscribe to an account, you get messages for _all transactions to or f
 
         **Warning:** If you use the `transaction.Amount` field instead, you may be vulnerable to the [partial payments exploit](partial-payments.html#partial-payments-exploit). Malicious users can use this exploit to trick you into allowing the malicious user to trade or withdraw more money than they paid you.
 
-    - **[CheckCash transactions][]** :not_enabled: allow an account to receive money authorized by a different account's [CheckCreate transaction][]. Look at the metadata of a **CheckCash transaction** to see how much currency the account received.
+    - **[CheckCash transactions][]** allow an account to receive money authorized by a different account's [CheckCreate transaction][]. Look at the metadata of a **CheckCash transaction** to see how much currency the account received.
 
     - **[EscrowFinish transactions][]** can deliver XRP by finishing an [Escrow](escrow.html) created by a previous [EscrowCreate transaction][]. Look at the metadata of the **EscrowFinish transaction** to see which account received XRP from the escrow and how much.
 

content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md

@@ -1,6 +1,6 @@
 # Cancel a Check
 
-_Requires the [Checks amendment][]._
+_Added by the [Checks amendment][]._
 
 This tutorial shows how to cancel a [Check](checks.html), which removes the [Check object from the ledger](check.html) without sending money.
 

content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md

@@ -1,6 +1,6 @@
 # Cash a Check for a Flexible Amount
 
-_Requires the [Checks amendment][]._
+_Added by the [Checks amendment][]._
 
 As long as the Check is in the ledger and not expired, the specified recipient can cash it to receive a flexible amount by sending a [CheckCash transaction][] with a `DeliverMin` field. When cashing a Check in this way, the receiver gets as much as is possible to deliver, debiting the Check's sender for the Check's full `SendMax` amount or as much as is available. Cashing fails if it doesn't deliver at least the `DeliverMin` amount to the Check's recipient.
 

content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-an-exact-amount.md

@@ -1,6 +1,6 @@
 # Cash a Check for an Exact Amount
 
-_Requires the [Checks amendment][]._
+_Added by the [Checks amendment][]._
 
 As long as the Check is in the ledger and not expired, the specified recipient can cash it to receive any exact amount up to the amount specified in the Check by sending a [CheckCash transaction][] with an `Amount` field. You would cash a Check this way if you want to receive a specific amount, for example to pay off an invoice or bill exactly.
 

content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md

@@ -1,6 +1,6 @@
 # Look Up Checks by Recipient
 
-_Requires the [Checks amendment][]._
+_Added by the [Checks amendment][]._
 
 This tutorial shows how to look up [Checks](checks.html) by their recipient. You may also want to [look up Checks by sender](look-up-checks-by-sender.html).
 

content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md

@@ -1,6 +1,6 @@
 # Look Up Checks by Sender
 
-_Requires the [Checks amendment][]._
+_Added by the [Checks amendment][]._
 
 This tutorial shows how to look up [Checks](checks.html) by their sender. You may also want to [look up Checks by recipient](look-up-checks-by-recipient.html).
 

content/tutorials/use-complex-payment-types/use-checks/send-a-check.md

@@ -1,6 +1,6 @@
 # Send a Check
 
-_Requires the [Checks amendment][]._
+_Added by the [Checks amendment][]._
 
 Sending a Check is like writing permission for an intended recipient to pull a payment from you. The outcome of this process is a [Check object in the ledger](check.html) which the recipient can cash later.