saving working state

docs/build/isc/v1.0.0-rc.6/docs/explanations/accounts-and-addresses.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 `<hname>@<chain-id>`. 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 `<hname=0>@<address zero (0x00000...)>`.
+
+### Ethereum Address
+
+An L2 account can also be owned by an Ethereum address. See [EVM](../introduction.md) 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.
+
+[![Example situation. Two chains are deployed, with three smart contracts and one address.](/img/tutorial/accounts.png)](/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.

docs/build/isc/v1.0.0-rc.6/docs/explanations/core-contracts.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
+
+![Wasp Node Core Contracts Overview](/img/banner/banner_wasp_core_contracts_overview.png)
+
+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.

docs/build/isc/v1.0.0-rc.6/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`](../reference/core-contracts/evm.md) [core contract](../reference/core-contracts/overview.md)
+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 = 10<sup>18</sup>wei), 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](../reference/core-contracts/root.md).
+
+### 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`](../reference/core-contracts/evm.md) [core contract](../reference/core-contracts/overview.md),
+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 L1's base token. The gas fee is debited from
+the sender's L2 account and must be deposited beforehand.

docs/build/isc/v1.0.0-rc.6/docs/getting-started/languages-and-vms.md

@@ -0,0 +1,87 @@
+# Supported Virtual Machines & Languages
+
+## EVM/Solidity Based Smart Contracts
+
+:::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]() 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?
+
+[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.
+
+[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 the IOTA
+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.
+
+### How IOTA Smart Contracts Work With EVM
+
+Every deployed IOTA Smart Contracts chain automatically includes a core contract
+called [`evm`](./reference/core-contracts/evm.md). 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
+tooling like [MetaMask](https://metamask.io/), [Remix](https://remix.ethereum.org/) or [Hardhat](https://hardhat.org/).
+Deploying EVM contracts is as easy as pointing your tools to the JSON-RPC endpoint.
+
+## 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).
+:::
+
+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.
+
+![Wasp node ISC Host](/img/wasm_vm/IscHost.png)
+
+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, 
+promoting security and adaptability with different programming languages.
+
+![Wasm VM](/img/wasm_vm/WasmVM.png)
+
+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.