diff --git a/docs/build/getting-started/sidebars.ts b/docs/build/getting-started/sidebars.ts
index a98467f2e81..2035ffb786e 100644
--- a/docs/build/getting-started/sidebars.ts
+++ b/docs/build/getting-started/sidebars.ts
@@ -23,12 +23,12 @@ module.exports = {
{
type: 'link',
label: 'WASP CLI',
- href: '/wasp/wasp-cli',
+ href: '/wasp-cli/how-tos/wasp-cli',
},
{
label: 'Schema Tool',
type: 'link',
- href: '/smart-contracts/guide/wasm_vm/schema',
+ href: '/wasp-wasm/how-tos/schema-tool/introduction',
},
{
label: 'Explorer',
diff --git a/docs/build/getting-started/welcome.md b/docs/build/getting-started/welcome.md
index 87442e4f2d9..174d0b759c0 100644
--- a/docs/build/getting-started/welcome.md
+++ b/docs/build/getting-started/welcome.md
@@ -46,9 +46,9 @@ any object in a GDPR-compliant, cost-efficient, and privacy-enabling manner.
### Smart Contracts
-The [IOTA Smart Contracts (ISC)](/smart-contracts/overview) bring scalable, flexible, and cost-effective smart
+The [IOTA Smart Contracts (ISC)](/learn/smart-contracts/introduction) bring scalable, flexible, and cost-effective smart
contract functionality to the IOTA ecosystem. By anchoring multiple chains to the IOTA Tangle, ISC enables
higher throughput and lower fees than traditional single-chain solutions. Users have the freedom to create custom
chains with control over gas fees and privacy settings, and the platform is virtual machine-agnostic, supporting both
-[Rust/Wasm](/smart-contracts/guide/wasm_vm/intro) and [Solidity/EVM](/smart-contracts/guide/evm/introduction)
+[Rust/Wasm](/wasp-wasm/introduction) and [Solidity/EVM](/wasp-evm/introduction)
smart contracts.
diff --git a/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md b/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md
index dfe3d56f5bd..b70399e4c5a 100644
--- a/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md
+++ b/docs/build/introduction-docs/stardust/docs/explanations/what_is_stardust/what_is_stardust.md
@@ -15,7 +15,7 @@ image: /img/logo/preview.png
The previous IOTA protocol, Chrysalis, was optimized for a single application: sending digital money from A to B.
The upcoming Stardust upgrade introduces computation and utility to the ledger:
-- Making IOTA an **infrastructure and settlement layer** for [second-layer smart contract chains](/smart-contracts/overview) using [IOTA Smart Contracts (ISC)](#isc).
+- Making IOTA an **infrastructure and settlement layer** for [second-layer smart contract chains](/learn/smart-contracts/introduction/) using [IOTA Smart Contracts (ISC)](#isc).
- Transforming IOTA into a **multi-asset ledger** with custom, user-defined tokens using the new [tokenization framework](#tokenization-framework).
## Tokenization Framework
@@ -54,7 +54,7 @@ ISC can be deployed as multiple Layer 2 (L2) chains, unlike many other projects
### Advantages
-- [L1 is not congested with smart contracts](/learn/smart-contracts/core_concepts/smart-contracts#scalable-smart-contracts).
+- [L1 is not congested with smart contracts](/learn/smart-contracts/introduction/#scalable-smart-contracts).
- Since L1 is not limited by the speed of the smart contract VM, transactions per second (TPS) increase significantly.
- No maximal extractable value (MEV). No front-running or sandwich attacks, resulting in a “fairer” DeFi environment. A set fee and randomization of transactions are included in blocks, making MEV impossible.
- Native randomness beacon (random number generator, or RNG). This is freely available to all dApps, removing the need for expensive, trusted third-party RNGs.
diff --git a/docs/build/introduction-docs/stardust/docs/welcome.md b/docs/build/introduction-docs/stardust/docs/welcome.md
index 9a209225fbd..0c96c6c79d5 100644
--- a/docs/build/introduction-docs/stardust/docs/welcome.md
+++ b/docs/build/introduction-docs/stardust/docs/welcome.md
@@ -9,7 +9,7 @@ image: /img/logo/preview.png
# Welcome
-Stardust protocol is the successor to IOTA 1.5, also known as [Chrysalis](/introduction/welcome), that transforms IOTA into a multi-asset ledger and enables the operation of [IOTA Smart Contracts](/smart-contracts/overview). This page outlines the new concepts
+Stardust protocol is the successor to IOTA 1.5, also known as [Chrysalis](/introduction/welcome), that transforms IOTA into a multi-asset ledger and enables the operation of [IOTA Smart Contracts](/learn/smart-contracts/introduction/). This page outlines the new concepts
and differences compared to Chrysalis, furthermore gives an overview of different components of the IOTA technology stack.
Stardust debuts on [Shimmer](https://shimmer.network/), the new staging network for IOTA, before being fully supported on the IOTA Mainnet.
diff --git a/docs/maintain/wasp/0.7.0/docs/chain-management.md b/docs/build/wasp-cli/0.7.0/docs/how-tos/chain-management.md
similarity index 65%
rename from docs/maintain/wasp/0.7.0/docs/chain-management.md
rename to docs/build/wasp-cli/0.7.0/docs/how-tos/chain-management.md
index 88d5abcc8b5..30f64ce9197 100644
--- a/docs/maintain/wasp/0.7.0/docs/chain-management.md
+++ b/docs/build/wasp-cli/0.7.0/docs/how-tos/chain-management.md
@@ -4,32 +4,32 @@ validators.'
image: /img/logo/WASP_logo_dark.png
keywords:
-- Smart Contracts
-- Chain
-- Management
-- Grafana
+ - Smart Contracts
+ - Chain
+ - Management
+ - Grafana
---
-# Chain Management
+# Manage a Chain
## Monitoring
You can view the chain state using the dashboard (`/wasp/dashboard` when using `node-docker-setup`).
-## Managing Chain Configuration and Validators
+## Manage Chain Configuration and Validators
You can manage the chain configuration and committee of validators by interacting with
-the [Governance contract](/learn/smart-contracts/core_concepts/core_contracts/governance).
+the [Governance contract](/wasp-wasm/reference/core-contracts/governance/).
The “Chain Owner” is the only one who can perform administrative tasks.
-### Changing Chain Ownership
+### Change Chain Ownership
To change the chain ownership, the current “Chain Owner” must call `delegateChainOwnership` specifying the `agentID` of
the next owner. The next owner must call `claimChainOwnership` to finalize the process.
-### Changing Access Nodes
+### Change Access Nodes
For new access nodes to join the network, they need to:
@@ -45,30 +45,29 @@ After this, new nodes should be able to sync the state and execute view queries
You can remove an access node by calling `changeAccessNodes`.
-Alternatively, to add any node as an "access node", you can add "non-permissioned" access nodes, without the signature from the chain owner.
+Alternatively, you can add "non-permissioned" access nodes without the signature from the chain owner to add any node as an "access node".
You can do this by using the following command:
```shell
wasp-cli chain access-nodes
```
-This node won't be "officially" recognized by the committee, but will still be able to sync the state and provide all regular functionality.
+This node won't be "officially" recognized by the committee but will still be able to sync the state and provide all regular functionality.
-### Changing the Set of Validators
+### Change the Set of Validators
-You can do this in different ways, depending on whom the
-[governor address](/tips/tips/TIP-0018#alias-output) of the alias output of the
-chain is.
+You can do this in different ways, depending on who controls the [governor address](/tips/tips/TIP-0018#alias-output)
+from the alias output of the chain.
- If the chain governor address is the chain committee, you can perform the rotation by calling
`rotateStateController` after adding the next state controller via `addAllowedStateControllerAddress`.
-- If the chain governor address is a regular user wallet (that you control), you can issue the rotation transaction using wasp-cli:
+- If the chain governor address is a regular user wallet that you control, you can issue the rotation transaction using wasp-cli:
```shell
wasp-cli chain rotate
```
-or:
+Or:
```shell
wasp-cli chain rotate-with-dkg --peers=<...>
diff --git a/docs/maintain/wasp/0.7.0/docs/setting-up-a-chain.md b/docs/build/wasp-cli/0.7.0/docs/how-tos/setting-up-a-chain.md
similarity index 70%
rename from docs/maintain/wasp/0.7.0/docs/setting-up-a-chain.md
rename to docs/build/wasp-cli/0.7.0/docs/how-tos/setting-up-a-chain.md
index d831e79c5c7..0fbedaf85e9 100644
--- a/docs/maintain/wasp/0.7.0/docs/setting-up-a-chain.md
+++ b/docs/build/wasp-cli/0.7.0/docs/how-tos/setting-up-a-chain.md
@@ -1,5 +1,5 @@
---
-description: Setting up a chain requirements, configuration parameters, validators and tests.
+description: 'Setting up a chain: requirements, configuration parameters, validators, and tests.'
image: /img/logo/WASP_logo_dark.png
keywords:
- Smart Contracts
@@ -10,11 +10,11 @@ keywords:
- Tests
---
-# Setting Up a Chain
+# Set Up a Chain
:::note
-It is possible to run a "committee" of a single Wasp node, and this is okay for testing purposes.
+It is possible to run a "committee" of a single Wasp node, which is okay for testing purposes.
However, in normal operation, multiple Wasp nodes should be used.
:::
@@ -41,15 +41,15 @@ PubKey: 8oQ9xHWvfnShRxB22avvjbMyAumZ7EXKujuthqrzapNM
PeeringURL: 127.0.0.1:4000
```
-PubKey and PeeringURL should be provided to other node operators.
-They can use this info to trust your node and accept communications with it.
+You should provide your `PubKey` and `PeeringURL` to other node operators.
+They can use this info to trust and accept communications with your node.
That's done by invoking `wasp-cli peering trust `, e.g.:
```shell
wasp-cli peering trust another-node 8oQ9xHWvfnShRxB22avvjbMyAumZ7EXKujuthqrzapNM 127.0.0.1:4000
```
-The list of trusted peers of your wasp node can be viewed with:
+You can view the list of your wasp node's trusted peers by calling:
```shell
wasp-cli peering list-trusted
@@ -57,9 +57,11 @@ wasp-cli peering list-trusted
All the nodes in a committee must trust each other to run the chain.
-## Starting The Chain
+## Start the Chain
-### Requesting Test Funds (only for testnet)
+### Request Test Funds (only for Testnet)
+
+You can request test funds to safely develop your application by calling:
```shell
wasp-cli request-funds
@@ -73,28 +75,27 @@ You can deploy your IOTA Smart Contracts chain by running:
wasp-cli chain deploy --peers=foo,bar,baz --chain=mychain --description="My chain" --block-keep-amount=10000
```
-The names in `--peers=foo,bar,baz` correspond to the names of the trusted peers of the node.
+The names in `--peers=foo,bar,baz` correspond to the names of the node's trusted peers.
-The `--chain=mychain` flag sets up an alias for the chain. From now on all chain commands will be targeted to this
-chain.
+The `--chain=mychain` flag sets up an alias for the chain.
+From now on, all chain commands will target this chain.
-The `--quorum` flag indicates the minimum amount of nodes required to form a consensus. The recommended formula to
-obtain this number `floor(N*2/3)+1` where `N` is the number of nodes in your committee.
+The `--quorum` flag indicates the minimum number of nodes required to form a consensus.
+The recommended formula to obtain this number is `floor(N*2/3)+1` where `N` is the number of nodes in your committee.
-The `--block-keep-amount` parameter determines how many blocks are stored in the [`blocklog`](/learn/smart-contracts/core_concepts/core_contracts/blocklog) core contract.
+The `--block-keep-amount` parameter determines how many blocks are stored in the [`blocklog`](/wasp-wasm/reference/core-contracts/blocklog) core contract.
After deployment, the chain must be activated by the node operators of all peers.
```shell
wasp-cli chain add # adds the chain to the wasp-cli config, can be skipped on the wasp-cli that initiated the deployment
wasp-cli chain activate --chain=
-
```
-## Testing If It Works
+## Test If It Works
-You can check that the chain was properly deployed in the Wasp node dashboard (`/wasp/dashboard` when using `node-docker-setup`).
-Note that the chain was deployed with some [core contracts](/learn/smart-contracts/core_concepts/core_contracts/overview).
+You can check that the chain was deployed correctly in the Wasp node dashboard (`/wasp/dashboard` when using `node-docker-setup`).
+Note that the chain was deployed with some [core contracts](/wasp-wasm/reference/core-contracts/overview).
You should also have an EVM-JSONRPC server opened on:
@@ -116,7 +117,7 @@ wasp-cli chain deploy-contract wasmtime inccounter "inccounter SC" tools/cluster
The `inccounter_bg.wasm` file is a precompiled Wasm contract included in the Wasp repo as an example.
-If you check the dashboard again, you should see that the `inccounter` contract is listed in the chain.
+If you recheck the dashboard, you should see that the `inccounter` contract is listed in the chain.
### Interacting With a Smart Contract
@@ -140,7 +141,7 @@ counter: 0
:::note
-The part after `|` is necessary because the return value is encoded, and you need to know the _schema_ in order to
+The part after `|` is necessary because the return value is encoded, and you need to know the _schema_ to
decode it. **The schema definition is in its early stages and will likely change in the future.**
:::
@@ -151,7 +152,7 @@ You can now call the `increment` function by running:
wasp-cli chain post-request inccounter increment
```
-After the request has been processed by the committee, you should get a new
+After the committee has processed the request, you should get a new
counter value after calling `getCounter`:
```shell
diff --git a/docs/maintain/wasp/0.7.0/docs/wasp-cli.md b/docs/build/wasp-cli/0.7.0/docs/how-tos/wasp-cli.md
similarity index 68%
rename from docs/maintain/wasp/0.7.0/docs/wasp-cli.md
rename to docs/build/wasp-cli/0.7.0/docs/how-tos/wasp-cli.md
index 8cecb778b7f..cf9e15f6d66 100644
--- a/docs/maintain/wasp/0.7.0/docs/wasp-cli.md
+++ b/docs/build/wasp-cli/0.7.0/docs/how-tos/wasp-cli.md
@@ -1,5 +1,5 @@
---
-description: How to configure the wasp-cli. Requirements and configuration parameters.
+description: How to configure wasp-cli. Requirements and configuration parameters.
image: /img/logo/WASP_logo_dark.png
keywords:
- Wasp-cli
@@ -8,14 +8,14 @@ keywords:
- command line
---
-# Configuring wasp-cli
+# Configure wasp-cli
-Step-by-step instructions on how to use wasp-cli to interact with Wasp nodes on the Hornet network.
+You can use these step-by-step instructions on how to use wasp-cli to interact with Wasp nodes on the Hornet network.
## Download wasp-cli
-Download the latest wasp-cli binary from the repo [relases page](https://github.com/iotaledger/wasp/releases).
-(For ease of use, it is recommend to add `wasp-cli` to your system `PATH`).
+Download the latest wasp-cli binary from the repo [releases page](https://github.com/iotaledger/wasp/releases).
+(For ease of use, it is recommended to add `wasp-cli` to your system `PATH`).
## Configuration
diff --git a/docs/build/wasp-cli/0.7.0/sidebars.js b/docs/build/wasp-cli/0.7.0/sidebars.js
new file mode 100644
index 00000000000..f7c2d3c88e5
--- /dev/null
+++ b/docs/build/wasp-cli/0.7.0/sidebars.js
@@ -0,0 +1,41 @@
+/**
+ * Creating a sidebar enables you to:
+ - create an ordered group of docs
+ - render a sidebar for each doc of that group
+ - provide next/previous navigation
+
+ The sidebars can be generated from the filesystem, or explicitly defined here.
+
+ Create as many sidebars as you want.
+ */
+
+module.exports = {
+ // By default, Docusaurus generates a sidebar from the docs folder structure
+ //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
+
+ // But you can create a sidebar manually
+ tutorialSidebar: [
+ {
+ type: 'category',
+ label: 'How To',
+ collapsed: false,
+ items: [
+ {
+ type: 'doc',
+ label: 'Configure wasp-cli',
+ id: 'how-tos/wasp-cli',
+ },
+ {
+ type: 'doc',
+ label: 'Set Up a Chain',
+ id: 'how-tos/setting-up-a-chain',
+ },
+ {
+ type: 'doc',
+ label: 'Manage a Chain',
+ id: 'how-tos/chain-management',
+ },
+ ],
+ },
+ ],
+};
diff --git a/docs/learn/smart-contracts/core_concepts/accounts/how-accounts-work.md b/docs/build/wasp-evm/0.7.0/docs/explanations/how-accounts-work.md
similarity index 82%
rename from docs/learn/smart-contracts/core_concepts/accounts/how-accounts-work.md
rename to docs/build/wasp-evm/0.7.0/docs/explanations/how-accounts-work.md
index 73b0c5e7eeb..7c3476e4a6f 100644
--- a/docs/learn/smart-contracts/core_concepts/accounts/how-accounts-work.md
+++ b/docs/build/wasp-evm/0.7.0/docs/explanations/how-accounts-work.md
@@ -20,7 +20,7 @@ ledger.
Tokens controlled by an address can be moved to another address by providing a valid signature using the private key
that controls the source address.
-In IOTA Smart Contracts, [each chain has a L1 address](../states.md#digital-assets-on-the-chain) (also known as the _Chain
+In IOTA Smart Contracts, [each chain has a L1 address](/learn/smart-contracts/states#digital-assets-on-the-chain) (also known as the _Chain
ID_) which enables it to control L1 assets (base tokens, native tokens and NFTs).
The chain acts as a custodian of the L1 assets on behalf of different entities, thus providing a _L2 Ledger_.
@@ -42,11 +42,11 @@ Tokens in an address account can only be moved through a request signed by the p
### Smart Contract
Any smart contract can be the owner of a L2 account. Recall that a smart
-contract is uniquely identified in a chain by a [_hname_](../smart-contract-anatomy.md#identifying-a-smart-contract).
+contract is uniquely identified in a chain by a [_hname_](/learn/smart-contracts/smart-contract-anatomy#identifying-a-smart-contract).
However, the hname is not enough to identify the account since a smart contract on another chain could own it.
Thus, the Agent ID of a smart contract is composed as the contract hname plus the [_chain
-ID_](../states.md#digital-assets-on-the-chain), with syntax `@`. For
+ID_](/learn/smart-contracts/states#digital-assets-on-the-chain), with syntax `@`. For
example: `cebf5908@tgl1pzehtgythywhnhnz26s2vtpe2wy4y64pfcwkp9qvzhpwghzxhwkps2tk0nd`.
Note that this allows trustless transfers of assets between smart contracts on the same or different chains.
@@ -63,7 +63,7 @@ The Agent ID of the common account is `@`.
### Ethereum Address
-An L2 account can also be owned by an Ethereum address. See [EVM](/smart-contracts/guide/evm/introduction) for more information.
+An L2 account can also be owned by an Ethereum address. See [EVM](/wasp-evm/introduction/) for more information.
The Agent ID of an Ethereum address is just the address prefixed with `0x`,
e.g. `0xd36722adec3edcb29c8e7b5a47f352d701393462`.
@@ -71,12 +71,12 @@ Tokens in an Ethereum account can only be moved by sending an Ethereum transacti
## The Accounts Contract
-The [`accounts` core contract](../core_contracts/accounts.md) is responsible for managing the L2 ledger.
+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](./view-account-balances.mdx)
-- [Deposit funds to the chain](./how-to-deposit-to-a-chain.mdx)
-- [Withdraw funds from the chain](./how-to-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-evm/0.7.0/docs/getting-started/compatibility.md b/docs/build/wasp-evm/0.7.0/docs/getting-started/compatibility.md
new file mode 100644
index 00000000000..ccc1451d661
--- /dev/null
+++ b/docs/build/wasp-evm/0.7.0/docs/getting-started/compatibility.md
@@ -0,0 +1,101 @@
+---
+description: Compatibility between the ISC EVM layer and existing Ethereum smart contracts and tooling.
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - smart contracts
+ - EVM
+ - Ethereum
+ - Solidity
+ - limitations
+ - compatibility
+ - fees
+ - reference
+---
+
+# EVM Compatibility in IOTA Smart Contracts
+
+The [`evm`](/wasp-wasm/reference/core-contracts/evm) [core contract](/wasp-wasm/reference/core-contracts/overview)
+provides EVM support in IOTA Smart Contracts. It stores the EVM state (account balances, state, code,
+etc.) and provides a way to execute EVM code to manipulate the state.
+
+The EVM core contract runs on top of the ISC layer, which provides the rest of the machinery needed to run smart
+contracts, such as signed requests, blocks, state, proofs, etc.
+
+However, the ISC EVM layer is also designed to be as compatible as possible with existing Ethereum tools
+like [MetaMask](https://metamask.io/), which assume that the EVM code runs on an Ethereum blockchain composed of
+Ethereum blocks containing Ethereum transactions. Since ISC works in a fundamentally different way,
+providing 100% compatibility is not possible. We do our best to emulate the behavior of an Ethereum node, so the
+Ethereum tools think they are interfacing with an actual Ethereum node, but some differences in behavior are inevitable.
+
+## Properties and Limitations
+
+:::warning
+
+There is a difference in the decimal precision of ether (18 decimal places) to MIOTA/SMR(6 decimal places). Because of this, when sending native tokens in the EVM, which are expressed in wei (ether = 1018wei), the last 12 decimal places will be ignored.
+
+Example: 1,999,999,999,999,999,999 wei = 1.999,999 SMR/MIOTA
+
+:::
+
+Here are some of the most important properties and limitations of EVM support in IOTA Smart Contracts:
+
+### Wrapped Calls to the JSON-RPC
+
+The Wasp node provides a JSON-RPC service, the standard protocol used by Ethereum tools. Upon receiving a signed
+Ethereum transaction via JSON-RPC, the transaction is wrapped into an ISC
+[off-ledger request](/learn/smart-contracts/invocation#off-ledger-requests). The sender of the request
+is the Ethereum address that signed the original transaction (e.g., the Metamask account).
+
+### Contract ID Source
+
+While ISC contracts are identified by an [hname](/learn/smart-contracts/smart-contract-anatomy), EVM contracts are
+identified by their Ethereum address.
+
+### WASM Root Contract List
+
+EVM contracts are not listed in the chain's [contract registry](/wasp-wasm/reference/core-contracts/root).
+
+### On-ledger Requests
+
+EVM contracts cannot be called via regular ISC requests; they can only be called through the JSON-RPC service.
+As a consequence, EVM contracts cannot receive [on-ledger requests](/learn/smart-contracts/invocation#on-ledger-requests).
+
+### Block Structure and Storage
+
+Unlike Ethereum's blockchain that houses the state in a Merkle tree, the EVM state resides in a raw form to prevent the
+duplication of efforts undertaken by the ISC layer.
+
+Any Ethereum transactions present in an ISC block are executed by
+the [`evm`](/wasp-wasm/reference/core-contracts/evm) [core contract](/wasp-wasm/reference/core-contracts/overview),
+updating the EVM state accordingly. An emulated Ethereum block is also created and stored to provide compatibility
+with EVM tools. As the emulated block is not part of a real Ethereum blockchain, some attributes of the blocks will
+contain dummy values (e.g. `stateRoot`, `nonce`, etc.).
+
+Each stored block contains the executed Ethereum transactions and corresponding Ethereum receipts. If storage is
+limited, you can configure EVM so that only the latest N blocks are stored.
+
+### No Enforced Block Time
+
+There is no guaranteed _block time_. A new EVM "block" will be created only when an ISC block is created, and ISC does
+not enforce an average block time. This means that block times are variable; a new block will be created as soon as needed. The average block time in the [Public Testnet](/build/networks-endpoints#public-testnet) is 8.4 seconds.
+
+### L2 Token Ownership
+
+In the IOTA Smart Contract chain, both IOTA and Ethereum addresses are a valid `AgentID`, facilitating the ownership of L2
+tokens.
+
+### Retrieving the Ethereum Balance
+
+The Ethereum balance of an account is tied to its L2 ISC balance in the token used to pay for gas. For example,
+by default `eth_getBalance` will return the L2 base token balance of the given Ethereum account.
+
+### The Magic Contract
+
+A [dedicated Ethereum contract](../how-tos/magic-contract/magic.md) exists to manage ISC tokens and generally avail ISC
+functionalities, introducing commands like `isc.send(...)` for token transfers.
+
+### Gas Fees
+
+The used EVM gas is converted to ISC gas before being charged to the sender. The conversion ratio is configurable. The
+token used to pay for gas is the same token configured in the ISC chain (the L1's base token by default). The gas fee is debited from
+the sender's L2 account and must be deposited beforehand.
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/tooling.md b/docs/build/wasp-evm/0.7.0/docs/getting-started/compatible-tools.md
similarity index 91%
rename from docs/build/wasp/0.7.0/docs/guide/evm/tooling.md
rename to docs/build/wasp-evm/0.7.0/docs/getting-started/compatible-tools.md
index c3d024a38d9..d30f0b47721 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/tooling.md
+++ b/docs/build/wasp-evm/0.7.0/docs/getting-started/compatible-tools.md
@@ -17,7 +17,7 @@ keywords:
---
-# EVM Tooling
+# Compatible Tools
EVM on IOTA Smart Contracts has been integrated in a way that the existing EVM tooling is compatible and can be used
directly with an IOTA Smart Contracts chain running EVM as long as you take a couple of things into account.
@@ -63,16 +63,16 @@ let your wallet interact with web applications utilizing an EVM chain (dApps).
To use your EVM chain with MetaMask, simply open up MetaMask and click on the network drop-down list at the very top. At
the bottom of this list, you will see the option `Add network`. On the new page you will see a list of popular network with the option `Add a network manually`.
-For example this would be the config to add the ShimmerEVM testnet:
+For example this would be the config to add the [Public Testnet](/build/networks-endpoints/#public-testnet):
-- Network Name: `ShimmerEVM Testnet`
+- Network Name: `Public Testnet`
- New RPC URL: `https://json-rpc.evm.testnet.shimmer.network/`
- Chain ID: `1072`
- Currency Symbol: `SMR`
- Block Explorer URL: `https://explorer.evm.testnet.shimmer.network/`
Ensure that your `RPC Url` and `Chain ID` are set correctly and match the dashboard values. The `Network Name` can be
-whatever you see fit. Click "Save" to add the ShimmerEVM Testnet to MetaMask.
+whatever you see fit. Click "Save" to add the [Public Testnet](/build/networks-endpoints/#public-testnet) to MetaMask.
If you wish to use additional EVM chains with Metamask, you can add more Custom RPC networks, as long as they have a
unique `Chain ID` and `RPC Url`. Once you have done this, you can start using MetaMask to manage your EVM wallet or
@@ -93,9 +93,9 @@ the `Custom (1074) network`.
[](https://user-images.githubusercontent.com/7383572/146169653-fd692eab-6e74-4b17-8833-bd87dafc0ce2.png)
-## Video Tutorial
+### Video Tutorial
-
+
## Hardhat
@@ -120,7 +120,7 @@ often offered through block explorer APIs.
:::
-## Video Tutorial
+### Video Tutorial
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/quickstart.mdx b/docs/build/wasp-evm/0.7.0/docs/getting-started/quickstart.mdx
similarity index 56%
rename from docs/build/wasp/0.7.0/docs/guide/evm/quickstart.mdx
rename to docs/build/wasp-evm/0.7.0/docs/getting-started/quickstart.mdx
index a79ea922b59..bdd952ad2f7 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/quickstart.mdx
+++ b/docs/build/wasp-evm/0.7.0/docs/getting-started/quickstart.mdx
@@ -1,5 +1,5 @@
---
-description: This guide will help you quickly get started with the ShimmerEVM Testnet
+description: This guide will help you quickly get started with the [Public Testnet](/build/networks-endpoints/#public-testnet)
image: /img/logo/WASP_logo_dark.png
keywords:
- quickstart
@@ -15,9 +15,9 @@ keywords:
import AddToMetaMaskButton from '@theme/AddToMetaMaskButton';
-# ShimmerEVM Testnet Quickstart Guide
+# Public Testnet Quickstart Guide
-This guide will help you quickly get started with the ShimmerEVM Testnet, where you can deploy and interact with EVM-compatible smart contracts on the Shimmer Testnet.
+This guide will help you quickly get started with the [Public Testnet](/build/networks-endpoints/#public-testnet), where you can deploy and interact with EVM-compatible smart contracts on the Shimmer Testnet.
## Prerequisites
@@ -29,11 +29,11 @@ Click this button:
-Please read [this MetaMask guide](./tooling.md#metamask) for a detailed guidance.
+Please read [this MetaMask guide](./compatible-tools.md#metamask) for a detailed guidance.
## Get Testnet SMR Tokens
-1. Go to the [ShimmerEVM Testnet Toolkit](https://evm-toolkit.evm.testnet.shimmer.network/).
+1. Go to the [Public Testnet Toolkit](https://evm-toolkit.evm.testnet.shimmer.network/).
2. Connect your MetaMask wallet by clicking "Connect Wallet" or paste an EVM address.
3. Select the account you want to receive testnet SMR tokens.
4. Click "Send funds" to get testnet SMR tokens.
@@ -48,20 +48,20 @@ Please read [this MetaMask guide](./tooling.md#metamask) for a detailed guidance
## Deploy and Interact with Smart Contracts
-You can now use your testnet SMR tokens and simulated bridged tokens to deploy and interact with smart contracts on the ShimmerEVM Testnet. Utilize popular development tools and frameworks, such as [Truffle](https://www.trufflesuite.com/), [Hardhat](https://hardhat.org/), or [Remix](https://remix.ethereum.org/), to build, test, and deploy your smart contracts.
+You can now use your testnet SMR tokens and simulated bridged tokens to deploy and interact with smart contracts on the [Public Testnet](/build/networks-endpoints/#public-testnet). Utilize popular development tools and frameworks, such as [Truffle](https://www.trufflesuite.com/), [Hardhat](https://hardhat.org/), or [Remix](https://remix.ethereum.org/), to build, test, and deploy your smart contracts.
-## Explore the ShimmerEVM Testnet
+## Explore the Public Testnet
-Visit the [ShimmerEVM Testnet Block Explorer](https://explorer.evm.testnet.shimmer.network/) to monitor the chain, track transactions, and explore deployed smart contracts.
+Visit the [Public Testnet Block Explorer](https://explorer.evm.testnet.shimmer.network/) to monitor the chain, track transactions, and explore deployed smart contracts.
## Additional Resources
- [Wasp GitHub repository](https://github.com/iotaledger/wasp) (smart contracts node implementation)
- [Standalone Wasp dashboard](https://dashboard.evm.testnet.shimmer.network/)
- [GitHub issues page for Wasp](https://github.com/iotaledger/wasp/issues)
-- [Wiki article on configuring wasp-cli](https://wiki.shimmer.network/docs/node-software/wasp-cli)
+- [Wiki article on configuring wasp-cli](/wasp-cli/how-tos/wasp-cli/)
- [EVM toolkit](https://toolkit.evm.testnet.shimmer.network/)
- [ERC20 simulated token faucet](https://erc20-faucet.evm.testnet.shimmer.network/)
- [GitHub Firefly Desktop 2.1.0 Beta 6](https://github.com/iotaledger/firefly/releases)
-With this quickstart guide, you should now be able to set up and start exploring the ShimmerEVM Testnet. As you begin to deploy and interact with smart contracts, remember to provide feedback on any issues or improvements you discover to help make the ShimmerEVM even better. Happy developing!
+With this quickstart guide, you should now be able to set up and start exploring the [Public Testnet](/build/networks-endpoints/#public-testnet). As you begin to deploy and interact with smart contracts, remember to provide feedback on any issues or improvements you discover to help make the ShimmerEVM even better. Happy developing!
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC20.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/ERC20.md
similarity index 93%
rename from docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC20.md
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/ERC20.md
index 39d58e403f7..2b5467ab1cc 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC20.md
+++ b/docs/build/wasp-evm/0.7.0/docs/how-tos/ERC20.md
@@ -18,14 +18,14 @@ keywords:
- [Remix IDE](https://remix.ethereum.org/).
- [A Metamask Wallet](https://metamask.io/).
-- [Connect your MetaMask with the public Testnet](../../tooling#metamask).
+- [Connect your MetaMask with the public Testnet](../getting-started/compatible-tools.md#metamask).
### Required Prior Knowledge
This guide assumes you are familiar with [tokens](https://en.wikipedia.org/wiki/Cryptocurrency#Crypto_token)
in [blockchain](https://en.wikipedia.org/wiki/Blockchain),
[Ethereum Request for Comments (ERCs)](https://eips.ethereum.org/erc)(also known as Ethereum Improvement Proposals (EIP))
-, [NFTs](learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts), [Smart Contracts](/learn/smart-contracts/core_concepts/smart-contracts) and have
+, [NFTs](learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts), [Smart Contracts](/learn/smart-contracts/introduction) and have
already tinkered with [Solidity](https://docs.soliditylang.org/en/v0.8.16/).
ERC20 is a standard for fungible tokens and is defined in
the [EIP-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) by Ethereum.
@@ -39,7 +39,7 @@ You can use the [Remix IDE](https://remix.ethereum.org/) to deploy any regular S
Set the environment to `Injected Web3` and connect Remix with your MetaMask wallet.
If you haven’t already, please follow the instructions
-on [how to connect your MetaMask with the public Testnet.](../../tooling#metamask).
+on [how to connect your MetaMask with the public Testnet.](../getting-started/compatible-tools.md#metamask).
## 1. Create a Smart Contract
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC721.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/ERC721.md
similarity index 97%
rename from docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC721.md
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/ERC721.md
index 0a5ce8585f3..ca11ec7144c 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/examples/ERC721.md
+++ b/docs/build/wasp-evm/0.7.0/docs/how-tos/ERC721.md
@@ -25,7 +25,7 @@ NFTs.
- [Remix IDE](https://remix.ethereum.org/).
- [A Metamask Wallet](https://metamask.io/).
-- [Connect your MetaMask with the public Testnet](../../tooling#metamask).
+- [Connect your MetaMask with the public Testnet](../getting-started/compatible-tools.md#metamask).
### Required Prior Knowledge
@@ -33,7 +33,7 @@ This guide assumes you are familiar with [tokens](https://en.wikipedia.org/wiki/
in [blockchain](https://en.wikipedia.org/wiki/Blockchain),
[Ethereum Request for Comments (ERCs)](https://eips.ethereum.org/erc)(also known as Ethereum Improvement Proposals (
EIP))
-, [NFTs](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts), [Smart Contracts](/learn/smart-contracts/core_concepts/smart-contracts) and have
+, [NFTs](/learn/protocols/stardust/core-concepts/multi-asset-ledger#non-fungible-tokens-nfts), [Smart Contracts](/learn/smart-contracts/introduction) and have
already tinkered with [Solidity](https://docs.soliditylang.org/en/v0.8.16/).
## About ERC721
@@ -144,7 +144,7 @@ task. If you are using hardhat or truffle, you should customize the config file
### Connect to the ISC Testnet
You can find instructions on this in
-the [testnet endpoints section](/smart-contracts/testnet#endpoints).
+the [testnet endpoints section](/build/networks-endpoints/#testnet-evm).
### Change the Environment to Injected Web3
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/examples/introduction.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/create-a-basic-contract.md
similarity index 100%
rename from docs/build/wasp/0.7.0/docs/guide/evm/examples/introduction.md
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/create-a-basic-contract.md
diff --git a/docs/learn/smart-contracts/core_concepts/accounts/how-to-deposit-to-a-chain.mdx b/docs/build/wasp-evm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx
similarity index 93%
rename from docs/learn/smart-contracts/core_concepts/accounts/how-to-deposit-to-a-chain.mdx
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx
index 6eb1938aa70..e88da4ca3ea 100644
--- a/docs/learn/smart-contracts/core_concepts/accounts/how-to-deposit-to-a-chain.mdx
+++ b/docs/build/wasp-evm/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](../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-evm/0.7.0/docs/how-tos/magic-contract/call-a-function.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/call-a-function.md
new file mode 100644
index 00000000000..25d1c74cf69
--- /dev/null
+++ b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/call-a-function.md
@@ -0,0 +1,22 @@
+# Call a Function
+
+In the example above, `ISC.sandbox.getEntropy()` calls the
+[`getEntropy`](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L20)
+method of the `ISCSandbox` interface, which, in turn,
+calls [ISC Sandbox's](/learn/smart-contracts/sandbox) `GetEntropy`.
+
+```solidity
+pragma solidity >=0.8.5;
+
+import "@iota/iscmagic/ISC.sol";
+
+contract MyEVMContract {
+ event EntropyEvent(bytes32 entropy);
+
+ // this will emit a "random" value taken from the ISC entropy value
+ function emitEntropy() public {
+ bytes32 e = ISC.sandbox.getEntropy();
+ emit EntropyEvent(e);
+ }
+}
+```
diff --git a/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/call-a-native-contract.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/call-a-native-contract.md
new file mode 100644
index 00000000000..a6330f3ad27
--- /dev/null
+++ b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/call-a-native-contract.md
@@ -0,0 +1,25 @@
+# Call a Native Contract
+
+You can call native contracts using [`ISC.sandbox.call`](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L56):
+
+```solidity
+pragma solidity >=0.8.5;
+
+import "@iota/iscmagic/ISC.sol";
+
+contract MyEVMContract {
+ event EntropyEvent(bytes32 entropy);
+
+ function callInccounter() public {
+ ISCDict memory params = ISCDict(new ISCDictItem[](1));
+ bytes memory int64Encoded42 = hex"2A00000000000000";
+ params.items[0] = ISCDictItem("counter", int64Encoded42);
+ ISCAssets memory allowance;
+ ISC.sandbox.call(ISC.util.hn("inccounter"), ISC.util.hn("incCounter"), params, allowance);
+ }
+}
+```
+
+`ISC.util.hn` is used to get the `hname` of the `inccounter` contract and the
+`incCounter` entry point. You can also call view entry points using
+[ISC.sandbox.callView](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L59).
diff --git a/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/magic.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/magic.md
new file mode 100644
index 00000000000..49fd7150035
--- /dev/null
+++ b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/magic.md
@@ -0,0 +1,44 @@
+---
+description: The ISC Magic Contract allows EVM contracts to access ISC functionality.
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - configure
+ - using
+ - EVM
+ - magic
+ - Ethereum
+ - Solidity
+ - metamask
+ - JSON
+ - RPC
+---
+
+# The ISC Magic Contract
+
+[EVM and ISC are inherently very different platforms](../../getting-started/compatibility.md).
+Some EVM-specific actions (e.g., manipulating Ethereum tokens) are disabled, and EVM contracts can access ISC-specific
+functionality through the \_[ISC Magic Contract](../../reference/magic-contract.md)\_\_.
+
+The Magic contract is an EVM contract deployed by default on every ISC chain, in the EVM genesis block, at
+address `0x1074000000000000000000000000000000000000`.
+The implementation of the Magic contract is baked-in in
+the [`evm`](/wasp-wasm/reference/core-contracts/evm) [core contract](/wasp-wasm/reference/core-contracts/overview));
+i.e. it is not a pure-Solidity contract.
+
+The Magic contract has several methods, which are categorized into specialized
+interfaces: `ISCSandbox`, `ISCAccounts`, `ISCUtil` and so on.
+You can access these interfaces from any Solidity contract by importing
+the [ISC library](https://www.npmjs.com/package/@iota/iscmagic):
+
+```sh
+yarn add @iota/iscmagic
+```
+
+You can import it into your contracts like this:
+
+```solidity
+import "@iota/iscmagic/ISC.sol";
+```
+
+The Magic contract also provides proxy ERC20 contracts to manipulate ISC base
+tokens and native tokens on L2.
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/magic-uses.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/send-tokens-to-l1.md
similarity index 94%
rename from docs/build/wasp/0.7.0/docs/guide/evm/magic-uses.md
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/send-tokens-to-l1.md
index eecd828394b..d88e5fc6b2c 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/magic-uses.md
+++ b/docs/build/wasp-evm/0.7.0/docs/how-tos/magic-contract/send-tokens-to-l1.md
@@ -13,9 +13,7 @@ keywords:
- RPC
---
-# The ISC Magic Usage
-
-## Send Assets and Tokens to L1
+# Send Assets and Tokens to L1
:::info
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/using.md b/docs/build/wasp-evm/0.7.0/docs/how-tos/using.md
similarity index 93%
rename from docs/build/wasp/0.7.0/docs/guide/evm/using.md
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/using.md
index fdbde2c79e5..f7e526072a4 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/using.md
+++ b/docs/build/wasp-evm/0.7.0/docs/how-tos/using.md
@@ -15,11 +15,11 @@ keywords:
- how to
---
-# How to use EVM in IOTA Smart Contracts
+# How To Set Up EVM in IOTA Smart Contracts
## 1. Deploy an IOTA Smart Contracts Chain
-When [deploying an IOTA Smart Contracts chain](/wasp/setting-up-a-chain), EVM support is automatically
+When [deploying an IOTA Smart Contracts chain](/wasp-cli/how-tos/setting-up-a-chain/), EVM support is automatically
added with the default configuration. The `wasp-cli chain deploy` command accepts the following EVM-specific option:
- `--evm-chainid `: EVM chain ID (default: 1074).
diff --git a/docs/learn/smart-contracts/core_concepts/accounts/view-account-balances.mdx b/docs/build/wasp-evm/0.7.0/docs/how-tos/view-account-balances.mdx
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/accounts/view-account-balances.mdx
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/view-account-balances.mdx
diff --git a/docs/learn/smart-contracts/core_concepts/accounts/how-to-withdraw-from-a-chain.mdx b/docs/build/wasp-evm/0.7.0/docs/how-tos/withdraw-from-a-chain.mdx
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/accounts/how-to-withdraw-from-a-chain.mdx
rename to docs/build/wasp-evm/0.7.0/docs/how-tos/withdraw-from-a-chain.mdx
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/introduction.md b/docs/build/wasp-evm/0.7.0/docs/introduction.md
similarity index 67%
rename from docs/build/wasp/0.7.0/docs/guide/evm/introduction.md
rename to docs/build/wasp-evm/0.7.0/docs/introduction.md
index 22acd239610..62174b8544f 100644
--- a/docs/build/wasp/0.7.0/docs/guide/evm/introduction.md
+++ b/docs/build/wasp-evm/0.7.0/docs/introduction.md
@@ -14,13 +14,20 @@ keywords:
# EVM/Solidity Based Smart Contracts
-The current release of IOTA Smart Contracts has experimental support
-for [EVM](https://ethereum.org/en/developers/docs/evm/)/[Solidity](https://docs.soliditylang.org/en/v0.8.16/) smart
-contracts, as well as Wasm based smart contracts, providing limited compatibility with existing smart contracts and
+:::caution
+
+Smart Contracts are currently only compatible with the [Stardust protocol](/learn/protocols/stardust/introduction) and
+therefore only compatible with the [Shimmer](/build/networks-endpoints/#shimmer) and
+[Public Testnet networks](/build/networks-endpoints/#public-testnet).
+
+:::
+
+The current release of IOTA Smart Contracts has support for [EVM](https://ethereum.org/en/developers/docs/evm/)/[Solidity](https://docs.soliditylang.org/en/v0.8.16/) smart
+contracts, as well as [Wasm](/wasp-wasm/introduction/) smart contracts, providing limited compatibility with existing smart contracts and
tooling from other EVM based chains like Ethereum. This allows us to offer the existing ecosystem around EVM/Solidity a
familiar alternative.
-### What is EVM/Solidity
+### What is EVM/Solidity?
[EVM](https://ethereum.org/en/developers/docs/evm/) stands for "Ethereum Virtual Machine" and is currently the tried and
tested virtual machine running most smart contract implementations.
@@ -28,8 +35,7 @@ tested virtual machine running most smart contract implementations.
[Solidity](https://soliditylang.org/) is the programming language of choice with EVM, which was created for this
specific purpose.
-The main benefit of using EVM/Solidity right now is its sheer amount of resources from years of development and
-experimentation on Ethereum. Many articles, tutorials, examples, and tools are available for EVM/Solidity, and the IOTA
+The main benefit of using EVM/Solidity right now is its sheer amount of resources from years of development andf
Smart Contracts implementation is fully compatible with all of them. If you have experience developing on other EVM
based chains, you will feel right at home. Any existing contracts you've written will probably need no (or very minimal)
changes to function on IOTA Smart Contracts.
@@ -37,7 +43,7 @@ changes to function on IOTA Smart Contracts.
### How IOTA Smart Contracts Work With EVM
Every deployed IOTA Smart Contracts chain automatically includes a core contract
-called [`evm`](/learn/smart-contracts/core_concepts/core_contracts/evm). This core contract is responsible for running EVM code and
+called [`evm`](/wasp-wasm/reference/core-contracts/evm/). This core contract is responsible for running EVM code and
storing the EVM state.
The Wasp node also provides a standard JSON-RPC service, which allows you to interact with the EVM layer using existing
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/accounts.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/accounts.md
similarity index 98%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/accounts.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/accounts.md
index 2f350e90e86..8c4976745b6 100644
--- a/docs/learn/smart-contracts/core_concepts/core_contracts/accounts.md
+++ b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/accounts.md
@@ -17,14 +17,14 @@ The `accounts` contract is one of the [core contracts](overview.md) on each IOTA
chain.
This contract keeps a consistent ledger of on-chain accounts in its state,
-i.e. [the L2 ledger](../accounts/how-accounts-work.md).
+i.e. [the L2 ledger](../../explanations/how-accounts-work.md).
---
## Entry Points
The `accounts` contract provides functions to deposit and withdraw tokens, information about the assets deposited on the
-chain, and the functionality to create and utilize foundries.
+chain, and the functionality to create and use foundries.
### `deposit()`
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/blob.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/blob.md
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/blob.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/blob.md
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/blocklog.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/blocklog.md
similarity index 98%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/blocklog.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/blocklog.md
index ae40afd5714..af6f4a9552e 100644
--- a/docs/learn/smart-contracts/core_concepts/core_contracts/blocklog.md
+++ b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/blocklog.md
@@ -21,7 +21,7 @@ status, receipts, block, and event details.
To avoid having a monotonically increasing state size, only the latest `N`
blocks (and their events and receipts) are stored. This parameter can be configured
-when [deploying the chain](/wasp/setting-up-a-chain).
+when [deploying the chain](/wasp-cli/how-tos/setting-up-a-chain/).
---
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/errors.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/errors.md
similarity index 99%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/errors.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/errors.md
index 10b4e3a382b..d3d3db383a8 100644
--- a/docs/learn/smart-contracts/core_concepts/core_contracts/errors.md
+++ b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/errors.md
@@ -13,7 +13,6 @@ keywords:
- ownership
- views
- reference
-
---
# The `errors` Contract
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/evm.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/evm.md
similarity index 98%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/evm.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/evm.md
index 9ff258d9e53..9c9cb0ea038 100644
--- a/docs/learn/smart-contracts/core_concepts/core_contracts/evm.md
+++ b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/evm.md
@@ -13,7 +13,6 @@ keywords:
- ownership
- views
- reference
-
---
# The `evm` Contract
@@ -21,11 +20,11 @@ keywords:
The `evm` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain.
The `evm` core contract provides the necessary infrastructure to accept Ethereum transactions and execute EVM code.
-It also includes the implementation of the [ISC Magic contract](/smart-contracts/guide/evm/magic).
+It also includes the implementation of the [ISC Magic contract](/wasp-evm/how-tos/magic-contract/magic).
:::note
-For more information about how ISC supports EVM contracts, refer to the [EVM](/smart-contracts/guide/evm/introduction) section.
+For more information about how ISC supports EVM contracts, refer to the [EVM](/wasp-evm/introduction/) section.
:::
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/governance.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/governance.md
similarity index 99%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/governance.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/governance.md
index 56a7f09bfe0..dd8faaa0ab6 100644
--- a/docs/learn/smart-contracts/core_concepts/core_contracts/governance.md
+++ b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/governance.md
@@ -16,7 +16,6 @@ keywords:
- chain info
- fee info
- reference
-
---
# The `governance` Contract
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/overview.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/overview.md
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/overview.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/overview.md
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/root.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/root.md
similarity index 99%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/root.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/root.md
index 14f945c7bb1..9ff834a509f 100644
--- a/docs/learn/smart-contracts/core_concepts/core_contracts/root.md
+++ b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/root.md
@@ -13,7 +13,6 @@ keywords:
- ownership
- views
- reference
-
---
# The `root` Contract
diff --git a/docs/learn/smart-contracts/core_concepts/core_contracts/xfer.md b/docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/xfer.md
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/core_contracts/xfer.md
rename to docs/build/wasp-evm/0.7.0/docs/reference/core-contracts/xfer.md
diff --git a/docs/build/wasp-evm/0.7.0/docs/reference/magic-contract.md b/docs/build/wasp-evm/0.7.0/docs/reference/magic-contract.md
new file mode 100644
index 00000000000..31ac1492e09
--- /dev/null
+++ b/docs/build/wasp-evm/0.7.0/docs/reference/magic-contract.md
@@ -0,0 +1,34 @@
+# Magic Contract
+
+- [Common type definitions](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCTypes.sol)
+- [ISC library](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISC.sol)
+- [ISCSandbox](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol)
+ interface, available at `ISC.sandbox`
+- [ISCAccounts](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCAccounts.sol)
+ interface, available at `ISC.accounts`
+- [ISCUtil](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCUtil.sol)
+ interface, available at `ISC.util`
+- [ERC20BaseTokens](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC20BaseTokens.sol)
+ contract, available at `ISC.baseTokens`
+ (address `0x1074010000000000000000000000000000000000`)
+- [ERC20NativeTokens](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC20NativeTokens.sol)
+ contract, available at `ISC.nativeTokens(foundrySN)` after being registered
+ by the foundry owner by calling
+ [`registerERC20NativeToken`](/wasp-wasm/reference/core-contracts/evm#registerERC20NativeToken)
+ (address `0x107402xxxxxxxx00000000000000000000000000` where `xxxxxxxx` is the
+ little-endian encoding of the foundry serial number)
+- [ERC20ExternalNativeTokens](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC20ExternalNativeTokens.sol)
+ contract, available at a dynamically assigned address after being registered
+ by the foundry owner by calling
+ [`registerERC20NativeTokenOnRemoteChain`](/wasp-wasm/reference/core-contracts/evm#registerERC20NativeTokenOnRemoteChain)
+ on the chain that controls the foundry.
+- [ERC721NFTs](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC721NFTs.sol)
+ contract, available at `ISC.nfts`
+ (address `0x1074030000000000000000000000000000000000`)
+- [ERC721NFTCollection](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC721NFTCollection.sol)
+ contract, available at `ISC.erc721NFTCollection(collectionID)`, after being
+ registered by calling [`registerERC721NFTCollection`](/wasp-wasm/reference/core-contracts/evm#registerERC721NFTCollection).
+
+There are some usage examples in
+the [ISCTest.sol](https://github.com/iotaledger/wasp/blob/develop/packages/evm/evmtest/ISCTest.sol) contract (used
+internally in unit tests).
diff --git a/docs/build/wasp-evm/0.7.0/sidebars.js b/docs/build/wasp-evm/0.7.0/sidebars.js
new file mode 100644
index 00000000000..2cec6dab601
--- /dev/null
+++ b/docs/build/wasp-evm/0.7.0/sidebars.js
@@ -0,0 +1,176 @@
+/**
+ * Creating a sidebar enables you to:
+ - create an ordered group of docs
+ - render a sidebar for each doc of that group
+ - provide next/previous navigation
+
+ The sidebars can be generated from the filesystem, or explicitly defined here.
+
+ Create as many sidebars as you want.
+ */
+
+module.exports = {
+ // By default, Docusaurus generates a sidebar from the docs folder structure
+ //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
+
+ // But you can create a sidebar manually
+ evmSidebar: [
+ {
+ type: 'doc',
+ label: 'Introduction',
+ id: 'introduction',
+ },
+ {
+ type: 'category',
+ label: 'Getting Started',
+ items: [
+ {
+ type: 'doc',
+ label: 'Quickstart',
+ id: 'getting-started/quickstart',
+ },
+ {
+ type: 'doc',
+ label: 'Compatible Tools',
+ id: 'getting-started/compatible-tools',
+ },
+ {
+ type: 'doc',
+ label: 'Compatibility & Limitations',
+ id: 'getting-started/compatibility',
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Explanations',
+ items: [
+ {
+ type: 'doc',
+ label: 'How Accounts Work',
+ id: 'explanations/how-accounts-work',
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'How To',
+ items: [
+ {
+ type: 'doc',
+ label: 'Use EVM in ISC',
+ id: 'how-tos/using',
+ },
+ {
+ type: 'doc',
+ label: 'Create a Basic Contract',
+ id: 'how-tos/create-a-basic-contract',
+ },
+ {
+ type: 'doc',
+ label: 'Create Custom Tokens',
+ id: 'how-tos/ERC20',
+ },
+ {
+ type: 'doc',
+ label: 'Create NFTs',
+ id: 'how-tos/ERC721',
+ },
+ {
+ type: 'category',
+ label: 'Use the Magic Contract',
+ items: [
+ {
+ type: 'doc',
+ label: 'Introduction',
+ id: 'how-tos/magic-contract/magic',
+ },
+ {
+ type: 'doc',
+ label: 'Call a Function',
+ id: 'how-tos/magic-contract/call-a-function',
+ },
+ {
+ type: 'doc',
+ label: 'Call a Native Contract',
+ id: 'how-tos/magic-contract/call-a-native-contract',
+ },
+ {
+ type: 'doc',
+ label: 'Send Tokens to L1',
+ id: 'how-tos/magic-contract/send-tokens-to-l1',
+ },
+ {
+ 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',
+ label: 'Reference',
+ items: [
+ 'reference/magic-contract',
+ {
+ type: 'category',
+ label: 'Core Contracts',
+ items: [
+ {
+ type: 'doc',
+ label: 'Overview',
+ id: 'reference/core-contracts/overview',
+ },
+ {
+ type: 'doc',
+ label: 'root',
+ id: 'reference/core-contracts/root',
+ },
+ {
+ type: 'doc',
+ label: 'accounts',
+ id: 'reference/core-contracts/accounts',
+ },
+ {
+ type: 'doc',
+ label: 'blob',
+ id: 'reference/core-contracts/blob',
+ },
+ {
+ type: 'doc',
+ label: 'blocklog',
+ id: 'reference/core-contracts/blocklog',
+ },
+ {
+ type: 'doc',
+ label: 'governance',
+ id: 'reference/core-contracts/governance',
+ },
+ {
+ type: 'doc',
+ label: 'errors',
+ id: 'reference/core-contracts/errors',
+ },
+ {
+ type: 'doc',
+ label: 'evm',
+ id: 'reference/core-contracts/evm',
+ },
+ ],
+ },
+ ],
+ },
+ ],
+};
diff --git a/docs/build/wasp/0.7.0/static/.nojekyll b/docs/build/wasp-evm/0.7.0/static/.nojekyll
similarity index 100%
rename from docs/build/wasp/0.7.0/static/.nojekyll
rename to docs/build/wasp-evm/0.7.0/static/.nojekyll
diff --git a/docs/build/wasp/0.7.0/static/img/Banner/banner_wasp.png b/docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/Banner/banner_wasp.png
rename to docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp.png
diff --git a/docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_core_concepts_architecture.png b/docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_core_concepts_architecture.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_core_concepts_architecture.png
rename to docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_core_concepts_architecture.png
diff --git a/docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_core_concepts_smart_contracts.png b/docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_core_concepts_smart_contracts.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_core_concepts_smart_contracts.png
rename to docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_core_concepts_smart_contracts.png
diff --git a/docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_core_contracts_overview.png b/docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_core_contracts_overview.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_core_contracts_overview.png
rename to docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_core_contracts_overview.png
diff --git a/docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_using_docker.png b/docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_using_docker.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/Banner/banner_wasp_using_docker.png
rename to docs/build/wasp-evm/0.7.0/static/img/Banner/banner_wasp_using_docker.png
diff --git a/docs/build/wasp/0.7.0/static/img/chain0.png b/docs/build/wasp-evm/0.7.0/static/img/chain0.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/chain0.png
rename to docs/build/wasp-evm/0.7.0/static/img/chain0.png
diff --git a/docs/build/wasp/0.7.0/static/img/chain1.png b/docs/build/wasp-evm/0.7.0/static/img/chain1.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/chain1.png
rename to docs/build/wasp-evm/0.7.0/static/img/chain1.png
diff --git a/docs/build/wasp/0.7.0/static/img/contributing/golintci-goland-1.png b/docs/build/wasp-evm/0.7.0/static/img/contributing/golintci-goland-1.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/contributing/golintci-goland-1.png
rename to docs/build/wasp-evm/0.7.0/static/img/contributing/golintci-goland-1.png
diff --git a/docs/build/wasp/0.7.0/static/img/contributing/golintci-goland-2.png b/docs/build/wasp-evm/0.7.0/static/img/contributing/golintci-goland-2.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/contributing/golintci-goland-2.png
rename to docs/build/wasp-evm/0.7.0/static/img/contributing/golintci-goland-2.png
diff --git a/docs/build/wasp/0.7.0/static/img/contributing/golintci-goland-3.png b/docs/build/wasp-evm/0.7.0/static/img/contributing/golintci-goland-3.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/contributing/golintci-goland-3.png
rename to docs/build/wasp-evm/0.7.0/static/img/contributing/golintci-goland-3.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/examples/compile.png b/docs/build/wasp-evm/0.7.0/static/img/evm/examples/compile.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/examples/compile.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/examples/compile.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/examples/deploy-metamask.png b/docs/build/wasp-evm/0.7.0/static/img/evm/examples/deploy-metamask.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/examples/deploy-metamask.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/examples/deploy-metamask.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/examples/deploy.png b/docs/build/wasp-evm/0.7.0/static/img/evm/examples/deploy.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/examples/deploy.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/examples/deploy.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/examples/erc20-balance.png b/docs/build/wasp-evm/0.7.0/static/img/evm/examples/erc20-balance.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/examples/erc20-balance.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/examples/erc20-balance.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/examples/explorer-contract-address.png b/docs/build/wasp-evm/0.7.0/static/img/evm/examples/explorer-contract-address.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/examples/explorer-contract-address.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/examples/explorer-contract-address.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/ozw-721.png b/docs/build/wasp-evm/0.7.0/static/img/evm/ozw-721.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/ozw-721.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/ozw-721.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/remix-721-deploy.png b/docs/build/wasp-evm/0.7.0/static/img/evm/remix-721-deploy.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/remix-721-deploy.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/remix-721-deploy.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/remix-721.png b/docs/build/wasp-evm/0.7.0/static/img/evm/remix-721.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/remix-721.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/remix-721.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/remix-deployed.png b/docs/build/wasp-evm/0.7.0/static/img/evm/remix-deployed.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/remix-deployed.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/remix-deployed.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/remix-metamask-detail.png b/docs/build/wasp-evm/0.7.0/static/img/evm/remix-metamask-detail.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/remix-metamask-detail.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/remix-metamask-detail.png
diff --git a/docs/build/wasp/0.7.0/static/img/evm/remix-vm-injected.png b/docs/build/wasp-evm/0.7.0/static/img/evm/remix-vm-injected.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/evm/remix-vm-injected.png
rename to docs/build/wasp-evm/0.7.0/static/img/evm/remix-vm-injected.png
diff --git a/docs/build/wasp/0.7.0/static/img/logo/WASP_logo_dark.png b/docs/build/wasp-evm/0.7.0/static/img/logo/WASP_logo_dark.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/logo/WASP_logo_dark.png
rename to docs/build/wasp-evm/0.7.0/static/img/logo/WASP_logo_dark.png
diff --git a/docs/build/wasp/0.7.0/static/img/logo/WASP_logo_light.png b/docs/build/wasp-evm/0.7.0/static/img/logo/WASP_logo_light.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/logo/WASP_logo_light.png
rename to docs/build/wasp-evm/0.7.0/static/img/logo/WASP_logo_light.png
diff --git a/docs/build/wasp/0.7.0/static/img/metamask.png b/docs/build/wasp-evm/0.7.0/static/img/metamask.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/metamask.png
rename to docs/build/wasp-evm/0.7.0/static/img/metamask.png
diff --git a/docs/build/wasp/0.7.0/static/img/metamask_network.png b/docs/build/wasp-evm/0.7.0/static/img/metamask_network.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/metamask_network.png
rename to docs/build/wasp-evm/0.7.0/static/img/metamask_network.png
diff --git a/docs/build/wasp/0.7.0/static/img/metamask_testnet.png b/docs/build/wasp-evm/0.7.0/static/img/metamask_testnet.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/metamask_testnet.png
rename to docs/build/wasp-evm/0.7.0/static/img/metamask_testnet.png
diff --git a/docs/build/wasp/0.7.0/static/img/multichain.png b/docs/build/wasp-evm/0.7.0/static/img/multichain.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/multichain.png
rename to docs/build/wasp-evm/0.7.0/static/img/multichain.png
diff --git a/docs/build/wasp/0.7.0/static/img/sandbox.png b/docs/build/wasp-evm/0.7.0/static/img/sandbox.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/sandbox.png
rename to docs/build/wasp-evm/0.7.0/static/img/sandbox.png
diff --git a/docs/build/wasp/0.7.0/static/img/tutorial/SC-structure.png b/docs/build/wasp-evm/0.7.0/static/img/tutorial/SC-structure.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/tutorial/SC-structure.png
rename to docs/build/wasp-evm/0.7.0/static/img/tutorial/SC-structure.png
diff --git a/docs/build/wasp/0.7.0/static/img/tutorial/accounts.png b/docs/build/wasp-evm/0.7.0/static/img/tutorial/accounts.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/tutorial/accounts.png
rename to docs/build/wasp-evm/0.7.0/static/img/tutorial/accounts.png
diff --git a/docs/build/wasp/0.7.0/static/img/tutorial/call_view.png b/docs/build/wasp-evm/0.7.0/static/img/tutorial/call_view.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/tutorial/call_view.png
rename to docs/build/wasp-evm/0.7.0/static/img/tutorial/call_view.png
diff --git a/docs/build/wasp/0.7.0/static/img/tutorial/send_request.png b/docs/build/wasp-evm/0.7.0/static/img/tutorial/send_request.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/tutorial/send_request.png
rename to docs/build/wasp-evm/0.7.0/static/img/tutorial/send_request.png
diff --git a/docs/build/wasp/0.7.0/static/img/wasm_vm/IscHost.png b/docs/build/wasp-evm/0.7.0/static/img/wasm_vm/IscHost.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/wasm_vm/IscHost.png
rename to docs/build/wasp-evm/0.7.0/static/img/wasm_vm/IscHost.png
diff --git a/docs/build/wasp/0.7.0/static/img/wasm_vm/Proxies.png b/docs/build/wasp-evm/0.7.0/static/img/wasm_vm/Proxies.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/wasm_vm/Proxies.png
rename to docs/build/wasp-evm/0.7.0/static/img/wasm_vm/Proxies.png
diff --git a/docs/build/wasp/0.7.0/static/img/wasm_vm/WasmVM.png b/docs/build/wasp-evm/0.7.0/static/img/wasm_vm/WasmVM.png
similarity index 100%
rename from docs/build/wasp/0.7.0/static/img/wasm_vm/WasmVM.png
rename to docs/build/wasp-evm/0.7.0/static/img/wasm_vm/WasmVM.png
diff --git a/docs/build/wasp-wasm/0.7.0/docs/explanations/context.mdx b/docs/build/wasp-wasm/0.7.0/docs/explanations/context.mdx
new file mode 100644
index 00000000000..399bd1d57ab
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/explanations/context.mdx
@@ -0,0 +1,50 @@
+---
+description: The call context is a predefined parameter to each smart contract function, which allows you to access the functionality that the call environment provides.
+keywords:
+ - WasmLib
+ - smart contract setup
+ - Func and View functions
+ - ScFuncContext
+ - ScViewContext
+ - Schema Tool
+image: /img/logo/WASP_logo_dark.png
+---
+
+# Call Context
+
+Understanding the call context is vital in leveraging the Wasm code within a sandboxed host environment effectively. The following section explains the distinction between different function calls and the role of WasmLib in setting up a smart contract.
+
+## Function Calls: Func and View
+
+Smart contract function calls come in two types, each having specific access levels to the smart contract state:
+
+### Funcs
+
+Func functions grants full mutable access, resulting in a state update. They accommodate both on-ledger and off-ledger requests, finalized once the state update is registered in the Tangle ledger.
+
+### Views
+
+View functions allow limited immutable access, **no state update occurs**. Views are ideal for quickly querying the contract's current state, they only facilitate off-ledger calls.
+
+## Using Func and View
+
+WasmLib offers distinct contexts for these function types, namely `ScFuncContext` for Func and `ScViewContext` for View, controlling the accessible functionality and enforcing usage constraints through compile-time type-checking.
+
+## Smart Contract Setup with WasmLib
+
+Setting up a smart contract requires the following:
+
+### Defining Funcs and Views
+
+Outline available Funcs and Views and communicate them to the host through WasmLib.
+It ensures the correct dispatch of function calls and maintains necessary restrictions.
+
+### Parameter and Return Value Determination
+
+Establish the parameters and return values for each function. ISC uses simple dictionaries to store details, necessitating consistent (de)serialization handled adeptly by WasmLib.
+
+### Utilizing Schema Tool
+
+Although you can use the WasmLib directly, the Schema Tool is recommended for automatically generating and updating the smart contract framework in a type-safe manner, using the preferred language.
+
+Grasping these concepts will facilitate a secure and efficient smart contract setup, steering clear of potential pitfalls while making the most of what WasmLib offers.
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
new file mode 100644
index 00000000000..7c3476e4a6f
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/explanations/how-accounts-work.md
@@ -0,0 +1,99 @@
+---
+description: 'IOTA Smart Contracts chains keeps a ledger of on-chain account balances. On-chain accounts are identified
+by an AgentID.'
+image: /img/tutorial/accounts.png
+keywords:
+
+- smart contracts
+- on-chain account
+- ownership
+- accounts Contract
+- explanation
+
+---
+
+# How Accounts Work
+
+On the L1 Ledger, like with any DLT, we have **trustless** and **atomic** transfers of assets between addresses on the
+ledger.
+
+Tokens controlled by an address can be moved to another address by providing a valid signature using the private key
+that controls the source address.
+
+In IOTA Smart Contracts, [each chain has a L1 address](/learn/smart-contracts/states#digital-assets-on-the-chain) (also known as the _Chain
+ID_) which enables it to control L1 assets (base tokens, native tokens and NFTs).
+The chain acts as a custodian of the L1 assets on behalf of different entities, thus providing a _L2 Ledger_.
+
+The L2 ledger is a collection of _on-chain accounts_ (sometimes called just _accounts_).
+L2 accounts can be owned by different entities, identified by a unique _Agent ID_.
+The L2 ledger is a mapping of Agent ID => balances of L2 assets.
+
+## Types of Accounts
+
+### L1 Address
+
+Any L1 address can be the owner of a L2 account.
+The Agent ID of an L1 address is just the address,
+
+e.g. `iota1pr7vescn4nqc9lpvv37unzryqc43vw5wuf2zx8tlq2wud0369hjjugg54mf`.
+
+Tokens in an address account can only be moved through a request signed by the private key of the L1 address.
+
+### Smart Contract
+
+Any smart contract can be the owner of a L2 account. Recall that a smart
+contract is uniquely identified in a chain by a [_hname_](/learn/smart-contracts/smart-contract-anatomy#identifying-a-smart-contract).
+However, the hname is not enough to identify the account since a smart contract on another chain could own it.
+
+Thus, the Agent ID of a smart contract is composed as the contract hname plus the [_chain
+ID_](/learn/smart-contracts/states#digital-assets-on-the-chain), with syntax `@`. For
+example: `cebf5908@tgl1pzehtgythywhnhnz26s2vtpe2wy4y64pfcwkp9qvzhpwghzxhwkps2tk0nd`.
+
+Note that this allows trustless transfers of assets between smart contracts on the same or different chains.
+
+Tokens in a smart contract account can only be moved by that smart contract.
+
+### The Common Account
+
+The chain owns a unique L2 account, called the _common account_.
+The common account is controlled by the chain owner (defined in the chain root contract) and is used to store funds
+collected by fees or sent to the chain L1 address.
+
+The Agent ID of the common account is `@`.
+
+### Ethereum Address
+
+An L2 account can also be owned by an Ethereum address. See [EVM](/wasp-evm/introduction/) for more information.
+The Agent ID of an Ethereum address is just the address prefixed with `0x`,
+e.g. `0xd36722adec3edcb29c8e7b5a47f352d701393462`.
+
+Tokens in an Ethereum account can only be moved by sending an Ethereum transaction signed by the same address.
+
+## The Accounts Contract
+
+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/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
+
+The following diagram illustrates an example situation.
+The the IDs and hnames are shortened for simplicity.
+
+[](/img/tutorial/accounts.png)
+
+Two chains are deployed, with IDs `chainA` and `chainB`.
+`chainA` has two smart contracts on it (with hnames `3037` and `2225`), and `chainB` has one smart contract (`7003`).
+
+There is also an address on the L1 Ledger: `iota1a2b3c4d`.
+This address controls 1337 base tokens and 42 `Red` native tokens on the L1 Ledger.
+
+The same address also controls 42 base tokens on `chainA` and 8 `Green` native tokens on `chainB`.
+
+So, the owner of the private key behind the address controls three different accounts: the L1 account and one L2 account
+on each chain.
+
+Smart contract `7003@chainB` has five base tokens on its native chain and controls eleven base tokens on chain A.
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
new file mode 100644
index 00000000000..f8b01261e92
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/explanations/proxies.mdx
@@ -0,0 +1,77 @@
+---
+keywords:
+ - proxies
+ - sandbox
+ - wasm
+ - value proxies
+ - container proxies
+ - array proxies
+ - map proxies
+ - explanation
+description: As there is no way for the Wasm code to access any memory outside its own memory space, the WasmLib interface provides a number of proxies to make accessing data within the ISC sandbox as seamless as possible.
+image: /img/wasm_vm/Proxies.png
+---
+
+# Data Access Proxies
+
+To interact seamlessly with the ISC sandbox's regulated environment and facilitate smart contract data access,
+the WasmLib introduces data access proxies.
+Proxies are objects that can perform the underlying data transfers between the
+separate systems.
+
+## Overview
+
+The restrictive ISC sandbox environment requires an intermediary, or a library, to access sandbox functionalities — a role that the WasmLib fulfills through data access `proxies`.
+These entities stand as bridges, enabling data transfers between segregated systems, providing a streamlined pathway to interact with smart contract data stored on the ISC host.
+
+## The Role of Proxies
+
+Proxies refer to actual objects or values housed in the ISC host,
+essentially acting as data references that understand how to manipulate the data they represent.
+At the core, data is secured in maps on the ISC host with byte strings serving as both keys and values.
+
+The WasmLib recognizes three predefined maps:
+
+- **[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](../how-tos/schema-tool/usage.mdx),
+although, fundamentally, this structure is rooted in simple key-value access on the underlying map.
+
+## Proxy Varieties
+
+Proxies are segmented into various categories to facilitate different functionalities, including value proxies and container proxies.
+
+### Value Proxies
+
+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](../how-tos/schema-tool/usage.mdx) ensures type-safe code generation, always selecting the suitable proxy type.
+
+### Container Proxies
+
+Container proxies offer a virtual nesting system on the underlying map,
+creating paths leading to value proxies housed in a virtual container.
+They use JSON and YAML nesting patterns, and there are two primary types:
+
+#### 1. Map Proxies
+
+- **Root Maps:** Encase any element type but restrict keys to human-readable strings, which are defined in the schema definition file.
+- **Virtual Maps:** Resides under a root map and accommodates values of a single associated data type.
+
+#### 2. Array Proxies
+
+- Operate as a specialized map where the key is an Int32 value, forming a sequence from 0 to N-1 for an array harboring N elements.
+
+## Proxies in Action
+
+
+
+In the illustration, we see the key-value combinations (Key 1 to Key 4) in the ISC state storage map. Key 4 directs us to an array containing indexed values ranging from 0 to N.
+
+Notice the precise reflection of these elements in the WasmLib proxies,
+which maintain a container proxy for every container and a value proxy for each stored value.
+However, it is not obligatory for a smart contract function to define a proxy for every value or container in the ISC state storage.
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx
new file mode 100644
index 00000000000..e88da4ca3ea
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/deposit-to-a-chain.mdx
@@ -0,0 +1,78 @@
+---
+description: The `deposit` entry point credits the transferred tokens into your on-chain account.
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - smart contracts
+ - deposit
+ - transfer
+ - chain
+ - Rust
+ - Solo
+ - how to
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# How to Deposit to a Chain
+
+Any assets attached to an on-ledger request are automatically deposited to the sender's L2 account before executing the
+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
+this purpose.
+
+:::note Gas Fees
+
+All requests are charged a gas fee, so the L2 account may receive fewer tokens than the amount sent.
+
+:::
+
+:::info Storage Deposits
+
+The IOTA L1 transaction needs a minimum amount of tokens attached for
+storage deposit. It will fail if the amount transferred is less than this minimum amount.
+
+:::
+
+
+
+
+```go
+// deposits N base tokens from wallet into chain
+err := chain.DepositBaseTokensToL2(N, wallet)
+require.NoError(t, err)
+```
+
+
+
+
+```go
+// deposits N base tokens from wallet into chain
+d := coreaccounts.ScFuncs.Deposit(ctx.Sign(wallet))
+d.Func.TransferBaseTokes(N).Post()
+require.NoError(t, ctx.Err)
+```
+
+
+
+
+```rust
+// deposits N iotas from wallet into chain
+let d = coreaccounts::ScFuncs::deposit(ctx.sign(wallet));
+d.func.transfer_base_tokens(N).post();
+```
+
+
+
+
+```go
+// deposits N iotas from wallet into chain
+d := coreaccounts.ScFuncs.Deposit(ctx.Sign(wallet))
+d.Func.TransferBaseTokens(N).Post()
+```
+
+
+
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/access.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/access.mdx
new file mode 100644
index 00000000000..c084cad4762
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/access.mdx
@@ -0,0 +1,37 @@
+---
+description: "This article explains how to define access controls for functions using the optional 'access' subsection in the schema definition file."
+keywords:
+ - Access Control
+ - Schema Tool
+ - Smart Contract
+ - AgentID
+ - Function Access
+image: /img/logo/WASP_logo_dark.png
+---
+
+# Limit Access
+
+You can define function access controls through the optional `access` subsection in the schema definition file.
+By default, functions are accessible to everyone. However, when specified, the `access` identifier restricts who can
+call a function.
+
+## Access Identifiers
+
+You can set access identifiers with **one** of the following options:
+
+- `self`: Restricts access to the smart contract itself.
+- `chain`: Allows only the chain owner to invoke the function.
+- Other: Specify an AgentID or AgentID[] variable in state storage, controlling the agent(s) permitted to call the
+ function.
+ You should provide a mechanism to initialize and manage this variable.
+
+The [Schema Tool](../schema-tool/usage.mdx) handles the auto-generation of the code for access verification.
+
+## Usage Examples
+
+You can find examples in the schema definition file where the `owner` state variable operates as an access identifier.
+Functions such as `init` initialize the state variable, while `setOwner` can modify ownership,
+enhancing the security by limiting function access to the current owner.
+
+Remember to tailor access identifiers to individual functions as required,
+and establish multiple identifiers if necessary.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/call.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/call.mdx
similarity index 53%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/call.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/call.mdx
index 07ba8943a7d..781bea0b3a9 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/call.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/call.mdx
@@ -1,51 +1,74 @@
---
+description: "Explore how synchronous function calls work between smart contracts, highlighting the role of function descriptors in parameter and token passage, and understanding the ISC host's role in this procedure."
keywords:
- - value
- - Synchronous functions
- - function descriptor
- - smart contract chain
- - views
- - funcs
-
-description: Synchronous calls can only be made between contracts that are running on the same contract chain. When calling a smart contract function you can only access the memory assigned to that specific smart contract, the only way to share data between smart contracts that call each other is through function parameters and return values.
-
+ - Synchronous Calls
+ - Smart Contracts
+ - Function Descriptors
+ - ISC Host
+ - Function Parameters
+ - Smart Contract Memory
image: /img/logo/WASP_logo_dark.png
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Calling Functions
+# Call Functions
+
+Synchronous function calls between smart contracts act very similar to how normal function calls work in any programming language,
+but with a slight twist.
+With normal function calls, you share all the global memory that you can access with every function that you call.
+However, when calling a smart contract function,
+you can only access the memory assigned to that specific smart contract.
+
+## How Synchronous Calls Operate
+
+### Data Sharing
+
+If you want to share data between smart contracts, you will need to use:
+
+- Function [parameters](params.mdx)
+- [Return](results.mdx) values
+
+## The ISC Host Role
+
+Ensuring smooth synchronous calls between contracts on the same chain, the ISC host:
+
+- Recognizes all contracts functioning on a chain.
+- Directs the call appropriately to the destined contract function using function descriptors.
-Synchronous function calls between smart contracts act very similar to how normal function
-calls work in any programming language, but with a slight twist. With normal function
-calls you share all the global memory that you can access with every function that you
-call. However, when calling a smart contract function you can only access the memory
-assigned to that specific smart contract. Remember, each smart contract runs in its own
-sandbox environment. Therefore, the only way to share data between smart contracts that
-call each other is through function parameters and return values.
+### Function Descriptors
-Synchronous calls can only be made between contracts that are running on the same contract
-chain. The ISC host knows about all the contracts it is running on a chain, and therefore
-is able to dispatch the call to the correct contract function. The function descriptor is
-used to specify the call parameters (if any) through its [Params](params.mdx) proxy, and
-to invoke the function through its `func` interface.
+Function descriptors allow:
-In addition, when the function that is called is not a [View](views.mdx), it is possible
-to pass tokens to the function call through this interface. Note that the only way to call
-a function and properly pass tokens to it _within the same chain_ is through the function
-descriptor. Otherwise, the `allowance()` function will not register any incoming tokens.
+- Specification of call parameters via the [Params](params.mdx) proxy.
+- Function invocation through the `func` interface.
+- Passing tokens to non-[View](views.mdx) function calls within the same chain.
-When the call is made, the calling function will be paused and wait for the called
-function to complete. After completion, it may access the returned values (if any) through
-the [Results](results.mdx) proxy of the function descriptor.
+:::note
-When calling a function from a View function, it is only possible to call other View
-functions. The ScFuncs interface enforces this at compile-time because it expects an
-`ScViewContext` to be passed to the constructor that creates the function descriptor.
+The only way to call a function and properly pass tokens to it within the same chain is through the function descriptor.
+Otherwise, the allowance() function will not register any incoming tokens.
-Here's how a smart contract would tell a `dividend` contract on the same chain to divide
-the 1000 tokens it passes to the function:
+:::
+
+### Call Process
+
+During a call:
+
+- The initiator function pauses and awaits the completion of the called function.
+- Post-completion, retrieves potential returned values through the [Results](results.mdx) proxy.
+
+### Calling From View Functions
+
+When a view function initiates a call:
+
+- It can only reach out to other [view](views.mdx) functions.
+- The `ScFuncs` interface mandates an `ScViewContext` for the constructor creating the function descriptor.
+
+## Usage Example
+
+Here's how a smart contract would tell a `dividend` contract on the same chain to divide the 1000 tokens it passes to the function:
@@ -153,6 +176,3 @@ f.func.ofContract(altContract).transferBaseTokens(1000).call();
-
-In the next section we will look at how to use function descriptors to
-[asynchronously call](post.mdx) smart contract functions on any chain.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/events.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/events.mdx
similarity index 70%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/events.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/events.mdx
index 38821930123..939892bc6e8 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/events.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/events.mdx
@@ -1,50 +1,50 @@
---
+description: "This article outlines how to trigger events in smart contracts utilizing ISC sandbox's ScFuncContext and the Schema Tool for structured events."
keywords:
- - functions
- - state
- - structures
- - storage
- - named fields
-
-description: The smart contracts can trigger events that the user can subscribe to and that convey changes to its state.
-
+ - Smart Contracts
+ - ISC Sandbox
+ - Schema Tool
+ - Event-driven
+ - Call Context
+ - ScFuncContext
+ - Event Triggering
image: /img/logo/WASP_logo_dark.png
---
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-# Triggering Events
-
-Smart contracts do not live in a vacuum. Even though they run in a very limited sandbox,
-from a larger perspective there will have to be a way for users to interact with them.
-Since smart contracts are essentially event-driven, and requests run asynchronously from
-the user's perspective, there is a need for triggering events by the smart contracts
-themselves. Of course, it would be possible for users to periodically call a view function
-to retrieve the latest state of the smart contract, but this burdens the nodes
-unnecessarily. A better way is to have the smart contracts trigger events that the user
-can subscribe to and that convey changes to its state.
-
-To support events the ISC sandbox provides only a very rudimentary interface. The
-`ScFuncContext` [Call Context](context.mdx) exposes this interface through its `event()`
-function, which takes a completely arbitrary text string as parameter. It is up to the
-smart contract creator to format this text string in a meaningful way, and it's up to the
-user to interpret this text string correctly. This is error-prone, inconsistent, and means
-that a lot of code needs to be written both on the smart contract side that generates
-these events, and on the client side that handles these events. And with any change to the
-formatting of these events both ends need to be modified to stay in sync.
-
-This is why the [Schema Tool](usage.mdx) allows you to define your own structured events.
-The [Schema Tool](usage.mdx) will generate a structure that will become part of all Func
-function contexts. Events can only be triggered from within a Func. They will become part
-of the state of the smart contract because every event is logged in the core `blocklog`
-contract. Therefore, events cannot be triggered from within a View.
-
-For each event defined in the `events` section of the schema definition file, this events
-structure will contain a member function that takes the defined types of parameters and
-will automatically encode the event as a consistently formatted string and pass it to the
-`event()` function. The string consists of the name of the event, a timestamp, and string
-representations of each field, all separated by vertical bars.
+# Trigger Events
+
+Smart contracts operate in a confined environment but need a mechanism to interact with users.
+A solution to this is triggering events, which is facilitated through smart contracts.
+
+## ISC Sandbox Interface
+
+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](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.
+Note that events:
+
+- Can only be triggered within a Func
+- Become part of the smart contract's state
+- Are logged in the core `blocklog` contract
+- Cannot be triggered within a View
+
+## Event Structure
+
+Define each event in the `events` section of the schema definition file.
+This setup ensures that events are encoded consistently,
+utilizing a function that automatically formats the event string with the event name, timestamp, and parameter fields,
+delimited by vertical bars.
+This structured approach facilitates streamlined, error-resistant event triggering.
+
+### Example
Here is the `events` section that can be found in the demo `fairroulette` smart contract:
@@ -313,6 +313,3 @@ stream and respond to any events it deems noteworthy. The [Schema Tool](usage.md
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.
-
-In the next section we will explore how the [Schema Tool](usage.mdx) helps to simplify
-smart contract [function definitions](funcs.mdx).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/funcdesc.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcdesc.mdx
similarity index 86%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/funcdesc.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcdesc.mdx
index fa47a4684c6..01e8804e532 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/funcdesc.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcdesc.mdx
@@ -14,18 +14,33 @@ image: /img/logo/WASP_logo_dark.png
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Function Descriptors
+# Add Function Descriptors
-The [Schema Tool](usage.mdx) provides us with an easy way to get access to smart contract
-functions through _function descriptors_. These are structures that provide access to the
-optional [Params](params.mdx) and [Results](results.mdx) maps through strict compile-time
-checked interfaces. They will also allow you to initiate the function by calling it
-[synchronously](call.mdx), or posting a request to run it [asynchronously](post.mdx).
+You can use the [Schema Tool](../schema-tool/usage.mdx) to access, and initiate smart contract functions seamlessly using
+function descriptors.
+These descriptors allow you to access optional [Params](params.mdx) and [Results](results.mdx) maps through strict
+compile-time checked interfaces.
-The [Schema Tool](usage.mdx) will generate a specific function descriptor for each func
-and view. It will also generate an interface called ScFuncs, that can be used to create
-and initialize each function descriptor. Here is the code generated for the `dividend`
-example in `contract.xx`:
+## Function Descriptors Overview
+
+Function descriptors are structures that:
+
+- Offer access to the optional [Params](params.mdx) and [Results](results.mdx) maps.
+- Allow synchronous or asynchronous initiation of functions through [`call`](call.mdx) or [`post`](post.mdx) requests.
+
+## The Schema Tool in Action
+
+The Schema Tool performs the following tasks:
+
+### 1. **Generate Specific Descriptors**:
+
+- For each function (`func`) and view.
+- The outcome: Structs granting access to [Params](params.mdx) or [Results](results.mdx) maps, wherever specified.
+
+## 2. **Create the `ScFuncs` Interface**:
+
+- Facilitate the creation and initialization of each function descriptor.
+- Incorporate a member function for every func or view to craft their respective function descriptor properly.
@@ -374,14 +389,16 @@ export class ScFuncs {
-As you can see a struct has been generated for each of the Funcs and Views. The structs
-only provide access to the [Params](params.mdx) or [Results](results.mdx) maps when these
-are specified for the function. Each struct has a `func` member that can be used to
-initiate the function call in certain ways. The `func` member will be of type `ScFunc` or
-`ScView`, depending on whether the function is a func or a view.
+## `dividend` Example - Generated Code
+
+In the `dividend` example in `contract.xx`, specific structs for [Funcs and Views](../../explanations/proxies.mdx) are created.
+Here's how they operate:
+
+### Access
+
+- Via the `func` member within each struct.
+- The `func` member type: Either `ScFunc` or `ScView`, contingent on whether it’s a function or a view.
-The ScFuncs struct provides a member function for each func or view that will create their
-respective function descriptor, initialize it properly, and returns it.
+### Utilization
-In the next section we will look at how to use function descriptors to
-[synchronously call](call.mdx) smart contract functions on the same chain.
+- The `func` member is used to initiate function calls in various ways.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/funcs.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcs.mdx
similarity index 81%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/funcs.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcs.mdx
index 15dab2f70e5..8617de41678 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/funcs.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/funcs.mdx
@@ -8,17 +8,16 @@ keywords:
- results
image: /img/logo/WASP_logo_dark.png
-
description: The code generated for Funcs will be able to inspect and modify the smart contract state, whereas the code generated for Views will only be able to inspect the state.
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Function Definitions
+# Define Functions
Here is the full schema definition file for the `dividend` example. We will now focus on
-its `funcs` and `views` sections. 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.
@@ -68,18 +67,16 @@ views:
As you can see each of the `funcs` and `views` sections defines their functions in the
-same way. The only resulting difference is in the way the [Schema Tool](usage.mdx)
-generates code for them. The code generated for Funcs will be able to inspect and modify
-the smart contract state, whereas the code generated for Views will only be able to
-inspect the state.
+same way. The only resulting difference is in the way the [Schema Tool](../schema-tool/usage.mdx)
+generates code for them:
+
+- The code generated for Funcs will be able to inspect and modify the smart contract state.
+- The code generated for Views will only be able to inspect the state.
Functions are defined as named subsections in the schema definition file. The name of the
subsection will become the name of the function. In turn, there can be 3 optional
subsections under each function subsection.
-- `access` indicates who is allowed to access the function.
+- [`access`](access.mdx) indicates who is allowed to access the function.
- `params` holds the field definitions that describe the function parameters.
- `results` holds the field definitions that describe the function results.
-
-We will now examine each subsection in more detail. In the next section we will first look
-at the [`access`](access.mdx) subsection.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/init.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/init.mdx
similarity index 87%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/init.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/init.mdx
index da9299a3660..be98d8089de 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/init.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/init.mdx
@@ -9,28 +9,33 @@ keywords:
- contract deployment
description: The init function will automatically be called immediately after the first time the contract has been deployed to the VM. This is a one-time initialization call, meant to be performed by the contract deployment mechanism.
-
image: /img/logo/WASP_logo_dark.png
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Smart Contract Initialization
+# Initialize a Smart Contract
+
+Smart contracts begin with a blank slate. You can define an initial state through the `init()` function.
+This function is vital for setting configurations at the time of deployment.
+
+## Features of the `init()` Function
+
+### One-time Call
+
+Triggered automatically post-deployment, **it can only be used once** to set the initial configurations.
-Smart contracts start out with a completely blank state. Sometimes you may want to be able
-to define initial state, for example if your contract is configurable. You may want to be
-able to pass this configuration to the contract upon deployment, so that its state
-reflects that configuration once the first request comes in. Such initialization can be
-provided through an optional function named `init()`.
+### Security
-When provided, the `init()` function will automatically be called immediately after the
-first time the contract has been deployed to the VM. Note that this is a one-time
-initialization call, meant to be performed by the contract deployment mechanism. ISC will
-prevent anyone else from calling this function ever again. So if you need to be able to
-reconfigure the contract later on, you will need to provide a separate configuration
-function, and guard it from being accessed by anyone else than properly authorized
-entities.
+The ISC ensures the `init()` function is inaccessible after its initial execution,
+safeguarding it from unauthorized accesses.
+
+### Necessity For a Separate Configuration Function
+
+To facilitate reconfiguration in the future, develop a distinct configuration function with proper access controls.
+
+## Usage Example
To show how creating a smart contract with WasmLib works, we will slowly start fleshing
out the smart contract functions of the `dividend` example in this tutorial. Here is the
@@ -188,10 +193,10 @@ export function funcInit(ctx: wasmlib.ScFuncContext, f: sc.InitContext): void {
We define an owner variable and allow it to be something other than the default value of
-contract creator. It is always a good idea to be flexible enough to be able to transfer
+the contract creator. It is always a good idea to be flexible enough to transfer
ownership to another entity if necessary. Remember that once a smart contract has been
-deployed it is no longer possible to change it. Therefore, it is good practice thinking
-through situations that could require change in advance, and allow the contract itself to
+deployed it is no longer possible to change it. Therefore, it is good practice to think
+through situations that could require a change in advance and allow the contract itself to
handle such changes through its state by providing a proper function interface:
@@ -258,11 +263,7 @@ export function funcSetOwner(
-Note that we only define a single owner here. Proper fall-back could require multiple
-owners in case the owner entity could disappear, which would allow others to take over
-instead of the contract becoming immutable with regard to owner functionality. Again, we
-cannot stress enough how important it is to **think through every aspect of a smart
-contract before deployment**.
-
-In the next section we will look at how a smart contract can
-[transfer tokens](transfers.mdx).
+Note that we only define a single owner here.
+A proper fall-back could require multiple owners in case the owner entity could disappear,
+which would allow others to take over instead of the contract becoming immutable about the “owner functionality”.
+We cannot stress enough how important it is to **think through every aspect of a smart contract before deployment**.
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
new file mode 100644
index 00000000000..bc0e60ca51c
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/introduction.mdx
@@ -0,0 +1,62 @@
+# Introduction
+
+Smart contracts need robustness, combining both flexibility and stringent regulation to prevent mistakes and foster efficiency.
+Using the Schema Tool ensures consistency, and simplifies smart contract development.
+
+## Why Use the Schema Tool?
+
+### Ensure Robustness and Consistency
+
+By employing a code generator rooted in a schema definition file, you achieve:
+
+- **Reliability**: Through debugged, trustworthy generated code.
+- **Adaptability**: Facilitating modifications in the smart contract interface.
+- **Intent Reflection**: Enforcing defined smart contract behavior at compile-time.
+- **Multilingual Support**: Accommodating various programming languages.
+
+### Prevent Repetitive Coding
+
+Initial experiences illustrated repetitive coding in:
+
+- `on_load` function setup and maintenance.
+- Function access rights verification.
+- Function parameter type and presence confirmation.
+- Establishing access to State, Params, and Results maps.
+- Common string constant definitions.
+
+The schema tool diminishes redundancy and ensures up-to-date functionalities.
+
+## The Schema Definition File
+
+### Defining a Clear Interface
+
+The schema definition file serves as a single source of truth, encompassing crucial details like:
+
+- State Storage Variables.
+- [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](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.
+
+## Benefits of Schema Tool in Smart Contracts
+
+### Centralized Information
+
+Having all pertinent details in one place allows:
+
+- **Uniform Function Calls**: Through a generated interface used by client-side code.
+- **Error Minimization**: Via compile-time type-checking.
+
+### Efficiency and Simplicity
+
+Knowledge of all essential aspects leads to:
+
+- **Constant Generation**: Avoiding typo-prone key strings repetition and precalculating essential values like `Hnames`.
+- **Informative Code**: Generating code to correctly notify the host about available `Funcs` and `Views`.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/params.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/params.mdx
similarity index 52%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/params.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/params.mdx
index 7d1b0ab8209..3dc604d6f28 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/params.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/params.mdx
@@ -1,38 +1,37 @@
---
+description: "Learn how to define function parameters using the 'params' subsection, and how the Schema Tool facilitates this process."
keywords:
- - params
- - parameters
- - field definition
- - field type
- - optional
- - schema tool
- - structure
- - immutable
-
-description: The optional params subsection contains field definitions for each of the parameters that a function takes.
-
+ - Function Parameters
+ - Schema Tool
+ - Params Subsection
+ - Optional Parameters
+ - Parameter Proxy
image: /img/logo/WASP_logo_dark.png
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Function Parameters
+# Define Function Parameters
+
+You can use the optional [`params`](params.mdx) subsection to specify the parameters a function accepts.
+This section can define both mandatory and optional parameters.
+Optional parameters are denoted with a question mark `?` following the field type.
+
+## Schema Tool Automation
-The optional [`params`](params.mdx) subsection contains field definitions for each of the
-parameters that a function takes. The layout of the field definitions is identical to the
-[`state`](state.mdx) subsection field definitions with one addition, the field type can be
-followed by a question mark to indicate that the parameter is optional.
+The [Schema Tool](../schema-tool/usage.mdx) streamlines the creation of functions by:
-The [Schema Tool](usage.mdx) will automatically generate an immutable structure with
-member variables for proxies to each parameter variable in the [Params](params.mdx) map.
-It will also generate code to check the presence of each non-optional parameter, and it
-will also verify the parameter's data type. This checking is done before the function is
-called. The user will be able to immediately start using the parameter proxy through the
-structure that is passed to the function.
+- Generating an immutable structure holding parameter proxies from the [Params](params.mdx) map.
+- Checking the presence and data type of non-optional parameters before the function call.
-When this subsection is empty or completely omitted, no structure will be generated or
-passed to the function.
+These functionalities allow users to directly use parameter proxies in the structure passed to the function.
+
+:::note
+
+Omitting the `params` subsection results in no structure generation or parameter passing to the function.
+
+:::
For example, here is the structure generated for the immutable [Params](params.mdx) for
the `member` function:
@@ -99,8 +98,5 @@ export class ImmutableMemberParams extends wasmtypes.ScProxy {
-Note that the [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).
-
-In the next section, we will look at the [`results`](results.mdx) subsection.
+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](../../explanations/context.mdx).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/post.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/post.mdx
new file mode 100644
index 00000000000..9a1284c76a4
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/post.mdx
@@ -0,0 +1,99 @@
+---
+keywords:
+ - function descriptor
+ - return values
+ - request
+ - post
+ - smart contract chain
+ - Asynchronous function
+description: Asynchronous function calls between smart contracts are posted as requests on the Tangle. They allow you to invoke any smart contract function that is not a View on any smart contract chain.
+image: /img/logo/WASP_logo_dark.png
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Post Asynchronous Requests
+
+Asynchronous requests enable interactions between different contracts.
+Learn how to navigate the subtleties of posting asynchronous requests on the Tangle,
+and how to effectively manage tokens and delays in execution.
+
+## Overview of Asynchronous Function Calls
+
+### Posting Requests on the Tangle
+
+Asynchronous function calls occur through requests posted on the Tangle.
+These calls can invoke any function that is not a [View](views.mdx) on any smart contract chain.
+
+### Function Descriptor Methods
+
+To post a request, use the following methods from the function descriptor:
+
+- `post()`: Posts to the current chain.
+- `postToChain()`: Allows specifying the chain through the chain ID parameter.
+
+### Delayed Execution
+
+You can set a delay in the execution using the `delay()` method,
+enhancing smart contracts with timed actions or time-lock functionalities.
+
+
+
+
+
+```go
+eor := ScFuncs.EndOfRound(ctx)
+eor.Func.Delay(3600).Post()
+```
+
+
+
+
+```rust
+let eor = ScFuncs::end_of_round(ctx);
+eor.func.delay(3600).post();
+```
+
+
+
+
+```ts
+let eor = sc.ScFuncs.endOfRound(ctx);
+eor.func.delay(3600).post();
+```
+
+
+
+
+## Managing Tokens in Asynchronous Calls
+
+### Mandatory Token Transfer
+
+Asynchronous requests require a minimum token transfer to cover the gas for function call execution.
+Unused tokens return to the caller's account on the chain.
+
+### Specifying Tokens
+
+You can specify tokens:
+
+- Explicitly, as in to synchronous calls.
+- Automatically, letting WasmLib determine the minimum requisite amount.
+
+### Prohibited `delay()` with [`call()`](call.mdx)
+
+Using `delay()` before a [`call()`](call.mdx) will cause a panic due to indeterminate user intentions at compile-time
+without substantial overhead.
+
+## Handling Return Values
+
+If you need some return values,
+you will have to create a mechanism that can do so.
+For example,
+you can provide a callback chain/contract/function combination as part of the input parameters of the requested function so that upon completion,
+that function can asynchronously post the results to the indicated function.
+It will require a certain degree of cooperation between both smart contracts.
+
+### Future Prospects
+
+Future developments aim to facilitate a generic mechanism for seamless return value communication in asynchronous function calls.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/results.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/results.mdx
similarity index 50%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/results.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/results.mdx
index a5029a4eb6f..ea44285bad6 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/results.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/results.mdx
@@ -1,35 +1,34 @@
---
-keywords:
- - results
- - function
- - user function
- - error message
- - implementations
- - mandatory parameter
- - immutable state
- - definition
-
-description: The optional `results` subsection contains field definitions for each of the results a function produces. The layout of the field definitions is identical to that of the state field definitions
-
image: /img/logo/WASP_logo_dark.png
+description: "Understand how to outline function results using the 'results' subsection and how the Schema Tool aids in this process."
+keywords:
+ - Function Results
+ - Schema Tool
+ - Results Subsection
+ - Mutable Structure
+ - Result Variables
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Function Results
+# Define Function Results
-The optional `results` subsection contains field definitions for each of the results a
-function produces. The layout of the field definitions is identical to that of the
-[Params](params.mdx) field definitions.
+You can use the optional `results` subsection to detail the results a function can produce.
+This setup aligns with the field definitions seen in the [Params](params.mdx) subsection.
-The [Schema Tool](usage.mdx) will automatically generate a mutable structure with member
-variables for proxies to each result variable in the [Results](results.mdx) map. The user
-will be able to set the result variables through this structure, which is passed to the
-function.
+## Schema Tool Features
-When this subsection is empty, or completely omitted, no structure will be generated or
-passed to the function.
+The [Schema Tool](../schema-tool/usage.mdx) assists in this setup by:
+
+- Creating a mutable structure that includes proxies for each result variable found in the [Results](results.mdx) map.
+- Enabling users to assign values to result variables via this generated structure during the function call.
+
+:::note
+
+If the `results` subsection is not used, no structure will be created or conveyed to the function.
+
+:::
For example, here is the structure generated for the mutable results for the `getFactor`
function:
@@ -81,10 +80,6 @@ export class MutableGetFactorResults extends wasmtypes.ScProxy {
-Note that the [Schema Tool](usage.mdx) will also generate an immutable version of the
+Note that the [Schema Tool](../schema-tool/usage.mdx) will also generate an immutable version of the
structure, suitable for accessing the results after by the caller of this smart contract
function.
-
-In the next section we will look at how so-called [thunk functions](thunks.mdx)
-encapsulate access and parameter checking and set up the type-safe function-specific
-contexts.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/spec.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/spec.mdx
similarity index 100%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/spec.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/spec.mdx
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/state.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/state.mdx
similarity index 58%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/state.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/state.mdx
index 564d474e8d8..7808d0b1def 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/state.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/state.mdx
@@ -15,23 +15,24 @@ image: /img/logo/WASP_logo_dark.png
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Smart Contract State
+# Define the State
-The smart contract state storage on the host consists of a single key/value map. Both key
-and value are raw data bytes. As long as you access the data in the same way that you used
-to store it, you will always get valid data back. The [Schema Tool](usage.mdx) will create
-a type-safe access layer to make sure that data storage and retrieval always uses the
-expected data type.
+In smart contract state storage, there is only a single key/value map,
+where both the key and value are constituted of raw data bytes.
+To ensure the retrieval of valid data, access it in the manner it was stored.
-The `state` section in the schema definition file contains a number of field definitions
-that together define the variables that are stored in the state storage. Each field
-definition uses a YAML key/value pair to define the name and data type of the field. The
-YAML key defines the field name. The YAML value (a string) defines the field's data type,
-and can be followed by an optional comment that describes the field.
+The [Schema Tool](usage.mdx) facilitates this by generating a type-safe layer
+that oversees the consistent utilization of the expected data type during data storage and retrieval.
-The [Schema Tool](usage.mdx) will use this information to generate the specific code that
-accesses the state variables in a type-safe way. Let's examine the `state` section of the
-`dividend` example in more detail:
+## State Section in Schema Definition File
+
+In the schema definition file the `state` section hosts field definitions,
+delineating the variables stored in the state storage.
+Each field is defined with a YAML key/value pair, indicating its name and data type.
+This pair can optionally be followed by a descriptive comment.
+
+With these details, the [Schema Tool](usage.mdx) creates specific code to type-safely access state variables.
+Take a closer look at the `state` section in the `dividend` example to understand this better:
@@ -50,21 +51,19 @@ state:
-Let's start with the simplest state variables. `totalFactor` is an Uint64, and `owner` is
-an AgentID. Both are predefined [WasmLib value types](../wasm_vm/types.mdx).
+### Simple Variables
-Then you have the `memberList` variable. The empty brackets `[]` indicate that this is an
-array. The brackets immediately follow the homogenous type of the elements in the array,
-which in this case is the predefined Address value type.
+Starting with straightforward state variables, `totalFactor`,
+and `owner` are characterized as Uint64 and AgentID, respectively.
+These represent predefined [WasmLib value types](../../reference/data-types/types.mdx).
-Finally, you have the `members` variable. The `map[]` indicates that this is a map.
-Between the brackets is the homogenous type of the keys, which in this case are of the
-predefined Address type. The brackets are immediately followed by the homogenous type of
-the values in the map, which in this case are of the predefined Uint64 type.
+### Arrays and Maps
-Here is part of the corresponding code in `state.xx` that the [Schema Tool](usage.mdx)
-generates. The `MutableDividendState` struct defines a type-safe interface to access each
-of the state variables through mutable proxies:
+Next, the `memberList` variable denoted by empty brackets `[]`, symbolizing an array.
+This array accommodates elements of a homogenous predefined Address value type.
+
+Lastly, the `members` variable, signified as a map with `map[]`, houses keys of a uniform predefined Address type.
+Following the brackets, the homogenous value type, here `Uint64`, is mentioned.
@@ -170,14 +169,19 @@ export class MutableDividendState extends wasmtypes.ScProxy {
-As you can see, the schema tool has generated a proxy interface for the mutable `dividend`
-state, called `MutableDividendState`. It has a 1-to-1 correspondence to the `state`
-section in the schema definition file. Each member function accesses a type-safe proxy
-object for the corresponding variable. In addition, the [Schema Tool](usage.mdx) generates
-any necessary intermediate map and array proxy types that force the usage of their
-respective homogenous types. In the above example both `ArrayOfMutableAddress` and
-`MapAddressToMutableUint64` are examples of such automatically generated proxy types.
-See the full `state.xx` for more details.
+## Generated Code Overview
-In the next section we will explore how the [Schema Tool](usage.mdx) helps to simplify
-[triggering events](events.mdx).
+Examining the `state.xx`code, generated by the [Schema Tool](usage.mdx),
+you can find the `MutableDividendState` struct.
+This interface allows type-safe access to each state variable through mutable [proxies](../../explanations/proxies.mdx),
+establishing a one-to-one relationship with the `state` section in the schema definition file.
+
+### Proxy Interfaces
+
+Note the generated proxy interface named `MutableDividendState` for mutable `dividend` state.
+It enables type-safe proxy object access for each corresponding variable.
+Moreover, the tool auto-generates intermediate map and array proxy types,
+such as `ArrayOfMutableAddress` and `MapAddressToMutableUint64`,
+enforcing the utilization of respective homogenous types.
+
+See the full `state.xx` for more details.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/structs.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/structs.mdx
similarity index 93%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/structs.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/structs.mdx
index ff6bf5341ea..14473408926 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/structs.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/structs.mdx
@@ -16,17 +16,17 @@ import TabItem from '@theme/TabItem';
# Structured Data Types
-The [Schema Tool](usage.mdx) allows you to define your own structured data types that are
+The [Schema Tool](../../how-tos/schema-tool/usage.mdx) allows you to define your structured data types that are
composed of the predefined WasmLib value data types. The tool will generate a struct with
-named fields according to the definition in the schema definition file, and also will
-generate code to serialize and deserialize the structure to a byte array, so that it can
+named fields according to the definition in the schema definition file and also will
+generate code to serialize and deserialize the structure to a byte array so that it can
be saved as a single unit of data bytes, for example in state storage.
-You can use structs directly as a type in state storage definitions and the
-[Schema Tool](usage.mdx) will automatically generate the proxy code to access and
+You can use structs directly as a type in state storage definitions, and the
+[Schema Tool](../../how-tos/schema-tool/usage.mdx) will automatically generate the proxy code to access and
(de)serialize it properly.
-For example, let's say you are creating a `betting` smart contract. Then you would want to
+For example, let's say you are creating a `betting` smart contract. Then, you would want to
store information for each bet. The Bet structure could consist of the bet amount and
time, the number of the item that was bet on, and the agent ID of the one who placed the
bet. And you would keep track of all bets in state storage in an array of Bet structs. To
@@ -49,7 +49,7 @@ state:
-The [Schema Tool](usage.mdx) will generate the following code in `structs.xx` for the Bet
+The [Schema Tool](../../how-tos/schema-tool/usage.mdx) will generate the following code in `structs.xx` for the Bet
struct:
@@ -505,13 +505,9 @@ export class MutableBettingState extends wasmtypes.ScProxy {
-The end results are ImmutableBettingState and MutableBettingState structures that can
+The results are ImmutableBettingState and MutableBettingState structures that can
directly interface to the state of the betting contract.
-Note how the comments from the schema definition file have been copied to the structure
-definition in the code and also to the access functions for the fields. This will allow
-your development environment to pop up context-sensitive help for those fields and access
-functions.
-
-In the next section we will look at how to use [type definitions](typedefs.mdx) to
-properly define container nesting relationships.
+Note how the comments from the schema definition file have been copied to the code's structure definition and access
+functions for the fields. This will allow your development environment to pop up context - sensitive help
+for those fields and access functions.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/thunks.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/thunks.mdx
similarity index 64%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/thunks.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/thunks.mdx
index 8e8010312e7..09467423d4c 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/thunks.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/thunks.mdx
@@ -1,11 +1,13 @@
---
+description: 'Learn about thunk functions and how the Schema Tool uses them to facilitate smart contract function calls.'
keywords:
- - functions
- - thunk
- - insert operations
-
-description: Thunk functions encapsulate access and parameter checking and set up the type-safe function-specific contexts. Thunks are used to insert operations at the beginning or end of the wrapped function to adapt it to changing requirements
-
+ - Thunk Functions
+ - Schema Tool
+ - Wrapper Function
+ - Smart Contract Functions
+ - Type-Safe
+ - Function Signature
+ - Code Injection
image: /img/logo/WASP_logo_dark.png
---
@@ -14,24 +16,22 @@ import TabItem from '@theme/TabItem';
# Thunk Functions
-In computer programming, a thunk is a wrapper function that is used to inject code around
-another function. Thunks are used to insert operations before and/or after the wrapped
-function is being called to adapt it to changing requirements. The
-[Schema Tool](usage.mdx) will generate such thunk functions to be able to properly set up
-calls to the smart contract functions. It also creates a mapping between the name/id of
-the function and the actual function, and generates code to properly communicate this
-mapping to the ISC host.
-
-In our case we use thunks not only to inject code around the smart contract function, but
-also to make the smart contract function type-safe. The thunks all have an identical
-function signature, and each will set up a function-specific data structure so that the
-actual smart contract function will deal with them in a type-safe way. Having a common
-function signature for the thunks means that it is easy to generate a table of all
-functions and their names that can be used to generically call these functions.
-
-All code for this table and the thunks is generated as part of `lib.xx` and it looks as
-follows for the `dividend` example smart contract (for simplicity the thunk function
-contents has been omitted for now):
+In software development, thunk functions are a crucial part of setting up smart contracts correctly,
+facilitating type-safety and easy mapping of function names to their actual implementations.
+
+## Overview
+
+A thunk is a wrapper function employed to inject code before and/or after a function call.
+It helps in adapting functions to meet changing demands.
+Through the [Schema Tool](../schema-tool/usage.mdx),
+thunks are generated to establish correct calls to smart contract functions and to ensure type-safety.
+They share a common function signature, fostering a straightforward creation of a function table for generic calls.
+
+## Role in Wasm
+
+Working hand in hand with the WebAssembly (Wasm) format,
+thunks play a pivotal role in the `lib.xx` component.
+Below is how a chunk of a `dividend` smart contract would look (the detailed thunk function content is omitted):
@@ -140,40 +140,30 @@ function viewGetOwnerThunk(ctx: ScViewContext) {}
-The key function here is the `OnDispatch()` function, which will be called by the main
-Wasm file. This main Wasm file is separate because the Wasm runtime format is
-essentially a dynamic link library. That means it not only defined exported functions,
-but also defines functions it needs to link to at a later stage, and which will be
-provided by the Wasm VM host.
+## The Dispatch Process
+
+The central player here is the `OnDispatch()` function,
+called by the primary Wasm file, essentially a dynamic link library.
+This mechanism keeps the smart contract (SC) code self-contained and versatile,
+fitting for both Wasm requirements and direct client-side executions.
-We want to keep the SC code separate as a self-contained library that is independent of
-the Wasm format requirements, because we will be reusing the same SC code in client-side
-code that can directly execute SC requests through this same interface.
+To meet Wasm's demands, we implement `on_load()` and `on_call()` callbacks that collaborate with `OnDispatch()` in the `lib.xx`,
+orchestrating a seamless dispatch process.
-The Wasm host requires us to implement the `on_load()`and `on_call()` Wasm callback
-functions. These will directly dispatch these calls through the corresponding
-`OnDispatch()` function in the generated `lib.xx`.
+### `on_load()`
The `on_load()` Wasm function will be called by the Wasm VM host upon loading of the Wasm
code. It will inform the host of all the function ids and types (Func or View) that this
smart contract provides.
+### `on_call()`
+
When the host needs to call a function of the smart contract it will call the `on_call()`
callback function with the corresponding function id, and then the `on_call()` function
will dispatch the call via the `ScExportMap` mapping table that was generated by the
-[Schema Tool](usage.mdx) to the proper associated thunk function.
-
-This Wasm-specific code has been separated out in `main.xx`, as a separate package next
-to the SC library. For Rust it is a little more complex, so it has been separated out to
-a folder with the same name, followed by `wasm`. The `src/lib.rs` file serves the same
-function as the `main.xx` file in the other languages.
+[Schema Tool](../schema-tool/usage.mdx) to the proper associated thunk function.
-The Wasm-specific code will also make sure that the WasmVMHost code will be pulled into
-the Wasm code because that defines the missing import functions that will be provided
-by the Wasm VM host. In this way we manage to make WasmLib independent of the Wasm code
-format as well. WasmLib defines an `ScHost` interface that will define what host
-environment is used, which in this case is `WasmVMHost`. For the client-side code we
-implement a different `ScHost` that hides the differences.
+## Generated Main Entry Point
Here is the generated `main.xx` that forms the main entry point for the Wasm code:
@@ -345,32 +335,45 @@ function funcSetOwnerThunk(ctx: wasmlib.ScFuncContext): void {
+## The Thunk Function in Action
+
+### Log the Contract and Function Name
+
First, the thunk logs the contract and function name to show that the call has started.
+
+### Set Up Strongly Typed Context
+
Then it sets up a strongly typed function-specific context structure. First, we add the
function-specific immutable [Params](params.mdx) interface structure, which is only
-present when the function actually can have parameters. Then we add the contract-specific
-[State](state.mdx) interface structure. In this case it is mutable because setOwner is a
-[Func](funcs.mdx). For [Views](views.mdx) this would be an immutable state interface.
+present when the function can have parameters. Then we add the contract-specific
+[State](../schema-tool/state.mdx) interface structure. In this case, it is mutable because setOwner is a
+[Func](funcs.mdx). For [Views](views.mdx), this would be an immutable state interface.
Finally, we would add the function-specific mutable [Results](results.mdx) interface
-structure, which is only present when the function actually returns results. Obviously,
-this is not the case for this `setOwner()` function.
+structure, which is only present when the function returns results.
+This is not the case for this `setOwner()` function.
-Next it sets up access control for the function according to the schema definition file.
-In this case it retrieves the `owner` state variable through the function context,
-requires that the variable exists, and then requires that the `caller()` of the function
+### Set Up Access Control
+
+Next, it sets up access control for the function according to the schema definition file.
+In this case, it retrieves the `owner` state variable through the function context,
+requires that the variable exists, and then requires that the function's `caller()`
equals that value. Any failing requirement will panic out of the thunk function with an
-error message. So this code makes sure that only the owner of the contract can call this
+error message. So, this code ensures that only the contract owner can call this
function.
+### Verify Function Parameters
+
Now we get to the point where we can use the function-specific [Params](params.mdx)
interface to check for mandatory parameters. Each mandatory parameter is required to
exist, or else we will panic out of the thunk function with an error message.
+### Call the Smart Contract Function
+
With the setup and automated checks completed, we now call the actual smart contract
-function implementation that is maintained by the user. After this function has completed,
-we would process the returned results for those functions that have any (in this case we
-obviously don't have results), and finally we log that the contract function has completed
+function implementation the user maintains.
+After this function has been completed,
+we would process the returned results for those functions that have any (in this case, we
+don't have results).
+Finally, we log that the contract function has been completed
successfully. Remember that any error within the user function will cause a panic, so this
logging will never occur in case that happens.
-
-In the next section we will look at the specifics of [view functions](views.mdx).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/transfers.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/transfers.mdx
similarity index 74%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/transfers.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/transfers.mdx
index 50774b1bb61..dc7045b7925 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/transfers.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/transfers.mdx
@@ -1,53 +1,60 @@
---
+description: 'Explore methods in the Call Context that facilitate the handling and transfer of asset balances in smart contracts using the `dividend` example.'
keywords:
- - balances
- - color
- - smart contract function
- - address
- - members
- - incoming
- - tokens
- - incoming
-
-description: There are two methods in the call context that deal with token balances. The balances() method can be used to determine the current asset balances. The allowance() method can be used to determine the caller assets that the function is allowed to use.
-
+ - Call Context
+ - Asset Balances
+ - ScBalances Proxy
+ - ScTransfer Proxy
+ - Dividend Smart Contract
image: /img/logo/WASP_logo_dark.png
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Token Transfers
-
-There are two methods in the [Call Context](context.mdx) that deal with token balances.
-The first one is the `balances()` method, which can be used to determine the current asset
-balances that are governed by this smart contract. The second one is the `allowance()`
-method, which can be used to determine the caller assets that the current call to the
-smart contract function is allowed to use.
-
-Both methods provide access to zero or more balances of assets, through a special
-`ScBalances` proxy. Note that the `allowance()` balances are not automatically transferred
-to the smart contract but instead will need to explicitly be transferred by the function.
-That way, if a function cannot handle the transfer the tokens will stay safely in the
-caller's on-chain account. The function explicitly transfers only assets it understands,
-and only in the amount that its algorithm defines, and never more than the allowed amount.
-
-There is also a `transfer_allowed()` method in the [Call Context](context.mdx) that can
-transfer assets from the caller's on-chain account to any other on-chain account. The
-assets to be transferred are provided to the method through a special `ScTransfer` proxy,
-which is essentially a mutable version of `ScBalances`. We will be using the
-`transfer_allowed()` method in the `dividend` example to disperse the incoming iotas to
-the member accounts.
-
-The idea behind the dividend smart contract is that once we have set up the list of
-members, consisting of address/factor pairs, and knowing the total sum of the factors, we
-can automatically pay out a dividend to each of the members in the list according to the
-factors involved. Whatever amount of iotas gets sent to the `divide()` function will be
-divided over the members in proportion based on their respective factors. For example, you
-could set it up so that address A has a factor of 50, B has 30, and C has 20, for a total
-of 100 to divide. Then whenever an amount of iotas gets sent to the `divide()` function,
-address A will receive 50/100th, address B will receive 30/100th, and address C will
-receive 20/100th of that amount.
+# Transfer Tokens
+
+The [Call Context](../../explanations/context.mdx) in smart contracts introduces two vital methods -
+`balances()` and `allowance()` - to manage token balances efficiently.
+Understanding how to use these can be foundational in setting up smart contracts,
+as demonstrated in the `dividend` smart contract example.
+
+## Methods Overview
+
+### 1. **`balances()` Method**:
+
+- **Functionality**: Fetch the present asset balances regulated by the smart contract.
+- **Access**: Through the `ScBalances` proxy.
+
+### 2. **`allowance()` Method**:
+
+- **Functionality**: Verify the caller assets that the current smart contract function can use.
+- **Transfer Requirement**: Assets are not automatically transferred;
+ the function must instigate the transfer explicitly within the allowed limit.
+- **Access**: Through the `ScBalances` proxy.
+
+### 3. **`transfer_allowed()` Method**:
+
+- **Functionality**: Facilitate asset transfers from the caller's on-chain account to another on-chain account.
+- **Proxy**: uses the `ScTransfer` proxy, a mutable variant of `ScBalances`.
+- **Application**: In the `dividend` contract, it aids in distributing iotas to member accounts.
+
+## Dividend Smart Contract Example
+
+The `dividend` smart contract operates on a principle of equitable asset distribution to its members based on predefined factors.
+Here's how it works:
+
+1. **Setup**: Establish a list of members with associated address/factor pairs and calculate the total factor sum.
+2. **Function**: The `divide()` function manages the dividend distribution.
+3. **Dividend Allocation**:
+ - **Input**: Iotas sent to the `divide()` function.
+ - **Distribution**: Proportional to the individual's factor.
+ - **Example**: For factors A:50, B:30, and C:20 (total 100):
+ - **A receives**: 50/100 of the input iotas.
+ - **B receives**: 30/100 of the input iotas.
+ - **C receives**: 20/100 of the input iotas.
+
+In this system, asset distribution is transparent, fair, and automated, ensuring a streamlined division process.
Here is the `divide` function:
@@ -233,6 +240,3 @@ export function funcDivide(
-
-In the next section we will introduce [Function Descriptors](funcdesc.mdx) that can be
-used to initiate smart contract functions.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/typedefs.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/typedefs.mdx
similarity index 95%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/typedefs.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/typedefs.mdx
index 7d64dd759f4..c7e2a331839 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/typedefs.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/typedefs.mdx
@@ -17,14 +17,20 @@ import TabItem from '@theme/TabItem';
# Type Definitions
-We allow nesting of [container types](../wasm_vm/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.
There is a simple solution to this problem. You can add a `typedefs` section to the schema
definition file, where you can define a single type name for a container type. That way
you can easily create containers that contain such container types. The
-[Schema Tool](usage.mdx) will automatically generate the in-between proxy types necessary
+[Schema Tool](../../how-tos/schema-tool/usage.mdx) will automatically generate the in-between proxy types necessary
to make this work.
To keep it at the `betting` smart contract from [the previous section](structs.mdx),
@@ -46,7 +52,7 @@ state:
-The [Schema Tool](usage.mdx) will generate the following code in `typedefs.xx` for the
+The [Schema Tool](../../how-tos/schema-tool/usage.mdx) will generate the following code in `typedefs.xx` for the
`BettingRound` type:
@@ -446,8 +452,5 @@ export class MutableBettingState extends wasmtypes.ScProxy {
Notice how the `rounds()` member function returns a proxy to an array of `BettingRound`.
Which in turn is an array of `Bet`. So, the desired result has been achieved. And every
-access step along the way only allows you to take the path laid out which is checked at
+access step only allows you to take the path laid out, which is checked at
compile-time.
-
-In the next section we will explore how the [Schema Tool](usage.mdx) generates a proxy
-interface to mutable [State](state.mdx).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/usage.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/usage.mdx
similarity index 70%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/usage.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/usage.mdx
index 6cbe9a0dc9d..799ecd6435a 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/usage.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/usage.mdx
@@ -10,28 +10,29 @@ keywords:
- yml
description: The `schema` tool will assist in creating a smart contract as unobtrusively as possible.
-
image: /img/logo/WASP_logo_dark.png
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Using the Schema Tool
+# Use the Schema Tool
+
+Creating smart contracts is simplified using the _Schema Tool_.
+This guide outlines the initial steps to set up a new smart contract from scratch.
+
+## Step 1: Establish a Central Folder
-We tried to make the creation of smart contracts as simple as possible. The _Schema Tool_
-will assist you along the way as unobtrusively as possible. This section will walk you
-through the steps to create a new smart contract from scratch.
+Select a central folder to house all your smart contracts.
+You'll create a separate subfolder for each contract within this central repository.
-First, you need to decide on a central folder where you want to keep all your smart
-contracts. Each smart contract you create will be maintained in a separate subfolder of
-this folder. We will use certain naming conventions that the schema tool expects
-throughout this section. First we will select a _capitalized camel case_ name for our
-smart contract. For our example, `MySmartContract`.
+Next, choose a descriptive, capitalized camel case name for your contract, like `MySmartContract`.
-Once you know what your smart contract will be named, it is time to set up your subfolder.
-Simply navigate to the central smart contract folder, and run the schema tool's
-initialization function:
+## Step 2: Create a Subfolder
+
+After naming your smart contract, you should create a corresponding subfolder.
+Open your terminal, navigate to the central folder,
+and initialize your project with the Schema Tool using the following command:
```shell
schema -init MySmartContract
@@ -39,7 +40,7 @@ schema -init MySmartContract
This command will create a subfolder named `mysmartcontract` and generate an initial YAML
schema definition file inside this subfolder. Note that the generated subfolder name is
-all lower case. This is to conform to best practices for package names in most languages.
+all lower-case. This is to conform to best practices for package names in most languages.
The generated schema definition file looks like this:
@@ -70,21 +71,26 @@ views:
-The schema definition file has been pre-populated with all sections that you could need,
-and some functions that allow you to maintain the ownership of the smart contract. Now
-that the schema definition file exists, it is up to you to modify it further to reflect
-the requirements of your smart contract.
+After initializing your project with the Schema Tool,
+a pre-populated schema definition file will be generated in the `mysmartcontract` subfolder.
+This file contains the necessary sections and functions to manage your smart contract's ownership.
+
+## Naming Conventions
-You should use _camel case_ naming convention throughout the schema definition file when
-naming items. Function and variable names always start with a lower case character, and
-type names always start with an upper case character.
+Ensure to follow the _camel case_ naming convention in the schema definition file. Here is how to use it:
-The first thing you may want to do is to modify the `description` field to something more
-sensible. And if you already know how to use the schema tool, then now is the moment to
-fill out some sections with the definitions you know you will need.
+- Function and variable names: start with a lowercase letter (e.g., `myFunction`)
+- Type names: start with an uppercase letter (e.g., `MyType`)
-The next step is to navigate into the new `mysmartcontract` subfolder and run the schema
-tool there to generate the initial code for the desired language:
+## Customizing Fields
+
+Begin by updating the `description` field with a relevant description of your smart contract.
+It is the perfect time to add any known definitions to the necessary sections.
+
+## Generating Initial Code
+
+Navigate to your `mysmartcontract` subfolder to generate the initial code for your preferred programming language using
+the Schema Tool.
@@ -272,20 +278,16 @@ export function viewGetOwner(
-As you can see the schema tool even generated an initial working version of the functions
-that are used to maintain the smart contract owner that will suffice for most cases.
-
-For a smooth building experience it is a good idea to set up a build rule in your build
-environment that runs the schema tool with the required parameters whenever the schema
-definition file changes. That way regeneration of files is automatic, and you no longer
-have to start the schema tool manually each time after changing the schema definition
-file. The schema tool will only regenerate the code when it finds that the schema
-definition file has been modified since the last time it generated the code. You can force
-the schema tool to regenerate all code by adding the `-force` flag to its command line
-parameter.
+The schema tool automatically generates an initial working version of the functions to maintain the smart contract owner,
+catering to most use cases.
-In the next section we will look at how a smart contract can access its associated
-storage by using [Data Access Proxies](proxies.mdx).
+To streamline the building process, configure a build rule in your environment.
+This rule should trigger the schema tool with the necessary parameters
+whenever there are changes in the schema definition file.
+This setup ensures automatic file regeneration,
+eliminating the need to run the schema tool manually after each modification.
+The tool regenerates code only if it detects alterations since its last operation.
+To override this and force regeneration, include the `-force` flag in the command line parameter.
## Video Tutorial
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/views.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/views.mdx
similarity index 66%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/views.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/views.mdx
index 8c4dc233073..355c5c05cb0 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/views.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/schema-tool/views.mdx
@@ -1,38 +1,46 @@
---
+description: "Explore the characteristics and constraints of view-only functions in smart contracts,
+illustrated through a 'getFactor' function example."
keywords:
- - results
- - call context
- - view function
- - retrieve state
-
-description: Views are smart contract functions that only allow you to retrieve state information about the smart contract. They have a special, limited call context that does not allow them to change the smart contract state.
-
+- View-Only Functions
+- Smart Contracts
+- Call Context
+- Immutable Proxies
+- Cross-Chain Requests
image: /img/logo/WASP_logo_dark.png
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# View-Only Functions
+# Use View-Only Functions
+
+View-only functions, also known as "views",
+are smart contract functions specialized in retrieving state information without altering the smart contract's state.
+
+## Characteristics
+
+### Immutable Proxies
+
+All state storage accesses occur through immutable proxies, ensuring the state remains unchanged.
-View-only functions, or Views for short, are smart contract functions that only allow you
-to _retrieve_ state information about the smart contract. They receive a special, limited
-[Call Context](context.mdx) that does not allow access to functionality that could result
-in changes to the smart contract state. This means that all access to the state storage
-will be through immutable proxies. It also means that they cannot receive or transfer
-tokens, because changes to the smart contract account are by definition state changes as
-well.
+### Restricted Functionalities
-Views are allowed to [`call()`](call.mdx) other views on the same chain, but they cannot
-call any non-view smart contract function, nor can they [`post()`](post.mdx) cross-chain
-requests.
+Views have a limited [Call Context](../../explanations/context.mdx),
+disabling any function that might induce state changes, including token transactions.
-View functions will always return some data to their caller. It would be silly not to
-return data from a View because by definition it cannot have any other side effects that
-show up elsewhere.
+### Intra-chain Calls
-For demonstration purposes we provided a View function with the `dividend` smart contract,
-called 'getFactor':
+While they can [`call()`](call.mdx) other views within the same chain,
+they cannot initiate non-view functions or [`post()`](post.mdx) cross-chain requests.
+
+### Return Data
+
+These functions are designed to return data to the caller, as they can't induce any other external effects.
+
+## Use Case: 'getFactor' Function
+
+To illustrate the use of view-only functions, consider the `getFactor()` function integrated in the `dividend` smart contract:
@@ -118,10 +126,8 @@ export function viewGetFactor(
-Return values are passed to the caller through the predefined [Results](results.mdx) map
-associated with the [Call Context](context.mdx). Again, this works the same way as for
-Funcs, although Funcs do not necessarily return values to the caller. The
-[Schema Tool](usage.mdx) will generate a function-specific [Results](results.mdx)
+The return values are passed to the caller through the predefined [Results](results.mdx) map
+associated with the [Call Context](../../explanations/context.mdx).
+Again, this works the same as for Funcs, although Funcs do not necessarily return values to the caller. The
+[Schema Tool](../schema-tool/usage.mdx) will generate a function-specific [Results](results.mdx)
structure with type-safe proxies to the result fields in this map.
-
-In the next section we will look at [smart contract initialization](init.mdx).
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..4662b574262
--- /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/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/0.7.0/docs/guide/solo/deploying-sc.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/deploying-sc.md
similarity index 95%
rename from docs/build/wasp/0.7.0/docs/guide/solo/deploying-sc.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/deploying-sc.md
index 5e60cf99e90..8d909e527fb 100644
--- a/docs/build/wasp/0.7.0/docs/guide/solo/deploying-sc.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/deploying-sc.md
@@ -18,15 +18,14 @@ keywords:
:::note WASM VM
-For more information about how to create Wasm smart contracts, refer to the [Wasm VM chapter](../wasm_vm/intro.mdx).
+For more information about how to create Wasm smart contracts, refer to the [Wasm VM chapter](../../introduction.mdx).
:::
## Deploy the Solo Tutorial
The following examples will make use of the
-[`solotutorial` Rust/Wasm smart contract](https://github.com/iotaledger/wasp/tree/develop/documentation/tutorial-examples)
-.
+[`solotutorial` Rust/Wasm smart contract](https://github.com/iotaledger/wasp/tree/develop/documentation/tutorial-examples).
In order to test the smart contract using Solo, first you need to deploy it. You can use the following code to
deploy `solotutorial_bg.wasm`:
diff --git a/docs/build/wasp/0.7.0/docs/guide/solo/error-handling.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/error-handling.md
similarity index 92%
rename from docs/build/wasp/0.7.0/docs/guide/solo/error-handling.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/error-handling.md
index ee283fa4047..6b02ae59faf 100644
--- a/docs/build/wasp/0.7.0/docs/guide/solo/error-handling.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/error-handling.md
@@ -44,7 +44,7 @@ Note that this test still ends with the state `#4`, although the last request to
```
This shows that a chain block is always generated, regardless of whether the smart contract call succeeds or not. The
-result of the request is stored in the chain's [`blocklog`](/learn/smart-contracts/core_concepts/core_contracts/blocklog) in the form of
+result of the request is stored in the chain's [`blocklog`](/wasp-wasm/reference/core-contracts/blocklog) in the form of
a receipt. In fact, the received Go error `err` in the test above is just generated from the request receipt.
If a panic occurs during a smart contract call, it is recovered by the VM context, and the request is marked as failed.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/examples.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/examples.mdx
similarity index 94%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/examples.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/examples.mdx
index 5ea93d2b3a8..6be2aa9811a 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/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()`](call.mdx) or
-[`post()`](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](views.mdx) and/or [Funcs](funcs.mdx) that return
-a result. Note that even though Funcs are usually invoked through a [`post()`](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()](call.mdx) from within another Func, in which these return values can
-be used normally. Since solo executes [`post()`](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.
diff --git a/docs/build/wasp/0.7.0/docs/guide/solo/first-example.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/first-example.md
similarity index 93%
rename from docs/build/wasp/0.7.0/docs/guide/solo/first-example.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/first-example.md
index baf2f5fccd3..512963622a2 100644
--- a/docs/build/wasp/0.7.0/docs/guide/solo/first-example.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/first-example.md
@@ -13,8 +13,8 @@ keywords:
# First Example
The following is an example of a _Solo_ test. It deploys a new chain and invokes some view calls in the
-[`root`](/learn/smart-contracts/core_concepts/core_contracts/root) and [`governance`](/learn/smart-contracts/core_concepts/core_contracts/governance)
-[core contracts](/learn/smart-contracts/core_concepts/core_contracts/overview).
+[`root`](/wasp-wasm/reference/core-contracts/root) and [`governance`](/wasp-wasm/reference/core-contracts/governance)
+[core contracts](/wasp-wasm/reference/core-contracts/overview).
```go
import (
@@ -81,7 +81,7 @@ The output of the test will be something like this:
:::
-The [core contracts](/learn/smart-contracts/core_concepts/core_contracts/overview) listed in the log are automatically deployed on each
+The [core contracts](/wasp-wasm/reference/core-contracts/overview) listed in the log are automatically deployed on each
new chain. The log also shows their _contract IDs_.
The output fragment in the log `state transition --> #1` means that the state of the chain has changed from block index
diff --git a/docs/build/wasp/0.7.0/docs/guide/solo/invoking-sc.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/invoking-sc.md
similarity index 100%
rename from docs/build/wasp/0.7.0/docs/guide/solo/invoking-sc.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/invoking-sc.md
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/test.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/test.mdx
similarity index 82%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/test.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/test.mdx
index dcf0be3c86b..cd1ec4d6288 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/test.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/test.mdx
@@ -9,7 +9,6 @@ keywords:
- Go
description: Testing of smart contracts happens in the Solo testing environment. This enables synchronous, deterministic testing of smart contract functionality without the overhead of having to start nodes, set up a committee, and send transactions over the Tangle.
-
image: /img/logo/WASP_logo_dark.png
---
@@ -27,7 +26,7 @@ combination with Solo to deploy chains and smart contracts and simulate transact
Solo directly interacts with the ISC code, and therfore uses all the ISC-specific data
types directly. Our Wasm smart contracts cannot access these types directly, because they
run in a separate, sandboxed environment. Therefore, WasmLib implements its
-[own versions](types.mdx) of these data types, and the VM layer acts as a data type
+[own versions](../../reference/data-types/types.mdx) of these data types, and the VM layer acts as a data type
translator between both systems.
The impact of this type transformation used to be that to be able to write tests in the
@@ -36,17 +35,17 @@ conversion functions, and exactly how to properly pass such data in and out of s
contract function calls. This burdened the user with an unnecessary increased learning
curve and countless unnecessary type conversions.
-With the introduction of the [Schema Tool](usage.mdx), we were able to remove this
+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](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.
The only concession we still have to make is to the language used. Because Solo only works
in the Go language environment, we have to use the Go language version of the interface
-code that the [Schema Tool](usage.mdx) generates when testing our smart contracts. Because
+code that the [Schema Tool](../schema-tool/usage.mdx) generates when testing our smart contracts. Because
WasmLib programming for Go, Rust, and TypeScript are practically identical, we feel that
this is not unsurmountable. The WasmLib interfaces only differ slightly if language
idiosyncrasies force differences in syntax or naming conventions. This hurdle used to be a
@@ -74,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](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:
@@ -109,15 +108,15 @@ func dividendGetFactor(ctx *wasmsolo.SoloContext, member *wasmsolo.SoloAgent) ui
As you can see, we pass the `SoloContext` and the parameters to the wrapper functions,
-then use the `SoloContext` to create a [Function Descriptor](funcdesc.mdx) for the wrapped
-function, pass any parameters through the its [Params](params.mdx) proxy, and then either
-[`post()`](post.mdx) the function request or [`call()`](call.mdx) the function. Any
-results returned are extracted through the descriptor's [Results](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](context.mdx) knows how to properly
-[`call()`](call.mdx) or [`post()`](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/0.7.0/docs/guide/solo/the-l1-ledger.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/the-l1-ledger.md
similarity index 100%
rename from docs/build/wasp/0.7.0/docs/guide/solo/the-l1-ledger.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/the-l1-ledger.md
diff --git a/docs/build/wasp/0.7.0/docs/guide/solo/the-l2-ledger.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/the-l2-ledger.md
similarity index 95%
rename from docs/build/wasp/0.7.0/docs/guide/solo/the-l2-ledger.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/the-l2-ledger.md
index fdfccdd3882..358439bf95a 100644
--- a/docs/build/wasp/0.7.0/docs/guide/solo/the-l2-ledger.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/the-l2-ledger.md
@@ -100,10 +100,10 @@ func TestTutorialAccounts(t *testing.T) {
The example above creates a chain and a wallet with `utxodb.FundsFromFaucetAmount` base tokens on L1.
Then, it sends 1 million tokens to the corresponding on-chain account by posting a
-[`deposit`](/learn/smart-contracts/core_concepts/core_contracts/accounts#deposit) request to the
-[`accounts` core contract](/learn/smart-contracts/core_concepts/core_contracts/accounts) on the chain.
+[`deposit`](/wasp-wasm/reference/core-contracts/accounts#deposit) request to the
+[`accounts` core contract](/wasp-wasm/reference/core-contracts/accounts) on the chain.
-Finally, it sends a [`withdraw`](/learn/smart-contracts/core_concepts/core_contracts/accounts#withdraw) request to the `accounts` core
+Finally, it sends a [`withdraw`](/wasp-wasm/reference/core-contracts/accounts#withdraw) request to the `accounts` core
contract to get the tokens back to L1.
Both requests are affected by the gas fees and the storage deposit.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/timelock.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/timelock.mdx
similarity index 98%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/timelock.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/timelock.mdx
index a6e9833f73e..4fb028f5711 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/timelock.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/timelock.mdx
@@ -10,7 +10,6 @@ keywords:
- delay
description: You can post a time-locked request by using the Delay() method. You can mint NFTs by using the MintNFT() method.
-
image: /img/logo/WASP_logo_dark.png
---
@@ -125,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()`](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/0.7.0/docs/guide/solo/view-sc.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/view-sc.md
similarity index 95%
rename from docs/build/wasp/0.7.0/docs/guide/solo/view-sc.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/view-sc.md
index 5f0503305c0..8147df7f92f 100644
--- a/docs/build/wasp/0.7.0/docs/guide/solo/view-sc.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/view-sc.md
@@ -33,7 +33,7 @@ view entry point will result in an exception, returning all attached tokens to t
Views are used to retrieve information about the smart contract's state, for example, to display on a website. Certain
Solo methods such as `chain.GetInfo`, `chain.GetGasFeePolicy`, and `chain.L2Assets` call views of
-the [core smart contracts](/learn/smart-contracts/core_concepts/core_contracts/overview) behind the scenes to retrieve the information
+the [core smart contracts](/wasp-wasm/reference/core-contracts/overview) behind the scenes to retrieve the information
about the chain or a specific smart contract.
## Decoding Results Returned by _PostRequestSync_ and _CallView_
diff --git a/docs/build/wasp/0.7.0/docs/guide/solo/what-is-solo.md b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/what-is-solo.md
similarity index 98%
rename from docs/build/wasp/0.7.0/docs/guide/solo/what-is-solo.md
rename to docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/what-is-solo.md
index ac6868c0604..006bf22ff6f 100644
--- a/docs/build/wasp/0.7.0/docs/guide/solo/what-is-solo.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/solo/what-is-solo.md
@@ -11,7 +11,6 @@ keywords:
- validate smart contracts
- install
- how-to
-
---
# Testing Smart Contracts with Solo
@@ -65,7 +64,7 @@ You will need a smart contract to test along with Solo.
You can find example implementations of Wasm smart contracts, including source code and tests, in the Wasp
repository’s [contracts/wasm folder](https://github.com/iotaledger/wasp/tree/develop/contracts/wasm).
-For information on creating Wasm smart contracts, refer to the [Wasm VM chapter](../wasm_vm/intro.mdx).
+For information on creating Wasm smart contracts, refer to the [Wasm VM chapter](../../introduction.mdx).
The following sections will present some Solo usage examples. You can find the example code in
the [Wasp repository](https://github.com/iotaledger/wasp/tree/develop/documentation/tutorial-examples).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/view-account-balances.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/view-account-balances.mdx
new file mode 100644
index 00000000000..09771af0901
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/view-account-balances.mdx
@@ -0,0 +1,170 @@
+---
+description: The Accounts contract provides the balance, totalAssets and accounts views.
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - smart contracts
+ - view
+ - account
+ - balances
+ - Rust
+ - Solo
+ - how to
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# View Account Balances
+
+The Accounts contract provides the following views:
+
+## `balance`
+
+Get the account balance of a specific account.
+
+### Parameters
+
+- `ParamAgentID`: account's AgentID.
+
+### Returns
+
+A map of `token ID -> amount` (the base token is identified by an empty token ID).
+
+### Examples
+
+
+
+
+```go
+balances := chain.L2Assets(agentID)
+```
+
+
+
+
+```go
+b := coreaccounts.ScFuncs.Balance(ctx)
+b.Params.AgentID().SetValue(agentID)
+b.Func.Call()
+require.NoError(t, ctx.Err)
+balances := b.Results.Balances()
+```
+
+
+
+
+```rust
+let b = coreaccounts::ScFuncs::balance(ctx);
+b.params.agent_id().set_value(&agentID);
+b.func.call();
+let balances = b.results.balances();
+```
+
+
+
+
+```go
+b := coreaccounts.ScFuncs.Balance(ctx)
+b.Params.AgentID().SetValue(agentID)
+b.Func.Call()
+balances := b.Results.Balances()
+```
+
+
+
+
+---
+
+## `totalAssets`
+
+Get the total funds controlled by the chain.
+
+### Returns
+
+- A map of [token_color] -> [amount] .
+
+
+
+
+```go
+balances := chain.L2TotalAssets()
+```
+
+
+
+
+```go
+b := coreaccounts.ScFuncs.TotalAssets(ctx)
+b.Func.Call()
+require.NoError(t, ctx.Err)
+balances := b.Results.Balances()
+```
+
+
+
+
+```rust
+let b = coreaccounts::ScFuncs::total_assets(ctx);
+b.func.call();
+let balances = b.results.balances();
+```
+
+
+
+
+```go
+b := coreaccounts.ScFuncs.TotalAssets(ctx)
+b.Func.Call()
+balances := b.Results.Balances()
+```
+
+
+
+
+---
+
+## `accounts`
+
+Get a list of all accounts that exist on the chain.
+
+### Returns
+
+A list of accounts (Agent IDs).
+
+
+
+
+```go
+accounts := chain.L2Accounts()
+```
+
+
+
+
+```go
+a := coreaccounts.ScFuncs.Accounts(ctx)
+a.Func.Call()
+require.NoError(t, ctx.Err)
+accounts := a.Results.AllAccounts()
+```
+
+
+
+
+```rust
+let a = coreaccounts::ScFuncs::accounts(ctx);
+a.func.call();
+let accounts = a.results.all_accounts();
+```
+
+
+
+
+```go
+a := coreaccounts.ScFuncs.Accounts(ctx)
+a.Func.Call()
+accounts := a.Results.AllAccounts()
+```
+
+
+
diff --git a/docs/build/wasp-wasm/0.7.0/docs/how-tos/withdraw-from-a-chain.mdx b/docs/build/wasp-wasm/0.7.0/docs/how-tos/withdraw-from-a-chain.mdx
new file mode 100644
index 00000000000..c348e414ebe
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/how-tos/withdraw-from-a-chain.mdx
@@ -0,0 +1,60 @@
+---
+description: The `withdraw` endpoint sends L2 funds owned by the caller to their L1 address.
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - smart contracts
+ - withdraw
+ - transfer
+ - chain
+ - Rust
+ - Solo
+ - how to
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# How to Withdraw From a Chain
+
+The `withdraw` endpoint sends L2 funds owned by the caller to their L1 address.
+
+
+
+
+```go
+// withdraw from chain to wallet
+req := solo.NewCallParams(accounts.Contract.Name, accounts.FuncWithdraw.Name)
+_, err := chain.PostRequestSync(req.WithMaxAffordableGasBudget(), wallet)
+require.NoError(t, err)
+```
+
+
+
+
+```go
+// withdraw from chain to wallet
+w := coreaccounts.ScFuncs.Withdraw(ctx.Sign(wallet))
+w.Func.Post()
+require.NoError(t, ctx.Err)
+```
+
+
+
+
+```rust
+// withdraw from chain to wallet
+let w = coreaccounts::ScFuncs::withdraw(ctx.sign(wallet));
+w.func.post();
+```
+
+
+
+
+```go
+// withdraw from chain to wallet
+w := coreaccounts.ScFuncs.Withdraw(ctx.sign(wallet))
+w.Func.Post()
+```
+
+
+
diff --git a/docs/build/wasp-wasm/0.7.0/docs/introduction.mdx b/docs/build/wasp-wasm/0.7.0/docs/introduction.mdx
new file mode 100644
index 00000000000..825a6d38daf
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/introduction.mdx
@@ -0,0 +1,71 @@
+---
+description: "Get to know IOTA Smart Contracts' flexible programming with Wasm VM, supporting a secure and dynamic smart contract development environment."
+keywords:
+ - IOTA Smart Contracts
+ - Wasm VM
+ - Smart contract development
+ - WasmLib
+ - Supported languages
+image: /img/wasm_vm/IscHost.png
+---
+
+# Introduction to the Wasm VM for ISC
+
+:::warning
+The Wasm VM is in experimental state, showcasing ISC's "VM plugin" architecture.
+
+Experiment but avoid using it for production applications; opt for [EVM](/wasp-evm/introduction).
+:::
+
+:::caution
+
+Smart Contracts are currently only compatible with the [Stardust protocol](/learn/protocols/stardust/introduction) and
+therefore only compatible with the [Shimmer](/build/networks-endpoints/#shimmer) and
+[Public Testnet networks](/build/networks-endpoints/#public-testnet).
+
+:::
+
+IOTA Smart Contracts (ISC) provide a sandboxed environment through an API, facilitating secure and deterministic interactions with ISC functions. This API supports any Virtual Machine (VM) aiming to build a system for smart contract code execution on ISC.
+
+
+
+We offer a VM example utilizing [WebAssembly (Wasm)](https://webassembly.org/) as a compilation target, facilitated by the open-source [Wasmtime runtime](https://wasmtime.dev/). This setup encourages dynamic smart contract operations compiled to Wasm code, promoting security and adaptability with different programming languages.
+
+
+
+The Wasm VM operates with self-contained `WasmLib` libraries linked to individual Wasm codes, optimizing the ISC sandbox functionality and smart contract state storage access.
+
+## Supported Functionalities
+
+The ISC sandbox environment offers:
+
+- Smart contract metadata and state data access
+- Request data retrieval for function calls
+- Token management within the contract
+- Utility functions from the host
+- Smooth initiation of other smart contract functions
+- Logging facility
+
+## Supported Languages
+
+The WasmLib started with [Rust](https://www.rust-lang.org/) support, expanding to include [Go](https://golang.org/) and [TypeScript](https://www.typescriptlang.org/) with the help of respective Wasm code generators:
+
+| Language | Wasm code generator |
+| ---------- | -------------------------------------------------- |
+| Go | [TinyGo](https://tinygo.org/) |
+| Rust | [wasm-pack](https://rustwasm.github.io/wasm-pack/) |
+| TypeScript | [AssemblyScript](https://www.assemblyscript.org/) |
+
+These generators maintain a common subset of their host language, aiming for a unified coding style to simplify the initiation into smart contract creation, welcoming developers with a C-style language background to quickly adapt.
+
+## Video Tutorial
+
+
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/accounts.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/accounts.md
new file mode 100644
index 00000000000..8c4976745b6
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/accounts.md
@@ -0,0 +1,352 @@
+---
+description: 'The `accounts` contract keeps the ledger of on-chain accounts.'
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - core contracts
+ - accounts
+ - deposit
+ - withdraw
+ - assets
+ - balance
+ - reference
+---
+
+# The `accounts` Contract
+
+The `accounts` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts
+chain.
+
+This contract keeps a consistent ledger of on-chain accounts in its state,
+i.e. [the L2 ledger](../../explanations/how-accounts-work.md).
+
+---
+
+## Entry Points
+
+The `accounts` contract provides functions to deposit and withdraw tokens, information about the assets deposited on the
+chain, and the functionality to create and use foundries.
+
+### `deposit()`
+
+A no-op that has the side effect of crediting any transferred tokens to the sender's account.
+
+:::note Gas Fees
+
+As with every call, the gas fee is debited from the L2 account right after executing the request.
+
+:::
+
+### `withdraw()`
+
+Moves tokens from the caller's on-chain account to the caller's L1 address. The number of
+tokens to be withdrawn must be specified via the allowance of the request.
+
+:::note Contract Account
+
+Because contracts does not have a corresponding L1 address it does not make sense to
+have them call this function. It will fail with an error.
+
+:::
+
+:::note Storage Deposit
+
+A call to withdraw means that a L1 output will be created. Because of this, the withdrawn
+amount must be able to cover the L1 storage deposit. Otherwise, it will fail.
+
+:::
+
+### `transferAllowanceTo(a AgentID)`
+
+Transfers the specified allowance from the sender's L2 account to the given L2 account on
+the chain.
+
+#### Parameters
+
+- `a` (`AgentID`): The target L2 account.
+
+### `transferAccountToChain(g GasReserve)`
+
+Transfers the specified allowance from the sender SC's L2 account on
+the target chain to the sender SC's L2 account on the origin chain.
+
+#### Parameters
+
+- `g` (`uint64`): Optional gas amount to reserve in the allowance for
+ the internal call to transferAllowanceTo(). Default 100 (MinGasFee).
+
+:::note Important Detailed Information
+
+[Read carefully before using this function.](xfer.md)
+
+:::
+
+### `foundryCreateNew(t TokenScheme) s SerialNumber`
+
+Creates a new foundry with the specified token scheme, and assigns the foundry to the sender.
+
+You can call this end point from the CLI using `wasp-cli chain create-foundry -h`
+
+#### Parameters
+
+- `t` ([`iotago::TokenScheme`](https://github.com/iotaledger/iota.go/blob/develop/token_scheme.go)): The token scheme
+ for the new foundry.
+
+The storage deposit for the new foundry must be provided via allowance (only the minimum required will be used).
+
+#### Returns
+
+- `s` (`uint32`): The serial number of the newly created foundry
+
+### `foundryModifySupply(s SerialNumber, d SupplyDeltaAbs, y DestroyTokens)`
+
+Mints or destroys tokens for the given foundry, which must be controlled by the caller.
+
+#### Parameters
+
+- `s` (`uint32`): The serial number of the foundry.
+- `d` (positive `big.Int`): Amount to mint or destroy.
+- `y` (optional `bool` - default: `false`): Whether to destroy tokens (`true`) or not (`false`).
+
+When minting new tokens, the storage deposit for the new output must be provided via an allowance.
+
+When destroying tokens, the tokens to be destroyed must be provided via an allowance.
+
+### `foundryDestroy(s SerialNumber)`
+
+Destroys a given foundry output on L1, reimbursing the storage deposit to the caller. The foundry must be owned by the
+caller.
+
+:::warning
+
+This operation cannot be reverted.
+
+:::
+
+#### Parameters
+
+- `s` (`uint32`): The serial number of the foundry.
+
+### `mintNFT(I ImmutableData, a AgentID, C CollectionID, w WithdrawOnMint)`
+
+Mints an NFT with ImmutableData `I` that will be owned by the AgentID `a`.
+It's possible to mint as part of a collection `C` (the caller must be the owner of the collection NFT to mint new NFTs as part of said collection).
+The mint can be done directly to any L1 address (it is not necessary for the target to have an account on the chain)
+
+#### Parameters
+
+- `I` (`[]byte`): ImmutableData for the NFT.
+- `a` (`AgentID`): AgentID that will be the owner of the NFT.
+- `C` (optional `NFTID` - default empty): collectionID (NFTID) for the NFT.
+- `w` (optional `bool` - default `false`): whether to withdrawal the NFT in the minting step (can only be `true` when the targetAgentID is a L1 address).
+
+#### Returns
+
+- `D` (`MintID`): the internal ID of the NFT at the time of minting that can be used by users/contracts to obtain the resulting NFTID on the next block
+
+---
+
+## Views
+
+### `balance(a AgentID)`
+
+Returns the fungible tokens owned by the given Agent ID on the chain.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID.
+
+#### Returns
+
+A map of [`TokenID`](#tokenid) => `big.Int`. An empty token ID (a string of zero length) represents the L1 base token.
+
+### `balanceBaseToken(a AgentID)`
+
+Returns the amount of base tokens owned by any AgentID `a` on the chain.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID.
+
+#### Returns
+
+- `B` (`uint64`): The amount of base tokens in the account.
+
+### `balanceNativeToken(a AgentID, N TokenID)`
+
+Returns the amount of native tokens with Token ID `N` owned by any AgentID `a` on the chain.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID.
+- `N` ([`TokenID`](#tokenid)): The Token ID.
+
+#### Returns
+
+- `B` (`big.Int`): The amount of native tokens in the account.
+
+### `totalAssets()`
+
+Returns the sum of all fungible tokens controlled by the chain.
+
+#### Returns
+
+A map of [`TokenID`](#tokenid) => `big.Int`. An empty token ID (a string of zero length) represents the L1 base token.
+
+### `accounts()`
+
+Returns a list of all agent IDs that own assets on the chain.
+
+#### Returns
+
+A map of `AgentiD` => `0x01`.
+
+### `getNativeTokenIDRegistry()`
+
+Returns a list of all native tokenIDs that are owned by the chain.
+
+#### Returns
+
+A map of [`TokenID`](#tokenid) => `0x01`
+
+### `foundryOutput(s FoundrySerialNumber)`
+
+#### Parameters
+
+- `s` ([`FoundrySerialNumber`](#foundryserialnumber)): The Foundry serial number.
+
+#### Returns
+
+- `b`: [`iotago::FoundryOutput`](https://github.com/iotaledger/iota.go/blob/develop/output_foundry.go)
+
+### `accountNFTs(a AgentID)`
+
+Returns the NFT IDs for all NFTs owned by the given account.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID
+
+#### Returns
+
+- `i` ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go)
+ of [`iotago::NFTID`](https://github.com/iotaledger/iota.go/blob/develop/output_nft.go)):
+ The NFT IDs owned by the account
+
+### `accountNFTAmount(a AgentID)`
+
+Returns the number of NFTs owned by the given account.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID
+
+#### Returns
+
+- `A` (`uint32`) Amount of NFTs owned by the account
+
+### `accountNFTsInCollection(a AgentID)`
+
+Returns the NFT IDs for all NFTs in the given collection that are owned by the given account.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID
+- `C` (`NFTID`): The NFT ID of the collection
+
+#### Returns
+
+- `i` ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go)
+ of [`iotago::NFTID`](https://github.com/iotaledger/iota.go/blob/develop/output_nft.go)):
+ The NFT IDs in the collection owned by the account
+
+### `accountNFTAmountInCollection(a AgentID)`
+
+Returns the number of NFTs in the given collection that are owned by the given account.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID
+- `C` (`NFTID`): The NFT ID of the collection
+
+#### Returns
+
+- `A` (`uint32`) Amount of NFTs in the collection owned by the account
+
+### `accountFoundries(a AgentID)`
+
+Returns all foundries owned by the given account.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID
+
+#### Returns
+
+A map of [`FoundrySerialNumber`](#foundryserialnumber) => `0x01`
+
+### `nftData(z NFTID)`
+
+Returns the data for a given NFT with ID `z` that is on the chain.
+
+#### Returns
+
+- `e`: [`NFTData`](#nftdata)
+
+### `NFTIDbyMintID(D MintID)`
+
+Returns the NFTID `z` for a given MintID `D`.
+
+#### Parameters
+
+- `D` (`MintID`): MintID producted at the time the NFT was minted
+
+#### Returns
+
+- `z` (`NFTID`): The ID of the NFT
+
+### `getAccountNonce(a AgentID)`
+
+Returns the current account nonce for a give AgentID `a`.
+The account nonce is used to issue off-ledger requests.
+
+#### Parameters
+
+- `a` (`AgentID`): The account Agent ID.
+
+#### Returns
+
+- `n` (`uint64`): The account nonce.
+
+## Schemas
+
+### `FoundrySerialNumber`
+
+```
+FoundrySerialNumber = uint32
+```
+
+### `TokenID`
+
+```
+TokenID = [38]byte
+```
+
+### `NFTID`
+
+```
+NFTID = [32]byte
+```
+
+### `MintID`
+
+```
+MintID = [6]byte
+```
+
+### `NFTData`
+
+`NFTData` is encoded as the concatenation of:
+
+- The issuer ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)).
+- The NFT metadata: the length (`uint16`) followed by the data bytes.
+- The NFT owner (`AgentID`).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/blob.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/blob.md
new file mode 100644
index 00000000000..2c3e84e3bfa
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/blob.md
@@ -0,0 +1,108 @@
+---
+description: The `blobs` contract maintains a registry of _blobs_ (a collection of arbitrary binary data) referenced from smart contracts via their hashes.
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - core contracts
+ - bloc
+ - binary data
+ - store
+ - get
+ - entry points
+ - views
+ - reference
+---
+
+# The `blob` Contract
+
+The `blob` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain.
+
+The objective of the `blob` contract is to maintain an on-chain registry of _blobs_.
+A blob is a collection of named chunks of binary data.
+
+```
+:
+:
+...
+:
+```
+
+Both names and chunks are arbitrarily long byte slices.
+
+Blobs can be used to store arbitrary data like, for example, a collection of Wasm binaries needed to deploy a smart contract.
+
+Each blob in the registry is referenced by its hash. The hash is deterministically calculated from the concatenation of all pieces:
+
+```
+blobHash = hash( fieldName1 || binaryChunk1 || fieldName2 || binaryChunk2 || ... || fieldNameN || binaryChunkN)
+```
+
+Usually, field names are short strings, but their interpretation is use-case specific.
+
+Two predefined field names are interpreted by the VM while deploying smart contracts from binary:
+
+- _fieldname_ = `"v"` is interpreted as the _VM type_.
+- _fieldname_ = `"p"` is interpreted as the _smart contract program binary_.
+
+If the field `"v"` is equal to the string `"wasmtime"`, the binary chunk of `"p"` is interpreted as WebAssembly binary, executable by the Wasmtime interpreter.
+
+The blob describing a smart contract may contain extra fields (ignored by the VM), for example:
+
+```
+"v" : VM type
+"p" : smart contract program binary
+"d" : data schema for data exchange between smart contract and outside sources and consumers
+"s" : program sources in .zip format
+```
+
+---
+
+## Entry Points
+
+### `storeBlob()`
+
+Stores a new blob in the registry.
+
+#### Parameters
+
+The key/value pairs of the received parameters are interpreted as the field/chunk pairs of the blob.
+
+#### Returns
+
+- `hash` (`[32]byte`): The hash of the stored blob.
+
+---
+
+## Views
+
+### `getBlobInfo(hash BlobHash)`
+
+Returns the size of each chunk of the blob.
+
+#### Parameters
+
+- `hash` (`[32]byte`): The hash of the blob.
+
+#### Returns
+
+```
+: (uint32)
+...
+: (uint32)
+```
+
+### `getBlobField(hash BlobHash, field BlobField)`
+
+Returns the chunk associated with the given blob field name.
+
+#### Parameters
+
+- `hash` (`[32]byte`): The hash of the blob.
+- `field` (`[]byte`): The field name.
+
+#### Returns
+
+- `bytes` (`[]byte`): The chunk associated with the given field name.
+
+### `listBlobs()`
+
+Returns a list of pairs `blob hash`: `total size of chunks` (`uint32`) for all blobs in the registry.
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/blocklog.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/blocklog.md
new file mode 100644
index 00000000000..af6f4a9552e
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/blocklog.md
@@ -0,0 +1,202 @@
+---
+description: The `blocklog` contract keeps track of the blocks of requests processed by the chain.
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - core contracts
+ - blocklog
+ - views
+ - information
+ - request status
+ - receipts
+ - events
+ - reference
+---
+
+# The `blocklog` Contract
+
+The `blocklog` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain.
+
+The `blocklog` contract keeps track of the blocks of requests processed by the chain, providing views to get request
+status, receipts, block, and event details.
+
+To avoid having a monotonically increasing state size, only the latest `N`
+blocks (and their events and receipts) are stored. This parameter can be configured
+when [deploying the chain](/wasp-cli/how-tos/setting-up-a-chain/).
+
+---
+
+## Entry Points
+
+### `retryUnprocessable(u requestID)`
+
+Tries to retry a given request that was marked as "unprocessable".
+
+:::note
+"Unprocessable" requests are on-ledger requests that do not include enough base tokens to cover the deposit fees (example if an user tries to deposit many native tokens in a single output but only includes the minimum possible amount of base tokens). Such requests will be collected into an "unprocessable list" and users are able to deposit more funds onto their on-chain account and retry them afterwards.
+:::
+
+#### Parameters
+
+- `u` ([`isc::RequestID`](https://github.com/iotaledger/wasp/blob/develop/packages/isc/request.go)): The requestID to be retried. (sender of the retry request must match the sender of the "unprocessable" request)
+
+---
+
+## Views
+
+### `getBlockInfo(n uint32)`
+
+Returns information about the block with index `n`.
+
+#### Parameters
+
+- `n`: (optional `uint32`) The block index. Default: the latest block.
+
+#### Returns
+
+- `n` (`uint32`):The block index.
+- `i` ([`BlockInfo`](#blockinfo)):The information about the block.
+
+### `getRequestIDsForBlock(n uint32)`
+
+Returns a list with all request IDs in the block with block index `n`.
+
+#### Parameters
+
+- `n` (optional `uint32`):The block index. The default value is the latest block.
+
+#### Returns
+
+- `n` (`uint32`):The block index.
+- `u`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go)
+ of [`RequestID`](#requestid))
+
+### `getRequestReceipt(u RequestID)`
+
+Returns the receipt for the request with the given ID.
+
+#### Parameters
+
+- `u` ([`RequestID`](#requestid)):The request ID.
+
+#### Returns
+
+- `n` (`uint32`):The block index.
+- `r` (`uint16`):The request index within the block.
+- `d` ([`RequestReceipt`](#requestreceipt)):The request receipt.
+
+### `getRequestReceiptsForBlock(n uint32)`
+
+Returns all the receipts in the block with index `n`.
+
+#### Parameters
+
+- `n` (optional `uint32`):The block index. Defaults to the latest block.
+
+#### Returns
+
+- `n` (`uint32`):The block index.
+- `d`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go)
+ of [`RequestReceipt`](#requestreceipt))
+
+### `isRequestProcessed(u RequestID)`
+
+Returns whether the request with ID `u` has been processed.
+
+#### Parameters
+
+- `u` ([`RequestID`](#requestid)):The request ID.
+
+#### Returns
+
+- `p` (`bool`):Whether the request was processed or not.
+
+### `getEventsForRequest(u RequestID)`
+
+Returns the list of events triggered during the execution of the request with ID `u`.
+
+### Parameters
+
+- `u` ([`RequestID`](#requestid)):The request ID.
+
+#### Returns
+
+- `e`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) of `[]byte`).
+
+### `getEventsForBlock(n blockIndex)`
+
+Returns the list of events triggered during the execution of all requests in the block with index `n`.
+
+#### Parameters
+
+- `n` (optional `uint32`):The block index. Defaults to the latest block.
+
+#### Returns
+
+- `e`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) of `[]byte`).
+
+### `getEventsForContract(h Hname)`
+
+Returns a list of events triggered by the smart contract with hname `h`.
+
+#### Parameters
+
+- `h` (`hname`):The smart contract’s hname.
+- `f` (optional `uint32` - default: `0`):"From" block index.
+- `t` (optional `uint32` - default: `MaxUint32`):"To" block index.
+
+#### Returns
+
+- `e`: ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go) of `[]byte`)
+
+### `hasUnprocessable(u requestID)`
+
+Asserts whether or not a given requestID (`u`) is present in the "unprocessable list"
+
+#### Parameters
+
+- `u` ([`isc::RequestID`](https://github.com/iotaledger/wasp/blob/develop/packages/isc/request.go)): The requestID to be checked
+
+#### Returns
+
+- `x` ([`bool`]) Whether or not the request exists in the "unprocessable list"
+
+---
+
+## Schemas
+
+### `RequestID`
+
+A `RequestID` is encoded as the concatenation of:
+
+- Transaction ID (`[32]byte`).
+- Transaction output index (`uint16`).
+
+### `BlockInfo`
+
+`BlockInfo` is encoded as the concatenation of:
+
+- The block timestamp (`uint64` UNIX nanoseconds).
+- Amount of requests in the block (`uint16`).
+- Amount of successful requests (`uint16`).
+- Amount of off-ledger requests (`uint16`).
+- Anchor transaction ID ([`iotago::TransactionID`](https://github.com/iotaledger/iota.go/blob/develop/transaction.go)).
+- Anchor transaction sub-essence hash (`[32]byte`).
+- Previous L1 commitment (except for block index 0).
+ - Trie root (`[20]byte`).
+ - Block hash (`[20]byte`).
+- Total base tokens in L2 accounts (`uint64`).
+- Total storage deposit (`uint64`).
+- Gas burned (`uint64`).
+- Gas fee charged (`uint64`).
+
+### `RequestReceipt`
+
+`RequestReceipt` is encoded as the concatenation of:
+
+- Gas budget (`uint64`).
+- Gas burned (`uint64`).
+- Gas fee charged (`uint64`).
+- The request ([`isc::Request`](https://github.com/iotaledger/wasp/blob/develop/packages/isc/request.go)).
+- Whether the request produced an error (`bool`).
+- If the request produced an error, the
+ [`UnresolvedVMError`](./errors.md#unresolvedvmerror).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/errors.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/errors.md
new file mode 100644
index 00000000000..d3d3db383a8
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/errors.md
@@ -0,0 +1,77 @@
+---
+description: 'The errors contract keeps a map of error codes to error message templates. These error codes are used in
+request receipts.'
+image: /img/logo/WASP_logo_dark.png
+keywords:
+
+- smart contracts
+- core
+- root
+- initialization
+- entry points
+- fees
+- ownership
+- views
+- reference
+---
+
+# The `errors` Contract
+
+The `errors` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts
+chain.
+
+The `errors` contract keeps a map of error codes to error message templates.
+This allows contracts to store lengthy error strings only once and then reuse them by just providing the error code (and
+optional extra values) when producing an error, thus saving storage and gas.
+
+---
+
+## Entry Points
+
+### `registerError(m ErrorMessageFormat) c ErrorCode`
+
+Registers an error message template.
+
+#### Parameters
+
+- `m` (`string`): The error message template, which supports standard [go verbs](https://pkg.go.dev/fmt#hdr-Printing)
+ for variable printing.
+
+#### Returns
+
+- `c` (`ErrorCode`): The error code of the registered template
+
+---
+
+## Views
+
+### `getErrorMessageFormat(c ErrorCode) m ErrorMessageFormat`
+
+Returns the message template stored for a given error code.
+
+#### Parameters
+
+- `c` (`ErrorCode`): The error code of the registered template.
+
+#### Returns
+
+- `m` (`string`): The error message template.
+
+---
+
+## Schemas
+
+### `ErrorCode`
+
+`ErrorCode` is encoded as the concatenation of:
+
+- The contract hname(`hname`).
+- The error ID, calculated as the hash of the error template(`uint16`).
+
+### `UnresolvedVMError`
+
+`UnresolvedVMError` is encoded as the concatenation of:
+
+- The error code ([`ErrorCode`](#errorcode)).
+- CRC32 checksum of the formatted string (`uint32`).
+- The JSON-encoded list of parameters for the template (`string` prefixed with `uint16` size).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/evm.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/evm.md
new file mode 100644
index 00000000000..9c9cb0ea038
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/evm.md
@@ -0,0 +1,170 @@
+---
+description: 'The evm core contract provides the necessary infrastructure to accept Ethereum transactions and execute
+EVM code.'
+image: /img/logo/WASP_logo_dark.png
+keywords:
+
+- smart contracts
+- core
+- root
+- initialization
+- entry points
+- fees
+- ownership
+- views
+- reference
+---
+
+# The `evm` Contract
+
+The `evm` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts chain.
+
+The `evm` core contract provides the necessary infrastructure to accept Ethereum transactions and execute EVM code.
+It also includes the implementation of the [ISC Magic contract](/wasp-evm/how-tos/magic-contract/magic).
+
+:::note
+
+For more information about how ISC supports EVM contracts, refer to the [EVM](/wasp-evm/introduction/) section.
+
+:::
+
+---
+
+## Entry Points
+
+Most entry points of the `evm` core contract are meant to be accessed through the JSON-RPC service provided
+automatically by the Wasp node so that the end users can use standard EVM tools like [MetaMask](https://metamask.io/).
+We only list the entry points not exposed through the JSON-RPC interface in this document.
+
+### `init()`
+
+Called automatically when the ISC is deployed.
+
+Some parameters of the `evm` contract can be specified by passing them to the
+[`root` contract `init` entry point](root.md#init):
+
+- `evmg` (optional [`GenesisAlloc`](#genesisalloc)): The genesis allocation. The balance of all accounts must be 0.
+- `evmbk` (optional `int32` - default: keep all): Amount of EVM blocks to keep in the state.
+- `evmchid` (optional `uint16` - default: 1074): EVM chain iD
+
+ :::caution
+
+ Re-using an existing Chain ID is not recommended and can be a security risk. For serious usage, register a unique
+ Chain ID on [Chainlist](https://chainlist.org/) and use that instead of the default. **It is not possible to change
+ the EVM chain ID after deployment.**
+
+ :::
+
+- `evmw` (optional [`GasRatio`](#gasratio) - default: `1:1`): The ISC to EVM gas ratio.
+
+### `registerERC20NativeToken`
+
+Registers an ERC20 contract to act as a proxy for the native tokens, at address
+`0x107402xxxxxxxx00000000000000000000000000`, where `xxxxxxxx` is the
+little-endian encoding of the foundry serial number.
+
+Only the foundry owner can call this endpoint.
+
+#### Parameters
+
+- `fs` (`uint32`): The foundry serial number
+- `n` (`string`): The token name
+- `t` (`string`): The ticker symbol
+- `d` (`uint8`): The token decimals
+
+You can call this endpoint with the `wasp-cli register-erc20-native-token` command. See
+`wasp-cli chain register-erc20-native-token -h` for instructions on how to use the command.
+
+### `registerERC20NativeTokenOnRemoteChain`
+
+Registers an ERC20 contract to act as a proxy for the native tokens **on another
+chain**.
+
+The foundry must be controlled by this chain. Only the foundry owner can call
+this endpoint.
+
+This endpoint is intended to be used in case the foundry is controlled by chain
+A, and the owner of the foundry wishes to register the ERC20 contract on chain
+B. In that case, the owner must call this endpoint on chain A with `target =
+chain B`. The request to chain B is then sent as an on-ledger request.
+After a few minutes, call
+[`getERC20ExternalNativeTokensAddress`](#geterc20externalnativetokensaddress)
+on chain B to find out the address of the ERC20 contract.
+
+#### Parameters
+
+- `fs` (`uint32`): The foundry serial number
+- `n` (`string`): The token name
+- `t` (`string`): The ticker symbol
+- `d` (`uint8`): The token decimals
+- `A` (`uint8`): The target chain address, where the ERC20 contract will be
+ registered.
+
+You can call this endpoint with the `wasp-cli register-erc20-native-token-on-remote-chain` command. See
+`wasp-cli chain register-erc20-native-token-on-remote-chain -h` for instructions on how to use the command.
+
+### `registerERC20ExternalNativeToken`
+
+Registers an ERC20 contract to act as a proxy for the native tokens.
+
+Only an alias address can call this endpoint.
+
+If the foundry is controlled by another ISC chain, the foundry owner can call
+[`registerERC20NativeTokenOnRemoteChain`](#registererc20nativetokenonchain)
+on that chain, which will automatically call this endpoint on the chain set as
+target.
+
+#### Parameters
+
+- `fs` (`uint32`): The foundry serial number
+- `n` (`string`): The token name
+- `t` (`string`): The ticker symbol
+- `d` (`uint8`): The token decimals
+- `T` (`TokenScheme`): The native token scheme
+
+### `registerERC721NFTCollection`
+
+Registers an ERC721 contract to act as a proxy for an NFT collection, at address
+`0x107404xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`, where `xxx...` is the first 17
+bytes of the collection ID.
+
+The call will fail if the address is taken by another collection with the same prefix.
+
+#### Parameters
+
+- `C` (`NTFID`): The collection ID
+
+---
+
+## Views
+
+### `getERC20ExternalNativeTokensAddress`
+
+Returns the address of an ERC20 contract registered with
+[`registerERC20NativeTokenOnRemoteChain`](#registererc20nativetokenonchain).
+
+Only the foundry owner can call this endpoint.
+
+#### Parameters
+
+- `N` (`NativeTokenID`): The native token ID
+
+---
+
+## Schemas
+
+### `GenesisAlloc`
+
+`GenesisAlloc` is encoded as the concatenation of:
+
+- Amount of accounts `n` (`uint32`).
+- `n` times:
+ - Ethereum address (`[]byte` prefixed with `uint32` size).
+ - Account code (`[]byte` prefixed with `uint32` size).
+ - Amount of storage key/value pairs `m`(`uint32`).
+ - `m` times:
+ - Key (`[]byte` prefixed with `uint32` size).
+ - Value(`[]byte` prefixed with `uint32` size).
+ - Account balance (must be 0)(`[]byte` prefixed with `uint32` size).
+ - Account nonce (`uint64`).
+ - Account private key (may be used for tests)(`uint64`).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/governance.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/governance.md
new file mode 100644
index 00000000000..dd8faaa0ab6
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/governance.md
@@ -0,0 +1,355 @@
+---
+description: 'The `governance` contract defines the set of identities that constitute the state controller, access nodes,
+who is the chain owner, and the fees for request execution.'
+image: /img/logo/WASP_logo_dark.png
+keywords:
+
+- core contracts
+- governance
+- state controller
+- identities
+- chain owner
+- rotate
+- remove
+- claim
+- add
+- chain info
+- fee info
+- reference
+---
+
+# The `governance` Contract
+
+The `governance` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts
+chain.
+
+The `governance` contract provides the following functionalities:
+
+- It defines the identity set that constitutes the state controller (the entity that owns the state output via the chain
+ Alias Address). It is possible to add/remove addresses from the state controller (thus rotating the committee of
+ validators).
+- It defines the chain owner (the L1 entity that owns the chain - initially whoever deployed it). The chain owner can
+ collect special fees and customize some chain-specific parameters.
+- It defines the entities allowed to have an access node.
+- It defines the fee policy for the chain (gas price, what token is used to pay for gas, and the validator fee share).
+
+---
+
+## Fee Policy
+
+The Fee Policy looks like the following:
+
+```go
+{
+ GasPerToken Ratio32 // how many gas units are paid for each token
+ EVMGasRatio Ratio32 // the ratio at which EVM gas is converted to ISC gas
+ ValidatorFeeShare uint8 // percentage of the fees that are credited to the validators (0 - 100)
+}
+```
+
+---
+
+## Entry Points
+
+### `rotateStateController(S StateControllerAddress)`
+
+Called when the committee is about to be rotated to the new address `S`.
+
+If it succeeds, the next state transition will become a governance transition, thus updating the state controller in the
+chain's Alias Output. If it fails, nothing happens.
+
+It can only be invoked by the chain owner.
+
+#### Parameters
+
+- `S` ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The address of the next
+ state controller. Must be an
+ [allowed](#addallowedstatecontrolleraddresss-statecontrolleraddress) state controller address.
+
+### `addAllowedStateControllerAddress(S StateControllerAddress)`
+
+Adds the address `S` to the list of identities that constitute the state controller.
+
+It can only be invoked by the chain owner.
+
+#### Parameters
+
+- `S` ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The address to add to the
+ set of allowed state controllers.
+
+### `removeAllowedStateControllerAddress(S StateControllerAddress)`
+
+Removes the address `S` from the list of identities that constitute the state controller.
+
+It can only be invoked by the chain owner.
+
+#### Parameters
+
+- `S` ([`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The address to remove from
+ the set of allowed state controllers.
+
+### `delegateChainOwnership(o AgentID)`
+
+Sets the Agent ID `o` as the new owner for the chain. This change will only be effective
+once [`claimChainOwnership`](#claimchainownership) is called by `o`.
+
+It can only be invoked by the chain owner.
+
+#### Parameters
+
+- `o` (`AgentID`): The Agent ID of the next chain owner.
+
+### `claimChainOwnership()`
+
+Claims the ownership of the chain if the caller matches the identity set
+in [`delegateChainOwnership`](#delegatechainownershipo-agentid).
+
+### `setFeePolicy(g FeePolicy)`
+
+Sets the fee policy for the chain.
+
+#### Parameters
+
+- `g`: ([`FeePolicy`](#feepolicy)).
+
+It can only be invoked by the chain owner.
+
+### `setGasLimits(l GasLimits)`
+
+Sets the gas limits for the chain.
+
+#### Parameters
+
+- `l`: ([`GasLimits`](#gaslimits)).
+
+It can only be invoked by the chain owner.
+
+### `setEVMGasRatio(e Ratio32)`
+
+Sets the EVM gas ratio for the chain.
+
+#### Parameters
+
+- `e` ([`Ratio32`](#ratio32)): The EVM gas ratio.
+
+It can only be invoked by the chain owner.
+
+### `addCandidateNode(ip PubKey, ic Certificate, ia API, i ForCommittee)`
+
+Adds a node to the list of candidates.
+
+#### Parameters
+
+- `ip` (`[]byte`): The public key of the node to be added.
+- `ic` (`[]byte`): The certificate is a signed binary containing both the node public key and their L1 address.
+- `ia` (`string`): The API base URL for the node.
+- `i` (optional `bool` - default: `false`): Whether the candidate node is being added to be part of the committee or
+ just an access node.
+
+It can only be invoked by the access node owner (verified via the Certificate field).
+
+### `revokeAccessNode(ip PubKey, ic Certificate, ia API, i ForCommittee)`
+
+Removes a node from the list of candidates.
+
+#### Parameters
+
+- `ip` (`[]byte`): The public key of the node to be removed.
+- `ic` (`[]byte`): The certificate of the node to be removed.
+
+It can only be invoked by the access node owner (verified via the Certificate field).
+
+### `changeAccessNodes(n actions)`
+
+Iterates through the given map of actions and applies them.
+
+#### Parameters
+
+- `n` ([`Map`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/map.go) of `public key` => `byte`):
+ The list of actions to perform. Each byte value can be one of the following:
+ - `0`: Remove the access node from the access nodes list.
+ - `1`: Accept a candidate node and add it to the list of access nodes.
+ - `2`: Drop an access node from the access node and candidate lists.
+
+It can only be invoked by the chain owner.
+
+### `startMaintenance()`
+
+Starts the chain maintenance mode, meaning no further requests will be processed except
+calls to the governance contract.
+
+It can only be invoked by the chain owner.
+
+### `stopMaintenance()`
+
+Stops the maintenance mode.
+
+It can only be invoked by the chain owner.
+
+### `setCustomMetadata(x bytes)`
+
+Changes optional extra metadata that is appended to the L1 AliasOutput.
+
+#### Parameters
+
+- `x` (`bytes`): the optional metadata
+
+### `setPayoutAgentID`
+
+`setPayoutAgentID` sets the payout AgentID. The default AgentID is the chain owner. Transaction fee will be taken to ensure the common account has minimum storage deposit which is in base token. The rest of transaction fee will be transferred to payout AgentID.
+
+#### Parameters
+
+- `s` (`AgentID`): the payout AgentID
+
+### `setMinCommonAccountBalance`
+
+`setMinCommonAccountBalance` sets the minimum balanced to be held in the common account.
+
+#### Parameters
+
+- `ms` (`AgentID`): the minimum common account balance
+
+---
+
+## Views
+
+### `getAllowedStateControllerAddresses()`
+
+Returns the list of allowed state controllers.
+
+#### Returns
+
+- `a` ([`Array`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/array.go)
+ of [`iotago::Address`](https://github.com/iotaledger/iota.go/blob/develop/address.go)): The list of allowed state
+ controllers.
+
+### `getChainOwner()`
+
+Returns the AgentID of the chain owner.
+
+#### Returns
+
+- `o` (`AgentID`): The chain owner.
+
+### `getChainInfo()`
+
+Returns information about the chain.
+
+#### Returns:
+
+- `c` (`ChainID`): The chain ID
+- `o` (`AgentID`): The chain owner
+- `g` ([`FeePolicy`](#feepolicy)): The gas fee policy
+- `l` ([`GasLimits`](#gaslimits)): The gas limits
+- `x` (`bytes`): The custom metadata
+
+### `getFeePolicy()`
+
+Returns the gas fee policy.
+
+#### Returns
+
+- `g` ([`FeePolicy`](#feepolicy)): The gas fee policy.
+
+### `getEVMGasRatio`
+
+Returns the ISC : EVM gas ratio.
+
+#### Returns
+
+- `e` ([`Ratio32`](#ratio32)): The ISC : EVM gas ratio.
+
+### `getGasLimits()`
+
+Returns the gas limits.
+
+#### Returns
+
+- `l` ([`GasLimits`](#gaslimits)): The gas limits.
+
+### `getChainNodes()`
+
+Returns the current access nodes and candidates.
+
+#### Returns
+
+- `ac` ([`Map`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/map.go)
+ of public key => `0x01`): The access nodes.
+- `an` ([`Map`](https://github.com/iotaledger/wasp/blob/develop/packages/kv/collections/map.go)
+ of public key => [`AccessNodeInfo`](#accessnodeinfo)): The candidate nodes.
+
+### `getMaintenanceStatus()`
+
+Returns whether the chain is undergoing maintenance.
+
+#### Returns
+
+- `m` (`bool`): `true` if the chain is in maintenance mode
+
+### `getCustomMetadata()`
+
+Returns the extra metadata that is added to the chain AliasOutput.
+
+#### Returns
+
+- `x` (`bytes`): the optional metadata
+
+### `getPayoutAgentID`
+
+`getPayoutAgentID` gets the payout AgentID.
+
+Returns the payout AgentID of the chain.
+
+#### Returns
+
+- `s` (`AgentID`): the payout AgentID.
+
+### `getMinCommonAccountBalance`
+
+`getMinCommonAccountBalance` returns the minimum balanced to be held in the common account.
+
+#### Returns
+
+- `ms` (`uint64`): the minimum storage deposit.
+
+## Schemas
+
+### `Ratio32`
+
+A ratio between two values `x` and `y`, expressed as two `int32` numbers `a:b`, where `y = x * b/a`.
+
+`Ratio32` is encoded as the concatenation of the two `uint32` values `a` & `b`.
+
+### `FeePolicy`
+
+`FeePolicy` is encoded as the concatenation of:
+
+- The [`TokenID`](accounts.md#tokenid) of the token used to charge for gas. (`iotago.NativeTokenID`)
+ - If this value is `nil`, the gas fee token is the base token.
+- Gas per token ([`Ratio32`](#ratio32)): expressed as an `a:b` (`gas/token`) ratio, meaning how many gas units each token pays for.
+- Validator fee share. Must be between 0 and 100, meaning the percentage of the gas fees distributed to the
+ validators. (`uint8`)
+- The ISC:EVM gas ratio ([`Ratio32`](#ratio32)): such that `ISC gas = EVM gas * a/b`.
+
+### `GasLimits`
+
+`GasLimits` is encoded as the concatenation of:
+
+- The maximum gas per block (`uint64`). A request that exceeds this limit is
+ skipped and processed in the next block.
+- The minimum gas per request (`uint64`). If a request consumes less than this
+ value, it is charged for this instead.
+- The maximum gas per request (`uint64`). If a request exceeds this limit, it
+ is rejected as failed.
+- The maximum gas per external view call (`uint64). This is the gas budget
+ assigned to external view calls.
+
+### `AccessNodeInfo`
+
+`AccessNodeInfo` is encoded as the concatenation of:
+
+- The validator address. (`[]byte` prefixed by `uint16` size)
+- The certificate. (`[]byte` prefixed by `uint16` size)
+- Whether the access node is part of the committee of validators. (`bool`)
+- The API base URL. (`string` prefixed by `uint16` size)
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/overview.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/overview.md
new file mode 100644
index 00000000000..2f88072657d
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/overview.md
@@ -0,0 +1,37 @@
+---
+description: There currently are 6 core smart contracts that are always deployed on each chain, root, _default, accounts, blob, blocklog, and governance.
+image: /img/Banner/banner_wasp_core_contracts_overview.png
+keywords:
+ - smart contracts
+ - core
+ - initialization
+ - request handling
+ - on-chain ledger
+ - accounts
+ - data
+ - receipts
+ - reference
+---
+
+# Core Contracts
+
+
+
+There are currently 7 core smart contracts that are always deployed on each
+chain. These are responsible for the vital functions of the chain and
+provide infrastructure for all other smart contracts:
+
+- [`root`](./root.md): Responsible for the initialization of the chain, maintains registry of deployed contracts.
+
+- [`accounts`](./accounts.md): Manages the on-chain ledger of accounts.
+
+- [`blob`](./blob.md): Responsible for the registry of binary objects of arbitrary size.
+
+- [`blocklog`](./blocklog.md): Keeps track of the blocks and receipts of requests that were processed by the chain.
+
+- [`governance`](./governance.md): Handles the administrative functions of the chain. For example: rotation of the committee of validators of the chain, fees and other chain-specific configurations.
+
+- [`errors`](./errors.md): Keeps a map of error codes to error messages templates. These error codes are used in request receipts.
+
+- [`evm`](./evm.md): Provides the necessary infrastructure to accept Ethereum
+ transactions and execute EVM code.
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/root.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/root.md
new file mode 100644
index 00000000000..9ff834a509f
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/root.md
@@ -0,0 +1,121 @@
+---
+description: 'The root contract is the first smart contract deployed on the chain. It functions as a smart contract
+factory for the chain.'
+image: /img/logo/WASP_logo_dark.png
+keywords:
+
+- smart contracts
+- core
+- root
+- initialization
+- entry points
+- fees
+- ownership
+- views
+- reference
+---
+
+# The `root` Contract
+
+The `root` contract is one of the [core contracts](overview.md) on each IOTA Smart Contracts
+chain.
+
+The `root` contract is responsible for the initialization of the chain.
+It is the first smart contract deployed on the chain and, upon receiving the `init` request, bootstraps the state of the
+chain.
+Deploying all of the other core contracts is a part of the state initialization.
+
+The `root` contract also functions as a smart contract factory for the chain: upon request, it deploys other smart
+contracts and maintains an on-chain registry of smart contracts in its state.
+The contract registry keeps a list of contract records containing their respective name, hname, description, and
+creator.
+
+---
+
+## Entry Points
+
+### `init()`
+
+The constructor. Automatically called immediately after confirmation of the origin transaction and never called again.
+When executed, this function:
+
+- Initializes base values of the chain according to parameters.
+- Sets the caller as the _chain owner_.
+- Deploys all the core contracts.
+
+### `deployContract(ph ProgramHash, nm Name, ds Description)`
+
+Deploys a non-EVM smart contract on the chain if the caller has deployment permission.
+
+#### Parameters
+
+- `ph` (`[32]byte`): The hash of the binary _blob_ (that has been previously stored in the [`blob` contract](blob.md)).
+- `nm` (`string`): The name of the contract to be deployed, used to calculate the
+ contract's _hname_. The hname must be unique among all contract hnames in the chain.
+- `ds` (`string`): Description of the contract to be deployed.
+
+Any other parameters that are passed to the deployContract function will be passed on to
+the `init` function of the smart contract being deployed. Note that this means that the
+init parameter names cannot be the above ones, as they will have been filtered out.
+
+### `grantDeployPermission(dp AgentID)`
+
+The chain owner grants deploy permission to the agent ID `dp`.
+
+#### Parameters
+
+`dp`(AgentID): The agent ID.
+
+### `revokeDeployPermission(dp AgentID)`
+
+The chain owner revokes the deploy permission of the agent ID `dp`.
+
+#### Parameters
+
+`dp`(AgentID): The agent ID.
+
+### `requireDeployPermissions(de DeployPermissionsEnabled)`
+
+#### Parameters
+
+- `de` (`bool`): Whether permissions should be required to deploy a contract on the chain.
+
+By default, permissions are enabled (addresses need to be granted the right to deploy), but the chain owner can override
+this setting to allow anyone to deploy contracts on the chain.
+
+---
+
+## Views
+
+### `findContract(hn Hname)`
+
+Returns the record for a given smart contract with Hname `hn` (if it exists).
+
+#### Parameters
+
+`hn`: The smart contract’s Hname
+
+#### Returns
+
+- `cf` (`bool`): Whether or not the contract exists.
+- `dt` ([`ContractRecord`](#contractrecord)): The requested contract record (if it exists).
+
+### `getContractRecords()`
+
+Returns the list of all smart contracts deployed on the chain and related records.
+
+#### Returns
+
+A map of `Hname` => [`ContractRecord`](#contractrecord)
+
+---
+
+## Schemas
+
+### `ContractRecord`
+
+A `ContractRecord` is encoded as the concatenation of:
+
+- Program hash (`[32]byte`).
+- Contract description (`string`).
+- Contract name (`string`).
diff --git a/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/xfer.md b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/xfer.md
new file mode 100644
index 00000000000..f515cc9c0ba
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/core-contracts/xfer.md
@@ -0,0 +1,71 @@
+---
+description: 'The `transferAccountToChain` contract needs special consideration.'
+image: /img/logo/WASP_logo_dark.png
+keywords:
+ - core contracts
+ - accounts
+ - deposit
+ - withdraw
+ - assets
+ - balance
+ - reference
+---
+
+# `accounts.transferAccountToChain`
+
+The `transferAccountToChain` function of the `accounts` contract is one that needs
+careful consideration before use. Make sure you understand precisely how to use it to
+prevent
+
+---
+
+## Entry Point
+
+### `transferAccountToChain(g GasReserve)`
+
+Transfers the specified allowance from the sender SC's L2 account on
+the target chain to the sender SC's L2 account on the origin chain.
+
+Caller must be a contract, and we will transfer the allowance from its L2 account
+on the target chain to its L2 account on the origin chain. This requires that
+this function takes the allowance into custody and in turn sends the assets as
+allowance to the origin chain, where that chain's accounts.TransferAllowanceTo()
+function then transfers it into the caller's L2 account on that chain.
+
+#### Parameters
+
+- `g` (`uint64`): Optional gas amount to reserve in the allowance for
+ the internal call to transferAllowanceTo(). Default 100 (MinGasFee).
+ But better to provide it so that it matches the fee structure.
+
+### IMPORTANT CONSIDERATIONS:
+
+1. The caller contract needs to provide sufficient base tokens in its
+ allowance, to cover the gas fee GAS1 for this request.
+ Note that this amount depends on the fee structure of the target chain,
+ which can be different from the fee structure of the caller's own chain.
+
+2. The caller contract also needs to provide sufficient base tokens in
+ its allowance, to cover the gas fee GAS2 for the resulting request to
+ accounts.TransferAllowanceTo() on the origin chain. The caller needs to
+ also specify this GAS2 amount through the GasReserve parameter.
+
+3. The caller contract also needs to provide a storage deposit SD with
+ this request, holding enough base tokens _independent_ of the GAS1 and
+ GAS2 amounts.
+ Since this storage deposit is dictated by L1 we can use this amount as
+ storage deposit for the resulting accounts.TransferAllowanceTo() request,
+ where it will then be returned to the caller as part of the transfer.
+
+4. This means that the caller contract needs to provide at least
+ GAS1 + GAS2 + SD base tokens as assets to this request, and provide an
+ allowance to the request that is exactly GAS2 + SD + transfer amount.
+ Failure to meet these conditions may result in a failed request and
+ worst case the assets sent to accounts.TransferAllowanceTo() could be
+ irretrievably locked up in an account on the origin chain that belongs
+ to the accounts core contract of the target chain.
+
+5. The caller contract needs to set the gas budget for this request to
+ GAS1 to guard against unanticipated changes in the fee structure that
+ raise the gas price, otherwise the request could accidentally cannibalize
+ GAS2 or even SD, with potential failure and locked up assets as a result.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/types.mdx b/docs/build/wasp-wasm/0.7.0/docs/reference/data-types/types.mdx
similarity index 89%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/types.mdx
rename to docs/build/wasp-wasm/0.7.0/docs/reference/data-types/types.mdx
index 5800301bf6e..df95213b20b 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/types.mdx
+++ b/docs/build/wasp-wasm/0.7.0/docs/reference/data-types/types.mdx
@@ -8,7 +8,6 @@ keywords:
- reference
description: The WasmLib provides direct support for the basic value data types that are found in all programming languages, and WasmLib versions of ISC-specific value data types.
-
image: /img/logo/WASP_logo_dark.png
---
@@ -24,7 +23,7 @@ as human-readable text string.
These are mostly simple built-in scalar data types as provided by most programming
languages. Each integer data type has a clearly defined storage size. The
-[Schema Tool](usage.mdx) will attempt to use the closest matching built-in data type when
+[Schema Tool](../../how-tos/schema-tool/usage.mdx)) will attempt to use the closest matching built-in data type when
generating code for a specific language.
- `BigInt` - An arbitrary-length unsigned integer.
@@ -58,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](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
@@ -100,11 +99,8 @@ The consistent naming makes it easy to remember the type names. Bool, Bytes, Str
the integer types are the odd ones out. They are implemented in WasmLib by the closest
equivalents in the chosen WasmLib implementation programming language.
-The [Schema Tool](usage.mdx) will automatically generate the proper (im)mutable proxies
+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](state.mdx) map through immutable proxies. The same goes for the
-[Params](params.mdx) map that was passed into a Func or View, and for the
-[Results](results.mdx) map that was returned from a call to a Func or View.
-
-In the next section we will show how use these predefined types to create user-defined
-[Structured Data Types](structs.mdx).
+[State](../../how-tos/schema-tool/state.mdx) map through immutable proxies. The same goes for the
+[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/0.7.0/docs/testnet.md b/docs/build/wasp-wasm/0.7.0/docs/testnet.md
similarity index 100%
rename from docs/build/wasp/0.7.0/docs/testnet.md
rename to docs/build/wasp-wasm/0.7.0/docs/testnet.md
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/example_projects/fair_roulette.md b/docs/build/wasp-wasm/0.7.0/docs/tutorials/fair_roulette.md
similarity index 95%
rename from docs/build/wasp/0.7.0/docs/guide/wasm_vm/example_projects/fair_roulette.md
rename to docs/build/wasp-wasm/0.7.0/docs/tutorials/fair_roulette.md
index e863018d6b9..6e736d03afb 100644
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/example_projects/fair_roulette.md
+++ b/docs/build/wasp-wasm/0.7.0/docs/tutorials/fair_roulette.md
@@ -52,13 +52,13 @@ There are two ways to interact with smart contracts.
#### On Ledger Requests
-See: [On-ledger Requests](/learn/smart-contracts/core_concepts/invocation#on-ledger)
+See: [On-ledger Requests](/learn/smart-contracts/invocation#on-ledger)
On-ledger requests are sent to GoShimmer nodes. Wasp periodically requests new On-ledger requests from GoShimmer nodes, and handles them accordingly. These messages are validated through the network and take some time to be processed.
#### Off Ledger Requests
-See: [Off-ledger Requests](/learn/smart-contracts/core_concepts/invocation#off-ledger)
+See: [Off-ledger Requests](/learn/smart-contracts/invocation#off-ledger)
Off-ledger requests are directly sent to Wasp nodes and do not require validation through GoShimmer nodes. They are therefore faster. However, they require an initial deposit of funds to a chain account as this account will initiate required On-ledger requests on behalf of the desired contract or player.
@@ -95,7 +95,7 @@ To interact with a smart contract, you will need:
The PoC consists of two projects residing in `contracts/wasm/fairroulette`.
-One is the smart contract itself. Its boilerplate was generated using the new [Schema tool](/smart-contracts/guide/wasm_vm/intro) which is shipped with this beta release.
+One is the smart contract itself. Its boilerplate was generated using the new [Schema tool](/wasp-wasm/introduction/) which is shipped with this beta release.
The contract logic is written in Rust, but the same implementation can be achieved
interchangeably with Golang and Assemblyscript which is demonstrated in the root folder
and `./src`.
@@ -105,7 +105,7 @@ This frontend sends On-ledger requests to place bets towards the fair roulette s
### The Smart Contract
-See: [Anatomy of a Smart Contract](/learn/smart-contracts/core_concepts/smart-contract-anatomy)
+See: [Anatomy of a Smart Contract](/learn/smart-contracts/smart-contract-anatomy)
As the smart contract is the only actor that is allowed to modify state in the context of the game, it needs to handle a few tasks such as:
@@ -232,13 +232,13 @@ This transaction also requires an address to send the request to, and also a var
For Wasp, the address to send funds to is the chainId.
:::
-See: [Invoking](/smart-contracts/guide/solo/invoking-sc)
+See: [Invoking](/wasp-wasm/how-tos/solo/invoking-sc)
##### CallView
The [callView](https://github.com/iotaledger/wasp/blob/7b3ddc54891ccf021c7aaa32db35d88361fade16/contracts/wasm/fairroulette/frontend/src/lib/fairroulette_client/fair_roulette_service.ts#L165) function is responsible for calling smart contract view functions.
-See: [Calling a view](/smart-contracts/guide/solo/view-sc)
+See: [Calling a view](/wasp-wasm/how-tos/solo/view-sc)
To give access to the smart contracts state, you can use view functions to return selected parts of the state.
@@ -284,7 +284,7 @@ cp config.dev.sample.js config.dev.js
Make sure to update the config values according to your setup.
-The `chainId` is the chainId which gets defined after [deploying a chain](/wasp/setting-up-a-chain#deploy-the-isc-chain). You can get your chain id from your dashboard, or list all chains by running:
+The `chainId` is the chainId which gets defined after [deploying a chain](/wasp-cli/how-tos/setting-up-a-chain/#deploy-the-isc-chain). You can get your chain id from your dashboard, or list all chains by running:
```shell
wasp-cli chain list
@@ -309,7 +309,7 @@ If you want to expose the dev server to the public, it might be required to bind
## Deployment
-You should follow the [Deployment](/wasp/setting-up-a-chain#deploy-the-isc-chain) documentation until you reach the `deploy-contract` command.
+You should follow the [Deployment](/wasp-cli/how-tos/setting-up-a-chain/#deploy-the-isc-chain) documentation until you reach the `deploy-contract` command.
The deployment of a contract requires funds to be deposited to the **chain**.
You can do this by executing the following command from the directory where your Wasp node was configured:
diff --git a/docs/build/wasp-wasm/0.7.0/sidebars.js b/docs/build/wasp-wasm/0.7.0/sidebars.js
new file mode 100644
index 00000000000..77e9b238512
--- /dev/null
+++ b/docs/build/wasp-wasm/0.7.0/sidebars.js
@@ -0,0 +1,294 @@
+/**
+ * Creating a sidebar enables you to:
+ - create an ordered group of docs
+ - render a sidebar for each doc of that group
+ - provide next/previous navigation
+
+ The sidebars can be generated from the filesystem, or explicitly defined here.
+
+ Create as many sidebars as you want.
+ */
+
+module.exports = {
+ // By default, Docusaurus generates a sidebar from the docs folder structure
+ //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
+
+ // But you can create a sidebar manually
+ wasmSidebar: [
+ {
+ type: 'doc',
+ label: 'Wasm VM for ISC',
+ id: 'introduction',
+ },
+ {
+ type: 'category',
+ label: 'Explanations',
+ items: [
+ {
+ type: 'doc',
+ label: 'How Accounts Work',
+ id: 'explanations/how-accounts-work',
+ },
+ {
+ type: 'doc',
+ label: 'Call Context',
+ id: 'explanations/context',
+ },
+ {
+ type: 'doc',
+ label: 'Data Access Proxies',
+ id: 'explanations/proxies',
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'How To',
+ items: [
+ {
+ type: 'category',
+ label: 'Use the Schema Tool',
+ items: [
+ {
+ type: 'doc',
+ label: 'Introduction',
+ id: 'how-tos/schema-tool/introduction',
+ },
+ {
+ type: 'doc',
+ label: 'Create a Schema',
+ id: 'how-tos/schema-tool/usage',
+ },
+ {
+ type: 'doc',
+ label: 'Define the State',
+ id: 'how-tos/schema-tool/state',
+ },
+ {
+ type: 'doc',
+ label: 'Use Structured Data Types',
+ id: 'how-tos/schema-tool/structs',
+ },
+ {
+ type: 'doc',
+ label: 'Generate Type Definitions',
+ id: 'how-tos/schema-tool/typedefs',
+ },
+ {
+ type: 'doc',
+ label: 'Trigger Events',
+ id: 'how-tos/schema-tool/events',
+ },
+ {
+ type: 'doc',
+ label: 'Define Functions',
+ id: 'how-tos/schema-tool/funcs',
+ },
+ {
+ type: 'doc',
+ label: 'Limit Access',
+ id: 'how-tos/schema-tool/access',
+ },
+ {
+ type: 'doc',
+ label: 'Define Function Parameters',
+ id: 'how-tos/schema-tool/params',
+ },
+ {
+ type: 'doc',
+ label: 'Define Function Results',
+ id: 'how-tos/schema-tool/results',
+ },
+ {
+ type: 'doc',
+ label: 'Use Thunk Functions',
+ id: 'how-tos/schema-tool/thunks',
+ },
+ {
+ type: 'doc',
+ label: 'Use View-Only Functions',
+ id: 'how-tos/schema-tool/views',
+ },
+ {
+ type: 'doc',
+ label: 'Initialize a Smart Contract',
+ id: 'how-tos/schema-tool/init',
+ },
+ {
+ type: 'doc',
+ label: 'Transfer Tokens',
+ id: 'how-tos/schema-tool/transfers',
+ },
+ {
+ type: 'doc',
+ label: 'Add Function Descriptors',
+ id: 'how-tos/schema-tool/funcdesc',
+ },
+ {
+ type: 'doc',
+ label: 'Call Functions',
+ id: 'how-tos/schema-tool/call',
+ },
+ {
+ type: 'doc',
+ label: 'Post Asynchronous Requests',
+ id: 'how-tos/schema-tool/post',
+ },
+ ],
+ },
+ {
+ 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',
+ label: 'Test Smart Contracts with Solo',
+ items: [
+ {
+ type: 'doc',
+ label: 'What is Solo?',
+ id: 'how-tos/solo/what-is-solo',
+ },
+ {
+ type: 'doc',
+ label: 'First Example',
+ id: 'how-tos/solo/first-example',
+ },
+ {
+ type: 'doc',
+ label: 'The L1 Ledger',
+ id: 'how-tos/solo/the-l1-ledger',
+ },
+ {
+ type: 'doc',
+ label: 'Deploy a Smart Contract',
+ id: 'how-tos/solo/deploying-sc',
+ },
+ {
+ type: 'doc',
+ label: 'Invoke a Smart Contract',
+ id: 'how-tos/solo/invoking-sc',
+ },
+ {
+ type: 'doc',
+ label: 'Call a View',
+ id: 'how-tos/solo/view-sc',
+ },
+ {
+ type: 'doc',
+ label: 'Error Handling',
+ id: 'how-tos/solo/error-handling',
+ },
+ {
+ type: 'doc',
+ label: 'Accounts',
+ id: 'how-tos/solo/the-l2-ledger',
+ },
+ {
+ type: 'doc',
+ label: 'Test Smart Contracts',
+ id: 'how-tos/solo/test',
+ },
+ {
+ type: 'doc',
+ label: 'Example Tests',
+ id: 'how-tos/solo/examples',
+ },
+ {
+ type: 'doc',
+ label: 'Colored Tokens and Time Locks',
+ id: 'how-tos/solo/timelock',
+ },
+ ],
+ },
+ ],
+ },
+
+ {
+ type: 'category',
+ label: 'Reference',
+ items: [
+ {
+ type: 'category',
+ label: 'Core Contracts',
+ items: [
+ {
+ type: 'doc',
+ label: 'Overview',
+ id: 'reference/core-contracts/overview',
+ },
+ {
+ type: 'doc',
+ label: 'root',
+ id: 'reference/core-contracts/root',
+ },
+ {
+ type: 'doc',
+ label: 'accounts',
+ id: 'reference/core-contracts/accounts',
+ },
+ {
+ type: 'doc',
+ label: 'blob',
+ id: 'reference/core-contracts/blob',
+ },
+ {
+ type: 'doc',
+ label: 'blocklog',
+ id: 'reference/core-contracts/blocklog',
+ },
+ {
+ type: 'doc',
+ label: 'governance',
+ id: 'reference/core-contracts/governance',
+ },
+ {
+ type: 'doc',
+ label: 'errors',
+ id: 'reference/core-contracts/errors',
+ },
+ {
+ type: 'doc',
+ label: 'evm',
+ id: 'reference/core-contracts/evm',
+ },
+ ],
+ },
+
+ {
+ type: 'category',
+ label: 'Data Types',
+ items: [
+ {
+ type: 'doc',
+ label: 'WasmLib Data Types',
+ id: 'reference/data-types/types',
+ },
+ ],
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Tutorials',
+ items: [
+ {
+ type: 'doc',
+ label: 'Fair Roulette',
+ id: 'tutorials/fair_roulette',
+ },
+ ],
+ },
+ ],
+};
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp.png b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp.png
new file mode 100644
index 00000000000..a1348ded187
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_concepts_architecture.png b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_concepts_architecture.png
new file mode 100644
index 00000000000..8b52f671b08
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_concepts_architecture.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_concepts_smart_contracts.png b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_concepts_smart_contracts.png
new file mode 100644
index 00000000000..a44e2589fbc
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_concepts_smart_contracts.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_contracts_overview.png b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_contracts_overview.png
new file mode 100644
index 00000000000..6eae1806f46
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_core_contracts_overview.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_using_docker.png b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_using_docker.png
new file mode 100644
index 00000000000..34ed36b8455
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/Banner/banner_wasp_using_docker.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/chain0.png b/docs/build/wasp-wasm/0.7.0/static/img/chain0.png
new file mode 100644
index 00000000000..e9753d59209
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/chain0.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/chain1.png b/docs/build/wasp-wasm/0.7.0/static/img/chain1.png
new file mode 100644
index 00000000000..5b66b22b3d4
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/chain1.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-1.png b/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-1.png
new file mode 100644
index 00000000000..db478b344fe
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-1.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-2.png b/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-2.png
new file mode 100644
index 00000000000..a8f23757e2b
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-2.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-3.png b/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-3.png
new file mode 100644
index 00000000000..473dfb612fd
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/contributing/golintci-goland-3.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/compile.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/compile.png
new file mode 100644
index 00000000000..6c4bb12e1c8
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/compile.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/deploy-metamask.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/deploy-metamask.png
new file mode 100644
index 00000000000..8395cd68268
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/deploy-metamask.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/deploy.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/deploy.png
new file mode 100644
index 00000000000..b6af6b09513
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/deploy.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/erc20-balance.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/erc20-balance.png
new file mode 100644
index 00000000000..ec88a5cff26
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/erc20-balance.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/explorer-contract-address.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/explorer-contract-address.png
new file mode 100644
index 00000000000..399126ef8fe
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/examples/explorer-contract-address.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/ozw-721.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/ozw-721.png
new file mode 100644
index 00000000000..fc875e06c63
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/ozw-721.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-721-deploy.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-721-deploy.png
new file mode 100644
index 00000000000..fd877ac1659
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-721-deploy.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-721.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-721.png
new file mode 100644
index 00000000000..56a1a453441
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-721.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-deployed.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-deployed.png
new file mode 100644
index 00000000000..1c0fa30d6f8
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-deployed.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-metamask-detail.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-metamask-detail.png
new file mode 100644
index 00000000000..c01a6fa2bf8
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-metamask-detail.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-vm-injected.png b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-vm-injected.png
new file mode 100644
index 00000000000..6d2e4c8e087
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/evm/remix-vm-injected.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/logo/WASP_logo_dark.png b/docs/build/wasp-wasm/0.7.0/static/img/logo/WASP_logo_dark.png
new file mode 100644
index 00000000000..cddeb2cdc1e
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/logo/WASP_logo_dark.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/logo/WASP_logo_light.png b/docs/build/wasp-wasm/0.7.0/static/img/logo/WASP_logo_light.png
new file mode 100644
index 00000000000..eeb6ae39d22
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/logo/WASP_logo_light.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/metamask.png b/docs/build/wasp-wasm/0.7.0/static/img/metamask.png
new file mode 100644
index 00000000000..e6d686d68cb
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/metamask.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/metamask_network.png b/docs/build/wasp-wasm/0.7.0/static/img/metamask_network.png
new file mode 100644
index 00000000000..7224783f504
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/metamask_network.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/metamask_testnet.png b/docs/build/wasp-wasm/0.7.0/static/img/metamask_testnet.png
new file mode 100644
index 00000000000..c9eddeb8002
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/metamask_testnet.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/multichain.png b/docs/build/wasp-wasm/0.7.0/static/img/multichain.png
new file mode 100644
index 00000000000..2c761f45866
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/multichain.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/sandbox.png b/docs/build/wasp-wasm/0.7.0/static/img/sandbox.png
new file mode 100644
index 00000000000..2071da12eec
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/sandbox.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/tutorial/SC-structure.png b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/SC-structure.png
new file mode 100644
index 00000000000..1ae84b7ac05
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/SC-structure.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/tutorial/accounts.png b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/accounts.png
new file mode 100644
index 00000000000..827935368b1
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/accounts.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/tutorial/call_view.png b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/call_view.png
new file mode 100644
index 00000000000..6ec91b99354
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/call_view.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/tutorial/send_request.png b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/send_request.png
new file mode 100644
index 00000000000..19f6343cf79
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/tutorial/send_request.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/IscHost.png b/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/IscHost.png
new file mode 100644
index 00000000000..0e7f750f225
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/IscHost.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/Proxies.png b/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/Proxies.png
new file mode 100644
index 00000000000..5af874582f3
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/Proxies.png differ
diff --git a/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/WasmVM.png b/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/WasmVM.png
new file mode 100644
index 00000000000..2cf870f93a5
Binary files /dev/null and b/docs/build/wasp-wasm/0.7.0/static/img/wasm_vm/WasmVM.png differ
diff --git a/docs/build/wasp/0.7.0/docs/contribute.md b/docs/build/wasp/0.7.0/docs/contribute.md
deleted file mode 100644
index 6c9a084cfc6..00000000000
--- a/docs/build/wasp/0.7.0/docs/contribute.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-description: How to contribute to IOTA Smart Contracts. How to create better pull requests by running tests and the linter locally.
-image: /img/logo/WASP_logo_dark.png
-keywords:
- - smart contracts
- - Contribute
- - pull request
- - linting
- - Go-lang
- - golangci-lint
- - how to
----
-
-# Contributing
-
-If you want to contribute to this repository, consider posting a [bug report](https://github.com/iotaledger/wasp/issues/new-issue), feature request, or a [pull request](https://github.com/iotaledger/wasp/pulls/).
-
-You can talk to us directly on our [Discord server](https://discord.iota.org/), in the `#smartcontracts-dev` channel.
-
-## Creating a Pull Request
-
-Please base your work on the `develop` branch.
-
-Before creating a pull request ensure that all tests pass locally, and that the linter reports no violations.
-
-## Running Tests
-
-To run tests locally, execute one of the following commands:
-
-```shell
-go test -short -tags rocksdb ./...
-```
-
-or, as an alternative:
-
-```shell
-make test-short
-```
-
-The commands above execute a subset of all available tests. If you introduced major changes, consider running the whole test suite instead, with `make test` or `make test-full` (these can take several minutes, so go and grab a coffee!).
-
-## Running the Linter
-
-### Setup
-
-#### Step 1: Install golintci
-
-See the [provider instructions](https://golangci-lint.run/usage/install/#local-installation) on how to install golintci.
-
-#### Step 2: Set Up Your Environment
-
-See the [provider instructions](https://golangci-lint.run/usage/integrations/#editor-integration) on how to integrate golintci into your source code editor. You can also find our [recommended settings](#appendix-recommended-settings) for VS Code and GoLand at the bottom of this article.
-
-### Usage
-
-To run the linter locally, execute:
-
-```shell
-golangci-lint run
-```
-
-or
-
-```shell
-make lint
-```
-
-The linter will also automatically run every time you run:
-
-```shell
-make
-```
-
-### False Positives
-
-You can [disable](https://golangci-lint.run/usage/false-positives/) false positives by placing a special comment directly above the "violating" element:
-
-```go
-//nolint
-func foobar() *string {
- // ...
-}
-```
-
-To be sure that linter will not ignore actual issues in the future, try to suppress only relevant warnings over an element. Also explain the reason why the `nolint` is needed. E.g.:
-
-```go
-//nolint:unused // This is actually used by the xyz tool
-func foo() *string {
- // ...
-}
-```
-
-## Appendix: Recommended Settings
-
-### Visual Studio Code
-
-Adjust your VS Code settings as follows:
-
-```json
-// required:
-"go.lintTool": "golangci-lint",
-// recommended:
-"go.lintOnSave": "package"
-"go.lintFlags": ["--fix"],
-"editor.formatOnSave": true,
-```
-
-### GoLand
-
-1. Install the [golintci](https://plugins.jetbrains.com/plugin/12496-go-linter) plugin.
-
-
-
-2. Configure path for golangci.
-
-
-
-3. Add a golangci file watcher with a custom command. We recommend you to use it with the `--fix` parameter.
-
-
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/compatibility.md b/docs/build/wasp/0.7.0/docs/guide/evm/compatibility.md
deleted file mode 100644
index 11629b2c4df..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/evm/compatibility.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-description: Compatibility between the ISC EVM layer and existing Ethereum smart contracts and tooling.
-image: /img/logo/WASP_logo_dark.png
-keywords:
- - smart contracts
- - EVM
- - Ethereum
- - Solidity
- - limitations
- - compatibility
- - fees
- - reference
----
-
-# EVM Compatibility in IOTA Smart Contracts
-
-The [`evm`](/learn/smart-contracts/core_concepts/core_contracts/evm) [core contract](/learn/smart-contracts/core_concepts/core_contracts/overview)
-provides EVM support in IOTA Smart Contracts. It stores the EVM state (account balances, state, code,
-etc.) and provides a way to execute EVM code to manipulate the state.
-
-The EVM core contract runs on top of the ISC layer, which provides the rest of the machinery needed to run smart
-contracts, such as signed requests, blocks, state, proofs, etc.
-
-However, the ISC EVM layer is also designed to be as compatible as possible with existing Ethereum tools
-like [MetaMask](https://metamask.io/), which assume that the EVM code runs on an Ethereum blockchain composed of
-Ethereum blocks containing Ethereum transactions. Since ISC works in a fundamentally different way,
-providing 100% compatibility is not possible. We do our best to emulate the behavior of an Ethereum node, so the
-Ethereum tools think they are interfacing with an actual Ethereum node, but some differences in behavior are inevitable.
-
-:::warning
-There is a difference in the decimal precision of ether (18 decimal places) to MIOTA/SMR(6 decimal places). Because of this, when sending native tokens in the EVM, which are expressed in wei (ether = 1018wei), the last 12 decimal places will be ignored.
-
-example: 1,999,999,999,999,999,999 wei = 1.999,999 SMR/MIOTA
-:::
-
-Here are some of the most important properties and limitations of EVM support in IOTA Smart Contracts:
-
-- The Wasp node provides a JSON-RPC service, the standard protocol used by Ethereum tools. Upon receiving a signed
- Ethereum transaction via JSON-RPC, the transaction is wrapped into an ISC off-ledger request. The sender of the
- request
- is the Ethereum address that signed the original transaction (e.g., the Metamask account).
-
-- While ISC contracts are identified by an [hname](/learn/smart-contracts/core_concepts/smart-contract-anatomy), EVM contracts are
- identified by their Ethereum address.
-
-- EVM contracts are not listed in the chain's [contract registry](/learn/smart-contracts/core_concepts/core_contracts/root).
-
-- EVM contracts cannot be called via regular ISC requests; they can only be
- called through the JSON-RPC service.
- As a consequence, EVM contracts cannot receive on-ledger requests.
-
-- In contrast with an Ethereum blockchain, which stores the state in a Merkle tree, the EVM state is stored in raw form.
- It would be inefficient to do that since it would be duplicating work done by the ISC layer.
-
-- Any Ethereum transactions present in an ISC block are executed by
- the [`evm`](/learn/smart-contracts/core_concepts/core_contracts/evm) [core contract](/learn/smart-contracts/core_concepts/core_contracts/overview),
- updating the EVM state accordingly. An emulated Ethereum block is also created and stored to provide compatibility
- with EVM tools. As the emulated block is not part of a real Ethereum blockchain, some attributes of the blocks will
- contain dummy values (e.g. `stateRoot`, `nonce`, etc.).
-
-- Each stored block contains the executed Ethereum transactions and corresponding Ethereum receipts. If storage is
- limited, you can configure EVM so that only the latest N blocks are stored.
-
-- There is no guaranteed _block time_. A new EVM "block" will be created only when an ISC block is created, and ISC does
- not enforce an average block time.
-
-- Any Ethereum address is accepted as a valid `AgentID`, and thus can own L2 tokens on an IOTA Smart Contract chain,
- just like IOTA addresses.
-
-- The Ethereum balance of an account is tied to its L2 ISC balance in the token used to pay for gas. For example,
- by default `eth_getBalance` will return the L2 base token balance of the given Ethereum account.
-
-- To manipulate the owned ISC tokens and access ISC functionality in general, there is
- a [special Ethereum contract](magic.md) that provides bindings to the ISC sandbox (e.g. call `isc.send(...)` to send
- tokens).
-
-- The used EVM gas is converted to ISC gas before being charged to the sender. The conversion ratio is configurable. The
- token used to pay for gas is the same token configured in the ISC chain (IOTA by default). The gas fee is debited from
- the sender's L2 account and must be deposited beforehand.
diff --git a/docs/build/wasp/0.7.0/docs/guide/evm/magic.md b/docs/build/wasp/0.7.0/docs/guide/evm/magic.md
deleted file mode 100644
index 567149d0e3e..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/evm/magic.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-description: The ISC Magic Contract allows EVM contracts to access ISC functionality.
-image: /img/logo/WASP_logo_dark.png
-keywords:
- - configure
- - using
- - EVM
- - magic
- - Ethereum
- - Solidity
- - metamask
- - JSON
- - RPC
----
-
-# The ISC Magic Contract
-
-[EVM and ISC are inherently very different platforms](compatibility.md).
-Some EVM-specific actions (e.g., manipulating Ethereum tokens) are disabled, and EVM contracts can access ISC-specific
-functionality through the _ISC Magic Contract_.
-
-The Magic contract is an EVM contract deployed by default on every ISC chain, in the EVM genesis block, at
-address `0x1074000000000000000000000000000000000000`.
-The implementation of the Magic contract is baked-in in
-the [`evm`](/learn/smart-contracts/core_concepts/core_contracts/evm) [core contract](/learn/smart-contracts/core_concepts/core_contracts/overview));
-i.e. it is not a pure-Solidity contract.
-
-The Magic contract has several methods, which are categorized into specialized
-interfaces: `ISCSandbox`, `ISCAccounts`, `ISCUtil` and so on.
-You can access these interfaces from any Solidity contract by importing
-the [ISC library](https://www.npmjs.com/package/@iota/iscmagic):
-
-```sh
-yarn add @iota/iscmagic
-```
-
-You can import it into your contracts like this:
-
-```solidity
-import "@iota/iscmagic/ISC.sol";
-```
-
-The Magic contract also provides proxy ERC20 contracts to manipulate ISC base
-tokens and native tokens on L2.
-
-## Examples
-
-### Calling getEntropy()
-
-```solidity
-pragma solidity >=0.8.5;
-
-import "@iota/iscmagic/ISC.sol";
-
-contract MyEVMContract {
- event EntropyEvent(bytes32 entropy);
-
- // this will emit a "random" value taken from the ISC entropy value
- function emitEntropy() public {
- bytes32 e = ISC.sandbox.getEntropy();
- emit EntropyEvent(e);
- }
-}
-```
-
-In the example above, `ISC.sandbox.getEntropy()` calls the
-[`getEntropy`](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L20)
-method of the `ISCSandbox` interface, which, in turn,
-calls [ISC Sandbox's](/learn/smart-contracts/core_concepts/sandbox) `GetEntropy`.
-
-### Calling a native contract
-
-You can call native contracts using [`ISC.sandbox.call`](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L56):
-
-```solidity
-pragma solidity >=0.8.5;
-
-import "@iota/iscmagic/ISC.sol";
-
-contract MyEVMContract {
- event EntropyEvent(bytes32 entropy);
-
- function callInccounter() public {
- ISCDict memory params = ISCDict(new ISCDictItem[](1));
- bytes memory int64Encoded42 = hex"2A00000000000000";
- params.items[0] = ISCDictItem("counter", int64Encoded42);
- ISCAssets memory allowance;
- ISC.sandbox.call(ISC.util.hn("inccounter"), ISC.util.hn("incCounter"), params, allowance);
- }
-}
-```
-
-`ISC.util.hn` is used to get the `hname` of the incounter countract and the
-`incCounter` entry point. You can also call view entry points using
-[ISC.sandbox.callView](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol#L59).
-
-## API Reference
-
-- [Common type definitions](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCTypes.sol)
-- [ISC library](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISC.sol)
-- [ISCSandbox](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCSandbox.sol)
- interface, available at `ISC.sandbox`
-- [ISCAccounts](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCAccounts.sol)
- interface, available at `ISC.accounts`
-- [ISCUtil](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ISCUtil.sol)
- interface, available at `ISC.util`
-- [ERC20BaseTokens](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC20BaseTokens.sol)
- contract, available at `ISC.baseTokens`
- (address `0x1074010000000000000000000000000000000000`)
-- [ERC20NativeTokens](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC20NativeTokens.sol)
- contract, available at `ISC.nativeTokens(foundrySN)` after being registered
- by the foundry owner by calling
- [`registerERC20NativeToken`](/learn/smart-contracts/core_concepts/core_contracts/evm#registerERC20NativeToken)
- (address `0x107402xxxxxxxx00000000000000000000000000` where `xxxxxxxx` is the
- little-endian encoding of the foundry serial number)
-- [ERC20ExternalNativeTokens](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC20ExternalNativeTokens.sol)
- contract, available at a dynamically assigned address after being registered
- by the foundry owner by calling
- [`registerERC20NativeTokenOnRemoteChain`](/learn/smart-contracts/core_concepts/core_contracts/evm#registerERC20NativeTokenOnRemoteChain)
- on the chain that controls the foundry.
-- [ERC721NFTs](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC721NFTs.sol)
- contract, available at `ISC.nfts`
- (address `0x1074030000000000000000000000000000000000`)
-- [ERC721NFTCollection](https://github.com/iotaledger/wasp/blob/develop/packages/vm/core/evm/iscmagic/ERC721NFTCollection.sol)
- contract, available at `ISC.erc721NFTCollection(collectionID)`, after being
- registered by calling [`registerERC721NFTCollection`](/learn/smart-contracts/core_concepts/core_contracts/evm#registerERC721NFTCollection).
-
-There are some usage examples in
-the [ISCTest.sol](https://github.com/iotaledger/wasp/blob/develop/packages/evm/evmtest/ISCTest.sol) contract (used
-internally in unit tests).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/access.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/access.mdx
deleted file mode 100644
index 6b32b44a094..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/access.mdx
+++ /dev/null
@@ -1,42 +0,0 @@
----
-keywords:
- - functions
- - access
- - self
- - chain
- - creator
- - agentID
-
-description: The optional access subsection indicates the agent who is allowed to access the function. When this definition is omitted, anyone is allowed to call the function.
-
-image: /img/logo/WASP_logo_dark.png
----
-
-# Limiting Access
-
-The optional `access` subsection is made of a single definition, it indicates the agent
-who is allowed to access the function. When this definition is omitted, anyone is allowed
-to call the function. When the definition is present it should be an access identifier,
-optionally followed by an explanatory comment. Access identifiers can be one of the
-following:
-
-- `self`: Only the smart contract itself can call this function.
-- `chain`: Only the chain owner can call this function.
-- anything else: The name of an AgentID or AgentID[] variable in state storage. Only the
- agent(s) defined there can call this function. When this option is used you should also
- provide functionality that can initialize and/or modify this variable. As long as this
- state variable has not been set, nobody will be allowed to call this function.
-
-The [Schema Tool](usage.mdx) will automatically generate code to properly check the access
-rights of the agent that called the function before the actual function is called.
-
-You can see usage examples of the access identifier in the schema definition file, where
-the state variable `owner` is used as an access identifier. The `init` function
-initializes this state variable, and the `setOwner` function can only be used by the
-current owner to set a new owner. Finally, the `member` function can also only be called
-by the current owner.
-
-Note that there can be different access identifiers for different functions as needed. You
-can set up as many access identifiers as you like.
-
-In the next section we will look at the [`params`](params.mdx) subsection.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/concepts.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/concepts.mdx
deleted file mode 100644
index 4e180009078..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/concepts.mdx
+++ /dev/null
@@ -1,105 +0,0 @@
----
-keywords:
- - concepts
- - smart contracts
- - allowance
-
-description: First let's talk about some important concepts about smart contracts in general and then about ISC smart contract concepts in particular.
-
-image: /img/logo/WASP_logo_dark.png
----
-
-# Smart Contract Concepts
-
-First let's talk about some important general concepts of smart contracts, and then about
-ISC-specific smart contract concepts.
-
-## General Concepts
-
-Smart contracts consist of a number of functions that operate on their state storage.
-These functions are guaranteed to run deterministically. That means that given certain
-input data and input storage state they will always produce the same output data and
-output storage state. Determinism is key because it is the only way to be able to
-validate their execution results independently.
-
-The consequence of this is that it is impossible for a smart contract to go out and fetch
-data from external sources, because these sources cannot be guaranteed to be the same at
-every invocation. Smart contract function calls are therefore always following the data
-push model. They need to receive a complete, atomic set of input data. This is important
-to remember, because in most other programming applications it is very common to pull
-external data into running code whenever required. This changes the mental model necessary
-for building smart contract solutions considerably.
-
-Smart contract functions have no access to a file system, nor can they use timing or
-randomness sources. Any time or randomness data must be provided as part of the input
-data. Changes to global static data in the smart contract code itself will not persist
-between separate smart contract function calls. Multi-threading is also highly
-non-deterministic and its usage is therefore not allowed.
-
-To make sure that timing differences between processors do not influence the consensus
-outcome of long-running processes, and to prevent endless loops, smart contracts use a
-system where the maximum running time of a function is bounded by an amount of **gas**
-that is provided at the moment of invocation. Each Wasm instruction and each ISC API call
-burns a certain amount of gas, and therefore any function that runs out of gas will do so
-at the exact same point, no matter who runs it. This is the only way to be able to have
-Turing-complete computing that is bounded in a deterministic way. Gas is not just used to
-limit the amount of (finite) processing resources that can be used, but it can also be
-used to assign a monetary cost to the actual amount of processing resources used when
-running a smart contract function by associating a fee per unit of gas used.
-
-## ISC-specific Concepts
-
-A unique feature of ISC is its ability to run multiple blockchains in parallel securely.
-Requests can arrive asynchronously, but each separate blockchain is guaranteed to handle
-its requests synchronously, ordered by consensus between the chain's processing nodes.
-Each chain runs its own set of smart contracts. Some are built-in (core) contracts,
-others are user-defined, dynamically loaded contracts.
-
-Within a blockchain contracts can call each other's functionality either synchronously or
-asynchronously. Synchronous calls are akin to a subroutine call. Asynchronous calls are
-wrapped in a request transaction and posted on the Tangle, to be executed sometime after
-the current set of requests has been processed.
-
-This same asynchronous request mechanism can be used to post calls to smart contracts in
-other blockchains. Delivery of such request transactions is guaranteed, but processing of
-these requests is only guaranteed as long as the target blockchain is active.
-
-Although smart contracts will always post asynchronous requests on the Tangle, and it is
-possible to do this from a user application as well, there is a price to be paid in the
-form of having to wait for confirmation pf the request on the Tangle before it can be
-processed. Therefore, ISC also allows user applications to send requests directly to a
-blockchain through a web API provided by the processing nodes. We call such requests
-_off-ledger_ requests, as opposed to the _on-ledger_ requests that are posted directly on
-the Tangle ledger. Off-ledger requests can be sent at a much higher frequency than
-off-ledger requests, but on-ledger requests offer a few additional features that are not
-available to off-ledger requests.
-
-In both cases requests are initiated by a so-called _sender_. The sender signs the request
-with its private key and can therefore be uniquely and securely identified. We also
-identify a _caller_ to a smart contract function. While a request is being processed the
-sender will stay the same, but the caller will change with every synchronous call that is
-being made. This will allow the transfer of assets between calls to different contracts
-within the chain, and allows the called function to easily identify the origin of these
-assets. Note that a function can only access assets that were provided by the caller of
-the function. So even though the original sender of the request is known at any call
-depth, only the top level function can access the assets that the sender provided to the
-request.
-
-The way assets are provided to a smart contract function is by specifying a so-called
-_allowance_. The function is allowed (but not required) to transfer ownership of the
-assets indicated in the allowance to itself, depending on the requirements of the
-function. The allowance is taken out of the on-chain account of the caller. This means
-that the caller needs to make sure that these assets are available in the account when
-the call is executed. For off-ledger requests this means that prior to sending the request
-sufficient assets need to be deposited in the sender's on-chain account. For on-ledger
-requests the assets may also have been deposited prior to sending the request, or they may
-be sent along as part of the request.
-
-Any assets that are sent to a chain as part of an on-ledger request will end up in the
-sender's on-chain account. The allowance mechanism makes it impossible for assets to
-inadvertently be sent to a wrong or non-existing contract and become lost forever. Any
-assets that are not handled by any contract will safely stay in the sender's on-chain
-account and can be withdrawn by the sender at any time.
-
-In the next section we will explore how smart contracts use the WasmLib
-[Call Context](context.mdx).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/context.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/context.mdx
deleted file mode 100644
index 76d20327b3f..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/context.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-keywords:
- - functions
- - views
- - Funcs
- - ScFuncContext
- - ScViewContext
-
-description: The call context is a predefined parameter to each smart contract function, which allows you to access the functionality that the call environment provides.
-
-image: /img/logo/WASP_logo_dark.png
----
-
-# Call Context
-
-Due to the sandboxed nature of Wasm code, it needs a host which runs the Wasm Virtual
-Machine (VM) that is able to load and execute the Wasm code. The host also provides the
-Wasm code with restricted access to the host environment. These restrictions make the host
-environment itself sandboxed as well. Smart contracts will only be able to call certain
-environment functionality, depending on the _call context_.
-
-We distinguish between two types of smart contract function calls:
-
-- **Func**, which allows full mutable access to the smart contract state, and always
- results in a state update. Funcs can be initiated through on-ledger and off-ledger
- requests. A call to a Func is only complete once the associated state update has been
- registered in the ledger (Tangle).
-- **View**, which allows only limited, immutable access to the smart contract state, and
- therefore does not result in a state update. Views are always initiated through
- off-ledger function calls. Since they do not require a state update on the ledger they
- can be used to efficiently query the current state of the smart contract.
-
-To support this function call type distinction, Func and View functions each receive a
-separate, different call context through WasmLib. Only the functionality that is necessary
-for their implementation can be accessed through their respective WasmLib contexts,
-`ScFuncContext` and `ScViewContext`. ScViewContext provides a limited, immutable subset of
-the full functionality provided by ScFuncContext. By having separate context types,
-compile-time type-checking can easily be used to enforce these usage constraints.
-
-# Smart Contract Setup
-
-An important part of setting up a smart contract is defining exactly which Funcs and Views
-are available and informing the host about them through WasmLib. The host will have to be
-able to dispatch requested function calls to the corresponding smart contract code and
-will have to apply any restrictions necessary to prevent Views from accidentally accessing
-full Func functionality.
-
-Another important part is to define for each function exactly what parameters and return
-values are expected/available, if any. The ISC stores parameter, state, and result values
-in simple dictionaries, with both keys and values being arbitrary byte strings. Normally,
-programming languages provide a much richer set of data types, which means that these data
-types will need to be serialized and deserialized correctly and consistently. WasmLib
-provides a rich set of (de)serialization functions specifically for this purpose
-
-Even though it is definitely possible for a contract creator to directly use WasmLib to
-achieve his goals, we decided to provide a _Schema Tool_, which can be used to
-automatically generate and update the entire smart contract framework code in the desired
-language in a consistent and type-safe way.
-
-In the next section we will introduce this smart contract [`Schema Tool`](schema.mdx).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/intro.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/intro.mdx
deleted file mode 100644
index f1ef3bdb8a4..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/intro.mdx
+++ /dev/null
@@ -1,111 +0,0 @@
----
-keywords:
- - Rust
- - Go
- - TypeScript
- - WASM
- - memory space
- - smart contract state
- - API
- - Access
- - store
- - state
-
-description: IOTA Smart Contracts (ISC) provides a very flexible way of programming smart contracts by providing an API to a sandboxed environment that allows you to interact deterministically and without any security risks with ISC-provided functionality.
-
-image: /img/wasm_vm/IscHost.png
----
-
-# Introduction to the Wasm VM for ISC
-
-:::warning
-The Wasm VM is still in an experimental state, it is a testament to the "VM plugin" architecture of ISC.
-
-Experiment away, but please don't rely on it for any valuable applications (stick to EVM for now).
-:::
-
-IOTA Smart Contracts (ISC) provides a very flexible way of programming smart contracts by
-providing an API to a sandboxed environment that allows you to interact deterministically
-and without any security risks with ISC-provided functionality. The API provides a generic
-way to store, access, and modify the state of smart contracts. The API can be used by any
-kind of Virtual Machine (VM) to implement a system to load and run smart contract code on
-top of ISC. The actual VMs can be implemented by whoever wants to create them.
-
-[](/img/wasm_vm/IscHost.png)
-
-Of course, we provide an example implementation of such a VM to allow anyone to get a
-taste of what it is like to program a smart contract for ISC. Our VM implementation uses
-[WebAssembly](https://webassembly.org/) (Wasm) code as an intermediate compilation target.
-The implementation of the Wasm VM currently uses the open-source
-[Wasmtime](https://wasmtime.dev/) runtime environment. The Wasm VM enables dynamic
-loading and running of smart contracts that have been compiled to Wasm code.
-
-We chose Wasm to be able to program smart contracts from many programming languages. Since
-more and more languages are becoming capable of generating the intermediate Wasm code this
-will eventually allow developers to choose a language they are familiar with.
-
-Because each Wasm code unit runs in its own memory space and cannot access anything
-outside that memory by design, Wasm code is ideally suited for secure smart contracts.
-The Wasm VM runtime system will only provide access to external functionality that is
-necessary for the smart contracts to be able to do their thing, but nothing more. In our
-case, we only provide access to the ISC host's sandboxed API environment. The way we do
-that is by providing a small, self-contained library that can be linked to the Wasm code.
-This library is called `WasmLib`.
-
-
-
-As you can see, we can have any number of smart contracts running in our Wasm VM. Each
-smart contract is a separately compiled Wasm code unit that contains its own copy of
-WasmLib embedded into it. Each WasmLib provides the ISC sandbox functionality to its
-corresponding smart contract and knows how to use it to access the underlying smart
-contract state storage through the VM runtime system. This makes the ISC sandbox API
-access seamless to the smart contract by hiding the details of bridging the gap between
-the smart contract's memory space, and the otherwise inaccessible memory space of the ISC
-host.
-
-The ISC sandbox environment enables the following functionality:
-
-- Access to smart contract metadata
-- Access to request data for smart contract function calls
-- Access to the smart contract state data
-- A way to return result data to the caller of a smart contract function
-- Access to tokens meant for the smart contract, and the ability to move them
-- Ability to initiate or call other smart contract functions
-- Access to logging functionality
-- Access to several utility functions provided by the host
-
-The initial WasmLib implementation was created for the [Rust](https://www.rust-lang.org/)
-programming language. Rust had the most advanced and stable support for generating Wasm
-code at the time when we started implementing our Wasm VM environment. In the meantime,
-we have also implemented fully functional [Go](https://golang.org/) and
-[TypeScript](https://www.typescriptlang.org/) implementations. We currently support the
-following Wasm code generators:
-
-| Language | Wasm code generator |
-| ---------- | -------------------------------------------------- |
-| Go | [TinyGo](https://tinygo.org/) |
-| Rust | [wasm-pack](https://rustwasm.github.io/wasm-pack/) |
-| TypeScript | [AssemblyScript](https://www.assemblyscript.org/) |
-
-All WasmLib implementations use only a very small common subset of their host language.
-The same goes for the interface they provide to smart contract writers. This keeps the
-coding style very similar, barring some syntactic idiosyncrasies. The reason for doing
-this is that we wanted to make it as easy as possible for anyone to start working with our
-smart contract system. If you have previous experience in any C-style language you should
-quickly feel comfortable writing smart contracts in any of the supported languages,
-without having to dive too deeply into the more esoteric aspects of the chosen language.
-
-We will next discuss some [`concepts`](concepts.mdx) that are central to (ISC) smart
-contract programming.
-
-## Video Tutorial
-
-
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/post.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/post.mdx
deleted file mode 100644
index d3de81a7b0b..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/post.mdx
+++ /dev/null
@@ -1,93 +0,0 @@
----
-keywords:
- - function descriptor
- - return values
- - request
- - post
- - smart contract chain
- - Asynchronous function
-description: Asynchronous function calls between smart contracts are posted as requests on the Tangle. They allow you to invoke any smart contract function that is not a View on any smart contract chain.
-
-image: /img/logo/WASP_logo_dark.png
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-# Posting Asynchronous Requests
-
-Asynchronous function calls between smart contracts are posted as requests on the Tangle.
-They allow you to invoke any smart contract function that is not a View on any smart
-contract chain. You will notice that the behavior is very similar to a synchronous
-function call, but instead of using the [`call()`](call.mdx) method of the `func` member
-in the function descriptor, you will now use the `post()` or `postToChain()` methods. The
-`post()` method posts the request to the current chain, while `postToChain()` takes the
-chain ID of the desired chain as parameter.
-
-In addition to the previously discussed [`transferBaseTokens()`](call.mdx) and
-[`ofContract()`](call.mdx) methods, you can modify the behavior further by providing a
-`delay()` in seconds, which enables delayed execution of the request. This is of
-particular interest to smart contracts that need a delayed action like betting contracts
-with a timed betting round, or to create time-lock functionality in a smart contract.
-Here's how that works:
-
-
-
-
-
-```go
-eor := ScFuncs.EndOfRound(ctx)
-eor.Func.Delay(3600).Post()
-```
-
-
-
-
-```rust
-let eor = ScFuncs::end_of_round(ctx);
-eor.func.delay(3600).post();
-```
-
-
-
-
-```ts
-let eor = sc.ScFuncs.endOfRound(ctx);
-eor.func.delay(3600).post();
-```
-
-
-
-
-Because it is posted as a request on the Tangle, and it is not possible to have a request
-without a transfer, _an asynchronous request always needs to send at least some tokens_.
-In fact, there is a minimum amount of tokens to send, because you need to cover the gas
-that is necessary to run the function call. You can specify the tokens explicitly, in the
-same way we did previously with [synchronous calls](call.mdx), or you can have WasmLib
-specify a minimum amount of tokens automatically. Any tokens that are not used will end up
-in the caller's account on the chain.
-
-So, if you post to a function that expects tokens you just specify the amount of tokens
-required, but if you post to a function that does not expect any tokens then you can have
-WasmLib send the minimum amount for you.
-
-**Providing a `delay()` before a [`call()`](call.mdx) will result in a panic**. We do not
-know the intention of the user until the actual [`call()`](call.mdx) or
-[`post()`](post.mdx) is encountered, so we cannot check for this at compile-time unless we
-are willing to accept a lot of extra overhead. It should not really be a problem because
-using `delay()` is rare and using it with [`call()`](call.mdx) cannot have been the
-intention.
-
-The function that posts the request through the function descriptor will immediately
-continue execution and does not wait for its completion. Therefore, it is not possible to
-directly retrieve the return values from such a call.
-
-If you need some return values, you will have to create a mechanism that can do so, for
-example by providing a callback chain/contract/function combination as part of the input
-parameters of the requested function, so that upon completion that function can
-asynchronously post the results to the indicated function. It will require a certain
-degree of cooperation between both smart contracts. In the future we will probably be
-looking at providing a generic mechanism for this.
-
-In the next section we will look at how we can use the function descriptors when
-[testing smart contracts with Solo](test.mdx).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/proxies.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/proxies.mdx
deleted file mode 100644
index 32787d40e08..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/proxies.mdx
+++ /dev/null
@@ -1,104 +0,0 @@
----
-keywords:
- - proxies
- - sandbox
- - wasm
- - value proxies
- - container proxies
- - array proxies
- - map proxies
- - explanation
-
-description: As there is no way for the Wasm code to access any memory outside its own memory space, the WasmLib interface provides a number of proxies to make accessing data within the ISC sandbox as seamless as possible.
-
-image: /img/wasm_vm/Proxies.png
----
-
-# Data Access Proxies
-
-As we cannot call the ISC sandbox functions directly, we need some library to access the
-sandbox functionality. There is no way for the Wasm code to access any memory outside its
-wn memory space. Therefore, any data that is governed by the ISC sandbox has to be copied
-in and out of that memory space through well-defined protected channels in the Wasm
-runtime system.
-
-To make this whole process as seamless as possible the WasmLib interface uses so-called
-`proxies`. Proxies are objects that can perform the underlying data transfers between the
-separate systems. Proxies are like data references in that regard, they refer to the
-actual objects or values stored on the ISC host, and know how to manipulate them. Proxies
-provide a consistent interface to access the smart contract data.
-
-At the lowest level data is stored on the ISC host in maps that take a byte string as key
-and a byte string as value. There are 3 predefined maps from the viewpoint of WasmLib.
-They are:
-
-- the [State](state.mdx) map, which holds all state storage values
-- the [Params](params.mdx) map, which holds the current function call's parameter values
-- the [Results](results.mdx) map, which returns the function call's result values
-
-The [Schema Tool](usage.mdx) is able to build a more complex, JSON-like data structure
-on top of these maps, but in the end it all translates to simple key/value access on the
-underlying map.
-
-## Value Proxies
-
-The most basic proxies are value proxies. They refer to a single value instance of a
-predetermined data type. Value proxies refer to their values through a proxy object that
-defines the underlying map and the key that uniquely defines the value's location in that
-map. Value proxies can manipulate the value they refer to and will perform appropriate
-type conversion of the byte string that makes up the stored value.
-
-The [Schema Tool](usage.mdx) will make sure that the type-safe code that it generates
-always uses the appropriate proxy type.
-
-## Container Proxies
-
-Container proxies create a virtual nesting system on the underlying map. Just as with
-value proxies, they refer to their virtual container through a proxy object that defines
-the underlying map and the key that uniquely defines the virtual container in that map.
-Contrary to value proxies these virtual containers need no storage.
-
-The [Schema Tool](usage.mdx) automatically generates code that allows the user to navigate
-the virtual path through the nested virtual containers. In the end this path leads to
-access to value proxies of all values that are located in that virtual container.
-
-To keep things as simple and understandable we imitate the way JSON and YAML nest
-containers. That means there are only two different kinds of container proxies: array
-proxies and map proxies. Because we allow nesting of containers, these are enough to be
-able to define surprisingly complex data structures.
-
-### Map Proxies
-
-A map is a key/value store where the key is one of our supported value types. Within a
-map, keys are always of the same data type. The root maps ([State](state.mdx),
-[Params](params.mdx), and [Results](results.mdx)) can store elements of any type, but
-their keys are limited to human-readable strings. This is because these keys needs to be
-defined in the schema definition file. Virtual maps, which are nested under a root map,
-can hold values of a single associated data type, which can be one of our supported value
-types, a user-defined data type, or a virtual container object (map or array).
-
-### Array Proxies
-
-An array can be seen as a special kind of map. Its key is an Int32 value that has the
-property that keys always form a sequence from 0 to N-1 for an array with N elements.
-Arrays always store elements of a single associated data type, which can be one of our
-supported value types, a user-defined type, or a virtual container object (map or array).
-
-## Example That Shows the Use of Proxies in WasmLib
-
-[](/img/wasm_vm/Proxies.png)
-
-In this example we have a single map in the ISC state storage that contains a number of
-key/value combinations (Key 1 through Key 4). One of them (Key 4) refers to an array,
-which in turn contains indexed values stored at indexes 0 through N.
-
-Notice how the WasmLib proxies mirror these exactly. There is a container proxy for each
-container, and a value proxy for each value stored.
-
-Also note that despite the one-to-one correspondence in the example it is not necessary
-for a smart contract function to define a proxy for every value or container in the ISC
-state storage. In practice a function will only use proxies to data that it actually
-needs to access.
-
-In the next section we will go into more detail about the supported
-[WasmLib Data Types](types.mdx).
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/schema.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/schema.mdx
deleted file mode 100644
index 6dbb5b1bb49..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/schema.mdx
+++ /dev/null
@@ -1,84 +0,0 @@
----
-keywords:
- - code generation
- - schema tool
- - automatic
- - repetitive code fragments
- - robust
- - schema definition file
-
-description: To facilitate code generation, we decided to use a _schema definition file_ for smart contracts. All aspects of a smart contract that should be known by someone who wants to use the contract are clearly defined in a schema definition file.
-
-image: /img/logo/WASP_logo_dark.png
----
-
-# Smart Contract Schema Tool
-
-Smart contracts need to be very robust. The generic nature of WasmLib allows for a lot of
-flexibility, but it also provides a lot of opportunities to make mistakes. In addition,
-there is a lot of repetitive coding involved in creating smart contracts. The setup code
-that is needed for every smart contract must follow strict rules. You also want to assure
-that certain functions can only be called by specific entities. You need to verify that
-mandatory function parameter values are present. And function parameter values and return
-values need to be converted between their binary representation and their actual data
-type in a consistent way.
-
-The best way to increase robustness is by using a code generator that will take care of
-most repetitive coding tasks. A code generator only needs to be debugged once, after which
-the generated code is 100% accurate and trustworthy. Another advantage of code generation
-is that you can regenerate code to correctly reflect any changes to the smart contract
-interface. A code generator can also help you by generating wrapper code that limits what
-you can do to mirror the intent behind it. This enables compile-time enforcing of some
-aspects of the defined smart contract behavior. A code generator can also support multiple
-different programming languages.
-
-During the initial experiences with creating demo smart contracts for WasmLib, we quickly
-identified a number of areas where there was a lot of repetitive coding going on. Some
-examples of repetition were:
-
-- Setting up the `on_load` function and keeping it up to date
-- Checking function access rights
-- Verifying function parameter types
-- Verifying the presence of mandatory function parameters
-- Setting up access to [State](state.mdx), [Params](params.mdx), and [Results](results.mdx) maps
-- Defining common strings as constants
-
-To facilitate the code generation, it was decided to use a _schema definition file_ for
-smart contracts. The aspects of a smart contract that should be known by someone who wants
-to use the contract are all clearly defined in a schema definition file. This schema
-definition file then becomes the single source of truth for the interface to the smart
-contract. This schema definition file is then used by our [Schema Tool](usage.mdx) to
-automatically generate a complete smart contract skeleton that reflects the schema
-definition and only needs to be augmented by providing the actual function
-implementations.
-
-The schema definition file defines things like the [state storage](state.mdx) variables
-that the smart contract uses, the [Funcs](funcs.mdx) and [Views](views.mdx) that the
-contract implements, the [access rights](access.mdx) for each function, the
-[input parameters](params.mdx) and [output results](results.mdx) for each function, and
-additional data structures that the contract uses.
-
-With detailed schema information readily available in a single location, it becomes
-possible to do a lot more than just generating repetitive code fragments. You can use the
-schema information to generate the interfaces to functions, and have parameters, results,
-and state variables that use strict compile-time type-checking. That removes a common
-source of accidental errors. The generated interface can also be used by client side code
-so that there is a single, consistent way of calling smart contract functions.
-
-Another advantage of knowing everything about important smart contract aspects is that it
-is possible to generate constants to prevent repeating of typo-prone key strings, and
-precalculate necessary values like Hnames and encode them as constants instead of having
-the code recalculate them every time they are needed.
-
-Similarly, since you know all static keys that are going to be used by the smart contract
-in advance, you can now generate code that will inform the host correctly about all Funcs
-and Views that are available in the smart contract.
-
-Because of all this the code becomes both simpler and more efficient. Note that all the
-improvements described above are independent of the actual programming language that is
-being generated.
-
-The schema definition file can also provide a starting point for other tooling, for
-example a tool that automatically audits a smart contract.
-
-In the next section we will look at how the [Schema Tool](usage.mdx) works.
diff --git a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/yaml.mdx b/docs/build/wasp/0.7.0/docs/guide/wasm_vm/yaml.mdx
deleted file mode 100644
index 788fea9f07b..00000000000
--- a/docs/build/wasp/0.7.0/docs/guide/wasm_vm/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/0.7.0/docs/overview.md b/docs/build/wasp/0.7.0/docs/overview.md
deleted file mode 100644
index f3d8d99fa36..00000000000
--- a/docs/build/wasp/0.7.0/docs/overview.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-description: IOTA Smart Contracts allow you to run smart contracts on top of the IOTA Tangle.
-image: /img/Banner/banner_wasp.png
-keywords:
- - smart contracts
- - core concepts
- - scaling
- - flexibility
- - explanation
----
-
-# IOTA Smart Contracts
-
-
-
-:::caution
-
-Smart Contracts are currently only compatible with the stardust update and therefore only compatible with the Shimmer main- and testnetwork.
-
-:::
-
-IOTA Smart Contracts (ISC) is a platform that brings scalable and flexible smart contracts into the IOTA ecosystem. It
-allows anyone to spin up a smart contract blockchain and anchor it to the IOTA Tangle, a design that offers multiple
-advantages.
-
-## ISC Advantages
-
-### Scaling and Fees
-
-Due to the ordered structure and execution time of a smart contract, a single blockchain can only handle so many
-transactions per second before deciding which transactions it needs to postpone until other blocks are produced, as
-there is no processing power available for them on that chain.
-On smart contract platforms that support a single blockchain, this eventually results in low throughput and high fees.
-
-ISC allows many chains to be anchored to the IOTA Tangle and lets them execute in parallel and communicate with each
-other.
-Because of this, ISC will typically have much higher throughput and lower fees than single-chain smart contract
-platforms.
-Moreover, ISC is a level 2 solution where only a committee of nodes spends resources executing the smart contracts for
-any given chain. Hence, the rest of the IOTA network is mainly unaffected by ISC traffic.
-
-### Custom Chains
-
-Since anyone can start a new chain and set its rules, many things that were otherwise not available in single-chain
-platforms become possible.
-
-For example, the chain owner has complete control over the gas fee policy: set the gas price, select which native token
-to charge, and what percentage of the fee goes to validators.
-
-It is possible to spin up a private blockchain with no public data besides the state hash anchored to the main IOTA
-Tangle.
-This allows parties that need private blockchains to use the security of the public IOTA network without exposing their
-data to the public.
-
-### Flexibility
-
-ISC is agnostic about the virtual machine that executes the smart contract code.
-We support [Rust/Wasm](https://rustwasm.github.io/docs/book/)-based smart contracts
-and [Solidity/EVM](https://docs.soliditylang.org/en/v0.8.6/)-based smart contracts.
-Eventually, all kinds of virtual machines can be supported in an ISC chain depending on the demand.
-
-IOTA Smart Contracts are more complex than conventional smart contracts, but this provides freedom and flexibility to
-use smart contracts in a wide range of use cases.
-
-## Wasp
-
-Wasp is the reference implementation of IOTA Smart Contracts.
-Multiple Wasp nodes form a committee in charge of an ISC chain.
-When they reach a consensus on a virtual machine state-change, they anchor that state change to the IOTA tangle, making
-it immutable.
-
-## Feedback
-
-We are eager to receive your feedback about your experiences with the IOTA Smart Contracts Beta. You can
-use [this form](https://docs.google.com/forms/d/e/1FAIpQLSd4jcmLzCPUNDIijEwGzuWerO23MS0Jmgzszgs-D6_awJUWow/viewform) to
-share your developer experience with us. This feedback will help us improve the product in future releases.
diff --git a/docs/build/wasp/0.7.0/sidebars.js b/docs/build/wasp/0.7.0/sidebars.js
deleted file mode 100644
index 0302af87131..00000000000
--- a/docs/build/wasp/0.7.0/sidebars.js
+++ /dev/null
@@ -1,283 +0,0 @@
-/**
- * Creating a sidebar enables you to:
- - create an ordered group of docs
- - render a sidebar for each doc of that group
- - provide next/previous navigation
-
- The sidebars can be generated from the filesystem, or explicitly defined here.
-
- Create as many sidebars as you want.
- */
-
-module.exports = {
- // By default, Docusaurus generates a sidebar from the docs folder structure
- //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
-
- // But you can create a sidebar manually
- tutorialSidebar: [
- {
- type: 'doc',
- label: 'Overview',
- id: 'overview',
- },
- {
- type: 'category',
- label: 'EVM',
- items: [
- {
- type: 'doc',
- label: 'Introduction',
- id: 'guide/evm/introduction',
- },
- {
- type: 'doc',
- label: 'Quickstart',
- id: 'guide/evm/quickstart',
- },
- {
- type: 'doc',
- label: 'Compatibility',
- id: 'guide/evm/compatibility',
- },
- {
- type: 'doc',
- label: 'How to Use',
- id: 'guide/evm/using',
- },
- {
- type: 'doc',
- label: 'The Magic Contract',
- id: 'guide/evm/magic',
- },
- {
- type: 'doc',
- label: 'Magic Contract Usage',
- id: 'guide/evm/magic-uses',
- },
- {
- type: 'doc',
- label: 'Tooling',
- id: 'guide/evm/tooling',
- },
- {
- type: 'category',
- label: 'Examples',
- items: [
- {
- type: 'doc',
- label: 'Example Contract',
- id: 'guide/evm/examples/introduction',
- },
- {
- type: 'doc',
- label: 'ERC20',
- id: 'guide/evm/examples/ERC20',
- },
- {
- type: 'doc',
- label: 'ERC721',
- id: 'guide/evm/examples/ERC721',
- },
- ],
- },
- ],
- },
- {
- type: 'doc',
- id: 'testnet',
- },
- {
- type: 'category',
- label: 'Wasm VM (Experimental)',
- items: [
- {
- type: 'doc',
- label: 'Wasm VM for ISC',
- id: 'guide/wasm_vm/intro',
- },
- {
- type: 'doc',
- label: 'Smart Contract Concepts',
- id: 'guide/wasm_vm/concepts',
- },
- {
- type: 'doc',
- label: 'Call Context',
- id: 'guide/wasm_vm/context',
- },
- {
- type: 'doc',
- label: 'Smart Contract Schema Tool',
- id: 'guide/wasm_vm/schema',
- },
- {
- type: 'doc',
- label: 'Using the Schema Tool',
- id: 'guide/wasm_vm/usage',
- },
- {
- type: 'category',
- label: 'Testing Smart Contracts with Solo',
- items: [
- {
- type: 'doc',
- label: 'What is Solo?',
- id: 'guide/solo/what-is-solo',
- },
- {
- type: 'doc',
- label: 'First Example',
- id: 'guide/solo/first-example',
- },
- {
- type: 'doc',
- label: 'The L1 Ledger',
- id: 'guide/solo/the-l1-ledger',
- },
- {
- type: 'doc',
- label: 'Deploying a Smart Contract',
- id: 'guide/solo/deploying-sc',
- },
- {
- type: 'doc',
- label: 'Invoking a Smart Contract',
- id: 'guide/solo/invoking-sc',
- },
- {
- type: 'doc',
- label: 'Calling a View',
- id: 'guide/solo/view-sc',
- },
- {
- type: 'doc',
- label: 'Error Handling',
- id: 'guide/solo/error-handling',
- },
- {
- type: 'doc',
- label: 'Accounts',
- id: 'guide/solo/the-l2-ledger',
- },
- ],
- },
- {
- type: 'doc',
- label: 'Data Access Proxies',
- id: 'guide/wasm_vm/proxies',
- },
- {
- type: 'doc',
- label: 'WasmLib Data Types',
- id: 'guide/wasm_vm/types',
- },
- {
- type: 'doc',
- label: 'Structured Data Types',
- id: 'guide/wasm_vm/structs',
- },
- {
- type: 'doc',
- label: 'Type Definitions',
- id: 'guide/wasm_vm/typedefs',
- },
- {
- type: 'doc',
- label: 'Smart Contract State',
- id: 'guide/wasm_vm/state',
- },
- {
- type: 'doc',
- label: 'Triggering Events',
- id: 'guide/wasm_vm/events',
- },
- {
- type: 'doc',
- label: 'Function Definitions',
- id: 'guide/wasm_vm/funcs',
- },
- {
- type: 'doc',
- label: 'Limiting Access',
- id: 'guide/wasm_vm/access',
- },
- {
- type: 'doc',
- label: 'Function Parameters',
- id: 'guide/wasm_vm/params',
- },
- {
- type: 'doc',
- label: 'Function Results',
- id: 'guide/wasm_vm/results',
- },
- {
- type: 'doc',
- label: 'Thunk Functions',
- id: 'guide/wasm_vm/thunks',
- },
- {
- type: 'doc',
- label: 'View-Only Functions',
- id: 'guide/wasm_vm/views',
- },
- {
- type: 'doc',
- label: 'Smart Contract Initialization',
- id: 'guide/wasm_vm/init',
- },
- {
- type: 'doc',
- label: 'Token Transfers',
- id: 'guide/wasm_vm/transfers',
- },
- {
- type: 'doc',
- label: 'Function Descriptors',
- id: 'guide/wasm_vm/funcdesc',
- },
- {
- type: 'doc',
- label: 'Calling Functions',
- id: 'guide/wasm_vm/call',
- },
- {
- type: 'doc',
- label: 'Posting Asynchronous Requests',
- id: 'guide/wasm_vm/post',
- },
- {
- type: 'doc',
- label: 'Testing Smart Contracts',
- id: 'guide/wasm_vm/test',
- },
- {
- type: 'doc',
- label: 'Example Tests',
- id: 'guide/wasm_vm/examples',
- },
- {
- type: 'doc',
- label: 'Colored Tokens and Time Locks',
- id: 'guide/wasm_vm/timelock',
- },
- {
- type: 'category',
- label: 'Example projects',
- items: [
- {
- type: 'doc',
- label: 'Fair Roulette',
- id: 'guide/wasm_vm/example_projects/fair_roulette',
- },
- ],
- },
- ],
- },
- {
- type: 'doc',
- label: 'Contribute',
- id: 'contribute',
- },
- ],
-};
diff --git a/docs/learn/protocols/stardust/introduction.md b/docs/learn/protocols/stardust/introduction.md
index d5b08880d1d..4aa229f16c9 100644
--- a/docs/learn/protocols/stardust/introduction.md
+++ b/docs/learn/protocols/stardust/introduction.md
@@ -48,7 +48,7 @@ If a user decides they no longer need the storage, they can reclaim their deposi
## ISC Support
-You can deploy [IOTA Smart Contracts (ISC)](../../smart-contracts/core_concepts/smart-contracts.md) as Layer 2 (L2) chains
+You can deploy [IOTA Smart Contracts (ISC)](../../smart-contracts/introduction.md) as Layer 2 (L2) chains
in Stardust.
This approach differs from platforms that run smart contracts on their primary layer,
ensuring the main layer remains efficient and speedy while also providing the flexibility that smart contracts offer on
diff --git a/docs/learn/sidebars.ts b/docs/learn/sidebars.ts
index 6bf6861add0..3e70cccde5b 100644
--- a/docs/learn/sidebars.ts
+++ b/docs/learn/sidebars.ts
@@ -61,132 +61,49 @@ module.exports = {
collapsed: true,
items: [
{
- type: 'category',
- label: 'Core Concepts',
- items: [
- {
- type: 'doc',
- label: 'Smart Contracts',
- id: 'smart-contracts/core_concepts/smart-contracts',
- },
- {
- type: 'doc',
- label: 'ISC Architecture',
- id: 'smart-contracts/core_concepts/isc-architecture',
- },
- {
- type: 'doc',
- label: 'Validators and Access Nodes',
- id: 'smart-contracts/core_concepts/validators',
- },
- {
- type: 'doc',
- label: 'Consensus',
- id: 'smart-contracts/core_concepts/consensus',
- },
- {
- type: 'doc',
- label: 'State manager',
- id: 'smart-contracts/core_concepts/state_manager',
- },
- {
- type: 'doc',
- label: 'State, Transitions and State Anchoring',
- id: 'smart-contracts/core_concepts/states',
- },
- {
- type: 'doc',
- label: 'Anatomy of a Smart Contract',
- id: 'smart-contracts/core_concepts/smart-contract-anatomy',
- },
- {
- type: 'doc',
- label: 'Calling a Smart Contract',
- id: 'smart-contracts/core_concepts/invocation',
- },
- {
- type: 'doc',
- label: 'Sandbox Interface',
- id: 'smart-contracts/core_concepts/sandbox',
- },
- {
- type: 'category',
- label: 'Core Contracts',
- items: [
- {
- type: 'doc',
- label: 'Overview',
- id: 'smart-contracts/core_concepts/core_contracts/overview',
- },
- {
- type: 'doc',
- label: 'root',
- id: 'smart-contracts/core_concepts/core_contracts/root',
- },
- {
- type: 'doc',
- label: 'accounts',
- id: 'smart-contracts/core_concepts/core_contracts/accounts',
- },
- {
- type: 'doc',
- label: 'blob',
- id: 'smart-contracts/core_concepts/core_contracts/blob',
- },
- {
- type: 'doc',
- label: 'blocklog',
- id: 'smart-contracts/core_concepts/core_contracts/blocklog',
- },
- {
- type: 'doc',
- label: 'governance',
- id: 'smart-contracts/core_concepts/core_contracts/governance',
- },
- {
- type: 'doc',
- label: 'errors',
- id: 'smart-contracts/core_concepts/core_contracts/errors',
- },
- {
- type: 'doc',
- label: 'evm',
- id: 'smart-contracts/core_concepts/core_contracts/evm',
- },
- ],
- },
- {
- type: 'category',
- label: 'Accounts',
- items: [
- {
- type: 'doc',
- label: 'How Accounts Work',
- id: 'smart-contracts/core_concepts/accounts/how-accounts-work',
- },
- {
- type: 'doc',
- label: 'How To Deposit To a Chain',
- id: 'smart-contracts/core_concepts/accounts/how-to-deposit-to-a-chain',
- },
- {
- type: 'doc',
- label: 'How To Withdraw From a Chain',
- id: 'smart-contracts/core_concepts/accounts/how-to-withdraw-from-a-chain',
- },
- {
- type: 'doc',
- label: 'View Account Balances',
- id: 'smart-contracts/core_concepts/accounts/view-account-balances',
- },
- {
- type: 'doc',
- label: 'The Common Account',
- id: 'smart-contracts/core_concepts/accounts/the-common-account',
- },
- ],
- },
- ],
+ type: 'doc',
+ label: 'Introduction',
+ id: 'smart-contracts/introduction',
+ },
+ {
+ type: 'doc',
+ label: 'ISC Architecture',
+ id: 'smart-contracts/isc-architecture',
+ },
+ {
+ type: 'doc',
+ label: 'Anatomy of a Smart Contract',
+ id: 'smart-contracts/smart-contract-anatomy',
+ },
+ {
+ type: 'doc',
+ label: 'Sandbox Interface',
+ id: 'smart-contracts/sandbox',
+ },
+ {
+ type: 'doc',
+ label: 'Calling a Smart Contract',
+ id: 'smart-contracts/invocation',
+ },
+ {
+ type: 'doc',
+ label: 'State, Transitions and State Anchoring',
+ id: 'smart-contracts/states',
+ },
+ {
+ type: 'doc',
+ label: 'State manager',
+ id: 'smart-contracts/state_manager',
+ },
+ {
+ type: 'doc',
+ label: 'Validators and Access Nodes',
+ id: 'smart-contracts/validators',
+ },
+ {
+ type: 'doc',
+ label: 'Consensus',
+ id: 'smart-contracts/consensus',
},
],
},
diff --git a/docs/learn/smart-contracts/core_concepts/consensus.md b/docs/learn/smart-contracts/consensus.md
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/consensus.md
rename to docs/learn/smart-contracts/consensus.md
diff --git a/docs/learn/smart-contracts/core_concepts/accounts/the-common-account.mdx b/docs/learn/smart-contracts/core_concepts/accounts/the-common-account.mdx
deleted file mode 100644
index 5ecaf691e88..00000000000
--- a/docs/learn/smart-contracts/core_concepts/accounts/the-common-account.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: The common account is controlled by the chain owner, and is used to store funds collected by fees, invalid contracts or sent to the L1 chain address.
-image: /img/logo/WASP_logo_dark.png
-keywords:
- - smart contracts
- - deposit
- - transfer
- - chain
- - Rust
- - Solo
- - how to
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-# The Common Account
-
-The common account is controlled by the chain owner defined in the chain [root contract](../core_contracts/root.md).
-
-This account is only used to accumulate funds for minimum storage deposit.
diff --git a/docs/learn/smart-contracts/core_concepts/smart-contracts.md b/docs/learn/smart-contracts/introduction.md
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/smart-contracts.md
rename to docs/learn/smart-contracts/introduction.md
diff --git a/docs/learn/smart-contracts/core_concepts/invocation.md b/docs/learn/smart-contracts/invocation.md
similarity index 98%
rename from docs/learn/smart-contracts/core_concepts/invocation.md
rename to docs/learn/smart-contracts/invocation.md
index 88cd869bcea..c0e04f55abd 100644
--- a/docs/learn/smart-contracts/core_concepts/invocation.md
+++ b/docs/learn/smart-contracts/invocation.md
@@ -87,7 +87,7 @@ etc.) has an associated gas cost.
For users to specify how much they're willing to pay for a request, they need to specify a `GasBudget` in the request.
This gas budget is the "maximum operations that this request can execute" and will be charged as a fee based on the
-chain's current [fee policy](core_contracts/governance.md#fee-policy).
+chain's current [fee policy](/wasp-wasm/reference/core-contracts/governance#fee-policy).
The funds to cover the gas used will be charged directly from the user's on-chain account.
diff --git a/docs/learn/smart-contracts/core_concepts/isc-architecture.md b/docs/learn/smart-contracts/isc-architecture.md
similarity index 90%
rename from docs/learn/smart-contracts/core_concepts/isc-architecture.md
rename to docs/learn/smart-contracts/isc-architecture.md
index 9330d085f1d..04f216cf7a0 100644
--- a/docs/learn/smart-contracts/core_concepts/isc-architecture.md
+++ b/docs/learn/smart-contracts/isc-architecture.md
@@ -14,7 +14,7 @@ keywords:
# ISC Architecture
IOTA Smart Contracts work as a _layer 2_ (L2 for short) extension of the [_IOTA Multi-Asset
-Ledger_](https://github.com/lzpap/tips/blob/master/tips/TIP-0018/tip-0018.md) (Layer 1, or L1 for short, also sometimes
+Ledger_](../protocols/stardust/core-concepts/multi-asset-ledger.md) (Layer 1, or L1 for short, also sometimes
called the UTXO Ledger).
In IOTA Smart Contracts, each L2 chain has its own state and smart contracts that cause this state to change.
diff --git a/docs/learn/smart-contracts/core_concepts/sandbox.md b/docs/learn/smart-contracts/sandbox.md
similarity index 93%
rename from docs/learn/smart-contracts/core_concepts/sandbox.md
rename to docs/learn/smart-contracts/sandbox.md
index 5d7082c68a8..5ccb1918a59 100644
--- a/docs/learn/smart-contracts/core_concepts/sandbox.md
+++ b/docs/learn/smart-contracts/sandbox.md
@@ -30,14 +30,14 @@ their internal state as a list of key/value pairs.
Besides reading and writing to the contract state, the Sandbox interface allows smart contracts to access:
-- The [ID](./accounts/how-accounts-work.md#agent-id) of the contract.
+- The [ID](/wasp-wasm/explanations/how-accounts-work) of the contract.
- The details of the current request or view call.
- The current request allowance and a way to claim the allowance.
- The balances owned by the contract.
- The ID of whoever had deployed the contract.
- The timestamp of the current block.
- Cryptographic utilities like hashing, signature verification, and so on.
-- The [events](/smart-contracts/guide/wasm_vm/events) dispatch.
+- The [events](/wasp-wasm/how-tos/schema-tool/events) dispatch.
- Entropy that emulates randomness in an unpredictable yet deterministic way.
- Logging. Used for debugging in a test environment.
diff --git a/docs/learn/smart-contracts/core_concepts/smart-contract-anatomy.md b/docs/learn/smart-contracts/smart-contract-anatomy.md
similarity index 86%
rename from docs/learn/smart-contracts/core_concepts/smart-contract-anatomy.md
rename to docs/learn/smart-contracts/smart-contract-anatomy.md
index 4d5e73dfa40..bde93f46b05 100644
--- a/docs/learn/smart-contracts/core_concepts/smart-contract-anatomy.md
+++ b/docs/learn/smart-contracts/smart-contract-anatomy.md
@@ -16,7 +16,8 @@ Smart contracts are programs that are immutably stored in the chain.
Through _VM abstraction_, the ISC virtual machine is agnostic about the interpreter used to execute each smart contract.
It can support different _VM types_ (i.e., interpreters) simultaneously on the same chain.
-For example, it is possible to have Wasm and EVM/Solidity smart contracts coexisting on the same chain.
+For example, it is possible to have [Wasm](/wasp-wasm/introduction/) and [EVM/Solidity](/wasp-evm/introduction/) smart
+contracts coexisting on the same chain.
The logical structure of IOTA Smart Contracts is independent of the VM type:
@@ -26,7 +27,8 @@ The logical structure of IOTA Smart Contracts is independent of the VM type:
Each smart contract on the chain is identified by a _hname_ (pronounced "aitch-name"), which is a `uint32` value
calculated as a hash of the smart contract's instance name (a string).
-For example, the hname of the [`root`](/learn/smart-contracts/core_concepts/core_contracts/root) core contract is `0xcebf5908`. This
+For example, the hname of the [`root`](/wasp-wasm/reference/core-contracts/root/) core contract
+is `0xcebf5908`. This
value uniquely identifies this contract in every chain.
## State
@@ -47,7 +49,8 @@ Only the smart contract program can change its data state and spend from its
account. Tokens can be sent to the smart contract account by any other agent on
the ledger, be it a wallet with an address or another smart contract.
-See [Accounts](/learn/smart-contracts/core_concepts/accounts/how-accounts-work) for more information on sending and receiving tokens.
+See [Accounts](https://wiki.iota.org/build/wasp-wasm/how-accounts-work/) for more information on sending and receiving
+tokens.
## Entry Points
@@ -65,7 +68,8 @@ There are two types of entry points:
## Execution Results
After a request to a Smart Contract is executed (a call to a full entry point), a _receipt_ will be added to
-the [`blocklog`](/learn/smart-contracts/core_concepts/core_contracts/blocklog) core contract. The receipt details the execution results
+the [`blocklog`](/wasp-wasm/reference/core-contracts/blocklog/) core contract. The receipt details the
+execution results
of said request: whether it was successful, the block it was included in, and other information.
Any events dispatched by the smart contract in context of this execution will also be added to the receipt.
diff --git a/docs/learn/smart-contracts/smart-contracts.md b/docs/learn/smart-contracts/smart-contracts.md
new file mode 100644
index 00000000000..608e2248272
--- /dev/null
+++ b/docs/learn/smart-contracts/smart-contracts.md
@@ -0,0 +1,54 @@
+---
+description: 'Smart contracts are applications you can trust that run on a distributed network with multiple validators
+all executing and validating the same code.'
+image: /img/Banner/banner_wasp_core_concepts_smart_contracts.png
+keywords:
+
+- smart contracts
+- blockchain
+- parallel
+- scaling
+- explanation
+
+---
+
+# Smart Contracts
+
+
+
+## What Are Smart Contracts?
+
+Smart contracts are software applications that run on a distributed network with multiple validators executing and
+validating the same code. This ensures the application behaves as expected and that there is no tampering in the
+program's execution.
+
+### Applications You Can Trust
+
+As you can be certain that the executed code is always the same (and will not change), this results in
+applications you can trust. This allows you to use smart contracts for applications with a trust issue. The
+smart contract rules define what the contract can and can not do, making it a decentralized and predictable
+decision-maker.
+
+You can use smart contracts for all kinds of purposes. A recurring reason to use a smart contract is to automate
+specific
+actions without needing a centralized entity to enforce this specific action. A good example is a smart contract
+that can exchange a certain amount of IOTA tokens for land ownership. The smart contract will accept
+both the IOTA tokens and the land ownership, and will predictably exchange them between both parties without the risk of
+one of the parties not delivering on their promise. **With a smart contract, code is law**.
+
+### Scalable Smart Contracts
+
+Anyone willing to pay the fees for deploying a smart contract on a public blockchain can deploy one. Once your smart
+contract has been deployed to the chain, you no longer have the option to change it, and you can be sure that your
+smart contract application will be there as long as that blockchain exists. Smart contracts can communicate with one
+another, and you can invoke programmed public functions on a smart contract to trigger actions on a smart contract, or
+address the state of a smart contract.
+
+Because smart contracts do not run on a single computer but on many validators, a network of validators can only
+process so many smart contracts at once, even if the software has been written optimally. This means smart contracts are
+expensive to execute, and do not scale well on a single blockchain, often resulting in congested networks and costly
+fees for executing functions on smart contracts. **By allowing many blockchains executing smart contracts to run in
+parallel** and communicate with one another, **IOTA Smart Contracts solves this scalability problem.**
+
+At the same time, ISC provides advanced means of communication between its chains and preserves the ability to create
+complex, composed smart contracts.
diff --git a/docs/learn/smart-contracts/core_concepts/state_manager.md b/docs/learn/smart-contracts/state_manager.md
similarity index 99%
rename from docs/learn/smart-contracts/core_concepts/state_manager.md
rename to docs/learn/smart-contracts/state_manager.md
index b7b1a9f2fc1..021e9bc3a07 100644
--- a/docs/learn/smart-contracts/core_concepts/state_manager.md
+++ b/docs/learn/smart-contracts/state_manager.md
@@ -9,7 +9,7 @@ keywords:
- WAL
---
-# State manager
+# State Manager
State manager aims at keeping the state of the node up to date by retrieving missing data and ensuring that it is
consistently stored in the DB. It services requests by other Wasp components (consensus, mempool), which mainly
diff --git a/docs/learn/smart-contracts/core_concepts/states.md b/docs/learn/smart-contracts/states.md
similarity index 100%
rename from docs/learn/smart-contracts/core_concepts/states.md
rename to docs/learn/smart-contracts/states.md
diff --git a/docs/learn/smart-contracts/core_concepts/validators.md b/docs/learn/smart-contracts/validators.md
similarity index 96%
rename from docs/learn/smart-contracts/core_concepts/validators.md
rename to docs/learn/smart-contracts/validators.md
index 20b5ac3ec24..a9118b0e24f 100644
--- a/docs/learn/smart-contracts/core_concepts/validators.md
+++ b/docs/learn/smart-contracts/validators.md
@@ -46,4 +46,5 @@ It is common for validator nodes to be part of a private subnet and have only a
outside world, protecting the committee from external attacks.
The management of validator and access nodes is done through
-the [`governance` core contract](./core_contracts/governance.md).
+the [`governance` core contract](/wasp-wasm/reference/core-contracts/
+governance/).
diff --git a/docs/maintain/getting-started/welcome.md b/docs/maintain/getting-started/welcome.md
index b9d7db99161..09b7d3bce60 100644
--- a/docs/maintain/getting-started/welcome.md
+++ b/docs/maintain/getting-started/welcome.md
@@ -27,6 +27,6 @@ removing the Coordinator from the IOTA networks.
### WASP - IOTA Smart Contracts
[WASP](/wasp/running-a-node) is an INX plugin you can install and use to run your smart contract chain.
-You can use the documentation to get your node up and running, and [set up](/wasp/setting-up-a-chain) and
-[manage](/wasp/chain-management) a chain, or check out the available
+You can use the documentation to get your node up and running, and [set up](/wasp-cli/how-tos/setting-up-a-chain/) and
+[manage](/wasp-cli/how-tos/chain-management) a chain, or check out the available
[configuration options](/wasp/configuration).
diff --git a/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md b/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md
index 3bf472d0787..36c8ea81d03 100644
--- a/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md
+++ b/docs/maintain/hornet/2.0.0-rc.6/docs/how_tos/using_docker.md
@@ -104,6 +104,7 @@ If you want to change the port to a different value you can create a file named
```
HTTP_PORT=9000
```
+
If you don't have a DNS name for your node, you can use the (external) IP address for `NODE_HOST`, for example, `192.168.1.123`, or your public IP address.
With this setting, you can reach the node dashboard from within your network or the internet.
You don’t need `COMPOSE_FILE` and `ACME_EMAIL` for HTTP. You can remove them from your `.env` file or place a `#` before it to make it a remark:
diff --git a/docs/maintain/wasp/0.7.0/docs/metrics.md b/docs/maintain/wasp/0.7.0/docs/metrics.md
index cbcff80c1dc..d055dc45de7 100644
--- a/docs/maintain/wasp/0.7.0/docs/metrics.md
+++ b/docs/maintain/wasp/0.7.0/docs/metrics.md
@@ -9,14 +9,14 @@ keywords:
# Exposed Metrics
-You can see all exposed metrics at our [metrics endpoint](https://wasp.sc.iota.org/metrics). Refer to the [testnet endpoints description](/smart-contracts/testnet#endpoints) for access details.
+Refer to the [testnet endpoints description](/build/networks-endpoints/#testnet-evm) for access details.
-| Metric | Description |
-| ------------------------------------------ | ----------------------------------------------------- |
-| `wasp_off_ledger_requests_counter` | Off-ledger requests per chain. |
-| `wasp_on_ledger_request_counter` | On-ledger requests per chain. |
-| `wasp_processed_request_counter` | Total number of requests processed. |
-| `messages_received_per_chain` | Number of messages received per chain. |
-| `receive_requests_acknowledgement_message` | Number of request acknowledgement messages per chain. |
-| `request_processing_time` | Time to process request. |
-| `vm_run_time` | Time it takes to run the vm. |
+| Metric | Description |
+| ------------------------------------------ | ---------------------------------------------------- |
+| `wasp_off_ledger_requests_counter` | Off-ledger requests per chain. |
+| `wasp_on_ledger_request_counter` | On-ledger requests per chain. |
+| `wasp_processed_request_counter` | Total number of requests processed. |
+| `messages_received_per_chain` | Number of messages received per chain. |
+| `receive_requests_acknowledgement_message` | Number of request acknowledgment messages per chain. |
+| `request_processing_time` | Time to process request. |
+| `vm_run_time` | Time it takes to run the VM. |
diff --git a/docs/maintain/wasp/0.7.0/docs/running-a-node.md b/docs/maintain/wasp/0.7.0/docs/running-a-node.md
index ff18793c889..ef18a3ae308 100644
--- a/docs/maintain/wasp/0.7.0/docs/running-a-node.md
+++ b/docs/maintain/wasp/0.7.0/docs/running-a-node.md
@@ -15,12 +15,12 @@ keywords:
# Running a Node
-Due to wasp being desgined as an INX plugin, its necessary to run the wasp node alongside your own hornet node, for this we provide a simple docker-compose setup.
+As Wasp is an INX plugin, you must run the wasp node alongside your hornet node. You can use the simple docker-compose setup to do so.
-## Setup
+## Set Up
Clone and follow the instructions on the [node-docker-setup repo](https://github.com/iotaledger/node-docker-setup).
:::note
-This is aimed for prodution-ready deployment, if you're looking to spawn a local node for testing/development, please see: [local-setup](https://github.com/iotaledger/wasp/tree/develop/tools/local-setup)
+This is aimed at production-ready deployment. If you're looking to spawn a local node for testing/development, please see the [local-setup](https://github.com/iotaledger/wasp/tree/develop/tools/local-setup)
:::
diff --git a/docs/maintain/wasp/0.7.0/sidebars.js b/docs/maintain/wasp/0.7.0/sidebars.js
index fde7656f21f..2a7b08b09e7 100644
--- a/docs/maintain/wasp/0.7.0/sidebars.js
+++ b/docs/maintain/wasp/0.7.0/sidebars.js
@@ -19,18 +19,6 @@ module.exports = {
type: 'doc',
id: 'running-a-node',
},
- {
- type: 'doc',
- id: 'wasp-cli',
- },
- {
- type: 'doc',
- id: 'setting-up-a-chain',
- },
- {
- type: 'doc',
- id: 'chain-management',
- },
{
type: 'doc',
id: 'configuration',
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 38fa2cea9fb..517a2663f03 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -56,7 +56,9 @@ module.exports = async () => {
'^(/[^/]+)?/wallet.rs/.*|' +
'^(/[^/]+)?/stronghold.rs/.*|' +
'^(/[^/]+)?/streams/.*|' +
- '^(/[^/]+)?/smart-contracts/.*',
+ '^(/[^/]+)?/wasp-cli/.*' +
+ '^(/[^/]+)?/wasp-wasm/.*' +
+ '^(/[^/]+)?/wasp-evm/.*',
},
{
label: 'Maintain',
diff --git a/src/components/HomeLayout/AppLibrariesSection.tsx b/src/components/HomeLayout/AppLibrariesSection.tsx
index f0d59962e58..18581f56d23 100644
--- a/src/components/HomeLayout/AppLibrariesSection.tsx
+++ b/src/components/HomeLayout/AppLibrariesSection.tsx
@@ -132,7 +132,7 @@ const LibrariesSection: FC = () => (
Learn about ISC
diff --git a/src/switcher.config.ts b/src/switcher.config.ts
index dae9567fefe..2e2ed266f64 100644
--- a/src/switcher.config.ts
+++ b/src/switcher.config.ts
@@ -151,14 +151,42 @@ const buildDocs = [
],
},
{
- id: 'smart-contract-0-7-0',
- label: 'Smart Contracts',
- description: 'Create smart contracts.',
+ id: 'wasp-evm-0-7-0',
+ label: 'EVM',
+ description: 'Create EVM smart contracts.',
icon: 'SmartContracts',
subsection: 'build-layer-2',
versions: [
{
- id: 'smart-contract-0-7-0',
+ id: 'wasp-evm-0-7-0',
+ label: '0.7.0',
+ badges: ['Shimmer'],
+ },
+ ],
+ },
+ {
+ id: 'wasp-cli-0-7-0',
+ label: 'Wasp CLI',
+ description: 'Create custom smart contract chains.',
+ icon: 'SmartContracts',
+ subsection: 'build-layer-2',
+ versions: [
+ {
+ id: 'wasp-cli-0-7-0',
+ label: '0.7.0',
+ badges: ['Shimmer'],
+ },
+ ],
+ },
+ {
+ id: 'wasp-wasm-0-7-0',
+ label: 'WASM (Experimental)',
+ description: 'Create WASM smart contracts.',
+ icon: 'SmartContracts',
+ subsection: 'build-layer-2',
+ versions: [
+ {
+ id: 'wasp-wasm-0-7-0',
label: '0.7.0',
badges: ['Shimmer'],
},
diff --git a/tutorials/pages/shimmerevm-dapp-voting.md b/tutorials/pages/shimmerevm-dapp-voting.md
index fc79593987b..3f3fed375ad 100644
--- a/tutorials/pages/shimmerevm-dapp-voting.md
+++ b/tutorials/pages/shimmerevm-dapp-voting.md
@@ -283,7 +283,7 @@ Please make a note of the ABI while you're compiling it. You will need it later.
Most of the front end is design work which is not the focus of this tutorial, so let's jump to the js part. You can use [this project](https://github.com/anistark/smart-contracts-demo/tree/main/voting) if you're looking for a ready design to get started. Feel free to make changes to the design to suit your needs.
-We will also use [Metamask](/smart-contracts/guide/evm/tooling/#metamask) in this section, so please ensure you have installed and logged in to Metamask.
+We will also use [Metamask](/wasp-evm/getting-started/compatible-tools) in this section, so please ensure you have installed and logged in to Metamask.
The first thing you need to do is check that Metamask is accessible from your dApp:
```javascript!
diff --git a/tutorials/pages/shimmerevm-setup.md b/tutorials/pages/shimmerevm-setup.md
index f15ece23e26..e77b815f629 100644
--- a/tutorials/pages/shimmerevm-setup.md
+++ b/tutorials/pages/shimmerevm-setup.md
@@ -13,7 +13,7 @@ In this tutorial, we will connect to Shimmer EVM Testnet, connect Metamask to it
## Connect to Shimmer EVM Testnet
-First, let's setup our Metamask with the EVM. For this exercise, we will use the testnet EVM chain. You can find all endpoints [here](/smart-contracts/testnet).
+First, let's setup our Metamask with the EVM. For this exercise, we will use the testnet EVM chain. You can find all endpoints [here](/build/networks-endpoints/#testnet-evm).
Add a new network on your Metamask, as shown below: