Categorize Learn Section (#646)

* Categorize Learn Section

* moving things around

* fix links

* more links

* mas links

* beaucoup links

* mais links

* authorization heading fix

* message

* little nits

docs/building-apps/application-design-considerations.mdx

@@ -11,7 +11,7 @@ There are four custody options to consider:
 
 - Non-custodial service - the user of the application stores their own secret key
 - Custodial service - the service provider (application) stores the users’ secret keys
-- Mixture of both - with the use of [multisig](../learn/encyclopedia/signatures-multisig.mdx), this option is useful for maintaining non-custodial status while still allowing for account recovery
+- Mixture of both - with the use of [multisig](../learn/encyclopedia/security/signatures-multisig.mdx), this option is useful for maintaining non-custodial status while still allowing for account recovery
 - Third-party key management services - integrate a third-party custodial service into your application that can store your users’ secret keys
 
 ### Non-custodial service
@@ -24,11 +24,11 @@ Typically, non-custodial applications create or import a pre-existing Stellar ac
 
 With a custodial service, the service provider (an application such as a centralized exchange) stores the users’ secret keys and delegates usage rights to the user.
 
-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).
+Many custodial services choose to use a single pooled Stellar account (called shared, omnibus, or [pooled accounts](../learn/encyclopedia/transactions-specialized/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/transactions-specialized/pooled-accounts-muxed-accounts-memos.mdx#muxed-accounts).
 
 ### 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.
+Building an application with [multi-signature](../learn/encyclopedia/security/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.
 
 ### Third-party key management services​
 

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

@@ -191,5 +191,5 @@ Our `walletStore` is used in a ton of places in our application, especially in t
 [accounts section]: ../../learn/fundamentals/stellar-data-structures/accounts.mdx
 [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
+[sponsored reserves]: ../../learn/encyclopedia/transactions-specialized/sponsored-reserves.mdx
 [contacts list]: ./contacts-list

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

@@ -3,7 +3,7 @@ title: "Setup for Anchored Assets"
 sidebar_position: 10
 ---
 
-An anchor is a Stellar-specific term for the on and off-ramps that connect the Stellar network to traditional financial rails, such as financial institutions or fintech companies. When a user deposits with an anchor, that anchor will credit their Stellar account with the equivalent amount of digital tokens. The user can then hold, transfer, or trade those tokens just like any other Stellar asset. When a user withdraws those tokens, the anchor redeems them for cash in hand or money in the bank. Read more about anchors in this [anchor section](../../../learn/encyclopedia/anchors.mdx).
+An anchor is a Stellar-specific term for the on and off-ramps that connect the Stellar network to traditional financial rails, such as financial institutions or fintech companies. When a user deposits with an anchor, that anchor will credit their Stellar account with the equivalent amount of digital tokens. The user can then hold, transfer, or trade those tokens just like any other Stellar asset. When a user withdraws those tokens, the anchor redeems them for cash in hand or money in the bank. Read more about anchors in this [anchor section](../../../learn/fundamentals/anchors.mdx).
 
 When a customer downloads a wallet application that is connected to an anchor service, their Stellar account can either be created by the wallet application or the anchor service. In this example, the account has been created by the wallet application, BasicPay. Account creation strategies are described more in-depth [here](../../application-design-considerations.mdx#account-creation-strategies).
 

docs/building-apps/example-application-tutorial/path-payment.mdx

@@ -3,7 +3,7 @@ title: Path Payment
 sidebar_position: 50
 ---
 
-A path payment is where the asset sent can be different from the asset received. There are two possible path payment operations: 1) `path_payment_strict_send`, which allows the user to specify the amount of the asset to send, and 2) `path_payment_strict_receive`, which allows the user to specify the amount of the asset received. Read more in the [Path Payments Encyclopedia Entry](../../learn/encyclopedia/path-payments.mdx).
+A path payment is where the asset sent can be different from the asset received. There are two possible path payment operations: 1) `path_payment_strict_send`, which allows the user to specify the amount of the asset to send, and 2) `path_payment_strict_receive`, which allows the user to specify the amount of the asset received. Read more in the [Path Payments Encyclopedia Entry](../../learn/encyclopedia/transactions-specialized/path-payments.mdx).
 
 ## User experience
 

docs/building-apps/wallet/sep30.mdx

@@ -186,7 +186,7 @@ var recoverableWallet = await recovery.createRecoverableWallet(
 With the given parameters, this function will create a transaction that will:
 
 1. Set `deviceKp` as the primary account key. Please note that the master key belonging to `accountKp` will be locked. `deviceKp` should be used as a primary signer instead.
-2. Set all operation thresholds to 10. You can read more about threshold in the [documentation](../../learn/encyclopedia/signatures-multisig.mdx#thresholds)
+2. Set all operation thresholds to 10. You can read more about threshold in the [documentation](../../learn/encyclopedia/security/signatures-multisig.mdx#thresholds)
 3. Use identities that were defined earlier on both servers. (That means, both server will accept SEP-10 authentication via `recoveryKp` as an auth method)
 4. Set device key weight to 10, and recovery server weight to 5. Given these account thresholds, both servers must be used to recover the account, as transaction signed by one will only have weight of 5, which is not sufficient to change account key.
 

docs/building-apps/wallet/stellar.mdx

@@ -403,7 +403,7 @@ bool success = await stellar.submitTransaction(modifyAccountTransaction);
 
 #### Sponsor Operations
 
-Some operations, that modify account reserves can be [sponsored](../../learn/encyclopedia/sponsored-reserves.mdx#sponsored-reserves-operations). For sponsored operations, the sponsoring account will be paying for the reserves instead of the account that being sponsored. This allows you to do some operations, even if account doesn't have enough funds to perform such operations. To sponsor a transaction, <LanguageSpecific kt={<span>simply start a <code>sponsoring</code> block:</span>} ts={<span>simply create a building function (describing which operations are to be sponsored) and pass it to the <code>sponsoring</code> method:</span>}/>
+Some operations, that modify account reserves can be [sponsored](../../learn/encyclopedia/transactions-specialized/sponsored-reserves.mdx#sponsored-reserves-operations). For sponsored operations, the sponsoring account will be paying for the reserves instead of the account that being sponsored. This allows you to do some operations, even if account doesn't have enough funds to perform such operations. To sponsor a transaction, <LanguageSpecific kt={<span>simply start a <code>sponsoring</code> block:</span>} ts={<span>simply create a building function (describing which operations are to be sponsored) and pass it to the <code>sponsoring</code> method:</span>}/>
 
 <CodeExample>
 

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](../learn/encyclopedia/anchors.mdx).
+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/fundamentals/anchors.mdx).
 
 ### Treasury management
 

docs/issuing-assets/control-asset-access.mdx

@@ -32,7 +32,7 @@ Using a distribution account is better for auditing because an issuing account c
 
 One thing you must decide when issuing an asset is what to call it. An asset code is the asset’s identifying code. There are three possible formats: Alphanumeric 4, Alphanumeric 12, and liquidity pool shares.
 
-Learn about liquidity pool shares in the [Liquidity Pool Encyclopedia Entry](../learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx).
+Learn about liquidity pool shares in the [Liquidity Pool Encyclopedia Entry](../learn/encyclopedia/sdex/liquidity-on-stellar-sdex-liquidity-pools.mdx).
 
 - Alphanumeric 4-character maximum: Any characters from the set a-z, A-Z, 0-9 are allowed. The code can be shorter than 4 characters, but the trailing characters must all be empty.
 - Alphanumeric 12-character maximum: Any characters from the set a-z, A-Z, 0-9 are allowed. The code can be any number of characters from 5 to 12, but the trailing characters must all be empty.
@@ -73,11 +73,11 @@ There are three levels of authorization an asset issuer can remove using the `Se
 
 - `AUTHORIZED_FLAG`: signifies complete authorization allowing an account to transact freely with the asset to make and receive payments and place orders.
 - `AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG`: denotes limited authorization that allows an account to maintain current orders but not to otherwise transact with the asset.
-- `CLAWBACK_ENABLED`: enables the issuing account to take back (burning) all of the asset. See our [section on Clawbacks](../learn/encyclopedia/clawbacks.mdx) for more information.
+- `CLAWBACK_ENABLED`: enables the issuing account to take back (burning) all of the asset. See our [section on Clawbacks](../learn/encyclopedia/transactions-specialized/clawbacks.mdx) for more information.
 
 #### Clawback Enabled (0x8)
 
-With the `AUTH_CLAWBACK_ENABLED_FLAG` flag set, any _subsequent_ trustlines established with this account will have clawbacks enabled. You can read more about clawbacks (and selectively controlling them on a per-trustline basis) [here](../learn/encyclopedia/clawbacks.mdx).
+With the `AUTH_CLAWBACK_ENABLED_FLAG` flag set, any _subsequent_ trustlines established with this account will have clawbacks enabled. You can read more about clawbacks (and selectively controlling them on a per-trustline basis) [here](../learn/encyclopedia/transactions-specialized/clawbacks.mdx).
 
 Note that this flag requires that revocable is also set.
 
@@ -109,7 +109,7 @@ The authorization sandwich allows the issuer to inspect the specific payment and
 
 ### Sample code
 
-In the following code samples, proper error checking is omitted. However, you should always validate your results, as there are many ways that requests can fail. Refer to the [Error Handling Encyclopedia Entry](../learn/encyclopedia/error-handling.mdx) for tips on error management strategies.
+In the following code samples, proper error checking is omitted. However, you should always validate your results, as there are many ways that requests can fail. Refer to the [Error Handling Encyclopedia Entry](../learn/encyclopedia/errors-and-debugging/error-handling.mdx) for tips on error management strategies.
 
 The following example sets authorization to be both required and revocable:
 
@@ -222,6 +222,6 @@ With that warning in mind:
 
 It is possible to lock down the issuing account of an asset so that the asset’s supply cannot increase. To do this, first set the issuing account’s master weight to 0 using the Set Options operation. This prevents the issuing account from being able to sign transactions and therefore, making the issuer unable to issue any more assets. Be sure to do this only after you’ve issued all desired assets to the distribution account. If the asset has a Stellar Asset Contract, also make sure the admin for the contract was not updated from the default (which is the issuer) using the `set_admin` contract call. If the admin was not the issuer, then the admin would be able to mint the asset even with the issuing account locked.
 
-Learn more about signature weights in the [Signature and Multisig Encyclopedia Entry](../learn/encyclopedia/signatures-multisig.mdx).
+Learn more about signature weights in the [Signature and Multisig Encyclopedia Entry](../learn/encyclopedia/security/signatures-multisig.mdx).
 
 See how to do this in step five of the [Issuing an Asset Tutorial](./how-to-issue-an-asset.mdx).

docs/issuing-assets/how-to-issue-an-asset.mdx

@@ -18,7 +18,7 @@ If you'd like to interact with an asset issued on the Stellar network in smart c
 
 You must ensure you have the required amount of XLM to create your issuing and distribution accounts and cover the minimum balance and transaction fees. If you’re issuing an asset on the testnet, you can fund your account by getting test XLM from friendbot. If you’re issuing an asset in production, you will need to acquire XLM from another wallet or exchange.
 
-If you’d like to avoid your users having to deal with transaction fees, consider using fee-bump transactions. Read more in our [Fee-Bump Transaction Encyclopedia Entry](../learn/encyclopedia/fee-bump-transactions.mdx).
+If you’d like to avoid your users having to deal with transaction fees, consider using fee-bump transactions. Read more in our [Fee-Bump Transaction Encyclopedia Entry](../learn/encyclopedia/transactions-specialized/fee-bump-transactions.mdx).
 
 Learn about the testnet and mainnet in our [Networks section](../learn/fundamentals/networks.mdx).
 
@@ -57,7 +57,7 @@ An account must establish a trustline with the issuing account to hold that acco
 
 Read more about trustlines in the [Trustlines section](../learn/fundamentals/stellar-data-structures/accounts.mdx#trustlines).
 
-If you’d like to avoid your users having to deal with trustlines or XLM, consider using sponsored reserves. Read more in our [Sponsored Reserves Encyclopedia Entry](../learn/encyclopedia/sponsored-reserves.mdx).
+If you’d like to avoid your users having to deal with trustlines or XLM, consider using sponsored reserves. Read more in our [Sponsored Reserves Encyclopedia Entry](../learn/encyclopedia/transactions-specialized/sponsored-reserves.mdx).
 
 <CodeExample>
 

docs/learn/encyclopedia/contract-development/README.mdx

@@ -0,0 +1,8 @@
+---
+title: Contract Development
+sidebar_position: 10
+---
+
+import DocCardList from "@theme/DocCardList";
+
+<DocCardList />

docs/learn/smart-contract-internals/contract-interactions/README.mdx → docs/learn/encyclopedia/contract-development/contract-interactions/README.mdx

@@ -1,6 +1,6 @@
 ---
 title: Contract Interactions
-sidebar_position: 120
+sidebar_position: 60
 ---
 
 import DocCardList from "@theme/DocCardList";