UPDATE

In order to streamline our dev process, the astar-frame repository has been merged into the main repository astar.

For future issues and pull requests, please kindly submit in the astar repo instead.

We appreciate your understanding and support to Astar Network.

---

Astar Network is an interoperable blockchain based 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.

This repository only contains custom frame modules, for runtimes and node code please check here.

For contributing to this project, please read our Contribution Guideline.

Versioning Schema

Repository doesn't have a dedicated master branch, instead the main branch is assigned to the branch of active polkadot version, e.g. polkadot-v0.9.13. All deliveries should be made to the default branch unless they are intended for another temporary branch.

When a pallet has been modified (version in .toml is updated), a new release tag must be created. Naming format for the tag is: pallet-name-toml-version/polkadot-version

E.g. pallet-dapps-staking-1.1.2/polkadot-v0.9.13.

dApps-staking Pallets

Since both pallet-dapps-staking and pallet-precompile-dapps-staking are tightly related, we use a direct dependency (path) from the precompile to FRAME pallet. Due to this, both pallet versions should be the same (incrementing one also means that other should be incremented).

When creating tags, it is sufficient to just create a single tag for pallet-dapps-staking and reuse it for the precompiles in Astar repo.

Workspace Dependency Handling

All dependencies should be listed inside the workspace's root Cargo.toml file. This allows us to easily change version of a crate used by the entire repo by modifying the version in a single place.

Right now, if non_std is required, default-features = false must be set in the root Cargo.toml file (related to this issue). Otherwise, it will have no effect, causing your compilation to fail. Also package imports aren't properly propagated from root to sub-crates, so defining those should be avoided.

Defining features in the root Cargo.toml is additive with the features defined in concrete crate's Cargo.toml.

Adding Dependency

1. Check if the dependency is already defined in the root Cargo.toml
   1. if yes, nothing to do, just take note of the enabled features
   2. if no, add it (make sure to use default-features = false if dependency is used in no_std context)
2. Add new_dependecy = { workspace = true } to the required crate
3. In case dependency is defined with default-features = false but you need it in std context, add features = ["std"] to the required crate.

Further Reading

• Official Documentation
• Whitepaper
• Whitepaper(JP)
• Subtrate Developer Hub
• Substrate Glossary
• Substrate Client Library Documentation