Use :enabled: and :not_enabled: for amendments

content/concepts/payment-system-basics/accounts/depositauth.md

@@ -1,6 +1,6 @@
 # Deposit Authorization
 
-_((ENABLED_ICON) Requires the [DepositAuth amendment](known-amendments.html#depositauth).)_
+_(Requires the [DepositAuth amendment][] :enabled:.)_
 
 Deposit Authorization is an optional feature of an [account](accounts.html) in the XRP Ledger. With Deposit Authorization enabled, transactions cannot send value of any kind to the account unless the sender of those transactions is the account itself. This includes transfers of XRP and issued currencies.
 
@@ -14,7 +14,7 @@ The Deposit Authorization flag introduces an option for those using the XRP Ledg
 
 When you have Deposit Authorization enabled, you can receive money from [Checks](known-amendments.html#checks), [Escrow](escrow.html), and [Payment Channels](known-amendments.html#paychan). In these transactions' "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds.
 
-To receive money from [Payment transactions][] when you have Deposit Authorization enabled, you must [preauthorize](#preauthorization) the senders of those Payments. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
+To receive money from [Payment transactions][] when you have Deposit Authorization enabled, you must [preauthorize](#preauthorization) the senders of those Payments. _(Requires the [DepositPreauth amendment][] :enabled:.)_
 
 ## Recommended Usage
 
@@ -29,15 +29,15 @@ To get the full effect of Deposit Authorization, Ripple recommends also doing th
 An account with Deposit Authorization enabled:
 
 - **Cannot** be the destination of [Payment transactions][], with **the following exceptions**:
-    - If the destination has [preauthorized](#preauthorization) the sender of the Payment. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
+    - If the destination has [preauthorized](#preauthorization) the sender of the Payment. _(Requires the [DepositPreauth amendment][] :enabled:)_
     - If the account's XRP balance is equal to or below the minimum account [reserve requirement](reserves.html), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 20 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
 - Can receive XRP from [PaymentChannelClaim transactions][] **only in the following cases**:
     - The sender of the PaymentChannelClaim transaction is the destination of the payment channel.
-    - The destination of the PaymentChannelClaim transaction has [preauthorized](#preauthorization) the sender of the PaymentChannelClaim. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
+    - The destination of the PaymentChannelClaim transaction has [preauthorized](#preauthorization) the sender of the PaymentChannelClaim. _(Requires the [DepositPreauth amendment][] :enabled:)_
 - Can receive XRP from [EscrowFinish transactions][] **only in the following cases**:
     - The sender of the EscrowFinish transaction is the destination of the escrow.
-    - The destination of the EscrowFinish transaction has [preauthorized](#preauthorization) the sender of the EscrowFinish. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
-- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _((NOT_ENABLED_ICON) Requires the [Checks amendment](known-amendments.html#checks).)_
+    - The destination of the EscrowFinish transaction has [preauthorized](#preauthorization) the sender of the EscrowFinish. _(Requires the [DepositPreauth amendment][] :enabled:)_
+- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Requires the [Checks amendment][] :not_enabled:.)_
 - **Can** receive XRP or issued currencies by sending [OfferCreate transactions][].
     - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the remainder of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions.
 - If the account has created any trust lines without the [NoRipple flag](rippling.html) enabled, or has enabled the DefaultRipple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions.
@@ -64,7 +64,7 @@ If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (
 
 ## Preauthorization
 
-_((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
+_(Requires the [DepositPreauth amendment][] :enabled:.)_
 
 Accounts with DepositAuth enabled can _preauthorize_ certain senders, to allow payments from those senders to succeed even with DepositAuth enabled. This allows specific senders to send funds directly without the receiver taking action on each transaction individually. Preauthorization is not required to use DepositAuth, but can make certain operations more convenient.
 

content/concepts/payment-system-basics/accounts/reserves.md

@@ -21,7 +21,7 @@ Many objects in the ledger are owned by a particular address, and count toward t
 
 - [Offers](offer.html) are owned by the address that placed them. Transaction processing automatically removes Offers that are fully consumed or found to be unfunded. Alternatively, the owner can cancel an Offer by sending an [OfferCancel transaction][], or by sending an [OfferCreate transaction][] that contains an `OfferSequence` parameter.
 - [Trust lines](ripplestate.html) are shared between two addresses. The owner reserve can apply to one or both of the addresses, depending on whether the fields that address controls are in their default state. See [Contributing to the Owner Reserve](ripplestate.html#contributing-to-the-owner-reserve) for details.
-- Without the [MultiSignReserve amendment](known-amendments.html#multisignreserve), a single [SignerList](signerlist.html) counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. With the [MultiSignReserve amendment](known-amendments.html#multisignreserve) enabled, a single SignerList counts as 1 object for purposes of the owner reserve, regardless of the number of members it has. See also: [SignerLists and Reserves](signerlist.html#signerlists-and-reserves).
+- Without the [MultiSignReserve amendment][], a single [SignerList](signerlist.html) counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. With the [MultiSignReserve amendment][] enabled, a single SignerList counts as 1 object for purposes of the owner reserve, regardless of the number of members it has. See also: [SignerLists and Reserves](signerlist.html#signerlists-and-reserves).
 - [Held Payments (Escrow)](escrow-object.html) are owned by the address that placed them.
 - [Payment Channels](use-payment-channels.html) are owned by the address that created them.
 - [Owner directories](directorynode.html) list all the ledger objects that contribute to an address's owner reserve. However, the owner directory itself does not count towards the reserve.

content/concepts/payment-system-basics/transaction-basics/transaction-cost.md

@@ -30,7 +30,7 @@ The transaction cost is not paid to any party: the XRP is irrevocably destroyed.
 
 ## Load Cost and Open Ledger Cost
 
-When the [FeeEscalation amendment](known-amendments.html#feeescalation) is enabled, there are two thresholds for the transaction cost:
+When the [FeeEscalation amendment][] is enabled, there are two thresholds for the transaction cost:
 
 * If the transaction cost does not meet a `rippled` server's [load-based transaction cost threshold](#local-load-cost), the server ignores the transaction completely. (This logic is essentially unchanged with or without the amendment.)
 * If the transaction cost does not meet a `rippled` server's [open ledger cost threshold](#open-ledger-cost), the server queues the transaction for a later ledger.
@@ -82,7 +82,7 @@ _Fee levels_ represent the proportional difference between the minimum cost and
 
 The `rippled` APIs have two ways to query the local load-based transaction cost: the `server_info` command (intended for humans) and the `server_state` command (intended for machines).
 
-If the [FeeEscalation amendment](known-amendments.html#feeescalation) is enabled, you can use the [fee method][] to check the open ledger cost.
+If the [FeeEscalation amendment][] is enabled, you can use the [fee method][] to check the open ledger cost.
 
 ### server_info
 
@@ -144,7 +144,7 @@ This feature is designed to allow you to recover an account if the regular key i
 
 The [lsfPasswordSpent flag](accountroot.html) starts out disabled. It gets enabled when you send a SetRegularKey transaction signed by the master key pair. It gets disabled again when the account receives a [Payment](payment.html) of XRP.
 
-When the [FeeEscalation amendment](known-amendments.html#feeescalation) is enabled, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
+When the [FeeEscalation amendment][] is enabled, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
 
 
 ## Changing the Transaction Cost