# Welcome to Magnet A Quick Guide to Magnet ## Overview Magnet comprises two main components: Magnet Network and Magnet Stack. {% hint style="success" %} Magnet Network is the first DOT-AS-GAS chain in Polkadot, featuring support for EVM, WASM, and MoveVM. {% endhint %} {% hint style="success" %} Magnet Stack generates coretime-ready chain codes, complete with customizable functions and pallets with a user-friendly app. {% endhint %} ## Magnet Network Magnet Network strives to become Polkadot's native smart contract platform, incorporating Agile Coretime from the outset. It is also the first blockchain to utilize DOT as the gas and to support multiple VMs, including EVM, WASM, and MoveVM. ## Magnet Stack Magnet Stack is crafted to simplify the deployment of Polkadot Coretime-ready chains and initiate projects. Magnet Stack enables developers to tailor their blockchain network via a user-friendly web interface and automatically generates the corresponding node codes. ## Quick links {% content-ref url="/pages/K8h2WyfWucR2MS9h7SR0" %} [Magnet Network Features](/overview/magnet-network-features) {% endcontent-ref %} {% content-ref url="/pages/AsFnlgEVGoHblnkUu4gk" %} [Magnet Stack Features](/overview/magnet-stack-features) {% endcontent-ref %} ## Get Started We've put together some helpful guides for you to get setup with our product quickly and easily. {% content-ref url="/pages/goWD4gudPI7LSEEIsqWh" %} [Setup a Local Node](/product-guides/setup-a-local-node) {% endcontent-ref %} {% content-ref url="/pages/avCAZEUg5Q0E9EpGVsI8" %} [Deploy Contracts on Magnet Network](/product-guides/deploy-contracts-on-magnet-network) {% endcontent-ref %} {% content-ref url="/pages/sN1hvigLWC4gK77JbGkY" %} [Develop Coretime-Ready chain with Magnet Stack](/product-guides/develop-coretime-ready-chain-with-magnet-stack) {% endcontent-ref %} 🔎 For more about Magnet, head to our [website](https://magnet.magport.io/) 📢 Follow our latest updates on [Twitter](https://twitter.com/Magnet_network) 🤝 Engage with fellow developers on our [Telegram server](https://t.me/+aep298N0KXUwZTM1) 💻For more development details: [Magnet Github](https://github.com/Magport/Magnet) 🌟To give it a simple try, please visit our [demo app](https://magnet.magport.io/bridges) # Magnet Network Features {% hint style="info" %} Deploy your contract on the Magnet Network, the first DOT-AS-GAS chain of Polkadot, with support for EVM, WASM, and MoveVM. {% endhint %} ### Key Features **DOT as GAS** Utilizes DOT for all transactions and operations, eliminating the need for token conversion and enhancing the direct use of DOT within the ecosystem. **Coretime Ready** Magnet Network is built to support Polkadot's Agile Coretime from the beginning, allowing for flexible blockspace and coretime allocation based on actual usage, optimizing resource management and reducing costs. **On-demand Block Production and Coretime Ordering** Magnet's On-Demand Block Production is a system where blocks are produced only when needed, optimizing efficiency and resource usage. Coretime Ordering is controlled by two key parameters: **Price Limit** and **Price Threshold**. The **Price Limit** sets the maximum allowable price for placing orders, while the **Price Threshold** defines the price point at which certain actions are triggered, such as halting or allowing order placement. These parameters ensure that block production remains cost-effective and responsive to network demand, enabling a flexible and efficient blockchain environment. **EVM, WASM and MoveVMSupport** Supports both EVM, WASM and MoveVM environments, facilitating interaction with various smart contract platforms and enhancing developer flexibility. **Strategic Profit Mechanism** Collects gas fees, strategically leveraging price differences to generate continuous profits, which are distributed to Polkadot Treasury, System Reserves, Collator Incentives, and Project Maintenance. **Advanced Pallet System** Includes specialized pallets like the Blockspace Ordering Pallet, Profit Operator Pallet, and Blockspace/Coretime Assurance Pallet, each designed to ensure efficient transaction processing, profit calculation, and system stability. **On-demand Coretime Ordering** Dynamically produces blocks based on transaction demand. When demand is low, block production pauses to save resources. When transactions occur, Magnet orders coretime and produces blocks as needed, optimizing resource usage and ensuring efficient operation. **XCM and Asset Bridge** Facilitates seamless asset transfers and cross-chain communication within the Polkadot ecosystem using XCM (Cross-Consensus Messaging). The asset bridge allows for efficient transfer of DOT and other tokens between Substrate and EVM accounts, ensuring smooth deployment and interaction of smart contracts across different environments. For more about Magnet Network: {% content-ref url="/pages/COiz9eQF0qwWbR0PK6jp" %} [Magnet Coretime](/overview/magnet-network-features/magnet-coretime) {% endcontent-ref %} {% content-ref url="/pages/HAJ5GdhJ4bcnrzT5esjt" %} [Workflows of Magnet Network](/overview/magnet-network-features/workflows-of-magnet-network) {% endcontent-ref %} {% content-ref url="/pages/2XPTGohNYeLHLpsze7KN" %} [Profit Calcuation and Distribution](/overview/magnet-network-features/profit-calcuation-and-distribution) {% endcontent-ref %} {% content-ref url="/pages/VseMU5RZs6cxJppJufdS" %} [Coretime Order Control and Assurance](/overview/magnet-network-features/coretime-order-control-and-assurance) {% endcontent-ref %} #### Learn More For more detailed information and updates, visit our [website](https://magnet.magport.io/) and follow us on [Twitter](https://twitter.com/magnet_project). Join our [Telegram server](https://t.me/magnet_network) to engage with fellow developers and stay informed about the latest developments. # Magnet Coretime Magnet aims to implement a mechanism to dynamically purchase computing resources (core time) and trigger order logic when specific conditions are met. This plan covers modifications to both Node and Runtime parts. #### **Node part** 1. **Monitoring Relay Chain Blocks**: * Implement a monitoring task in `service.rs`, created through `task_manager`, to specifically monitor the latest best block notification of the relay chain. This task is responsible for continuously tracking updates to the Relay Chain blocks. * When a new relay chain best block is detected, in addition to obtaining relevant information through the Runtime API, you also need to query the block to see if there is an event of placing an order, and obtain the account number and fee for placing the order from the event. 2. **Check order conditions**: * Monitor new transactions in the transaction pool and accumulate gas fees for transactions to determine whether the order threshold has been reached. * If the conditions are met (for example, the gas fee of the transaction pool reaches the set value), the logic of placing an order is triggered, and the `place_order` transaction of the relay chain is constructed and submitted through RPC. 3. **Order logic**: * When the conditions are met, the Node part will construct and sign the `place_order` transaction of the relay chain and submit it to the relay chain through RPC. This step is now implemented in the Node part and is no longer called through the Runtime API, but is handled directly by the Node, including verifying whether it has the authority to place an order and whether it is the node's turn to place an order. 4. **Carry proof information when generating a block**: * Collator contains inherited data when generating blocks and carries proof information for placing orders, which is used for verification when synchronizing blocks in parallel chains. **Runtime part** 1. **Runtime API**: * The Runtime API now mainly supports the recording and query functions of order information, including obtaining the last scheduled relaychain block height and hash value, bid information, etc. The `buyCore` function has been removed, and this logic is directly implemented by the Node part. 2. **Pallet modification**: * The definition of the order structure remains unchanged, containing necessary order information such as order number, relay chain block hash, height, orderer, price, etc. * Storage items also include order serial numbers, order list, current orderer, relaychain block information, bid, etc. * Implement the `on_initialize` method to update the order status at the beginning of each block. The checking of order conditions and execution of order operations have been moved to the Node part. 3. **New features of Order Pallet**: * **Verify inherited**: Verify the validity of the order. * **Query Interface**: Provides a query interface, such as querying the order information in the relaychain block, the order threshold of the trading pool, etc. * **Parameter Settings**: Allows you to set the block interval for placing orders and the order threshold for the trading pool. After adjustment, this comprehensive design plan more accurately reflects the mechanism for dynamically purchasing computing resources in the Node part, as well as the division of responsibilities for processing order information recording and querying in the Runtime part. This design ensures that the parachain can efficiently and safely execute order logic based on the latest block information of the relay chain and the status of the transaction pool while maintaining the flexibility and scalability of the system. # Coretime Order Control and Assurance {% hint style="info" %} Coretime order control and assurance functions are for on-demand coretime only. {% endhint %} #### Coretime Orders and Price Control **Price Limit:**\ The Price Limit is a parameter that sets the maximum allowable price for coretime orders. This limit ensures that users are protected from excessive costs, particularly during periods of high demand or network congestion. **Price Threshold:**\ The Price Threshold controls profitability from gas collection. $$ \text{Price Threshold} = \frac{\text{Gas Fee Collected}}{\text{Coretime Price}} $$ For example, a threshold of 0.7 means that the total gas fee collection equals 70% of the real-time on-demand coretime price, implying that a 30% loss is acceptable; a threshold of 1.6 means that the total gas fee collection equals 160% of the real-time on-demand coretime price, implying that a 60% profit is required. **Coretime Workflow：**In the on-demand model, the system first checks if the current core time price is within the user-configured price limit (setting price limit = 0 disables this check). If the price exceeds the limit and Assurance is disabled, the system continuously checks until the core time price is within the limit. It then compares the gas fee with the core time cost: if (gas fee collected / core time price) > price threshold, it purchases core time; otherwise, it waits until both conditions are met. If Assurance is enabled and any condition is not met, the assurance pallet checks the difference between the current block number of the relay chain and last bid block number. If the difference is bigger than “bid threshold”, then Assurance pallet calls create\_order function to place order. #### **Assurance Mechanism in Magnet** Magnet’s Assurance mechanism is designed to ensure the reliability and execution of coretime orders, providing a safeguard against disruptions in block production. In cases where coretime order placement is halted by the order control mechanisms (Price Limit & Price Threshold) for an extended period, the Assurance mechanism steps in. If the halt persists beyond the defined bid threshold—measured in relay chain blocks—this function forces the placement of the coretime order, ensuring that block production continues uninterrupted. For example, if the bid threshold is set to 8 relay chain blocks, the Assurance mechanism allows the system to pause on-demand order placement for up to 8 blocks if the Price Limit and Price Threshold conditions are not met. Beyond this threshold, the Assurance mechanism intervenes to guarantee that orders are placed and the network remains stable. # Workflows of Magnet Network

workflow of Magnet Network

1\. The node monitors the latest block of the relay chain and retrieves the storage state root of the relay chain block. It then calls the order pallet to obtain the OnDemandOrderPlaced event within it, aiming to determine whether an order has been placed, who placed it, and the actual price. 2\. When transaction information is generated, the system initially checks for available coretime. If none is found, it proceeds to enter the order process. 3\. A double check is conducted to determine if the coretime price threshold or the time threshold has been reached. If either condition is met, a coretime purchase will be initiated. 4\. Once the coretime event information indicates that coretime has been obtained, the process transitions to the block packaging phase. At the same time, coretime order information is recorded and the block will be submitted to the relaychain for block verification. 5\. The block is synchronized with other nodes, and these nodes verify the block information. Upon successful verification, the block generation is considered complete. **Workflow of TXs generation**

Workflow of TXs generation

1. When users have sufficient DOT as Gas fees in the Magnet EVM, they can directly deploy contracts or initiate transactions using the Magnet EVM. 2. If users do not have enough DOT for gas fees in the Magnet EVM, but have sufficient DOT in their Magnet Substrate account, they can perform an Asset Bridge operation to transfer DOT to the Magnet EVM. 3. Before bridging, an account binding must be performed. This step prepares for the bridge of Token assets (other than DOT). 4. After account binding, users can transfer DOT between the substrate account and the EVM account via the Asset Bridge for subsequent operations. 5. If users have no DOT in Magnet, they need to transfer DOT to their Magnet Substrate account via XCM, after which they can continue with their operations. # Profit Calcuation and Distribution #### Module goals and functions This module is designed to automatically settlement and distribution of Gas fee income. It ensures transparency and fairness in the network's finances by tracking every transaction and fee in detail. #### Function introduction * **Automatic Income and Expenditure Settlement**: This module can automatically track and calculate all income and expenses within the network. Revenue mainly comes from Gas fees paid by users, while expenditures include the purchase of computing resources, etc. * **Detailed Information Tracking**: In order to ensure the transparency of financial management, this module provides an interface for querying the detailed information of each computing resource purchase, such as buyer, cost, etc. * **Profit Calculation and Distribution**: Based on the total income and total expenditure in each period (Era), the net profit is calculated and distributed to the system reserves, relay chain treasury, operating reserves and network maintainers according to established rules ( Collators). #### Operation flow 1. **Income Calculation**: The system will count the Gas fees generated by each block as income. 2. **Expenditure Calculation**: At the same time, the system will calculate all expenses incurred when purchasing computing resources as expenses. 3. **Profit Settlement**: At the end of each Era, the system will automatically calculate the total income of the period minus the total expenses to obtain the net profit. 4. **Profit Distribution**: If the net profit is positive, it will be distributed to the system reserve, relay chain treasury, operating reserve and Collators according to the predetermined proportion. If the net profit is negative, the corresponding amount is deducted from the system reserve. ### Income and expenditure calculation formula 1. **Total income calculation**: Total revenue is made up of the sum of gas fees for all blocks in the network. If we express the Gas fee generated by each block as (Gas\_{block}), then the total income (Total\_Income) within a period of time (one Era) can be expressed as:\ \ $$TotalIncome = \sum\_{i=1}^{N} GasBlock\_i$$\ \ Among them, (N) represents the total number of blocks in the period. 2. **Total expenditure calculation**: The total expenditure mainly includes the purchase cost of computing resources (Coretime). If the cost of each purchase of computing resources is expressed as (Coretime\_Cost), then the total expenditure (Total\_Cost) in the period can be expressed as\ \ $$TotalCost = \sum\_{j=1}^{M} CoretimeCost\_j$$\ \ Among them, (M) represents the number of computing resource purchases during this period. 3. **Total profit calculation**: Total profit (Total\_Profit) for the period is total revenue minus total expenses:
$$TotalProfit = TotalIncome - TotalCost$$ ### Profit distribution strategy When the calculated total profit (Total\_Profit) is greater than 0, it will be distributed to the following parties according to a predetermined proportion: 1. **System Reserve**: As a guarantee for network operation, it is used to cover unforeseen expenditures or negative profit situations. 2. **Relaychain\_Treasury**: Supports the development of the entire network ecosystem and funds important public projects and proposals. 3. **Operation Reserve**: Ensure the daily operation and maintenance of the network. 4. **Collators Incentive**: Corresponding rewards will be given to Collators based on their contribution in maintaining network stability and processing transactions. The specific distribution ratio of profits can be adjusted according to network governance decisions. If (Total\_Profit) is less than or equal to 0, that is, the network operation is in a loss state, and the corresponding amount will be deducted from the system reserve to cover the loss. ### Cost return mechanism For users who participate in the purchase of computing resources (Coretime\_Buyer), if there is residual profit, a portion of the fee will be returned in proportion to the purchase cost. ### Advantages and Value * **Transparency**: Through open calculation formulas and automated processes, all participants can clearly understand the specific situation of income and expenditure settlement and profit distribution. * **Efficiency**: Automated processing reduces the need for manual operations and improves the efficiency of financial management. * **Fairness**: Profit distribution is based on open and transparent rules and calculation formulas, ensuring that participants receive fair returns based on their contributions. By introducing this module, the network is not only able to effectively manage its financial status, but also motivates network participants to actively contribute and jointly promote the healthy development of the blockchain network. # Magnet Stack Features {% hint style="info" %} Generate Coretime-ready node codes with custom pallets and functions using Magnet Stack. {% endhint %} ### Key Features #### User-Friendly Interface Magnet Stack enhances the user experience with a user-friendly interface, making blockchain development for core-time ready parachains more accessible and efficient for developers of all skill levels. #### Agile Coretime Magnet Stack supports two types of Coretime functionalities, on-demand and Bulk, optimizing resource management and providing flexibility in blockchain architecture. On-demand coretime mode also supports on-demand block production and assurance mechanisms to further increase resource efficiency and stability. #### Multi-VM Support Magnet Stack leverages Substrate's robust framework to support multiple virtual machines, including EVM, WASM and MoveVM, enabling developers to run and interact with various smart contract environments. #### Customizable Functionalities Magnet Stack provides customizable templates for various functionalities, allowing users to tailor their blockchain network to meet specific needs. This layer includes pre-built modules that can be easily integrated into your project, saving development time and effort. #### Appchain Model The Appchain Model offers flexibility with support for multiple models, including parathread and Tanssi-container chains. This allows developers to choose the best architecture for their specific use case. #### Dynamic Generator The Dynamic Generator facilitates the one-click generation of Substrate code for customized features, simplifying the node deployment process. This feature enables developers to quickly create and deploy nodes with the required specifications.

Magnet Stack Layers

Learn More {% content-ref url="/pages/d7lyql3d67jqK6MwcFK5" %} [Magnet Stack Coretime Modules](/overview/magnet-stack-features/magnet-stack-coretime-modules) {% endcontent-ref %} Start now with Magnet Stack APP, also please refer this section: {% content-ref url="/pages/sN1hvigLWC4gK77JbGkY" %} [Develop Coretime-Ready chain with Magnet Stack](/product-guides/develop-coretime-ready-chain-with-magnet-stack) {% endcontent-ref %} # Magnet Stack Coretime Modules Implementation and Workflow In Magnet Stack, developers have the option to select either the On-demand or Bulk coretime module, depending on their business needs. ### On-demand Coretime Module: On-demand coretime orders are placed immediately if the profit control conditions are met. **Profit Control Mechanism:** * Price Limit: Ensures coretime price per block does not exceed a predefined limit. * Price Threshold (Profit Control): Allows developers to set a target threshold for gas fees in relation to coretime prices ( $$\frac{\text{gas fee collected}}{\text{coretime price}}$$ ). For instance, setting the threshold to 1 means the gas fee matches the coretime price, a value above 1 indicates a profit, and a value below 1 (e.g., 0.7) indicates an acceptable loss. **Assurance Mechanism** When the on-demand coretime order is paused by profit control beyond the bid threshold set by developers, the assurance mechanism triggers the use of reserve funds to order the necessary blockspace. This prevents excessive waiting times and guarantees timely transaction processing. The system continuously monitors transaction pool gas, coretime prices, and block intervals, activating the assurance mechanism as needed to maintain smooth network operations and financial stability. ### Bulk Coretime Order Module: Coretime order requests are fulfilled through bulk purchases or via Lastic if available.（future steps）
### Magnet Stack Coretime Workflow： \ **On-Demand mode:** The system first checks if the current coretime price is within the user-configured price limit (the price limit is zero by default indicating no limit) 1. If Assurance function is disabled, the system will keep checking until the the coretime pirce is within limit. When the coretime price is within list, the following criteria determine whether gas fees justify the coretime expense: * If $$\frac{\text{gas fee collected}}{\text{coretime price}} \geq \text{price threshold}$$, coretime order will be placed; * if $$\frac{\text{gas fee collected}}{\text{coretime price}} \leq \text{price threshold},$$ then keep waiting, until both conditions are met. 2. In the enabled state of the assurances pallet, if the bid threshold (time threshold) is exceeded, then `create_order` function will be called to place coretime order
# Setup a Local Node Preparations This guide will assist you in setup local nodes for Magnet Network. Before starting Magnet, please complete the following preparation steps: {% content-ref url="/pages/a0YSKMoEbW5FUSPPRhAU" %} [Installing Substrate Dependencies](/product-guides/setup-a-local-node/installing-substrate-dependencies) {% endcontent-ref %} {% content-ref url="/pages/jOV9Q4Qvf1pALHw53YE4" %} [Launching the Local Relay Chain](/product-guides/setup-a-local-node/launching-the-local-relay-chain) {% endcontent-ref %} If you have done these prepareations, please procceed to: {% content-ref url="/pages/zQaGIT72BkRihRxH8cRb" %} [Build the Magnet Node](/product-guides/setup-a-local-node/build-the-magnet-node) {% endcontent-ref %} # Installing Substrate Dependencies **Installing Substrate Dependencies** Substrate is a modular framework that enables you to create purpose-built blockchains by composing custom or pre-built components. Below is a markdown document that you can use as a template for creating a guide on installing Substrate dependencies. #### **1. Install Rust** Substrate is developed using Rust; hence, Rust is a prerequisite for Substrate. Install Rust using rustup by running the following command in your terminal: ``` curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` After completing the installation, restart your terminal and run: ``` source $HOME/.cargo/env ``` Or, add the following line to your shell profile file (e.g., `~/.bashrc` or `~/.zshrc`): ``` export PATH=$HOME/.cargo/bin:$PATH ``` **Update Rust** Keep your Rust installation up to date by running: ``` rustup update ``` #### **2. Install Additional Libraries** Substrate has several library dependencies. Install them using the appropriate commands for your operating system: **For Ubuntu** ``` sudo apt update sudo apt install -y cmake pkg-config libssl-dev git build-essential clang libclang-dev ``` **For macOS** ``` brew install cmake pkg-config openssl git llvm ``` #### **3. Install Substrate** With Rust and the necessary libraries installed, proceed to install Substrate: ``` curl https://getsubstrate.io -sSf | bash -s -- --fast ``` #### **4. Verify Installation** Check your Substrate installation by running: ``` substrate --version ``` This command should output the installed Substrate version. #### **5. Configure Rust Toolchain** Configure the Rust toolchain for Substrate by running: ``` rustup default nightly rustup target add wasm32-unknown-unknown --toolchain nightly ``` **Completion** At this point, you should have a working Substrate development environment. Regularly check for updates and keep your installations current by running `rustup update` and `cargo update`. Remember to replace the placeholder text with the actual content, and feel free to modify the structure and formatting to suit your preferences and requirements. # Launching the Local Relay Chain {% hint style="info" %} Magnet need a proper Substrate development environment to start. If you need a refresher setting up your Substrate environment, see [Substrate's Getting Started Guide](https://substrate.dev/docs/en/knowledgebase/getting-started/). {% endhint %} Using the [`custom-spec-raw.json`](https://docs.substrate.io/assets/tutorials/relay-chain-specs/raw-local-chainspec.json/) file provided by substrate. 1. **Build the relay chain node** Clone the most recent release branch of the Polkadot repository to prepare a stable working environment. ``` git clone --branch release-v1.1.0 https://github.com/paritytech/polkadot-sdk.git ``` Change to the root of the polkadot directory by running the following command: ``` cd polkadot ``` Build the relay chain node by running the following command: ``` cargo build --release ``` Compiling the node can take 15 to 60 minuets to complete. Verify the node built correctly by running the following command: ``` ./target/release/polkadot --help ``` If command-line help is displayed, the node is ready to configure. 2. **Create the First Node** ``` nohup ./target/release/polkadot --alice --validator --chain custom-spec-raw.json --port 30333 --rpc-port 9944 --rpc-cors all --unsafe-rpc-external >alice.log 2>&1 & ``` 3. **Create the Second Node** ``` nohup ./target/release/polkadot --bob --validator --chain custom-spec-raw.json --port 30334 --rpc- ``` # Build the Magnet Node **1. Build the Magnet Node from Source Code** This method involves cloning the Magnet project repository from GitHub and compiling the project using Cargo, the package manager and build tool for Rust. Follow these steps: ``` # Clone the repository git clone https://github.com/Magport/Magnet.git # Navigate to the project directory cd Magnet # Build the project using Cargo cargo build --release ``` Compiling the node may take about 30 minutes to complete, depending on your system's performance. **2. Run the Pre-Compiled Executable from GitHub** If you prefer not to build from source, you can directly download the pre-compiled executable file of the Magnet node from GitHub. This is usually faster as it bypasses the compilation process. Follow these steps: a. Visit the Magnet project's GitHub releases page: [Magnet Releases](https://github.com/Magport/Magnet/releases) . b. Select the latest version and download the pre-compiled executable suitable for your operating system. c. After downloading, you may need to grant execution permissions to the file, depending on your operating system. On Linux or macOS, you can use the following command: ``` chmod +x magnet_executable # Replace with the actual name of the downloaded file ``` d. Run the executable to start the Magnet node: ``` ./magnet_executable # Replace with the actual name of the downloaded file ``` **3. Create a new `paraid` in the browser** * a. Click on `network`, select `parachains`. ![](https://doc.magport.io/~gitbook/image?url=https%3A%2F%2Fmagnet-2.gitbook.io%2F%7Egitbook%2Fimage%3Furl%3Dhttps%3A%252F%252Fgithub.com%252Fy19818%252FMagnet%252Fblob%252Fmain%252FImg%252F1a.png%26width%3D300%26dpr%3D4%26quality%3D100%26sign%3D26f799af5cadbabfd62c72a556d131d3644c325597cc25918570fa45490e85fc\&width=300\&dpr=4\&quality=100\&sign=f26f8122\&sv=1) * b. Click on `parathreads`, click on `paraid`. ![](https://doc.magport.io/~gitbook/image?url=https%3A%2F%2Fmagnet-2.gitbook.io%2F%7Egitbook%2Fimage%3Furl%3Dhttps%3A%252F%252Fgithub.com%252Fy19818%252FMagnet%252Fblob%252Fmain%252FImg%252F1b.png%26width%3D300%26dpr%3D4%26quality%3D100%26sign%3Df8f76e8d3e4b33abbe03907ff848f2c0b725493096f1eaa0106c7662389a94cc\&width=300\&dpr=4\&quality=100\&sign=38878cab\&sv=1) * c. Choose an account and submit. * d. The registered `paraid` for this session is 2000. **4. Modify the Default Chain Specification** * a. Generate the default chain specification: ``` ./target/release/parachain-magnet-node build-spec --disable-default-bootnode >magnet-2000.json ``` Modify the `magnet-2000.json` file, change `para_id` to 2000 and `parachainid` to 2000. * b. Convert the spec file to a raw file: ``` ./target/release/parachain-magnet-node build-spec --disable-default-bootnode --chain magnet-2000.json --raw>raw-magn ``` # Prepare the parachain Collator {% hint style="info" %} ### Prepare the parachain collator With the local relay chain running and the raw chain specification for the parachain template updated, you are ready to start the parachain collator node and export information about its runtime and genesis state. {% endhint %} 1. Export the WebAssembly runtime for the parachain. (We continue to use Magnet as an example for this session.) The relay chain needs the parachain-specific runtime validation logic to validate parachain blocks. You can export the WebAssembly runtime for a parachain collator node by running the following command: ``` ./target/release/parachain-magnet-node export-genesis-wasm --chain raw-magnet-2000.json magnet-2000-wasm ``` 2. Generate a parachain genesis state. To register a parachain, the relay chain needs to know the genesis state of the parachain. You can export the entire genesis state—hex-encoded—to a file by running the following command: ``` ./target/release/parachain-magnet-node export-genesis-state --chain raw-magnet-2000.json magnet-2000-state ``` You should note that the runtime and state you export must be for the genesis block. You can't connect a parachain with any previous state to a relay chain. All parachains must start from block 0 on the relay chain. 3. Start the collator node: ``` nohup ./target/release/parachain-magnet-node --alice --collator --force-authoring --chain raw-magnet-2000.json --base-path ./alice --p ``` # Register on the Local Relay Chain **Register on the Local Relay Chain** * a. Open the browser, click on `Developer`, select `Sudo`. ![](https://doc.magport.io/~gitbook/image?url=https%3A%2F%2Fmagnet-2.gitbook.io%2F%7Egitbook%2Fimage%3Furl%3Dhttps%3A%252F%252Fgithub.com%252Fy19818%252FMagnet%252Fblob%252Fmain%252FImg%252F4a.png%26width%3D300%26dpr%3D4%26quality%3D100%26sign%3Deaeb447f8a5af08ca8e643726423cf954a0dbbdafa66383ec5f5eff16f624680\&width=300\&dpr=4\&quality=100\&sign=5f29c0e8\&sv=1) * b. On the left, select `paraSudoWrapper`, on the right, select `sudoScheduleParaInitialize(id,genesis)`. ![](https://doc.magport.io/~gitbook/image?url=https%3A%2F%2Fmagnet-2.gitbook.io%2F%7Egitbook%2Fimage%3Furl%3Dhttps%3A%252F%252Fgithub.com%252Fy19818%252FMagnet%252Fblob%252Fmain%252FImg%252F4b.png%26width%3D300%26dpr%3D4%26quality%3D100%26sign%3Daf50e204ca721f5a1f34e95f3c58494eeb9bbb94897c50914b57ba95e07f8e48\&width=300\&dpr=4\&quality=100\&sign=8546b63e\&sv=1) ![](https://doc.magport.io/~gitbook/image?url=https%3A%2F%2Fmagnet-2.gitbook.io%2F%7Egitbook%2Fimage%3Furl%3Dhttps%3A%252F%252Fgithub.com%252Fy19818%252FMagnet%252Fblob%252Fmain%252FImg%252F4b2.png%26width%3D300%26dpr%3D4%26quality%3D100%26sign%3D65cf75c5e9def86dddf5561330de2a531471a6354c14bf91e9ff31c7d3861608\&width=300\&dpr=4\&quality=100\&sign=1e487f26\&sv=1) * c. For `id`, enter 2000. For `genesisHead`, choose file upload and upload the genesis file `para-2000-genesis-state` generated in the steps above. For `ValidationCode`, choose file upload and upload the file `para-2000-wasm` generated above. For `paraKind`, select yes. ![](https://doc.magport.io/~gitbook/image?url=https%3A%2F%2Fmagnet-2.gitbook.io%2F%7Egitbook%2Fimage%3Furl%3Dhttps%3A%252F%252Fgithub.com%252Fy19818%252FMagnet%252Fblob%252Fmain%252FImg%252F4c.png%26width%3D300%26dpr%3D4%26quality%3D100%26sign%3Df8283f163084fc5a8fe0925f576781a826efe5b077da4f4fc151430a82b46e10\&width=300\&dpr=4\&quality=100\&sign=45b71cf5\&sv=1) Click `submit`, followed by `sign and submit`. Then, check the explorer to verify that the parachain is syncing with the relay chain. ![](https://doc.magport.io/~gitbook/image?url=https%3A%2F%2Fmagnet-2.gitbook.io%2F%7Egitbook%2Fimage%3Furl%3Dhttps%3A%252F%252Fgithub.com%252Fy19818%252FMagnet%252Fblob%252Fmain%252FImg%252F5.png%26width%3D300%26dpr%3D4%26quality%3D100%26sign%3D5d35323907865ccf49ad133dead5dd7266cd2fbad6d03b67ea1a055985eef071\&width=300\&dpr=4\&quality=100\&sign=c870446c\&sv=1) **Test Parachain Block Production** Using polkadot.js, connect to port 8844, initiate a transfer, and verify that blocks are generated as expected. # Deploy Contracts on Magnet Network The Magnet testnet is currently connected to Rococo with Agile Coretime. You can check the status of the Magnet testnet by following the provided link: {% embed url="" %} Magnet Testnet {% endembed %} Information for contract deployment on Magnet Testnet Chain ID: Token Symbol: DOT RPC: WS: Faucet： {% content-ref url="/pages/NATp1kFJjPWrWfM9Cfbh" %} [EVM Contract Deployment](/product-guides/deploy-contracts-on-magnet-network/evm-contract-deployment) {% endcontent-ref %} {% content-ref url="/pages/rHOJX8ZR6du0URfDJEd1" %} [WASM Contract Deployment](/product-guides/deploy-contracts-on-magnet-network/wasm-contract-deployment) {% endcontent-ref %} {% content-ref url="/pages/jSH2fmqtZLdJy6QdbRce" %} [MoveVM Contract Deployment](/product-guides/deploy-contracts-on-magnet-network/movevm-contract-deployment) {% endcontent-ref %} # EVM Contract Deployment ### Deploying a Standard ERC20 Contract This document outlines the steps to deploy a standard ERC20 contract using your preferred tooling. #### **Step 1: Choose a Standard ERC20 Contract** Several readily available standard ERC20 contracts exist online. Choose one based on your specific needs and security considerations. #### **Step 2: Compile the Contract** Once you have chosen a contract, compile it using the relevant compiler and settings. This may involve using tools like Solidity compiler or Remix. #### **Step 3: Deploy the Contract** 1. Select the "Deploy & Run Transaction" button. This button is typically located at the bottom of the left toolbar in your development environment. 2. Choose "WalletConnect" as the connection method. 3. Connect your Metamask wallet to WalletConnect or Injected Provider . 4. Metamask is connected to the magnet network. If you need to deploy a contract on the tanssi network, you only need to change the URL to the corresponding port in metamask or other wallets. 5. This will allow you to sign the transaction and pay the gas fees. 6. Review the transaction details and confirm the deployment. #### **Step 4: Add Contract Address to Metamask** 1. Copy the deployed contract address. 2. Open Metamask and click the "Add Token" button. 3. Select "Custom Token" and paste the contract address. 4. Metamask will automatically fetch the token details and display them. 5. Click "Next" and then "Add Tokens" to confirm. #### **Step 5: Verify Token Existence** Once you have added the contract address to Metamask, your ERC20 tokens will be visible in your wallet. You can verify their existence by exploring your token balance and interacting with the contract through its functions. **Additional Notes:** * This is a general guide, and the specific steps may vary depending on your chosen tools and contract implementation. * Before deploying the contract, ensure you have sufficient DOT in your Metamask wallet to cover the gas fees. * Remember to securely store your private key and handle your tokens responsibly. # WASM Contract Deployment #### Smart Contract Runtime Environment Magnet runtimes are based on Substrate, incorporate `pallet-contracts`, a sandboxed environment used to deploy and execute WebAssembly smart contracts. Any language that compiles to Wasm may be deployed and run on this Wasm Virtual Machine, however, the code should be compatible with the `pallet-contracts` [API](https://docs.rs/pallet-contracts/latest/pallet_contracts/api_doc/trait.Current.html). To avoid unnecessary complexity, and writing boilerplate code, the most appropriate method of building will involve the use of an eDSL specifically targeting `pallet-contracts`, such as \[ink!] (based on Rust), or \[ask!] (based on AssemblyScript), or possibly others as the ecosystem grows. After compilation, a Wasm blob can then be deployed and stored on-chain. **Execution Engine** Pallet-contracts uses [wasmi](https://github.com/paritytech/wasmi) as a Wasm interpreter to execute Wasm smart contract blobs. Although there is a faster JIT interpreter such as [wasmtime](https://github.com/bytecodealliance/wasmtime) available in the native runtime, smart contracts are an untrusted environment which require a higher degree of correctness of interpretation, which makes wasmi a more suitable option. **Two-step Deployment of Contracts** The contract code (Wasm blob), and contract address and storage are decoupled from one another other, so require two steps to deploy a new contract on-chain:
1. First, upload the Wasm contract on-chain (every contract Wasm code has a `code_hash` as an identifier). 2. Second, instantiate the contract - it will create an address and storage for that contract. 3. Anyone can instantiate a contract based on its `code_hash`. There are several benefits of decoupling the contract code from the address/storage: * To save space on-chain. Since a contract can have several constructors and instantiations, a redeployment will create a new instance based on the same underlying code. Think about standardized tokens, that will have one `code_hash` & `blob` living on-chain, and as many instantiations as are needed, rather than having to upload code with each new instantiation (for example, on Ethereum). * To instantiate a new contract using code within an existing smart contract (see the delegator example), `code_hash` is all that is needed. * Some standard contracts will only be uploaded on-chain once, preventing users from having to pay gas costs for uploading new code. * Update contract code for an address: replace the contract code at the specified address with new code. Storage and balances will be preserved. # MoveVM Contract Deployment # Bridge Asset Magnet's Asset Bridge facilitates the transfer of assets between EVM and Substrate accounts, as well as the movement of assets across Polkadot's ecosystem using XCM. {% content-ref url="/pages/9ptPht4UDKMudD8UPyMB" %} [Bridging Asset between EVM and Substrate](/product-guides/bridge-asset/bridging-asset-between-evm-and-substrate) {% endcontent-ref %} {% content-ref url="/pages/uhZKhr6f9IFbmwj3DlZ5" %} [Bridging Asset with XCM](/product-guides/bridge-asset/bridging-asset-with-xcm) {% endcontent-ref %} # Bridging Asset between EVM and Substrate # Bridging Asset with XCM # Develop Coretime-Ready chain with Magnet Stack This guide will assist you in using Magnet Stack to generate node codes for coretime-ready parachains. Before utilizing Magnet Stack for your chain code generation, please complete the following preparation steps: {% content-ref url="/pages/4kP7fzhG2mLN8D05sqC0" %} [Preparation: Reserve a ParaID](/product-guides/develop-coretime-ready-chain-with-magnet-stack/preparation-reserve-a-paraid) {% endcontent-ref %} {% content-ref url="/pages/BnE2IImuqmP0a05zxMp1" %} [Define the collator's address](/product-guides/develop-coretime-ready-chain-with-magnet-stack/deployment-and-connection-to-rocococ/define-the-collators-address) {% endcontent-ref %} {% content-ref url="/pages/8ukePS1VZaxPR6mQzGRf" %} [Preparation: Purchase Bulk Core](/product-guides/develop-coretime-ready-chain-with-magnet-stack/preparation-purchase-bulk-core) {% endcontent-ref %} If the preparations are complete, please continue to the following step: {% content-ref url="/pages/AYOeSxtTS5IRSK9TcNoD" %} [Using Magnet Stack : Coretime Configuration](/product-guides/develop-coretime-ready-chain-with-magnet-stack/using-magnet-stack-coretime-configuration) {% endcontent-ref %} # Preparation: Reserve a ParaID The ParaID (Parachain ID) is a unique identifier for a parachain or parathread on the Polkadot, Rococo, or Kusama networks. To reserve a ParaID, follow these steps: {% hint style="info" %} [Polkadot-JS](https://polkadot.js.org/) comprises a suite of tools that interface with the Polkadot blockchain, its parachains, and testnets such as Rococo in detail. If you are new to Polkadot, referring to this [guide ](https://wiki.polkadot.network/docs/learn-polkadot-js-guides)is recommended. {% endhint %} 1\. [**Open Polkadot-js APP**](https://polkadot.js.org/apps/#/explorer)**:** Navigate to the Network tab. 2\. **Select Parachains**: Choose "Parathreads" and then click on "ParaID."

Polkadot JS APP Interface

3\. **Submit a Request:** Choose an account and submit your request.
**Note:** \- A deposit is required to reserve your ParaID. \- For Rococo testnet: The deposit amount is 40 ROC, you may visit the [Polkadot Faucet](https://faucet.polkadot.io/rococo) to get ROCs as test token. \- For Kusama and Polkadot: The deposit amount 40 KSM / 100 DOT respectively. \ Once you have reserved your ParaID, you can start using Magnet Stack. # Preparation: Generate the Collator's Address Collator's address can be input with Magnet stack and writeen into default configation file for your parachain template. You can manually define the collator's address by specifying a custom key pair when starting the node. To generate a key pair using the Substrate CLI, you can use the `subkey` utility that comes with Substrate. Here’s how you can do it: #### Steps to Generate a Key Pair 1. **Install Subkey** (if not already installed): * If you have Substrate installed, you already have `subkey`. If not, you can install it using the following command: ```bash cargo install --force subkey ``` 2. **Generate a Key Pair**: * Run the following command to generate a new key pair: ```bash subkey generate ``` * This will output something like: ```plaintext Secret phrase `seed phrase here` is account: Secret seed: 0x... Public key (hex): 0x... Account ID: 0x... SS58 Address: 5... ``` * The `Secret phrase` is your mnemonic seed phrase, which you can use to regenerate the keys. The `SS58 Address` is the public address derived from the public key. 3. **Generate a Key Pair for a Specific Network**: * If you want to generate a key pair for a specific network like Polkadot or Kusama, you can add the network option: ```bash subkey generate --network polkadot ``` * This ensures that the generated address is compatible with the specific network’s format. 4. **Specify a Custom Seed Phrase**: * If you want to generate a key pair from a specific seed phrase, you can use: ```bash subkey inspect "" ``` * This will output the corresponding public key and address for that seed phrase. 5. **Get a Key Pair for Specific Cryptography Type**: * Subkey supports various cryptography types, such as `sr25519` (default), `ed25519`, and `ecdsa`. You can specify one using: ```bash subkey generate --scheme sr25519 ``` #### Example Output ```plaintext Secret phrase `crisp judge talk palm tent confirm salad lunar stomach inspire brain jaguar` is account: Secret seed: 0x9245...f66a Public key (hex): 0x4b9a...d019 Account ID: 0x4b9a...d019 SS58 Address: 5EYCAe5LC5G... ``` #### Saving the Keys * You can save the secret seed and public key to a file for later use. Ensure that the seed phrase or secret seed is stored securely, as it provides full control over the corresponding account. By following these steps, you can generate key pairs for your Substrate-based projects or networks, which you can use for collators, validators, or any other accounts on the network. # Preparation: Purchase Bulk Core To **simplify your Coretime purchasing process**, we recommend that you **purchase and manage Coretime directly** from [Lastic](https://www.lastic.xyz/kusama/bulkcore1). # Using Magnet Stack : Coretime Configuration Step 1: Coretime and basic information configuration Open the Magnet Stack app and select your desired coretime type using the button at the top.
{% hint style="info" %} Magnet's on-demand coretime mode includes on-demand block production. If no transactions occur, block production will be halted. {% endhint %} **Basic Information:** \- Input the name of your chain and the ParaID you reserved. **Native Token:** \- Define your native token or use DOT as the native token for your chain. \- If using DOT, select "DOT as GAS." \- Set your token's decimal places. **Coretime Order Control:** Config these parameters to utilize Magnet Network’s order control mechanism for on-demand orders. \- Price Limit: Sets an upper limit for coretime price. Orders will not be placed if exceeded. \- Price Threshold: Controls profitability from gas collection. $$ \text{Price Threshold} = \frac{\text{Gas Fee Collected}}{\text{Coretime Price}} $$ {% hint style="info" %} Price Threshold is available only when using DOT as GAS because coretime cost and revenue are measured in different tokens if using a native token. {% endhint %} For more information about Magnet's coretime mechanism, please refer to these sections: {% content-ref url="/pages/COiz9eQF0qwWbR0PK6jp" %} [Magnet Coretime](/overview/magnet-network-features/magnet-coretime) {% endcontent-ref %} {% content-ref url="/pages/VseMU5RZs6cxJppJufdS" %} [Coretime Order Control and Assurance](/overview/magnet-network-features/coretime-order-control-and-assurance) {% endcontent-ref %} **Sudo Account:** \- Input your sudo account address, which will also be used in profit distribution management. \- Set the initial balance for the sudo account (if not using DOT as GAS).
# Using Magnet Stack : Virtual Machine Configuration Step 2: Choose VM You may choose VMs from EVM, WASM and MoveVM. You must input chain ID if you choose EVM. {% hint style="info" %} Chain ID is a unique number for each EVM-compatible blockchain network. Visit [Chainlist](https://chainlist.org/) to check if your chosen Chain ID has been used or to register your ID. {% endhint %}
# Using Magnet Stack : Functional Models Step 3: Choose additional functional models **Profit Distribution:** \- Define the target address and distribution ratios for profit. \- If left empty, profit distribution will be disabled, and profits will remain in the system account. {% hint style="info" %} If DOT is selected as the gas token in the coretime configuration, any price difference between the coretime orders and the gas fees collected per block will be calculated as profit and automatically allocated to the designated address. If you choose your native token as the gas token, all gas fees collected will be allocated directly, without involving DOT. {% endhint %} \ For more infortmaion about profit calcuation, please refer to this section: {% content-ref url="/pages/2XPTGohNYeLHLpsze7KN" %} [Profit Calcuation and Distribution](/overview/magnet-network-features/profit-calcuation-and-distribution) {% endcontent-ref %} **Assurance:** This function ensures that coretime order placement is forced and block production continues if the order control mechanisms (Price Limit & Price Threshold) halt order placement for longer than the defined bid threshold. The bid threshold is specified by the number of relay chain blocks. For example, if the bid threshold is set to 8, on-demand order placement can be halted for up to 8 relay chain blocks if the Price Limit and Price Threshold conditions are not met. You may define bid threshold in this section. For more information about assurance function, please refer to this section: {% content-ref url="/pages/VseMU5RZs6cxJppJufdS" %} [Coretime Order Control and Assurance](/overview/magnet-network-features/coretime-order-control-and-assurance) {% endcontent-ref %} **Other Functions:** \- [XCM](https://wiki.polkadot.network/docs/learn-xcm-index): Facilitates communication and data transfer between different blockchains within the Polkadot and Kusama ecosystems. \- [Proxy](https://wiki.polkadot.network/docs/learn-guides-accounts-proxy): Proxies enable users to engage less frequently with an account while still actively contributing to the network with the token weight of that account. Proxies have the authority to execute a limited set of actions pertaining to certain substrate pallets on behalf of another account. \- [Multisig](https://wiki.polkadot.network/docs/learn-guides-accounts-multisig): Enables joint account control by requiring multiple signatures for transaction approval. \- OpenGov: Provides a framework for decentralized governance, allowing stakeholders to propose and vote on network changes.
# Using Magnet Stack : Summary Step 3: Confirm your configation and generate Parachain Codes You can review your configuration summary and generate code for either the Rococo or Polkadot. Once you click the button, the packaged code will be ready for download within a few seconds. # Deployment & Connection to Rocococ # Define the collator's address define the collator's address You can manually define the collator's address by specifying a custom key pair when starting the node. This is done by providing the node with a key file or directly specifying the keys using CLI options.
* **Using a Key File**: You can generate your key pair using the Substrate CLI or another tool and store it in a file. When you start the collator, you can instruct the node to use this key:
```bash bashCopy code./target/release/parachain-magnet-node --collator --chain raw-magnet-2000.json --base-path ./alice --node-key ``` \ The key file contains your private key, from which the public address is derived. This way, you can control which address your collator uses.
* **Specifying a Seed Phrase**: Alternatively, you can specify the key using a seed phrase directly in the CLI:
```bash bashCopy code./target/release/parachain-magnet-node --collator --chain raw-magnet-2000.json --base-path ./alice --node-key ``` \ This will generate the same address every time you use the same seed phrase.