Astar, a Substrate chain with three runtimes and a split versioning scheme

What Astar is and where it sits

Astar Network is described as an interoperable blockchain based on the Substrate framework and the hub for dApps within the Polkadot ecosystem. With Astar Network and Shiden Network, people can stake their tokens to a smart contract for rewarding projects that provide value to the network.

That is the two-sided description in the README, and it is worth separating. Astar is both a pair of live networks, Astar and Shiden, and the dApp hub for that ecosystem. The repository here is the node implementation, not the hub frontend, so anyone reading it to build a dApp is looking at the wrong artifact.

The technical substrate is Substrate, with a badge naming Substrate 3.0.0, and the topics list names Polkadot, Kusama, Plasm Network, EVM, WASM, staking and web3. The EVM and WASM pair tells you the design: the chain is a Substrate parachain with an Ethereum Virtual Machine layer, so Solidity contracts and Substrate pallets coexist.

The primary language is Rust, the licence is GPL-3.0, and the code is published by Stake Technologies, named as the workspace author in the Cargo.toml with the homepage astar.network. There is a Docker image for the collator under the staketechnologies organisation, and the project runs a Discord, a Telegram channel and a Medium publication.

The default branch is master and the last push was on 2026-10-22, so this is an actively maintained network rather than an archived experiment.

The three runtimes and why they matter

The Cargo.toml workspace members list is the clearest map of the project: bin/collator and bin/xcm-tools for the node binaries, runtime/astar, runtime/shiden and runtime/shibuya for the three runtimes, pallets/* and precompiles/* for the custom logic, primitives for shared types, tests/xcm-simulator and tests/integration for the test suites, and a long list of vendor/ entries.

Those vendor entries are the interesting part. They include vendor/evm-tracing, vendor/primitives/txpool, vendor/rpc/debug, vendor/rpc/trace and vendor/runtime/ext, with several more for primitives and rpc-core. These are forks of upstream Substrate or Polkadot code that Astar has patched, most visibly the EVM tracing and transaction pool code that the node needs to expose. A vendor directory in a Substrate workspace is not vendoring a third-party crate in the Cargo sense; the Cargo.toml excludes the vendor directory from the workspace resolver and treats each entry as its own crate.

Three runtimes means three networks. Astar and Shiden are the live public networks, and shibuya is the test network, which the Makefile confirms by running the integration test suite once per runtime with the corresponding feature flag:

SKIP_WASM_BUILD= ${cargo_test} -p integration-tests --features=shibuya
SKIP_WASM_BUILD= ${cargo_test} -p integration-tests --features=shiden
SKIP_WASM_BUILD= ${cargo_test} -p integration-tests --features=astar

That per-runtime testing is the operational consequence of running several networks from one codebase. A change to shared primitives has to be validated three times, and the recent release history shows runtime releases landing separately from the client, with runtime-2400 in August 2026 and runtime-2500 in September 2026.

The workspace also sets a production profile with lto enabled and codegen-units of 1, and a release profile with panic set to unwind, with the comment that the Astar runtime requires unwinding.

Building the node from source

The README's build section assumes macOS or a Debian variant and says that for Windows, although there are ways to run it, it recommends WSL or a virtual machine for stability.

The setup uses the automatic Substrate environment script, then clones the repository with submodules, then compiles:

$ curl https://getsubstrate.io -sSf | bash -s -- --fast
$ git clone --recurse-submodules https://github.com/AstarNetwork/Astar.git
$ cd Astar
$ cargo build --profile production
$ ./target/production/astar-collator --help

The README flags the most common failure in a note: you may encounter errors if the wasm32-unknown-unknown target is not installed, or if the toolchain channel is outdated. There is a rust-toolchain.toml in the repository root, which pins the channel the project expects, and the wasm target matters because a Substrate runtime is compiled to WASM.

There is a Nix path as well, which fetches a pinned nixpkgs channel:

$ curl https://nixos.org/nix/install | sh
$ nix-shell -I nixpkgs=channel:nixos-21.05 third-party/nix/shell.nix --run "cargo build --release"

Note that the nixpkgs channel here is nixos-21.05, which is old relative to the current date. That is the sort of detail that means a Nix build may need updating before it works on a current machine.

The Makefile provides the build and test entry points: make build for the release profile with the lock file enforced, make test for unit tests across the workspace, make test-features for the try-runtime, runtime-benchmarks and evm-tracing features, make test-runtimes for the per-runtime integration tests, and make test-all to run the lot. It also prefers cargo nextest when it is installed and falls back to cargo test otherwise.

Running a collator and the two-version release scheme

Running a collator means starting the node with the right arguments, and the README gives the Shiden example:

$ ./target/release/astar-collator \
  --base-path <path to save blocks> \
  --name <node display name> \
  --port 30333 \
  --rpc-port 9944 \
  --telemetry-url 'wss://telemetry.polkadot.io/submit/ 0' \
  --rpc-cors all \
  --collator

The session key is then obtained with an RPC call:

$ curl -H 'Content-Type: application/json' --data '{ "jsonrpc":"2.0", "method":"author_rotateKeys", "id":1 }' localhost:9933

which returns the key as hex, and the README notes the RPC port in that example, 9933, differs from the 9944 given in the node arguments.

The versioning scheme is the part with real consequences for operators. Up to v5.44.0, each release contained both the client and the runtime, following semantic versioning. From v5.45.0 the process splits: the client keeps semantic versioning, while the runtime follows a runtime-XXYY scheme where XX starts at 10 and increments by one, and YY is a two digit patch number. So runtime-1000 is followed by runtime-1100, and a fix to runtime-1000 becomes runtime-1001.

The Rust crate version aligns with it, with the major and minor matching the XXYY number and the patch always 00, so runtime-1100 corresponds to crate version 11.0.0 and runtime-1101 to 11.1.0.

That scheme exists because a runtime upgrade is a state transition on a live network, and coupling it to the client version forces node operators to upgrade the client when only the runtime changed. Separating them means the runtime can be patched on its own cadence, and the operator's job becomes watching two version streams instead of one.

Dependencies, lint policy and the shape of the contribution rules

The workspace dependency rules are strict and worth knowing before you open a pull request. All dependencies go in the root Cargo.toml so a crate version can be changed in one place for the whole repository.

There are two sharp edges. If no_std is required, default-features = false must be set in the root Cargo.toml, because otherwise it has no effect and the compilation fails. And package imports are not properly propagated from the root to sub-crates, so defining those should be avoided.

Features defined in the root Cargo.toml are additive with the features defined in a concrete crate's own Cargo.toml, which is how the per-runtime feature flags used by the test targets work.

The adding-a-dependency procedure is spelled out. Check whether the dependency is already defined in the root Cargo.toml and if so take note of the enabled features. If not, add it, using default-features = false when it is used in a no_std context. Then add new_dependecy = { workspace = true } to the crate that needs it.

The lint configuration is unusually explicit for a workspace. The rust lints set unexpected_cfgs to warn with a check-cfg for substrate_runtime and allow suspicious_double_ref_op. The clippy lints allow almost everything by default at priority 0, but deny correctness and complexity at priority 1, and then allow a list of specific rules with comments explaining why. bind_instead_of_map and default_constructed_unit_structs are marked as stylistic, derivable_impls is allowed as false positives, eq_op is allowed with the comment that in tests equality is tested, and erasing_op is allowed with an example about zero times dollars.

A deny by default model with a documented allow list is a healthier approach than a large allow list, because new lints arrive denied and each exception carries its reason.

The repository also carries a CODE_OF_CONDUCT.md, a CONTRIBUTING.md that the README points to first, a tarpaulin.toml for coverage, a taplo.toml for TOML formatting, a Makefile, a .devcontainer/ directory and a scripts/ directory.

Editorial conclusion

Adopt Astar if you need a Substrate based chain with EVM compatibility and you intend to run a collator, since the repository gives you the full runtime and collator source. Skip it if you are building a dApp rather than a chain, because the astar.network hub and the SDKs serve that case and the node itself is not the tool. Verify first by checking the runtime your target network uses, since astar, shiden and shibuya are separate crates with separate versions, and by building with cargo build --profile production after installing the wasm32-unknown-unknown target.

Frequently asked questions

Official sources

1. AstarNetwork/Astar on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases