diff --git a/docs/building-apps/application-design-considerations.mdx b/docs/building-apps/application-design-considerations.mdx
index 30542296b..2cfada49c 100644
--- a/docs/building-apps/application-design-considerations.mdx
+++ b/docs/building-apps/application-design-considerations.mdx
@@ -26,8 +26,6 @@ With a custodial service, the service provider (an application such as a central
 
 Many custodial services choose to use a single pooled Stellar account (called shared, omnibus, or [pooled accounts](../learn/encyclopedia/pooled-accounts-muxed-accounts-memos.mdx)) to handle transactions on behalf of their users instead of creating a new Stellar account for each user. To distinguish between individual users in a pooled account, we encourage the implementation of [muxed accounts](../learn/encyclopedia/pooled-accounts-muxed-accounts-memos.mdx#muxed-accounts).
 
-Learn how to set up an application as a custodial service in this [tutorial].
-
 ### A mixture of non-custodial and custodial
 
 Building an application with [multi-signature](../learn/encyclopedia/signatures-multisig.mdx) capabilities allows you to have a non-custodial service with account recovery. If the user loses their secret key, they can still sign transactions with other authorized signatures, granted the signature threshold is high enough.
diff --git a/docs/building-apps/example-application-tutorial/account-creation.mdx b/docs/building-apps/example-application-tutorial/account-creation.mdx
index 4a8b1aed1..260163699 100644
--- a/docs/building-apps/example-application-tutorial/account-creation.mdx
+++ b/docs/building-apps/example-application-tutorial/account-creation.mdx
@@ -189,7 +189,7 @@ Source: https://github.com/stellar/basic-payment-app/blob/main/src/lib/stellar/h
 Our `walletStore` is used in a ton of places in our application, especially in the confirmation modal when asking a user to input their pincode. Read on to see how we've done that.
 
 [accounts section]: ../../learn/fundamentals/stellar-data-structures/accounts.mdx
-[non-custodial application]: ../application-design-considerations#non-custodial-service
+[non-custodial application]: ../application-design-considerations.mdx#non-custodial-service
 [`js-stellar-wallets` sdk]: https://github.com/stellar/js-stellar-wallets
 [sponsored reserves]: ../../learn/encyclopedia/sponsored-reserves.mdx
 [contacts list]: ./contacts-list
diff --git a/docs/building-apps/example-application-tutorial/anchor-integration/sep6.mdx b/docs/building-apps/example-application-tutorial/anchor-integration/sep6.mdx
index 2f430e714..7605c70f0 100644
--- a/docs/building-apps/example-application-tutorial/anchor-integration/sep6.mdx
+++ b/docs/building-apps/example-application-tutorial/anchor-integration/sep6.mdx
@@ -47,7 +47,7 @@ export async function getSep6Info(domain) {
 
 ## Display interactive elements
 
-Since many of the SEP-6 (and SEP-24) endpoints require authentication, we wait until our user is [authenticated with SEP-10](./sep10) before we display what kinds of transfers are available. When they have a valid authentication token, we can display some buttons the user can use to begin a transfer.
+Since many of the SEP-6 (and SEP-24) endpoints require authentication, we wait until our user is [authenticated with SEP-10](./sep10.mdx) before we display what kinds of transfers are available. When they have a valid authentication token, we can display some buttons the user can use to begin a transfer.
 
 The user can then initiate one of the transfer methods (in BasicPay, only deposits and withdraws are supported) by clicking the “Deposit” or “Withdraw” button underneath a supported asset.
 
diff --git a/docs/building-apps/example-application-tutorial/anchor-integration/setup.mdx b/docs/building-apps/example-application-tutorial/anchor-integration/setup.mdx
index 7be37f673..c5529e1aa 100644
--- a/docs/building-apps/example-application-tutorial/anchor-integration/setup.mdx
+++ b/docs/building-apps/example-application-tutorial/anchor-integration/setup.mdx
@@ -3,9 +3,9 @@ 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 our [Anchor Documentation](https://developers.stellar.org/docs/anchoring-assets/overview).
+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/encyclopedia/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#account-creation-strategies).
+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).
 
diff --git a/docs/building-apps/example-application-tutorial/overview.mdx b/docs/building-apps/example-application-tutorial/overview.mdx
index e99c46e5a..5516911fa 100644
--- a/docs/building-apps/example-application-tutorial/overview.mdx
+++ b/docs/building-apps/example-application-tutorial/overview.mdx
@@ -5,7 +5,7 @@ sidebar_position: 10
 
 :::note
 
-This tutorial walks through how to build an application with the [`js-stellar-sdk`], to build with the Wallet SDK, please follow the [Build a Wallet tutorial](../wallet/overview). To build with smart contracts, navigate to the [Smart Contracts section](../../smart-contracts/getting-started/setup.mdx).
+This tutorial walks through how to build an application with the [`js-stellar-sdk`], to build with the Wallet SDK, please follow the [Build a Wallet tutorial](../wallet/overview.mdx). To build with smart contracts, navigate to the [Smart Contracts section](../../smart-contracts/getting-started/setup.mdx).
 
 :::
 
diff --git a/docs/building-apps/example-application-tutorial/payment.mdx b/docs/building-apps/example-application-tutorial/payment.mdx
index 9d846cd7e..d0df84ab0 100644
--- a/docs/building-apps/example-application-tutorial/payment.mdx
+++ b/docs/building-apps/example-application-tutorial/payment.mdx
@@ -37,7 +37,7 @@ The following additional features have been implemented:
   4. The amount entered for the send/receive value.
 - An optional memo field is available for text-only memos.
 
-For now, we'll focus on regular payments, and we'll dig into the path payments in a [later section](./path-payment).
+For now, we'll focus on regular payments, and we'll dig into the path payments in a [later section](./path-payment.mdx).
 
 ```html title="/src/routes/dashboard/send/+page.svelte"
 <script>
diff --git a/docs/building-apps/wallet/sep24.mdx b/docs/building-apps/wallet/sep24.mdx
index 94fe43936..a9bb9c1a0 100644
--- a/docs/building-apps/wallet/sep24.mdx
+++ b/docs/building-apps/wallet/sep24.mdx
@@ -81,7 +81,7 @@ var asset = info.currencies.firstWhere((it)=>it.code=='USDC').assetId;
 
 :::info
 
-Before starting with the deposit flow, make sure that the user account has [established a trustline](/docs/building-apps/wallet/stellar#modify-assets-trustlines) for the asset you are working with.
+Before starting with the deposit flow, make sure that the user account has [established a trustline](/docs/building-apps/wallet/stellar.mdx#modify-assets-trustlines) for the asset you are working with.
 
 :::
 
diff --git a/docs/building-apps/wallet/sep6.mdx b/docs/building-apps/wallet/sep6.mdx
index 2a94a141e..fba62c982 100644
--- a/docs/building-apps/wallet/sep6.mdx
+++ b/docs/building-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](/docs/building-apps/wallet/sep24).
+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](/docs/building-apps/wallet/sep24.mdx).
 
 ## Get Anchor Information
 
@@ -44,7 +44,7 @@ To initiate an operation, we need to know an asset. You can hardcode this. Ensur
 
 :::info
 
-Before starting with the deposit flow, make sure that the user account has [established a trustline](/docs/building-apps/wallet/stellar#modify-assets-trustlines) for the asset you are working with.
+Before starting with the deposit flow, make sure that the user account has [established a trustline](/docs/building-apps/wallet/stellar.mdx#modify-assets-trustlines) for the asset you are working with.
 
 :::
 
diff --git a/docs/issuing-assets/anatomy-of-an-asset.mdx b/docs/issuing-assets/anatomy-of-an-asset.mdx
index 35b8d14db..6a8b8394f 100644
--- a/docs/issuing-assets/anatomy-of-an-asset.mdx
+++ b/docs/issuing-assets/anatomy-of-an-asset.mdx
@@ -17,7 +17,7 @@ One major category of assets is the stablecoin. A stablecoin is a blockchain-bas
 
 Reserve-backed stablecoins are pegged to a real-world asset at a 1:1 ratio. Because the underlying asset is maintained as collateral, users should be able to trade their stablecoin for the asset at any time. Asset reserves can be maintained by independent custodians and should be regularly audited.
 
-Currently, one of Stellar's most significant use cases is the tokenization of fiat currency for processes like cross-border payments. With anchors, users can connect Stellar tokens to existing rails that allow for the deposit of real-world assets in exchange for digital currency and vice versa. Learn more about anchors in our [Anchors section](https://developers.stellar.org/docs/anchoring-assets/).
+Currently, one of Stellar's most significant use cases is the tokenization of fiat currency for processes like cross-border payments. With anchors, users can connect Stellar tokens to existing rails that allow for the deposit of real-world assets in exchange for digital currency and vice versa. Learn more about anchors in our [Anchors section](../learn/encyclopedia/anchors.mdx).
 
 ### Treasury management
 
@@ -27,5 +27,5 @@ When issuing a reserve-backed stablecoin, you must set up its off-chain reserve,
 
 As an asset issuer, you may need to comply with regulatory requirements that vary based on jurisdiction. Stellar has built-in features that can help meet these requirements, such as:
 
-- [Controlling access to an asset with flags](./control-asset-access#controlling-access-to-an-asset-with-flags)
+- [Controlling access to an asset with flags](./control-asset-access.mdx#controlling-access-to-an-asset-with-flags)
 - [SEP-0008: Regulated Assets](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md) - regulated assets are assets that require an issuer’s approval (or a delegated third party’s approval) on a per-transaction basis. Check out this Stellar Ecosystem Proposal to learn how to implement regulated assets into your use case.
diff --git a/docs/learn/encyclopedia/claimable-balances.mdx b/docs/learn/encyclopedia/claimable-balances.mdx
index d37dd05de..c3ee41be3 100644
--- a/docs/learn/encyclopedia/claimable-balances.mdx
+++ b/docs/learn/encyclopedia/claimable-balances.mdx
@@ -21,7 +21,7 @@ Once a ClaimableBalanceEntry has been claimed, it is deleted.
 
 ### Create Claimable Balance
 
-For basic parameters, see the Create Claimable Balance entry in our [List of Operations section](../fundamentals/list-of-operations#create-claimable-balance).
+For basic parameters, see the Create Claimable Balance entry in our [List of Operations section](../fundamentals/list-of-operations.mdx#create-claimable-balance).
 
 #### Additional parameters
 
@@ -53,7 +53,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 Encyclopedia Entry](./clawbacks).
+Learn more about clawbacks in our [Clawback Encyclopedia Entry](./clawbacks.mdx).
 
 ## Example
 
diff --git a/docs/learn/encyclopedia/error-handling.mdx b/docs/learn/encyclopedia/error-handling.mdx
index 0991fc5f9..2e3914c55 100644
--- a/docs/learn/encyclopedia/error-handling.mdx
+++ b/docs/learn/encyclopedia/error-handling.mdx
@@ -186,4 +186,4 @@ If you’re using SDF’s public Horizon instance, you may get a `429 Too Many R
 
 Any transaction that would reduce an account’s balance to less than the minimum will be rejected with an `INSUFFICIENT_BALANCE` error. Likewise, lumen selling liabilities that would reduce an account’s balance to less than the minimum plus lumen selling liabilities will be rejected with an `INSUFFICIENT_BALANCE` error.
 
-For more on minimum balances, see our [Lumens section](../fundamentals/lumens#minimum-balance).
+For more on minimum balances, see our [Lumens section](../fundamentals/lumens.mdx#minimum-balance).
diff --git a/docs/learn/encyclopedia/fee-bump-transactions.mdx b/docs/learn/encyclopedia/fee-bump-transactions.mdx
index 834540861..1f4800589 100644
--- a/docs/learn/encyclopedia/fee-bump-transactions.mdx
+++ b/docs/learn/encyclopedia/fee-bump-transactions.mdx
@@ -52,7 +52,7 @@ A fee-bump transaction goes through a series of checks in its lifecycle to deter
   - If the fee-bump transaction is taking advantage of the replace-by-fee, the fee must be 10x higher than the first transaction
 - **Fee account signature** — the fee-bump transaction envelope must contain a valid signature for the fee account. Additionally, the weight of that signature must meet the low threshold for the fee account, and the appropriate network passphrase must be part of the transaction hash signed by the fee account.
 - **Fee account balance** — the fee account must have a sufficient XLM balance to cover the fee
-- **Inner transaction** — the inner transaction must be valid, which means it must meet the requirements described in the [Validity of a Transaction section](../fundamentals/stellar-data-structures/operations-and-transactions#transaction-and-operation-validity). If validation of the inner transaction is successful, then the result is `FEE_BUMP_INNER_SUCCESS`, and the validation results from the validation of the inner transaction appear in the inner result. If the inner transaction is invalid, the result is `FEE_BUMP_INNER_FAILED`, and the fee-bump transaction is invalid because the inner transaction is invalid.
+- **Inner transaction** — the inner transaction must be valid, which means it must meet the requirements described in the [Validity of a Transaction section](../fundamentals/stellar-data-structures/operations-and-transactions.mdx#transaction-and-operation-validity). If validation of the inner transaction is successful, then the result is `FEE_BUMP_INNER_SUCCESS`, and the validation results from the validation of the inner transaction appear in the inner result. If the inner transaction is invalid, the result is `FEE_BUMP_INNER_FAILED`, and the fee-bump transaction is invalid because the inner transaction is invalid.
 
 ## Application
 
diff --git a/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx b/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx
index cfd7cffa7..02e98cade 100644
--- a/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx
+++ b/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx
@@ -12,7 +12,7 @@ This section is scoped specifically to liquidity regarding the AMM and SDEX buil
 
 Users can trade and convert assets on the Stellar network with the use of path payments through Stellar’s decentralized exchange and liquidity pools.
 
-In this section, we will talk about the SDEX and liquidity pools. To learn about how these work together to execute transactions, see our [Path Payments Encyclopedia Entry](./path-payments).
+In this section, we will talk about the SDEX and liquidity pools. To learn about how these work together to execute transactions, see our [Path Payments Encyclopedia Entry](./path-payments.mdx).
 
 ## SDEX
 
diff --git a/docs/learn/encyclopedia/memos.mdx b/docs/learn/encyclopedia/memos.mdx
index 6397e4e0d..b533af123 100644
--- a/docs/learn/encyclopedia/memos.mdx
+++ b/docs/learn/encyclopedia/memos.mdx
@@ -6,7 +6,7 @@ Memos are an optional unstructured data field that can be used to embed any addi
 
 They were previously used to differentiate between individual accounts in a pooled account- something we used muxed accounts for now.
 
-For more information on muxed accounts, see our [Pooled Accounts - Muxed Accounts & Memos Encyclopedia Entry](./pooled-accounts-muxed-accounts-memos)
+For more information on muxed accounts, see our [Pooled Accounts - Muxed Accounts & Memos Encyclopedia Entry](./pooled-accounts-muxed-accounts-memos.mdx)
 
 Memos can be one of the following types:
 
diff --git a/docs/learn/encyclopedia/path-payments.mdx b/docs/learn/encyclopedia/path-payments.mdx
index bfa4f643c..2ca5b1839 100644
--- a/docs/learn/encyclopedia/path-payments.mdx
+++ b/docs/learn/encyclopedia/path-payments.mdx
@@ -10,7 +10,7 @@ Account A sells XLM → [buy XLM / sell ETH → buy ETH / sell BTC → buy BTC /
 
 It is possible for path payments to fail if there are no viable exchange paths.
 
-For more information on the Stellar Decentralized Exchange and Liquidity Pools, see our [Liquidity on Stellar: SDEX and Liquidity Pools Encyclopedia Entry](./liquidity-on-stellar-sdex-liquidity-pools)
+For more information on the Stellar Decentralized Exchange and Liquidity Pools, see our [Liquidity on Stellar: SDEX and Liquidity Pools Encyclopedia Entry](./liquidity-on-stellar-sdex-liquidity-pools.mdx)
 
 ## Operations
 
diff --git a/docs/learn/encyclopedia/pooled-accounts-muxed-accounts-memos.mdx b/docs/learn/encyclopedia/pooled-accounts-muxed-accounts-memos.mdx
index 2752b4b56..fe21792e6 100644
--- a/docs/learn/encyclopedia/pooled-accounts-muxed-accounts-memos.mdx
+++ b/docs/learn/encyclopedia/pooled-accounts-muxed-accounts-memos.mdx
@@ -332,7 +332,7 @@ There are also abstractions for constructing and managing both muxed and regular
 
 Prior to the introduction of muxed accounts, products and services that relied on pooled accounts often used transaction memos to differentiate between users. Supporting muxed accounts is better in the long term, but for now you may want to support both memos and muxed accounts as all exchanges, anchors, and wallets may not support muxed accounts.
 
-To learn about what other purposes memos can be used for, see our [Memos Encyclopedia Entry](./memos).
+To learn about what other purposes memos can be used for, see our [Memos Encyclopedia Entry](./memos.mdx).
 
 ## Why are muxed accounts better in the long term?
 
diff --git a/docs/learn/encyclopedia/signatures-multisig.mdx b/docs/learn/encyclopedia/signatures-multisig.mdx
index f1d737b6d..4b165a92c 100644
--- a/docs/learn/encyclopedia/signatures-multisig.mdx
+++ b/docs/learn/encyclopedia/signatures-multisig.mdx
@@ -10,9 +10,9 @@ Transaction signatures are created by signing the transaction object contents wi
 
 ### Thresholds
 
-Each operation falls under a specific threshold category: low, medium, or high with a number level between 0-255 (to read more about this see our section on [Operations and Transactions](../fundamentals/stellar-data-structures/operations-and-transactions#operations)). This threshold determines what signature weight is needed to authorize an operation.
+Each operation falls under a specific threshold category: low, medium, or high with a number level between 0-255 (to read more about this see our section on [Operations and Transactions](../fundamentals/stellar-data-structures/operations-and-transactions.mdx#operations)). This threshold determines what signature weight is needed to authorize an operation.
 
-To view each operation’s threshold, see our [List of Operations section](../fundamentals/list-of-operations).
+To view each operation’s threshold, see our [List of Operations section](../fundamentals/list-of-operations.mdx).
 
 Accounts can set their own signature weight, threshold values, and additional signing keys with the Set Options operation. By default, all operation threshold levels are set to 0, and the master key is set to weight 1. For most cases, it is recommended to set thresholds such that `low <= medium <= high`.
 
diff --git a/docs/learn/encyclopedia/sponsored-reserves.mdx b/docs/learn/encyclopedia/sponsored-reserves.mdx
index f2790464f..23b778b0b 100644
--- a/docs/learn/encyclopedia/sponsored-reserves.mdx
+++ b/docs/learn/encyclopedia/sponsored-reserves.mdx
@@ -10,7 +10,7 @@ Both the Begin Sponsoring Future Reserves and the End Sponsoring Future Reserves
 
 Anything that increases the minimum balance can be sponsored (account creation, offers, trustlines, data entries, signers, claimable balances).
 
-To learn about base reserves, see our section on [Lumens](../fundamentals/lumens#base-reserves).
+To learn about base reserves, see our section on [Lumens](../fundamentals/lumens.mdx#base-reserves).
 
 ## Sponsored reserves operations
 
@@ -28,7 +28,7 @@ End Sponsoring Future Reserves ends the current is-sponsoring-future-reserves-fo
 
 At the end of any transaction, there must be no ongoing is-sponsoring-future-reserves-for relationships, which is why these two operations must be used together in a single transaction.
 
-View operation details in our [List of Operations section](../fundamentals/list-of-operations).
+View operation details in our [List of Operations section](../fundamentals/list-of-operations.mdx).
 
 ### Revoke sponsorship
 
@@ -47,7 +47,7 @@ Operation logic
   - Source account is not the beneficiary of a is-sponsoring-future-reserves-for relationship
     - No-Op
 
-View operation details in our [List of Operations section](../fundamentals/list-of-operations#begin-sponsoring-future-reserves).
+View operation details in our [List of Operations section](../fundamentals/list-of-operations.mdx#begin-sponsoring-future-reserves).
 
 ## Effect on minimum balance
 
@@ -57,13 +57,13 @@ When account A is sponsoring future reserves for account B, any reserve requirem
 
 When a sponsored entry or subentry is removed, `numSponsoring` is decreased on the sponsoring account and `numSponsored` is decreased on the sponsored account.
 
-To learn more about minimum balance requirements, see our section on [Lumens](../fundamentals/lumens#minimum-balance).
+To learn more about minimum balance requirements, see our section on [Lumens](../fundamentals/lumens.mdx#minimum-balance).
 
 ## Effect on claimable balances
 
 All claimable balances are sponsored through built-in logic in the claimable balance operations. The account that creates the claimable balance pays the base reserve to get the claimable balance on the ledger. When the claimable balance is claimed by the claimant(s), the claimable balance is removed from the ledger, and the account that created it gets the base reserve back.
 
-Read more about claimable balances in our [Claimable Balances Encyclopedia Entry](./claimable-balances).
+Read more about claimable balances in our [Claimable Balances Encyclopedia Entry](./claimable-balances.mdx).
 
 ## Examples
 
diff --git a/docs/learn/fundamentals/list-of-operations.mdx b/docs/learn/fundamentals/list-of-operations.mdx
index 61f2dbe0f..6eec9e7ea 100644
--- a/docs/learn/fundamentals/list-of-operations.mdx
+++ b/docs/learn/fundamentals/list-of-operations.mdx
@@ -5,7 +5,7 @@ sidebar_position: 40
 
 Operations are objects that represent a desired change to the ledger and are submitted to the network grouped in a transaction. For each operation, there is a successful or failed result type. In the case of success, the user can gather information about the effect of the operation. In the case of failure, the user can learn more about the error.
 
-Learn more about transactions and operations in our [Transaction and Operations section](./stellar-data-structures/operations-and-transactions).
+Learn more about transactions and operations in our [Operations and Transactions section](./stellar-data-structures/operations-and-transactions.mdx).
 
 There are currently 26 operations you can use on the Stellar network, these operations, their definitions, SDKs, thresholds, parameters, and errors are listed below.
 
@@ -56,7 +56,7 @@ Sends an amount in a specific asset to a destination account
 | PAYMENT_SRC_NO_TRUST | -3 | The source account does not trust the issuer of the asset it is trying to send. |
 | PAYMENT_SRC_NOT_AUTHORIZED | -4 | The source account is not authorized to send this payment. |
 | PAYMENT_NO_DESTINATION | -5 | The receiving account does not exist. Note that this error will **not** be returned if the receiving account is the issuer of `asset`. |
-| PAYMENT_NO_TRUST | -6 | The receiver does not trust the issuer of the asset being sent. For more information, see the [Assets section](./stellar-data-structures/assets). |
+| PAYMENT_NO_TRUST | -6 | The receiver does not trust the issuer of the asset being sent. For more information, see the [Assets section](./stellar-data-structures/assets.mdx). |
 | PAYMENT_NOT_AUTHORIZED | -7 | The destination account is not authorized by the asset's issuer to hold the asset. |
 | PAYMENT_LINE_FULL | -8 | The destination account (receiver) does not have sufficient limits to receive `amount` and still satisfy its buying liabilities. |
 
@@ -64,7 +64,7 @@ Sends an amount in a specific asset to a destination account
 
 A payment where the asset sent can be different than the asset received; allows the user to specify the amount of the asset to send
 
-Learn more about path payments: [Path Payments Encyclopedia Entry](../encyclopedia/path-payments)
+Learn more about path payments: [Path Payments Encyclopedia Entry](../encyclopedia/path-payments.mdx)
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.pathPaymentStrictSend) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/PathPaymentStrictSendOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#PathPaymentStrictSend)  
 **Threshold**: Medium  
@@ -89,7 +89,7 @@ Learn more about path payments: [Path Payments Encyclopedia Entry](../encycloped
 | PATH_PAYMENT_STRICT_SEND_SRC_NO_TRUST | -3 | The source account does not trust the issuer of the asset it is trying to send. |
 | PATH_PAYMENT_STRICT_SEND_SRC_NOT_AUTHORIZED | -4 | The source account is not authorized to send this payment. |
 | PATH_PAYMENT_STRICT_SEND_NO_DESTINATION | -5 | The destination account does not exist. |
-| PATH_PAYMENT_STRICT_SEND_NO_TRUST | -6 | The destination account does not trust the issuer of the asset being sent. For more, see the [Assets section](./stellar-data-structures/assets). |
+| PATH_PAYMENT_STRICT_SEND_NO_TRUST | -6 | The destination account does not trust the issuer of the asset being sent. For more, see the [Assets section](./stellar-data-structures/assets.mdx). |
 | PATH_PAYMENT_STRICT_SEND_NOT_AUTHORIZED | -7 | The destination account is not authorized by the asset's issuer to hold the asset. |
 | PATH_PAYMENT_STRICT_SEND_LINE_FULL | -8 | The destination account does not have sufficient limits to receive `destination amount` and still satisfy its buying liabilities. |
 | PATH_PAYMENT_STRICT_SEND_TOO_FEW_OFFERS | -10 | There is no path of offers connecting the `send asset` and `destination asset`. Stellar only considers paths of length 5 or shorter. |
@@ -100,7 +100,7 @@ Learn more about path payments: [Path Payments Encyclopedia Entry](../encycloped
 
 A payment where the asset received can be different from the asset sent; allows the user to specify the amount of the asset received
 
-Learn more about path payments: [Path Payments Encyclopedia Entry](../encyclopedia/path-payments)
+Learn more about path payments: [Path Payments Encyclopedia Entry](../encyclopedia/path-payments.mdx)
 
 **SDKs**: [JavaScript](https://stellar.github.io/js-stellar-sdk/Operation.html#.pathPaymentStrictReceive) | [Java](https://stellar.github.io/java-stellar-sdk/org/stellar/sdk/PathPaymentStrictReceiveOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#PathPaymentStrictReceive)  
 **Threshold**: Medium  
@@ -125,7 +125,7 @@ Learn more about path payments: [Path Payments Encyclopedia Entry](../encycloped
 | PATH_PAYMENT_STRICT_RECEIVE_SRC_NO_TRUST | -3 | The source account does not trust the issuer of the asset it is trying to send. |
 | PATH_PAYMENT_STRICT_RECEIVE_SRC_NOT_AUTHORIZED | -4 | The source account is not authorized to send this payment. |
 | PATH_PAYMENT_STRICT_RECEIVE_NO_DESTINATION | -5 | The destination account does not exist. |
-| PATH_PAYMENT_STRICT_RECEIVE_NO_TRUST | -6 | The destination account does not trust the issuer of the asset being sent. For more, see the [Assets section](./stellar-data-structures/assets). |
+| PATH_PAYMENT_STRICT_RECEIVE_NO_TRUST | -6 | The destination account does not trust the issuer of the asset being sent. For more, see the [Assets section](./stellar-data-structures/assets.mdx). |
 | PATH_PAYMENT_STRICT_RECEIVE_NOT_AUTHORIZED | -7 | The destination account is not authorized by the asset's issuer to hold the asset. |
 | PATH_PAYMENT_STRICT_RECEIVE_LINE_FULL | -8 | The destination account does not have sufficient limits to receive `destination amount` and still satisfy its buying liabilities. |
 | PATH_PAYMENT_STRICT_RECEIVE_TOO_FEW_OFFERS | -10 | There is no path of offers connecting the `send asset` and `destination asset`. Stellar only considers paths of length 5 or shorter. |
@@ -136,7 +136,7 @@ Learn more about path payments: [Path Payments Encyclopedia Entry](../encycloped
 
 Creates, updates, or deletes an offer to buy a specific amount of an asset for another
 
-Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools)
+Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx)
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.manageBuyOffer) | [Java](https://stellar.github.io/java-stellar-sdk/org/stellar/sdk/ManageBuyOfferOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#ManageBuyOffer)  
 **Threshold**: Medium  
@@ -170,7 +170,7 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity
 
 Creates, updates, or deletes an offer to sell a specific amount of an asset for another
 
-Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools)
+Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx)
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.manageSellOffer) | [Java](https://stellar.github.io/java-stellar-sdk/org/stellar/sdk/ManageSellOfferOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#ManageSellOffer)  
 **Threshold**: Medium  
@@ -204,7 +204,7 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity
 
 Creates an offer to sell one asset for another without taking a reverse offer of equal price
 
-Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools)
+Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx)
 
 **SDKs**: [JavaScript](https://stellar.github.io/js-stellar-sdk/Operation.html#.createPassiveSellOffer) | [Java](https://stellar.github.io/java-stellar-sdk/org/stellar/sdk/CreatePassiveSellOfferOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#CreatePassiveSellOffer)  
 **Threshold**: Medium  
@@ -237,9 +237,9 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity
 
 Set options for an account such as flags, inflation destination, signers, home domain, and master key weight
 
-Learn more about flags: [Flags Encyclopedia Entry](../glossary/#flags)  
+Learn more about flags: [Flags Encyclopedia Entry](../glossary.mdx/#flags)  
 Learn more about the home domain: [Stellar Ecosystem Proposals SEP-0001](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md)  
-Learn more about signers operations and key weight: [Signature and Multisignature Encyclopedia Entry](../encyclopedia/signatures-multisig)
+Learn more about signers operations and key weight: [Signature and Multisignature Encyclopedia Entry](../encyclopedia/signatures-multisig.mdx)
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.setOptions) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/SetOptionsOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#SetOptions)  
 **Threshold**: High (when updating signers or other thresholds) or Medium (when updating everything else)  
@@ -249,12 +249,12 @@ Learn more about signers operations and key weight: [Signature and Multisignatur
 | Parameters | Type | Description |
 | --- | --- | --- |
 | Inflation Destination | account ID | Account of the inflation destination. |
-| Clear flags | integer | Indicates which flags to clear. For details about the flags, please refer to the [Accounts section](./stellar-data-structures/accounts). The bit mask integer subtracts from the existing flags of the account. This allows for setting specific bits without knowledge of existing flags. |
-| Set flags | integer | Indicates which flags to set. For details about the flags, please refer to the [Accounts section](./stellar-data-structures/accounts). The bit mask integer adds onto the existing flags of the account. This allows for setting specific bits without knowledge of existing flags. |
+| Clear flags | integer | Indicates which flags to clear. For details about the flags, please refer to the [Accounts section](./stellar-data-structures/accounts.mdx). The bit mask integer subtracts from the existing flags of the account. This allows for setting specific bits without knowledge of existing flags. |
+| Set flags | integer | Indicates which flags to set. For details about the flags, please refer to the [Accounts section](./stellar-data-structures/accounts.mdx). The bit mask integer adds onto the existing flags of the account. This allows for setting specific bits without knowledge of existing flags. |
 | Master weight | integer | A number from 0-255 (inclusive) representing the weight of the master key. If the weight of the master key is updated to 0, it is effectively disabled. |
-| Low threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a low threshold](../encyclopedia/signatures-multisig). |
-| Medium threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a medium threshold](../encyclopedia/signatures-multisig). |
-| High threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a high threshold](../encyclopedia/signatures-multisig). |
+| Low threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a low threshold](../encyclopedia/signatures-multisig.mdx). |
+| Medium threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a medium threshold](../encyclopedia/signatures-multisig.mdx). |
+| High threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a high threshold](../encyclopedia/signatures-multisig.mdx). |
 | Home domain | string | Sets the home domain of an account. See [Federation](../encyclopedia/federation.mdx). |
 | Signer | \{Public Key, weight} | Add, update, or remove a signer from an account. Signer weight is a number from 0-255 (inclusive). The signer is deleted if the weight is 0. |
 
@@ -276,7 +276,7 @@ Learn more about signers operations and key weight: [Signature and Multisignatur
 
 Creates, updates, or deletes a trustline
 
-Learn more about trustlines: [Trustlines section](./stellar-data-structures/accounts#trustlines)
+Learn more about trustlines: [Trustlines section](./stellar-data-structures/accounts.mdx#trustlines)
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.changeTrust) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/ChangeTrustOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#ChangeTrust)  
 **Threshold**: Medium  
@@ -358,7 +358,7 @@ Transfers the XLM balance of an account to another account and removes the sourc
 
 Sets, modifies, or deletes a data entry (name/value pair) that is attached to an account
 
-Learn more about entries and subentries: [Accounts section](./stellar-data-structures/accounts#subentries)
+Learn more about entries and subentries: [Accounts section](./stellar-data-structures/accounts.mdx#subentries)
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.manageData) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/ManageDataOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#ManageData)  
 **Threshold**: Medium  
@@ -402,7 +402,7 @@ Bumps forward the sequence number of the source account to the given sequence nu
 
 Moves an amount of asset from the operation source account into a new ClaimableBalanceEntry
 
-Learn more about claimable balances: [Claimable Balances Encyclopedia Entry](../encyclopedia/claimable-balances)
+Learn more about claimable balances: [Claimable Balances Encyclopedia Entry](../encyclopedia/claimable-balances.mdx)
 
 **Threshold**: Medium  
 **Result**: `CreateClaimableBalanceResult`  
@@ -428,7 +428,7 @@ Learn more about claimable balances: [Claimable Balances Encyclopedia Entry](../
 
 Claims a ClaimableBalanceEntry that corresponds to the BalanceID and adds the amount of an asset on the entry to the source account
 
-Learn more about claimable balances and view more parameters: [Claimable Balances Encyclopedia Entry](../encyclopedia/claimable-balances)
+Learn more about claimable balances and view more parameters: [Claimable Balances Encyclopedia Entry](../encyclopedia/claimable-balances.mdx)
 
 **Threshold**: Low  
 **Result**: `ClaimClaimableBalanceResult`  
@@ -436,7 +436,7 @@ Learn more about claimable balances and view more parameters: [Claimable Balance
 
 | Parameters | Type | Description |
 | --- | --- | --- |
-| BalanceID | claimableBalanceID | BalanceID on the ClaimableBalanceEntry that the source account is claiming. The balanceID can be retrieved from a successful `CreateClaimableBalanceResult`. See [Claimable Balance Encyclopedia Entry](../encyclopedia/claimable-balances#create-claimable-balance) for more information. |
+| BalanceID | claimableBalanceID | BalanceID on the ClaimableBalanceEntry that the source account is claiming. The balanceID can be retrieved from a successful `CreateClaimableBalanceResult`. See [Claimable Balance Encyclopedia Entry](../encyclopedia/claimable-balances.mdx#create-claimable-balance) for more information. |
 
 **Possible errors**:
 
@@ -454,7 +454,7 @@ Allows an account to pay the base reserves for another account; sponsoring accou
 
 There must also be an end sponsoring future reserves operation in the same transaction
 
-Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves)
+Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves.mdx)
 
 **Threshold**: Medium  
 **Result**: `BeginSponsoringFutureReservesResult`  
@@ -476,7 +476,7 @@ Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../
 
 Terminates the current is-sponsoring-future-reserves relationship in which the source account is sponsored
 
-Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves)
+Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves.mdx)
 
 **Threshold**: Medium  
 **Result**: `EndSponsoringFutureReservesResult`  
@@ -496,7 +496,7 @@ Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../
 
 Sponsoring account can remove or transfer sponsorships of existing ledgerEntries and signers; the logic of this operation depends on the state of the source account
 
-Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves)
+Learn more about sponsored reserves: [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves.mdx)
 
 **Threshold**: Medium  
 **Result**: `RevokeSponsorshipResult`
@@ -505,7 +505,7 @@ This operation is a union with **two** possible types:
 
 | Union Type | Parameters | Type | Description |
 | --- | --- | --- | --- |
-| REVOKE_SPONSORSHIP_LEDGER_ENTRY | LedgerKey | ledgerKey | Ledger key that holds information to identify a specific ledgerEntry that may have its sponsorship modified. See [LedgerKey](../glossary#ledgerkey) for more information. |
+| REVOKE_SPONSORSHIP_LEDGER_ENTRY | LedgerKey | ledgerKey | Ledger key that holds information to identify a specific ledgerEntry that may have its sponsorship modified. See [LedgerKey](../glossary.mdx#ledgerkey) for more information. |
 
 Or
 
@@ -527,7 +527,7 @@ Or
 
 Burns an amount in a specific asset from a receiving account
 
-Learn more about clawbacks: [Clawback Encyclopedia Entry](../encyclopedia/clawbacks)
+Learn more about clawbacks: [Clawback Encyclopedia Entry](../encyclopedia/clawbacks.mdx)
 
 **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.clawback) | [Java](http://stellar.github.io/java-stellar-sdk/org/stellar/sdk/ClawbackOperation.Builder.html) | [Go](https://godoc.org/github.com/stellar/go/txnbuild#Clawback)  
 **Threshold**: Medium  
@@ -553,9 +553,9 @@ Learn more about clawbacks: [Clawback Encyclopedia Entry](../encyclopedia/clawba
 
 Claws back an unclaimed ClaimableBalanceEntry, burning the pending amount of the asset
 
-Learn more about clawbacks: [Clawback Encyclopedia Entry](../encyclopedia/clawbacks)
+Learn more about clawbacks: [Clawback Encyclopedia Entry](../encyclopedia/clawbacks.mdx)
 
-Learn more about claimable balances: [Claimable Balances Encyclopedia Entry](../encyclopedia/claimable-balances)
+Learn more about claimable balances: [Claimable Balances Encyclopedia Entry](../encyclopedia/claimable-balances.mdx)
 
 **Threshold**: Medium  
 **Result**: `ClaimClaimableBalanceResult`  
@@ -579,7 +579,7 @@ Allows issuing account to configure authorization and trustline flags to an asse
 
 The Asset parameter is of the `TrustLineAsset` type. If you are modifying a trustline to a regular asset (i.e. one in a Code:Issuer format), this is equivalent to the Asset type. If you are modifying a trustline to a pool share, however, this is composed of the liquidity pool's unique ID.
 
-Learn more about flags: [Flags Glossary Entry](../glossary/#flags)
+Learn more about flags: [Flags Glossary Entry](../glossary.mdx/#flags)
 
 **Threshold**: Low  
 **Result**: `SetTrustLineFlagsResult`  
@@ -610,7 +610,7 @@ Parameters to this operation depend on the ordering of assets in the liquidity p
 
 If the pool is empty, then this operation deposits maxAmountA of A and maxAmountB of B into the pool. If the pool is not empty, then this operation deposits at most maxAmountA of A and maxAmountB of B into the pool. The actual amounts deposited are determined using the current reserves of the pool. You can use these parameters to control a percentage of slippage.
 
-Learn more about liquidity pools: [Liquidity Pools Encyclopedia Entry](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools)
+Learn more about liquidity pools: [Liquidity Pools Encyclopedia Entry](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx)
 
 **Threshold**: Medium  
 **Result**: `LiquidityPoolDepositResult`  
@@ -642,7 +642,7 @@ Withdraw assets from a liquidity pool, reducing the number of pool shares in exc
 
 The minAmountA and minAmountB parameters can be used to control a percentage of slippage from the "spot price" on the pool.
 
-Learn more about liquidity pools: [Liquidity Pools Encyclopedia Entry](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools)
+Learn more about liquidity pools: [Liquidity Pools Encyclopedia Entry](../encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx)
 
 **Threshold**: Medium  
 **Result**: `LiquidityPoolWithdrawResult`  
@@ -677,7 +677,7 @@ The `InvokeHostFunctionOp` can be used to perform the following Soroban operatio
 
 Note that Soroban transactions can only contain one operation per transaction.
 
-Learn more in the [Soroban docs](https://soroban.stellar.org/docs/fundamentals-and-concepts/invoking-contracts-with-transactions#invokehostfunctionop).
+Learn more [here](../smart-contract-internals/contract-interactions/stellar-transaction.mdx#invokehostfunctionop).
 
 **Threshold**: Medium  
 **Result**: `InvokeHostFunctionResult`  
@@ -704,7 +704,7 @@ Extend the time to live (TTL) of entries for Soroban smart contracts with the `E
 
 Note that Soroban transactions can only contain one operation per transaction.
 
-Learn more in the [Soroban docs](https://soroban.stellar.org/docs/fundamentals-and-concepts/state-expiration#bumpfootprintexpirationop).
+Learn more in the [State Archival section](../smart-contract-internals/state-archival.mdx).
 
 **Threshold**: Medium  
 **Result**: `ExtendFootprintTTLResult`  
@@ -729,7 +729,7 @@ Make archived Soroban smart contract entries accessible again by restoring them
 
 Note that Soroban transactions can only contain one operation per transaction.
 
-Learn more in the [Soroban docs](https://soroban.stellar.org/docs/fundamentals-and-concepts/state-expiration#restorefootprintop).
+Learn more in the [State Archival section](../smart-contract-internals/state-archival.mdx).
 
 **Threshold**: Medium  
 **Result**: `RestoreFootprintResult`  
diff --git a/docs/learn/fundamentals/lumens.mdx b/docs/learn/fundamentals/lumens.mdx
index aa774c23f..60fc031fe 100644
--- a/docs/learn/fundamentals/lumens.mdx
+++ b/docs/learn/fundamentals/lumens.mdx
@@ -13,7 +13,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)). Read more in the [Fees and Metering section](https://soroban.stellar.org/docs/fundamentals-and-concepts/fees-and-metering) in the Soroban docs.
+Smart contract transactions on Stellar employ a different fee structure based on an inclusion fee and resource consumption (which includes [rent](#rent)). Read more in the [Fees and Metering section](./fees-resource-limits-metering.mdx).
 
 ## Base reserves
 
@@ -31,8 +31,8 @@ For example, an account with one trustline, two offers, and a claimable balance
 
 2 base reserves (1 XLM) + 3 subentries/base reserves (1.5 XLM) + 1 ledger entry/base reserve (1 XLM) = 3.5 XLM
 
-When you close a subentry, the associated base reserve will be added to your available balance. An account must always pay its own minimum balance unless a subentry is being sponsored by another account. For information about this, see our [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves).
+When you close a subentry, the associated base reserve will be added to your available balance. An account must always pay its own minimum balance unless a subentry is being sponsored by another account. For information about this, see our [Sponsored Reserves Encyclopedia Entry](../encyclopedia/sponsored-reserves.mdx).
 
 ## Rent
 
-Smart contract data does not require any base reserves in order to live on the ledger, so every smart contract entry must pay rent instead. The rent charged for an entry to exist on the ledger is based on how big the entry is and how long the it should be live on the ledger before being archived. There are different rent requirements for each storage type `Persistent`, `Temporary`, and `Instance`, which you can read about in the [Fees and Metering section](https://soroban.stellar.org/docs/fundamentals-and-concepts/fees-and-metering#refundable-resources) of the Soroban docs.
+Smart contract data does not require any base reserves in order to live on the ledger, so every smart contract entry must pay rent instead. The rent charged for an entry to exist on the ledger is based on how big the entry is and how long the it should be live on the ledger before being archived. There are different rent requirements for each storage type `Persistent`, `Temporary`, and `Instance`, which you can read about in the [State Archival section](../smart-contract-internals/state-archival.mdx).
diff --git a/docs/learn/fundamentals/networks.mdx b/docs/learn/fundamentals/networks.mdx
index ad8b89466..15c24e67c 100644
--- a/docs/learn/fundamentals/networks.mdx
+++ b/docs/learn/fundamentals/networks.mdx
@@ -12,7 +12,7 @@ Stellar has three networks: the public network (Mainnet, also called Pubnet or t
 - Validator nodes are run by the public
 - SDF offers free [Horizon Testnet and Futurenet Instances](/network/horizon/horizon-providers#sdf-provided-horizon) to interact with the Testnet and Futurenet. The ecosystem has [Horizon providers](/network/horizon/horizon-providers#ecosystem-horizon-providers) whom offer instances for Testnet and Mainnet. You can [run your own Horizon](/network/core-node/admin-guide) or use an instance offered by an [infrastructure provider](/network/horizon/horizon-providers#ecosystem-horizon-providers).
 - You need to fund your account with XLM from another account
-- Mainnet is limited to 1,000 operations per ledger and will be limited to a maximum of 100 smart contract transactions per ledger (the precise amount of smart contract txs per ledger can vary greatly depending on transaction [resource limits](./fees-resource-limits-metering#resource-limits)).
+- Mainnet is limited to 1,000 operations per ledger and will be limited to a maximum of 100 smart contract transactions per ledger (the precise amount of smart contract txs per ledger can vary greatly depending on transaction [resource limits](./fees-resource-limits-metering.mdx#resource-limits)).
   - See more detailed smart contract network settings in the section on [Fees and Metering](./fees-resource-limits-metering.mdx).
 - No publicly available RPC, see RPC service providers [here](/network/soroban-rpc/rpc-providers)
 
diff --git a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx
index fd8530968..08f8df16d 100644
--- a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx
+++ b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx
@@ -5,21 +5,21 @@ sidebar_position: 20
 
 Accounts are the central data structure in Stellar- they hold balances, sign transactions, and issue assets. Accounts can only exist with a valid keypair and the required minimum balance of XLM.
 
-To learn about minimum balance requirements, [see our section on Lumens](../lumens#minimum-balance).
+To learn about minimum balance requirements, [see our section on Lumens](../lumens.mdx#minimum-balance).
 
 Accounts are made up of the below fields. Click on the field to learn more about it.
 
-- [Account ID](../../glossary#account-id)
-- [Balances](../../glossary#balance)
-- [Flags](../../glossary/#flags)
-- [Home Domain (up to 32 characters)](../../glossary#home-domain)
-- [Liabilities](../../glossary#liability)
-- [Number of entries sponsored by this account](../../encyclopedia/sponsored-reserves)
-- [Number of sponsored reserves](../../encyclopedia/sponsored-reserves)
-- [Number of subentries](./accounts#subentries)
-- [Sequence number](../../glossary#sequence-number)
-- [Signers](../../encyclopedia/signatures-multisig)
-- [Thresholds](../../encyclopedia/signatures-multisig#thresholds)
+- [Account ID](../../glossary.mdx#account-id)
+- [Balances](../../glossary.mdx#balance)
+- [Flags](../../glossary.mdx#flags)
+- [Home Domain (up to 32 characters)](../../glossary.mdx#home-domain)
+- [Liabilities](../../glossary.mdx#liability)
+- [Number of entries sponsored by this account](../../encyclopedia/sponsored-reserves.mdx)
+- [Number of sponsored reserves](../../encyclopedia/sponsored-reserves.mdx)
+- [Number of subentries](./accounts.mdx#subentries)
+- [Sequence number](../../glossary.mdx#sequence-number)
+- [Signers](../../encyclopedia/signatures-multisig.mdx)
+- [Thresholds](../../encyclopedia/signatures-multisig.mdx#thresholds)
 
 ## Base reserves and subentries
 
@@ -42,6 +42,6 @@ Account data is stored in subentries, each of which increases an account’s min
 
 Trustlines are an explicit opt-in for an account to hold and trade a particular asset. To hold a specific asset, an account must establish a trustline with the issuing account using the change_trust operation. Trustlines track the balance of an asset and can also limit the amount of an asset that an account can hold.
 
-A trustline must be established for an account to receive any asset except lumens (XLM). You can create a claimable balance to send assets to an account without a trustline, but the recipient has to create a trustline to claim that balance. Learn more here: [Claimable Balances Encyclopedia Entry](../../encyclopedia/claimable-balances)
+A trustline must be established for an account to receive any asset except lumens (XLM). You can create a claimable balance to send assets to an account without a trustline, but the recipient has to create a trustline to claim that balance. Learn more here: [Claimable Balances Encyclopedia Entry](../../encyclopedia/claimable-balances.mdx)
 
 A trustline also tracks liabilities. Buying liabilities equal the total amount of the asset offered to buy aggregated over all offers owned by an account, and selling liabilities equal the total amount of the asset offered to sell aggregated over all offers owned by an account. A trustline must always have a balance sufficiently large to satisfy its selling liabilities and a balance sufficiently below its limit to accommodate its buying liabilities.
diff --git a/docs/learn/fundamentals/stellar-data-structures/assets.mdx b/docs/learn/fundamentals/stellar-data-structures/assets.mdx
index 344bc66d5..b1a0f3c4f 100644
--- a/docs/learn/fundamentals/stellar-data-structures/assets.mdx
+++ b/docs/learn/fundamentals/stellar-data-structures/assets.mdx
@@ -31,7 +31,7 @@ Assets issued on the Stellar network are accessible to smart contracts. Every St
 
 The Soroban CLI can deploy a Stellar Asset Contract for a Stellar asset. Deploying the Stellar Asset Contract for a Stellar asset enables that asset for use with smart contracts.
 
-Learn more in the [SAC section in the Soroban docs](../../../smart-contracts/tokens/stellar-asset-contract.mdx).
+Learn more in the [SAC section](../../../smart-contracts/tokens/stellar-asset-contract.mdx).
 
 ## Representation
 
diff --git a/docs/learn/fundamentals/stellar-data-structures/contracts.mdx b/docs/learn/fundamentals/stellar-data-structures/contracts.mdx
index c29eb7cfd..be4300b22 100644
--- a/docs/learn/fundamentals/stellar-data-structures/contracts.mdx
+++ b/docs/learn/fundamentals/stellar-data-structures/contracts.mdx
@@ -5,7 +5,7 @@ sidebar_position: 50
 
 :::note
 
-Stellar has integrated a smart contracts platform called "[Soroban](../../../smart-contracts/getting-started/README.mdx)" into the core protocol. This platform is live on Mainnet and is in [Phase 1 of its phased rollout launch](https://stellar.org/blog/developers/the-stellar-network-s-phased-rollout-of-smart-contracts-the-road-to-mainnet).
+Stellar has integrated a smart contracts platform called "[Soroban](../../../smart-contracts/getting-started/README.mdx)" into the core protocol.
 
 :::
 
diff --git a/docs/learn/fundamentals/stellar-data-structures/operations-and-transactions.mdx b/docs/learn/fundamentals/stellar-data-structures/operations-and-transactions.mdx
index c0670c581..55459f488 100644
--- a/docs/learn/fundamentals/stellar-data-structures/operations-and-transactions.mdx
+++ b/docs/learn/fundamentals/stellar-data-structures/operations-and-transactions.mdx
@@ -13,34 +13,34 @@ Operations are individual commands that modify the ledger. Operations are used t
 
 All operations fall into one of three threshold categories: low, medium, or high, and each threshold category has a weight between 0 and 255 (which can be determined using set_options). Thresholds determine what signature weight is required for the operation to be accepted. For example, let’s say an account sets the medium threshold weight to 5. If the account wants to successfully establish a trustline with the `changeTrust` operation, the weight of the signature(s) must be greater than or equal to 5.
 
-To learn more about signature weight, see the [Signature and Multisignature Encyclopedia Entry](../../encyclopedia/signatures-multisig).
+To learn more about signature weight, see the [Signature and Multisignature Encyclopedia Entry](../../encyclopedia/signatures-multisig.mdx).
 
-View a comprehensive list of Stellar operations and their threshold levels in the [List of Operations section](../list-of-operations).
+View a comprehensive list of Stellar operations and their threshold levels in the [List of Operations section](../list-of-operations.mdx).
 
 ### Transactions
 
-The Stellar network encodes transactions using a standardized protocol called External Data Representation (XDR). You can read more about this in our [XDR Encyclopedia Entry](../../encyclopedia/xdr).
+The Stellar network encodes transactions using a standardized protocol called External Data Representation (XDR). You can read more about this in our [XDR Encyclopedia Entry](../../encyclopedia/xdr.mdx).
 
 Accounts can only perform one transaction at a time.
 
 Transactions comprise a bundle of between 1-100 operations (except smart contract transactions, which can only have one operation per transaction) and are signed and submitted to the ledger by accounts. Transactions always need to be authorized by the source account’s public key to be valid, which involves signing the transaction object with the public key’s associated secret key. A transaction plus its signature(s) is called a transaction envelope.
 
-A transaction may need more than one signature- this happens if it has operations that affect more than one account or if it has a high threshold weight. Check out the [Signature and Multisignature Encyclopedia Entry](../../encyclopedia/signatures-multisig) for more information.
+A transaction may need more than one signature- this happens if it has operations that affect more than one account or if it has a high threshold weight. Check out the [Signature and Multisignature Encyclopedia Entry](../../encyclopedia/signatures-multisig.mdx) for more information.
 
 Transactions are atomic. Meaning if one operation in a transaction fails, all operations fail, and the entire transaction is not applied to the ledger.
 
 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`. Read more in the [Soroban docs](https://soroban.stellar.org/docs/fundamentals-and-concepts/interacting-with-contracts#transaction-simulation).
+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`. Read more in the [Soroban docs](https://soroban.stellar.org/docs/fundamentals-and-concepts/interacting-with-contracts#transaction-simulation.mdx).
 
 #### Transaction attributes
 
 - [Fee](../fees-resource-limits-metering.mdx)
-- [List of operations](../list-of-operations)
-- [List of signatures](../../encyclopedia/signatures-multisig)
-- [Memo or muxed account](../../encyclopedia/pooled-accounts-muxed-accounts-memos)
-- [Sequence number](../../glossary#sequence-number)
-- [Source account](../../glossary#source-account)
+- [List of operations](../list-of-operations.mdx)
+- [List of signatures](../../encyclopedia/signatures-multisig.mdx)
+- [Memo or muxed account](../../encyclopedia/pooled-accounts-muxed-accounts-memos.mdx)
+- [Sequence number](../../glossary.mdx#sequence-number)
+- [Source account](../../glossary.mdx#source-account)
 - [Preconditions (optional)](#preconditions)
 
 ## Transaction and operation validity
@@ -131,7 +131,7 @@ The fee must be greater than or equal to the network minimum fee for the number
 
 #### Fee-bump (if applicable)
 
-See Validity of a [Fee-Bump Transaction section](../../encyclopedia/fee-bump-transactions#validity-of-a-fee-bump-transaction)
+See Validity of a [Fee-Bump Transaction section](../../encyclopedia/fee-bump-transactions.mdx#validity-of-a-fee-bump-transaction)
 
 #### Sequence number
 
diff --git a/docs/learn/glossary.mdx b/docs/learn/glossary.mdx
index 21c45117f..6bafe3dbf 100644
--- a/docs/learn/glossary.mdx
+++ b/docs/learn/glossary.mdx
@@ -27,7 +27,7 @@ A software program designed for users to carry out a specific task (other than o
 
 Fiat, physical, or other tokens of value that are tracked, held, or transferred by the Stellar distributed network.
 
-See the [Assets section](./fundamentals/stellar-data-structures/assets) to learn more.
+See the [Assets section](./fundamentals/stellar-data-structures/assets.mdx) to learn more.
 
 ### Balance
 
@@ -49,7 +49,7 @@ Learn more in our [Fees section](./fundamentals/fees-resource-limits-metering.md
 
 A unit of measurement used to calculate an account’s minimum balance. One base reserve is currently 0.5 XLM.
 
-Learn more in our [Lumens section](./fundamentals/lumens#base-reserves).
+Learn more in our [Lumens section](./fundamentals/lumens.mdx#base-reserves).
 
 ### Burn
 
@@ -89,7 +89,7 @@ A payment that automatically handles the conversion of dissimilar assets.
 
 A distributed exchange that allows the trading and conversion of assets on the network.
 
-Learn more in our [Liquidity on Stellar](./encyclopedia/liquidity-on-stellar-sdex-liquidity-pools#sdex) Encyclopedia Entry.
+Learn more in our [Liquidity on Stellar](./encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx#sdex) Encyclopedia Entry.
 
 ### External Data Representation (XDR)
 
@@ -133,7 +133,7 @@ An encrypted store or file that serves as a repository of private keys, certific
 
 A representation of the state of the Stellar universe at a given point in time, shared across all network nodes.
 
-Learn more in the [Ledgers section](./fundamentals/stellar-data-structures/ledgers).
+Learn more in the [Ledgers section](./fundamentals/stellar-data-structures/ledgers.mdx).
 
 ### LedgerKey
 
@@ -147,7 +147,7 @@ A buying or selling obligation, required to satisfy (selling) or accommodate (bu
 
 The native, built-in token on the Stellar network.
 
-Learn more about lumens in our [Lumens section](./fundamentals/lumens).
+Learn more about lumens in our [Lumens section](./fundamentals/lumens.mdx).
 
 ### Master key
 
@@ -157,7 +157,7 @@ The private key used in initial account creation.
 
 The smallest permissible balance in lumens for a Stellar account, currently 1 lumen.
 
-Learn more in our [Lumens section](./fundamentals/lumens#minimum-balance).
+Learn more in our [Lumens section](./fundamentals/lumens.mdx#minimum-balance).
 
 ### Network capacity
 
@@ -171,7 +171,7 @@ The number of entries owned by an account, used to calculate the account’s min
 
 An individual command that modifies the ledger.
 
-Learn more in our [Operations and Transactions](./fundamentals/stellar-data-structures/operations-and-transactions) section.
+Learn more in our [Operations and Transactions](./fundamentals/stellar-data-structures/operations-and-transactions.mdx) section.
 
 ### OperationID
 
@@ -181,13 +181,13 @@ Contains the transaction source account, sequence number, and the operation inde
 
 An offer to buy or sell an asset.
 
-Learn more in our [Liquidity on Stellar: SDEX and Liquidity Pools Encyclopedia Entry](./encyclopedia/liquidity-on-stellar-sdex-liquidity-pools#orders).
+Learn more in our [Liquidity on Stellar: SDEX and Liquidity Pools Encyclopedia Entry](./encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx#orders).
 
 ### Orderbook
 
 A record of outstanding orders on the Stellar network.
 
-Learn more in our [Liquidity on Stellar: SDEX and Liquidity Pools Encyclopedia Entry](./encyclopedia/liquidity-on-stellar-sdex-liquidity-pools#order-books).
+Learn more in our [Liquidity on Stellar: SDEX and Liquidity Pools Encyclopedia Entry](./encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx#order-books).
 
 ### Passive order
 
@@ -197,7 +197,7 @@ An order that does not execute against a marketable counter order with the same
 
 The Mainnet and Testnet each have their own unique passphrase, which are used to validate signatures on a given transaction.
 
-Learn more about network passphrases in the [Network Passphrases Encyclopedia Entry](./encyclopedia/network-passphrases).
+Learn more about network passphrases in the [Network Passphrases Encyclopedia Entry](./encyclopedia/network-passphrases.mdx).
 
 ### Pathfinding
 
@@ -211,7 +211,7 @@ Allows two parties who frequently transact with one another to move the bulk of
 
 Optional requirements you can add to control a transaction’s validity.
 
-See the [Operation and Transaction Validity section](./fundamentals/stellar-data-structures/operations-and-transactions#preconditions) for more information.
+See the [Operation and Transaction Validity section](./fundamentals/stellar-data-structures/operations-and-transactions.mdx#preconditions) for more information.
 
 ### Price
 
@@ -225,7 +225,7 @@ The public part of a keypair that identifies a Stellar account. The public key i
 
 The Stellar Public Network, aka mainnet, the main network used by applications in production.
 
-Read more in our [Networks section](./fundamentals/networks).
+Read more in our [Networks section](./fundamentals/networks.mdx).
 
 ### Rate-limiting
 
@@ -245,13 +245,13 @@ The private key is part of a keypair, which is associated with an account. Do no
 
 Standards and protocols to allow the Stellar ecosystem to interoperate.
 
-Learn more in our [SEPs section](./fundamentals/stellar-ecosystem-proposals).
+Learn more in our [SEPs section](./fundamentals/stellar-ecosystem-proposals.mdx).
 
 ### Signer
 
 Refers to the master key or to any other signing keys added later. A signer is defined as the pair: public key + weight. Signers can be set with the Set Options operation.
 
-See our [Signature and Multisignature Encyclopedia Entry](./encyclopedia/signatures-multisig) for more information.
+See our [Signature and Multisignature Encyclopedia Entry](./encyclopedia/signatures-multisig.mdx) for more information.
 
 ### Smart contract
 
@@ -277,7 +277,7 @@ A decentralized, federated peer-to-peer network that allows people to send payme
 
 Provides a way to reach consensus without relying on a closed system to accurately record financial transactions.
 
-See our [SCP section](./fundamentals/stellar-consensus-protocol) to learn more.
+See our [SCP section](./fundamentals/stellar-consensus-protocol.mdx) to learn more.
 
 ### Stellar Core
 
@@ -299,7 +299,7 @@ As cents are to dollars, stroops are to assets: the smallest unit of an asset, o
 
 The Stellar Test Network is maintained by the Stellar Development Foundation, which developers can use to test applications. Testnet is free to use and provides the same functionality as the main (public) network.
 
-Read more in our [Networks](./fundamentals/networks).
+Read more in our [Networks](./fundamentals/networks.mdx).
 
 ### Threshold
 
@@ -307,21 +307,21 @@ The level of access for an operation.
 
 Also used to describe the ratio of validator nodes in a quorum set that must agree in order to reach consensus as part of the Stellar Consensus Protocol.
 
-Read more about operation thresholds in the [Operations and Transactions section](./fundamentals/stellar-data-structures/operations-and-transactions#operations).
+Read more about operation thresholds in the [Operations and Transactions section](./fundamentals/stellar-data-structures/operations-and-transactions.mdx#operations).
 
-Learn more about quorum set validators in our [Stellar Consensus Protocol section](./fundamentals/stellar-consensus-protocol).
+Learn more about quorum set validators in our [Stellar Consensus Protocol section](./fundamentals/stellar-consensus-protocol.mdx).
 
 ### Time bounds
 
 An optional feature you can apply to a transaction to enforce a time limit on the transaction; either the transaction makes it to the ledger or times out (fails) depending on your time parameters.
 
-Read more about time bounds in our [Operation and Transaction Validity section](./fundamentals/stellar-data-structures/operations-and-transactions#transaction-and-operation-validity).
+Read more about time bounds in our [Operation and Transaction Validity section](./fundamentals/stellar-data-structures/operations-and-transactions.mdx#transaction-and-operation-validity).
 
 ### Transaction
 
 A group of 1 to 100 operations that modify the ledger state.
 
-Read more in the [Operations and Transactions section](./fundamentals/stellar-data-structures/operations-and-transactions#transactions).
+Read more in the [Operations and Transactions section](./fundamentals/stellar-data-structures/operations-and-transactions.mdx#transactions).
 
 ### Transaction envelope
 
@@ -331,13 +331,13 @@ A wrapper for a transaction that carries signatures.
 
 Stellar requires a small fee for all transactions to prevent ledger spam and prioritize transactions during surge pricing.
 
-Learn more in our [Lumens section](./fundamentals/lumens#transaction-fees).
+Learn more in our [Lumens section](./fundamentals/lumens.mdx#transaction-fees).
 
 ### Trustline
 
 An explicit opt-in for an account to hold a particular asset that tracks liabilities, the balance of the asset, and can also limit the amount of an asset that an account can hold.
 
-Learn more in our [Accounts section](./fundamentals/stellar-data-structures/accounts#trustlines).
+Learn more in our [Accounts section](./fundamentals/stellar-data-structures/accounts.mdx#trustlines).
 
 ### TTL (Time To Live)
 
diff --git a/docs/learn/interactive/quest.mdx b/docs/learn/interactive/quest.mdx
index bc69f442c..c5bdabda5 100644
--- a/docs/learn/interactive/quest.mdx
+++ b/docs/learn/interactive/quest.mdx
@@ -5,6 +5,6 @@ sidebar_position: 10
 
 Stellar Quest teaches you about Stellar operations and fundamentals in a gamified experience. It includes three sets of five quests along with an additional three side quests (fee-bumps, minting NFTs, and muxed accounts) and a pioneer quest that teaches you about setting up a wallet.
 
-Stellar Quest can be played by using [the Laboratory](https://laboratory.stellar.org/#?network=public) for non-coders or by using manual code.
+Stellar Quest can be played by using [the Laboratory](https://laboratory.stellar.org/#?network=test) for non-coders or by using manual code.
 
 Learn more and play the games by going to the [Stellar Quest site](https://quest.stellar.org)!
diff --git a/docs/learn/migrate/evm/introduction-to-solidity-and-rust.mdx b/docs/learn/migrate/evm/introduction-to-solidity-and-rust.mdx
index 320f8a34d..98c174500 100644
--- a/docs/learn/migrate/evm/introduction-to-solidity-and-rust.mdx
+++ b/docs/learn/migrate/evm/introduction-to-solidity-and-rust.mdx
@@ -6,11 +6,11 @@ description: Explore the fundamentals of Solidity, Rust, and Soroban.
 
 # Introduction
 
-We are excited to introduce you to [Soroban](https://soroban.stellar.org/docs), a powerful smart contracts platform designed to be sensible, built-to-scale, and developer-friendly, with a focus on Rust's performance and safety benefits. With its user-friendly interface and powerful features, Soroban offers an ideal platform for developers who are seeking a more efficient and effective way to build decentralized applications and transition from Solidity to Rust. In this article, we will explore the fundamentals of Solidity, Rust, and Soroban, and guide you through setting up the development environment to start your journey with Soroban's Rust smart contract compatibility.
+We are excited to introduce you to Soroban, a powerful smart contracts platform designed to be sensible, built-to-scale, and developer-friendly, with a focus on Rust's performance and safety benefits. With its user-friendly interface and powerful features, Soroban offers an ideal platform for developers who are seeking a more efficient and effective way to build decentralized applications and transition from Solidity to Rust. In this article, we will explore the fundamentals of Solidity, Rust, and Soroban, and guide you through setting up the development environment to start your journey with Soroban's Rust smart contract compatibility.
 
-## Solidity and dApp Development
+## Solidity and Dapp Development
 
-Solidity is a high-level, statically-typed programming language primarily used for developing smart contracts on the Ethereum Virtual Machine (EVM). It enables the creation of decentralized applications (dApps) that can run on various blockchain platforms, automating complex transactions and interactions without the need for a central authority.
+Solidity is a high-level, statically-typed programming language primarily used for developing smart contracts on the Ethereum Virtual Machine (EVM). It enables the creation of decentralized applications (dapps) that can run on various blockchain platforms, automating complex transactions and interactions without the need for a central authority.
 
 ## Rust: Performance and Safety
 
@@ -20,11 +20,11 @@ Rust is a systems programming language that emphasizes safety, concurrency, and
 
 Soroban, a sensible and built-to-scale smart contracts platform, offers a developer-friendly and batteries-included experience. While it shares the same principles of scalability and practicality as Stellar, Soroban can also function as a standalone platform and integrate with other transaction processors, such as L2s, permissioned ledgers, and even other blockchains. With Soroban, Classic Stellar gains the added functionality of programmable logic in the form of custom operations encapsulated within smart contracts.
 
-You can learn more about Soroban's features and benefits in the [Soroban Welcome Page](https://soroban.stellar.org/docs).
+You can learn more about Soroban's features and benefits in the [Soroban Overview](../../../smart-contracts).
 
 ## Setting Up the Development Environment for Rust and Soroban
 
-To get started with Rust and Soroban, follow the steps on the [Setup Page](https://soroban.stellar.org/docs/getting-started/setup).
+To get started with Rust and Soroban, follow the steps on the [Setup Page](../../../smart-contracts/getting-started/setup.mdx).
 
 Or if you want to jump right in, you can open up our examples in a ready to go dev Environment in Gitpod by clicking the button below:
 
diff --git a/docs/learn/migrate/evm/smart-contract-deployment.mdx b/docs/learn/migrate/evm/smart-contract-deployment.mdx
index 4d9f38eb2..15f1c99e9 100644
--- a/docs/learn/migrate/evm/smart-contract-deployment.mdx
+++ b/docs/learn/migrate/evm/smart-contract-deployment.mdx
@@ -9,7 +9,7 @@ import TabItem from "@theme/TabItem";
 
 # Smart Contract Development with Soroban and Hardhat
 
-In this tutorial, we will discover the similarities in smart contract deployment by examining workflows with [Soroban](https://soroban.stellar.org/docs) and [Hardhat](https://hardhat.org/). We will dive into the intricacies of each framework, learn to write secure and efficient smart contract code, and harness the power of Rust and Soroban to create customized contract logic.
+In this tutorial, we will discover the similarities in smart contract deployment by examining workflows with Soroban and [Hardhat](https://hardhat.org/). We will dive into the intricacies of each framework, learn to write secure and efficient smart contract code, and harness the power of Rust and Soroban to create customized contract logic.
 
 ## Table of Contents
 
@@ -26,7 +26,7 @@ Soroban and Hardhat are both frameworks that enable developers to build, test, a
 
 ### Soroban Framework
 
-Soroban is a Rust-based framework tailored for developing smart contracts on the Stellar network. Designed as a lightweight framework, with [tools to support developers](https://developers.stellar.org/docs/tools/developer-tools#soroban-cli), Soroban allows developers to develop smart contracts through a simple and intuitive workflow.
+Soroban is a Rust-based framework tailored for developing smart contracts on the Stellar network. Designed as a lightweight framework, with [tools to support developers](../../../tools/developer-tools.mdx), Soroban allows developers to develop smart contracts through a simple and intuitive workflow.
 
 ### Hardhat
 
@@ -44,7 +44,7 @@ Soroban, with its lightweight design, offers developers an exceptional platform
 
 Hardhat offers a streamlined workflow for deploying smart contracts on the Ethereum Virtual Machine, with key components such as `ethers.js`, `scripts`, and `testing` playing crucial roles.
 
-On the other hand, Soroban presents a compelling alternative, boasting powerful SDKs that facilitate smart contract development and deployment. In the upcoming section, we will delve into [Soroban's SDKs](https://developers.stellar.org/docs/tools/sdks), drawing comparisons with Hardhat components, and highlighting the unique advantages each platform brings to the table.
+On the other hand, Soroban presents a compelling alternative, boasting powerful SDKs that facilitate smart contract development and deployment. In the upcoming section, we will delve into [Soroban's SDKs](../../../tools/sdks/library.mdx), drawing comparisons with Hardhat components, and highlighting the unique advantages each platform brings to the table.
 
 ### Ethers.js
 
@@ -62,7 +62,7 @@ async function main() {
 
 ### Soroban Client
 
-Soroban offers a comparable library, [`stellar-sdk`](https://developers.stellar.org/docs/tools/sdks/library#javascript-sdk), that enables seamless interaction smart contracts deployed on the Stellar Network. This library supplies a comprehensive networking layer API for Soroban RPC methods as well as the traditional Horizon API, simplifying the process of building and signing transactions. Additionally, `stellar-sdk` streamlines communication with RPC instances and supports submitting transactions or querying network state with ease.
+Soroban offers a comparable library, [`stellar-sdk`](../../../tools/sdks/library.mdx#javascript-sdk), that enables seamless interaction smart contracts deployed on the Stellar Network. This library supplies a comprehensive networking layer API for Soroban RPC methods as well as the traditional Horizon API, simplifying the process of building and signing transactions. Additionally, `stellar-sdk` streamlines communication with RPC instances and supports submitting transactions or querying network state with ease.
 
 ### Scripts
 
@@ -89,7 +89,7 @@ main()
 
 ### Soroban Scripts
 
-Soroban offers an extensive collection of SDKs that include scripting capabilities, ensuring a smooth workflow for deploying and managing smart contracts. Developers can automate tasks such as compiling, deploying, and interacting with smart contracts using a variety of SDKs that support scripting in languages like [`JavaScript`, `TypeScript`, `Python`, and others](https://developers.stellar.org/docs/tools/sdks).
+Soroban offers an extensive collection of SDKs that include scripting capabilities, ensuring a smooth workflow for deploying and managing smart contracts. Developers can automate tasks such as compiling, deploying, and interacting with smart contracts using a variety of SDKs that support scripting in languages like [`JavaScript`, `TypeScript`, `Python`, and others](../../../tools/sdks/library.mdx).
 
 ```python
 # This example shows how to deploy a compiled contract to the Stellar network.
@@ -185,7 +185,7 @@ We've learned that Smart contracts are self-executing contracts that can be prog
 
 ### Setup
 
-If you haven't already setup up the dev environment for Soroban, you can get started by following the steps on the [Setup Page](https://soroban.stellar.org/docs/getting-started/setup).
+If you haven't already setup up the dev environment for Soroban, you can get started by following the steps on the [Setup Page](../../../smart-contracts/getting-started/setup.mdx).
 
 This project requires using the `soroban_token_contract.wasm` file which you will need to import manually.
 
diff --git a/docs/learn/migrate/evm/solidity-and-rust-basics.mdx b/docs/learn/migrate/evm/solidity-and-rust-basics.mdx
index 3ebda4ce9..2369bf824 100644
--- a/docs/learn/migrate/evm/solidity-and-rust-basics.mdx
+++ b/docs/learn/migrate/evm/solidity-and-rust-basics.mdx
@@ -455,7 +455,7 @@ impl IncrementContract {
 }
 ```
 
-This code is an implementation of a smart contract written in Rust using the [`Soroban Rust SDK`](https://developers.stellar.org/docs/tools/sdks/library#soroban-rust-sdk), a Rust-based smart contract development toolkit developed by the [Stellar Development Foundation (SDF)](https://stellar.org/foundation). The Soroban Rust SDK provides a powerful set of tools for writing smart contracts that run on the Soroban Virtual Machine.
+This code is an implementation of a smart contract written in Rust using the [`Soroban Rust SDK`](../../../tools/sdks/library.mdx#soroban-rust-sdk), a Rust-based smart contract development toolkit developed by the [Stellar Development Foundation (SDF)](https://stellar.org/foundation). The Soroban Rust SDK provides a powerful set of tools for writing smart contracts that run on the Soroban Virtual Machine.
 
 Here's a line-by-line explanation of what the code is doing:
 
@@ -541,7 +541,7 @@ env.storage().instance().get(&COUNTER).unwrap_or(0)
 
 This is a repeat of the code we saw earlier, which retrieves the value associated with the key `COUNTER` from the contract storage. If there is no value set for the key `COUNTER`, a default value of 0 is used. Finally, the `unwrap()` method is called to extract the actual value from the `Ok` wrapper, which is then returned to the caller of the function.
 
-Now that we have written our smart contract, it's time to explore how we can interact with it using the [Soroban-CLI](https://developers.stellar.org/docs/tools/developer-tools#soroban-cli), one of many robust [Developer Tools](https://developers.stellar.org/docs/tools/developer-tools) available. This powerful command-line tool allows us to interact with the Soroban Virtual Machine from a local machine, providing us with an efficient and flexible way to manage our smart contract.
+Now that we have written our smart contract, it's time to explore how we can interact with it using the [Soroban-CLI](../../../tools/developer-tools.mdx#cli), one of many robust [Developer Tools](../../../tools/developer-tools.mdx) available. This powerful command-line tool allows us to interact with the Soroban Virtual Machine from a local machine, providing us with an efficient and flexible way to manage our smart contract.
 
 ### Interacting with the Rust Smart Counter
 
@@ -595,7 +595,7 @@ inherits = "release"
 debug-assertions = true
 ```
 
-> _Note_: For a detailed explanation of the `Cargo.toml` configuration used in this tutorial, check out the [Hello World Example](https://soroban.stellar.org/docs/getting-started/hello-world#import-soroban-sdk-and-features).
+> _Note_: For a detailed explanation of the `Cargo.toml` configuration used in this tutorial, check out the [Hello World Example](../../../smart-contracts/getting-started/hello-world.mdx).
 
 Next, build the project using the `soroban contract build` command.
 
diff --git a/docs/learn/smart-contract-internals/authorization.mdx b/docs/learn/smart-contract-internals/authorization.mdx
index 58ccd023a..909762d86 100644
--- a/docs/learn/smart-contract-internals/authorization.mdx
+++ b/docs/learn/smart-contract-internals/authorization.mdx
@@ -38,9 +38,7 @@ We realize that it's not possible to cover each and every case, but we hope that
 
 #### Contract storage
 
-Contracts have an exclusive read and write access to their [storage] in the ledger. This allows contracts to safely control and manage user access to their data. For example, a token contract may ensure that only the administrator can mint more of the token by storing the administrator identity in its storage. Similarly, it can make sure that only an owner of the balance may transfer that balance.
-
-[storage]: https://soroban.stellar.org/docs/getting-started/storing-data
+Contracts have an exclusive read and write access to their [storage](../../smart-contracts/getting-started/storing-data.mdx) in the ledger. This allows contracts to safely control and manage user access to their data. For example, a token contract may ensure that only the administrator can mint more of the token by storing the administrator identity in its storage. Similarly, it can make sure that only an owner of the balance may transfer that balance.
 
 #### `Address`
 
diff --git a/docs/learn/smart-contract-internals/contract-interactions/stellar-transaction.mdx b/docs/learn/smart-contract-internals/contract-interactions/stellar-transaction.mdx
index 98d21a2ea..18ddfd7e2 100644
--- a/docs/learn/smart-contract-internals/contract-interactions/stellar-transaction.mdx
+++ b/docs/learn/smart-contract-internals/contract-interactions/stellar-transaction.mdx
@@ -25,7 +25,7 @@ import TabItem from "@theme/TabItem";
 
 ## Example SDK Usage
 
-Some (but not all yet) of the Stellar SDKs have functions built-in to handle most of the process of building a Stellar transaction to interact with a Soroban smart contract. Below, we demonstrate in JavaScript and Python how to build and submit a Stellar transaction that will invoke an instance of the [increment example](https://soroban.stellar.org/docs/getting-started/storing-data) smart contract.
+Some (but not all yet) of the Stellar SDKs have functions built-in to handle most of the process of building a Stellar transaction to interact with a Soroban smart contract. Below, we demonstrate in JavaScript and Python how to build and submit a Stellar transaction that will invoke an instance of the [increment example](../../../smart-contracts/getting-started/storing-data.mdx) smart contract.
 
 <Tabs>
 <TabItem value="js" label="JavaScript">
@@ -382,7 +382,7 @@ The `InvokeHostFunctionOp` can be used to perform the following Soroban operatio
 
 - Invoke contract functions.
 - Upload Wasm of the new contracts.
-- Deploy new contracts using the uploaded Wasm or built-in implementations (this currently includes only the [token contract](https://soroban.stellar.org/docs/tokens/stellar-asset-contract)).
+- Deploy new contracts using the uploaded Wasm or built-in implementations (this currently includes only the [token contract](../../../smart-contracts/tokens/stellar-asset-contract.mdx)).
 
 [`soroban-cli`]: https://soroban.stellar.org/docs/getting-started/setup#install-the-soroban-cli
 
@@ -503,11 +503,11 @@ The `hostFunction` in `InvokeHostFunctionOp` will be executed by the Soroban hos
 
 ##### JavaScript Usage
 
-Each of these variations of host function invocation has convenience methods in the [JavaScript SDK](https://developers.stellar.org/docs/tools/sdks/library#javascript-sdk):
+Each of these variations of host function invocation has convenience methods in the [JavaScript SDK](../../../tools/sdks/library.mdx#javascript-sdk):
 
 - [`Operation.invokeHostFunction`](https://stellar.github.io/js-stellar-sdk/Operation.html#.invokeHostFunction) is the lowest-level method that corresponds directly to the XDR.
 - [`Operation.invokeContractFunction`](https://stellar.github.io/js-stellar-sdk/Operation.html#.invokeContractFunction) is an abstraction to invoke the method of a particular contract, similar to [`Contract.call`](https://stellar.github.io/js-stellar-sdk/Contract.html#call).
-- [`Operation.createStellarAssetContract`](https://stellar.github.io/js-stellar-sdk/Operation.html#.createStellarAssetContract) and [`Operation.createCustomContract`](https://stellar.github.io/js-stellar-sdk/Operation.html#.createCustomContract) are abstractions to instantiate contracts: the former is for wrapping an existing [Stellar asset](https://developers.stellar.org/docs/issuing-assets/how-to-issue-an-asset) into a smart contract and the latter is for deploying your own contract.
+- [`Operation.createStellarAssetContract`](https://stellar.github.io/js-stellar-sdk/Operation.html#.createStellarAssetContract) and [`Operation.createCustomContract`](https://stellar.github.io/js-stellar-sdk/Operation.html#.createCustomContract) are abstractions to instantiate contracts: the former is for wrapping an existing [Stellar asset](../../../issuing-assets/how-to-issue-an-asset.mdx) into a smart contract and the latter is for deploying your own contract.
 - [`Operation.uploadContractWasm`](https://stellar.github.io/js-stellar-sdk/Operation.html#.uploadContractWasm) corresponds to the above `HOST_FUNCTION_TYPE_UPLOAD_CONTRACT_WASM` variant, letting you upload the raw WASM buffer to the ledger.
 
 #### Authorization Data
diff --git a/docs/learn/smart-contract-internals/contract-lifecycle.mdx b/docs/learn/smart-contract-internals/contract-lifecycle.mdx
index a7d60c3bb..2100c8a3c 100644
--- a/docs/learn/smart-contract-internals/contract-lifecycle.mdx
+++ b/docs/learn/smart-contract-internals/contract-lifecycle.mdx
@@ -59,4 +59,4 @@ TBD: expand this section.
 
 ## Upgrading contracts
 
-See the [Upgrading Contracts](https://soroban.stellar.org/docs/guides/conventions/upgrading-contracts) page for details on this.
+See the [Upgrading Contracts page](../../smart-contracts/guides/conventions/upgrading-contracts.mdx) for details on this.
diff --git a/docs/learn/smart-contract-internals/rust-dialect.mdx b/docs/learn/smart-contract-internals/rust-dialect.mdx
index 299f3a990..645500f6b 100644
--- a/docs/learn/smart-contract-internals/rust-dialect.mdx
+++ b/docs/learn/smart-contract-internals/rust-dialect.mdx
@@ -23,7 +23,7 @@ For this reason it makes sense to consider code written for contracts to be a _d
 
 These constraints and priorities are _similar_ to those encountered when writing Rust code for "embedded systems", and the tools, libraries and techniques used in the "contract dialect" are frequently borrowed from the [Rust embedded systems community](https://docs.rust-embedded.org/book/index.html), and by default contracts are recommended to be built with the [`#[no_std]` mode](https://docs.rust-embedded.org/book/intro/no-std.html) that excludes the Rust standard library entirely, relying on the smaller underlying `core` library instead.
 
-Note: these constraints and priorities are **not enforced when building in local-testing mode**, and in fact local contract tests will _frequently_ use facilities -- to generate test input, inspect test output, and guide testing -- that are not supported in the deployment guest environment. Developers **must understand** the difference between code that is compiled-in to Wasm modules for deployment and code that is conditionally compiled for testing. See [debugging contracts](debugging) for more details.
+Note: these constraints and priorities are **not enforced when building in local-testing mode**, and in fact local contract tests will _frequently_ use facilities -- to generate test input, inspect test output, and guide testing -- that are not supported in the deployment guest environment. Developers **must understand** the difference between code that is compiled-in to Wasm modules for deployment and code that is conditionally compiled for testing. See [debugging contracts](./debugging.mdx) for more details.
 
 The "contract dialect" has the following characteristics:
 
diff --git a/docs/learn/smart-contract-internals/state-archival.mdx b/docs/learn/smart-contract-internals/state-archival.mdx
index 6912c9d6b..18b5ee177 100644
--- a/docs/learn/smart-contract-internals/state-archival.mdx
+++ b/docs/learn/smart-contract-internals/state-archival.mdx
@@ -19,7 +19,7 @@ Contract data is made up of three different types: `Persistent`, `Temporary`, an
 All contract data has a Time To Live (TTL) that must be periodically extended. If an entry's TTL is not periodically extended, the entry's TTL will eventually go to 0 and either become "archived" or permanently deleted depending on the storage type. Each type of storage functions similarly, but has different fees and archival behavior:
 
 - When a `Temporary` entry's TTL is 0, it is deleted from the ledger and is permanently inaccessible.
-- When a `Persistent` or `Instance` entry TTL is 0, it becomes inaccessible and is "archived", but can be "restored" and used again via the [`RestoreFootprintOp`].
+- When a `Persistent` or `Instance` entry TTL is 0, it becomes inaccessible and is "archived", but can be "restored" and used again via the [`RestoreFootprintOp`](#restorefootprintop).
 
 ## Contract Data Type Descriptions
 
@@ -35,7 +35,7 @@ The general usage and interface are identical for all storage types. They differ
 ### `Instance`
 
 - Most expensive fees (same price as `Persistent` storage).
-- Archived when TTL goes to 0, can be restored using the [`RestoreFootprintOp`] operation.
+- Archived when TTL goes to 0, can be restored using the [`RestoreFootprintOp`](#restorefootprintop) operation.
 - Shares the same TTL as the contract instance. If the contract instance has not been archived, instance data is guaranteed to be accessible and not archived.
 - Limited amount of storage available.
 - Suitable for "shared" contract state that cannot be `Temporary` (i.e. admin accounts, contract metadata, etc.).
@@ -43,7 +43,7 @@ The general usage and interface are identical for all storage types. They differ
 ### `Persistent`
 
 - Most expensive fees (same price as `Instance` storage).
-- Archived when TTL goes to 0, can be restored using the [`RestoreFootprintOp`] operation.
+- Archived when TTL goes to 0, can be restored using the [`RestoreFootprintOp`](#restorefootprintop) operation.
 - Does not share the same TTL as the contract instance. If the contract instance is not archived, `Persistent` data may be archived and need to be restored before invoking the contract.
 - Unlimited amount of storage.
 - Suitable for user data that cannot be `Temporary` (i.e. balances).
@@ -67,7 +67,7 @@ All `Instance` storage is stored in a single contract instance `LedgerEntry` and
 
 A call to `extend_ttl(N)` ensures that the current TTL of the contract instance entry is _at least_ N ledgers. For example, if `extend_ttl(100)` is called and the contract instance entry has a current TTL of 50 ledgers, the TTL will be extended up to 100 ledgers. If `extend_ttl(100)` is called and the contract instance entry has a current TTL of 150 ledgers, the TTL will not be extended and the `extend_ttl()` call is a no-op.
 
-In addition to contract-defined TTL extensions using the `extend_ttl()` function, a contract data entry's TTL can be extended via the [`ExtendFootprintTTLOp`] operation.
+In addition to contract-defined TTL extensions using the `extend_ttl()` function, a contract data entry's TTL can be extended via the [`ExtendFootprintTTLOp`](#extendfootprintttlop) operation.
 
 ## Terms and Semantics
 
@@ -164,7 +164,7 @@ We've done our best to build tooling around state archival in both the Soroban R
 
 Both restoring and extending the TTL of ledger entries follows a three-step process regardless of their nature (contract data, instances, etc.):
 
-1. **Identify the ledger entries**. This usually means acquiring them from a Soroban RPC server as part of your initial transaction simulation (see the [transaction simulation docs](contract-interactions/transaction-simulation.mdx) and the [`simulateTransaction`](https://developers.stellar.org/platforms/soroban-rpc/methods/simulateTransaction) RPC method).
+1. **Identify the ledger entries**. This usually means acquiring them from a Soroban RPC server as part of your initial transaction simulation (see the [transaction simulation docs](contract-interactions/transaction-simulation.mdx) and the [`simulateTransaction`](../../../network/soroban-rpc/api-reference/methods/simulateTransaction) RPC method).
 
 2. **Prepare your operation**. This means describing the ledger entries within the corresponding operation (i.e. `ExtendFootprintTTLOp` or `RestoreFootprintOp`) and its ledger footprint (the `SorobanTransactionData` field), then simulating it to fill out fee and resource usage information (when restoring, you usually have simulation results already).
 
diff --git a/docs/learn/smart-contract-internals/types/built-in-types.mdx b/docs/learn/smart-contract-internals/types/built-in-types.mdx
index acba112fc..ccc5763a8 100644
--- a/docs/learn/smart-contract-internals/types/built-in-types.mdx
+++ b/docs/learn/smart-contract-internals/types/built-in-types.mdx
@@ -20,7 +20,7 @@ description: Built-in types used as smart contract inputs and outputs.
 Built-in types are available to all contracts for use as contract function inputs and outputs, and are defined by the [environment] and the [Rust SDK].
 
 [environment]: ../environment-concepts.mdx
-[rust sdk]: https://developers.stellar.org/docs/tools/sdks/library#soroban-rust-sdk
+[rust sdk]: ../../../tools/sdks/library.mdx#soroban-rust-sdk
 
 :::tip
 
diff --git a/docs/learn/smart-contract-internals/types/custom-types.mdx b/docs/learn/smart-contract-internals/types/custom-types.mdx
index 8e710f687..e5a5612eb 100644
--- a/docs/learn/smart-contract-internals/types/custom-types.mdx
+++ b/docs/learn/smart-contract-internals/types/custom-types.mdx
@@ -29,7 +29,7 @@ The [custom types example] demonstrates how to define your own types.
 
 :::info
 
-Error enum types are another type contracts can define that have some unique behaviors. See [Errors] for more information. [Errors]: ../errors.mdx
+Error enum types are another type contracts can define that have some unique behaviors. See [Errors](../errors.mdx) for more information.
 
 :::
 
diff --git a/docs/learn/smart-contract-internals/types/fully-typed-contracts.mdx b/docs/learn/smart-contract-internals/types/fully-typed-contracts.mdx
index 58e1295ad..4334e979f 100644
--- a/docs/learn/smart-contract-internals/types/fully-typed-contracts.mdx
+++ b/docs/learn/smart-contract-internals/types/fully-typed-contracts.mdx
@@ -21,11 +21,11 @@ sidebar_label: Fully-Typed Contracts
   />
 </head>
 
-When you compile a contract created with [soroban-sdk](https://developers.stellar.org/docs/tools/sdks/library#soroban-rust-sdk), the Wasm file ends up with a [custom section](https://webassembly.github.io/spec/core/appendix/custom.html) containing a machine-readable description of your contract's interface types, sometimes called its [spec](https://github.com/stellar/rs-soroban-sdk/tree/main/soroban-spec) or its [API](https://github.com/stellar/soroban-docs/pull/381#issuecomment-1507283476). This is similar to [ABIs](https://www.quicknode.com/guides/ethereum-development/smart-contracts/what-is-an-abi/) in Ethereum, except that Soroban will store every single one of them on-chain from day one, and they include the comments from the contract's author.
+When you compile a contract created with [soroban-sdk](../../../tools/sdks/library.mdx#soroban-rust-sdk), the Wasm file ends up with a [custom section](https://webassembly.github.io/spec/core/appendix/custom.html) containing a machine-readable description of your contract's interface types, sometimes called its [spec](https://github.com/stellar/rs-soroban-sdk/tree/main/soroban-spec) or its [API](https://github.com/stellar/soroban-docs/pull/381#issuecomment-1507283476). This is similar to [ABIs](https://www.quicknode.com/guides/ethereum-development/smart-contracts/what-is-an-abi/) in Ethereum, except that Soroban will store every single one of them on-chain from day one, and they include the comments from the contract's author.
 
-Today, these interface types are formatted using [XDR](https://developers.stellar.org/docs/encyclopedia/xdr), but this [may change](https://github.com/stellar/rs-soroban-sdk/issues/683) down the road.
+Today, these interface types are formatted using [XDR](../../encyclopedia/xdr.mdx), but this [may change](https://github.com/stellar/rs-soroban-sdk/issues/683) down the road.
 
-The important part is that tooling can fetch these interface types to make your life easier. [Soroban CLI](https://developers.stellar.org/docs/tools/developer-tools#soroban-cli) is the first tool to do so. Specifically, one subcommand:
+The important part is that tooling can fetch these interface types to make your life easier. [Soroban CLI](../../../tools/developer-tools.mdx#cli) is the first tool to do so. Specifically, one subcommand:
 
 ## `soroban contract invoke`
 
diff --git a/docs/reference/networks.mdx b/docs/reference/networks.mdx
index 2fc05ea13..4f9faabd9 100644
--- a/docs/reference/networks.mdx
+++ b/docs/reference/networks.mdx
@@ -1,7 +1,7 @@
 ---
 sidebar_position: 10
 title: Networks
-description: The shared Soroban test networks.
+description: Specs for Stellar's various networks
 ---
 
 Read more about the different networks in the [Networks section](../learn/fundamentals/networks.mdx).
diff --git a/docs/smart-contracts/example-contracts/TEMPLATE.mdx b/docs/smart-contracts/example-contracts/TEMPLATE.mdx
index e9e8fdb3c..7764f6ae7 100644
--- a/docs/smart-contracts/example-contracts/TEMPLATE.mdx
+++ b/docs/smart-contracts/example-contracts/TEMPLATE.mdx
@@ -11,13 +11,13 @@ Quick note about what this [example demonstrates]. Maybe it's also based on some
 
 :::tip
 
-Place each link definition at the bottom of the section it (first) is used In
+Place each link definition at the bottom of the section it first is used in.
 
 :::
 
 [oigp]: https://gitpod.io/#https://github.com/stellar/soroban-examples/tree/v20.0.0
 [example demonstrates]: https://github.com/stellar/soroban-examples/tree/v20.0.0/hello_world
-[other example]: ../getting-started/
+[other example]: ../getting-started/setup.mdx
 
 ## Run the Example
 
diff --git a/docs/smart-contracts/example-contracts/deployer.mdx b/docs/smart-contracts/example-contracts/deployer.mdx
index 616a86afc..6c02ea80a 100644
--- a/docs/smart-contracts/example-contracts/deployer.mdx
+++ b/docs/smart-contracts/example-contracts/deployer.mdx
@@ -118,7 +118,7 @@ Open the `deployer/deployer/src/lib.rs` file to follow along.
 
 Before deploying the new contract instances, the Wasm code needs to be uploaded on-chain. Then it can be used to deploy an arbitrary number of contract instances. The upload should typically happen outside of the deployer contract, as it needs to happen just once. However, it is possible to use `env.deployer().upload_contract_wasm()` function to upload Wasm from a contract as well.
 
-See the [tests](#tests) for an example of uploading the contract code programmatically. For the actual on-chain installation see the general deployment [tutorial](https://soroban.stellar.org/docs/getting-started/deploy-to-testnet).
+See the [tests](#tests) for an example of uploading the contract code programmatically. For the actual on-chain installation see the general deployment [tutorial](../../smart-contracts/getting-started/deploy-to-testnet.mdx).
 
 ### Authorization
 
@@ -130,7 +130,7 @@ This section can be skipped for factory contracts that deploy another contract f
 
 :::info
 
-For introduction to Soroban authorization see the [auth tutorial](./auth.mdx)
+For introduction to Soroban authorization see the [auth tutorial](./auth.mdx).
 
 :::
 
diff --git a/docs/smart-contracts/example-contracts/events.mdx b/docs/smart-contracts/example-contracts/events.mdx
index e16937837..a07e7899d 100644
--- a/docs/smart-contracts/example-contracts/events.mdx
+++ b/docs/smart-contracts/example-contracts/events.mdx
@@ -250,10 +250,4 @@ The following output should occur using the code above.
 
 A single event `#0` is outputted, which is the contract event the contract published. The event contains the two topics, each a `symbol` (displayed as bytes), and the data object containing the `u32`.
 
-:::info
-
-Soroban is a pre-release and at this time outputs events in an unstable JSON format.
-
-:::
-
 [`soroban-cli`]: ../getting-started/setup.mdx#install-the-soroban-cli
diff --git a/docs/smart-contracts/example-contracts/liquidity-pool.mdx b/docs/smart-contracts/example-contracts/liquidity-pool.mdx
index 78cd28791..d25cfc11a 100644
--- a/docs/smart-contracts/example-contracts/liquidity-pool.mdx
+++ b/docs/smart-contracts/example-contracts/liquidity-pool.mdx
@@ -28,7 +28,7 @@ Soroban liquidity pools are exclusive to Soroban and cannot interact with built-
 
 Implementing a custom liquidity pool should be done cautiously. User funds are involved, so great care should be taken to ensure safety and transparency. The example here should _not_ be considered a ready-to-go contract. Please use it as a reference only.
 
-The Stellar network already has liquidity pool functionality built right in to the core protocol. [Learn more here.](https://developers.stellar.org/docs/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools)
+The Stellar network already has liquidity pool functionality built right in to the core protocol. [Learn more here](../../learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx).
 
 :::
 
@@ -897,4 +897,4 @@ soroban contract invoke \
     --min_b 196 \
 ```
 
-[`soroban-cli`]: https://developers.stellar.org/docs/tools/developer-tools#soroban-cli
+[`soroban-cli`]: ../../tools/developer-tools.mdx#cli
diff --git a/docs/smart-contracts/example-contracts/timelock.mdx b/docs/smart-contracts/example-contracts/timelock.mdx
index d19a6184d..a0f2be581 100644
--- a/docs/smart-contracts/example-contracts/timelock.mdx
+++ b/docs/smart-contracts/example-contracts/timelock.mdx
@@ -27,4 +27,4 @@ The contract accepts deposits of an amount of a token, and allows other users to
 
 [oigp]: https://gitpod.io/#https://github.com/stellar/soroban-examples/tree/v20.0.0
 [timelock example]: https://github.com/stellar/soroban-examples/tree/v20.0.0/timelock
-[claimable balance]: https://developers.stellar.org/docs/glossary/claimable-balance
+[claimable balance]: ../../learn/encyclopedia/claimable-balances.mdx
diff --git a/docs/smart-contracts/example-contracts/tokens.mdx b/docs/smart-contracts/example-contracts/tokens.mdx
index 85f9aea71..e2d709dc6 100644
--- a/docs/smart-contracts/example-contracts/tokens.mdx
+++ b/docs/smart-contracts/example-contracts/tokens.mdx
@@ -999,4 +999,4 @@ soroban contract invoke \
     --id GBZV3NONYSUDVTEHATQO4BCJVFXJO3XQU5K32X3XREVZKSMMOZFO4ZXR
 ```
 
-[`soroban-cli`]: https://developers.stellar.org/docs/tools/developer-tools#soroban-cli
+[`soroban-cli`]: ../../tools/developer-tools.mdx#cli
diff --git a/docs/smart-contracts/getting-started/create-an-app.mdx b/docs/smart-contracts/getting-started/create-an-app.mdx
index 1d9e8e8c5..4ed0916e6 100644
--- a/docs/smart-contracts/getting-started/create-an-app.mdx
+++ b/docs/smart-contracts/getting-started/create-an-app.mdx
@@ -48,7 +48,7 @@ This will add the following to your project, which we'll go over in more detail
 
 ## Generate an NPM package for the Hello World contract
 
-Before we open the new frontend files, let's generate an NPM package for the Hello World contract. This is our suggested way to interact with contracts from frontends. These generated libraries work with any JavaScript project (not a specific UI like React), and make it easy to work with some of the trickiest bits of Soroban, like encoding [XDR](https://soroban.stellar.org/docs/fundamentals-and-concepts/fully-typed-contracts).
+Before we open the new frontend files, let's generate an NPM package for the Hello World contract. This is our suggested way to interact with contracts from frontends. These generated libraries work with any JavaScript project (not a specific UI like React), and make it easy to work with some of the trickiest bits of Soroban, like encoding [XDR](../../learn/smart-contract-internals/types/fully-typed-contracts.mdx).
 
 This is going to use the CLI command `soroban contract bindings typescript`:
 
diff --git a/docs/smart-contracts/guides/cli/README.mdx b/docs/smart-contracts/guides/cli/README.mdx
index 0701827a1..9b25a5692 100644
--- a/docs/smart-contracts/guides/cli/README.mdx
+++ b/docs/smart-contracts/guides/cli/README.mdx
@@ -5,4 +5,4 @@ hide_table_of_contents: true
 
 The [Soroban CLI] is a crucial tool for developers to use while creating and interacting with Soroban smart contracts.
 
-[soroban cli]: https://developers.stellar.org/docs/tools/developer-tools#soroban-cli
+[soroban cli]: ../../../tools/developer-tools.mdx#cli
diff --git a/docs/smart-contracts/guides/cli/deploy-stellar-asset-contract.mdx b/docs/smart-contracts/guides/cli/deploy-stellar-asset-contract.mdx
index 0586ca38d..dbdbfa2c0 100644
--- a/docs/smart-contracts/guides/cli/deploy-stellar-asset-contract.mdx
+++ b/docs/smart-contracts/guides/cli/deploy-stellar-asset-contract.mdx
@@ -47,7 +47,7 @@ soroban contract id asset \
 ```
 
 [stellar asset contract]: ../../tokens/stellar-asset-contract.mdx
-[lumens]: https://developers.stellar.org/docs/fundamentals-and-concepts/lumens
+[lumens]: ../../../learn/fundamentals/lumens.mdx
 [sep-41]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md
 [`soroban_sdk::token`]: https://docs.rs/soroban-sdk/latest/soroban_sdk/token/
 [`token::tokenclient`]: https://docs.rs/soroban-sdk/latest/soroban_sdk/token/struct.TokenClient.html
diff --git a/docs/smart-contracts/guides/conversions/README.mdx b/docs/smart-contracts/guides/conversions/README.mdx
index 011728ee7..f8a95ad6c 100644
--- a/docs/smart-contracts/guides/conversions/README.mdx
+++ b/docs/smart-contracts/guides/conversions/README.mdx
@@ -3,4 +3,4 @@ title: Type Conversions
 hide_table_of_contents: true
 ---
 
-A collection of guides for converting from one data type to another, in a variety of SDK languages.
+A collection of guides for converting from one data type to another in a variety of SDK languages.
diff --git a/docs/smart-contracts/guides/transactions/README.mdx b/docs/smart-contracts/guides/transactions/README.mdx
index 505341787..ce8d6af37 100644
--- a/docs/smart-contracts/guides/transactions/README.mdx
+++ b/docs/smart-contracts/guides/transactions/README.mdx
@@ -5,4 +5,4 @@ hide_table_of_contents: true
 
 The entry point for every smart contract interaction is ultimately a [transaction] on the Stellar network.
 
-[transaction]: https://developers.stellar.org/docs/fundamentals-and-concepts/stellar-data-structures/operations-and-transactions
+[transaction]: ../../../learn/fundamentals/stellar-data-structures/operations-and-transactions.mdx
diff --git a/docs/smart-contracts/tokens/token-interface.mdx b/docs/smart-contracts/tokens/token-interface.mdx
index 12895e488..90f7c0e20 100644
--- a/docs/smart-contracts/tokens/token-interface.mdx
+++ b/docs/smart-contracts/tokens/token-interface.mdx
@@ -20,7 +20,7 @@ For any given contract function, there are 3 requirements that should be consist
 
 ### Code
 
-The interface below uses the Rust [soroban-sdk](https://developers.stellar.org/docs/tools/sdks/library#soroban-rust-sdk) to declare a trait that complies with the [SEP-41](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md) token interface.
+The interface below uses the Rust [soroban-sdk](../../tools/sdks/library.mdx#soroban-rust-sdk) to declare a trait that complies with the [SEP-41](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md) token interface.
 
 ```rust
 pub trait TokenInterface {
diff --git a/docs/tools/developer-tools.mdx b/docs/tools/developer-tools.mdx
index ebdb0734e..22f211ba1 100644
--- a/docs/tools/developer-tools.mdx
+++ b/docs/tools/developer-tools.mdx
@@ -53,7 +53,7 @@ Check data related to payments, accounts, deployed contracts, and more for Stell
 
 The command line interface to Soroban smart contracts. It allows you to build, deploy, and interact with smart contracts; configure identities; generate key pairs; manage networks; and more.
 
-Install Soroban CLI as explained in [Setup](https://soroban.stellar.org/docs/getting-started/setup).
+Install Soroban CLI as explained in [Setup](../smart-contracts/getting-started/setup#install-the-soroban-cli).
 
 Auto-generated comprehensive reference documentation is available [here](https://github.com/stellar/soroban-cli/blob/main/docs/soroban-cli-full-docs.md).
 
diff --git a/docs/tutorials/follow-received-payments.mdx b/docs/tutorials/follow-received-payments.mdx
index 4c8729b4b..537fe9539 100644
--- a/docs/tutorials/follow-received-payments.mdx
+++ b/docs/tutorials/follow-received-payments.mdx
@@ -111,7 +111,7 @@ After a few seconds, the Stellar network will perform consensus, close the ledge
 
 ## Following payments using `curl`
 
-To follow new payments connected to your account you simply need to send the `Accept: text/event-stream` header to the [/payments](https://developers.stellar.org/api/resources/operations/object/payment/) endpoint.
+To follow new payments connected to your account you simply need to send the `Accept: text/event-stream` header to the [/payments](../../network/horizon/api-reference/resources/operations) endpoint.
 
 <CodeExample>
 
@@ -147,7 +147,7 @@ data: {"_links":{"effects":{"href":"/operations/713226564145153/effects/{?cursor
 
 </CodeExample>
 
-Every time you receive a new payment you will get a new row of data. Payments is not the only endpoint that supports streaming. You can also stream transactions [/transactions](https://developers.stellar.org/api/resources/transactions/) and operations [/operations](https://developers.stellar.org/api/resources/operations/).
+Every time you receive a new payment you will get a new row of data. Payments is not the only endpoint that supports streaming. You can also stream transactions [/transactions](../../network/horizon/api-reference/resources/transactions) and operations [/operations](../../network/horizon/api-reference/resources/operations).
 
 ## Following payments using `EventStream`
 
diff --git a/docs/tutorials/send-and-receive-payments.mdx b/docs/tutorials/send-and-receive-payments.mdx
index 57ad05a5b..26e143045 100644
--- a/docs/tutorials/send-and-receive-payments.mdx
+++ b/docs/tutorials/send-and-receive-payments.mdx
@@ -24,7 +24,7 @@ In the following code samples, proper error checking is omitted for brevity. How
 
 ## Send a Payment
 
-Stellar stores and communicates transaction data in a binary format called [XDR](../learn/encyclopedia/xdr.mdx), which is optimized for network performance but unreadable to the human eye. Luckily, [Horizon](https://developers.stellar.org/api), the Stellar API, and the [Stellar SDKs](../tools/sdks/library.mdx) convert XDRs into friendlier formats. Here’s how you might send 10 lumens to an account:
+Stellar stores and communicates transaction data in a binary format called [XDR](../learn/encyclopedia/xdr.mdx), which is optimized for network performance but unreadable to the human eye. Luckily, [Horizon](../../network/horizon), the Stellar API, and the [Stellar SDKs](../tools/sdks/library.mdx) convert XDRs into friendlier formats. Here’s how you might send 10 lumens to an account:
 
 <CodeExample>
 
diff --git a/network/anchor-platform/admin-guide/events/integration.mdx b/network/anchor-platform/admin-guide/events/integration.mdx
index 7ba292805..e5c7b9ef7 100644
--- a/network/anchor-platform/admin-guide/events/integration.mdx
+++ b/network/anchor-platform/admin-guide/events/integration.mdx
@@ -112,7 +112,7 @@ Anchor Platform signs the callback requests it sends to client applications. The
 
 ### As a Business Server
 
-In addition to SEP transaction status updates, business servers can receive events about SEP-31 quote creation or SEP-12 customer information updates. The schema of the event data will depend on the type of event being sent. Visit the [Event API documentation](../../api-reference/callbacks/post-event) for more information about the schema of the event data.
+In addition to SEP transaction status updates, business servers can receive events about SEP-31 quote creation or SEP-12 customer information updates. The schema of the event data will depend on the type of event being sent. Visit the [Event API documentation](../../api-reference/callbacks/post-event.api.mdx) for more information about the schema of the event data.
 
 To receive events as a business server, you will need to expose a callback URL that the event service can send events to. The event service will send a POST request to this endpoint with the event data in the request body.
 
diff --git a/network/anchor-platform/admin-guide/sep31/integration.mdx b/network/anchor-platform/admin-guide/sep31/integration.mdx
index 6fac45be2..e033b7de5 100644
--- a/network/anchor-platform/admin-guide/sep31/integration.mdx
+++ b/network/anchor-platform/admin-guide/sep31/integration.mdx
@@ -679,14 +679,14 @@ This endpoint may be removed during future major version updates of the Anchor P
 [demo-wallet]: https://demo-wallet.stellar.org
 [indicative]: https://www.investopedia.com/terms/i/indicativequote.asp
 [firm]: https://www.investopedia.com/terms/f/firmquote.asp
-[get-unique-address]: ../../api-reference/callbacks/gen-address
-[get-customer]: ../../api-reference/callbacks/get-customer
-[put-customer]: ../../api-reference/callbacks/put-customer
-[get-rate]: ../../api-reference/callbacks/get-rates
-[get-fee]: ../../api-reference/callbacks/get-fee
-[get-unique-address]: ../../api-reference/callbacks/gen-address
-[put-customer-callback]: ../../api-reference/callbacks/put-customer-callback
-[delete-customer]: ../../api-reference/callbacks/del-customer
+[get-unique-address]: ../../api-reference/callbacks/gen-address.api.mdx
+[get-customer]: ../../api-reference/callbacks/get-customer.api.mdx
+[put-customer]: ../../api-reference/callbacks/put-customer.api.mdx
+[get-rate]: ../../api-reference/callbacks/get-rates.api.mdx
+[get-fee]: ../../api-reference/callbacks/get-fee.api.mdx
+[get-unique-address]: ../../api-reference/callbacks/gen-address.api.mdx
+[put-customer-callback]: ../../api-reference/callbacks/put-customer.api.mdx
+[delete-customer]: ../../api-reference/callbacks/del-customer.api.mdx
 [json-rpc-methods]: ../../api-reference/rpc/methods/README.mdx
 [sep24-integration-make-json-rpc-request]: ../sep24/integration.mdx#making-json-rpc-requests
 [sep24-integration-rpc-request]: ../sep24/integration.mdx#json-rpc-request
diff --git a/network/anchor-platform/admin-guide/sep6/integration.mdx b/network/anchor-platform/admin-guide/sep6/integration.mdx
index 5d0720247..d75340763 100644
--- a/network/anchor-platform/admin-guide/sep6/integration.mdx
+++ b/network/anchor-platform/admin-guide/sep6/integration.mdx
@@ -979,4 +979,4 @@ Works in the same manner as for the deposit flow. For more details, see [Transac
 
 <Observer />
 
-[get-transactions]: ../../api-reference/resources/transactions
+[get-transactions]: ../../api-reference/resources/transactions/README.mdx
diff --git a/network/horizon/admin-guide/ingestion-filtering.mdx b/network/horizon/admin-guide/ingestion-filtering.mdx
index 536633cb2..514679c82 100644
--- a/network/horizon/admin-guide/ingestion-filtering.mdx
+++ b/network/horizon/admin-guide/ingestion-filtering.mdx
@@ -22,7 +22,7 @@ Some key aspects to note about filtering behavior:
 - Filtering applies only to ingestion of historical data in the database, it does not affect how ingestion process maintains current state data stored in database, which is the last known ledger entry for each unique entity within accounts, trustlines, liquidity pools, offers. However, current state data consumes a relatively small amount of the overall storage capacity.
 - When filter rules are changed, they only apply to existing, running ingestion processes(**live** and **historical range**). They don't trigger any retro-active filtering or back-filling of existing historical data on the database.
   - When the filter rules are updated to include additional accounts or assets in the white-list, the related transactions from **live** ingestion will only appear in the historical database data once the filter rules have been updated using the Admin API. The same applies to **historical range** ingestion, where the new filter rules will only affect the data from the current ledger within its configured range at the time of the update.
-  - Updating the filter rules to include additional accounts or assets does not trigger automatic back-filling related to new entites in the historical database. To include prior history of newly white-listed entites in the database you can manually run a new [Historical Ingestion Range](ingestion.mdx#ingesting-historical-data) after updating the filter rules.
+  - Updating the filter rules to include additional accounts or assets does not trigger automatic back-filling related to new entites in the historical database. To include prior history of newly white-listed entites in the database you can manually run a new [Historical Ingestion Range](./ingestion.mdx#ingesting-historical-data) after updating the filter rules.
   - When the filter rules are updated to remove accounts or assets previously defined on white-list, the historical data in the database will not be retroactively purged or filtered based on the updated rules. The data is stored in the history tables for the lifetime of the database or until the `HISTORY_RETENTION_COUNT` is exceeded. Once the retention limit is reached, Horizon will purge all historical data related to older ledgers, regardless of any filtering rules.
 - Filtering will not affect the performance or throughput rate of an ingestion process, it will remain consistent whether filter rules are present or not.
 
@@ -93,4 +93,4 @@ curl -X 'PUT' \
 
 2. Since this is new horizon database, and first filter rules, there is nothing more to do, and effectively stop here.
 
-3. However, for sake of exercise, suppose you already had Horizon running for a while and the database populated based on some filter rules, and these new rules were additional white-listings you just added. In this case, you choose whether you want to retro-actively back fill historical data on horizon database for these new white-listed entites from a prior time up to the present time, because they were originally dropped at prior ingestion time and not included on the database. If you decide you want to back fill, then you run a separate Horizon **historical range** ingestion process, refer to [Historical Ingestion Range](ingestion.mdx#ingesting-historical-data) for steps:
+3. However, for sake of exercise, suppose you already had Horizon running for a while and the database populated based on some filter rules, and these new rules were additional white-listings you just added. In this case, you choose whether you want to retro-actively back fill historical data on horizon database for these new white-listed entites from a prior time up to the present time, because they were originally dropped at prior ingestion time and not included on the database. If you decide you want to back fill, then you run a separate Horizon **historical range** ingestion process, refer to [Historical Ingestion Range](./ingestion.mdx#ingesting-historical-data) for steps:
diff --git a/network/horizon/admin-guide/ingestion.mdx b/network/horizon/admin-guide/ingestion.mdx
index a50b44e6b..b2e386964 100644
--- a/network/horizon/admin-guide/ingestion.mdx
+++ b/network/horizon/admin-guide/ingestion.mdx
@@ -23,7 +23,7 @@ To keep your storage footprint small, we recommend the following:
 - Use **live** ingestion, use **historical** ingestion only in limited exceptional cases.
 - If your application requires access to all network data, no filtering can be done, we recommend limiting historical retention of ingested data to a sliding window of 1 month (HISTORY_RETENTION_COUNT=518400) which is default set by Horizon.
 - If your application can work on a [filtered network dataset](./ingestion-filtering.mdx) based on specific accounts and assets, then we recommend applying ingestion filter rules. When using filter rules, it provides benefit of choice in longer historical retention timeframe since the filtering is reducing the overall database size to such a degree, historical retention(`HISTORY_RETENTION_COUNT`) can be set in terms of years rather than months or even disabled(`HISTORY_RETENTION_COUNT=0`).
-- If you cannot limit your history retention window to 30 days and cannot use filter rules, we recommend considering [Stellar Hubble Data Warehouse](https://developers.stellar.org/docs/accessing-data/overview) for any historical data.
+- If you cannot limit your history retention window to 30 days and cannot use filter rules, we recommend considering [Stellar Hubble Data Warehouse](../../hubble/README.mdx) for any historical data.
 
 ### Ingesting Live Data
 
diff --git a/network/horizon/admin-guide/prerequisites.mdx b/network/horizon/admin-guide/prerequisites.mdx
index dd5f99bd6..732273d04 100644
--- a/network/horizon/admin-guide/prerequisites.mdx
+++ b/network/horizon/admin-guide/prerequisites.mdx
@@ -40,7 +40,7 @@ To achieve high availability, redundancy, and high throughput, explore the [scal
 
 - Ensure that the Horizon instance can establish a connection with the PostgreSQL database instance. The default port for PostgreSQL is 5432.
 
-- A stable and fast network connection with the Internet is required for any Horizon instance running the ingestion role. This is to ensure it has efficient outbound connectivity to remote hosts in the [quorum set](https://developers.stellar.org/docs/run-core-node/configuring#choosing-your-quorum-set) and [archive urls](https://developers.stellar.org/docs/run-core-node/configuring#history) for the chosen Stellar network. During ingestion, the Horizon instance communicates with these hosts, receiving network transaction data through its local captive core sub-process.
+- A stable and fast network connection with the Internet is required for any Horizon instance running the ingestion role. This is to ensure it has efficient outbound connectivity to remote hosts in the [quorum set](../../core-node/admin-guide/configuring.mdx#choosing-your-quorum-set) and [archive urls](../../core-node/admin-guide/configuring.mdx#history) for the chosen Stellar network. During ingestion, the Horizon instance communicates with these hosts, receiving network transaction data through its local captive core sub-process.
 
 :::note
 
diff --git a/network/horizon/api-reference/resources/accounts/README.mdx b/network/horizon/api-reference/resources/accounts/README.mdx
index fa2e5e4bb..1e82dc502 100644
--- a/network/horizon/api-reference/resources/accounts/README.mdx
+++ b/network/horizon/api-reference/resources/accounts/README.mdx
@@ -7,7 +7,7 @@ import { EndpointsTable } from "@site/src/components/EndpointsTable";
 
 Users interact with the Stellar network through accounts. Everything else in the ledger—assets, offers, trustlines, etc.—are owned by accounts, and accounts must authorize all changes to the ledger through signed transactions.
 
-Learn more about [accounts](/docs/learn/glossary/#account).
+Learn more about [accounts](../../../../../docs/learn/glossary/#account).
 
 <EndpointsTable title="Endpoints">
 
diff --git a/network/horizon/api-reference/resources/accounts/object.mdx b/network/horizon/api-reference/resources/accounts/object.mdx
index 75f3c19bf..f0a48f193 100644
--- a/network/horizon/api-reference/resources/accounts/object.mdx
+++ b/network/horizon/api-reference/resources/accounts/object.mdx
@@ -24,10 +24,10 @@ When Horizon returns information about an account, it uses the following format:
   - This account's current sequence number. For use when submitting this account's next transaction.
 - sequence_ledger
   - number
-  - The unsigned 32-bit ledger number of the sequence number's [age](/docs/learn/glossary/#sequence-time-and-ledger).
+  - The unsigned 32-bit ledger number of the sequence number's [age](../../../../../docs/learn/glossary/#sequence-number).
 - sequence_time
   - string
-  - The unsigned 64-bit UNIX timestamp of the sequence number's [age](/docs/learn/glossary/#sequence-time-and-ledger).
+  - The unsigned 64-bit UNIX timestamp of the sequence number's [age](../../../../../docs/learn/glossary/#sequence-number).
 - subentry_count
   - number
   - The number of subentries on this account.
@@ -72,7 +72,7 @@ When Horizon returns information about an account, it uses the following format:
       - If set to `true`, this account can freeze the balance of a holder of an asset issued by this account.
     - auth_clawback_enabled
       - boolean
-      - If set to `true`, trustlines created for assets issued by this account have [clawbacks](/docs/learn/glossary#clawback) enabled.
+      - If set to `true`, trustlines created for assets issued by this account have [clawbacks](../../../../../docs/learn/glossary#clawback) enabled.
 - balances
   - object
   - The assets this account holds.
diff --git a/network/horizon/api-reference/resources/assets/README.mdx b/network/horizon/api-reference/resources/assets/README.mdx
index 2b4d52184..359613aa9 100644
--- a/network/horizon/api-reference/resources/assets/README.mdx
+++ b/network/horizon/api-reference/resources/assets/README.mdx
@@ -7,7 +7,7 @@ import { EndpointsTable } from "@site/src/components/EndpointsTable";
 
 Assets are representations of value issued on the Stellar network. An asset consists of a type, code, and issuer.
 
-Learn more about [assets](/docs/learn/glossary/#asset).
+Learn more about [assets](../../../../../docs/learn/glossary/#asset).
 
 <EndpointsTable title="Endpoints">
 
diff --git a/network/horizon/api-reference/resources/ledgers/README.mdx b/network/horizon/api-reference/resources/ledgers/README.mdx
index 8add7183f..d73f4c475 100644
--- a/network/horizon/api-reference/resources/ledgers/README.mdx
+++ b/network/horizon/api-reference/resources/ledgers/README.mdx
@@ -7,7 +7,7 @@ import { EndpointsTable } from "@site/src/components/EndpointsTable";
 
 Each ledger stores the state of the network at a point in time and contains all the changes - transactions, operations, effects, etc. - to that state.
 
-Learn more about [ledgers](/docs/learn/glossary/#ledger).
+Learn more about [ledgers](../../../../../docs/learn/glossary/#ledger).
 
 <EndpointsTable title="Endpoints">
 
diff --git a/network/horizon/api-reference/resources/ledgers/object.mdx b/network/horizon/api-reference/resources/ledgers/object.mdx
index a6bfedf04..fd6f3da5b 100644
--- a/network/horizon/api-reference/resources/ledgers/object.mdx
+++ b/network/horizon/api-reference/resources/ledgers/object.mdx
@@ -21,7 +21,7 @@ When Horizon returns information about a ledger, it uses the following format:
   - A cursor value for use in [pagination](../../structure/pagination/README.mdx).
 - hash
   - string
-  - A hex-encoded SHA-256 hash of this ledger’s [XDR](/docs/learn/encyclopedia/xdr)-encoded form.
+  - A hex-encoded SHA-256 hash of this ledger’s [XDR](../../../../../docs/learn/encyclopedia/xdr)-encoded form.
 - prev_hash
   - string
   - The hash of the ledger immediately preceding this ledger.
diff --git a/network/horizon/api-reference/resources/offers/README.mdx b/network/horizon/api-reference/resources/offers/README.mdx
index 1786532ca..4d698d098 100644
--- a/network/horizon/api-reference/resources/offers/README.mdx
+++ b/network/horizon/api-reference/resources/offers/README.mdx
@@ -7,7 +7,7 @@ import { EndpointsTable } from "@site/src/components/EndpointsTable";
 
 Offers are statements about how much of an asset an account wants to buy or sell.
 
-Learn more about [offers](/docs/learn/glossary/#decentralized-exchange).
+Learn more about [offers](../../../../../docs/learn/glossary/#decentralized-exchange).
 
 <EndpointsTable title="Endpoints">
 
diff --git a/network/horizon/api-reference/resources/operations/object/extend-footprint-ttl.mdx b/network/horizon/api-reference/resources/operations/object/extend-footprint-ttl.mdx
index 371d87b5a..c44991831 100644
--- a/network/horizon/api-reference/resources/operations/object/extend-footprint-ttl.mdx
+++ b/network/horizon/api-reference/resources/operations/object/extend-footprint-ttl.mdx
@@ -6,7 +6,7 @@ order: 230
 import { ExampleResponse } from "@site/src/components/ExampleResponse";
 import { AttributeTable } from "@site/src/components/AttributeTable";
 
-[Extends](https://developers.stellar.org/docs/learn/fundamentals/list-of-operations#extend-footprint-ttl) the TTL for a given set of ledger entries.
+[Extends](/docs/learn/fundamentals/list-of-operations#extend-footprint-ttl) the TTL for a given set of ledger entries.
 
 
 <AttributeTable>
diff --git a/network/horizon/api-reference/resources/operations/object/invoke-host-function.mdx b/network/horizon/api-reference/resources/operations/object/invoke-host-function.mdx
index 8f3537f7b..8d3987e48 100644
--- a/network/horizon/api-reference/resources/operations/object/invoke-host-function.mdx
+++ b/network/horizon/api-reference/resources/operations/object/invoke-host-function.mdx
@@ -6,7 +6,7 @@ order: 220
 import { ExampleResponse } from "@site/src/components/ExampleResponse";
 import { AttributeTable } from "@site/src/components/AttributeTable";
 
-[Invokes](https://developers.stellar.org/docs/learn/fundamentals/list-of-operations#invoke-host-function) a Soroban smart contract function.
+[Invokes](/docs/learn/fundamentals/list-of-operations#invoke-host-function) a Soroban smart contract function.
 
 
 <AttributeTable>
@@ -46,7 +46,7 @@ import { AttributeTable } from "@site/src/components/AttributeTable";
       - The Stellar address of the issuer of the asset being sent. Appears if the `asset_type` is not `native`.
     - type
       - string
-      - The type of the [Stellar Asset Contract event](https://soroban.stellar.org/docs/tokens/token-interface). It can be one of `transfer`, `mint`, `clawback`, or `burn`.
+      - The type of the [Stellar Asset Contract event](/docs/smart-contracts/tokens/stellar-asset-contract). It can be one of `transfer`, `mint`, `clawback`, or `burn`.
     - from
       - string
       - The Stellar address of the sender (can be a contract or a Stellar account). This field is not present when `type` is `mint`.
diff --git a/network/horizon/api-reference/resources/transactions/object.mdx b/network/horizon/api-reference/resources/transactions/object.mdx
index 5b8f17a55..2c48523e7 100644
--- a/network/horizon/api-reference/resources/transactions/object.mdx
+++ b/network/horizon/api-reference/resources/transactions/object.mdx
@@ -39,10 +39,10 @@ When Horizon returns information about a transaction, it uses the following form
   - The source account's sequence number that this transaction consumed.
 - fee_charged
   - number
-  - The fee (in [stroops](/docs/issuing-assets/anatomy-of-an-asset#lumens-xlm)) paid by the source account to apply this transaction to the ledger.
+  - The fee (in [stroops](/docs/learn/fundamentals/lumens)) paid by the source account to apply this transaction to the ledger.
 - max_fee
   - number
-  - The maximum fee (in [stroops](/docs/issuing-assets/anatomy-of-an-asset#lumens-xlm)) that the source account was willing to pay.
+  - The maximum fee (in [stroops](/docs/learn/fundamentals/lumens)) that the source account was willing to pay.
 - operation_count
   - number
   - The number of operations contained within this transaction.
diff --git a/network/soroban-rpc/api-reference/methods/getLedgerEntries.mdx b/network/soroban-rpc/api-reference/methods/getLedgerEntries.mdx
index aefc1f9db..c0611af7d 100644
--- a/network/soroban-rpc/api-reference/methods/getLedgerEntries.mdx
+++ b/network/soroban-rpc/api-reference/methods/getLedgerEntries.mdx
@@ -334,5 +334,5 @@ And the response we get contains (even more) `LedgerEntryData` that we can decod
 }
 ```
 
-[`increment` example contract]: https://soroban.stellar.org/docs/getting-started/storing-data
+[`increment` example contract]: /docs/smart-contracts/getting-started/storing-data
 ["View XDR" page of the Stellar Laboratory]: https://laboratory.stellar.org/#xdr-viewer?type=LedgerEntryData&network=testnet