diff --git a/content/concepts/consensus-network/amendments/known-amendments.md b/content/concepts/consensus-network/amendments/known-amendments.md
index 52577b1c2b..20b8d80130 100644
--- a/content/concepts/consensus-network/amendments/known-amendments.md
+++ b/content/concepts/consensus-network/amendments/known-amendments.md
@@ -5,6 +5,7 @@ The following is a comprehensive list of all known amendments and their status o
| Name | Introduced | Status |
|:--------------------------------|:-----------|:------------------------------|
+| [HardenedValidations][] | v1.6.0-b5 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fix1781][] | v1.6.0-b1 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [CryptoConditionsSuite][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
@@ -12,7 +13,7 @@ The following is a comprehensive list of all known amendments and their status o
| [fixQualityUpperBound][] | v1.5.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.5.0.html "BADGE_80d0e0") |
| [RequireFullyCanonicalSig][] | v1.5.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.5.0.html "BADGE_80d0e0") |
| [FlowCross][] | v0.70.0 | [Open for Voting: TBD](https://xrpl.org/blog/2017/rippled-0.70.0.html "BADGE_80d0e0") |
-| [Checks][] | v0.90.0 | [Expected: 2020-06-18](https://xrpl.org/blog/2020/checks-expected.html "BADGE_BLUE") |
+| [Checks][] | v0.90.0 | [Enabled: 2020-06-18](https://xrpcharts.ripple.com/#/transactions/D88F2DCDFB10023F9F6CBA8DF34C18E321D655CAC8FDB962387A5DB1540242A6 "BADGE_GREEN") |
| [DeletableAccounts][] | v1.4.0 | [Enabled: 2020-05-08](https://xrpcharts.ripple.com/#/transactions/47B90519D31E0CB376B5FEE5D9359FA65EEEB2289F1952F2A3EB71D623B945DE "BADGE_GREEN") |
| [fixCheckThreading][] | v1.4.0 | [Enabled: 2020-05-01](https://xrpcharts.ripple.com/#/transactions/74AFEA8C17D25CA883D40F998757CA3B0DB1AC86794335BAA25FF20E00C2C30A "BADGE_GREEN") |
| [fixPayChanRecipientOwnerDir][] | v1.4.0 | [Enabled: 2020-05-01](https://xrpcharts.ripple.com/#/transactions/D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09 "BADGE_GREEN") |
@@ -54,7 +55,7 @@ The following is a comprehensive list of all known amendments and their status o
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
-| 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 | Expected |
+| 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 | Enabled |
Introduces "Checks" to the XRP Ledger. Checks work similarly to personal paper checks. The sender signs a transaction to create a Check for a specific maximum amount and destination. Later, the destination can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. If cashing the Check fails, the Check object remains in the ledger so it may be successfully cashed later.
@@ -454,6 +455,17 @@ Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange.
This is a previous version of the [Flow](#flow) amendment. It was [rejected due to a bug](https://xrpl.org/blog/2016/flowv2-vetoed.html) and removed in version 0.33.0.
+## HardenedValidations
+[HardenedValidations]: #hardenedvalidations
+
+| Amendment ID | Status |
+|:-----------------------------------------------------------------|:----------|
+| 1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 | In Development |
+
+Allows validators to include a new optional field in their validations to attest to the hash of
+the latest ledger that that validator considers to be fully validated. The consensus process can use this information to increase the robustness of consensus.
+
+
## MultiSign
[MultiSign]: #multisign
diff --git a/content/concepts/consensus-network/transaction-malleability.md b/content/concepts/consensus-network/transaction-malleability.md
index 5f5d80fcab..80b6d89be8 100644
--- a/content/concepts/consensus-network/transaction-malleability.md
+++ b/content/concepts/consensus-network/transaction-malleability.md
@@ -10,7 +10,7 @@ There are two circumstances that could lead to transaction malleability:
**Use the [tfFullyCanonicalSig flag](transaction-common-fields.html#global-flags)** to guarantee that a transaction is not malleable in this way. Although transactions [signed with Ed25519 keys](cryptographic-keys.html#signing-algorithms) are not vulnerable to this problem, **there is no downside** to using this flag on _all_ transactions.
- If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions are protected against malleability regardless of the tfFullyCanonicalSig flag.
+ If the [RequireFullyCanonicalSig amendment][] is enabled, all transactions are protected against malleability regardless of the tfFullyCanonicalSig flag.
2. The transaction is [multi-signed](multi-signing.html) and has more signatures than necessary. Even if the transaction originally did not have more signatures than necessary, it could be malleable if an authorized signer provides an additional signature.
diff --git a/content/concepts/decentralized-exchange/offers.ja.md b/content/concepts/decentralized-exchange/offers.ja.md
index cbf5c952ff..7e742abf8a 100644
--- a/content/concepts/decentralized-exchange/offers.ja.md
+++ b/content/concepts/decentralized-exchange/offers.ja.md
@@ -66,7 +66,7 @@ OfferCreateトランザクションの処理時に、このトランザクショ
**注記:** レジャーを変更できるのは新しいトランザクションだけであることから、有効期限切れのオファーは、非アクティブになった後でもレジャーに残ることがあります。このオファーは資金化されていないと見なされ特に影響はありませんが、（[ledger_entry](ledger_entry.html)コマンドなどの）実行結果に、引き続き表示される可能性があります。後に、サーバーが処理中に有効期限切れのオファーを検出すると、このオファーは別のトランザクション（別のOfferCreateなど）の結果として最終的に削除されることがあります。
-OfferCreateトランザクションが最初にレジャーに追加された時点で、このトランザクションに指定されている`Expiration`時刻をすでに経過していた場合は、トランザクションはオファーを実行しません。このようなトランザクションの結果コードは、[Checks Amendment][]:not_enabled:が有効であるかどうかによって異なります。Checks Amendmentが有効な場合、トランザクションの結果コードは`tecEXPIRED`です。それ以外の場合、トランザクションの結果コードは`tesSUCCESS`です。いずれの場合でも、このトランザクションには、[トランザクションコスト](transaction-cost.html)として支払われたXRPを消却する以外に影響はありません。
+OfferCreateトランザクションが最初にレジャーに追加された時点で、このトランザクションに指定されている`Expiration`時刻をすでに経過していた場合は、トランザクションはオファーを実行しません。このようなトランザクションの結果コードは、[Checks Amendment][]が有効であるかどうかによって異なります。Checks Amendmentが有効な場合、トランザクションの結果コードは`tecEXPIRED`です。それ以外の場合、トランザクションの結果コードは`tesSUCCESS`です。いずれの場合でも、このトランザクションには、[トランザクションコスト](transaction-cost.html)として支払われたXRPを消却する以外に影響はありません。
diff --git a/content/concepts/decentralized-exchange/offers.md b/content/concepts/decentralized-exchange/offers.md
index 32465f0940..1331af74dd 100644
--- a/content/concepts/decentralized-exchange/offers.md
+++ b/content/concepts/decentralized-exchange/offers.md
@@ -66,7 +66,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](ledger_entry.html) 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][]:not_enabled: 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, the transaction has no effect except to destroy the XRP paid as a [transaction cost](transaction-cost.html).
+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][] 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, the transaction has no effect except to destroy the XRP paid as a [transaction cost](transaction-cost.html).
## See Also
diff --git a/content/concepts/decentralized-exchange/ticksize.md b/content/concepts/decentralized-exchange/ticksize.md
index b4f2144c05..f4e417879b 100644
--- a/content/concepts/decentralized-exchange/ticksize.md
+++ b/content/concepts/decentralized-exchange/ticksize.md
@@ -1,6 +1,6 @@
# Tick Size
-_(Requires the [TickSize amendment][].)_
+_(Added by the [TickSize amendment][].)_
When an Offer is placed into an order book, its exchange rate is truncated based on the `TickSize` values set by the issuers of the currencies involved in the Offer. When a trader offers to exchange XRP and an issued currency, the `TickSize` from the issuer of the currency applies. When a trader offers to exchange two issued currencies, the offer uses the smaller `TickSize` value (that is, the one with fewer significant digits). If neither currency has a `TickSize` set, the default behavior applies.
diff --git a/content/concepts/issued-currencies/authorized-trust-lines.md b/content/concepts/issued-currencies/authorized-trust-lines.md
index 5df7c27669..4cc6de80eb 100644
--- a/content/concepts/issued-currencies/authorized-trust-lines.md
+++ b/content/concepts/issued-currencies/authorized-trust-lines.md
@@ -10,7 +10,7 @@ The transaction to authorize a trust line must be signed by the issuing address,
2. A customer sends a [TrustSet transaction][] to create a trust line from her XRP Ledger address to the gateway's issuing address. This indicates that she is willing to hold a specific currency issued by the gateway, up to a specific numeric limit.
3. The gateway's issuing address sends a TrustSet transaction authorizing the customer's trust line.
-**Tip:** An issuing gateway can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Requires the [TrustSetAuth amendment][].)_
+**Tip:** An issuing gateway can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_
## RequireAuth Setting
diff --git a/content/concepts/payment-system-basics/accounts/accounts.md b/content/concepts/payment-system-basics/accounts/accounts.md
index 09d5edad8a..cdcfef5463 100644
--- a/content/concepts/payment-system-basics/accounts/accounts.md
+++ b/content/concepts/payment-system-basics/accounts/accounts.md
@@ -69,7 +69,7 @@ To be deleted, an account must meet the following requirements:
- `Escrow`
- `PayChannel`
- `RippleState`
- - `Check` :not_enabled:
+ - `Check`
- The account must own fewer than 1000 objects in the ledger.
- The [AccountDelete transaction][] must pay a special [transaction cost][] equal to at least the [owner reserve](reserves.html) for one item (currently 5 XRP).
diff --git a/content/concepts/payment-system-basics/accounts/depositauth.md b/content/concepts/payment-system-basics/accounts/depositauth.md
index b763548e66..c1aa45c34d 100644
--- a/content/concepts/payment-system-basics/accounts/depositauth.md
+++ b/content/concepts/payment-system-basics/accounts/depositauth.md
@@ -1,6 +1,6 @@
# Deposit Authorization
-_(Requires the [DepositAuth amendment][].)_
+_(Added by the [DepositAuth amendment][].)_
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. _(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. _(Added by the [DepositPreauth amendment][].)_
## 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. _(Requires the [DepositPreauth amendment][])_
+ - If the destination has [preauthorized](#preauthorization) the sender of the Payment. _(Added by the [DepositPreauth amendment][])_
- 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. _(Requires the [DepositPreauth amendment][])_
+ - The destination of the PaymentChannelClaim transaction has [preauthorized](#preauthorization) the sender of the PaymentChannelClaim. _(Added by the [DepositPreauth amendment][])_
- 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. _(Requires the [DepositPreauth amendment][])_
-- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Requires the [Checks amendment][] :not_enabled:.)_
+ - The destination of the EscrowFinish transaction has [preauthorized](#preauthorization) the sender of the EscrowFinish. _(Added by the [DepositPreauth amendment][])_
+- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Added by the [Checks amendment][].)_
- **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
-_(Requires the [DepositPreauth amendment][].)_
+_(Added by the [DepositPreauth amendment][].)_
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.
diff --git a/content/concepts/payment-types/checks.ja.md b/content/concepts/payment-types/checks.ja.md
index f797dc50aa..684fe65b27 100644
--- a/content/concepts/payment-types/checks.ja.md
+++ b/content/concepts/payment-types/checks.ja.md
@@ -1,6 +1,6 @@
# Checks
-_（[Checks Amendment][]が必要です :not_enabled:）_
+_（[Checks Amendment][]が必要です）_
XRP LedgerのChecks機能を使用すると、指定の受取人による取消または換金が可能な後払いの支払いを生成することができます。個人用の紙の小切手と同様に、XRP Ledger Checksでは最初に資金の送金元が金額と受取人を指定するCheckを作成します。受取人はCheckを換金して、送金元のアカウントから受取人のアカウントに資金を移動します。受取人がCheckを換金するまでは、実際の資金移動は発生しません。Checkの作成時には資金は保留されていないことから、受取人が換金する時点で送金元に十分な資金がない場合、従来の小切手同様に換金が失敗します。Checkを換金できなかった場合、送信者はCheckが有効期限切れになるまで再試行できます。
@@ -15,7 +15,7 @@ Checksは[Escrow](escrow.html)と[Payment Channel](use-payment-channels.html)に
* EscrowではXRPを自分自身に送金できます。ChecksとPayment Channelを使用してXRP（Checksの場合は発行済み通貨）を自身に送金することはできません。
-**注記:** [Checks Amendment][]:not_enabled: により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](offers.html#オファーの有効期限)を参照してください。
+**注記:** [Checks Amendment][] により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](offers.html#オファーの有効期限)を参照してください。
## Checksを利用する理由
diff --git a/content/concepts/payment-types/checks.md b/content/concepts/payment-types/checks.md
index 3fa4d87839..e6f383b783 100644
--- a/content/concepts/payment-types/checks.md
+++ b/content/concepts/payment-types/checks.md
@@ -1,6 +1,6 @@
# Checks
-_(Requires the [Checks amendment][] :not_enabled:.)_
+_(Added by the [Checks amendment][].)_
The Checks feature in the XRP Ledger allows users to create deferred payments that can be canceled or cashed by the intended recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a Check that specifies an amount and a recipient. The recipient cashes the check to pull the funds from the sender's account into the recipient's account. No money moves until the recipient cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the recipient tries to cash it, just like traditional checks. If there's a failure cashing the check, the check's recipient can retry until the Check expires.
@@ -15,7 +15,7 @@ Checks are similar to [Escrow](escrow.html) and [Payment Channels](use-payment-c
* You can send XRP to yourself through Escrow. You cannot use Checks or Payment Channels to send XRP (or, in the case of Checks, issued currencies) to yourself.
-**Note:** The [Checks amendment][]:not_enabled: changes the expiration behavior of the [OfferCreate][] transaction. For more information, see [Offer Expiration](offers.html#offer-expiration).
+**Note:** The [Checks amendment][] changes the expiration behavior of the [OfferCreate][] transaction. For more information, see [Offer Expiration](offers.html#offer-expiration).
## Why Checks?
diff --git a/content/concepts/payment-types/direct-xrp-payments.md b/content/concepts/payment-types/direct-xrp-payments.md
index f8e724cb1d..5b20c9e870 100644
--- a/content/concepts/payment-types/direct-xrp-payments.md
+++ b/content/concepts/payment-types/direct-xrp-payments.md
@@ -66,7 +66,7 @@ From a relatively high level, the XRP Ledger's transaction processing engine app
- **Direct XRP Payments** are the only way to both send and receive XRP in a single transaction. They are a good balance of speed, simplicity, and low cost.
- [Cross-currency payments](cross-currency-payments.html) also use the [Payment][] transaction type, but can send any combination of XRP and non-XRP [issued currencies](issued-currencies.html) except XRP-to-XRP. They can also be [partial payments](partial-payments.html). Cross-currency payments are good for payments not denominated in XRP or for taking arbitrage opportunities in the [decentralized exchange](decentralized-exchange.html).
-- [Checks](checks.html) :not_enabled: let the sender set up an obligation without transferring any money immediately. The recipient can cash it any time before it expires, but the amount is not guaranteed. Checks can send either XRP or issued currencies. Checks are good for giving the recipient the autonomy to claim the payment.
+- [Checks](checks.html) let the sender set up an obligation without transferring any money immediately. The recipient can cash it any time before it expires, but the amount is not guaranteed. Checks can send either XRP or issued currencies. Checks are good for giving the recipient the autonomy to claim the payment.
- [Escrow](escrow.html) sets aside XRP which can be claimed by its intended recipient when certain conditions are met. The XRP amount is fully guaranteed and cannot be otherwise used by the sender unless the Escrow expires. Escrow is good for smart contracts in large amounts.
- [Payment Channels](payment-channels.html) set aside XRP. The recipient can claim XRP from the channel in bulk using signed authorizations. Individual authorizations can be verified without sending a full XRP Ledger transaction. Payment channels are good for extremely high-volume micropayments or "streaming" payments.
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md
index 6048f73160..cceb8bba24 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md
@@ -43,7 +43,7 @@ The `AccountRoot` object has the following fields:
| `EmailHash` | String | Hash128 | _(Optional)_ The md5 hash of an email address. Clients can use this to look up an avatar through services such as [Gravatar](https://en.gravatar.com/). |
| `MessageKey` | String | VariableLength | _(Optional)_ A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. No more than 33 bytes. |
| `RegularKey` | String | AccountID | _(Optional)_ The address of a [key pair](cryptographic-keys.html) that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction][] to change this value. |
-| `TickSize` | Number | UInt8 | _(Optional)_ How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Requires the [TickSize amendment][].)_ |
+| `TickSize` | Number | UInt8 | _(Optional)_ How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Added by the [TickSize amendment][].)_ |
| `TransferRate` | Number | UInt32 | _(Optional)_ A [transfer fee](https://ripple.com/knowledge_center/transfer-fees/) to charge other users for sending currency issued by this account to each other. |
| `WalletLocator` | String | Hash256 | _(Optional)_ **DEPRECATED**. Do not use. |
| `WalletSize` | Number | UInt32 | _(Optional)_ **DEPRECATED**. Do not use. |
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.ja.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.ja.md
index 43e3f5e2b7..cdb8d939f4 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.ja.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.ja.md
@@ -1,7 +1,7 @@
# Check
[[ソース]
](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170 "Source")
-_（[Checks Amendment][]が必要です :not_enabled:）_
+_（[Checks Amendment][]が必要です）_
`Check`オブジェクトはCheckを表します。Checkは紙の個人小切手に似ており、送金先はCheckを換金して送金元からの資金を獲得できます。（予定されている支払いは送金元によりすでに承認されていますが、換金されるまでは資金の移動は発生しません。[Escrow](escrow.html)とは異なり、Checkの資金は預託されず、資金不足が原因でCheckの換金が失敗することがあります。）
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md
index 285f342642..96655e82e3 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md
@@ -1,7 +1,7 @@
# Check
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170 "Source")
-_(Requires the [Checks amendment][] :not_enabled:.)_
+_(Added by the [Checks amendment][].)_
A `Check` object describes a check, similar to a paper personal check, which can be cashed by its destination to get money from its sender. (The potential payment has already been approved by its sender, but no money moves until it is cashed. Unlike an [Escrow](escrow.html), the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.)
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
index 5221939e45..3ce1dc1f02 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
@@ -1,7 +1,7 @@
# Escrow
[[Source]](https://github.com/ripple/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101 "Source")
-_(Requires the [Escrow amendment][].)_
+_(Added by the [Escrow amendment][].)_
The `Escrow` object type represents a held payment of XRP waiting to be executed or canceled. An [EscrowCreate transaction][] creates an `Escrow` object in the ledger. A successful [EscrowFinish][] or [EscrowCancel][] transaction deletes the object. If the ``Escrow`` object has a [_crypto-condition_](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), the payment can only succeed if an EscrowFinish transaction provides the corresponding _fulfillment_ that satisfies the condition. (The only supported crypto-condition type is [PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1).) If the `Escrow` object has a `FinishAfter` time, the held payment can only execute after that time.
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
index 6bff18b334..3cac47dfe7 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
@@ -1,7 +1,7 @@
# PayChannel
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L141-L155 "Source")
-_(Requires the [PayChan amendment][].)_
+_(Added by the [PayChan amendment][].)_
The `PayChannel` object type represents a payment channel. Payment channels enable small, rapid off-ledger payments of XRP that can be later reconciled with the consensus ledger. A payment channel holds a balance of XRP that can only be paid out to a specific destination address until the channel is closed. Any unspent XRP is returned to the channel's owner (the source address that created and funded it) when the channel closes.
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
index 2e9ee17e7e..ee4926972c 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
@@ -1,7 +1,7 @@
# SignerList
[[Source]](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
-_(Requires the [MultiSign amendment][].)_
+_(Added by the [MultiSign amendment][].)_
The `SignerList` object type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a SignerList using a [SignerListSet transaction][].
@@ -71,7 +71,7 @@ When processing a multi-signed transaction, the server dereferences the `Account
## {{currentpage.name}} Flags
-_(Requires the [MultiSignReserve amendment][].)_
+_(Added by the [MultiSignReserve amendment][].)_
SignerList objects can have the following flag value:
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
index 4fca67ae87..baede3c1e9 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
@@ -10,9 +10,9 @@ The types of objects that may appear in the `account_objects` response for an ac
- The account's [SignerList](signerlist.html), if the account has [multi-signing](multi-signing.html) enabled.
- [Escrow objects](escrow.html) for held payments that have not yet been executed or canceled.
- [PayChannel objects](paychannel.html) for open payment channels.
-- [Check objects](check.html) :not_enabled: for pending Checks.
+- [Check objects](check.html) for pending Checks.
- [DepositPreauth objects](depositpreauth-object.html) for deposit preauthorizations. [New in: rippled 1.1.0][]
-- [Ticket objects](known-amendments.html#tickets) :not_enabled: for tickets.
+- [Ticket objects](known-amendments.html#tickets) for tickets.
## Request Format
diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md
index 1bdf05da6d..065bfb72e0 100644
--- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md
+++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md
@@ -199,7 +199,7 @@ The response follows the [standard format][], with a successful result containin
| `ledger.transactions` | Array | (Omitted unless requested) Transactions applied in this ledger version. By default, members are the transactions' identifying [Hash][] strings. If the request specified `expand` as true, members are full representations of the transactions instead, in either JSON or binary depending on whether the request specified `binary` as true. |
| `ledger_hash` | String | Unique identifying hash of the entire ledger. |
| `ledger_index` | Number | The [Ledger Index][] of this ledger. |
-| `queue_data` | Array | (Omitted unless requested with the `queue` parameter) Array of objects describing queued transactions, in the same order as the queue. If the request specified `expand` as true, members contain full representations of the transactions, in either JSON or binary depending on whether the request specified `binary` as true. Requires the [FeeEscalation amendment][]. [New in: rippled 0.70.0][] |
+| `queue_data` | Array | (Omitted unless requested with the `queue` parameter) Array of objects describing queued transactions, in the same order as the queue. If the request specified `expand` as true, members contain full representations of the transactions, in either JSON or binary depending on whether the request specified `binary` as true. Added by the [FeeEscalation amendment][]. [New in: rippled 0.70.0][] |
The following fields are deprecated and may be removed without further notice: `accepted`, `hash` (use `ledger_hash` instead), `seqNum` (use `ledger_index` instead), `totalCoins` (use `total_coins` instead).
diff --git a/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_authorize.md b/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_authorize.md
index 92f182929f..626e62234d 100644
--- a/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_authorize.md
+++ b/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_authorize.md
@@ -1,7 +1,7 @@
# channel_authorize
[[Source]](https://github.com/ripple/rippled/blob/d4a56f223a3b80f64ff70b4e90ab6792806929ca/src/ripple/rpc/handlers/PayChanClaim.cpp#L41 "Source")
-_(Requires the [PayChan amendment][] to be enabled. [New in: rippled 0.33.0][])_
+_(Added by the [PayChan amendment][] to be enabled. [New in: rippled 0.33.0][])_
The `channel_authorize` method creates a signature that can be used to redeem a specific amount of XRP from a payment channel.
diff --git a/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_verify.md b/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_verify.md
index d45822e10f..a8e6171b5b 100644
--- a/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_verify.md
+++ b/content/references/rippled-api/public-rippled-methods/payment-channel-methods/channel_verify.md
@@ -1,7 +1,7 @@
# channel_verify
[[Source]](https://github.com/ripple/rippled/blob/d4a56f223a3b80f64ff70b4e90ab6792806929ca/src/ripple/rpc/handlers/PayChanClaim.cpp#L89 "Source")
-_(Requires the [PayChan amendment][] to be enabled. [New in: rippled 0.33.0][])_
+_(Added by the [PayChan amendment][] to be enabled. [New in: rippled 0.33.0][])_
The `channel_verify` method checks the validity of a signature that can be used to redeem a specific amount of XRP from a payment channel.
diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md
index fd1c1de911..f72b9ae9af 100644
--- a/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md
+++ b/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md
@@ -22,7 +22,7 @@ For the most part, transactions with `tec` codes take no action other than to de
| `tecINSUFF_FEE` | 136 | The transaction failed because the sending account does not have enough XRP to pay the [transaction cost](transaction-cost.html) that it specified. (In this case, the transaction processing destroys all of the sender's XRP even though that amount is lower than the specified transaction cost.) This result only occurs if the account's balance decreases _after_ this transaction has been distributed to enough of the network to be included in a consensus set. Otherwise, the transaction fails with [`terINSUF_FEE_B`](ter-codes.html) before being distributed. |
| `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 [SignerLists and Reserves](signerlist.html#signerlists-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. Requires the [EnforceInvariants amendment][]. 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). |
| `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][] |
| `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_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. |
@@ -30,7 +30,7 @@ For the most part, transactions with `tec` codes take no action other than to de
| `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. |
| `tecNO_ENTRY` | 140 | Reserved for future use. |
| `tecNO_ISSUER` | 133 | The account specified in the `issuer` field of a currency amount does not exist. |
-| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the tfFillOrKill flag and could not be filled, so it was killed. _(Requires the [fix1578 amendment][].)_ |
+| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the tfFillOrKill flag and could not be filled, so it was killed. _(Added by the [fix1578 amendment][].)_ |
| `tecNO_LINE` | 135 | The `TakerPays` field of the [OfferCreate transaction][] specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, `tecNO_AUTH` occurs instead. |
| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) |
| `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md
index 28c1580a11..2880535ed7 100644
--- a/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md
+++ b/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md
@@ -17,7 +17,7 @@ These codes indicate that the transaction failed and was not included in a ledge
| `tefEXCEPTION` | While processing the transaction, the server entered an unexpected state. This may be caused by unexpected inputs, for example if the binary data for the transaction is grossly malformed. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. |
| `tefFAILURE` | Unspecified failure in applying the transaction. |
| `tefINTERNAL` | When trying to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. |
-| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](transaction-cost.html). Requires the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
+| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](transaction-cost.html). Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
| `tefMASTER_DISABLED` | The transaction was signed with the account's master key, but the account has the `lsfDisableMaster` field set. |
| `tefMAX_LEDGER` | The transaction included a [`LastLedgerSequence`](reliable-transaction-submission.html#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. |
| `tefNO_AUTH_REQUIRED` | The [TrustSet transaction][] tried to mark a trustline as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. |
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md
index 02833dd7db..99514d06da 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md
@@ -30,7 +30,7 @@ An AccountSet transaction modifies the properties of an [account in the XRP Ledg
| MessageKey | String | Blob | _(Optional)_ Public key for sending encrypted messages to this account. |
| [SetFlag][] | Number | UInt32 | _(Optional)_ Integer flag to enable for this account. |
| [TransferRate][] | Unsigned Integer | UInt32 | _(Optional)_ The fee to charge when users transfer this account's issued currencies, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
-| [TickSize][] | Unsigned Integer | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Requires the [TickSize amendment][].)_ |
+| [TickSize][] | Unsigned Integer | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Added by the [TickSize amendment][].)_ |
| WalletLocator | String | Hash256 | _(Optional)_ Not used. |
| WalletSize | Number | UInt32 | _(Optional)_ Not used. |
@@ -71,7 +71,7 @@ The available AccountSet flags are:
|:-----------------|:--------------|:--------------------------|:--------------|
| asfAccountTxnID | 5 | (None) | Track the ID of this account's most recent transaction. Required for [AccountTxnID](transaction-common-fields.html#accounttxnid) |
| asfDefaultRipple | 8 | lsfDefaultRipple | Enable [rippling](rippling.html) on this account's trust lines by default. [New in: rippled 0.27.3][] |
-| asfDepositAuth | 9 | lsfDepositAuth | Enable [Deposit Authorization](depositauth.html) on this account. _(Requires the [DepositAuth amendment][].)_ |
+| asfDepositAuth | 9 | lsfDepositAuth | Enable [Deposit Authorization](depositauth.html) on this account. _(Added by the [DepositAuth amendment][].)_ |
| asfDisableMaster | 4 | lsfDisableMaster | Disallow use of the master key pair. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](cryptographic-keys.html) or a [Signer List](multi-signing.html). |
| asfDisallowXRP | 3 | lsfDisallowXRP | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) |
| asfGlobalFreeze | 7 | lsfGlobalFreeze | [Freeze](freezes.html) all assets issued by this account. |
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.ja.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.ja.md
index abb9484a10..264d8f5eec 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.ja.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.ja.md
@@ -1,7 +1,7 @@
# CheckCancel
[[ソース]
](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CancelCheck.cpp "Source")
-_（[Checks Amendment][]が必要です :not_enabled:）_
+_（[Checks Amendment][]が必要です）_
未清算のCheckを取り消し、送金を行わずにレジャーから削除します。Checkの送金元または送金先は、いつでもこのトランザクションタイプを使用してCheckを取り消すことができます。有効期限切れのCheckはすべてのアドレスが取り消すことができます。
@@ -31,4 +31,4 @@ _（[Checks Amendment][]が必要です :not_enabled:）_
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
-{% include '_snippets/rippled_versions.md' %}
\ No newline at end of file
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.md
index 4e7ba8c3cc..e55cd2b332 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcancel.md
@@ -1,7 +1,7 @@
# CheckCancel
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CancelCheck.cpp "Source")
-_(Requires the [Checks amendment][] :not_enabled:.)_
+_(Added by the [Checks amendment][].)_
Cancels an unredeemed Check, removing it from the ledger without sending any money. The source or the destination of the check can cancel a Check at any time using this transaction type. If the Check has expired, any address can cancel it.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcash.ja.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcash.ja.md
index 9377a3aeb5..e2b4c39e1a 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcash.ja.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcash.ja.md
@@ -1,7 +1,7 @@
# CheckCash
[[ソース]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CashCheck.cpp "Source")
-_（[Checks Amendment][]が必要です :not_enabled:）_
+_（[Checks Amendment][]が必要です）_
対応する[CheckCreateトランザクション][]で承認された額まで受領するため、レジャーでCheckオブジェクトの清算を試みます。CheckCashトランザクションでCheckを換金できるのは、Checkの`Destination`アドレスだけです。このCheckの換金方法は、送金先により開始される[Payment][]の実行に似ています。
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md
index 1ce8ba14bd..88037af138 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md
@@ -1,7 +1,7 @@
# CheckCash
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CashCheck.cpp "Source")
-_(Requires the [Checks amendment][] :not_enabled:.)_
+_(Added by the [Checks amendment][].)_
Attempts to redeem a Check object in the ledger to receive up to the amount authorized by the corresponding [CheckCreate transaction][]. Only the `Destination` address of a Check can cash it with a CheckCash transaction. Cashing a check this way is similar to executing a [Payment][] initiated by the destination.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.ja.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.ja.md
index 2ac8fd9a88..345ec0732f 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.ja.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.ja.md
@@ -1,7 +1,7 @@
# CheckCreate
[[ソース]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CreateCheck.cpp "Source")
-_（[Checks Amendment][]が必要です :not_enabled:）_
+_（[Checks Amendment][]が必要です）_
レジャーにCheckオブジェクトを作成します。これにより指定の送金先は後日換金することができます。このトランザクションの送信者はCheckの送金元です。
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md
index 124f8b3df9..1c0ba7e651 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md
@@ -1,7 +1,7 @@
# CheckCreate
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CreateCheck.cpp "Source")
-_(Requires the [Checks amendment][] :not_enabled:.)_
+_(Added by the [Checks amendment][].)_
Create a Check object in the ledger, which is a deferred payment that can be cashed by its intended destination. The sender of this transaction is the sender of the Check.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/depositpreauth.md b/content/references/rippled-api/transaction-formats/transaction-types/depositpreauth.md
index 23a1b4ee62..7fc1d99574 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/depositpreauth.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/depositpreauth.md
@@ -1,7 +1,7 @@
# DepositPreauth
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/DepositPreauth.cpp "Source")
-_Requires the [DepositPreauth amendment][]._
+_Added by the [DepositPreauth amendment][]._
A DepositPreauth transaction gives another account pre-approval to deliver payments to the sender of this transaction. This is only useful if the sender of this transaction is using (or plans to use) [Deposit Authorization](depositauth.html).
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/escrowcancel.md b/content/references/rippled-api/transaction-formats/transaction-types/escrowcancel.md
index 265a5b601c..fb7ab04cae 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/escrowcancel.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/escrowcancel.md
@@ -2,7 +2,7 @@
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
-_Requires the [Escrow amendment][]._
+_Added by the [Escrow amendment][]._
Return escrowed XRP to the sender.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/escrowcreate.md b/content/references/rippled-api/transaction-formats/transaction-types/escrowcreate.md
index 1dc33cbca6..3c96c3815c 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/escrowcreate.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/escrowcreate.md
@@ -2,7 +2,7 @@
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
-_Requires the [Escrow amendment][]._
+_Added by the [Escrow amendment][]._
Sequester XRP until the escrow process either finishes or is canceled.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md b/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md
index 8210eaa5a8..873ca4cead 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md
@@ -2,7 +2,7 @@
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/Escrow.cpp "Source")
-_Requires the [Escrow amendment][]._
+_Added by the [Escrow amendment][]._
Deliver XRP from a held payment to the recipient.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md
index fbb5719b92..609fbd878c 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md
@@ -1,7 +1,7 @@
# PaymentChannelClaim
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp "Source")
-_Requires the [PayChan amendment][]._
+_Added by the [PayChan amendment][]._
Claim XRP from a payment channel, adjust the payment channel's expiration, or both. This transaction can be used differently depending on the transaction sender's role in the specified channel:
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelcreate.md b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelcreate.md
index 924e95982b..fa660179d7 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelcreate.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelcreate.md
@@ -1,7 +1,7 @@
# PaymentChannelCreate
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp "Source")
-_Requires the [PayChan amendment][]._
+_Added by the [PayChan amendment][]._
Create a unidirectional channel and fund it with XRP. The address sending this transaction becomes the "source address" of the payment channel.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelfund.md b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelfund.md
index c5188619ce..ed9b7f3795 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelfund.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelfund.md
@@ -1,7 +1,7 @@
# PaymentChannelFund
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp "Source")
-_Requires the [PayChan amendment][]._
+_Added by the [PayChan amendment][]._
Add additional XRP to an open payment channel, update the expiration time of the channel, or both. Only the source address of the channel can use this transaction. (Transactions from other addresses fail with the error `tecNO_PERMISSION`.)
diff --git a/content/tutorials/get-started/look-up-transaction-results.md b/content/tutorials/get-started/look-up-transaction-results.md
index 2fdb4deeba..607bd89197 100644
--- a/content/tutorials/get-started/look-up-transaction-results.md
+++ b/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:
diff --git a/content/tutorials/get-started/monitor-incoming-payments-with-websocket.md b/content/tutorials/get-started/monitor-incoming-payments-with-websocket.md
index d8e7b12656..1cb2b6722b 100644
--- a/content/tutorials/get-started/monitor-incoming-payments-with-websocket.md
+++ b/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.
diff --git a/content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md b/content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md
index ef6536d1a5..856919ad79 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md
+++ b/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.
diff --git a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md b/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md
index dc7b7ed51e..bcf883f6f4 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md
+++ b/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.
diff --git a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-an-exact-amount.md b/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-an-exact-amount.md
index 0a547fbcc3..bef078c97c 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-an-exact-amount.md
+++ b/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.
diff --git a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md b/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md
index bcbd8bea35..7b39479af0 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md
+++ b/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).
diff --git a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md b/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md
index b1b5c46c0d..3df4cc7674 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md
+++ b/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).
diff --git a/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md b/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
index bee3dd3e3e..6ebe7800af 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
+++ b/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.
diff --git a/dactyl-config.yml b/dactyl-config.yml
index 3f852d8472..ce2264fe50 100644
--- a/dactyl-config.yml
+++ b/dactyl-config.yml
@@ -613,7 +613,6 @@ pages:
doc_type: Concepts
category: Payment Types
blurb: Checks let users create deferred payments that can be canceled or cashed by the intended recipients.
- status: not_enabled
targets:
- en
@@ -623,7 +622,6 @@ pages:
doc_type: Concepts
category: Payment Types
blurb: Checks let users create deferred payments that can be canceled or cashed by the intended recipients. #TODO:translate
- status: not_enabled
targets:
- ja
@@ -1760,7 +1758,6 @@ pages:
category: Use Specialized Payment Types
subcategory: Use Checks
blurb: Checks in the XRP Ledger authorize another account to claim funds later, similar to how personal paper checks work.
- status: not_enabled
template: template-landing-children.html
targets:
- en
@@ -1772,7 +1769,6 @@ pages:
category: Use Specialized Payment Types
subcategory: Use Checks
blurb: Checks in the XRP Ledger authorize another account to claim funds later, similar to how personal paper checks work.
- status: not_enabled
template: template-landing-children.html
targets:
- ja
@@ -1783,7 +1779,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- en
@@ -1793,7 +1788,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- ja
@@ -1803,7 +1797,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- en
@@ -1813,7 +1806,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- ja
@@ -1823,7 +1815,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- en
@@ -1833,7 +1824,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- ja
@@ -1843,7 +1833,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- en
@@ -1853,7 +1842,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- ja
@@ -1863,7 +1851,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- en
@@ -1873,7 +1860,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- ja
@@ -1883,7 +1869,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- en
@@ -1893,7 +1878,6 @@ pages:
doc_type: Tutorials
category: Use Specialized Payment Types
subcategory: Use Checks
- status: not_enabled
targets:
- ja
@@ -4578,7 +4562,6 @@ pages:
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: A check that can be redeemed for money by its destination.
- status: not_enabled
targets:
- en
@@ -4590,7 +4573,6 @@ pages:
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: A check that can be redeemed for money by its destination. #TODO:translate
- status: not_enabled
targets:
- ja
@@ -4900,7 +4882,6 @@ pages:
category: Transaction Formats
subcategory: Transaction Types
blurb: Cancel a check.
- status: not_enabled
targets:
- en
@@ -4912,7 +4893,6 @@ pages:
category: Transaction Formats
subcategory: Transaction Types
blurb: 未清算のCheckを取り消し、送金を行わずにレジャーから削除します。
- status: not_enabled
targets:
- ja
@@ -4924,7 +4904,6 @@ pages:
category: Transaction Formats
subcategory: Transaction Types
blurb: Redeem a check.
- status: not_enabled
targets:
- en
@@ -4936,7 +4915,6 @@ pages:
category: Transaction Formats
subcategory: Transaction Types
blurb: レジャーでCheckオブジェクトの清算を試みます。
- status: not_enabled
targets:
- ja
@@ -4948,7 +4926,6 @@ pages:
category: Transaction Formats
subcategory: Transaction Types
blurb: Create a check.
- status: not_enabled
targets:
- en
@@ -4960,7 +4937,6 @@ pages:
category: Transaction Formats
subcategory: Transaction Types
blurb: レジャーにCheckオブジェクトを作成します
- status: not_enabled
targets:
- ja