🔗 Clarify learn-more link labels

JFWooten4 · codex · JFWooten4 · commit 9cd92bea459b · 2026-07-29T03:01:24.000-04:00
Co-authored-by: Codex &lt;noreply@openai.com&gt;
diff --git a/docs/build/apps/example-application-tutorial/anchor-integration/setup.mdx b/docs/build/apps/example-application-tutorial/anchor-integration/setup.mdx
@@ -3,7 +3,7 @@ title: "Setup for Anchored Assets"
 sidebar_position: 10
 ---
 
-An anchor is a Stellar-specific term for the on and off-ramps that connect the Stellar network to traditional financial rails, such as financial institutions or fintech companies. When a user deposits with an anchor, that anchor will credit their Stellar account with the equivalent amount of digital tokens. The user can then hold, transfer, or trade those tokens just like any other Stellar asset. When a user withdraws those tokens, the anchor redeems them for cash in hand or money in the bank. Learn more about anchors in this [anchor section](../../../../learn/fundamentals/anchors.mdx).
+An anchor is a Stellar-specific term for the on and off-ramps that connect the Stellar network to traditional financial rails, such as financial institutions or fintech companies. When a user deposits with an anchor, that anchor will credit their Stellar account with the equivalent amount of digital tokens. The user can then hold, transfer, or trade those tokens just like any other Stellar asset. When a user withdraws those tokens, the anchor redeems them for cash in hand or money in the bank. Learn more about anchors in the [Anchors section](../../../../learn/fundamentals/anchors.mdx).
 
 When a customer downloads a wallet application that is connected to an anchor service, their Stellar account can either be created by the wallet application or the anchor service. In this example, the account has been created by the wallet application, BasicPay. Account creation strategies are described more in-depth [here](../../application-design-considerations.mdx#account-creation-strategies).
 
diff --git a/docs/build/apps/example-application-tutorial/path-payment.mdx b/docs/build/apps/example-application-tutorial/path-payment.mdx
@@ -3,7 +3,7 @@ title: Path Payment
 sidebar_position: 50
 ---
 
-A path payment is where the asset sent can be different from the asset received. There are two possible path payment operations: 1) `path_payment_strict_send`, which allows the user to specify the amount of the asset to send, and 2) `path_payment_strict_receive`, which allows the user to specify the amount of the asset received. Learn more in the [Path Payments Guide](../../../build/guides/transactions/path-payments.mdx).
+A path payment is where the asset sent can be different from the asset received. There are two possible path payment operations: 1) `path_payment_strict_send`, which allows the user to specify the amount of the asset to send, and 2) `path_payment_strict_receive`, which allows the user to specify the amount of the asset received. Learn more in the [Path Payments guide](../../../build/guides/transactions/path-payments.mdx).
 
 ## User experience
 
diff --git a/docs/build/apps/wallet/component/kt/configClient.mdx b/docs/build/apps/wallet/component/kt/configClient.mdx
@@ -1,6 +1,6 @@
 ### Configuring the Client
 
-The Kotlin wallet SDK uses the [ktor client](https://ktor.io/docs/getting-started-ktor-client.html) for all network requests (excluding Horizon, where the Stellar SDK's HTTP client is used). Currently, the okhttp engine is configured to be used with the client. Learn more about how to configure the ktor client [here](https://ktor.io/docs/create-client.html#configure-client).
+The Kotlin wallet SDK uses the [ktor client](https://ktor.io/docs/getting-started-ktor-client.html) for all network requests (excluding Horizon, where the Stellar SDK's HTTP client is used). Currently, the okhttp engine is configured to be used with the client. Learn more in the [Ktor client configuration documentation](https://ktor.io/docs/create-client.html#configure-client).
 
 For example, the client can be globally configured:
 
diff --git a/docs/build/apps/wallet/component/ts/configClient.mdx b/docs/build/apps/wallet/component/ts/configClient.mdx
@@ -1,6 +1,6 @@
 ### Configuring the Client
 
-The Typescript wallet SDK uses the [axios client](https://axios-http.com/docs/intro) for all network requests. Learn more about how to configure the axios client [here](https://axios-http.com/docs/instance).
+The Typescript wallet SDK uses the [axios client](https://axios-http.com/docs/intro) for all network requests. Learn more in the [Axios instance documentation](https://axios-http.com/docs/instance).
 
 For example, we can configure our axios client to be globally configured with a timeout:
 
diff --git a/docs/build/apps/wallet/intro.mdx b/docs/build/apps/wallet/intro.mdx
@@ -123,7 +123,7 @@ Default configuration connects to the public Stellar Horizon instance. You can c
 
 :::
 
-Learn more about working with the Stellar network in the [respective section](./stellar.mdx).
+Learn more in the [Stellar Network section](./stellar.mdx).
 
 ## Anchor Basics
 
diff --git a/docs/build/apps/wallet/sep30.mdx b/docs/build/apps/wallet/sep30.mdx
@@ -176,7 +176,7 @@ let identity2 = [
 
 Here, stellar key and email are used as recovery methods. Other recovery servers may support phone as a recovery method as well.
 
-Learn more about SEP-30 identities [here](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md#common-request-fields)
+Learn more about SEP-30 identities in the [Common Request Fields section](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md#common-request-fields).
 
 Next, let's create a recoverable account:
 
@@ -233,7 +233,7 @@ let recoverableWallet = try await recovery.createRecoverableWallet(config: confi
 With the given parameters, this function will create a transaction that will:
 
 1. Set `deviceKp` as the primary account key. Please note that the master key belonging to `accountKp` will be locked. `deviceKp` should be used as a primary signer instead.
-2. Set all operation thresholds to 10. Learn more about threshold in the [documentation](../../../learn/fundamentals/transactions/signatures-multisig.mdx#thresholds)
+2. Set all operation thresholds to 10. Learn more about thresholds in the [Signatures and Multisig section](../../../learn/fundamentals/transactions/signatures-multisig.mdx#thresholds).
 3. Use identities that were defined earlier on both servers. (That means, both server will accept SEP-10 authentication via `recoveryKp` as an auth method)
 4. Set device key weight to 10, and recovery server weight to 5. Given these account thresholds, both servers must be used to recover the account, as transaction signed by one will only have weight of 5, which is not sufficient to change account key.
 
diff --git a/docs/build/guides/dapps/frontend-guide.mdx b/docs/build/guides/dapps/frontend-guide.mdx
@@ -377,7 +377,7 @@ Now that we have our basic UI components in place, let's integrate them with the
 - Test network: This is a test environment for developers to test their applications without using real lumens.
 - Futurenet network: This is a network for testing new features before they are deployed to the public network.
 
-For this guide, we'll be using the Test network to avoid using real lumens during development. Learn more about the [Stellar networks here](../../../networks/README.mdx).
+For this guide, we'll be using the Test network to avoid using real lumens during development. Learn more in the [Networks section](../../../networks/README.mdx).
 
 ### Setting up the Stellar SDK
 
diff --git a/docs/build/guides/transactions/claimable-balances.mdx b/docs/build/guides/transactions/claimable-balances.mdx
@@ -55,7 +55,7 @@ This operation claws back a claimable balance, returning the asset to the issuer
 
 Clawback claimable balances require the claimable balance ID.
 
-Learn more about clawbacks in our [Clawback guide](./clawbacks.mdx).
+Learn more about clawbacks in our [Clawbacks guide](./clawbacks.mdx).
 
 ## Example
 
diff --git a/docs/build/smart-contracts/overview.mdx b/docs/build/smart-contracts/overview.mdx
@@ -132,8 +132,8 @@ Learn more in the [Environment Concepts section](../../learn/fundamentals/contra
   To the greatest extent possible, we recommend issuing tokens as Stellar
   assets. These tokens will benefit from being interoperable with the existing
   tools available in the Stellar ecosystem and are more performant because the
-  Stellar Asset Contract is built into the host. Learn more in the [Tokens
-  Overview](../../tokens/README.mdx).
+  Stellar Asset Contract is built into the host. Learn more in the [Stellar
+  Assets and Contract Tokens section](../../tokens/README.mdx).
 </details>
 
 {/* prettier-ignore-end */}
diff --git a/docs/learn/fundamentals/contract-development/storage/state-archival.mdx b/docs/learn/fundamentals/contract-development/storage/state-archival.mdx
@@ -94,7 +94,7 @@ If you would like to extend the contract code or contract instance separately, y
 Here are some important points to keep in mind when it comes to archived entries -
 
 1. A Soroban transaction that has a key to an archived Persistent entry in the footprint, but not in the transaction's restore list, will fail immediately during the apply stage prior to contract execution. It does not matter if the contract itself was going to access the entry. (If the entry _is_ included in the restore list, it's [automatically restored](#contract-data-automatic-restoration) before the host function runs instead.)
-2. Due to the previous point that archived entries can never make it into smart contract logic, there is no reason to write code in your contract to handle archived entries. The same applies to contract test cases - while you may want to write tests that check if your extension logic is correct, you don't need to write archival tests because the transaction will fail before getting to the contract. It is possible though to access an archived entry in a Soroban test case, in which case the host will panic. Learn more about this in [Test TTL Extensions](../../../../build/guides/archival/test-ttl-extension.mdx).
+2. Due to the previous point that archived entries can never make it into smart contract logic, there is no reason to write code in your contract to handle archived entries. The same applies to contract test cases - while you may want to write tests that check if your extension logic is correct, you don't need to write archival tests because the transaction will fail before getting to the contract. It is possible though to access an archived entry in a Soroban test case, in which case the host will panic. Learn more about this in the [Test TTL extension guide](../../../../build/guides/archival/test-ttl-extension.mdx).
 3. Archived persistent entries can never be re-created. They must instead be restored. Once they are restored, then they can be modified or deleted.
 
 ## Terms and Semantics
diff --git a/docs/learn/fundamentals/lumens.mdx b/docs/learn/fundamentals/lumens.mdx
@@ -17,7 +17,7 @@ Stellar requires a small fee for all transactions to prevent ledger spam and pri
 
 To learn about fees on Stellar, see our [Fees section](./fees-resource-limits-metering.mdx).
 
-Smart contract transactions on Stellar employ a different fee structure based on an inclusion fee and resource consumption (which includes [rent](#rent)). Learn more in the [Fees and Metering section](./fees-resource-limits-metering.mdx).
+Smart contract transactions on Stellar employ a different fee structure based on an inclusion fee and resource consumption (which includes [rent](#rent)). Learn more in the [Fees, Resource Limits, and Metering section](./fees-resource-limits-metering.mdx).
 
 ## Base reserves
 
diff --git a/docs/learn/fundamentals/stellar-data-structures/assets.mdx b/docs/learn/fundamentals/stellar-data-structures/assets.mdx
@@ -21,7 +21,7 @@ Assets exist in two forms on Stellar:
 
 "Classic" assets issued by Stellar accounts (`G...` addresses) and their built-in Stellar Asset Contract (SAC) implementation, and contract tokens issued by a deployed Wasm contract (`C...` addresses).
 
-Learn more about the differences in the [Assets and Tokens section](../../../tokens/README.mdx).
+Learn more about the differences in the [Stellar Assets and Contract Tokens section](../../../tokens/README.mdx).
 
 :::
 
diff --git a/docs/learn/fundamentals/transactions/list-of-operations.mdx b/docs/learn/fundamentals/transactions/list-of-operations.mdx
@@ -551,7 +551,7 @@ Or
 
 Burns an amount in a specific asset from an account. Only the issuing account for the asset can perform this operation.
 
-Learn more about clawbacks in our [Clawback guide](../../../build/guides/transactions/clawbacks.mdx).
+Learn more about clawbacks in our [Clawbacks guide](../../../build/guides/transactions/clawbacks.mdx).
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.clawback) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ClawbackOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#Clawback)  
 **Threshold**: Medium  
@@ -577,7 +577,7 @@ Learn more about clawbacks in our [Clawback guide](../../../build/guides/transac
 
 Claws back an unclaimed ClaimableBalanceEntry, burning the pending amount of the asset. Only the issuing account for the asset can perform this operation.
 
-Learn more about clawbacks in our [Clawback guide](../../../build/guides/transactions/clawbacks.mdx).
+Learn more about clawbacks in our [Clawbacks guide](../../../build/guides/transactions/clawbacks.mdx).
 
 Learn more about claimable balances in our [Claimable Balances guide](../../../build/guides/transactions/claimable-balances.mdx).
 
diff --git a/docs/learn/fundamentals/transactions/operations-and-transactions.mdx b/docs/learn/fundamentals/transactions/operations-and-transactions.mdx
@@ -29,7 +29,7 @@ View a comprehensive list of Stellar operations and their threshold levels in th
 
 ### Transactions
 
-The Stellar network encodes transactions using a standardized protocol called External Data Representation (XDR). Learn more about this in our [XDR Section](../data-format/xdr.mdx).
+The Stellar network encodes transactions using a standardized protocol called External Data Representation (XDR). Learn more about this in our [XDR section](../data-format/xdr.mdx).
 
 Accounts can only perform one transaction at a time.
 
@@ -41,7 +41,7 @@ Transactions are atomic. Meaning if one operation in a transaction fails, all op
 
 Operations are executed for the source account of the transaction unless an operation override is defined.
 
-Smart contract transactions also go through a simulation process where developers can test how the transaction would be executed on the network using the RPC endpoint `simulateTransaction`. Learn more in the [Soroban docs](../../fundamentals/contract-development/contract-interactions/transaction-simulation.mdx).
+Smart contract transactions also go through a simulation process where developers can test how the transaction would be executed on the network using the RPC endpoint `simulateTransaction`. Learn more in the [Transaction Simulation section](../../fundamentals/contract-development/contract-interactions/transaction-simulation.mdx).
 
 ## Memo
 
diff --git a/docs/learn/glossary.mdx b/docs/learn/glossary.mdx
@@ -81,7 +81,7 @@ Learn more in our [Claimable Balances guide](../build/guides/transactions/claima
 
 An amount of asset from a trustline or claimable balance removed (clawed back) from a recipient’s balance sheet.
 
-Learn more in our [Clawback guide](../build/guides/transactions/clawbacks.mdx).
+Learn more in our [Clawbacks guide](../build/guides/transactions/clawbacks.mdx).
 
 ### Composable Data Platform {/* #cdp */}
 
@@ -117,7 +117,7 @@ Makes a payment to a 0-balance public key (Stellar address), thereby creating th
 
 A payment that automatically handles the conversion of dissimilar assets.
 
-Learn more in our [Path Payments section](../build/guides/transactions/path-payments.mdx).
+Learn more in our [Path Payments guide](../build/guides/transactions/path-payments.mdx).
 
 ### Custom Token
 
@@ -147,7 +147,7 @@ Flags control access to an asset on the account level. Learn more about flags in
 
 An automated test that rapidly stuffs massive amounts of randomized, malformed data into a system to reveal adverse or unexpected results that indicate vulnerabilities.
 
-Learn more in the [Fuzz Testing Tutorial](../build/smart-contracts/example-contracts/fuzzing.mdx).
+Learn more in the [Fuzz Testing tutorial](../build/smart-contracts/example-contracts/fuzzing.mdx).
 
 ### GitHub
 
diff --git a/docs/learn/migrate/evm/solidity-and-rust-advanced-concepts.mdx b/docs/learn/migrate/evm/solidity-and-rust-advanced-concepts.mdx
@@ -542,7 +542,7 @@ In contrast to Solidity's global variables, Soroban relies on passing an [`Env`]
 
 The `Env` provides access to information about the currently executing contract, who invoked it, contract data, functions for signing, hashing, etc.
 
-For instance, you would use `env.storage().persistent().get(key)` to access a `persistent` target value from the contract's [storage](https://docs.rs/soroban-sdk/latest/soroban_sdk/struct.Env.html). Learn more about the different storage types [here](../../fundamentals/contract-development/storage/persisting-data.mdx).
+For instance, you would use `env.storage().persistent().get(key)` to access a `persistent` target value from the contract's [storage](https://docs.rs/soroban-sdk/latest/soroban_sdk/struct.Env.html). Learn more about the different storage types in the [Persisting Data section](../../fundamentals/contract-development/storage/persisting-data.mdx).
 
 - `env.storage()` is used to get a struct for accessing and updating contract data that has been stored.
 - Used as `env.storage().persistent().get()` or `env.persistent().storage().set()`.
diff --git a/docs/networks/software-versions.mdx b/docs/networks/software-versions.mdx
@@ -225,7 +225,7 @@ New features in X-Ray, Protocol 25:
 
 ### Release notes
 
-Protocol 24 is a stability upgrade following Whisk (Protocol 23). Learn more about the upgrade here:
+Protocol 24 is a stability upgrade following Whisk (Protocol 23). Learn more about the upgrade:
 
 - [Release Notes](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0076.md)
 - [Stability Upgrade After Whisk](https://stellar.org/blog/developers/addressing-state-archival-inconsistencies-protocol-upgrade-vote-next-week)
@@ -258,7 +258,7 @@ Protocol 24 is a stability upgrade following Whisk (Protocol 23). Learn more abo
 
 ### Release notes
 
-Protocol 24 is a stability upgrade following Whisk (Protocol 23). Learn more about the upgrade here:
+Protocol 24 is a stability upgrade following Whisk (Protocol 23). Learn more about the upgrade:
 
 - [Stability Upgrade After Whisk](https://stellar.org/blog/developers/addressing-state-archival-inconsistencies-protocol-upgrade-vote-next-week)
 
diff --git a/docs/platforms/anchor-platform/CONTRIBUTING.md b/docs/platforms/anchor-platform/CONTRIBUTING.md
@@ -185,7 +185,7 @@ This should help to make it a bit clearer.
 > `/platforms/stellar-disbursement-platform` plugin instance in the above
 > examples, and it all works pretty much identically.
 
-Learn more about links [here](https://docusaurus.io/docs/markdown-features/links)
+Learn more in the [Docusaurus links documentation](https://docusaurus.io/docs/markdown-features/links)
 (especially toward the bottom of the page).
 
 ## Directories to Know
diff --git a/docs/platforms/anchor-platform/api-reference/platform/rpc/overview.mdx b/docs/platforms/anchor-platform/api-reference/platform/rpc/overview.mdx
@@ -13,4 +13,4 @@ All member names exchanged between the Client and the Server that are considered
 
 :::
 
-Learn more about JSON-RPC protocol [here](https://www.jsonrpc.org/specification).
+Learn more in the [JSON-RPC specification](https://www.jsonrpc.org/specification).
diff --git a/docs/tokens/control-asset-access.mdx b/docs/tokens/control-asset-access.mdx
@@ -74,7 +74,7 @@ There are three levels of authorization an asset issuer can remove using the `Se
 
 #### Clawback Enabled (0x8)
 
-With the `AUTH_CLAWBACK_ENABLED_FLAG` flag set, any _subsequent_ trustlines established with this account will have clawbacks enabled. Learn more about clawbacks (and selectively controlling them on a per-trustline basis) [here](../build/guides/transactions/clawbacks.mdx).
+With the `AUTH_CLAWBACK_ENABLED_FLAG` flag set, any _subsequent_ trustlines established with this account will have clawbacks enabled. Learn more about clawbacks (and selectively controlling them per-trustline basis) in the [Clawbacks guide](../build/guides/transactions/clawbacks.mdx).
 
 Note that this flag requires that revocable is also set.
 
diff --git a/docs/tokens/how-to-issue-an-asset.mdx b/docs/tokens/how-to-issue-an-asset.mdx
@@ -19,7 +19,7 @@ If you'd like to interact with an asset issued on the Stellar network in smart c
 
 You must ensure you have the required amount of XLM to create your issuing and distribution accounts and cover the minimum balance and transaction fees. If you’re issuing an asset on the testnet, you can fund your account by getting test XLM from friendbot. If you’re issuing an asset in production, you will need to acquire XLM from another wallet or exchange.
 
-If you’d like to avoid your users having to deal with transaction fees, consider using fee-bump transactions. Learn more in our [Fee-Bump Transaction Guide](../build/guides/transactions/fee-bump-transactions.mdx).
+If you’d like to avoid your users having to deal with transaction fees, consider using fee-bump transactions. Learn more in our [Fee-Bump Transaction guide](../build/guides/transactions/fee-bump-transactions.mdx).
 
 Learn about the testnet and mainnet in our [Networks section](../networks/README.mdx).
 
diff --git a/docs/tokens/stellar-asset-contract.mdx b/docs/tokens/stellar-asset-contract.mdx
diff --git a/docs/tokens/token-interface.mdx b/docs/tokens/token-interface.mdx
