Update links after renaming accounts.md to index.md

docs/concepts/accounts/account-types.md

@@ -71,7 +71,7 @@ If a standby address is compromised, the consequences are like an operational ad
 ## See Also
 
 - **Concepts:**
-    - [Accounts](accounts.md)
+    - [Accounts](index.md)
     - [Cryptographic Keys](cryptographic-keys.md)
 - **Tutorials:**
     - [Assign a Regular Key Pair](../../tutorials/tasks/manage-account-settings/assign-a-regular-key-pair.md)

docs/concepts/accounts/addresses.md

@@ -10,7 +10,7 @@ labels:
 
 {% partial file="/docs/_snippets/data_types/address.md" /%}
 
-Any valid address can [become an account in the XRP Ledger](accounts.md#creating-accounts) by being funded. You can also use an address that has not been funded to represent a [regular key](cryptographic-keys.md) or a member of a [signer list](multi-signing.md). Only a funded account can be the sender of a transaction.
+Any valid address can [become an account in the XRP Ledger](index.md#creating-accounts) by being funded. You can also use an address that has not been funded to represent a [regular key](cryptographic-keys.md) or a member of a [signer list](multi-signing.md). Only a funded account can be the sender of a transaction.
 
 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.)
 

docs/concepts/accounts/cryptographic-keys.md

@@ -62,14 +62,14 @@ Transactions in the XRP Ledger must include the public keys so that the network
 
 ### Account ID and Address
 
-The **Account ID** is the core identifier for an [account](accounts.md) or a key pair. It is derived from the public key. In the XRP Ledger protocol, the Account ID is 20 bytes of binary data. Most XRP Ledger APIs represent the Account ID as an address, in one of two formats:
+The **Account ID** is the core identifier for an [account](index.md) or a key pair. It is derived from the public key. In the XRP Ledger protocol, the Account ID is 20 bytes of binary data. Most XRP Ledger APIs represent the Account ID as an address, in one of two formats:
 
 - A "classic address" writes an Account ID in [base58][] with a checksum. In a [wallet_propose method][] response, this is the `account_id` value.
 - An "X-Address" combines an Account ID _and_ a [Destination Tag](../transactions/source-and-destination-tags.md) and writes the combined value in [base58][] with a checksum.
 
 The checksum in both formats is there so that small changes result in an invalid address, instead of changing it to refer to a different, but still potentially valid, account. This way, if you make a typo or a transmission error occurs, you don't send money to the wrong place.
 
-It is important to know that not all Account IDs (or addresses) refer to accounts in the ledger. Deriving keys and addresses is purely a mathematical operation. For an account to have a record in the XRP Ledger, it must [receive a payment of XRP](accounts.md#creating-accounts) that funds its [reserve requirement](reserves.md). An account cannot send any transactions until after it has been funded.
+It is important to know that not all Account IDs (or addresses) refer to accounts in the ledger. Deriving keys and addresses is purely a mathematical operation. For an account to have a record in the XRP Ledger, it must [receive a payment of XRP](index.md#creating-accounts) that funds its [reserve requirement](reserves.md). An account cannot send any transactions until after it has been funded.
 
 Even if an Account ID or address does not refer to a funded account, you _can_ use that Account ID or address to represent a [regular key pair](#regular-key-pair) or a [member of a signer list](multi-signing.md).
 

docs/concepts/accounts/deleting-accounts.md

@@ -12,7 +12,7 @@ The owner of an account can send an [AccountDelete transaction][] to deletes the
 
 Some types of associated ledger entries block an account from being deleted. For example, the issuer of a fungible token can't be deleted while anyone holds a nonzero balance of that token.
 
-After an account has been deleted, it can be re-created in the ledger through the normal method of [creating accounts](accounts.md#creating-accounts). An account that has been deleted and re-created is no different than an account that has been created for the first time.
+After an account has been deleted, it can be re-created in the ledger through the normal method of [creating accounts](index.md#creating-accounts). An account that has been deleted and re-created is no different than an account that has been created for the first time.
 
 ## Requirements
 

docs/concepts/accounts/depositauth.md

@@ -11,7 +11,7 @@ labels:
 
 _(Added by the [DepositAuth amendment][].)_
 
-Deposit Authorization is an optional [account](accounts.md) setting in the XRP Ledger. If enabled, Deposit Authorization blocks all transfers from strangers, including transfers of XRP and [tokens](../tokens/index.md). An account with Deposit Authorization can only receive value in two ways:
+Deposit Authorization is an optional [account](index.md) setting in the XRP Ledger. If enabled, Deposit Authorization blocks all transfers from strangers, including transfers of XRP and [tokens](../tokens/index.md). An account with Deposit Authorization can only receive value in two ways:
 
 - From accounts it has [preauthorized](#preauthorization).
 - By sending a transaction to receive the funds. For example, an account with Deposit Authorization could finish an [Escrow](../payment-types/escrow.md) that was initiated by a stranger.

docs/concepts/consensus-protocol/consensus-structure.md

@@ -19,7 +19,7 @@ When building applications on the XRP Ledger, it is important to understand this
 
 The peer-to-peer XRP Ledger network provides a worldwide, shared ledger, which gives applications authoritative information about the state of its contents. This state information includes:
 
-- settings for each [account](../accounts/accounts.md)
+- settings for each [account](../accounts/index.md)
 - balances of XRP and [tokens](../tokens/index.md)
 - offers in the distributed exchange
 - network settings, such as [transaction costs](../transactions/transaction-cost.md) and [reserve](../accounts/reserves.md) amounts

docs/concepts/consensus-protocol/invariant-checking.md

@@ -90,7 +90,7 @@ The XRP Ledger checks all the following invariants on each transaction:
 ### Account Roots Not Deleted
 
 - **Invariant Condition(s):**
-    - An [account](../accounts/accounts.md) cannot be deleted from the ledger except by an [AccountDelete transaction][].
+    - An [account](../accounts/index.md) cannot be deleted from the ledger except by an [AccountDelete transaction][].
     - A successful AccountDelete transaction always deletes exactly 1 account.
 
 
@@ -129,7 +129,7 @@ The XRP Ledger checks all the following invariants on each transaction:
 - **Invariant Condition(s):**
     - A new [account root](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md) must be the consequence of a payment.
     - A new account root must have the right starting [sequence](../../references/protocol/data-types/basic-data-types.md#account-sequence).
-    - A transaction must not create more than one new [account](../accounts/accounts.md).
+    - A transaction must not create more than one new [account](../accounts/index.md).
 
 ### ValidNFTokenPage
 

docs/concepts/tokens/decentralized-exchange/index.md

@@ -53,7 +53,7 @@ Because trades are only executed each time a new ledger closes (approximately ev
 
 The XRP Ledger does not natively represent concepts such as market orders, stop orders, or trading on leverage. Some of these may be possible with creative use of custom tokens and Offer properties.
 
-As a decentralized system, the XRP Ledger does not have any information on the actual people and organizations behind the [accounts](../../accounts/accounts.md) involved in trading. The ledger itself cannot implement restrictions around who can or cannot participate in trading, and users and issuers must take care to follow any relevant laws to regulate trading tokens that represent various types of underlying assets. Features such as [freezes](../fungible-tokens/freezes.md) and [authorized trust lines](../fungible-tokens/authorized-trust-lines.md) are intended to help issuers comply with relevant laws and regulations.
+As a decentralized system, the XRP Ledger does not have any information on the actual people and organizations behind the [accounts](../../accounts/index.md) involved in trading. The ledger itself cannot implement restrictions around who can or cannot participate in trading, and users and issuers must take care to follow any relevant laws to regulate trading tokens that represent various types of underlying assets. Features such as [freezes](../fungible-tokens/freezes.md) and [authorized trust lines](../fungible-tokens/authorized-trust-lines.md) are intended to help issuers comply with relevant laws and regulations.
 
 ## See Also
 

docs/concepts/tokens/fungible-tokens/index.md

@@ -18,7 +18,7 @@ Trust lines are structures in the XRP Ledger for holding fungible [tokens](../in
 
 Each "trust line" is a _bidirectional_ relationship consisting of:
 
-- The identifiers for the two [accounts](../../accounts/accounts.md) that the trust line connects.
+- The identifiers for the two [accounts](../../accounts/index.md) that the trust line connects.
 - A single, shared balance, which is positive from the perspective of one account and negative from the other perspective.
     - The account with a negative balance is generally considered the "issuer" of the tokens. However, in the [APIs](../../../references/http-websocket-apis/index.md), the name `issuer` can refer to either side.
 - Various settings and metadata. _Each_ of the two accounts can control its own settings on the trust line.

docs/concepts/tokens/nfts/guaranteeing-a-fixed-supply.md

@@ -12,7 +12,7 @@ For some projects, you might want to guarantee that no more than a fixed number
 
 To guarantee a fixed number of NFTs:
 
-1. Create and fund a new account, the _Issuer_. This account is the issuer of the tokens within the collection. See [Creating Accounts](../../accounts/accounts.md#creating-accounts).
+1. Create and fund a new account, the _Issuer_. This account is the issuer of the tokens within the collection. See [Creating Accounts](../../accounts/index.md#creating-accounts).
 1. Use `AccountSet` to assign your operational wallet as an authorized minter for the issuer. See [Authorizing Another Account to Mint Your NFTs](authorizing-another-minter.md).
 1. Use your operational account to mint the tokens using `NFTokenMint`. The operational wallet holds all of the tokens minted for the Issuer. See [Batch Minting](batch-minting.md).
 1.  Use `AccountSet` to remove your operational wallet as an authorized minter for the Issuer.

docs/concepts/transactions/finality-of-results/look-up-transaction-results.md

@@ -63,7 +63,7 @@ The following example shows a successful transaction, as returned by the [tx met
 }
 ```
 
-This example shows an [AccountSet transaction][] sent by the [account](../../accounts/accounts.md) with address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`, using [Sequence number][] 376. The transaction's [identifying hash][] is `017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567` and its [result](../../../references/protocol/transactions/transaction-results/transaction-results.md) is `tesSUCCESS`. The transaction was included in ledger version 46447423, which has been validated, so these results are final.
+This example shows an [AccountSet transaction][] sent by the [account](../../accounts/index.md) with address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`, using [Sequence number][] 376. The transaction's [identifying hash][] is `017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567` and its [result](../../../references/protocol/transactions/transaction-results/transaction-results.md) is `tesSUCCESS`. The transaction was included in ledger version 46447423, which has been validated, so these results are final.
 
 
 ### Case: Not Included in a Validated Ledger
@@ -223,7 +223,7 @@ XRP amounts are tracked in the `Balance` field of `AccountRoot` objects. (XRP ca
 
 You should always use [the `delivered_amount` field](../../payment-types/partial-payments.md#the-delivered_amount-field) to see how much a payment delivered.
 
-If the payment contains a `CreatedNode` with `"LedgerEntryType": "AccountRoot"`, that means the payment [funded a new account](../../accounts/accounts.md#creating-accounts) in the ledger.
+If the payment contains a `CreatedNode` with `"LedgerEntryType": "AccountRoot"`, that means the payment [funded a new account](../../accounts/index.md#creating-accounts) in the ledger.
 
 #### Token Payments
 

docs/concepts/transactions/source-and-destination-tags.md

@@ -22,7 +22,7 @@ The practice of giving customers the ability to send and receive transactions fr
 
 ## Rationale
 
-In other distributed ledgers, it is common to use different deposit addresses for each customer. In the XRP Ledger, an address must be a funded, permanent [account](../accounts/accounts.md) to receive payments. Using this approach in the XRP Ledger wastefully consumes resources of all servers in the network, and is costly because the [reserve](../accounts/reserves.md) amount must be set aside indefinitely for each address.
+In other distributed ledgers, it is common to use different deposit addresses for each customer. In the XRP Ledger, an address must be a funded, permanent [account](../accounts/index.md) to receive payments. Using this approach in the XRP Ledger wastefully consumes resources of all servers in the network, and is costly because the [reserve](../accounts/reserves.md) amount must be set aside indefinitely for each address.
 
 Source and destination tags provide a more lightweight way to map deposits and payments to individual customers.