📝 Diction introducing/discussing cross-reference materials

docs/build/agentic-payments/mpp/README.mdx

@@ -37,19 +37,19 @@ Two credential modes are available:
 - **Pull** (default) — The client prepares and signs the Soroban authorization entries; the server broadcasts the transaction. Supports an optional sponsored path where the server rebuilds the transaction with its own account as source, so the client never pays network fees.
 - **Push** — The client broadcasts the transaction itself and sends a `signedHash` credential for server verification — the transaction hash plus a signature proving the client controls the paying (`from`) account.
 
-See the [MPP Charge Guide](./charge-guide.mdx) to get started.
+Learn more in the [MPP Charge Guide](./charge-guide.mdx) to get started.
 
 ### Session
 
 The session intent enables high-frequency, pay-as-you-go payments over unidirectional [payment channels](https://github.com/stellar-experimental/one-way-channel). The funder deposits tokens into the channel once, then makes many off-chain payments by signing cumulative commitments — no per-payment on-chain transactions, ideal for AI agent interactions. The server settles by closing the channel when convenient.
 
-See the [MPP Session Guide](./channel-guide.mdx) to get started.
+Learn more in the [MPP Session Guide](./channel-guide.mdx) to get started.
 
 ## Demo
 
 Try the live demo at [mpp.stellar.buzz](https://mpp.stellar.buzz), or run the [MPP Demo](https://github.com/stellar/stellar-mpp-sdk/tree/main/demo) locally. It runs a Node.js server that charges 0.01 USDC per request and a minimal browser UI for testing end-to-end payment flows on Stellar Testnet.
 
-To build an MPP-enabled service or integrate payments into your app, see [Build Applications](../../apps/README.mdx) and the resources below.
+To build an MPP-enabled service or integrate payments into your app, start with [Build Applications](../../apps/README.mdx) and the resources below.
 
 ## Install
 

docs/build/agentic-payments/mpp/channel-guide.mdx

@@ -98,7 +98,7 @@ Before using channel mode, you need a deployed [one-way-channel contract](https:
 - A **commitment key** — an ed25519 keypair. The client signs commitments with the private key; the contract verifies with the public key.
 - A **token deposit** — the funder's initial balance in the channel asset. This example uses USDC.
 
-See the [one-way-channel repo](https://github.com/stellar-experimental/one-way-channel) for deployment instructions.
+Learn more in the [one-way-channel repo](https://github.com/stellar-experimental/one-way-channel) for deployment instructions.
 
 ## Session server
 

docs/build/agentic-payments/mpp/charge-guide.mdx

@@ -154,7 +154,7 @@ app.listen(PORT, () => {
 });
 ```
 
-Set `STELLAR_RECIPIENT` to the Stellar public key (`G...`) for the account that should receive USDC payments. Your account will need a testnet USDC trustline — see [Setting up a testnet wallet](#setting-up-a-testnet-wallet) below.
+Set `STELLAR_RECIPIENT` to the Stellar public key (`G...`) for the account that should receive USDC payments. Your account will need a testnet USDC trustline. Learn more in [Setting up a testnet wallet](#setting-up-a-testnet-wallet) below.
 
 Start the API locally:
 
@@ -440,7 +440,7 @@ When `feePayer` is configured, the server automatically signals fee sponsorship
 
 :::info[Channel open removal]
 
-The channel `open` MPP action was removed in v0.7 as it was dead code — the Soroban contract has no on-chain open entrypoint. Channels are created on-chain directly by signing and broadcasting a deploy transaction. See the [MPP Session Guide](./channel-guide.mdx) for channel setup details.
+The channel `open` MPP action was removed in v0.7 as it was dead code — the Soroban contract has no on-chain open entrypoint. Channels are created on-chain directly by signing and broadcasting a deploy transaction. Learn more in the [MPP Session Guide](./channel-guide.mdx) for channel setup details.
 
 :::
 

docs/build/agentic-payments/x402/README.mdx

@@ -11,7 +11,7 @@ keywords:
 
 x402 is an open protocol from the Coinbase Developer Platform that enables programmatic, per request payments over HTTP, designed especially for AI agents and APIs. It effectively turns the old “402 Payment Required” HTTP status code into something usable, for both humans and AI agents.
 
-On Stellar, x402 works with Soroban authorization so that clients can pay for API requests via signed auth entries, ideal for micropayments and payment enabled apps. To build an x402-enabled service or integrate payments into your app, see [Build Applications](../../apps/README.mdx) and the resources below.
+On Stellar, x402 works with Soroban authorization so that clients can pay for API requests via signed auth entries, ideal for micropayments and payment enabled apps. To build an x402-enabled service or integrate payments into your app, start with [Build Applications](../../apps/README.mdx) and the resources below.
 
 ## Demo
 

docs/build/agentic-payments/x402/built-on-stellar.mdx

@@ -176,7 +176,7 @@ This approach provides several benefits:
 
 ## Self-hosting
 
-If you want to run your own instance of the facilitator instead of using the hosted service, you can deploy the OpenZeppelin Relayer with the x402 Facilitator Plugin directly. See the [OpenZeppelin x402 Facilitator guide][oz-facilitator-guide] and the [plugin source code][oz-plugin] for setup instructions.
+If you want to run your own instance of the facilitator instead of using the hosted service, you can deploy the OpenZeppelin Relayer with the x402 Facilitator Plugin directly. Learn more in the [OpenZeppelin x402 Facilitator guide][oz-facilitator-guide] and the [plugin source code][oz-plugin] for setup instructions.
 
 ## Resources
 

docs/build/apps/example-application-tutorial/account-creation.mdx

@@ -3,7 +3,7 @@ title: Account Creation
 sidebar_position: 20
 ---
 
-Accounts are the central data structure in Stellar and can only exist with a valid keypair (a public and secret key) and the required minimum balance of XLM. Read more in the [Accounts section].
+Accounts are the central data structure in Stellar and can only exist with a valid keypair (a public and secret key) and the required minimum balance of XLM. Learn more in the [Accounts section].
 
 ## User experience
 

docs/build/apps/example-application-tutorial/anchor-integration/setup.mdx

@@ -3,15 +3,15 @@ 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. Read 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).
 
 In this example, we’ll use an anchor on Stellar’s Testnet to simulate a bank transfer into and out of the user’s wallet using [SEP-6: Deposit and Withdrawal API](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md) and/or [SEP-24: Hosted Deposit and Withdrawal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md).
 
 :::info
 
-SEPs define community-decided standards for interoperability on Stellar. Read more in our [SEPs section](../../../../learn/fundamentals/stellar-ecosystem-proposals.mdx).
+SEPs define community-decided standards for interoperability on Stellar. Learn more in our [SEPs section](../../../../learn/fundamentals/stellar-ecosystem-proposals.mdx).
 
 :::
 

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. Read 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
 

docs/build/apps/example-application-tutorial/payment.mdx

@@ -13,7 +13,7 @@ In our BasicPay application, the user will navigate to the Payments page where c
 
 The user clicks the "Confirm Transaction" button. If the destination account exists and is properly funded with XLM, this will trigger a Transaction Preview where they can view the transaction details.
 
-All Stellar transactions require a small fee to make it to the ledger. Read more in our [Fees section](../../../learn/fundamentals/fees-resource-limits-metering.mdx).
+All Stellar transactions require a small fee to make it to the ledger. Learn more in our [Fees section](../../../learn/fundamentals/fees-resource-limits-metering.mdx).
 
 In BasicPay, we’ve set it up so that the user always pays a static fee of 100,000 [stroops](../../../learn/fundamentals/stellar-data-structures/assets.mdx#amount-precision) (one stroop equals 0.0000001 XLM) per operation. Alternatively, you can add a feature to your application that allows the user to set their own fee.
 

docs/build/apps/guestbook/bindings.mdx

@@ -104,7 +104,7 @@ That was a lot of steps and a lot of work wasn't it!? The good news is that our
 - Generate bindings from the deployed contracts
 - Create a `$lib/contracts/<contract_alias>.ts` file for easy import into your frontend code
 
-You can always customize this script to suit your needs. Check out the [source code here](https://github.com/ElliotFriend/soroban-template-sveltekit-passkeys/blob/main/initialize.js) (which has been documented with comments). Or, you can see the [officially maintained script](https://github.com/stellar/soroban-template-astro/blob/main/initialize.js) in the [`soroban-template-astro` repository](https://github.com/stellar/soroban-template-astro), as well.
+You can always customize this script to suit your needs. Check out the [source code here](https://github.com/ElliotFriend/soroban-template-sveltekit-passkeys/blob/main/initialize.js) (which has been documented with comments). Or, you can learn more in the [officially-maintained script](https://github.com/stellar/soroban-template-astro/blob/main/initialize.js) in the [`soroban-template-astro` repository](https://github.com/stellar/soroban-template-astro), as well.
 
 Run the initialization script like so:
 

docs/build/apps/overview.mdx

@@ -17,7 +17,7 @@ This documentation includes sections on how to build applications without smart
 
 Many Stellar assets connect to real-world currencies, and Stellar has open protocols for integrating deposits and withdrawals of these assets via the [anchor network](https://stellar.org/learn/anchor-basics). Because of this, a Stellar-based application can take advantage of real banking rails and connect to real money.
 
-Read more about anchors in our [Anchors section](../../learn/fundamentals/anchors.mdx).
+Learn more about anchors in our [Anchors section](../../learn/fundamentals/anchors.mdx).
 
 Set up an anchor using the [Anchor Platform](../../platforms/anchor-platform/README.mdx).
 

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. You can read 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:
 

docs/build/apps/wallet/component/kt/watcher.mdx

@@ -20,6 +20,6 @@ This code example will consume all events coming from the channel until it's clo
 
 :::info
 
-Events are stored in the channel until they are received, and calling the `receive()` method will block the channel until a message is received. You can read more about how channels work in the [channel documentation](https://kotlinlang.org/docs/coroutines-and-channels.html#channels).
+Events are stored in the channel until they are received, and calling the `receive()` method will block the channel until a message is received. Learn more about how channels work in the [channel documentation](https://kotlinlang.org/docs/coroutines-and-channels.html#channels).
 
 :::

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. You can read 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:
 

docs/build/apps/wallet/intro.mdx

@@ -123,7 +123,7 @@ Default configuration connects to the public Stellar Horizon instance. You can c
 
 :::
 
-You can read more about working with the Stellar network in the [respective section](./stellar.mdx).
+Learn more in the [Stellar Network section](./stellar.mdx).
 
 ## Anchor Basics
 

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.
 
-You can read 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. You can read 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.
 

docs/build/apps/wallet/sep6.mdx

@@ -12,7 +12,7 @@ import Header from "./component/header.mdx";
 
 The [SEP-6] standard defines a way for anchors and wallets to interact on behalf of users. Wallets use this standard to facilitate exchanges between on-chain assets (such as stablecoins) and off-chain assets (such as fiat, or other network assets such as BTC).
 
-Please note, this is for _programmatic_ deposits and withdrawals. For hosted deposits and withdrawals, where the anchor interacts with wallets interactively using a popup, please see [Hosted Deposit and Withdrawal](./sep24.mdx).
+Please note, this is for _programmatic_ deposits and withdrawals. For hosted deposits and withdrawals, where the anchor interacts with wallets interactively using a popup, learn more in [Hosted Deposit and Withdrawal](./sep24.mdx).
 
 ## Get Anchor Information
 

docs/build/apps/wallet/stellar.mdx

@@ -576,7 +576,7 @@ let signedTransaction = stellar.decodeTransaction(xdr: xdrStringFromBackend)
 
 :::note
 
-You can read more about passing XDR transaction to the server in the [chapter below](#using-xdr-to-send-transaction-data).
+Learn more about passing XDR transaction to the server in the [chapter below](#using-xdr-to-send-transaction-data).
 
 :::
 

docs/build/building-with-ai.mdx

@@ -35,7 +35,7 @@ Unlike the static [`llms.txt`](#using-llmstxt) file and the installable [Stellar
 
 ### Connect your agent
 
-Add the server, then sign in. Sign-in happens inside your own client (Raven uses OAuth), so the first request opens your browser to authorize. For full setup details see [raven.stellar.buzz](https://raven.stellar.buzz).
+Add the server, then sign in. Sign-in happens inside your own client (Raven uses OAuth), so the first request opens your browser to authorize. For full setup details learn more at [raven.stellar.buzz](https://raven.stellar.buzz).
 
 {/* Rendered from src/data/agentTools.ts, shared with the "For agents" panel. */}
 

docs/build/guides/archival/README.mdx

@@ -4,4 +4,4 @@ hide_table_of_contents: true
 sidebar_position: 77
 ---
 
-Soroban's novel strategy to combat state bloat can present a learning curve for developers. Here are some quick guides that will help you through the process. Read more in the [State Archival section](../../../learn/fundamentals/contract-development/storage/state-archival.mdx).
+Soroban's novel strategy to combat state bloat can present a learning curve for developers. Here are some quick guides that will help you through the process. Learn more in the [State Archival section](../../../learn/fundamentals/contract-development/storage/state-archival.mdx).