Add versioned ISC docs

docs/build/isc/v1.0.0-rc.6/docs/how-tos/core-contracts/token/create-native-token.md → docs/build/isc/v1.1/docs/how-tos/core-contracts/token/create-native-token.md

@@ -14,7 +14,7 @@ import ExampleCodeIntro from '../../../_partials/how-tos/token/_example_code_int
 
 # Create a Native Token
 
-This guide will show you how you can efficiently mint new tokens and register them for use as ERC20 tokens with the `createNativeTokenFoundry` function in one seamless operation. It will create a foundry on L1 and register it as an ERC20 on L2. This method ensures that only the foundry owner can mint tokens, maintaining security and control over the token creation process.
+This guide will show you how you can efficiently mint new tokens and register them for use as ERC20 tokens with the [`createNativeTokenFoundry`](../../../reference/magic-contract/ISCAccounts.md#createnativetokenfoundry) function in one seamless operation. It will create a foundry on L1 and register it as an ERC20 on L2. This method ensures that only the foundry owner can mint tokens, maintaining security and control over the token creation process.
 
 ## About Foundries
 
@@ -27,7 +27,7 @@ The Foundry lets you specify your native token's maximum supply **once** and cha
 
 ### 2. Define the Token Scheme
 
-Define the `NativeTokenScheme` by specifying the `maximumSupply`.
+Define the [`NativeTokenScheme`](../../../reference/magic-contract/ISCTypes.md#nativetokenscheme) by specifying the `maximumSupply`.
 
 ```solidity
 NativeTokenScheme memory nativeTokenScheme = NativeTokenScheme({
@@ -39,7 +39,7 @@ NativeTokenScheme memory nativeTokenScheme = NativeTokenScheme({
 
 ### 3. Mint and Register Native Token 
 
-Minting native tokens and registering them as ERC20 tokens using `createNativeTokenFoundry` method
+Minting native tokens and registering them as ERC20 tokens using [`createNativeTokenFoundry`](../../../reference/magic-contract/ISCAccounts.md#createnativetokenfoundry) method
 
 ```solidity
 uint32 foundrySN = ISC.accounts.createNativeTokenFoundry(

docs/build/isc/v1.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/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.3-alpha/docs/_partials/how-tos/token/_obsolete_token_creation.md

@@ -0,0 +1,5 @@
+:::caution
+
+This method is now obsolete, use the new [`createNativeTokenFoundry`](../../../how-tos/core-contracts/token/create-native-token.md) method instead.
+
+:::

docs/build/isc/v1.3-alpha/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.3-alpha/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.3-alpha/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.