- moonwall init
- ✔ Provide a label for the config file moonwall_config
- ✔ Provide a global timeout value 30000
- ✔ Provide a name for this environment default_env
- ✔ What type of network foundation is this? dev
- ✔ Provide the path for where tests for this environment are kept tests/
- ? Would you like to generate this config? (no to restart from beginning) (Y/n)
-
+The configuration file allows you to modify the storage of the forked network by rewriting the pallet, state component and value that you want to change. For example, Polkadot's file rewrites Alice's `system.Account` storage so that the free balance is set to `10000000000000000000`.
-The wizard generates a `moonwall.config` file:
+### CLI Flags
-```json
-{
- "label": "moonwall_config",
- "defaultTestTimeout": 30000,
- "environments": [
- {
- "name": "default_env",
- "testFileDir": ["tests/"],
- "foundation": {
- "type": "dev"
- }
- }
- ]
-}
+Alternatively, all settings (except for genesis and timestamp) can be configured via command-line flags, providing a comprehensive method to set up the environment.
-```
+## WebSocket Commands
-The default configuration requires specific details about your blockchain node and test requirements:
+Chopstick's internal WebSocket server has special endpoints that allow the manipulation of the local Polkadot SDK chain.
-- The `foundation` object defines how your test blockchain node will be launched and managed. The dev foundation, which runs a local node binary, is used for local development.
+These are the methods that can be invoked and their parameters:
- For more information about available options, check the [Foundations](https://moonsong-labs.github.io/moonwall/guide/intro/foundations.html){target=\_blank} section.
+- **dev_newBlock** (newBlockParams): Generates one or more new blocks.
-- The `connections` array specifies how your tests will interact with the blockchain node. This typically includes provider configuration and endpoint details.
+ === "Parameters"
- A provider is a tool that allows you or your application to connect to a blockchain network and simplifies the low-level details of the process. A provider handles submitting transactions, reading state, and more. For more information on available providers, check the [Providers supported](https://moonsong-labs.github.io/moonwall/guide/intro/providers.html#providers-supported){target=\_blank} page in the Moonwall documentation.
-
-Here's a complete configuration example for testing a local node using Polkadot.js as a provider:
-
-```json
-{
- "label": "moonwall_config",
- "defaultTestTimeout": 30000,
- "environments": [
- {
- "name": "default_env",
- "testFileDir": ["tests/"],
- "foundation": {
- "launchSpec": [
- {
- "binPath": "./node-template",
- "newRpcBehaviour": true,
- "ports": { "rpcPort": 9944 }
- }
- ],
- "type": "dev"
- },
- "connections": [
- {
- "name": "myconnection",
- "type": "polkadotJs",
- "endpoints": ["ws://127.0.0.1:9944"]
- }
- ]
- }
- ]
-}
-
-```
-
-## Writing Tests
-
-Moonwall uses the [`describeSuite`](https://github.com/Moonsong-Labs/moonwall/blob/7568048c52e9f7844f38fb4796ae9e1b9205fdaa/packages/cli/src/lib/runnerContext.ts#L65){target=\_blank} function to define test suites, like using [Mocha](https://mochajs.org/){target=\_blank}. Each test suite requires the following:
-
-- **`id`**: Unique identifier for the suite.
-- **`title`**: Descriptive name for the suite.
-- **`foundationMethods`**: Specifies the testing environment (e.g., `dev` for local node testing).
-- **`testCases`**: A callback function that houses the individual test cases of this suite.
-
-The following example shows how to test a balance transfer between two accounts:
-
-```ts
-import '@polkadot/api-augment';
-import { describeSuite, expect } from '@moonwall/cli';
-import { Keyring } from '@polkadot/api';
-
-describeSuite({
- id: 'D1',
- title: 'Demo suite',
- foundationMethods: 'dev',
- testCases: ({ it, context, log }) => {
- it({
- id: 'T1',
- title: 'Test Case',
- test: async () => {
- // Set up polkadot.js API and testing accounts
- let api = context.polkadotJs();
- let alice = new Keyring({ type: 'sr25519' }).addFromUri('//Alice');
- let charlie = new Keyring({ type: 'sr25519' }).addFromUri('//Charlie');
-
- // Query Charlie's account balance before transfer
- const balanceBefore = (await api.query.system.account(charlie.address))
- .data.free;
-
- // Before transfer, Charlie's account balance should be 0
- expect(balanceBefore.toString()).toEqual('0');
- log('Balance before: ' + balanceBefore.toString());
-
- // Transfer from Alice to Charlie
- const amount = 1000000000000000;
- await api.tx.balances
- .transferAllowDeath(charlie.address, amount)
- .signAndSend(alice);
-
- // Wait for the transaction to be included in a block.
- // This is necessary because the balance is not updated immediately.
- // Block time is 6 seconds.
- await new Promise((resolve) => setTimeout(resolve, 6000));
-
- // Query Charlie's account balance after transfer
- const balanceAfter = (await api.query.system.account(charlie.address))
- .data.free;
-
- // After transfer, Charlie's account balance should be 1000000000000000
- expect(balanceAfter.toString()).toEqual(amount.toString());
- log('Balance after: ' + balanceAfter.toString());
- },
- });
- },
-});
-
-```
-
-This test demonstrates several key concepts:
-
-- Initializing the Polkadot.js API through Moonwall's context and setting up test accounts.
-- Querying on-chain state.
-- Executing transactions.
-- Waiting for block inclusion.
-- Verifying results using assertions.
-
-## Running the Tests
-
-Execute your tests using the `test` Moonwall CLI command. For the default environment setup run:
-
-```bash
-moonwall test default_env -c moonwall.config
-```
-
-The test runner will output detailed results showing:
-
-- Test suite execution status.
-- Individual test case results.
-- Execution time.
-- Detailed logs and error messages (if any).
-
-Example output:
-
- moonwall test default_env -c moonwall.config
- stdout | tests/test1.ts > 🗃️ D1 Demo suite > 📁 D1T1 Test Case
- 2025-01-21T19:27:55.624Z test:default_env Balance before: 0
-
- stdout | tests/test1.ts > 🗃️ D1 Demo suite > 📁 D1T1 Test Case
- 2025-01-21T19:28:01.637Z test:default_env Balance after: 1000000000000000
-
- ✓ default_env tests/test1.ts (1 test) 6443ms
- ✓ 🗃️ D1 Demo suite > 📁 D1T1 Test Case 6028ms
-
- Test Files 1 passed (1)
- Tests 1 passed (1)
- Start at 16:27:53
- Duration 7.95s (transform 72ms, setup 0ms, collect 1.31s, tests 6.44s, environment 0ms, prepare 46ms)
-
- ✅ All tests passed
-
-
-## Where to Go Next
-
-For a comprehensive guide to Moonwall's full capabilities, available configurations, and advanced usage, see the official [Moonwall](https://moonsong-labs.github.io/moonwall/){target=\_blank} documentation.
-
-
----
-
-Page Title: Fork a Parachain Using Chopsticks
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/parachains-testing-fork-a-parachain.md
-- Canonical (HTML): https://docs.polkadot.com/parachains/testing/fork-a-parachain/
-- Summary: Simplify Polkadot SDK development with Chopsticks. Learn essential features, how to install Chopsticks, and how to configure local blockchain forks.
-
-# Fork a Parachain Using Chopsticks
-
-## Introduction
-
-[Chopsticks](https://github.com/AcalaNetwork/chopsticks/){target=\_blank}, developed by the [Acala Foundation](https://github.com/AcalaNetwork){target=\_blank}, is a versatile tool tailored for developers working on Polkadot SDK-based blockchains. With Chopsticks, you can fork live chains locally, replay blocks to analyze extrinsics, and simulate complex scenarios like XCM interactions all without deploying to a live network.
-
-This guide walks you through installing Chopsticks and provides information on configuring a local blockchain fork. By streamlining testing and experimentation, Chopsticks empowers developers to innovate and accelerate their blockchain projects within the Polkadot ecosystem.
-
-For additional support and information, please reach out through [GitHub Issues](https://github.com/AcalaNetwork/chopsticks/issues){target=_blank}.
-
-!!! warning
- Chopsticks uses [Smoldot](https://github.com/smol-dot/smoldot){target=_blank} light client, which only supports the native Polkadot SDK API. Consequently, a Chopsticks-based fork doesn't support Ethereum JSON-RPC calls, meaning you cannot use it to fork your chain and connect Metamask.
-
-## Prerequisites
-
-Before you begin, ensure you have the following installed:
-
-- [Node.js](https://nodejs.org/en/){target=\_blank}.
-- A package manager such as [npm](https://www.npmjs.com/){target=\_blank}, which should be installed with Node.js by default, or [Yarn](https://yarnpkg.com/){target=\_blank}.
-
-## Install Chopsticks
-
-You can install Chopsticks globally or locally in your project. Choose the option that best fits your development workflow. This documentation explains the features of Chopsticks version `1.2.2`. Make sure you're using the correct version to match these instructions.
-
-### Global Installation
-
-To install Chopsticks globally, allowing you to use it across multiple projects, run:
-
-```bash
-npm i -g @acala-network/chopsticks@1.2.2
-```
-
-Now, you should be able to run the `chopsticks` command from your terminal.
-
-### Local Installation
-
-To use Chopsticks in a specific project, first create a new directory and initialize a Node.js project:
-
-```bash
-mkdir my-chopsticks-project
-cd my-chopsticks-project
-npm init -y
-```
-
-Then, install Chopsticks as a local dependency:
-
-```bash
-npm i @acala-network/chopsticks@1.2.2
-```
-
-Finally, you can run Chopsticks using the `npx` command. To see all available options and commands, run it with the `--help` flag:
-
-```bash
-npx @acala-network/chopsticks --help
-```
-
-## Configure Chopsticks
-
-To run Chopsticks, you need to configure some parameters. This can be set either through using a configuration file or the command line interface (CLI). The parameters that can be configured are as follows:
-
-- **`genesis`**: The link to a parachain's raw genesis file to build the fork from, instead of an endpoint.
-- **`timestamp`**: Timestamp of the block to fork from.
-- **`endpoint`**: The endpoint of the parachain to fork.
-- **`block`**: Use to specify at which block hash or number to replay the fork.
-- **`wasm-override`**: Path of the Wasm to use as the parachain runtime, instead of an endpoint's runtime.
-- **`db`**: Path to the name of the file that stores or will store the parachain's database.
-- **`config`**: Path or URL of the config file.
-- **`port`**: The port to expose an endpoint on.
-- **`build-block-mode`**: How blocks should be built in the fork: batch, manual, instant.
-- **`import-storage`**: A pre-defined JSON/YAML storage path to override in the parachain's storage.
-- **`allow-unresolved-imports`**: Whether to allow Wasm unresolved imports when using a Wasm to build the parachain.
-- **`html`**: Include to generate storage diff preview between blocks.
-- **`mock-signature-host`**: Mock signature host so that any signature starts with `0xdeadbeef` and filled by `0xcd` is considered valid.
-
-### Configuration File
-
-The Chopsticks source repository includes a collection of [YAML](https://yaml.org/){target=\_blank} files that can be used to set up various Polkadot SDK chains locally. You can download these configuration files from the [repository's `configs` folder](https://github.com/AcalaNetwork/chopsticks/tree/master/configs){target=\_blank}.
-
-An example of a configuration file for Polkadot is as follows:
-
-{% raw %}
-```yaml
-endpoint:
- - wss://rpc.ibp.network/polkadot
- - wss://polkadot-rpc.dwellir.com
-mock-signature-host: true
-block: ${env.POLKADOT_BLOCK_NUMBER}
-db: ./db.sqlite
-runtime-log-level: 5
-
-import-storage:
- System:
- Account:
- - - - 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
- - providers: 1
- data:
- free: '10000000000000000000'
- ParasDisputes:
- $removePrefix: ['disputes'] # those can makes block building super slow
-
-```
-{% endraw %}
-
-The configuration file allows you to modify the storage of the forked network by rewriting the pallet, state component and value that you want to change. For example, Polkadot's file rewrites Alice's `system.Account` storage so that the free balance is set to `10000000000000000000`.
-
-### CLI Flags
-
-Alternatively, all settings (except for genesis and timestamp) can be configured via command-line flags, providing a comprehensive method to set up the environment.
-
-## WebSocket Commands
-
-Chopstick's internal WebSocket server has special endpoints that allow the manipulation of the local Polkadot SDK chain.
-
-These are the methods that can be invoked and their parameters:
-
-- **dev_newBlock** (newBlockParams): Generates one or more new blocks.
-
- === "Parameters"
-
- - **`newBlockParams` ++"NewBlockParams"++**: The parameters to build the new block with. Where the `NewBlockParams` interface includes the following properties.
+ - **`newBlockParams` ++"NewBlockParams"++**: The parameters to build the new block with. Where the `NewBlockParams` interface includes the following properties.
- **`count` ++"number"++**: The number of blocks to build.
- **`dmp` ++"{ msg: string, sentAt: number }[]"++**: The downward messages to include in the block.
@@ -3936,497 +3211,129 @@ These functionalities empower developers to build innovative, multi-chain applic
---
-Page Title: Glossary
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-glossary.md
-- Canonical (HTML): https://docs.polkadot.com/reference/glossary/
-- Summary: Glossary of terms used within the Polkadot ecosystem, Polkadot SDK, its subsequent libraries, and other relevant Web3 terminology.
-
-# Glossary
+Page Title: Indexers
-Key definitions, concepts, and terminology specific to the Polkadot ecosystem are included here.
+- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/parachains-integrations-indexers.md
+- Canonical (HTML): https://docs.polkadot.com/parachains/integrations/indexers/
+- Summary: Discover blockchain indexers. Enhance data access, enable fast and complex queries, and optimize blockchain data for seamless app performance.
-Additional glossaries from around the ecosystem you might find helpful:
+# Indexers
-- [Polkadot Wiki Glossary](https://wiki.polkadot.com/general/glossary){target=\_blank}
-- [Polkadot SDK Glossary](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/glossary/index.html){target=\_blank}
+## The Challenge of Blockchain Data Access
-## Authority
+Blockchain data is inherently sequential and distributed, with information stored chronologically across numerous blocks. While retrieving data from a single block through JSON-RPC API calls is straightforward, more complex queries that span multiple blocks present significant challenges:
-The role in a blockchain that can participate in consensus mechanisms.
+- Data is scattered and unorganized across the blockchain.
+- Retrieving large datasets can take days or weeks to sync.
+- Complex operations (like aggregations, averages, or cross-chain queries) require additional processing.
+- Direct blockchain queries can impact dApp performance and responsiveness.
-- **[GRANDPA](#grandpa)**: The authorities vote on chains they consider final.
-- **[Blind Assignment of Blockchain Extension](#blind-assignment-of-blockchain-extension-babe) (BABE)**: The authorities are also [block authors](#block-author).
+## What is a Blockchain Indexer?
-Authority sets can be used as a basis for consensus mechanisms such as the [Nominated Proof of Stake (NPoS)](#nominated-proof-of-stake-npos) protocol.
+A blockchain indexer is a specialized infrastructure tool that processes, organizes, and stores blockchain data in an optimized format for efficient querying. Think of it as a search engine for blockchain data that:
-## Authority Round (Aura)
+- Continuously monitors the blockchain for new blocks and transactions.
+- Processes and categorizes this data according to predefined schemas.
+- Stores the processed data in an easily queryable database.
+- Provides efficient APIs (typically [GraphQL](https://graphql.org/){target=\_blank}) for data retrieval.
-A deterministic [consensus](#consensus) protocol where block production is limited to a rotating list of [authorities](#authority) that take turns creating blocks. In authority round (Aura) consensus, most online authorities are assumed to be honest. It is often used in combination with [GRANDPA](#grandpa) as a [hybrid consensus](#hybrid-consensus) protocol.
+## Indexer Implementations
-Learn more by reading the official [Aura consensus algorithm](https://openethereum.github.io/Aura){target=\_blank} wiki article.
+
-## Blind Assignment of Blockchain Extension (BABE)
+- __Subsquid__
-A [block authoring](#block-author) protocol similar to [Aura](#authority-round-aura), except [authorities](#authority) win [slots](#slot) based on a Verifiable Random Function (VRF) instead of the round-robin selection method. The winning authority can select a chain and submit a new block.
+ ---
-Learn more by reading the official Web3 Foundation [BABE research document](https://research.web3.foundation/Polkadot/protocols/block-production/Babe){target=\_blank}.
+ Subsquid is a data network that allows rapid and cost-efficient retrieval of blockchain data from 100+ chains using Subsquid's decentralized data lake and open-source SDK. In simple terms, Subsquid can be considered an ETL (extract, transform, and load) tool with a GraphQL server included. It enables comprehensive filtering, pagination, and even full-text search capabilities. Subsquid has native and full support for EVM and Substrate data, even within the same project.
-## Block Author
+ [:octicons-arrow-right-24: Reference](https://www.sqd.ai/){target=\_blank}
-The node responsible for the creation of a block, also called _block producers_. In a Proof of Work (PoW) blockchain, these nodes are called _miners_.
+- __Subquery__
-## Byzantine Fault Tolerance (BFT)
+ ---
-The ability of a distributed computer network to remain operational if a certain proportion of its nodes or [authorities](#authority) are defective or behaving maliciously. A distributed network is typically considered Byzantine fault tolerant if it can remain functional, with up to one-third of nodes assumed to be defective, offline, actively malicious, and part of a coordinated attack.
+ SubQuery is a fast, flexible, and reliable open-source data decentralised infrastructure network that provides both RPC and indexed data to consumers worldwide.
+ It provides custom APIs for your web3 project across multiple supported chains.
-### Byzantine Failure
+ [:octicons-arrow-right-24: Reference](https://subquery.network/){target=\_blank}
-The loss of a network service due to node failures that exceed the proportion of nodes required to reach consensus.
+
-### Practical Byzantine Fault Tolerance (pBFT)
-An early approach to Byzantine fault tolerance (BFT), practical Byzantine fault tolerance (pBFT) systems tolerate Byzantine behavior from up to one-third of participants.
+---
-The communication overhead for such systems is `O(n²)`, where `n` is the number of nodes (participants) in the system.
+Page Title: Install Polkadot SDK
-### Preimage
+- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/parachains-install-polkadot-sdk.md
+- Canonical (HTML): https://docs.polkadot.com/parachains/install-polkadot-sdk/
+- Summary: Install all required Polkadot SDK dependencies, set up the SDK itself, and verify that it runs correctly on your machine.
-A preimage is the data that is input into a hash function to calculate a hash. Since a hash function is a [one-way function](https://en.wikipedia.org/wiki/One-way_function){target=\_blank}, the output, the hash, cannot be used to reveal the input, the preimage.
+# Install Polkadot SDK
-## Call
+This guide provides step-by-step instructions for installing the Polkadot SDK on macOS, Linux, and Windows. The installation process consists of two main parts:
-In the context of pallets containing functions to be dispatched to the runtime, `Call` is an enumeration data type that describes the functions that can be dispatched with one variant per pallet. A `Call` represents a [dispatch](#dispatchable) data structure object.
+- **Installing dependencies**: Setting up Rust, required system packages, and development tools.
+- **Building the Polkadot SDK**: Cloning and compiling the Polkadot SDK repository.
-## Chain Specification
+Follow the appropriate section for your operating system to ensure all necessary tools are installed and configured properly.
-A chain specification file defines the properties required to run a node in an active or new Polkadot SDK-built network. It often contains the initial genesis runtime code, network properties (such as the network's name), the initial state for some pallets, and the boot node list. The chain specification file makes it easy to use a single Polkadot SDK codebase as the foundation for multiple independently configured chains.
+## Install Dependencies: macOS
-## Collator
+You can install Rust and set up a Substrate development environment on Apple macOS computers with Intel or Apple M1 processors.
-An [author](#block-author) of a [parachain](#parachain) network.
-They aren't [authorities](#authority) in themselves, as they require a [relay chain](#relay-chain) to coordinate [consensus](#consensus).
+### Before You Begin {: #before-you-begin-mac-os }
-More details are found on the [Polkadot Collator Wiki](https://wiki.polkadot.com/learn/learn-collator/){target=\_blank}.
+Before you install Rust and set up your development environment on macOS, verify that your computer meets the following basic requirements:
-## Collective
+- Operating system version is 10.7 Lion or later.
+- Processor speed of at least 2 GHz. Note that 3 GHz is recommended.
+- Memory of at least 8 GB RAM. Note that 16 GB is recommended.
+- Storage of at least 10 GB of available space.
+- Broadband Internet connection.
-Most often used to refer to an instance of the Collective pallet on Polkadot SDK-based networks such as [Kusama](#kusama) or [Polkadot](#polkadot) if the Collective pallet is part of the FRAME-based runtime for the network.
+### Install Homebrew
-## Consensus
+In most cases, you should use Homebrew to install and manage packages on macOS computers. If you don't already have Homebrew installed on your local computer, you should download and install it before continuing.
-Consensus is the process blockchain nodes use to agree on a chain's canonical fork. It is composed of [authorship](#block-author), finality, and [fork-choice rule](#fork-choice-rulestrategy). In the Polkadot ecosystem, these three components are usually separate and the term consensus often refers specifically to authorship.
+To install Homebrew:
-See also [hybrid consensus](#hybrid-consensus).
+1. Open the Terminal application.
+2. Download and install Homebrew by running the following command:
-## Consensus Algorithm
+ ```bash
+ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
+ ```
-Ensures a set of [actors](#authority)—who don't necessarily trust each other—can reach an agreement about the state as the result of some computation. Most consensus algorithms assume that up to one-third of the actors or nodes can be [Byzantine fault tolerant](#byzantine-fault-tolerance-bft).
+3. Verify Homebrew has been successfully installed by running the following command:
-Consensus algorithms are generally concerned with ensuring two properties:
+ ```bash
+ brew --version
+ ```
-- **Safety**: Indicating that all honest nodes eventually agreed on the state of the chain.
-- **Liveness**: Indicating the ability of the chain to keep progressing.
+ The command displays output similar to the following:
-## Consensus Engine
+
+ brew --version
+ Homebrew 4.3.15
+
-The node subsystem responsible for consensus tasks.
+### Support for Apple Silicon
-For detailed information about the consensus strategies of the [Polkadot](#polkadot) network, see the [Polkadot Consensus](/reference/polkadot-hub/consensus-and-security/pos-consensus/){target=\_blank} blog series.
+Protobuf must be installed before the build process can begin. To install it, run the following command:
-See also [hybrid consensus](#hybrid-consensus).
+```bash
+brew install protobuf
+```
-## Coretime
+### Install Required Packages and Rust {: #install-required-packages-and-rust-mac-os }
-The time allocated for utilizing a core, measured in relay chain blocks. There are two types of coretime: *on-demand* and *bulk*.
+Because the blockchain requires standard cryptography to support the generation of public/private key pairs and the validation of transaction signatures, you must also have a package that provides cryptography, such as `openssl`.
-On-demand coretime refers to coretime acquired through bidding in near real-time for the validation of a single parachain block on one of the cores reserved specifically for on-demand orders. They are available as an on-demand coretime pool. Set of cores that are available on-demand. Cores reserved through bulk coretime could also be made available in the on-demand coretime pool, in parts or in entirety.
+To install `openssl` and the Rust toolchain on macOS:
-Bulk coretime is a fixed duration of continuous coretime represented by an NFT that can be split, shared, or resold. It is managed by the [Broker pallet](https://paritytech.github.io/polkadot-sdk/master/pallet_broker/index.html){target=\_blank}.
-
-## Development Phrase
-
-A [mnemonic phrase](https://en.wikipedia.org/wiki/Mnemonic#For_numerical_sequences_and_mathematical_operations){target=\_blank} that is intentionally made public.
-
-Well-known development accounts, such as Alice, Bob, Charlie, Dave, Eve, and Ferdie, are generated from the same secret phrase:
-
-```
-bottom drive obey lake curtain smoke basket hold race lonely fit walk
-```
-
-Many tools in the Polkadot SDK ecosystem, such as [`subkey`](https://github.com/paritytech/polkadot-sdk/tree/polkadot-stable2506-2/substrate/bin/utils/subkey){target=\_blank}, allow you to implicitly specify an account using a derivation path such as `//Alice`.
-
-## Digest
-
-An extensible field of the [block header](#header) that encodes information needed by several actors in a blockchain network, including:
-
-- [Light clients](#light-client) for chain synchronization.
-- Consensus engines for block verification.
-- The runtime itself, in the case of pre-runtime digests.
-
-## Dispatchable
-
-Function objects that act as the entry points in FRAME [pallets](#pallet). Internal or external entities can call them to interact with the blockchain’s state. They are a core aspect of the runtime logic, handling [transactions](#transaction) and other state-changing operations.
-
-## Events
-
-A means of recording that some particular [state](#state) transition happened.
-
-In the context of [FRAME](#frame-framework-for-runtime-aggregation-of-modularized-entities), events are composable data types that each [pallet](#pallet) can individually define. Events in FRAME are implemented as a set of transient storage items inspected immediately after a block has been executed and reset during block initialization.
-
-## Executor
-
-A means of executing a function call in a given [runtime](#runtime) with a set of dependencies.
-There are two orchestration engines in Polkadot SDK, _WebAssembly_ and _native_.
-
-- The _native executor_ uses a natively compiled runtime embedded in the node to execute calls. This is a performance optimization available to up-to-date nodes.
-
-- The _WebAssembly executor_ uses a [Wasm](#webassembly-wasm) binary and a Wasm interpreter to execute calls. The binary is guaranteed to be up-to-date regardless of the version of the blockchain node because it is persisted in the [state](#state) of the Polkadot SDK-based chain.
-
-## Existential Deposit
-
-The minimum balance an account is allowed to have in the [Balances pallet](https://paritytech.github.io/polkadot-sdk/master/pallet_balances/index.html){target=\_blank}. Accounts cannot be created with a balance less than the existential deposit amount.
-
-If an account balance drops below this amount, the Balances pallet uses [a FRAME System API](https://paritytech.github.io/substrate/master/frame_system/pallet/struct.Pallet.html#method.dec_ref){target=\_blank} to drop its references to that account.
-
-If the Balances pallet reference to an account is dropped, the account can be [reaped](https://paritytech.github.io/substrate/master/frame_system/pallet/struct.Pallet.html#method.allow_death){target=\_blank}.
-
-## Extrinsic
-
-A general term for data that originates outside the runtime, is included in a block, and leads to some action. This includes user-initiated transactions and inherent transactions placed into the block by the block builder.
-
-It is a SCALE-encoded array typically consisting of a version number, signature, and varying data types indicating the resulting runtime function to be called. Extrinsics can take two forms: [inherents](#inherent-transactions) and [transactions](#transaction).
-
-For more technical details, see the [Polkadot spec](https://spec.polkadot.network/id-extrinsics){target=\_blank}.
-
-## Fork Choice Rule/Strategy
-
-A fork choice rule or strategy helps determine which chain is valid when reconciling several network forks. A common fork choice rule is the [longest chain](https://paritytech.github.io/polkadot-sdk/master/sc_consensus/struct.LongestChain.html){target=\_blank}, in which the chain with the most blocks is selected.
-
-## FRAME (Framework for Runtime Aggregation of Modularized Entities)
-
-Enables developers to create blockchain [runtime](#runtime) environments from a modular set of components called [pallets](#pallet). It utilizes a set of procedural macros to construct runtimes.
-
-[Visit the Polkadot SDK docs for more details on FRAME.](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/polkadot_sdk/frame_runtime/index.html){target=\_blank}
-
-## Full Node
-
-A node that prunes historical states, keeping only recently finalized block states to reduce storage needs. Full nodes provide current chain state access and allow direct submission and validation of [extrinsics](#extrinsic), maintaining network decentralization.
-
-## Genesis Configuration
-
-A mechanism for specifying the initial state of a blockchain. By convention, this initial state or first block is commonly referred to as the genesis state or genesis block. The genesis configuration for Polkadot SDK-based chains is accomplished by way of a [chain specification](#chain-specification) file.
-
-## GRANDPA
-
-A deterministic finality mechanism for blockchains that is implemented in the [Rust](https://www.rust-lang.org/){target=\_blank} programming language.
-
-The [formal specification](https://github.com/w3f/consensus/blob/master/pdf/grandpa-old.pdf){target=\_blank} is maintained by the [Web3 Foundation](https://web3.foundation/){target=\_blank}.
-
-## Header
-
-A structure that aggregates the information used to summarize a block. Primarily, it consists of cryptographic information used by [light clients](#light-client) to get minimally secure but very efficient chain synchronization.
-
-## Hybrid Consensus
-
-A blockchain consensus protocol that consists of independent or loosely coupled mechanisms for [block production](#block-author) and finality.
-
-Hybrid consensus allows the chain to grow as fast as probabilistic consensus protocols, such as [Aura](#authority-round-aura), while maintaining the same level of security as deterministic finality consensus protocols, such as [GRANDPA](#grandpa).
-
-## Inherent Transactions
-
-A special type of unsigned transaction, referred to as _inherents_, that enables a block authoring node to insert information that doesn't require validation directly into a block.
-
-Only the block-authoring node that calls the inherent transaction function can insert data into its block. In general, validators assume the data inserted using an inherent transaction is valid and reasonable even if it can't be deterministically verified.
-
-## JSON-RPC
-
-A stateless, lightweight remote procedure call protocol encoded in JavaScript Object Notation (JSON). JSON-RPC provides a standard way to call functions on a remote system by using JSON.
-
-For Polkadot SDK, this protocol is implemented through the [Parity JSON-RPC](https://github.com/paritytech/jsonrpc){target=\_blank} crate.
-
-## Keystore
-
-A subsystem for managing keys for the purpose of producing new blocks.
-
-## Kusama
-
-[Kusama](https://kusama.network/){target=\_blank} is a Polkadot SDK-based blockchain that implements a design similar to the [Polkadot](#polkadot) network.
-
-Kusama is a [canary](https://en.wiktionary.org/wiki/canary_in_a_coal_mine){target=\_blank} network and is referred to as [Polkadot's "wild cousin."](https://wiki.polkadot.com/learn/learn-comparisons-kusama/){target=\_blank}.
-
-As a canary network, Kusama is expected to be more stable than a test network like [Westend](#westend) but less stable than a production network like [Polkadot](#polkadot). Kusama is controlled by its network participants and is intended to be stable enough to encourage meaningful experimentation.
-
-## libp2p
-
-A peer-to-peer networking stack that allows the use of many transport mechanisms, including WebSockets (usable in a web browser).
-
-Polkadot SDK uses the [Rust implementation](https://github.com/libp2p/rust-libp2p){target=\_blank} of the `libp2p` networking stack.
-
-## Light Client
-
-A type of blockchain node that doesn't store the [chain state](#state) or produce blocks.
-
-A light client can verify cryptographic primitives and provides a [remote procedure call (RPC)](https://en.wikipedia.org/wiki/Remote_procedure_call){target=\_blank} server, enabling blockchain users to interact with the network.
-
-## Metadata
-
-Data that provides information about one or more aspects of a system.
-The metadata that exposes information about a Polkadot SDK blockchain enables you to interact with that system.
-
-## Nominated Proof of Stake (NPoS)
-
-A method for determining [validators](#validator) or _[authorities](#authority)_ based on a willingness to commit their stake to the proper functioning of one or more block-producing nodes.
-
-## Oracle
-
-An entity that connects a blockchain to a non-blockchain data source. Oracles enable the blockchain to access and act upon information from existing data sources and incorporate data from non-blockchain systems and services.
-
-## Origin
-
-A [FRAME](#frame-framework-for-runtime-aggregation-of-modularized-entities) primitive that identifies the source of a [dispatched](#dispatchable) function call into the [runtime](#runtime). The FRAME System pallet defines three built-in [origins](#origin). As a [pallet](#pallet) developer, you can also define custom origins, such as those defined by the [Collective pallet](https://paritytech.github.io/substrate/master/pallet_collective/enum.RawOrigin.html){target=\_blank}.
-
-## Pallet
-
-A module that can be used to extend the capabilities of a [FRAME](#frame-framework-for-runtime-aggregation-of-modularized-entities)-based [runtime](#runtime).
-Pallets bundle domain-specific logic with runtime primitives like [events](#events) and [storage items](#storage-item).
-
-## Parachain
-
-A parachain is a blockchain that derives shared infrastructure and security from a _[relay chain](#relay-chain)_.
-You can learn more about parachains on the [Polkadot Wiki](https://wiki.polkadot.com/learn/learn-parachains/){target=\_blank}.
-
-## Paseo
-
-Paseo TestNet provisions testing on Polkadot's "production" runtime, which means less chance of feature or code mismatch when developing parachain apps. Specifically, after the [Polkadot Technical fellowship](https://wiki.polkadot.com/learn/learn-polkadot-technical-fellowship/){target=\_blank} proposes a runtime upgrade for Polkadot, this TestNet is updated, giving a period where the TestNet will be ahead of Polkadot to allow for testing.
-
-## Polkadot
-
-The [Polkadot network](https://polkadot.com/){target=\_blank} is a blockchain that serves as the central hub of a heterogeneous blockchain network. It serves the role of the [relay chain](#relay-chain) and provides shared infrastructure and security to support [parachains](#parachain).
-
-## Polkadot Cloud
-
-Polkadot Cloud is a platform for deploying resilient, customizable and scalable Web3 applications through Polkadot's functionality. It encompasses the wider Polkadot network infrastructure and security layer where parachains operate. The platform enables users to launch Ethereum-compatible chains, build specialized blockchains, and flexibly manage computing resources through on-demand or bulk coretime purchases. Initially launched with basic parachain functionality, Polkadot Cloud has evolved to offer enhanced flexibility with features like coretime, elastic scaling, and async backing for improved performance.
-
-## Polkadot Hub
-
-Polkadot Hub is a Layer 1 platform that serves as the primary entry point to the Polkadot ecosystem, providing essential functionality without requiring parachain deployment. It offers core services including smart contracts, identity management, staking, governance, and interoperability with other ecosystems, making it simple and fast for both builders and users to get started in Web3.
-
-## PolkaVM
-
-PolkaVM is a custom virtual machine optimized for performance, leveraging a RISC-V-based architecture to support Solidity and any language that compiles to RISC-V. It is specifically designed for the Polkadot ecosystem, enabling smart contract deployment and execution.
-
-## Relay Chain
-
-Relay chains are blockchains that provide shared infrastructure and security to the [parachains](#parachain) in the network. In addition to providing [consensus](#consensus) capabilities, relay chains allow parachains to communicate and exchange digital assets without needing to trust one another.
-
-## Rococo
-
-A [parachain](#parachain) test network for the Polkadot network. The [Rococo](#rococo) network is a Polkadot SDK-based blockchain with an October 14, 2024 deprecation date. Development teams are encouraged to use the Paseo TestNet instead.
-
-## Runtime
-
-The runtime represents the [state transition function](#state-transition-function-stf) for a blockchain. In Polkadot SDK, the runtime is stored as a [Wasm](#webassembly-wasm) binary in the chain state. The Runtime is stored under a unique state key and can be modified during the execution of the state transition function.
-
-## Slot
-
-A fixed, equal interval of time used by consensus engines such as [Aura](#authority-round-aura) and [BABE](#blind-assignment-of-blockchain-extension-babe). In each slot, a subset of [authorities](#authority) is permitted, or obliged, to [author](#block-author) a block.
-
-## Sovereign Account
-
-The unique account identifier for each chain in the relay chain ecosystem. It is often used in cross-consensus (XCM) interactions to sign XCM messages sent to the relay chain or other chains in the ecosystem.
-
-The sovereign account for each chain is a root-level account that can only be accessed using the Sudo pallet or through governance. The account identifier is calculated by concatenating the Blake2 hash of a specific text string and the registered parachain identifier.
-
-## SS58 Address Format
-
-A public key address based on the Bitcoin [`Base-58-check`](https://en.bitcoin.it/wiki/Base58Check_encoding){target=\_blank} encoding. Each Polkadot SDK SS58 address uses a `base-58` encoded value to identify a specific account on a specific Polkadot SDK-based chain
-
-The [canonical `ss58-registry`](https://github.com/paritytech/ss58-registry){target=\_blank} provides additional details about the address format used by different Polkadot SDK-based chains, including the network prefix and website used for different networks
-
-## State Transition Function (STF)
-
-The logic of a blockchain that determines how the state changes when a block is processed. In Polkadot SDK, the state transition function is effectively equivalent to the [runtime](#runtime).
-
-## Storage Item
-
-[FRAME](#frame-framework-for-runtime-aggregation-of-modularized-entities) primitives that provide type-safe data persistence capabilities to the [runtime](#runtime).
-Learn more in the [storage items](https://paritytech.github.io/polkadot-sdk/master/frame_support/storage/types/index.html){target=\_blank} reference document in the Polkadot SDK.
-
-## Substrate
-
-A flexible framework for building modular, efficient, and upgradeable blockchains. Substrate is written in the [Rust](https://www.rust-lang.org/){target=\_blank} programming language and is maintained by [Parity Technologies](https://www.parity.io/){target=\_blank}.
-
-## Transaction
-
-An [extrinsic](#extrinsic) that includes a signature that can be used to verify the account authorizing it inherently or via [signed extensions](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/signed_extensions/index.html){target=\_blank}.
-
-## Transaction Era
-
-A definable period expressed as a range of block numbers during which a transaction can be included in a block.
-Transaction eras are used to protect against transaction replay attacks if an account is reaped and its replay-protecting nonce is reset to zero.
-
-## Trie (Patricia Merkle Tree)
-
-A data structure used to represent sets of key-value pairs and enables the items in the data set to be stored and retrieved using a cryptographic hash. Because incremental changes to the data set result in a new hash, retrieving data is efficient even if the data set is very large. With this data structure, you can also prove whether the data set includes any particular key-value pair without access to the entire data set.
-
-In Polkadot SDK-based blockchains, state is stored in a trie data structure that supports the efficient creation of incremental digests. This trie is exposed to the [runtime](#runtime) as [a simple key/value map](#storage-item) where both keys and values can be arbitrary byte arrays.
-
-## Validator
-
-A validator is a node that participates in the consensus mechanism of the network. Its roles include block production, transaction validation, network integrity, and security maintenance.
-
-## WebAssembly (Wasm)
-
-An execution architecture that allows for the efficient, platform-neutral expression of
-deterministic, machine-executable logic.
-
-[Wasm](https://webassembly.org/){target=\_blank} can be compiled from many languages, including
-the [Rust](https://www.rust-lang.org/){target=\_blank} programming language. Polkadot SDK-based chains use a Wasm binary to provide portable [runtimes](#runtime) that can be included as part of the chain's state.
-
-## Weight
-
-A convention used in Polkadot SDK-based blockchains to measure and manage the time it takes to validate a block.
-Polkadot SDK defines one unit of weight as one picosecond of execution time on reference hardware.
-
-The maximum block weight should be equivalent to one-third of the target block time with an allocation of one-third each for:
-
-- Block construction
-- Network propagation
-- Import and verification
-
-By defining weights, you can trade-off the number of transactions per second and the hardware required to maintain the target block time appropriate for your use case. Weights are defined in the runtime, meaning you can tune them using runtime updates to keep up with hardware and software improvements.
-
-## Westend
-
-Westend is a Parity-maintained, Polkadot SDK-based blockchain that serves as a test network for the [Polkadot](#polkadot) network.
-
-
----
-
-Page Title: Indexers
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/parachains-integrations-indexers.md
-- Canonical (HTML): https://docs.polkadot.com/parachains/integrations/indexers/
-- Summary: Discover blockchain indexers. Enhance data access, enable fast and complex queries, and optimize blockchain data for seamless app performance.
-
-# Indexers
-
-## The Challenge of Blockchain Data Access
-
-Blockchain data is inherently sequential and distributed, with information stored chronologically across numerous blocks. While retrieving data from a single block through JSON-RPC API calls is straightforward, more complex queries that span multiple blocks present significant challenges:
-
-- Data is scattered and unorganized across the blockchain.
-- Retrieving large datasets can take days or weeks to sync.
-- Complex operations (like aggregations, averages, or cross-chain queries) require additional processing.
-- Direct blockchain queries can impact dApp performance and responsiveness.
-
-## What is a Blockchain Indexer?
-
-A blockchain indexer is a specialized infrastructure tool that processes, organizes, and stores blockchain data in an optimized format for efficient querying. Think of it as a search engine for blockchain data that:
-
-- Continuously monitors the blockchain for new blocks and transactions.
-- Processes and categorizes this data according to predefined schemas.
-- Stores the processed data in an easily queryable database.
-- Provides efficient APIs (typically [GraphQL](https://graphql.org/){target=\_blank}) for data retrieval.
-
-## Indexer Implementations
-
-
-
-- __Subsquid__
-
- ---
-
- Subsquid is a data network that allows rapid and cost-efficient retrieval of blockchain data from 100+ chains using Subsquid's decentralized data lake and open-source SDK. In simple terms, Subsquid can be considered an ETL (extract, transform, and load) tool with a GraphQL server included. It enables comprehensive filtering, pagination, and even full-text search capabilities. Subsquid has native and full support for EVM and Substrate data, even within the same project.
-
- [:octicons-arrow-right-24: Reference](https://www.sqd.ai/){target=\_blank}
-
-- __Subquery__
-
- ---
-
- SubQuery is a fast, flexible, and reliable open-source data decentralised infrastructure network that provides both RPC and indexed data to consumers worldwide.
- It provides custom APIs for your web3 project across multiple supported chains.
-
- [:octicons-arrow-right-24: Reference](https://subquery.network/){target=\_blank}
-
-
-
-
----
-
-Page Title: Install Polkadot SDK
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/parachains-install-polkadot-sdk.md
-- Canonical (HTML): https://docs.polkadot.com/parachains/install-polkadot-sdk/
-- Summary: Install all required Polkadot SDK dependencies, set up the SDK itself, and verify that it runs correctly on your machine.
-
-# Install Polkadot SDK
-
-This guide provides step-by-step instructions for installing the Polkadot SDK on macOS, Linux, and Windows. The installation process consists of two main parts:
-
-- **Installing dependencies**: Setting up Rust, required system packages, and development tools.
-- **Building the Polkadot SDK**: Cloning and compiling the Polkadot SDK repository.
-
-Follow the appropriate section for your operating system to ensure all necessary tools are installed and configured properly.
-
-## Install Dependencies: macOS
-
-You can install Rust and set up a Substrate development environment on Apple macOS computers with Intel or Apple M1 processors.
-
-### Before You Begin {: #before-you-begin-mac-os }
-
-Before you install Rust and set up your development environment on macOS, verify that your computer meets the following basic requirements:
-
-- Operating system version is 10.7 Lion or later.
-- Processor speed of at least 2 GHz. Note that 3 GHz is recommended.
-- Memory of at least 8 GB RAM. Note that 16 GB is recommended.
-- Storage of at least 10 GB of available space.
-- Broadband Internet connection.
-
-### Install Homebrew
-
-In most cases, you should use Homebrew to install and manage packages on macOS computers. If you don't already have Homebrew installed on your local computer, you should download and install it before continuing.
-
-To install Homebrew:
-
-1. Open the Terminal application.
-2. Download and install Homebrew by running the following command:
-
- ```bash
- /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
- ```
-
-3. Verify Homebrew has been successfully installed by running the following command:
-
- ```bash
- brew --version
- ```
-
- The command displays output similar to the following:
-
-
- brew --version
- Homebrew 4.3.15
-
-
-### Support for Apple Silicon
-
-Protobuf must be installed before the build process can begin. To install it, run the following command:
-
-```bash
-brew install protobuf
-```
-
-### Install Required Packages and Rust {: #install-required-packages-and-rust-mac-os }
-
-Because the blockchain requires standard cryptography to support the generation of public/private key pairs and the validation of transaction signatures, you must also have a package that provides cryptography, such as `openssl`.
-
-To install `openssl` and the Rust toolchain on macOS:
-
-1. Open the Terminal application.
-2. Ensure you have an updated version of Homebrew by running the following command:
+1. Open the Terminal application.
+2. Ensure you have an updated version of Homebrew by running the following command:
```bash
brew update
@@ -4778,87 +3685,17 @@ To stop the node, press `Control-C` in the terminal.
---
-Page Title: Interoperability
+Page Title: JSON-RPC APIs
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-interoperability.md
-- Canonical (HTML): https://docs.polkadot.com/reference/parachains/interoperability/
-- Summary: Explore the importance of interoperability in the Polkadot ecosystem, covering XCM, bridges, and cross-chain communication.
+- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/smart-contracts-for-eth-devs-json-rpc-apis.md
+- Canonical (HTML): https://docs.polkadot.com/smart-contracts/for-eth-devs/json-rpc-apis/
+- Summary: JSON-RPC APIs guide for Polkadot Hub, covering supported methods, parameters, and examples for interacting with the chain.
-# Interoperability
+# JSON-RPC APIs
## Introduction
-Interoperability lies at the heart of the Polkadot ecosystem, enabling communication and collaboration across a diverse range of blockchains. By bridging the gaps between parachains, relay chains, and even external networks, Polkadot unlocks the potential for truly decentralized applications, efficient resource sharing, and scalable solutions.
-
-Polkadot’s design ensures that blockchains can transcend their individual limitations by working together as part of a unified system. This cooperative architecture is what sets Polkadot apart in the blockchain landscape.
-
-## Why Interoperability Matters
-
-The blockchain ecosystem is inherently fragmented. Different blockchains excel in specialized domains such as finance, gaming, or supply chain management, but these chains function in isolation without interoperability. This lack of connectivity stifles the broader utility of blockchain technology.
-
-Interoperability solves this problem by enabling blockchains to:
-
-- **Collaborate across networks**: Chains can interact to share assets, functionality, and data, creating synergies that amplify their individual strengths.
-- **Achieve greater scalability**: Specialized chains can offload tasks to others, optimizing performance and resource utilization.
-- **Expand use-case potential**: Cross-chain applications can leverage features from multiple blockchains, unlocking novel user experiences and solutions.
-
-In the Polkadot ecosystem, interoperability transforms a collection of isolated chains into a cohesive, efficient network, pushing the boundaries of what blockchains can achieve together.
-
-## Key Mechanisms for Interoperability
-
-At the core of Polkadot's cross-chain collaboration are foundational technologies designed to break down barriers between networks. These mechanisms empower blockchains to communicate, share resources, and operate as a cohesive ecosystem.
-
-### Cross-Consensus Messaging (XCM): The Backbone of Communication
-
-Polkadot's Cross-Consensus Messaging (XCM) is the standard framework for interaction between parachains, relay chains, and, eventually, external blockchains. XCM provides a trustless, secure messaging format for exchanging assets, sharing data, and executing cross-chain operations.
-
-Through XCM, decentralized applications can:
-
-- Transfer tokens and other assets across chains.
-- Coordinate complex workflows that span multiple blockchains.
-- Enable seamless user experiences where underlying blockchain differences are invisible.
-- XCM exemplifies Polkadot’s commitment to creating a robust and interoperable ecosystem.
-
-For further information about XCM, check the [Get Started with XCM](/parachains/interoperability/get-started/){target=\_blank} article.
-
-### Bridges: Connecting External Networks
-
-While XCM enables interoperability within the Polkadot ecosystem, bridges extend this functionality to external blockchains such as Ethereum and Bitcoin. By connecting these networks, bridges allow Polkadot-based chains to access external liquidity, additional functionalities, and broader user bases.
-
-With bridges, developers and users gain the ability to:
-
-- Integrate external assets into Polkadot-based applications.
-- Combine the strengths of Polkadot’s scalability with the liquidity of other networks.
-- Facilitate accurate multi-chain applications that transcend ecosystem boundaries.
-
-For more information about bridges in the Polkadot ecosystem, see the [Bridge Hub](/reference/polkadot-hub/bridging/){target=\_blank} guide.
-
-## The Polkadot Advantage
-
-Polkadot was purpose-built for interoperability. Unlike networks that add interoperability as an afterthought, Polkadot integrates it as a fundamental design principle. This approach offers several distinct advantages:
-
-- **Developer empowerment**: Polkadot’s interoperability tools allow developers to build applications that leverage multiple chains’ capabilities without added complexity.
-- **Enhanced ecosystem collaboration**: Chains in Polkadot can focus on their unique strengths while contributing to the ecosystem’s overall growth.
-- **Future-proofing blockchain**: By enabling seamless communication, Polkadot ensures its ecosystem can adapt to evolving demands and technologies.
-
-## Looking Ahead
-
-Polkadot’s vision of interoperability extends beyond technical functionality, representing a shift towards a more collaborative blockchain landscape. By enabling chains to work together, Polkadot fosters innovation, efficiency, and accessibility, paving the way for a decentralized future where blockchains are not isolated competitors but interconnected collaborators.
-
-
----
-
-Page Title: JSON-RPC APIs
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/smart-contracts-for-eth-devs-json-rpc-apis.md
-- Canonical (HTML): https://docs.polkadot.com/smart-contracts/for-eth-devs/json-rpc-apis/
-- Summary: JSON-RPC APIs guide for Polkadot Hub, covering supported methods, parameters, and examples for interacting with the chain.
-
-# JSON-RPC APIs
-
-## Introduction
-
-Polkadot Hub provides Ethereum compatibility through its JSON-RPC interface, allowing developers to interact with the chain using familiar Ethereum tooling and methods. This document outlines the supported [Ethereum JSON-RPC methods](https://ethereum.org/developers/docs/apis/json-rpc/#json-rpc-methods){target=\_blank} and provides examples of how to use them.
+Polkadot Hub provides Ethereum compatibility through its JSON-RPC interface, allowing developers to interact with the chain using familiar Ethereum tooling and methods. This document outlines the supported [Ethereum JSON-RPC methods](https://ethereum.org/developers/docs/apis/json-rpc/#json-rpc-methods){target=\_blank} and provides examples of how to use them.
This guide uses the Polkadot Hub TestNet endpoint:
@@ -5715,384 +4552,6 @@ If an error occurs, the response will include an error object:
```
----
-
-Page Title: Light Clients
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-tools-light-clients.md
-- Canonical (HTML): https://docs.polkadot.com/reference/tools/light-clients/
-- Summary: Light clients enable secure and efficient blockchain interaction without running a full node. Learn everything you need to know about light clients on Polkadot.
-
-# Light Clients
-
-## Introduction
-
-Light clients enable secure and efficient blockchain interaction without running a full node. They provide a trust-minimized alternative to JSON-RPC by verifying data through cryptographic proofs rather than blindly trusting remote nodes.
-
-This guide covers:
-
-- What light clients are and how they work.
-- Their advantages compared to full nodes and JSON-RPC.
-- Available implementations in the Polkadot ecosystem.
-- How to use light clients in your applications.
-
-Light clients are particularly valuable for resource-constrained environments and applications requiring secure, decentralized blockchain access without the overhead of maintaining full nodes.
-
-!!!note "Light node or light client?"
- The terms _light node_ and _light client_ are interchangeable. Both refer to a blockchain client that syncs without downloading the entire blockchain state. All nodes in a blockchain network are fundamentally clients, engaging in peer-to-peer communication.
-
-## Light Clients Workflow
-
-Unlike JSON-RPC interfaces, where an application must maintain a list of providers or rely on a single node, light clients are not limited to or dependent on a single node. They use cryptographic proofs to verify the blockchain's state, ensuring it is up-to-date and accurate. By verifying only block headers, light clients avoid syncing the entire state, making them ideal for resource-constrained environments.
-
-```mermaid
-flowchart LR
-DAPP([dApp])-- Query Account Info -->LC([Light Client])
-LC -- Request --> FN(((Full Node)))
-LC -- Response --> DAPP
-FN -- Response (validated via Merkle proof) --> LC
-```
-
-In the diagram above, the decentralized application queries on-chain account information through the light client. The light client runs as part of the application and requires minimal memory and computational resources. It uses Merkle proofs to verify the state retrieved from a full node in a trust-minimized manner. Polkadot-compatible light clients utilize [warp syncing](https://spec.polkadot.network/sect-lightclient#sect-sync-warp-lightclient){target=\_blank}, which downloads only block headers.
-
-Light clients can quickly verify the blockchain's state, including [GRANDPA finality](/polkadot-protocol/glossary#grandpa){target=\_blank} justifications.
-
-!!!note "What does it mean to be trust-minimized?"
- _Trust-minimized_ means that the light client does not need to fully trust the full node from which it retrieves the state. This is achieved through the use of Merkle proofs, which allow the light client to verify the correctness of the state by checking the Merkle tree root.
-
-## JSON-RPC and Light Client Comparison
-
-Another common method of communication between a user interface (UI) and a node is through the JSON-RPC protocol. Generally, the UI retrieves information from the node, fetches network or [pallet](/polkadot-protocol/glossary#pallet){target=\_blank} data, and interacts with the blockchain. This is typically done in one of two ways:
-
-- **User-controlled nodes**: The UI connects to a node client installed on the user's machine.
- - These nodes are secure, but installation and maintenance can be inconvenient.
-- **Publicly accessible nodes**: The UI connects to a third-party-owned publicly accessible node client.
- - These nodes are convenient but centralized and less secure. Applications must maintain a list of backup nodes in case the primary node becomes unavailable.
-
-While light clients still communicate with [full nodes](/polkadot-protocol/glossary#full-node), they offer significant advantages for applications requiring a secure alternative to running a full node:
-
-| Full Node | Light Client |
-| :---------------------------------------------------------------------------------------------: | :------------------------------------------------------------: |
-| Fully verifies all blocks of the chain | Verifies only the authenticity of blocks |
-| Stores previous block data and the chain's storage in a database | Does not require a database |
-| Installation, maintenance, and execution are resource-intensive and require technical expertise | No installation is typically included as part of the application |
-
-## Using Light Clients
-
-The [`smoldot`](https://github.com/smol-dot/smoldot){target=\_blank} client is the cornerstone of light client implementation for Polkadot SDK-based chains. It provides the primitives needed to build light clients and is also integrated into libraries such as [PAPI](#papi-light-client-support).
-
-### PAPI Light Client Support
-
-The [Polkadot API (PAPI)](/develop/toolkit/api-libraries/papi){target=\_blank} library natively supports light client configurations powered by [`smoldot`](https://github.com/smol-dot/smoldot){target=\_blank}. This allows developers to connect to multiple chains simultaneously using a light client.
-
-### Substrate Connect - Browser Extension
-
-The [Substrate Connect browser extension](https://www.npmjs.com/package/@substrate/connect-extension-protocol){target=\_blank} enables end-users to interact with applications connected to multiple blockchains or to connect their own blockchains to supported applications.
-
-Establishing a sufficient number of peers can be challenging due to browser limitations on WebSocket connections from HTTPS pages, as many nodes require TLS. The Substrate Connect browser extension addresses this limitation by keeping chains synced in the background, enabling faster application performance.
-
-Substrate Connect automatically detects whether the user has the extension installed. If not, an in-page Wasm light client is created for them.
-
-## Resources
-
-- [What is a light client and why you should care?](https://medium.com/paritytech/what-is-a-light-client-and-why-you-should-care-75f813ae2670){target=\_blank}
-- [Introducing Substrate Connect: Browser-Based Light Clients for Connecting to Substrate Chains](https://www.parity.io/blog/introducing-substrate-connect){target=\_blank}
-- [Substrate Connect GitHub Repository](https://github.com/paritytech/substrate-connect/tree/master/projects/extension){target=\_blank}
-- [Light Clients - Polkadot Specification](https://spec.polkadot.network/sect-lightclient){target=\_blank}
-
-
----
-
-Page Title: Networks
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-networks.md
-- Canonical (HTML): https://docs.polkadot.com/reference/parachains/networks/
-- Summary: Explore Polkadot's testing and production networks, including Westend, Kusama, and Paseo, for efficient development, deployment, and testing.
-
-# Networks
-
-## Introduction
-
-The Polkadot ecosystem is built on a robust set of networks designed to enable secure and scalable development. Whether you are testing new features or deploying to live production, Polkadot offers several layers of networks tailored for each stage of the development process. From local environments to experimental networks like Kusama and community-run TestNets such as Paseo, developers can thoroughly test, iterate, and validate their applications. This guide will introduce you to Polkadot's various networks and explain how they fit into the development workflow.
-
-## Network Overview
-
-Polkadot's development process is structured to ensure new features and upgrades are rigorously tested before being deployed on live production networks. The progression follows a well-defined path, starting from local environments and advancing through TestNets, ultimately reaching the Polkadot MainNet. The diagram below outlines the typical progression of the Polkadot development cycle:
-
-``` mermaid
-flowchart LR
- id1[Local] --> id2[Westend] --> id4[Kusama] --> id5[Polkadot]
- id1[Local] --> id3[Paseo] --> id5[Polkadot]
-```
-
-This flow ensures developers can thoroughly test and iterate without risking real tokens or affecting production networks. Testing tools like [Chopsticks](#chopsticks) and various TestNets make it easier to experiment safely before releasing to production.
-
-A typical journey through the Polkadot core protocol development process might look like this:
-
-1. **Local development node**: Development starts in a local environment, where developers can create, test, and iterate on upgrades or new features using a local development node. This stage allows rapid experimentation in an isolated setup without any external dependencies.
-
-2. **Westend**: After testing locally, upgrades are deployed to [Westend](#westend), Polkadot's primary TestNet. Westend simulates real-world conditions without using real tokens, making it the ideal place for rigorous feature testing before moving on to production networks.
-
-3. **Kusama**: Once features have passed extensive testing on Westend, they move to Kusama, Polkadot's experimental and fast-moving "canary" network. Kusama operates as a high-fidelity testing ground with actual economic incentives, giving developers insights into how their features will perform in a real-world environment.
-
-4. **Polkadot**: After passing tests on Westend and Kusama, features are considered ready for deployment to Polkadot, the live production network.
-
- In addition, parachain developers can leverage local TestNets like [Zombienet](#zombienet) and deploy upgrades on parachain TestNets.
-
-5. **Paseo**: For parachain and dApp developers, Paseo serves as a community-run TestNet that mirrors Polkadot's runtime. Like Westend for core protocol development, Paseo provides a testing ground for parachain development without affecting live networks.
-
-!!!note
- The Rococo TestNet deprecation date was October 14, 2024. Teams should use Westend for Polkadot protocol and feature testing and Paseo for chain development-related testing.
-
-## Polkadot Development Networks
-
-Development and testing are crucial to building robust dApps and parachains and performing network upgrades within the Polkadot ecosystem. To achieve this, developers can leverage various networks and tools that provide a risk-free environment for experimentation and validation before deploying features to live networks. These networks help avoid the costs and risks associated with real tokens, enabling testing for functionalities like governance, cross-chain messaging, and runtime upgrades.
-
-## Kusama Network
-
-Kusama is the experimental version of Polkadot, designed for developers who want to move quickly and test their applications in a real-world environment with economic incentives. Kusama serves as a production-grade testing ground where developers can deploy features and upgrades with the pressure of game theory and economics in mind. It mirrors Polkadot but operates as a more flexible space for innovation.
-
-The native token for Kusama is KSM. For more information about KSM, visit the [Native Assets](https://wiki.polkadot.com/kusama/kusama-getting-started/){target=\_blank} page.
-
-## Test Networks
-
-The following test networks provide controlled environments for testing upgrades and new features. TestNet tokens are available from the [Polkadot faucet](https://faucet.polkadot.io/){target=\_blank}.
-
-### Westend
-
-Westend is Polkadot's primary permanent TestNet. Unlike temporary test networks, Westend is not reset to the genesis block, making it an ongoing environment for testing Polkadot core features. Managed by Parity Technologies, Westend ensures that developers can test features in a real-world simulation without using actual tokens.
-
-The native token for Westend is WND. More details about WND can be found on the [Native Assets](https://wiki.polkadot.com/learn/learn-dot/#__tabbed_2_2){target=\_blank} page.
-
-### Paseo
-
-[Paseo](https://github.com/paseo-network){target=\_blank} is a community-managed TestNet designed for parachain and dApp developers. It mirrors Polkadot's runtime and is maintained by Polkadot community members. Paseo provides a dedicated space for parachain developers to test their applications in a Polkadot-like environment without the risks associated with live networks.
-
-The native token for Paseo is PAS. Additional information on PAS is available on the [Native Assets](https://wiki.polkadot.com/learn/learn-dot/#__tabbed_2_1){target=\_blank} page.
-
-## Local Test Networks
-
-Local test networks are an essential part of the development cycle for blockchain developers using the Polkadot SDK. They allow for fast, iterative testing in controlled, private environments without connecting to public TestNets. Developers can quickly spin up local instances to experiment, debug, and validate their code before deploying to larger TestNets like Westend or Paseo. Two key tools for local network testing are Zombienet and Chopsticks.
-
-### Zombienet
-
-[Zombienet](https://github.com/paritytech/zombienet){target=\_blank} is a flexible testing framework for Polkadot SDK-based blockchains. It enables developers to create and manage ephemeral, short-lived networks. This feature makes Zombienet particularly useful for quick iterations, as it allows you to run multiple local networks concurrently, mimicking different runtime conditions. Whether you're developing a parachain or testing your custom blockchain logic, Zombienet gives you the tools to automate local testing.
-
-Key features of Zombienet include:
-
-- Creating dynamic, local networks with different configurations.
-- Running parachains and relay chains in a simulated environment.
-- Efficient testing of network components like cross-chain messaging and governance.
-
-Zombienet is ideal for developers looking to test quickly and thoroughly before moving to more resource-intensive public TestNets.
-
-### Chopsticks
-
-[Chopsticks](https://github.com/AcalaNetwork/chopsticks){target=\_blank} is a tool designed to create forks of Polkadot SDK-based blockchains, allowing developers to interact with network forks as part of their testing process. This capability makes Chopsticks a powerful option for testing upgrades, runtime changes, or cross-chain applications in a forked network environment.
-
-Key features of Chopsticks include:
-
-- Forking live Polkadot SDK-based blockchains for isolated testing.
-- Simulating cross-chain messages in a private, controlled setup.
-- Debugging network behavior by interacting with the fork in real-time.
-
-Chopsticks provides a controlled environment for developers to safely explore the effects of runtime changes. It ensures that network behavior is tested and verified before upgrades are deployed to live networks.
-
-
----
-
-Page Title: Node and Runtime
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-node-and-runtime.md
-- Canonical (HTML): https://docs.polkadot.com/reference/parachains/node-and-runtime/
-- Summary: Learn how Polkadot SDK-based nodes function, how the client and runtime are separated, and how they communicate using SCALE-encoded data.
-
-# Node and Runtime
-
-## Introduction
-
-Every blockchain platform relies on a decentralized network of computers, called nodes, that communicate with each other about transactions and blocks. In this context, a node refers to the software running on the connected devices rather than the physical or virtual machines in the network.
-
-Polkadot SDK-based nodes consist of two main components, each with distinct responsibilities: the client (also called node) and the runtime.
-
-If the system were a monolithic protocol, any modification would require updating the entire system. Instead, Polkadot achieves true upgradeability by defining an immutable meta-protocol (the client) and a protocol (the runtime) that can be upgraded independently.
-
-This separation gives the [Polkadot Relay Chain](/polkadot-protocol/architecture/polkadot-chain){target=\_blank} and all connected [parachains](/polkadot-protocol/architecture/parachains){target=\_blank} an evolutionary advantage over other blockchain platforms.
-
-## Architectural Principles
-
-The Polkadot SDK-based blockchain architecture is fundamentally built on two distinct yet interconnected components:
-
-- Client (Meta-protocol):
- - Handles the foundational infrastructure of the blockchain.
- - Manages runtime execution, networking, consensus, and other off-chain components.
- - Provides an immutable base layer that ensures network stability.
- - Upgradable only through hard forks.
-
-- Runtime (Protocol):
- - Defines the blockchain's state transition logic.
- - Determines the specific rules and behaviors of the blockchain.
- - Compiled to WebAssembly (Wasm) for platform-independent execution.
- - Capable of being upgraded without network-wide forking.
-
-### Advantages of this Architecture
-
-- **Forkless upgrades**: Runtime can be updated without disrupting the entire network.
-- **Modularity**: Clear separation allows independent development of client and runtime.
-- **Flexibility**: Enables rapid iteration and evolution of blockchain logic.
-- **Performance**: WebAssembly compilation provides efficient, cross-platform execution.
-
-## Node (Client)
-
-The node, also known as the client, is the core component responsible for executing the Wasm runtime and orchestrating various essential blockchain components. It ensures the correct execution of the state transition function and manages multiple critical subsystems, including:
-
-- **Wasm execution**: Runs the blockchain runtime, which defines the state transition rules.
-- **Database management**: Stores blockchain data.
-- **Networking**: Facilitates peer-to-peer communication, block propagation, and transaction gossiping.
-- **Transaction pool (Mempool)**: Manages pending transactions before they are included in a block.
-- **Consensus mechanism**: Ensures agreement on the blockchain state across nodes.
-- **RPC services**: Provides external interfaces for applications and users to interact with the node.
-
-## Runtime
-
-The runtime is more than just a set of rules. It's the fundamental logic engine that defines a blockchain's entire behavior. In Polkadot SDK-based blockchains, the runtime represents a complete, self-contained description of the blockchain's state transition function.
-
-### Characteristics
-
-The runtime is distinguished by three key characteristics:
-
-- **Business logic**: Defines the complete application-specific blockchain behavior.
-- **WebAssembly compilation**: Ensures platform-independent, secure execution.
-- **On-chain storage**: Stored within the blockchain's state, allowing dynamic updates.
-
-### Key Functions
-
-The runtime performs several critical functions, such as:
-
-- Define state transition rules.
-- Implement blockchain-specific logic.
-- Manage account interactions.
-- Control transaction processing.
-- Define governance mechanisms.
-- Handle custom pallets and modules.
-
-## Communication Between Node and Runtime
-
-The client and runtime communicate exclusively using [SCALE-encoded](/polkadot-protocol/parachain-basics/data-encoding){target=\_blank} communication. This ensures efficient and compact data exchange between the two components.
-
-### Runtime APIs
-
-The Runtime API consists of well-defined functions and constants a client assumes are implemented in the Runtime Wasm blob. These APIs enable the client to interact with the runtime to execute blockchain operations and retrieve information. The client invokes these APIs to:
-
-- Build, execute, and finalize blocks.
-- Access metadata.
-- Access consensus related information.
-- Handle transaction execution.
-
-### Host Functions
-
-During execution, the runtime can access certain external client functionalities via host functions. The specific functions the client exposes allow the runtime to perform operations outside the WebAssembly domain. Host functions enable the runtime to:
-
-- Perform cryptographic operations.
-- Access the current blockchain state.
-- Handle storage modifications.
-- Allocate memory.
-
-
----
-
-Page Title: On-Chain Governance Overview
-
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-governance.md
-- Canonical (HTML): https://docs.polkadot.com/reference/governance/
-- Summary: Discover Polkadot’s cutting-edge OpenGov system, enabling transparent, decentralized decision-making through direct democracy and flexible governance tracks.
-
-# On-Chain Governance
-
-## Introduction
-
-Polkadot’s governance system exemplifies decentralized decision-making, empowering its community of stakeholders to shape the network’s future through active participation. The latest evolution, OpenGov, builds on Polkadot’s foundation by providing a more inclusive and efficient governance model.
-
-This guide will explain the principles and structure of OpenGov and walk you through its key components, such as Origins, Tracks, and Delegation. You will learn about improvements over earlier governance systems, including streamlined voting processes and enhanced stakeholder participation.
-
-With OpenGov, Polkadot achieves a flexible, scalable, and democratic governance framework that allows multiple proposals to proceed simultaneously, ensuring the network evolves in alignment with its community's needs.
-
-## Governance Evolution
-
-Polkadot’s governance journey began with [Governance V1](https://wiki.polkadot.com/learn/learn-polkadot-opengov/#governance-summary){target=\_blank}, a system that proved effective in managing treasury funds and protocol upgrades. However, it faced limitations, such as:
-
-- Slow voting cycles, causing delays in decision-making.
-- Inflexibility in handling multiple referendums, restricting scalability.
-
-To address these challenges, Polkadot introduced OpenGov, a governance model designed for greater inclusivity, efficiency, and scalability. OpenGov replaces the centralized structures of Governance V1, such as the Council and Technical Committee, with a fully decentralized and dynamic framework.
-
-For a full comparison of the historic and current governance models, visit the [Gov1 vs. Polkadot OpenGov](https://wiki.polkadot.com/learn/learn-polkadot-opengov/#gov1-vs-polkadot-opengov){target=\_blank} section of the Polkadot Wiki.
-
-## OpenGov Key Features
-
-OpenGov transforms Polkadot’s governance into a decentralized, stakeholder-driven model, eliminating centralized decision-making bodies like the Council. Key enhancements include:
-
-- **Decentralization**: Shifts all decision-making power to the public, ensuring a more democratic process.
-- **Enhanced delegation**: Allows users to delegate their votes to trusted experts across specific governance tracks.
-- **Simultaneous referendums**: Multiple proposals can progress at once, enabling faster decision-making.
-- **Polkadot Technical Fellowship**: A broad, community-driven group replacing the centralized Technical Committee.
-
-This new system ensures Polkadot governance remains agile and inclusive, even as the ecosystem grows.
-
-## Origins and Tracks
-
-In OpenGov, origins and tracks are central to managing proposals and votes.
-
-- **Origin**: Determines the authority level of a proposal (e.g., Treasury, Root) which decides the track of all referendums from that origin.
-- **Track**: Define the procedural flow of a proposal, such as voting duration, approval thresholds, and enactment timelines.
-
-Developers must be aware that referendums from different origins and tracks will take varying amounts of time to reach approval and enactment. The [Polkadot Technical Fellowship](https://wiki.polkadot.com/learn/learn-polkadot-technical-fellowship/){target=\_blank} has the option to shorten this timeline by whitelisting a proposal and allowing it to be enacted through the [Whitelist Caller](https://wiki.polkadot.com/learn/learn-polkadot-opengov-origins/#whitelisted-caller){target=\_blank} origin.
-
-Visit [Origins and Tracks Info](https://wiki.polkadot.com/learn/learn-polkadot-opengov/#origins-and-tracks){target=\_blank} for details on current origins and tracks, associated terminology, and parameters.
-
-## Referendums
-
-In OpenGov, anyone can submit a referendum, fostering an open and participatory system. The timeline for a referendum depends on the privilege level of the origin with more significant changes offering more time for community voting and participation before enactment.
-
-The timeline for an individual referendum includes four distinct periods:
-
-- **Lead-in**: A minimum amount of time to allow for community participation, available room in the origin, and payment of the decision deposit. Voting is open during this period.
-- **Decision**: Voting continues.
-- **Confirmation**: Referendum must meet [approval and support](https://wiki.polkadot.com/learn/learn-polkadot-opengov/#approval-and-support){target=\_blank} criteria during entire period to avoid rejection.
-- **Enactment**: Changes approved by the referendum are executed.
-
-### Vote on Referendums
-
-Voters can vote with their tokens on each referendum. Polkadot uses a voluntary token locking mechanism, called conviction voting, as a way for voters to increase their voting power. A token holder signals they have a stronger preference for approving a proposal based upon their willingness to lock up tokens. Longer voluntary token locks are seen as a signal of continual approval and translate to increased voting weight.
-
-See [Voting on a Referendum](https://wiki.polkadot.com/learn/learn-polkadot-opengov/#voting-on-a-referendum){target=\_blank} for a deeper look at conviction voting and related token locks.
-
-### Delegate Voting Power
-
-The OpenGov system also supports multi-role delegations, allowing token holders to assign their voting power on different tracks to entities with expertise in those areas.
-
-For example, if a token holder lacks the technical knowledge to evaluate proposals on the [Root track](https://wiki.polkadot.com/learn/learn-polkadot-opengov-origins/#root){target=\_blank}, they can delegate their voting power for that track to an expert they trust to vote in the best interest of the network. This ensures informed decision-making across tracks while maintaining flexibility for token holders.
-
-Visit [Multirole Delegation](https://wiki.polkadot.com/learn/learn-polkadot-opengov/#multirole-delegation){target=\_blank} for more details on delegating voting power.
-
-### Cancel a Referendum
-
-Polkadot OpenGov has two origins for rejecting ongoing referendums:
-
-- [**Referendum Canceller**](https://wiki.polkadot.com/learn/learn-polkadot-opengov-origins/#referendum-canceller){target=\_blank}: Cancels an active referendum when non-malicious errors occur and refunds the deposits to the originators.
-- [**Referendum Killer**](https://wiki.polkadot.com/learn/learn-polkadot-opengov-origins/#referendum-killer){target=\_blank}: Used for urgent, malicious cases this origin instantly terminates an active referendum and slashes deposits.
-
-See [Cancelling, Killing, and Blacklisting](https://wiki.polkadot.com/learn/learn-polkadot-opengov/#cancelling-killing--blacklisting){target=\_blank} for additional information on rejecting referendums.
-
-## Additional Resources
-
-- **[Democracy pallet](https://github.com/paritytech/polkadot-sdk/tree/polkadot-stable2506-2/substrate/frame/democracy/src){target=\_blank}**: Handles administration of general stakeholder voting.
-- **[Gov2: Polkadot’s Next Generation of Decentralised Governance](https://medium.com/polkadot-network/gov2-polkadots-next-generation-of-decentralised-governance-4d9ef657d11b){target=\_blank}**: Medium article by Gavin Wood.
-- **[Polkadot Direction](https://matrix.to/#/#Polkadot-Direction:parity.io){target=\_blank}**: Matrix Element client.
-- **[Polkassembly](https://polkadot.polkassembly.io/){target=\_blank}**: OpenGov dashboard and UI.
-- **[Polkadot.js Apps Governance](https://polkadot.js.org/apps/#/referenda){target=\_blank}**: Overview of active referendums.
-
-
---
Page Title: Oracles
@@ -6262,3677 +4721,1358 @@ This section covers the most common customization patterns you'll encounter:
---
-Page Title: Overview of the Polkadot Relay Chain
+Page Title: Run a Parachain Network
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-polkadot-hub-consensus-and-security-relay-chain.md
-- Canonical (HTML): https://docs.polkadot.com/reference/polkadot-hub/consensus-and-security/relay-chain/
-- Summary: Explore Polkadot's core architecture, including its multi-chain vision, shared security, and the DOT token's governance and staking roles.
+- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/parachains-testing-run-a-parachain-network.md
+- Canonical (HTML): https://docs.polkadot.com/parachains/testing/run-a-parachain-network/
+- Summary: Quickly install and configure Zombienet to deploy and test Polkadot-based blockchain networks with this comprehensive getting-started guide.
-# Overview
+# Run a Parachain Network Using Zombienet
## Introduction
-Polkadot is a next-generation blockchain protocol designed to support a multi-chain future by enabling secure communication and interoperability between different blockchains. Built as a Layer-0 protocol, Polkadot introduces innovations like application-specific Layer-1 chains ([parachains](/polkadot-protocol/architecture/parachains/){targe=\_blank}), shared security through [Nominated Proof of Stake (NPoS)](/reference/glossary/#nominated-proof-of-stake-npos){target=\_blank}, and cross-chain interactions via its native [Cross-Consensus Messaging Format (XCM)](/parachains/interoperability/get-started/){target=\_blank}.
+Zombienet is a robust testing framework designed for Polkadot SDK-based blockchain networks. It enables developers to efficiently deploy and test ephemeral blockchain environments on platforms like Kubernetes, Podman, and native setups. With its simple and versatile CLI, Zombienet provides an all-in-one solution for spawning networks, running tests, and validating performance.
-This guide covers key aspects of Polkadot’s architecture, including its high-level protocol structure, blockspace commoditization, and the role of its native token, DOT, in governance, staking, and resource allocation.
+This guide will outline the different installation methods for Zombienet, provide step-by-step instructions for setting up on various platforms, and highlight essential provider-specific features and requirements.
-## Polkadot 1.0
+By following this guide, Zombienet will be up and running quickly, ready to streamline your blockchain testing and development workflows.
-Polkadot 1.0 represents the state of Polkadot as of 2023, coinciding with the release of [Polkadot runtime v1.0.0](https://github.com/paritytech/polkadot/releases/tag/v1.0.0){target=\_blank}. This section will focus on Polkadot 1.0, along with philosophical insights into network resilience and blockspace.
+## Install Zombienet
-As a Layer-0 blockchain, Polkadot contributes to the multi-chain vision through several key innovations and initiatives, including:
+Zombienet releases are available on the [Zombienet repository](https://github.com/paritytech/zombienet){target=\_blank}.
-- **Application-specific Layer-1 blockchains (parachains)**: Polkadot's sharded network allows for parallel transaction processing, with shards that can have unique state transition functions, enabling custom-built L1 chains optimized for specific applications.
+Multiple options are available for installing Zombienet, depending on the user's preferences and the environment where it will be used. The following section will guide you through the installation process for each option.
-- **Shared security and scalability**: L1 chains connected to Polkadot benefit from its [Nominated Proof of Stake (NPoS)](/reference/polkadot-hub/consensus-and-security/pos-consensus/#nominated-proof-of-stake){target=\_blank} system, providing security out-of-the-box without the need to bootstrap their own.
+=== "Use the executable"
-- **Secure interoperability**: Polkadot's native interoperability enables seamless data and value exchange between parachains. This interoperability can also be used outside of the ecosystem for bridging with external networks.
+ Install Zombienet using executables by visiting the [latest release](https://github.com/paritytech/zombienet/releases){target=\_blank} page and selecting the appropriate asset for your operating system. You can download the executable and move it to a directory in your PATH.
-- **Resilient infrastructure**: Decentralized and scalable, Polkadot ensures ongoing support for development and community initiatives via its on-chain [treasury](https://wiki.polkadot.com/learn/learn-polkadot-opengov-treasury/){target=\_blank} and governance.
+ Each release includes executables for Linux and macOS. Executables are generated using [pkg](https://github.com/vercel/pkg){target=\_blank}, which allows the Zombienet CLI to operate without requiring Node.js to be installed.
-- **Rapid L1 development**: The [Polkadot SDK](/reference/parachains/){target=\_blank} allows fast, flexible creation and deployment of Layer-1 chains.
+ Then, ensure the downloaded file is executable:
-- **Cultivating the next generation of Web3 developers**: Polkadot supports the growth of Web3 core developers through initiatives such as.
+ ```bash
+ chmod +x zombienet-macos-arm64
+ ```
- - [Polkadot Blockchain Academy](https://polkadot.com/blockchain-academy){target=\_blank}
- - [EdX courses](https://www.edx.org/school/web3x){target=\_blank}
- - Rust and Substrate courses (coming soon)
+ Finally, you can run the following command to check if the installation was successful. If so, it will display the version of the installed Zombienet:
-### High-Level Architecture
+ ```bash
+ ./zombienet-macos-arm64 version
+ ```
-Polkadot features a chain that serves as the central component of the system. This chain is depicted as a ring encircled by several parachains that are connected to it.
+ If you want to add the `zombienet` executable to your PATH, you can move it to a directory in your PATH, such as `/usr/local/bin`:
-According to Polkadot's design, any blockchain that can compile to WebAssembly (Wasm) and adheres to the Parachains Protocol becomes a parachain on the Polkadot network.
+ ```bash
+ mv zombienet-macos-arm64 /usr/local/bin/zombienet
+ ```
-Here’s a high-level overview of the Polkadot protocol architecture:
+ Now you can refer to the `zombienet` executable directly.
-{ style="background:white" }
+ ```bash
+ zombienet version
+ ```
-Parachains propose blocks to Polkadot validators, who check for availability and validity before finalizing them. With the relay chain providing security, collators—full nodes of parachains—can focus on their tasks without needing strong incentives.
+=== "Use Nix"
-The [Cross-Consensus Messaging Format (XCM)](/parachains/interoperability/get-started/){target=\_blank} allows parachains to exchange messages freely, leveraging the chain's security for trust-free communication.
+ For Nix users, the Zombienet repository provides a [`flake.nix`](https://github.com/paritytech/zombienet/blob/main/flake.nix){target=\_blank} file to install Zombienet making it easy to incorporate Zombienet into Nix-based projects.
+
+ To install Zombienet utilizing Nix, users can run the following command, triggering the fetching of the flake and subsequently installing the Zombienet package:
-In order to interact with chains that want to use their own finalization process (e.g., Bitcoin), Polkadot has [bridges](/reference/parachains/interoperability/#bridges-connecting-external-networks){target=\_blank} that offer two-way compatibility, meaning that transactions can be made between different parachains.
+ ```bash
+ nix run github:paritytech/zombienet/INSERT_ZOMBIENET_VERSION -- \
+ spawn INSERT_ZOMBIENET_CONFIG_FILE_NAME.toml
+ ```
-### Polkadot's Additional Functionalities
+ Replace the `INSERT_ZOMBIENET_VERSION` with the desired version of Zombienet and the `INSERT_ZOMBIENET_CONFIG_FILE_NAME` with the name of the configuration file you want to use.
-Historically, obtaining core slots on Polkadot chain relied upon crowdloans and auctions. Chain cores were leased through auctions for three-month periods, up to a maximum of two years. Crowdloans enabled users to securely lend funds to teams for lease deposits in exchange for pre-sale tokens, which is the only way to access slots on Polkadot 1.0. Auctions are now deprecated in favor of [coretime](/polkadot-protocol/architecture/system-chains/coretime/){target=\_blank}.
+ To run the command above, you need to have [Flakes](https://nixos.wiki/wiki/Flakes#Enable_flakes){target=\_blank} enabled.
-Additionally, the chain handles [staking](https://wiki.polkadot.com/learn/learn-staking/){target=\_blank}, [accounts](/reference/parachains/accounts/){target=\_blank}, balances, and [governance](/reference/governance/){target=\_blank}.
+ Alternatively, you can also include the Zombienet binary in the PATH for the current shell using the following command:
+
+ ```bash
+ nix shell github:paritytech/zombienet/INSERT_ZOMBIENET_VERSION
+ ```
-#### Agile Coretime
+=== "Use Docker"
-The new and more efficient way of obtaining core on Polkadot is to go through the process of purchasing coretime.
+ Zombienet can also be run using Docker. The Zombienet repository provides a Docker image that can be used to run the Zombienet CLI. To run Zombienet using Docker, you can use the following command:
-[Agile coretime](/reference/polkadot-hub/consensus-and-security/agile-coretime/){target=\_blank} improves the efficient use of Polkadot's network resources and offers economic flexibility for developers, extending Polkadot's capabilities far beyond the original vision outlined in the [whitepaper](https://polkadot.com/papers/Polkadot-whitepaper.pdf){target=\_blank}.
+ ```bash
+ docker run -it --rm \
+ -v $(pwd):/home/nonroot/zombie-net/host-current-files \
+ paritytech/zombienet
+ ```
-It enables parachains to purchase monthly "bulk" allocations of coretime (the time allocated for utilizing a core, measured in Polkadot relay chain blocks), ensuring heavy-duty parachains that can author a block every six seconds with [Asynchronous Backing](https://wiki.polkadot.com/learn/learn-async-backing/#asynchronous-backing){target=\_blank} can reliably renew their coretime each month. Although six-second block times are now the default, parachains have the option of producing blocks less frequently.
+ The command above will run the Zombienet CLI inside a Docker container and mount the current directory to the `/home/nonroot/zombie-net/host-current-files` directory. This allows Zombienet to access the configuration file and other files in the current directory. If you want to mount a different directory, replace `$(pwd)` with the desired directory path.
-Renewal orders are prioritized over new orders, offering stability against price fluctuations and helping parachains budget more effectively for project costs.
+ Inside the Docker container, you can run the Zombienet CLI commands. First, you need to set up Zombienet to download the necessary binaries:
-### Polkadot's Resilience
-
-Decentralization is a vital component of blockchain networks, but it comes with trade-offs:
-
-- An overly decentralized network may face challenges in reaching consensus and require significant energy to operate.
-- Also, a network that achieves consensus quickly risks centralization, making it easier to manipulate or attack.
-
-A network should be decentralized enough to prevent manipulative or malicious influence. In this sense, decentralization is a tool for achieving resilience.
+ ```bash
+ npm run zombie -- setup polkadot polkadot-parachain
+ ```
-Polkadot 1.0 currently achieves resilience through several strategies:
+ After that, you need to add those binaries to the PATH:
-- **Nominated Proof of Stake (NPoS)**: Ensures that the stake per validator is maximized and evenly distributed among validators.
+ ```bash
+ export PATH=/home/nonroot/zombie-net:$PATH
+ ```
-- **Decentralized nodes**: Designed to encourage operators to join the network. This program aims to expand and diversify the validators in the ecosystem who aim to become independent of the program during their term. Feel free to explore more about the program on the official [Decentralized Nodes](https://nodes.web3.foundation/){target=\_blank} page.
+ Finally, you can run the Zombienet CLI commands. For example, to spawn a network using a specific configuration file, you can run the following command:
-- **On-chain treasury and governance**: Known as [OpenGov](/reference/governance/){target=\_blank}, this system allows every decision to be made through public referenda, enabling any token holder to cast a vote.
+ ```bash
+ npm run zombie -- -p native spawn host-current-files/minimal.toml
+ ```
-### Polkadot's Blockspace
+ The command above mounts the current directory to the `/workspace` directory inside the Docker container, allowing Zombienet to access the configuration file and other files in the current directory. If you want to mount a different directory, replace `$(pwd)` with the desired directory path.
-Polkadot 1.0’s design allows for the commoditization of blockspace.
+## Providers
-Blockspace is a blockchain's capacity to finalize and commit operations, encompassing its security, computing, and storage capabilities. Its characteristics can vary across different blockchains, affecting security, flexibility, and availability.
+Zombienet supports different backend providers for running the nodes. At this moment, [Kubernetes](https://kubernetes.io/){target=\_blank}, [Podman](https://podman.io/){target=\_blank}, and local providers are supported, which can be declared as `kubernetes`, `podman`, or `native`, respectively.
-- **Security**: Measures the robustness of blockspace in Proof of Stake (PoS) networks linked to the stake locked on validator nodes, the variance in stake among validators, and the total number of validators. It also considers social centralization (how many validators are owned by single operators) and physical centralization (how many validators run on the same service provider).
+To use a particular provider, you can specify it in the network file or use the `--provider` flag in the CLI:
-- **Flexibility**: Reflects the functionalities and types of data that can be stored, with high-quality data essential to avoid bottlenecks in critical processes.
+```bash
+zombienet spawn network.toml --provider INSERT_PROVIDER
+```
-- **Availability**: Indicates how easily users can access blockspace. It should be easily accessible, allowing diverse business models to thrive, ideally regulated by a marketplace based on demand and supplemented by options for "second-hand" blockspace.
+Alternatively, you can set the provider in the network file:
-Polkadot is built on core blockspace principles, but there's room for improvement. Tasks like balance transfers, staking, and governance are managed on the relay chain.
+```toml
+[settings]
+provider = "INSERT_PROVIDER"
+...
+```
-Delegating these responsibilities to [system chains](/polkadot-protocol/architecture/system-chains/){target=\_blank} could enhance flexibility and allow the relay chain to concentrate on providing shared security and interoperability.
+It's important to note that each provider has specific requirements and associated features. The following sections cover each provider's requirements and added features.
-For more information about blockspace, watch [Robert Habermeier’s interview](https://www.youtube.com/watch?v=e1vISppPwe4){target=\_blank} or read his [technical blog post](https://www.rob.tech/blog/polkadot-blockspace-over-blockchains/){target=\_blank}.
+### Kubernetes
-## DOT Token
+Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services. Zombienet is designed to be compatible with a variety of Kubernetes clusters, including:
-DOT is the native token of the Polkadot network, much like BTC for Bitcoin and Ether for the Ethereum blockchain. DOT has 10 decimals, uses the Planck base unit, and has a balance type of `u128`. The same is true for Kusama's KSM token with the exception of having 12 decimals.
+- [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine){target=\_blank}
+- [Docker Desktop](https://docs.docker.com/desktop/features/kubernetes/){target=\_blank}
+- [kind](https://kind.sigs.k8s.io/){target=\_blank}
-### Redenomination of DOT
+#### Requirements
-Polkadot conducted a community poll, which ended on 27 July 2020 at block 888,888, to decide whether to redenominate the DOT token. The stakeholders chose to redenominate the token, changing the value of 1 DOT from 1e12 plancks to 1e10 plancks.
-
-Importantly, this did not affect the network's total number of base units (plancks); it only affects how a single DOT is represented. The redenomination became effective 72 hours after transfers were enabled, occurring at block 1,248,328 on 21 August 2020 around 16:50 UTC.
-
-### The Planck Unit
-
-The smallest unit of account balance on Polkadot SDK-based blockchains (such as Polkadot and Kusama) is called _Planck_, named after the Planck length, the smallest measurable distance in the physical universe.
-
-Similar to how BTC's smallest unit is the Satoshi and ETH's is the Wei, Polkadot's native token DOT equals 1e10 Planck, while Kusama's native token KSM equals 1e12 Planck.
-
-### Uses for DOT
+To effectively interact with your cluster, you'll need to ensure that [`kubectl`](https://kubernetes.io/docs/reference/kubectl/){target=\_blank} is installed on your system. This Kubernetes command-line tool allows you to run commands against Kubernetes clusters. If you don't have `kubectl` installed, you can follow the instructions provided in the [Kubernetes documentation](https://kubernetes.io/docs/tasks/tools/#kubectl){target=\_blank}.
-DOT serves three primary functions within the Polkadot network:
+To create resources such as namespaces, pods, and CronJobs within the target cluster, you must grant your user or service account the appropriate permissions. These permissions are essential for managing and deploying applications effectively within Kubernetes.
-- **Governance**: It is used to participate in the governance of the network.
-- **Staking**: DOT is staked to support the network's operation and security.
-- **Buying coretime**: Used to purchase coretime in-bulk or on-demand and access the chain to benefit from Polkadot's security and interoperability.
+#### Features
+
+If available, Zombienet uses the Prometheus operator to oversee monitoring and visibility. This configuration ensures that only essential networking-related pods are deployed. Using the Prometheus operator, Zombienet improves its ability to monitor and manage network activities within the Kubernetes cluster efficiently.
-Additionally, DOT can serve as a transferable token. For example, DOT, held in the treasury, can be allocated to teams developing projects that benefit the Polkadot ecosystem.
+### Podman
-## JAM and the Road Ahead
+Podman is a daemonless container engine for developing, managing, and running Open Container Initiative (OCI) containers and container images on Linux-based systems. Zombienet supports Podman rootless as a provider on Linux machines. Although Podman has support for macOS through an internal virtual machine (VM), the Zombienet provider code requires Podman to run natively on Linux.
-The Join-Accumulate Machine (JAM) represents a transformative redesign of Polkadot's core architecture, envisioned as the successor to the current relay chain. Unlike traditional blockchain architectures, JAM introduces a unique computational model that processes work through two primary functions:
+#### Requirements
+
+To use Podman as a provider, you need to have Podman installed on your system. You can install Podman by following the instructions provided on the [Podman website](https://podman.io/getting-started/installation){target=\_blank}.
-- **Join**: Handles data integration.
-- **Accumulate**: Folds computations into the chain's state.
+#### Features
+
+Using Podman, Zombienet deploys additional pods to enhance the monitoring and visibility of the active network. Specifically, pods for [Prometheus](https://prometheus.io/){target=\_blank}, [Tempo](https://grafana.com/docs/tempo/latest/operations/monitor/){target=\_blank}, and [Grafana](https://grafana.com/){target=\_blank} are included in the deployment. Grafana is configured with Prometheus and Tempo as data sources.
-JAM removes many of the opinions and constraints of the current relay chain while maintaining its core security properties. Expected improvements include:
+Upon launching Zombienet, access to these monitoring services is facilitated through specific URLs provided in the output:
-- **Permissionless code execution**: JAM is designed to be more generic and flexible, allowing for permissionless code execution through services that can be deployed without governance approval.
-- **More effective block time utilization**: JAM's efficient pipeline processing model places the prior state root in block headers instead of the posterior state root, enabling more effective utilization of block time for computations.
+- **Prometheus**: `http://127.0.0.1:34123`
+- **Tempo**: `http://127.0.0.1:34125`
+- **Grafana**: `http://127.0.0.1:41461`
-This architectural evolution promises to enhance Polkadot's scalability and flexibility while maintaining robust security guarantees. JAM is planned to be rolled out to Polkadot as a single, complete upgrade rather than a stream of smaller updates. This approach seeks to minimize the developer overhead required to address any breaking changes.
+It's important to note that Grafana is deployed with default administrator access.
+
+When network operations cease, either from halting a running spawn with the `Ctrl+C` command or test completion, Zombienet automatically removes all associated pods.
+### Local Provider
----
+The Zombienet local provider, also called native, enables you to run nodes as local processes in your environment.
-Page Title: Parachains Overview
+#### Requirements
+
+You must have the necessary binaries for your network (such as `polkadot` and `polkadot-parachain`). These binaries should be available in your PATH, allowing Zombienet to spawn the nodes as local processes.
-- Source (raw): https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains.md
-- Canonical (HTML): https://docs.polkadot.com/reference/parachains/
-- Summary: Learn about parachains, specialized blockchains on Polkadot that gain shared security and interoperability. Discover how they work and the tools to build them.
+To install the necessary binaries, you can use the Zombienet CLI command:
-# Parachains Overview
+```bash
+zombienet setup polkadot polkadot-parachain
+```
-## Introduction
+This command will download and prepare the necessary binaries for Zombienet's use.
-A parachain is a specialized blockchain that connects to the Polkadot relay chain, benefiting from shared security, interoperability, and scalability. Parachains are built using the [Polkadot SDK](https://github.com/paritytech/polkadot-sdk){target=\_blank}, a powerful toolkit written in Rust that provides everything needed to create custom blockchain logic while integrating seamlessly with the Polkadot network.
+If you need to use a custom binary, ensure the binary is available in your PATH. You can also specify the binary path in the network configuration file. The following example uses the custom [OpenZeppelin template](https://github.com/OpenZeppelin/polkadot-runtime-templates){target=\_blank}:
-Unlike standalone blockchains that must bootstrap their own validator sets and security, parachains leverage Polkadot's pooled security model. This allows parachain developers to focus on their application-specific functionality rather than consensus and security infrastructure. Parachains can communicate with each other through Cross-Consensus Messaging (XCM), enabling seamless interoperability across the Polkadot ecosystem.
+First, clone the OpenZeppelin template repository using the following command:
-Key capabilities that parachains provide include:
+```bash
+git clone https://github.com/OpenZeppelin/polkadot-runtime-templates \
+&& cd polkadot-runtime-templates/generic-template
+```
-- **Shared security**: Inherit security from Polkadot's validator set without maintaining your own.
-- **Interoperability**: Communicate trustlessly with other parachains via XCM.
-- **Scalability**: Process transactions in parallel with other parachains.
-- **Customization**: Build application-specific logic tailored to your use case.
-- **Upgradeability**: Upgrade runtime logic without hard forks.
+Next, run the command to build the custom binary:
-## Polkadot SDK: Parachain Architecture
+```bash
+cargo build --release
+```
-Building a parachain involves understanding and utilizing several key components of the Polkadot SDK:
+Finally, add the custom binary to your PATH as follows:
-
+```bash
+export PATH=$PATH:INSERT_PATH_TO_RUNTIME_TEMPLATES/parachain-template-node/target/release
+```
-- **[Substrate](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/polkadot_sdk/substrate/index.html){target=\_blank}**: The foundation providing core blockchain primitives and libraries.
-- **[FRAME](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/polkadot_sdk/frame_runtime/index.html){target=\_blank}**: A modular framework for building your parachain's runtime logic.
-- **[Cumulus](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/polkadot_sdk/cumulus/index.html){target=\_blank}**: Essential libraries and pallets that enable parachain functionality.
-- **[XCM (Cross Consensus Messaging)](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/polkadot_sdk/xcm/index.html){target=\_blank}**: The messaging format for communicating with other parachains and the relay chain.
-- **[Polkadot](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/polkadot_sdk/polkadot/index.html){target=\_blank}**: The relay chain that provides security and coordination.
+Alternatively, you can specify the binary path in the network configuration file. The local provider exclusively utilizes the command configuration for nodes, which supports both relative and absolute paths. You can employ the `default_command` configuration to specify the binary for spawning all nodes in the relay chain.
-### Substrate: The Foundation
+```toml
+[relaychain]
+chain = "rococo-local"
+default_command = "./bin-v1.6.0/polkadot"
-Substrate provides the core infrastructure that every parachain is built upon. It handles the low-level blockchain functionality, allowing you to focus on your application's unique features. Substrate includes implementations for networking, database management, consensus participation, and the execution environment for your runtime.
+[parachain]
+id = 1000
-Every Polkadot SDK node consists of two main components:
+ [parachain.collators]
+ name = "collator01"
+ command = "./target/release/parachain-template-node"
+```
-- **Client (Host)**: Handles infrastructure services.
+#### Features
- - Native binary that runs on validator and collator nodes.
- - Executes the Wasm-compiled runtime.
- - Manages networking, database, mempool, and block production.
- - Interfaces with the relay chain for validation.
+The local provider does not offer any additional features.
-- **Runtime (State Transition Function)**: Contains your business logic.
+## Configure Zombienet
- - Defines how your Polkadot SDK node processes transactions.
- - Compiled to [Wasm](https://webassembly.org/){target=\_blank} for deterministic execution.
- - Stored on-chain and upgradeable via governance.
+Effective network configuration is crucial for deploying and managing blockchain systems. Zombienet simplifies this process by offering versatile configuration options in both JSON and TOML formats. Whether setting up a simple test network or a complex multi-node system, Zombienet's tools provide the flexibility to customize every aspect of your network's setup.
-```mermaid
-%%{init: {'flowchart': {'padding': 5, 'nodeSpacing': 50, 'rankSpacing': 10}}}%%
-graph TB
- classDef title font-size:20px,font-weight:bold,stroke-width:0px
- classDef clientStyle font-size:16px,font-weight:bold
- classDef clientSubNodeStyle margin-top:10px
- classDef runtimeCallExecutorStyle padding-top:10px
+The following sections will explore the structure and usage of Zombienet configuration files, explain key settings for network customization, and walk through CLI commands and flags to optimize your development workflow.
- subgraph sg1[ParachainNode] - direction TB +### Configuration Files - I[RuntimeCall Executor] - B[Wasm Runtime - STF] +The network configuration file can be either JSON or TOML format. The Zombienet repository also provides a collection of [example configuration files](https://github.com/paritytech/zombienet/tree/main/examples){target=\_blank} that can be used as a reference. - subgraph sg2[Client] - direction TB - C[Network and Blockchain
Infrastructure Services
+ Relay Chain Interface] - end +Each section may include provider-specific keys that aren't recognized by other providers. For example, if you use the local provider, any references to images for nodes will be disregarded. - I --> B - end +### CLI Usage - class sg1 title - class sg2 clientStyle - class C clientSubNodeStyle - class I runtimeCallExecutorStyle +Zombienet provides a CLI that allows interaction with the tool. The CLI can receive commands and flags to perform different kinds of operations. These operations use the following syntax: +```bash +zombienet
System]~~~A3[Transaction
Payment]~~~A4[Sudo] - B1[Identity]~~~B2[Balances]~~~B3[Assets]~~~B4[EVM] - C1[Timestamp]~~~C2[Staking]~~~C3[Contracts]~~~C4[and more...] - end - AP --> SP -``` - -### Cumulus: Parachain-Specific Functionality - -Cumulus is what transforms a Polkadot SDK-based runtime into a parachain-capable runtime. It provides the essential components for communicating with the relay chain, participating in Polkadot's consensus, and handling parachain-specific operations like block validation and collation. - -Key Cumulus components include: - -- **Parachain system pallet**: Core parachain functionality and relay chain communication. -- **Collator consensus**: Block production logic for parachain collators. -- **Relay chain interface**: APIs for interacting with the Polkadot relay chain. -- **Validation data**: Handling proof-of-validity data required by relay chain validators. - -## Where to Go Next - -Building a parachain requires understanding the relationship between your chain and the Polkadot relay chain. The Polkadot SDK provides all the tools needed to design custom runtime logic, enable cross-chain communication, and deploy your parachain to production. - -The following sections provide detailed guidance on each aspect of parachain development, from initial design through deployment and ongoing maintenance. +The following sections will guide you through the primary usage of the Zombienet CLI and the available commands and flags. -
+#### CLI Commands
-- Guide __Launch a Simple Parachain__
+- **`spawn `**: Spawn the network defined in the [configuration file](#configuration-files).
+- **`test `**: Run tests on the spawned network using the assertions and tests defined in the test file.
+- **`setup `**: Set up the Zombienet development environment to download and use the `polkadot` or `polkadot-parachain` executable.
+- **`convert `**: Transforms a [polkadot-launch](https://github.com/paritytech/polkadot-launch){target=\_blank} configuration file with a `.js` or `.json` extension into a Zombienet configuration file.
+- **`version`**: Prints Zombienet version.
+- **`help`**: Prints help information.
- ---
+#### CLI Flags
- Walk through the complete parachain launch flow: from setup and deployment to obtaining coretime.
+You can use the following flags to customize the behavior of the CLI:
- [:octicons-arrow-right-24: Deploy](/parachains/launch-a-parachain/set-up-the-parachain-template/)
+- **`-p`, `--provider`**: Override the [provider](#providers) to use.
+- **`-d`, `--dir`**: Specify a directory path for placing the network files instead of using the default temporary path.
+- **`-f`, `--force`**: Force override all prompt commands.
+- **`-l`, `--logType`**: Type of logging on the console. Defaults to `table`.
+- **`-m`, `--monitor`**: Start as monitor and don't auto clean up network.
+- **`-c`, `--spawn-concurrency`**: Number of concurrent spawning processes to launch. Defaults to `1`.
+- **`-h`, `--help`**: Display help for command.
+### Settings
--