diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_with_hardhat.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_with_hardhat.md
new file mode 100644
index 00000000000..87a5ebacf19
--- /dev/null
+++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_with_hardhat.md
@@ -0,0 +1,5 @@
+:::tip Deploy a Smart Contract with Hardhat
+
+Deploy a Solidity Smart Contract using Hardhat following our [how-to Deploy a Smart Contract guide](/isc/how-tos/EVM/deploy-a-smart-contract#hardhat).
+
+:::
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_with_remix.md b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_with_remix.md
new file mode 100644
index 00000000000..3c7b30fccc9
--- /dev/null
+++ b/docs/build/isc/v1.0.0-rc.6/docs/_admonitions/_deploy_with_remix.md
@@ -0,0 +1,5 @@
+:::tip Deploy a Smart Contract with Remix
+
+Deploy a Solidity Smart Contract using Remix following our [how-to Deploy a Smart Contract guide](/isc/how-tos/EVM/deploy-a-smart-contract#remix).
+
+:::
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md
index 673f1a224ff..2eed8ebd08e 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md
@@ -87,11 +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
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/explanations/invocation.md
chain's current [fee policy](../reference/core-contracts/governance.md#fee-policy).
-========
-chain's current [fee policy](/isc/reference/core-contracts/governance#fee-policy).
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/learn/smart-contracts/invocation.md
The funds to cover the gas used will be charged directly from the user's on-chain account.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md
index c4ab38535ca..a56cd5658e3 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md
@@ -30,22 +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:
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md
- The [ID](how-accounts-work.md) of the contract.
-========
-- The [ID](/isc/explanations/how-accounts-work) of the contract.
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/learn/smart-contracts/sandbox.md
- 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.
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/explanations/sandbox.md
- The [events](../schema/how-tos/events.mdx) dispatch.
-========
-- The [events](/isc/how-tos/wasm/events) dispatch.
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/learn/smart-contracts/sandbox.md
- Entropy that emulates randomness in an unpredictable yet deterministic way.
- Logging. Used for debugging in a test environment.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md b/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md
index afef656125f..97ed59a19c0 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md
@@ -46,8 +46,4 @@ 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
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/explanations/validators.md
the [`governance` core contract](../reference/core-contracts/governance.md).
-========
-the [`governance` core contract](/isc/reference/core-contracts/governance/).
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/learn/smart-contracts/validators.md
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md
index 8c5973f9ea5..b826ba6207c 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md
@@ -7,7 +7,7 @@ import NetworkWarning from '../_admonitions/_network_warning.md'
The current release of IOTA Smart Contracts has support for [EVM/Solidity](#evmsolidity-based-smart-contracts) smart
contracts, as well as experimental [Wasm](#wasm-vm-for-isc) 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
+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.
## EVM/Solidity Based Smart Contracts
@@ -47,14 +47,14 @@ Experiment but avoid using it for production applications; opt for [EVM](quick-s
:::
-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.
+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.
You can use a [WebAssembly (Wasm)](https://webassembly.org/) VM 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,
+[Wasmtime runtime](https://wasmtime.dev/). This setup encourages dynamic smart contract operations compiled to Wasm code,
promoting security and adaptability with different programming languages.
@@ -75,7 +75,7 @@ The ISC sandbox environment offers:
### Supported Languages
-The WasmLib started with [Rust](https://www.rust-lang.org/) support, expanding to include [Go](https://golang.org/)
+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 |
@@ -84,5 +84,5 @@ and [TypeScript](https://www.typescriptlang.org/) with the help of respective Wa
| 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
+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.
\ No newline at end of file
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx
index f2a8e2dcf7b..1b5d66884e4 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/getting-started/tools.mdx
@@ -19,6 +19,8 @@ tags:
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import {AddToMetaMaskButton, EVMNetworks} from '@theme/AddToMetaMaskButton';
+import DeployWithRemix from '../_admonitions/_deploy_with_remix.md';
+import DeployWithHardhat from '../_admonitions/_deploy_with_hardhat.md';
import { ChainId } from '@theme/ChainId';
# Compatible Tools
@@ -95,6 +97,8 @@ the `Environment` dropdown.
+
+
Metamask will ask to connect to Remix, and once connected, it will set the `Environment` to `Injected Web3` with
the "Custom () network" or "Custom () network".
@@ -140,6 +144,8 @@ networks: {
+
+
:::caution
Currently, there is no validation service available for EVM/Solidity smart contracts on IOTA Smart Contracts, which is
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC20.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC20.md
index 9df4e164e84..cb7ee206220 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC20.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/ERC20.md
@@ -12,41 +12,39 @@ tags:
- how to
---
-# ERC20 Example
+import DeployWithRemix from '../../_admonitions/_deploy_with_remix.md';
+import DeployWithHardhat from '../../_admonitions/_deploy_with_hardhat.md';
-## Prerequisites
+# Create ERC20 Custom Tokens
-- [Remix IDE](https://remix.ethereum.org/).
-- [A Metamask Wallet](https://metamask.io/).
-- [Connect your MetaMask with the public Testnet](../../getting-started/tools.mdx#metamask).
+## Required Prior Knowledge
-### Required Prior Knowledge
-
-This guide assumes you are familiar with [tokens](https://en.wikipedia.org/wiki/Cryptocurrency#Crypto_token)
+This guide assumes you are familiar with the concept
+of [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/introduction) and have
-already tinkered with [Solidity](https://docs.soliditylang.org/en/v0.8.16/).
+[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/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.
+This guide will use the [Remix IDE](https://remix.ethereum.org/), but you can use this contract with any IDE you are
+familiar with.
+
## About ERC20
With the ERC20 standard, you can create your own tokens and transfer them to the EVM on IOTA Smart Contracts without
fees.
-You can use the [Remix IDE](https://remix.ethereum.org/) to deploy any regular Solidity Smart Contract.
-
-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.](../../getting-started/tools.mdx#metamask).
-
-## 1. Create a Smart Contract
+## 1. Create the Smart Contract
Create a new Solidity file, for example, `ERC20.sol` in the contracts folder of
your [Remix IDE](https://remix.ethereum.org/) and add this code snippet:
```solidity
+// SPDX-License-Identifier: MIT
+
pragma solidity ^0.8.7;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
@@ -58,46 +56,43 @@ contract ExampleERC20Token is ERC20 {
}
```
-This imports all functions from the OpenZeppelin smart contract and creates a new ERC20 token with your name and Symbol.
-OpenZeppelin provides many audited smart contracts and is a good point to start and learn.
-
-You can change the token name `ExampleERC20Token` and the token symbol `EET`.
+This imports all functions from the [OpenZeppelin ERC20](https://docs.openzeppelin.com/contracts/4.x/erc20) smart
+contract and creates a new ERC20 token with your name and Symbol.
-## 2. Compile Your Smart Contract
+:::tip OpenZeppelin
-Go to the second tab and compile your smart contract with the **Compile ERC20.sol** button.
+OpenZeppelin provides many audited smart contracts and is a good point to start and learn.
-
+:::
-## 3. Deploy Your Smart Contract
+:::note Customize Your Token
-1. Go to the next tab and select `Injected Web3` as your environment. Ensure that your MetaMask is installed and set up
- correctly.
+You can change the token name `ExampleERC20Token` and the token symbol `EET` for anything you want.
-2. Choose your ´ExampleERC20Token´ smart contract in the contract dropdown.
+:::
-3. Press the "Deploy" button. Your MetaMask wallet will pop up, and you will need to accept the deployment.
+
-
+## 2. Add Your Custom Tokens to MetaMask
-4. Your MetaMask browser extension will open automatically - press **confirm**.
+Once you have deployed your contract, you can add your new custom token to your Metamask account.
-
+1. Open Metamask, and click on the transaction that created the contract. From there, you can simply click
+ on `View on block explorer` to visit the transaction details. Alternatively, you can copy the transaction ID and
+ visit the [ShimmerEVM Explorer](https://explorer.evm.testnet.shimmer.network/)
+ or [ShimmerEVM Testnet Explorer](https://explorer.evm.testnet.shimmer.network/) and use the search bar to find transaction.
-## 4. Add Your Token to MetaMask
+ 
-1. Get the `contract address` from the transaction after the successful deployment. You can click on the latest
- transaction in your MetaMask Activity tab. If you have configured your MetaMask correctly,
- the [ShimmerEVM Explorer](https://explorer.evm.shimmer.network) will open the transaction.
-2. Copy the contract address and import your token into MetaMask.
+2. Copy the contract address from the transaction details, and import your custom ERC20 tokens into MetaMask.
-
+
-## 5. Have some Fun
+## 3. Have some Fun
Now you should see your token in MetaMask. You can send them to your friends without any fees or gas costs.
-
+
You also can ask in the [Discord Chat Server](https://discord.iota.org) to send them around and discover what the
community is building on IOTA Smart Contracts.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/deploy-a-smart-contract.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/deploy-a-smart-contract.mdx
index 89d4f1e858d..5c18c737271 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/deploy-a-smart-contract.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/deploy-a-smart-contract.mdx
@@ -11,7 +11,6 @@ description: 'Learn how to deploy smart contracts to Shimmer EVM and Shimmer EVM
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import {AddToMetaMaskButton, EVMNetworks} from '@theme/AddToMetaMaskButton';
-import { ChainId } from '@theme/ChainId';
# Deploy a Smart Contract
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/get-funds.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/get-funds.md
deleted file mode 100644
index 3f18173f509..00000000000
--- a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/EVM/get-funds.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-description: How to fund your L2 account.
-image: /img/logo/WASP_logo_dark.png
-keywords:
- - configure
- - using
- - EVM
- - Ethereum
- - Solidity
- - deploy
- - hardhat
- - metamask
- - JSON
- - RPC
- - how to
----
-import {AddToMetaMaskButton, EVMNetworks} from '@theme/AddToMetaMaskButton';
-
-# How To Fund Your L2 Account
-
-There are multiple types of assets available on both IOTA L1 and L2, here we discuss a few of them, and how to get them
-onto L2.
-
-:::tip Testnet
-
-If you want to fund your Testnet account, please refer to our [ShimmerEVM Testnet Quickstart Guide](../../getting-started/quick-start.mdx)
-
-:::
-
-## Fund an Ethereum Account on a IOTA Smart Contracts Chain
-
-To send EVM transactions, you need to have an Ethereum address that owns tokens on the ISC chain (L2). These tokens will
-be used to cover gas fees.
-
-### Firefly Wallet
-
-You can use your [Firefly Wallet](https://firefly.iota.org/) to easily send L1 SMR to your L2 Shimmer EVM account.
-
-#### Requirements
-
-* [Shimmer Tokens](/get-started/introduction/shimmer/shimmer-token/)
-* [Firefly Wallet](https://firefly.iota.org/)
-* [Metamask](https://metamask.io/)
-
-1. The first thing you will need to do is add Shimmer EVM to Metamask by hitting the following button.
-
-
-
-2. Once you have added Shimmer EVM to Metamask, you can get your address:
-
- 
-
-3. Next, you will need to open your [Firefly Wallet](https://firefly.iota.org/) and click on `Send Assets`.
-
- 
-
-4. Select Shimmer EVM in the network dropdown.
-
- 
-
-5. Enter the amount of `SMR` tokens you want to transfer, and the Metamask address from step 2, and click on `Next`
-
- 
-
-6. Review the transaction details and click on `Send`.
-
- 
-
-### Bloom Wallet
-
-* [Shimmer Tokens](/get-started/introduction/shimmer/shimmer-token/)
-* [Bloom Wallet](https://bloomwallet.io/)
-* [Metamask](https://metamask.io/)
-
-
-You can use your [Bloom Wallet](https://bloomwallet.io/) to easily send L1 SMR to your L2 Shimmer EVM account.
-
-1. The first thing you will need to do is add Shimmer EVM to Metamask by hitting the following button:
-
-
-
-2. Once you have added Shimmer EVM to Metamask, you can get your address:
-
- 
-
-3. Next, you will need to open your [Bloom Wallet](https://firefly.iota.org/) and click on `Send`.
-
- 
-
-4. Select an account with `SMR` tokens.
-
- 
-
-5. Enter the address you copied in step 2.
-
- 
-
-6. Enter the amount of `SMR` tokens you want to transfer.
-
- 
-
-7. Review the transaction details and click on `Confirm`.
-
- 
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/magic.md b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/magic.md
index 19e02225b93..c12f17e9c0e 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/magic.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/magic.md
@@ -48,11 +48,7 @@ tokens and native tokens on L2.
In the example below, `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,
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/how-tos/magic.md
calls [ISC Sandbox's](../explanations/sandbox.md) `GetEntropy`.
-========
-calls [ISC Sandbox's](/learn/smart-contracts/sandbox) `GetEntropy`.
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/magic.md
```solidity
pragma solidity >=0.8.5;
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-tokens-to-l1.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-tokens-to-l1.mdx
index 2e2230a09fc..5cc313f4a66 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-tokens-to-l1.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-tokens-to-l1.mdx
@@ -12,11 +12,7 @@ tags:
- JSON
- RPC
---
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/how-tos/send-tokens-to-l1.mdx
import AboutAccounts from '../_admonitions/_about-accounts.md';
-========
-import AboutAccounts from '../../_admonitions/_about-accounts.md';
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/use-the-magic-contract/send-tokens-to-l1.mdx
# Send Assets and Tokens to L1
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/simple-contract.mdx b/docs/build/isc/v1.0.0-rc.6/docs/how-tos/simple-contract.mdx
deleted file mode 100644
index aeb187965c2..00000000000
--- a/docs/build/isc/v1.0.0-rc.6/docs/how-tos/simple-contract.mdx
+++ /dev/null
@@ -1,36 +0,0 @@
----
-description: Creating a basic contract using ISC functionality.
-image: /img/logo/WASP_logo_dark.png
-keywords:
- - configure
- - using
- - EVM
- - magic
- - Ethereum
- - Solidity
- - metamask
- - JSON
- - RPC
----
-# Create a Simple Contract using ISC functionality
-
-## Example Code
-
-```solidity
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.0;
-
-import "@iota/iscmagic/ISC.sol";
-
-contract Entropy {
- 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/isc/v1.0.0-rc.6/docs/schema/how-tos/events.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/events.mdx
index c7a1a928351..02bd5174e73 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/events.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/events.mdx
@@ -20,7 +20,7 @@ A solution to this is triggering events, which is facilitated through smart cont
## ISC Sandbox Interface
-The `ScFuncContext` [Call Context](/isc/explanations/context) in ISC _Sandbox_ has an `event()` function to support event triggering.
+The `ScFuncContext` [Call Context](../../explanations/context.mdx) in ISC _Sandbox_ has an `event()` function to support event triggering.
This function takes a text string parameter, requiring creators and users to maintain and understand the chosen format.
However, this setup is prone to errors and inconsistency due to the arbitrary nature of the text strings used.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcdesc.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcdesc.mdx
index cc151f7681f..02cb861ba5c 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcdesc.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcdesc.mdx
@@ -391,7 +391,7 @@ export class ScFuncs {
## `dividend` Example - Generated Code
-In the `dividend` example in `contract.xx`, specific structs for [Funcs and Views](/isc/explanations/proxies) are created.
+In the `dividend` example in `contract.xx`, specific structs for [Funcs and Views](../../explanations/proxies.mdx) are created.
Here's how they operate:
### Access
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcs.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcs.mdx
index 2971517ad1d..0c48c6c85ed 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcs.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/funcs.mdx
@@ -17,7 +17,7 @@ import TabItem from '@theme/TabItem';
# Define Functions
Here is the full schema definition file for the `dividend` example. We will now focus on
-its [`funcs` and `views` sections](/isc/explanations/context). 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.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/params.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/params.mdx
index 4220f0cc8ce..60691771f75 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/params.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/params.mdx
@@ -99,4 +99,4 @@ export class ImmutableMemberParams extends wasmtypes.ScProxy {
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](/isc/explanations/context).
+suitable for providing the parameters when calling this smart contract function from any [Call Context](../../explanations/context.mdx).
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/state.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/state.mdx
index 3894d0a76ec..1c61ed7c5c2 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/state.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/state.mdx
@@ -55,7 +55,7 @@ state:
Starting with straightforward state variables, `totalFactor`,
and `owner` are characterized as Uint64 and AgentID, respectively.
-These represent predefined [WasmLib value types](/isc/reference/wasm-lib-data-types).
+These represent predefined [WasmLib value types](../../reference/wasm-lib-data-types.mdx).
### Arrays and Maps
@@ -173,7 +173,7 @@ export class MutableDividendState extends wasmtypes.ScProxy {
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](/isc/explanations/proxies),
+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
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/transfers.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/transfers.mdx
index ec279552b15..8e9e2447797 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/transfers.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/transfers.mdx
@@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem';
# Transfer Tokens
-The [Call Context](/isc/explanations/context) in smart contracts introduces two vital methods -
+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.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/typedefs.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/typedefs.mdx
index ab97e6eb54c..e162d586d42 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/typedefs.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/typedefs.mdx
@@ -19,11 +19,11 @@ import TabItem from '@theme/TabItem';
:::note WasmLib Types
-You can find the complete list of [WasmLib Data Types](/isc/reference/wasm-lib-data-types) in the reference section.
+You can find the complete list of [WasmLib Data Types](../../reference/wasm-lib-data-types.mdx) in the reference section.
:::
-The WasmLib allows of [container types](/isc/explanations/proxies#container-proxies), but it
+The WasmLib allows of [container types](../../explanations/proxies.mdx#container-proxies), but it
is not possible to specify these types directly because the type name syntax only allows
you to specify a single container type.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/views.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/views.mdx
index 18e2db88c1c..b9aef699f09 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/views.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/how-tos/views.mdx
@@ -26,7 +26,7 @@ All state storage accesses occur through immutable proxies, ensuring the state r
### Restricted Functionalities
-Views have a limited [Call Context](/isc/explanations/context),
+Views have a limited [Call Context](../../explanations/context.mdx),
disabling any function that might induce state changes, including token transactions.
### Intra-chain Calls
@@ -127,7 +127,7 @@ export function viewGetFactor(
The return values are passed to the caller through the predefined [Results](results.mdx) map
-associated with the [Call Context](/isc/explanations/context).
+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](usage.mdx) will generate a function-specific [Results](results.mdx)
structure with type-safe proxies to the result fields in this map.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/schema/introduction.mdx b/docs/build/isc/v1.0.0-rc.6/docs/schema/introduction.mdx
index 7efe67b03f0..de35b4c364a 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/schema/introduction.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/schema/introduction.mdx
@@ -33,11 +33,7 @@ The schema tool diminishes redundancy and ensures up-to-date functionalities.
The schema definition file serves as a single source of truth, encompassing crucial details like:
- State Storage Variables.
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/schema/introduction.mdx
- [Funcs and Views](../../explanations/context).
-========
-- [Funcs and Views](/isc/explanations/context).
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/schema/v1.0.0-rc.6/docs/introduction.mdx
- [Access rights](how-tos/access.mdx).
- [Input parameters](how-tos/params.mdx) and [output results](how-tos/results.mdx) .
- Additional Data Structures.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/deploying-sc.md b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/deploying-sc.md
index b6b9fe68247..387e4d18235 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/deploying-sc.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/deploying-sc.md
@@ -18,7 +18,7 @@ tags:
:::note WASM VM
-For more information about how to create Wasm smart contracts, refer to the [Wasm VM chapter](/isc/getting-started/languages-and-vms#wasm-vm-for-isc).
+For more information about how to create Wasm smart contracts, refer to the [Wasm VM chapter](../../getting-started/languages-and-vms.md#wasm-vm-for-isc).
:::
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/error-handling.md b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/error-handling.md
index 5cd5f55f319..40b414feedc 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/error-handling.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/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`](/isc/reference/core-contracts/blocklog) in the form of
+result of the request is stored in the chain's [`blocklog`](../../reference/core-contracts/blocklog.md) 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/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx
index 6cac50f58ba..c924b0b67fe 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx
@@ -19,18 +19,8 @@ import TabItem from '@theme/TabItem';
# Example Tests
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx
In the previous sections we showed how you can [`call()`](../../schema/how-tos/call.mdx) or
[`post()`](../../schema/how-tos/post.mdx) smart contract function requests. We also created a few wrapper
-========
-In the previous sections we showed how you can [`call()`](../wasm/call.mdx) or
-[`post()`](../wasm/post.mdx) smart contract function requests. We also created a few wrapper
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx
-========
-In the previous sections we showed how you can [`call()`](/schema/how-tos/call) or
-[`post()`](/schema/how-tos/post) smart contract function requests. We also created a few wrapper
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/solo/v1.0.0-rc.6/docs/how-tos/examples.mdx
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.
@@ -241,27 +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.
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/examples.mdx
Next we will show how to test [Views](../../schema/how-tos/views.mdx) and/or [Funcs](../../schema/how-tos/funcs.mdx) that return
a result. Note that even though Funcs are usually invoked through a [`post()`](../../schema/how-tos/post.mdx)
request, in which case any return values are inaccessible, they still can be invoked
through a [call()](../../schema/how-tos/call.mdx) from within another Func, in which these return values can
be used normally. Since solo executes [`post()`](../../schema/how-tos/post.mdx) requests synchronously, it is
-========
-Next we will show how to test [Views](../wasm/views.mdx) and/or [Funcs](../wasm/funcs.mdx) that return
-a result. Note that even though Funcs are usually invoked through a [`post()`](../wasm/post.mdx)
-request, in which case any return values are inaccessible, they still can be invoked
-through a [call()](../wasm/call.mdx) from within another Func, in which these return values can
-be used normally. Since solo executes [`post()`](../wasm/post.mdx) requests synchronously, it is
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/examples.mdx
-========
-Next we will show how to test [Views](/schema/how-tos/views) and/or [Funcs](/schema/how-tos/funcs that return
-a result. Note that even though Funcs are usually invoked through a [`post()`](/schema/how-tos/post)
-request, in which case any return values are inaccessible, they still can be invoked
-through a [call()](/schema/how-tos/call) from within another Func, in which these return values can
-be used normally. Since solo executes [`post()`](/schema/how-tos/post) requests synchronously, it is
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/solo/v1.0.0-rc.6/docs/how-tos/examples.mdx
possible to have a Func return a result and test for certain result values.
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/first-example.md b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/first-example.md
index e89e2b2fd52..f4189cee840 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/first-example.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/first-example.md
@@ -13,8 +13,8 @@ tags:
# First Example
The following is an example of a _Solo_ test. It deploys a new chain and invokes some view calls in the
-[`root`](/isc/reference/core-contracts/root) and [`governance`](/isc/reference/core-contracts/governance)
-[core contracts](/isc/reference/core-contracts/overview).
+[`root`](../../reference/core-contracts/root.md) and [`governance`](../../reference/core-contracts/governance.md)
+[core contracts](../../reference/core-contracts/overview.md).
```go
import (
@@ -81,7 +81,7 @@ The output of the test will be something like this:
:::
-The [core contracts](/isc/reference/core-contracts/overview) listed in the log are automatically deployed on each
+The [core contracts](../../reference/core-contracts/overview.md) 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/isc/v1.0.0-rc.6/docs/solo/how-tos/invoking-sc.md b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/invoking-sc.md
index bbb6520cb22..ec60f2d2cbe 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/invoking-sc.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/invoking-sc.md
@@ -1,13 +1,8 @@
---
description: Invoking smart contracts with on-ledger and off-ledger requests with Solo.
image: /img/tutorial/send_request.png
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/invoking-sc.md
tags:
- how-to
-========
-keywords:
- - how-tos
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/solo/v1.0.0-rc.6/docs/how-tos/invoking-sc.md
- explanation
- testing
- PostRequestSync
diff --git a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
index 0eaaf952949..aedbaab2e19 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
@@ -26,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](/isc/reference/wasm-lib-data-types) of these data types, and the _VM_ layer acts as a data type
+[own versions](../../reference/wasm-lib-data-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
@@ -35,33 +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.
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
With the introduction of the [Schema Tool](../../schema/how-tos/usage.mdx), we were able to remove this
-========
-With the introduction of the [Schema Tool](../wasm/usage.mdx), we were able to remove this
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/test.mdx
-========
-With the introduction of the [Schema Tool](/schema/how-tos/usage), we were able to remove this
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/solo/v1.0.0-rc.6/docs/how-tos/test.mdx
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](/isc/explanations/context) 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
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
code that the [Schema Tool](../../schema/how-tos/usage.mdx) generates when testing our smart contracts. Because
-========
-code that the [Schema Tool](../wasm/usage.mdx) generates when testing our smart contracts. Because
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/test.mdx
-========
-code that the [Schema Tool](/schema/how-tos/usage) generates when testing our smart contracts. Because
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/solo/v1.0.0-rc.6/docs/how-tos/test.mdx
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
@@ -89,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](/isc/explanations/context).
+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:
@@ -124,38 +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,
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
then use the `SoloContext` to create a [Function Descriptor](../../schema/how-tos/funcdesc.mdx) for the wrapped
function, pass any parameters through the [Params](../../schema/how-tos/params.mdx) proxy, and then either
[`post()`](../../schema/how-tos/post.mdx) the function request or [`call`](../../schema/how-tos/call.mdx) the function. Any
results returned are extracted through the descriptor's [Results](../../schema/how-tos/results.mdx) proxy, and
-========
-then use the `SoloContext` to create a [Function Descriptor](../wasm/funcdesc.mdx) for the wrapped
-function, pass any parameters through the its [Params](../wasm/params.mdx) proxy, and then either
-[`post()`](../wasm/post.mdx) the function request or [`call()`](../wasm/call.mdx) the function. Any
-results returned are extracted through the descriptor's [Results](../wasm/results.mdx) proxy, and
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/test.mdx
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](../../explanations/context.mdx) knows how to properly
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/test.mdx
[`call()`](../../schema/how-tos/call.mdx) or [`post()`](../../schema/how-tos/post.mdx) the function call through the function
-========
-[`call()`](../wasm/call.mdx) or [`post()`](../wasm/post.mdx) the function call through the function
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/test.mdx
-========
-then use the `SoloContext` to create a [Function Descriptor](/schema/how-tos/funcdesc) for the wrapped
-function, pass any parameters through the its [Params](/schema/how-tos/params) proxy, and then either
-[`post()`](/schema/how-tos/post) the function request or [`call()`](/schema/how-tos/call the function. Any
-results returned are extracted through the descriptor's [Results](/schema/how-tos/results) 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](/isc/explanations/context) knows how to properly
-[`call()`](/schema/how-tos/call) or [`post()`](/schema/how-tos/post the function call through the function
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/solo/v1.0.0-rc.6/docs/how-tos/test.mdx
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/isc/v1.0.0-rc.6/docs/solo/how-tos/the-l2-ledger.md b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/the-l2-ledger.md
index 4e4cc0d2dad..ed737dbeaed 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/the-l2-ledger.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/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`](/isc/reference/core-contracts/accounts#deposit) request to the
-[`accounts` core contract](/isc/reference/core-contracts/accounts) on the chain.
+[`deposit`](../../reference/core-contracts/accounts.md#deposit) request to the
+[`accounts` core contract](../../reference/core-contracts/accounts.md) on the chain.
-Finally, it sends a [`withdraw`](/isc/reference/core-contracts/accounts#withdraw) request to the `accounts` core
+Finally, it sends a [`withdraw`](../../reference/core-contracts/accounts.md#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/isc/v1.0.0-rc.6/docs/solo/how-tos/timelock.mdx b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/timelock.mdx
index d35f1d781f4..d30cfade07b 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/timelock.mdx
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/timelock.mdx
@@ -124,15 +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
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/timelock.mdx
-<<<<<<<< HEAD:docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/timelock.mdx
is known to [`post()`](../../schema/how-tos/post.mdx) a request to itself. Such requests are not immediately
-========
-is known to [`post()`](../wasm/post.mdx) a request to itself. Such requests are not immediately
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/solo/timelock.mdx
-========
-is known to [`post()`](/schema/how-tos/post) a request to itself. Such requests are not immediately
->>>>>>>> c1e6382878 (apply suggestions by @jlvandenhout):docs/build/solo/v1.0.0-rc.6/docs/how-tos/timelock.mdx
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/isc/v1.0.0-rc.6/docs/solo/how-tos/view-sc.md b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/view-sc.md
index b20eab77153..2bac649b39e 100644
--- a/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/view-sc.md
+++ b/docs/build/isc/v1.0.0-rc.6/docs/solo/how-tos/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](/isc/reference/core-contracts/overview) behind the scenes to retrieve the information
+the [core smart contracts](../../reference/core-contracts/overview.md) 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/schema/v1.0.0-rc.6/sidebars.js b/docs/build/schema/v1.0.0-rc.6/sidebars.js
deleted file mode 100644
index 11f3278daa7..00000000000
--- a/docs/build/schema/v1.0.0-rc.6/sidebars.js
+++ /dev/null
@@ -1,110 +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
- SchemaSidebar: [
- {
- type: 'doc',
- label: 'The Schema Tool',
- id: 'introduction',
- },
- {
- type: 'category',
- label: 'How To',
- items: [
- {
- type: 'doc',
- label: 'Create a Schema',
- id: 'how-tos/usage',
- },
- {
- type: 'doc',
- label: 'Define the State',
- id: 'how-tos/state',
- },
- {
- type: 'doc',
- label: 'Use Structured Data Types',
- id: 'how-tos/structs',
- },
- {
- type: 'doc',
- label: 'Generate Type Definitions',
- id: 'how-tos/typedefs',
- },
- {
- type: 'doc',
- label: 'Trigger Events',
- id: 'how-tos/events',
- },
- {
- type: 'doc',
- label: 'Define Functions',
- id: 'how-tos/funcs',
- },
- {
- type: 'doc',
- label: 'Limit Access',
- id: 'how-tos/access',
- },
- {
- type: 'doc',
- label: 'Define Function Parameters',
- id: 'how-tos/params',
- },
- {
- type: 'doc',
- label: 'Define Function Results',
- id: 'how-tos/results',
- },
- {
- type: 'doc',
- label: 'Use Thunk Functions',
- id: 'how-tos/thunks',
- },
- {
- type: 'doc',
- label: 'Use View-Only Functions',
- id: 'how-tos/views',
- },
- {
- type: 'doc',
- label: 'Initialize a Smart Contract',
- id: 'how-tos/init',
- },
- {
- type: 'doc',
- label: 'Transfer Tokens',
- id: 'how-tos/transfers',
- },
- {
- type: 'doc',
- label: 'Add Function Descriptors',
- id: 'how-tos/funcdesc',
- },
- {
- type: 'doc',
- label: 'Call Functions',
- id: 'how-tos/call',
- },
- {
- type: 'doc',
- label: 'Post Asynchronous Requests',
- id: 'how-tos/post',
- },
- ],
- },
- ],
-};
diff --git a/docs/build/solo/v1.0.0-rc.6/sidebars.js b/docs/build/solo/v1.0.0-rc.6/sidebars.js
deleted file mode 100644
index 103cd8e515c..00000000000
--- a/docs/build/solo/v1.0.0-rc.6/sidebars.js
+++ /dev/null
@@ -1,80 +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
- SoloSidebar: [
- {
- label: 'Getting Started',
- id: 'getting-started',
- type: 'doc',
- },
- {
- type: 'category',
- label: 'How To',
- items: [
- {
- type: 'doc',
- label: 'First Example',
- id: 'how-tos/first-example',
- },
- {
- type: 'doc',
- label: 'The L1 Ledger',
- id: 'how-tos/the-l1-ledger',
- },
- {
- type: 'doc',
- label: 'Deploy a Smart Contract',
- id: 'how-tos/deploying-sc',
- },
- {
- type: 'doc',
- label: 'Invoke a Smart Contract',
- id: 'how-tos/invoking-sc',
- },
- {
- type: 'doc',
- label: 'Call a View',
- id: 'how-tos/view-sc',
- },
- {
- type: 'doc',
- label: 'Error Handling',
- id: 'how-tos/error-handling',
- },
- {
- type: 'doc',
- label: 'Accounts',
- id: 'how-tos/the-l2-ledger',
- },
- {
- type: 'doc',
- label: 'Test Smart Contracts',
- id: 'how-tos/test',
- },
- {
- type: 'doc',
- label: 'Example Tests',
- id: 'how-tos/examples',
- },
- {
- type: 'doc',
- label: 'Colored Tokens and Time Locks',
- id: 'how-tos/timelock',
- },
- ],
- },
- ],
-};
diff --git a/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md
index 67ebfb501b1..b6273d1dd93 100644
--- a/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md
+++ b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md
@@ -20,11 +20,7 @@ You can view the chain state using the dashboard (`/wasp/dashboard` when us
## Manage Chain Configuration and Validators
You can manage the chain configuration and committee of validators by interacting with
-<<<<<<<< HEAD:docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/chain-management.md
the [Governance contract](/isc/reference/core-contracts/governance).
-========
-the [Governance contract](../../reference/core-contracts/governance.md).
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/chain-management.md
The “Chain Owner” is the only one who can perform administrative tasks.
diff --git a/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md
index c7006398725..4afeae67648 100644
--- a/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md
+++ b/docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md
@@ -83,11 +83,7 @@ From now on, all chain commands will target this chain.
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.
-<<<<<<<< HEAD:docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md
The `--block-keep-amount` parameter determines how many blocks are stored in the [`blocklog`](/isc/reference/core-contracts/blocklog) core contract.
-========
-The `--block-keep-amount` parameter determines how many blocks are stored in the [`blocklog`](../../reference/core-contracts/blocklog.md) core contract.
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/setting-up-a-chain.md
After deployment, the chain must be activated by the node operators of all peers.
@@ -99,11 +95,7 @@ wasp-cli chain activate --chain=
## Test If It Works
You can check that the chain was deployed correctly in the Wasp node dashboard (`/wasp/dashboard` when using `node-docker-setup`).
-<<<<<<<< HEAD:docs/maintain/wasp/v1.0.0-rc.6/docs/how-tos/setting-up-a-chain.md
Note that the chain was deployed with some [core contracts](/isc/reference/core-contracts/overview).
-========
-Note that the chain was deployed with some [core contracts](../../reference/core-contracts/overview.md).
->>>>>>>> 136ca6e9c8 (re-merge EVM and WASM):docs/build/isc/v1.0.0-rc.6/docs/how-tos/manage-chains/setting-up-a-chain.md
You should also have an EVM-JSONRPC server opened on:
diff --git a/static/img/evm/how-tos/ERC20/metamask-erc20-balance.png b/static/img/evm/how-tos/ERC20/metamask-erc20-balance.png
new file mode 100644
index 00000000000..b28fbcc2e71
Binary files /dev/null and b/static/img/evm/how-tos/ERC20/metamask-erc20-balance.png differ
diff --git a/static/img/evm/how-tos/ERC20/metamask-get-transaction-or-go-to-block-explorer.png b/static/img/evm/how-tos/ERC20/metamask-get-transaction-or-go-to-block-explorer.png
new file mode 100644
index 00000000000..951f4005e76
Binary files /dev/null and b/static/img/evm/how-tos/ERC20/metamask-get-transaction-or-go-to-block-explorer.png differ
diff --git a/static/img/evm/how-tos/ERC20/metamask-import-tokens.png b/static/img/evm/how-tos/ERC20/metamask-import-tokens.png
new file mode 100644
index 00000000000..65cc8c9774d
Binary files /dev/null and b/static/img/evm/how-tos/ERC20/metamask-import-tokens.png differ