Fix links in Accounts section.

content/concepts/accounts/account-deleting.md

@@ -27,4 +27,3 @@ After an account is deleted, you can recreate the account in the ledger through
 Unlike Bitcoin and many other cryptocurrencies, each new version of the XRP Ledger's public ledger chain contains the full state of the ledger, which increases in size with each new account. For that reason, you should not create new XRP Ledger accounts unless necessary. You can recover some of an account's 10 XRP reserve by deleting the account, but you must still destroy at least 2 XRP to do so.
 
 Institutions who send and receive value on behalf of many users can use **Source Tags** and **Destination Tags** to distinguish payments from and to their customers while only using one (or a handful) of accounts in the XRP Ledger.
-

content/concepts/accounts/account-types.md

@@ -25,7 +25,7 @@ If a malicious actor learns the secret key behind a institution's issuing accoun
 
 ### Multiple Issuing Accounts
 
-A financial institution can issue more than one type of token in the XRP Ledger from a single issuing account. However, there are some settings that apply equally to all (fungible) tokens issued from an account, including the percentage for [transfer fees](../tokens/transfer-fees.md) and the [global freeze](../tokens/freezing-tokens.md) status. If the financial institution wants the flexibility to manage settings differently for each type of token, the institution must multiple issuing accounts.
+A financial institution can issue more than one type of token in the XRP Ledger from a single issuing account. However, there are some settings that apply equally to all (fungible) tokens issued from an account, including the percentage for [transfer fees](transfer-fees.html) and the [global freeze](freezing-tokens.html) status. If the financial institution wants the flexibility to manage settings differently for each type of token, the institution must multiple issuing accounts.
 
 
 ## Operational Accounts
@@ -67,20 +67,3 @@ Operational accounts, which are operated by automated systems, send payments to
 As always, token payments must "ripple through" the issuer across trust lines with sufficient limits.
 
 Eventually, someone sends tokens back to the issuer. This destroys those tokens, reducing the issuer's obligations in the XRP Ledger. If the token is a stablecoin, this is the first step of redeeming the tokens for the corresponding off-ledger assets.
-
-<!--
-
-## See Also
-
-- **Concepts:**
-    - [Accounts](accounts.html)
-    - [Cryptographic Keys](cryptographic-keys.html)
-- **Tutorials:**
-    - [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
-    - [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
-    - [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
-- **References:**
-    - [account_info method][]
-    - [SetRegularKey transaction][]
-    - [AccountRoot object](accountroot.html)
--->

content/concepts/accounts/accounts.md

@@ -24,6 +24,3 @@ The typical way to get an account in the XRP Ledger is as follows:
 **Caution:** Funding an account _does not_ give you any special privileges over that account. Whoever has the secret key corresponding to the account's address has full control over the account and all XRP it contains. For some addresses, it is possible that no one has the secret key, in which case the account is a black hole and the XRP is lost forever.
 
 **Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the account reserve (currently 10 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers do not have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price.      
-
-
-

content/concepts/accounts/addresses.md

@@ -15,7 +15,7 @@ Accounts in the XRP Ledger are identified by an address in the XRP Ledger's base
 * Case-sensitive
 * Includes a 4-byte checksum so that the probability of generating a valid address from random characters is approximately 1 in 2<sup>32</sup>
 
-> **Note:** The XRP community has proposed an **X**-address format that "packs" a destination tag into the address. These addresses start with an `X` (for the mainnet) or a `T` (for the [testnet](../networks/parallel-networks.md)). Exchanges and wallets can use X-addresses to represent all the data a customer needs to know in one value. For more information, see the [X-address format site](https://xrpaddress.info/) and [codec](https://github.com/xrp-community/xrpl-tagged-address-codec).
+> **Note:** The XRP community has proposed an **X**-address format that "packs" a destination tag into the address. These addresses start with an `X` (for the mainnet) or a `T` (for the [testnet](parallel-networks.html)). Exchanges and wallets can use X-addresses to represent all the data a customer needs to know in one value. For more information, see the [X-address format site](https://xrpaddress.info/) and [codec](https://github.com/xrp-community/xrpl-tagged-address-codec).
 >
 > The XRP Ledger protocol only supports "classic" addresses natively, but many client libraries support X-addresses too.
 
@@ -27,8 +27,6 @@ Any valid address can become an account in the XRP Ledger by being funded. You c
 
 Creating a valid address is a strictly mathematical task starting with a key pair. You can generate a key pair and calculate its address entirely offline without communicating to the XRP Ledger or any other party. The conversion from a public key to an address involves a one-way hash function, so it is possible to confirm that a public key matches an address but it is impossible to derive the public key from the address alone. (This is part of the reason why signed transactions include the public key _and_ the address of the sender.)
 
-For more technical details of how to calculate an XRP Ledger address, see [Address Encoding](#address-encoding).
-
 
 ## Address Encoding
 

content/concepts/accounts/cryptographic-keys.md

@@ -7,7 +7,7 @@ labels:
 ---
 # Cryptographic Keys
 
-In the XRP Ledger, a digital signature _authorizes_ a [transaction](../transactions/transactions.md) to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger.
+In the XRP Ledger, a digital signature _authorizes_ a [transaction](transactions.html) to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger.
 
 To make a digital signature, you use a cryptographic key pair associated with the transaction's sending account. A key pair can be generated using any of the XRP Ledger's supported cryptographic signing algorithms signing-algorithms. A key pair can be used as a master key pair, regular key pair, or a member of a signer list, regardless of what algorithm was used to generate it.
 
@@ -44,7 +44,7 @@ The passphrase is secret information, so you must protect it very carefully. Any
 
 ### Seed
 
-A _seed_ value is a compact value that is used to derive the actual private and public keys for an account. In a `wallet_propose` method response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to sign transactions in the rippled APIs and some [other XRP Ledger software](xrpl-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
+A _seed_ value is a compact value that is used to derive the actual private and public keys for an account. In a `wallet_propose` method response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to sign transactions in the rippled APIs and some other XRP Ledger software. Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
 
 The seed value is secret information, so you must protect it very carefully. Anyone who has knows an address's seed value has effectively full control over that address.
 
@@ -246,19 +246,9 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu
 
     See [Address Encoding](addresses.html#address-encoding) for information and sample code to convert from an account's public key to its address.
 
-<!--
 
 ## See Also
 
-- **Concepts:**
-    - [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
 - **Tutorials:**
     - [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
     - [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
-- **References:**
-    - [SetRegularKey transaction][]
-    - [AccountRoot ledger object](accountroot.html)
-    - [wallet_propose method][]
-    - [account_info method][]
-    
--->

content/concepts/accounts/deposit-authorization.md

@@ -11,7 +11,7 @@ _(Added by the DepositAuth amendment.)_
 
 Deposit Authorization is an optional account setting in the XRP Ledger. If enabled, Deposit Authorization blocks all transfers from strangers, including transfers of XRP and [tokens](tokens.html). An account with Deposit Authorization can only receive value in two ways:
 
-- From accounts it has [preauthorized](#preauthorization).
+- From accounts it has preauthorized.
 - By sending a transaction to receive the funds. For example, an account with Deposit Authorization could finish an escrow that was initiated by a stranger.
 
 By default, new accounts have DepositAuth disabled and can receive XRP from anyone.
@@ -24,7 +24,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, escrow, and payment channels. 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. _(Added by the `DepositPreauth` amendment.)_
+To receive money from `Payment` transactions when you have Deposit Authorization enabled, you must preauthorize the senders of those Payments.
 
 ## Recommended Usage
 
@@ -39,15 +39,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. _(Added by the DepositPreauth amendment)_
+    - If the destination has preauthorized the sender of the Payment.
     - If the account's XRP balance is equal to or below the minimum account reserve requirement, it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 10 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. _(Added by the DepositPreauth amendment)_
+    - The destination of the `PaymentChannelClaim` transaction has preauthorized the sender of the PaymentChannelClaim.
 - 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`. _(Added by the DepositPreauth amendment)_
-- **Can** receive XRP or tokens by sending a `CheckCash` transaction. _(Added by the Checks amendment.)_
+    - The destination of the `EscrowFinish` transaction has preauthorized the sender of the `EscrowFinish`.
+- **Can** receive XRP or tokens by sending a `CheckCash` transaction.
 - **Can** receive XRP or tokens by sending `OfferCreate` transactions.
     - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the rest of the ordered XRP or token later when the offer is consumed by other accounts' `Payment` and `OfferCreate` transactions.
 - If the account has created any trust lines without the No Ripple flag enabled, or has enabled the Default Ripple flag and issued any currency, the account **can** receive the tokens of those trust lines in `Payment` transactions as a result of rippling. It cannot be the destination of those transactions.
@@ -76,8 +76,6 @@ If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (
 
 ## Preauthorization
 
-_(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.
 
 Preauthorization is currency-agnostic. You cannot preauthorize accounts for specific currencies only.
@@ -105,14 +103,9 @@ You can use the `deposit_authorized` method to see if an account is authorized t
 - Whether the destination account requires Deposit Authorization. (If it does not require authorization, then all source accounts are considered authorized.)
 - Whether the source account is preauthorized to send money to the destination.
 
-<!--
+
 ## See Also
 
-- The [DepositPreauth transaction][] reference.
-- The [DepositPreauth ledger object type](depositpreauth-object.html).
-- The [deposit_authorized method][] of the [`rippled` API](http-websocket-apis.html).
-- The [Authorized Trust Lines](authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
-- The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.)
-- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](become-an-xrp-ledger-gateway.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
-- [Partial Payments](partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
--->
+- **Concepts:**
+    - [Authorized Trust Lines](authorized-trust-lines.html)
+    - [Partial Payments](partial-payments.html)

content/concepts/accounts/reserves.md

@@ -13,7 +13,7 @@ To have an account, an address must hold a minimum amount of XRP in the shared g
 
 The current minimum reserve requirement is **10 XRP**. (This is the cost of an address that owns no other objects in the ledger.) Each new account must set aside this much XRP. Some of this XRP can be recovered by deleting the account.
 
-The [Fee Voting](../xrpl/fee-voting.md) process can change the reserve requirement if enough validators agree to new reserve settings.
+The [Fee Voting](fee-voting.html) process can change the reserve requirement if enough validators agree to new reserve settings.
 
 
 ## Base Reserve and Owner Reserve
@@ -50,25 +50,13 @@ The XRP Ledger considers an `OfferCreate` transaction to be an explicit statemen
 
 ## Going Below the Reserve Requirement
 
-During transaction processing, the [transaction cost](../transactions/transaction-cost.md) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement.
+During transaction processing, the [transaction cost](transaction-cost.html) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement.
 
-When an address holds less XRP than its current reserve requirement, it cannot send new transactions that would transfer XRP to others, or increase its own reserve. Even so, the address continues to exist in the ledger and can send other transactions as long as it has enough XRP to pay the transaction cost. The address can become able to send all types of transactions again if it receives enough XRP to meet its reserve requirement again, or if the [reserve requirement decreases](#changing-the-reserve-requirements) to less than the address's XRP holdings.
+When an address holds less XRP than its current reserve requirement, it cannot send new transactions that would transfer XRP to others, or increase its own reserve. Even so, the address continues to exist in the ledger and can send other transactions as long as it has enough XRP to pay the transaction cost. The address can become able to send all types of transactions again if it receives enough XRP to meet its reserve requirement again, or if the reserve requirement decreases to less than the address's XRP holdings.
 
 **Tip:** When an address is below the reserve requirement, it can send new `OfferCreate transactions` to acquire more XRP, or other currencies on its existing trust lines. These transactions cannot create new trust lines or Offer nodes in the ledger, so they can only execute trades that consume offers that are already in the order books.
 
 
 ## Changing the Reserve Requirements
 
-The XRP Ledger has a mechanism to adjust the reserve requirements. Such adjustments may consider, for example, long-term changes in the value of XRP, improvements in the capacity of commodity-level machine hardware, or increased efficiency in the server software implementation. Any changes have to be approved by the consensus process. See [Fee Voting](../xrpl/fee-voting.md) for more information.
-
-<!--
-## See Also
-
-- [account_objects method][]
-- [AccountRoot Object][]
-- [Fee Voting](fee-voting.html)
-
-
-
-- [SetFee pseudo-transaction][]
--->
+The XRP Ledger has a mechanism to adjust the reserve requirements. Such adjustments may consider, for example, long-term changes in the value of XRP, improvements in the capacity of commodity-level machine hardware, or increased efficiency in the server software implementation. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information.

content/concepts/xrpl/xrpl-ecosystem.md

@@ -1,4 +1,10 @@
-# Understanding the XRPL Ecosystem
+---
+html: xrpl-ecosystem.html
+parent:
+blurb: 
+labels:
+---
+# The XRPL Ecosystem
 
 The XRP Ledger is a layered ecosystem of software projects that power and enable the Internet of Value. It is impossible to list every project, tool, and business that interacts with the XRP Ledger. This page highlights some core projects.