Add versioned ISC docs

banners/wasp_staging.mdx

@@ -0,0 +1,6 @@
+:::info
+
+This is documentation for Wasp 1.1, which is currently tested on our staging Network Shimmer.
+For up-to-date documentation, see the [latest version](/isc/introduction).
+
+:::

banners/wasp_upcoming.mdx

@@ -0,0 +1,6 @@
+:::warning
+
+This is documentation for the upcoming 1.2 Wasp version, which is currently tested on our test Networks.
+For up-to-date documentation, see the [latest version](/isc/introduction).
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_EVM-required-prior-knowledge.md

@@ -0,0 +1,14 @@
+:::note Required Prior Knowledge
+
+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/).
+
+You should also have basic knowledge on how to [create](../how-tos/create-a-basic-contract.md) and [deploy](../how-tos/deploy-a-smart-contract.mdx)
+a smart contract.
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_EVM_compatibility.md

@@ -0,0 +1,7 @@
+:::info EVM Compatibility
+
+The ISC EVM layer is also designed to be as compatible as possible with existing Ethereum
+[tools](../getting-started/tools.mdx) and functionalities. However, please make sure you have checked out the current
+[properties and limitations](../getting-started/compatibility.md).
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_about-accounts.md

@@ -0,0 +1,5 @@
+:::info Accounts in ISC
+
+Learn more about the [different types of accounts](../explanations/how-accounts-work.md).
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_deploy_a_smart_contract.md

@@ -0,0 +1,5 @@
+:::tip Deploy a Smart Contract 
+
+Deploy a Solidity Smart Contract following our [how to Deploy a Smart Contract guide](/isc/how-tos/deploy-a-smart-contract#remix).
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_network_warning.md

@@ -0,0 +1,6 @@
+:::caution Only Available on Shimmer
+
+At the moment, Smart Contracts are only available on [Shimmer](/build/networks-endpoints/#shimmer) and
+its [Public Testnet](/build/networks-endpoints/#public-testnet) network.
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_ownership.md

@@ -0,0 +1,7 @@
+:::info Ownership
+
+You might want to look into making the function ownable with, for example,
+[OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable)
+so only owners of the contract can call certain functionalities of your contract.
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_payable.md

@@ -0,0 +1,10 @@
+:::info Payable
+
+Instead of making the function payable, you could let the contract pay for the storage deposit. 
+If so, you will need to change the `require` statement to check if the contract's balance has enough funds:
+
+```solidity
+require(address(this).balance > _storageDeposit);
+```
+
+:::

docs/build/isc/v1.1-rc/docs/_admonitions/_remix-IDE.md

@@ -0,0 +1,6 @@
+:::tip Remix
+
+This guide will use the [Remix IDE](https://remix.ethereum.org/), but you can use this contract with any IDE you are
+familiar with.
+
+:::

docs/build/isc/v1.1-rc/docs/_partials/_hardhat_config.md

@@ -0,0 +1,52 @@
+import CodeBlock from '@theme/CodeBlock';
+import { Networks } from '@theme/constant';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+<Tabs groupId='network'>
+<TabItem value='shimmer_testnet' label='ShimmerEVM Testnet'>
+
+<CodeBlock language="js">
+{`
+networks: {
+    'shimmerevm-testnet': {
+        url: '${Networks['shimmer_testnet'].evm.rpcUrls[0]}',
+        chainId: ${parseInt(Networks['shimmer_testnet'].evm.chainId)},
+        accounts: [YOUR PRIVATE KEY],
+    },
+}
+`}
+</CodeBlock>
+
+</TabItem>
+<TabItem value='iota_testnet' label='IOTA EVM Testnet'>
+
+<CodeBlock language="js">
+{`
+networks: {
+    'iotaevm-testnet': {
+        url: '${Networks['iota_testnet'].evm.rpcUrls[0]}',
+        chainId: ${parseInt(Networks['iota_testnet'].evm.chainId)},
+        accounts: [YOUR PRIVATE KEY],
+    },
+}
+`}
+</CodeBlock>
+
+</TabItem>
+<TabItem value='shimmer' label='ShimmerEVM'>
+
+<CodeBlock language="js">
+{`
+networks: {
+    'shimmerevm': {
+        url: '${Networks['shimmer'].evm.rpcUrls[0]}',
+        chainId: ${parseInt(Networks['shimmer'].evm.chainId)},
+        accounts: [YOUR PRIVATE KEY],
+    },
+}
+`}
+</CodeBlock>
+
+</TabItem>
+</Tabs>

docs/build/isc/v1.1-rc/docs/_partials/_on_off_ledger_request.md

@@ -0,0 +1,13 @@
+### On-Ledger Requests
+
+An on-ledger request is a Layer 1 transaction that validator nodes retrieve from the Tangle. The Tangle acts as an
+arbiter between users and chains and guarantees that the transaction is valid, making it the only way to transfer assets
+to a chain or between chains.
+
+### Off-Ledger Requests
+
+If all necessary assets are in the chain already, it is possible to send a request directly to that chain's validator
+nodes.
+This way, you don’t have to wait for the Tangle to process the message, significantly reducing the overall confirmation
+time.
+Due to the shorter delay, off-ledger requests are preferred over on-ledger requests unless you need to deposit assets to the chain.

docs/build/isc/v1.1-rc/docs/_partials/how-tos/token/_check_storage_deposit.md

@@ -0,0 +1,10 @@
+### 1. Check the Storage Deposit
+
+Check if the amount paid to the contract is the same as the required [storage deposit](/learn/protocols/stardust/core-concepts/storage-deposit)
+   and set the allowance.
+
+```solidity
+require(msg.value == _storageDeposit*(10**12), "Please send exact funds to pay for storage deposit");
+ISCAssets memory allowance;
+allowance.baseTokens = _storageDeposit;
+```

docs/build/isc/v1.1-rc/docs/_partials/how-tos/token/_example_code_intro.md

@@ -0,0 +1,9 @@
+import Ownership from '../../../_admonitions/_ownership.md';
+import Payable from '../../../_admonitions/_payable.md';
+import CheckStorageDeposit from './_check_storage_deposit.md'
+
+<Ownership/>
+
+<CheckStorageDeposit/>
+
+<Payable/>

docs/build/isc/v1.1-rc/docs/explanations/consensus.md

@@ -0,0 +1,53 @@
+---
+description: IOTA Smart Contracts consensus is how Layer 2 validators agree to change the chain state in the same way.
+image: /img/logo/WASP_logo_dark.png
+tags:
+  - smart contracts
+  - consensus
+  - validator committee
+  - validators
+  - validator nodes
+  - explanation
+---
+
+# Consensus
+
+To update the chain, its committee must reach a _consensus_, meaning that more than two thirds of its validators have to
+agree to change the state in the exact same way.
+This prevents a single malicious node from wreaking havoc over the chain, but there are also more mundane reasons for
+individual nodes to act up.
+
+Smart contracts are deterministic. All honest nodes will produce the same output — but only if they have received the
+same input. Each validator node has its point of access to the Tangle, so it may look different to different nodes, as
+new transactions take time to propagate through the network. Validator nodes will receive smart contract requests with
+random delays in a random order, and, finally, all computers run on their own always slightly skewed clocks.
+
+## Batch Proposals
+
+As the first step, each node provides its vision, a _batch proposal_. The proposal contains a local timestamp, a list of
+unprocessed requests, and the node's partial signature of the commitment to the current state.
+
+Then the nodes must agree on which batch proposals they want to work on. In short, nodes A, B, and C have to confirm
+that they plan to work on proposals from A, B, and C, and from no one else. As long as there are more than two thirds of
+honest nodes, they will be able to find an _asynchronous common subset_ of the batch proposals. From that point, nodes
+have the same input and will produce the same result independently.
+
+## The Batch
+
+The next step is to convert the raw list of batch proposals into an actual batch. All requests from all proposals are
+counted and filtered to produce the same list of requests in the same order.
+The partial signatures of all nodes are combined into a full signature that is then fed to a pseudo-random function that
+sorts the smart contract requests.
+Validator nodes can neither affect nor predict the final order of requests in the batch. (This protects ISC
+from [MEV attacks](https://ethereum.org/en/developers/docs/mev/)).
+
+## State Anchor
+
+After agreeing on the input, each node executes every smart contract request in order, independently producing the same
+new block. Each node then crafts a state anchor, a Layer 1 transaction that proves the commitment to this new chain
+state. The timestamp for this transaction is derived from the timestamps of all batch proposals.
+
+All nodes then sign the state anchor with their partial keys and exchange these signatures. This way, every node obtains
+the same valid combined signature and the same valid anchor transaction, which means that any node can publish this
+transaction to Layer 1. In theory, nodes could publish these state anchors every time they update the state; in
+practice, they do it only every approximately ten seconds to reduce the load on the Tangle.

docs/build/isc/v1.1-rc/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.
+tags:
+  - 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.

docs/build/isc/v1.1-rc/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
+tags:
+  - 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`](../reference/core-contracts/root.md): Responsible for the initialization of the chain, maintains registry of deployed contracts.
+
+- [`accounts`](../reference/core-contracts/accounts.md): Manages the on-chain ledger of accounts.
+
+- [`blob`](../reference/core-contracts/blob.md): Responsible for the registry of binary objects of arbitrary size.
+
+- [`blocklog`](../reference/core-contracts/blocklog.md): Keeps track of the blocks and receipts of requests that were processed by the chain.
+
+- [`governance`](../reference/core-contracts/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`](../reference/core-contracts/errors.md): Keeps a map of error codes to error messages templates. These error codes are used in request receipts.
+
+- [`evm`](../reference/core-contracts/evm.md): Provides the necessary infrastructure to accept Ethereum
+  transactions and execute EVM code.