Apply suggestions from @tequdev review

Co-authored-by: tequ <git@tequ.dev>

Author: mDuo13

docs/concepts/decentralized-storage/credentials.md

@@ -1,6 +1,6 @@
 # Credentials
 
-The Credentials feature is a set of tools for managing authorization and compliance requirements using the XRP Ledger blockchain, while respecting privacy and decentralization. This feature extends and interconnects with other features of the XRP Ledger including [Deposit Authorization](https://xrpl.org/docs/concepts/accounts/depositauth). The goal of this feature is to streamline the process of compliance checks such as [KYC (Know Your Customer)](https://en.wikipedia.org/wiki/Know_your_customer) and to enable further trust-based applications within the XRP Ledger ecosystem.
+The Credentials feature is a set of tools for managing authorization and compliance requirements using the XRP Ledger blockchain, while respecting privacy and decentralization. This feature extends and interconnects with other features of the XRP Ledger including [Deposit Authorization](../../concepts/accounts/depositauth.md)). The goal of this feature is to streamline the process of compliance checks such as [KYC (Know Your Customer)](https://en.wikipedia.org/wiki/Know_your_customer) and to enable further trust-based applications within the XRP Ledger ecosystem.
 
 The design of the Credentials standard draws from the [W3C Verifiable Credentials standard](https://www.w3.org/TR/vc-data-model-2.0/). It is intended to be compatible to an extent that makes sense in the context of the XRP Ledger. There are some differences in data structures and formatting: for example, the subject of a credential is identified by an XRP Ledger address rather than a URL.
 

docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_entry.md

@@ -112,7 +112,7 @@ You can use this type of request to get any singleton ledger entry, if it exists
 
 
 ### Get AccountRoot Entry
-<a id="get-accountroot-entry"></a><!-- legacy ID -->
+<a id="get-accountroot-object"></a><!-- legacy ID -->
 
 Retrieve an [AccountRoot entry](../../../protocol/ledger-data/ledger-entry-types/accountroot.md) by its address. This is roughly equivalent to the [account_info method][].
 
@@ -160,7 +160,7 @@ rippled json ledger_entry '{ "account_root": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59
 
 
 ### Get AMM Entry
-<a id="get-amm-entry"></a><!-- legacy ID -->
+<a id="get-amm-object"></a><!-- legacy ID -->
 
 _(Added by the [AMM amendment][])_
 

docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized.md

@@ -8,7 +8,7 @@ labels:
 # deposit_authorized
 [[Source]](https://github.com/XRPLF/rippled/blob/817d2339b8632cb2f97d3edd6f7af33aa7631744/src/ripple/rpc/handlers/DepositAuthorized.cpp "Source")
 
-The `deposit_authorized` command indicates whether one account is authorized to send payments directly to another. See [Deposit Authorization](https://xrpl.org/docs/concepts/accounts/depositauth/) for information on how to require authorization to deliver money to your account.
+The `deposit_authorized` command indicates whether one account is authorized to send payments directly to another. See [Deposit Authorization](../../../../concepts/accounts/depositauth.md) for information on how to require authorization to deliver money to your account.
 
 ## Request Format
 An example of the request format:
@@ -65,7 +65,7 @@ The request includes the following parameters:
 |:----------------------|:---------------------|:----------|-------------|
 | `source_account`      | String - [Address][] | Yes       | The sender of a possible payment. |
 | `destination_account` | String - [Address][] | Yes       | The recipient of a possible payment. |
-| `ledger_hash`         | [Hash][]             | No        | A 20-byte hex string for the ledger version to use. (See [Specifying Ledgers][]) |
+| `ledger_hash`         | [Hash][]             | No        | A 32-byte hex string for the ledger version to use. (See [Specifying Ledgers][]) |
 | `ledger_index`        | [Ledger Index][]     | No        | The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
 | `credentials`         | Array                | No        | A set of credentials to take into account when checking if the sender can send funds to the destination. Each member of the array must be the unique ID of a [Credential entry][] in the ledger. Cannot be an empty array. |
 
@@ -150,7 +150,7 @@ The response follows the [standard format][], with a successful result containin
 | Field                  | Type                      | Required? | Description   |
 |:-----------------------|:--------------------------|:----------|:--------------|
 | `credentials`          | Array of [Hash][]         | No        | The credentials specified in the request, if any. |
-| `deposit_authorized`   | Boolean                   | Yes       | Whether the specified source account is authorized to send payments directly to the destination account. If `true`, either the destination account does not require [deposit authorization](https://xrpl.org/docs/concepts/accounts/depositauth) or the source account is preauthorized. |
+| `deposit_authorized`   | Boolean                   | Yes       | Whether the specified source account is authorized to send payments directly to the destination account. If `true`, either the destination account does not require [deposit authorization](../../../../concepts/accounts/depositauth.md) or the source account is preauthorized. |
 | `destination_account`  | String - [Address][]      | Yes       | The destination account specified in the request. |
 | `ledger_hash`          | String                    | No        | The identifying hash of the ledger that was used to generate this response. |
 | `ledger_index`         | Number - [Ledger Index][] | No        | The ledger index of the ledger version that was used to generate this response. |
@@ -159,7 +159,7 @@ The response follows the [standard format][], with a successful result containin
 | `validated`            | Boolean                   | No        | If `true`, the information comes from a validated ledger version. |
 
 {% admonition type="info" name="Note" %}
-A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](https://xrpl.org/docs/concepts/tokens/fungible-tokens) for the specified currency, or there may not be enough liquidity to deliver a payment.
+A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](../../../../concepts/tokens/fungible-tokens/index.md) for the specified currency, or there may not be enough liquidity to deliver a payment.
 {% /admonition %}
 
 ## Possible Errors

docs/references/protocol/ledger-data/ledger-entry-types/credential.md

@@ -4,7 +4,7 @@ seo:
 ---
 # Credential
 
-A `Credential` entry represents a [credential](../index.md), which contains an attestation about a _subject_ account from a _credential issuer_ account. The meaning of the attestation is defined by the issuer.
+A `Credential` entry represents a [credential](../../../../concepts/decentralized-storage/credentials.md), which contains an attestation about a _subject_ account from a _credential issuer_ account. The meaning of the attestation is defined by the issuer.
 
 ## Example Credential JSON
 

docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth.md

@@ -9,7 +9,7 @@ labels:
 # DepositPreauth
 [[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L172-L178 "Source")
 
-A `DepositPreauth` entry tracks a preauthorization from one account. You can always create a preauthorization by sending a [DepositPreauth transaction][], but it has no effect unless you are using [Deposit Authorization](https://xrpl.org/docs/concepts/accounts/depositauth).
+A `DepositPreauth` entry tracks a preauthorization from one account. You can always create a preauthorization by sending a [DepositPreauth transaction][], but it has no effect unless you are using [Deposit Authorization](../../../../concepts/accounts/depositauth.md).
 
 A preauthorization allows specific others to send money directly to you even if you have Deposit Authorization enabled. Preauthorizations are one-directional, and have no effect on payments going the opposite direction.
 

docs/references/protocol/transactions/types/credentialaccept.md

@@ -2,7 +2,7 @@
 seo:
     description: Accept a credential provisionally issued to your account.
 ---
-# CredentialAccept Transaction
+# CredentialAccept
 
 A CredentialAccept transaction accepts a credential, which makes the credential valid. Only the subject of the credential can do this.
 
@@ -42,7 +42,7 @@ The combination of `Account`, `Issuer`, and `CredentialType` must match a `Crede
 | `tecEXPIRED` | The specified credential has an expiration time in the past. (In this case, the transaction also deletes the expired credentials from the ledger.) |
 | `tecNO_ENTRY` | The credential uniquely identified by the `Account`, `Issuer`, and `CredentialType` fields of the transaction does not exist in the ledger. |
 | `temDISABLED` | The related amendment is not enabled. |
-| `temINVALID_ACCOUNT_ID` | The provided `Issuer` field is invalid. For example, it contains [ACCOUNT_ZERO][]. |
+| `temINVALID_ACCOUNT_ID` | The provided `Issuer` field is invalid. For example, it contains [ACCOUNT_ZERO](../../../../concepts/accounts/addresses.md#special-addresses). |
 
 
 {% raw-partial file="/docs/_snippets/common-links.md" /%}

docs/references/protocol/transactions/types/credentialcreate.md

@@ -3,7 +3,7 @@ seo:
     description: Provisionally issue a credential to a subject account.
 ---
 
-# CredentialCreate Transaction
+# CredentialCreate
 
 A CredentialCreate transaction creates a credential in the ledger. The issuer of the credential uses this transaction to provisionally issue a credential. The credential is not valid until the subject of the credential accepts it with a [CredentialAccept transaction][].
 
@@ -37,15 +37,15 @@ The `Account` field (the sender) of the transaction is the issuer of the credent
 
 ## Error Cases
 
-Besides errors that can occur for all transactions, CredentialCreate transactions can result in the following [transaction result codes][]:
+Besides errors that can occur for all transactions, CredentialCreate transactions can result in the following [transaction result codes](../transaction-results/index.md):
 
 | Error Code | Description |
 |:-----------|:------------|
 | `tecDUPLICATE` | A credential with the same subject, issuer, and credential type already exists in the ledger. |
 | `tecEXPIRED` | The credential's expiration time is in the past. |
 | `tecNO_TARGET` | The account specified in the `Subject` field is not a funded account in the ledger. |
 | `temDISABLED` | The related amendment is not enabled. |
-| `temINVALID_ACCOUNT_ID` | The provided `Subject` field is invalid. For example, it contains [ACCOUNT_ZERO][]. |
+| `temINVALID_ACCOUNT_ID` | The provided `Subject` field is invalid. For example, it contains [ACCOUNT_ZERO](../../../../concepts/accounts/addresses.md#special-addresses). |
 
 
 {% raw-partial file="/docs/_snippets/common-links.md" /%}

docs/references/protocol/transactions/types/credentialdelete.md

@@ -2,9 +2,9 @@
 seo:
     description: Remove a credential from the ledger, effectively revoking it.
 ---
-# CredentialDelete Transaction
+# CredentialDelete
 
-A CredentialDelete transaction removes a credential from the ledger, effectively revoking it. Users may also want to delete an unwanted credential to reduce their [reserve requirement][].
+A CredentialDelete transaction removes a credential from the ledger, effectively revoking it. Users may also want to delete an unwanted credential to reduce their [reserve requirement](../../../../concepts/accounts/reserves.md).
 
 ## Example CredentialDelete JSON
 
@@ -41,7 +41,7 @@ This transaction looks for a [Credential ledger entry](../../ledger-data/ledger-
 | Error Code | Description |
 |:-----------|:------------|
 | `temDISABLED` | The related amendment is not enabled. |
-| `temINVALID_ACCOUNT_ID` | A provided `Subject` or `Issuer` field is invalid. For example, it contains [ACCOUNT_ZERO][]. |
+| `temINVALID_ACCOUNT_ID` | A provided `Subject` or `Issuer` field is invalid. For example, it contains [ACCOUNT_ZERO](../../../../concepts/accounts/addresses.md#special-addresses). |
 | `tecNO_PERMISSION` | The sender is neither the issuer nor subject of the credential, and the credential is not expired. |
 | `tecNO_ENTRY` | The specified credential does not exist in the ledger. |
 

docs/references/protocol/transactions/types/depositpreauth.md

@@ -83,7 +83,7 @@ In addition to error types that can occur for all transactions, DepositPreauth t
 | Error Code                | Description |
 |:--------------------------|:------------|
 | `tecDUPLICATE`            | The transaction would create a preauthorization that already exists. |
-| `tecINSUFFICIENT_RESERVE` | The sender would not meet the [reserve requirement][] after adding another entry to the ledger. (A DepositPreauth entry counts as one item towards the authorizer's owner reserve.) |
+| `tecINSUFFICIENT_RESERVE` | The sender would not meet the [reserve requirement](../../../../concepts/accounts/reserves.md) after adding another entry to the ledger. (A DepositPreauth entry counts as one item towards the authorizer's owner reserve.) |
 | `tecNO_ENTRY`             | The transaction tried to revoke a preauthorization that does not exist in the ledger. |
 | `tecNO_ISSUER`            | One or more specified credential issuers does not exist in the ledger. |
 | `tecNO_TARGET`            | The transaction tried to authorize an account that is not a funded account in the ledger. |