diff --git a/articleRedirects.js b/articleRedirects.js
index 7c8598438c8..3c23651f6d3 100644
--- a/articleRedirects.js
+++ b/articleRedirects.js
@@ -418,31 +418,31 @@ exports.articleRedirects = [
   },
   {
     from: '/shimmer/learn/smart-contracts/smart-contracts-community-tutorials',
-    to: '/smart-contracts/overview',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/learn/smart-contracts/smart-contracts-consensus',
-    to: '/learn/smart-contracts/core_concepts/smart-contracts',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/learn/smart-contracts/smart-contracts-dapps',
-    to: '/smart-contracts/overview',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/learn/smart-contracts/smart-contracts-introduction',
-    to: '/smart-contracts/overview',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/learn/smart-contracts/smart-contracts-tangle',
-    to: '/smart-contracts/overview',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/learn/smart-contracts/smart-contracts-validators',
-    to: '/smart-contracts/overview',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/learn/smart-contracts/smart-contracts-VM-and-languages',
-    to: '/smart-contracts/overview',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/learn/tangle',
@@ -466,19 +466,19 @@ exports.articleRedirects = [
   },
   {
     from: '/shimmer/smart-contracts/contribute',
-    to: '/smart-contracts/contribute',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/smart-contracts/guide/example_projects/fair_roulette',
-    to: '/smart-contracts/guide/wasm_vm/example_projects/fair_roulette',
+    to: '/wasp-wasm/tutorials/fair_roulette',
   },
   {
     from: '/shimmer/smart-contracts/metrics',
     to: '/wasp/metrics',
   },
   {
-    from: '/shimmer/smart-contracts/overview',
-    to: '/smart-contracts/overview',
+    from: '/shimmer/learn/smart-contracts/introduction',
+    to: '/learn/smart-contracts/introduction',
   },
   {
     from: '/shimmer/use/wallets/firefly/faq-and-troubleshooting',
diff --git a/docs/build/wasp-cli/0.7.0/sidebars.js b/docs/build/wasp-cli/0.7.0/sidebars.js
index 4deb9b6eca2..f7c2d3c88e5 100644
--- a/docs/build/wasp-cli/0.7.0/sidebars.js
+++ b/docs/build/wasp-cli/0.7.0/sidebars.js
@@ -17,7 +17,7 @@ module.exports = {
   tutorialSidebar: [
     {
       type: 'category',
-      label: 'How Tos',
+      label: 'How To',
       collapsed: false,
       items: [
         {
diff --git a/docs/build/wasp-evm/0.7.0/sidebars.js b/docs/build/wasp-evm/0.7.0/sidebars.js
index 351eec416b0..06387385d6e 100644
--- a/docs/build/wasp-evm/0.7.0/sidebars.js
+++ b/docs/build/wasp-evm/0.7.0/sidebars.js
@@ -43,7 +43,7 @@ module.exports = {
     },
     {
       type: 'category',
-      label: 'How Tos',
+      label: 'How To',
       items: [
         {
           type: 'doc',
diff --git a/docs/build/wasp-wasm/0.7.0/docs/explanations/how-accounts-work.md b/docs/build/wasp-wasm/0.7.0/docs/explanations/how-accounts-work.md
index 2c1df0a2d57..390320fbff0 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/explanations/how-accounts-work.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/explanations/how-accounts-work.md
@@ -74,9 +74,9 @@ Tokens in an Ethereum account can only be moved by sending an Ethereum transacti
 The [`accounts` core contract](../reference/core-contracts/accounts.md) is responsible for managing the L2 ledger.
 By calling this contract, it is possible to:
 
-- [View current account balances](../how-tos/accounts/view-account-balances.mdx)
-- [Deposit funds to the chain](../how-tos/accounts/deposit-to-a-chain.mdx)
-- [Withdraw funds from the chain](../how-tos/accounts/withdraw-from-a-chain.mdx)
+- [View current account balances](../how-tos/view-account-balances.mdx)
+- [Deposit funds to the chain](../how-tos/deposit-to-a-chain.mdx)
+- [Withdraw funds from the chain](../how-tos/withdraw-from-a-chain.mdx)
 
 ## Example
 
diff --git a/docs/build/wasp-wasm/0.7.0/docs/explanations/proxies.mdx b/docs/build/wasp-wasm/0.7.0/docs/explanations/proxies.mdx
index a5202187af9..f8b01261e92 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/explanations/proxies.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/explanations/proxies.mdx
@@ -32,12 +32,12 @@ At the core, data is secured in maps on the ISC host with byte strings serving a
 
 The WasmLib recognizes three predefined maps:
 
-- **[State Map](../schema-tool/state.mdx):** A repository for all state storage values.
-- **[Params Map](params.mdx):** Holds the parameter values of the current function call.
-- **[Results Map](results.mdx):** Returns the result values of the function call.
+- **[State Map](../how-tos/schema-tool/state.mdx):** A repository for all state storage values.
+- **[Params Map](../how-tos/schema-tool/params.mdx):** Holds the parameter values of the current function call.
+- **[Results Map](../how-tos/schema-tool/results.mdx):** Returns the result values of the function call.
 
 Through these maps, a complex,
-JSON-like data structure can be created with the aid of the [Schema Tool](../schema-tool/usage.mdx),
+JSON-like data structure can be created with the aid of the [Schema Tool](../how-tos/schema-tool/usage.mdx),
 although, fundamentally, this structure is rooted in simple key-value access on the underlying map.
 
 ## Proxy Varieties
@@ -49,7 +49,7 @@ Proxies are segmented into various categories to facilitate different functional
 Representing a single instance of a predetermined data type,
 value proxies are basic entities facilitating type conversion of the byte string representing the stored value.
 
-The [Schema Tool](../schema-tool/usage.mdx) ensures type-safe code generation, always selecting the suitable proxy type.
+The [Schema Tool](../how-tos/schema-tool/usage.mdx) ensures type-safe code generation, always selecting the suitable proxy type.
 
 ### Container Proxies
 
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/accounts/deposit-to-a-chain.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx
similarity index 93%
rename from docs/build/wasp-wasm/0.7.0/docs/how-tos/accounts/deposit-to-a-chain.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx
index 8b73834a60d..e88da4ca3ea 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/accounts/deposit-to-a-chain.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx
@@ -21,7 +21,7 @@ request.
 So, to deposit tokens, you only need to send _any_ on-ledger request with the tokens attached.
 
 A commonly needed operation is to only deposit some funds and do nothing else.
-The `deposit` entry point of the [`accounts` core contract](../../reference/core-contracts/accounts.md) is a no-op function that serves
+The `deposit` entry point of the [`accounts` core contract](../reference/core-contracts/accounts.md) is a no-op function that serves
 this purpose.
 
 :::note Gas Fees
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/functions-and-events/yaml.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/functions-and-events/yaml.mdx
deleted file mode 100644
index 788fea9f07b..00000000000
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/functions-and-events/yaml.mdx
+++ /dev/null
@@ -1,72 +0,0 @@
----
-keywords:
-  - definition
-  - yaml
-  - smart contract creator
-  - one-time
-  - contract generation
-  - datatypes
-description: the syntax of a schema definition file will be described here.
-image: /img/logo/WASP_logo_dark.png
----
-
-# YAML
-
-A schema definition file can have following level 1 attributes
-
-- name
-- description
-- events
-- structs
-- typedefs
-- state
-- funcs
-- views
-
-We are going to introduce each level 1 attributes in the following sections.
-
-## name
-
-Single string. The name of the smart contract. This name will be used as the package name of the smart contract.
-
-## description
-
-Single string. A description for what this smart contract works for. We currently not process it for the final smart contract.
-
-## events
-
-Map of strings. You can define your structured events here. Check [events](./events.mdx) for more information.
-The fields in an event must be primitive types, so array, map or typedef can't be the datatype of the fields.
-
-## structs
-
-Map of string maps. Declare the structs that can be used in the following development. A declared struct can be called in the schema definition, too.
-The fields in a struct can't be array, map or typedef alias. In other words, only the primitive types are accepted.
-
-## typedefs
-
-Map of strings. Declare alias of a primitive value. Now only a primitive value, a map of primitive values or an array of primitive values are accepted.
-And a nested typedef is not accepted now.
-
-## state
-
-Map of strings. `state` is a collection of arbitrary key/value pairs represent usecase-specific data. See [states](/learn/smart-contracts/core_concepts/states) for more information.
-If you want to use nested types, you can use typedef to declare an alias of array or map, then use the alias as the value in the state.
-However, the key of a map can't be an alias. The key of a map must be a primitive type.
-
-## funcs
-
-All the values of `funcs` and `views` in `params` and `results` which share the same name should be in the same datatype.
-For function names, `init` is a preserved keyword. A function named as `init` is a special function, see [init](./init.mdx) for more information.
-
-`access`: Who can access this function. This field must be state variable. You can visit [Limiting Access](./access.mdx#limiting-access) for more information.
-`params`: The input parameters of the function. The values in `params` can be an array, a map or typedef alias.
-`results`: The return values of the function. The values in `results` can be an array, a map or typedef alias.
-
-## views
-
-All the values of `funcs` and `views` in `params` and `results` which share the same name should be in the same datatype.
-
-`access`: Who can access this function. This field must be state variable. You can visit [Limiting Access](./access.mdx#limiting-access) for more information.
-`params`: The input parameters of the function. The values in `params` can be an array, a map or typedef alias.
-`results`: The return values of the function. The values in `results` can be an array, a map or typedef alias.
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/events.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/events.mdx
index 87a0a6a315e..939892bc6e8 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/events.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/events.mdx
@@ -18,14 +18,14 @@ A solution to this is triggering events, which is facilitated through smart cont
 
 ## ISC Sandbox Interface
 
-The `ScFuncContext` [Call Context](context.mdx) in ISC Sandbox has an `event()` function to support event triggering.
+The `ScFuncContext` [Call Context](../../explanations/context.mdx) in ISC Sandbox has an `event()` function to support event triggering.
 This function takes a text string parameter, requiring creators and users to maintain and understand the chosen format.
 However, this setup is prone to errors and inconsistency due to the arbitrary nature of the text strings used.
 
 ## Structured Events with Schema Tool
 
 To mitigate issues stemming from the rudimentary interface,
-use the [Schema Tool](../schema-tool/usage.mdx) to define structured events,
+use the [Schema Tool](usage.mdx) to define structured events,
 making event creation and handling more consistent and less error-prone.
 
 This tool allows you to establish structured events that are integrated into all Func function contexts.
@@ -71,7 +71,7 @@ events:
 </TabItem>
 </Tabs>
 
-The [Schema Tool](../schema-tool/usage.mdx) will generate `events.xx` which contains the following code
+The [Schema Tool](usage.mdx) will generate `events.xx` which contains the following code
 for the `FairRouletteEvents` struct:
 
 <Tabs groupId="language" queryString>
@@ -309,7 +309,7 @@ f.events.bet(bet.better.address(), bet.amount, bet.number);
 </Tabs>
 
 The smart contract client code can define handler functions to listen in to the event
-stream and respond to any events it deems noteworthy. The [Schema Tool](../schema-tool/usage.mdx) will
+stream and respond to any events it deems noteworthy. The [Schema Tool](usage.mdx) will
 automatically generate the necessary client side code that properly listens for the
 events, parses the event strings into a type-safe structure, and passes this structure to
 the corresponding handler function.
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcs.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcs.mdx
index 5907a668eeb..8617de41678 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcs.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcs.mdx
@@ -17,7 +17,7 @@ import TabItem from '@theme/TabItem';
 # Define Functions
 
 Here is the full schema definition file for the `dividend` example. We will now focus on
-its [`funcs` and `views` sections](../../explanations/context.md). Since they are structured identically we will only need
+its [`funcs` and `views` sections](../../explanations/context.mdx). Since they are structured identically we will only need
 to explain the layout of these sections once.
 
 <Tabs groupId="schema" queryString>
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/introduction.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/introduction.mdx
index 29e24ec658c..bc0e60ca51c 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/introduction.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/introduction.mdx
@@ -33,14 +33,14 @@ The schema tool diminishes redundancy and ensures up-to-date functionalities.
 The schema definition file serves as a single source of truth, encompassing crucial details like:
 
 - State Storage Variables.
-- [Funcs and Views](functions-and-events/context.mdx).
-- [Access rights](../how-tos/functions-and-events/access.mdx).
-- [Input parameters](../how-tos/functions-and-events/params.mdx) and [output results](../how-tos/functions-and-events/results.mdx) .
+- [Funcs and Views](../../explanations/context.mdx).
+- [Access rights](access.mdx).
+- [Input parameters](params.mdx) and [output results](results.mdx) .
 - Additional Data Structures.
 
 ### Automation with Schema Tool
 
-Using the [Schema Tool](../how-tos/schema-tool/usage.mdx), the file facilitates:
+Using the [Schema Tool](usage.mdx), the file facilitates:
 
 - **Skeleton Generation**: Crafting a smart contract framework that needs function implementations.
 - **Interface Generation**: Creating interfaces to functions with stringent compile-time type-checking, thereby reducing errors.
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/params.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/params.mdx
index 2e65f4ad374..3dc604d6f28 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/params.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/params.mdx
@@ -99,4 +99,4 @@ export class ImmutableMemberParams extends wasmtypes.ScProxy {
 </Tabs>
 
 The [Schema Tool](../schema-tool/usage.mdx) will also generate a mutable version of the structure,
-suitable for providing the parameters when calling this smart contract function from any [Call Context](context.mdx).
+suitable for providing the parameters when calling this smart contract function from any [Call Context](../../explanations/context.mdx).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/typedefs.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/typedefs.mdx
index daa00d422e5..c7e2a331839 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/typedefs.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/typedefs.mdx
@@ -17,7 +17,13 @@ import TabItem from '@theme/TabItem';
 
 # Type Definitions
 
-The WasmLib allows of [container types](../../explantions/functions-and-events/proxies.mdx#container-proxies), but it
+:::note WasmLib Types
+
+You can find the complete list of [WasmLib Data Types](../../reference/data-types/types.mdx) in the reference section.
+
+:::
+
+The WasmLib allows of [container types](../../explanations/proxies.mdx#container-proxies), but it
 is not possible to specify these types directly because the type name syntax only allows
 you to specify a single container type.
 
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/yaml.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/yaml.mdx
new file mode 100644
index 00000000000..335f7262652
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/yaml.mdx
@@ -0,0 +1,69 @@
+---
+keywords:
+  - definition
+  - yaml
+  - smart contract creator
+  - one-time
+  - contract generation
+  - datatypes
+description: the syntax of a schema definition file will be described here.
+image: /img/logo/WASP_logo_dark.png
+---
+
+# YAML Schema Definition: Level 1 Attributes
+
+The schema definition file can have the following level 1 attributes:
+
+## name
+
+- **Type**: Single string
+- **Usage**: Dictates the package name for the smart contract
+
+## description
+
+- **Type**: Single string
+- **Usage**: Describes the smart contract's functionality (currently not utilized in the final smart contract)
+
+## events
+
+- **Type**: Map of strings
+- **Usage**: Define structured events ([more info](./events.mdx))
+- **Restriction**: Field data types must be primitive; arrays, maps, or typedefs are not allowed
+
+## structs
+
+- **Type**: Map of string maps
+- **Usage**: Declare structs for future development, usable in schema definitions
+- **Restriction**: Fields must hold primitive types; arrays, maps, or typedef aliases are prohibited
+
+## typedefs
+
+- **Type**: Map of strings
+- **Usage**: Create aliases for primitive values; supports primitive values, maps of primitive values, or arrays of primitive values
+- **Restriction**: Nested typedefs are not permissible
+
+## state
+
+- **Type**: Map of strings
+- **Usage**: Contains key/value pairs for use-case specific data ([details](/learn/smart-contracts/core_concepts/states))
+- **Note**: To employ nested types, create a typedef alias for arrays or maps, but ensure map keys are primitive
+
+## funcs & views
+
+Describe functions and views sharing the same parameter and result names, ensuring they adhere to identical data types. The attributes common to both are:
+
+- **`access`**
+- **Requirement**: Must be a state variable
+- **Details**: Defines access permissions ([read more](./access.mdx#limiting-access))
+
+- **`params`**
+- **Type**: Can vary — array, map, or typedef alias
+- **Usage**: Specifies input parameters
+
+- **`results`**
+- **Type**: Can vary — array, map, or typedef alias
+- **Usage**: Designates return values
+
+### Special Note on `funcs`
+
+- **Reserved Keyword**: `init` — relates to a distinct function ([explore](./init.mdx))
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/examples.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/examples.mdx
index ca7c674197b..6be2aa9811a 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/examples.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/examples.mdx
@@ -19,8 +19,8 @@ import TabItem from '@theme/TabItem';
 
 # Example Tests
 
-In the previous sections we showed how you can [`call()`](../functions-and-events/call.mdx) or
-[`post()`](../functions-and-events/post.mdx) smart contract function requests. We also created a few wrapper
+In the previous sections we showed how you can [`call()`](../schema-tool/call.mdx) or
+[`post()`](../schema-tool/post.mdx) smart contract function requests. We also created a few wrapper
 functions to simplify calling these functions even further. Now we will look at how to use
 the SoloContext to create full-blown tests for the `dividend` example smart contract.
 
@@ -231,11 +231,11 @@ any remaining tokens are not transferred, but remain in the sender's account.
 Finally, we call `divide` again with 2M+234 tokens and again verify the asset balances
 afterwards.
 
-Next we will show how to test [Views](../functions-and-events/views.mdx) and/or [Funcs](../functions-and-events/funcs.mdx) that return
-a result. Note that even though Funcs are usually invoked through a [`post()`](../functions-and-events/post.mdx)
+Next we will show how to test [Views](../schema-tool/views.mdx) and/or [Funcs](../schema-tool/funcs.mdx) that return
+a result. Note that even though Funcs are usually invoked through a [`post()`](../schema-tool/post.mdx)
 request, in which case any return values are inaccessible, they still can be invoked
-through a [call()](../functions-and-events/call.mdx) from within another Func, in which these return values can
-be used normally. Since solo executes [`post()`](../functions-and-events/post.mdx) requests synchronously, it is
+through a [call()](../schema-tool/call.mdx) from within another Func, in which these return values can
+be used normally. Since solo executes [`post()`](../schema-tool/post.mdx) requests synchronously, it is
 possible to have a Func return a result and test for certain result values.
 
 <Tabs groupId="language" queryString>
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/test.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/test.mdx
index 59da771ba7d..cd1ec4d6288 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/test.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/test.mdx
@@ -38,7 +38,7 @@ curve and countless unnecessary type conversions.
 With the introduction of the [Schema Tool](../schema-tool/usage.mdx), we were able to remove this
 impedance mismatch and allow the users to test smart contract functionality in terms of
 the WasmLib data types and functions that they are already familiar with. To that end, we
-introduced `SoloContext`, a new [Call Context](../functions-and-events/context.mdx) that specifically works with
+introduced `SoloContext`, a new [Call Context](../../explanations/context.mdx) that specifically works with
 the Solo testing environment. We aimed to simplify the testing of smart contracts as much
 as possible, keeping the full Solo interface hidden as much as possible, but still
 available when necessary.
@@ -73,7 +73,7 @@ func TestDeploy(t *testing.T) {
 The first line will automatically create a new chain, and upload and deploy the provided
 example `dividend` contract to this chain. It returns a `SoloContext` for further use. The
 second line verifies the existence of the deployed contract on the chain associated with
-that [Call Context](../functions-and-events/context.mdx).
+that [Call Context](../../explanations/context.mdx).
 
 Here is another part of the `dividend` test code, where you can see how we wrap repetitive
 calls to smart contract functions that are used in multiple tests:
@@ -108,15 +108,15 @@ func dividendGetFactor(ctx *wasmsolo.SoloContext, member *wasmsolo.SoloAgent) ui
 </Tabs>
 
 As you can see, we pass the `SoloContext` and the parameters to the wrapper functions,
-then use the `SoloContext` to create a [Function Descriptor](../functions-and-events/funcdesc.mdx) for the wrapped
-function, pass any parameters through the its [Params](../functions-and-events/params.mdx) proxy, and then either
-[`post()`](../functions-and-events/post.mdx) the function request or [`call()`](../functions-and-events/call.mdx) the function. Any
-results returned are extracted through the descriptor's [Results](../functions-and-events/results.mdx) proxy, and
+then use the `SoloContext` to create a [Function Descriptor](../schema-tool/funcdesc.mdx) for the wrapped
+function, pass any parameters through the its [Params](../schema-tool/params.mdx) proxy, and then either
+[`post()`](../schema-tool/post.mdx) the function request or [`call()`](../schema-tool/call.mdx) the function. Any
+results returned are extracted through the descriptor's [Results](../schema-tool/results.mdx) proxy, and
 returned by the wrapper function.
 
 There is hardly any difference in the way the function interface is used within Wasm code
-or within Solo test code. The [Call Context](../functions-and-events/context.mdx) knows how to properly
-[`call()`](../functions-and-events/call.mdx) or [`post()`](../functions-and-events/post.mdx) the function call through the function
+or within Solo test code. The [Call Context](../../explanations/context.mdx) knows how to properly
+[`call()`](../schema-tool/call.mdx) or [`post()`](../schema-tool/post.mdx) the function call through the function
 descriptor. This makes for seamless testing of smart contracts.
 
 In the [next section](examples.mdx) we will go deeper into how the helper member functions
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/timelock.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/timelock.mdx
index 61945b78991..4fb028f5711 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/timelock.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/timelock.mdx
@@ -124,7 +124,7 @@ this will happen in a separate goroutine in the background, so we explicitly wai
 request counters to catch up with the one request that is pending.
 
 The `WaitForPendingRequests()` method can also be used whenever a smart contract function
-is known to [`post()`](../functions-and-events/post.mdx) a request to itself. Such requests are not immediately
+is known to [`post()`](../schema-tool/post.mdx) a request to itself. Such requests are not immediately
 executed, but added to the backlog, so you need to wait for these pending requests to
 actually be processed. The advantage of having to explicitly wait for those requests is
 that you can inspect the in-between state, which means that you can test even a function
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/accounts/view-account-balances.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/view-account-balances.mdx
similarity index 100%
rename from docs/build/wasp-wasm/0.7.0/docs/how-tos/accounts/view-account-balances.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/view-account-balances.mdx
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/accounts/withdraw-from-a-chain.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/withdraw-from-a-chain.mdx
similarity index 100%
rename from docs/build/wasp-wasm/0.7.0/docs/how-tos/accounts/withdraw-from-a-chain.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/withdraw-from-a-chain.mdx
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/data-types/types.mdx b/docs/build/wasp-wasm/0.7.0/docs/reference/data-types/types.mdx
index 436197fab7e..df95213b20b 100644
--- a/docs/build/wasp-wasm/0.7.0/docs/reference/data-types/types.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/data-types/types.mdx
@@ -57,7 +57,7 @@ More detailed explanations about their specific uses can be found in the
 
 ## Full Matrix of WasmLib Types
 
-WasmLib implements a full set of [value proxies](../../explanations/functions-and-events/proxies.mdx#value-proxies) for each
+WasmLib implements a full set of [value proxies](../../explanations/proxies.mdx#value-proxies) for each
 predefined value type that provide access to data on the ISC host. But there is one aspect
 of this data that we have not considered yet. Some data provided by the host is mutable,
 whereas other data may be immutable. To facilitate this distinction, each value proxy type
@@ -102,5 +102,5 @@ equivalents in the chosen WasmLib implementation programming language.
 The [Schema Tool](../../how-tos/schema-tool/usage.mdx) will automatically generate the proper (im)mutable proxies
 from the schema definition. For example, View functions will only be able to access the
 [State](../../how-tos/schema-tool/state.mdx) map through immutable proxies. The same goes for the
-[Params](../../how-tos/functions-and-events/params.mdx) map that was passed into a Func or View, and for the
-[Results](../../how-tos/functions-and-events/results.mdx) map that was returned from a call to a Func or View.
+[Params](../../how-tos/schema-tool/params.mdx) map that was passed into a Func or View, and for the
+[Results](../../how-tos/schema-tool/results.mdx) map that was returned from a call to a Func or View.
diff --git a/docs/build/wasp-wasm/0.7.0/sidebars.js b/docs/build/wasp-wasm/0.7.0/sidebars.js
index b2291422ef8..1f4b77b0d6e 100644
--- a/docs/build/wasp-wasm/0.7.0/sidebars.js
+++ b/docs/build/wasp-wasm/0.7.0/sidebars.js
@@ -142,25 +142,19 @@ module.exports = {
           ],
         },
         {
-          type: 'category',
-          label: 'Accounts',
-          items: [
-            {
-              type: 'doc',
-              label: 'Deposit To a Chain',
-              id: 'how-tos/accounts/deposit-to-a-chain',
-            },
-            {
-              type: 'doc',
-              label: 'Withdraw From a Chain',
-              id: 'how-tos/accounts/withdraw-from-a-chain',
-            },
-            {
-              type: 'doc',
-              label: 'View Account Balances',
-              id: 'how-tos/accounts/view-account-balances',
-            },
-          ],
+          type: 'doc',
+          label: 'Deposit To a Chain',
+          id: 'how-tos/deposit-to-a-chain',
+        },
+        {
+          type: 'doc',
+          label: 'Withdraw From a Chain',
+          id: 'how-tos/withdraw-from-a-chain',
+        },
+        {
+          type: 'doc',
+          label: 'View Account Balances',
+          id: 'how-tos/view-account-balances',
         },
         {
           type: 'category',