# Parachains Menu

# Introduction

This guide lists and describes the required and optional building blocks of a Parachain. It is up to the Parachain team to decide which of them to pick based on their specific business logic needs.

Each component will be labeled with one of the following symbols:

- ⚫ - Needed / Dependancy
- 🟢 - Highly Recommended
- 🟡 - Recommended
- 🟠 - Can be useful
- 🟣 - Depends on the project needs

---

# System

## ⚫ Frame System

The System module provides low-level access to core types and cross-cutting utilities.
It acts as the base layer for other pallets to interact with the Substrate framework components.

It also provides several utility functions for other FRAME pallets.

In addition, it manages the storage items for extrinsics data, indexes, event records, and digest items, among other things that support the execution of the current block.

https://github.com/paritytech/substrate/tree/master/frame/system

## ⚫ Timestamp pallet

Needed for consensus related tasks. Dependancy of the *Aura* pallet.

https://github.com/paritytech/substrate/tree/master/frame/timestamp

## ⚫ Parachain System

This pallet handles low-level details of being a parachain. It's responsibilities include:

- Ingestion of the parachain validation data
- Ingestion of incoming downward and lateral messages and dispatching them
- Coordinating upgrades with the relay-chain
- Communication of parachain outputs, such as sent messages, signalling an upgrade, etc.

https://github.com/paritytech/cumulus/tree/master/pallets/parachain-system

## ⚫ Parachain Info

Minimal Pallet that injects the *ParachainId* into Runtime storage

https://github.com/paritytech/cumulus/tree/master/parachains/pallets/parachain-info

# Consensus

## ⚫ Session pallet

The Session module allows Collators to manage their session keys, provides a function for changing the session length, and handles session rotation.

A **session** is a period of time that has a constant set of validators. Validators can only join
or exit the validator set at a session change. It is measured in block numbers. When the session is ending, a new validator set can be chosen.

A session key is actually several keys kept together that provide the various signing
functions required by network authorities/validators in pursuit of their duties.

The Session pallet is designed to make the following possible:

- Set session keys of the validator set for upcoming sessions.
- Control the length of sessions.
- Configure and switch between either normal or exceptional session rotations.

https://github.com/paritytech/substrate/tree/master/frame/session

## ⚫ Authorship pallet

This pallet is used to store and report **block authors** and **block uncles.** The **block author** is the validator (in the sense of pallet-session) that created the block.

https://github.com/paritytech/substrate/tree/master/frame/authorship

## 🟢 Aura & AuraExt pallets

Aura provides a slot-based block authoring mechanism. In Aura a known set of authorities take turns producing blocks.

AuraExt extends **the Substrate Aura pallet to make it compatible with parachains

https://github.com/paritytech/substrate/tree/master/frame/aura

https://github.com/paritytech/cumulus/tree/master/pallets/aura-ext

## 🟢 Collator Selection pallet

A pallet to manage collators in a parachain.

Terminology:

- Collator: A parachain block producer
- Bond: An amount of reserved balance for candidate registration
- Invulnerable: An account guaranteed to be in the collator set.

The final Collators are aggregated from two individual lists:

- Invulnerables: A set of collators appointed by governance. These accounts will always be collators.
- Candidates: these are candidates to the collation task and may or may not be elected as a final collator. The current implementation resolves congestion of *Candidates* in a first-come-first-serve manner.

Rewards -The Collator Selection pallet maintains an on-chain account (the "*Pot*"). In each block, the collator who authored it receives:

- Half the value of the *Pot*
- Half the value of the transaction fees within the block. The other half of the transaction fees are deposited into the *Pot*.

<aside>
💡 Recommended to follow this approach as the first option before going live, starting with at least 4 collators hosted by the team. Once the Parachain’s stability is proven and community around the project has grown, there are two options:
- Increase the number of external *Candidates* to allow community to run their own nodes
- Implement another reward system such as *Staking*

</aside>

https://github.com/paritytech/cumulus/tree/master/pallets/collator-selection

# Currency & Assets

## 🟢 Balances pallet

Its main purpose is to manage the issuance and account balances of the native asset. The native asset has many tasks in the system, it controls when accounts exist and will be removed again. It therefore has implications for other pallets that require that certain accounts exist (they are providers for or consumers of the account – this is managed in `frame-system`). Furthermore pallets might have requirements for minimal amounts of the native asset that user accounts need to hold. For this reason the following model is used by `pallet-balances`: every user account has a total balance. This total balance consist of a free balance and a reserved balance (so free + reserved = total). Additionally every account can have a number of named locks and every lock has an amount. These locks are imposed on the account by other pallets (for example `pallet-democracy` defines account locks for votings). The free balance must never drop below the amounts of these locks, i.e., it must be at least as large as the maximum of all lock values.

<aside>
💡 Due to its default interdependency with other pallets, including `frame-system`, it is highly recommended to add this pallet. It is difficult to think about a Parachain not using this pallet.

</aside>

https://github.com/paritytech/substrate/tree/master/frame/balances

## 🟢 Treasury

The Treasury Pallet itself provides the pot to store funds, and a means for stakeholders to propose, approve, and deny expenditures. The chain will need to provide a method (e.g.inflation, fees) for collecting funds.

By way of example, the Council could vote to fund the Treasury with a portion of the block reward
and use the funds to pay developers.

Following the default configuration funds can be spent through a *Spending Proposal* that has to be approved by the *Council*:

- When approved, it enters a waiting period called **spend period** (default to 24 days)
- After each spend period:
- Treasury could run out of funds funding approved proposals
- The rest of approved proposals are kept in a queue for when the Treasury has mire funds
- Treasury could not run out of funds
- 1% of the unspent funds are burned (to force to spend them)

https://github.com/paritytech/substrate/tree/master/frame/treasury

## 🟣 Assets pallet

The Assets module provides functionality for asset management of fungible asset classes
with a fixed supply, including:

- Asset Issuance
- Asset Transfer
- Asset Destruction

<aside>
💡 Recommended as it became a standard in the Polkadot Ecosystem.

Does not follow ERC-20 standard

</aside>

https://github.com/paritytech/substrate/tree/master/frame/assets

## 🟣 Uniques pallet

The Uniques module provides functionality for asset management of non-fungible asset classes, including:

- Asset Issuance
- Asset Transfer
- Asset Destruction

The Uniques pallet in Substrate is designed to make the following possible:

- Allow accounts to permissionlessly create asset classes (collections of asset instances).
- Allow a named (permissioned) account to mint and burn unique assets within a class.
- Move asset instances between accounts permissionlessly.
- Allow a named (permissioned) account to freeze and unfreeze unique assets within a class or the entire class.
- Allow the owner of an asset instance to delegate the ability to transfer the asset to some named third-party.

<aside>
💡 Currently, trading with Uniques is not possible, however, a V2 will land soon unlocking this capability.

Does not follow ERC-721 standard

</aside>

https://github.com/paritytech/substrate/tree/master/frame/uniques

## 🟢 Transaction Payment pallet

This pallet provides the basic logic needed to pay the absolute minimum amount needed for a transaction to be included. This includes:

- weight fee: A fee proportional to amount of weight a transaction consumes.
- length fee: A fee proportional to the encoded length of the transaction.
- tip: An optional tip. Tip increases the priority of the transaction, giving it a higher chance to be included by the transaction queue.

https://github.com/paritytech/substrate/tree/master/frame/transaction-payment

## 🟣 Assets Tx pallet

This pallet allows runtimes that include it to pay for transactions in assets other than the
native token of the chain.

<aside>
💡 It is currently implemented for the Statemine runtime. Following that configuration, the asset fee is sent to the block author.

This pallet is tightly coupled to `pallet-transaction-payment`

</aside>

https://github.com/paritytech/substrate/tree/master/frame/transaction-payment/asset-tx-payment

## 🟠 Vesting

A simple module providing a means of placing a linear curve on an account's locked balance. This module ensures that there is a lock in place preventing the balance to drop below the *unvested* amount for reason other than the ones specified in the configuration.

<aside>
💡 Can be useful for Crowdloan rewards

</aside>

https://github.com/paritytech/substrate/tree/master/frame/vesting

# Governance

## 🟢 Sudo pallet

This pallet equips a single *AccountId* – the *sudo AccountId* – with special rights. It allows the sudo account to call any extrinsic that requires a *Root Origin*. For this purpose it provides a dispatchable that wraps another extrinsic (the *target extrinsic*) as an argument. This dispatchable is only callable by the sudo *AccountId* and will execute the target extrinsic function as the root origin.

Additionally the sudo pallet also allows the sudo account to call any extrinsic function as a different origin *AccountId*.

Finally the sudo *AccountId* is allowed to determine a new sudo *AccountId*.

The initial sudo *AccountId* needs to be defined in the genesis configuration, otherwise there is no way to set the initial sudo account at a later point in time.

<aside>
💡 This pallet is especially useful to be included in testnets. It allows to bypass governance when a Root Origin is required.

For live Parachains, it is also recommended to be included until a Governance system has been tested and proven functional.

</aside>

https://github.com/paritytech/substrate/tree/master/frame/sudo

## 🟢 Democracy pallet

The Democracy pallet handles the administration of general stakeholder voting.

There are two different queues that a proposal can be added to before it
becomes a referendum:

- The proposal queue consisting of all public proposals
- The external queue consisting of a single proposal that originates
from one of the external origins (such as a collective group).

Every launch period - a length defined in the runtime - the Democracy pallet launches a referendum from a proposal that it takes from either the proposal queue or the external queue in turn. Any token holder in the system can vote on referenda. The voting system uses time-lock voting by allowing the token holder to set their conviction behind a vote. The conviction will dictate the length of time the tokens will be locked, as well as the multiplier that scales the vote power.

https://github.com/paritytech/substrate/tree/master/frame/democracy

## 🟢 Collective pallet

Collective system: Members of a set of account IDs can make their collective feelings known
through dispatched calls from one of two specialised origins.

A "prime" member may be set to help determine the default vote behaviour based on chain config. If the prime default vote is used, the prime vote acts as the default vote in case of any abstentions after the voting period. If not, then abstentions will first follow the majority of the collective voting, and then the prime member.

Voting happens through motions comprising a proposal (i.e. a dispatchable) plus a number of approvals required for it to pass and be called. Motions are open for members to vote on for a minimum period of time. As soon as the required number of approvals is given, the motion is closed and executed. If the number of approvals is not reached during the voting period, then it may be closed by any account in order to force the end of the motion explicitly. If a prime member is defined, then their vote is used instead of any abstentions and the proposal is executed if there are enough approvals counting the new votes.

If there are not, or if no prime member is set, then the motion is dropped without being executed.

https://github.com/paritytech/substrate/tree/master/frame/collective

## 🟢 Membership pallet

Allows control of membership of a set of *AccountId`s*, useful for managing membership of a
collective. A prime member may be set.

https://github.com/paritytech/substrate/tree/master/frame/membership

## 🟢 Elections Phragmen pallet

An election module based on sequential phragmen.

https://github.com/paritytech/substrate/tree/master/frame/elections-phragmen

## 🟢 Preimage pallet

The Preimage pallet allows for the users and the runtime to store the preimage of a hash on chain. This can be used by other pallets for storing and managing large byte-blobs.

<aside>
💡 Preimages can be attached to the proposals while the content of the proposal is stored off-chain

</aside>

https://github.com/paritytech/substrate/tree/master/frame/preimage

# Utils

## 🟢 Utility

This module contains two basic pieces of functionality:

- **Batch dispatch**: A stateless operation, allowing any origin to execute multiple calls in a
single dispatch.
- **Pseudonymal dispatch**: A stateless operation, allowing a signed origin to execute a call from
an alternative signed origin. This can be useful as a key management tool, where you
need multiple distinct accounts (e.g. as controllers for many staking accounts), but where
it's perfectly fine to have each of them controlled by the same underlying key-pair.

<aside>
💡 Highly recommended because of the **batching** functionality

</aside>

https://github.com/paritytech/substrate/tree/master/frame/utility

## 🟡 Multisig pallet

This pallet allows to create **multisig accounts** and to perform **multisig operations**.

This pallet associates a unique **multisig account** to every combination of a set of account ids and a *threshold* (which is a number between 1 and the number of account ids in the set). Whenever any of these parameters (set of account ids or the threshold) changes, then this pallet will associate a different multisig account.

<aside>
💡 This pallet can be useful for sharing the ownership of the sudo key between multiple owners.

</aside>

https://github.com/paritytech/substrate/tree/master/frame/multisig

## 🟡 Proxy pallet

The Proxy pallet provides another way you can configure specialised accounts for a Substrate-based chain using FRAME. With proxy accounts, primary account owners can designate one or more other accounts to act on their behalf. Proxy accounts can be used to add a layer of security by isolating primary account funds from accounts assigned to specific roles that can complete tasks on behalf of the primary account.

https://github.com/paritytech/substrate/tree/master/frame/proxy

## 🟡 Scheduler

This pallet allows to schedule tasks (extrinsics) that are to be executed in a future block. When scheduling a task one can either give an absolute block number (that must lie in the future) or a relative block number (so that the task will be scheduled that many blocks in the future).

Tasks can be repeated, in this case one specified a period (of block numbers) and a count $n$. The task will then be executed $n$ times in total with the specified period where the first instance of the task is executed in the specified block.

https://github.com/paritytech/substrate/tree/master/frame/scheduler

## 🟠 Identity pallet

A federated naming system, allowing for multiple registrars to be added from a specified origin.
Registrars can set a fee to provide identity-verification service. Anyone can put forth a
proposed identity for a fixed deposit and ask for review by any number of registrars (paying
each of their fees). Registrar judgements are given as an `enum`, allowing for sophisticated,
multi-tier opinions.

Some judgements are identified as *sticky*, which means they cannot be removed except by
complete removal of the identity, or by the registrar. Judgements are allowed to represent a
portion of funds that have been reserved for the registrar.

A super-user can remove accounts and in doing so, slash the deposit.

https://github.com/paritytech/substrate/tree/master/frame/identity

## 🟠 Indices pallet

This module handles allocation of indices for accounts. An index is a short form of an address.

https://github.com/paritytech/substrate/tree/master/frame/indices

## 🟠 Recovery

The Recovery pallet is an M-of-N social recovery tool for users to gain access to their accounts if the private key or other authentication mechanism is lost. Through this pallet, a user is able to make calls on-behalf-of another account which they have recovered. The recovery process is protected by trusted "friends" whom the original account owner chooses. A threshold (M) out of N friends are needed to give another account access to the recoverable account.

https://github.com/paritytech/substrate/tree/master/frame/recovery

## 🟠 Tips

A subsystem to allow for an agile "tipping" process, whereby a reward may be given without first
having a pre-determined stakeholder group come to consensus on how much should be paid.

A group of *Tippers* is determined through configuration. After half of these have declared some amount that they believe a particular reported reason deserves, then a countdown period is entered where any remaining members can declare their tip amounts also. After the close of the
countdown period, the median of all declared tips is paid to the reported beneficiary, along with
any finders fee, in case of a public (and bonded) original report.

<aside>
💡 This pallet is tightly coupled to `pallet-treasury`

</aside>

https://github.com/paritytech/substrate/tree/master/frame/tips

## 🟠 Bounties

A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined Treasury amount to be paid out. A curator is assigned after the bounty is approved and funded by Council, to be delegated with the responsibility of assigning a payout address once the specified set of objectives is completed.

After the Council has activated a bounty, it delegates the work that requires expertise to a curator in exchange of a deposit. Once the curator accepts the bounty, they get to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address, the curator fee and the return of the curator deposit. The delay allows for intervention through regular democracy. The Council gets to free the curator, resulting in a new curator election. The Council also gets to cancel the bounty if deemed necessary before assigning a curator or once the bounty is active or payout is pending, resulting in the slash of the curator's deposit.

<aside>
💡 This pallet is tightly coupled to `pallet-treasury`

</aside>

https://github.com/paritytech/substrate/tree/master/frame/bounties

# XCM

## 🟢 XCM pallet

Cross-Consensus Message Format(XCM) aims to be a language to communicate ideas between consensus systems. One of Polkadot's promises is that of interoperability, and XCM is the vehicle through which it will deliver this promise. Simply, it is a standard that allows protocol developers to define the data and origins which their chains can send and receive from.

The XCM pallet includes methods to perform the most common interoperability actions such as teleport and reserve transfer assets.

https://github.com/paritytech/polkadot/tree/master/xcm/pallet-xcm

Dependancies:

### ⚫ Cumulus XCM pallet

Pallet for specific XCM dependancies for parachains' usage of XCM.

### ⚫ DMP queue

Pallet implementing a message queue for downward messages from the relay-chain. Executes downward messages if there is enough weight available and schedules the rest for later execution.

<aside>
💡 Necessary for communicating with the Relay Chain (Polkadot / Kusama)

</aside>

https://github.com/paritytech/cumulus/tree/master/pallets/dmp-queue

### ⚫ XCMP queue

A pallet which uses the XCMP transport layer to handle both incoming and outgoing XCM message sending and dispatch, queuing, signalling and back-pressure

<aside>
💡 Necessary for communicating with other Parachains

</aside>

https://github.com/paritytech/cumulus/tree/master/pallets/xcmp-queue

# Client side

## 🟣 Frontier

Frontier is the suite that provides an Ethereum compatibility layer for Substrate. Frontier enables you to run Ethereum dapps natively on Substrate, but does not deal with the issues of communicating with other Ethereum-based networks. If you want a standalone blockchain, you are looking for Frontier. If you want to create a parachain that has Ethereum functionality, you need to combine Frontier with Cumulus. If you do not want EVM functionality natively but want to communicate with other networks, you need the Parity Bridge project.

It has two runtime components that can be activated separately:

- **Pallet EVM**
- **Pallet Ethereum** with **Ethereum compatible RPC methods**

https://github.com/paritytech/frontier

# Smart Contracts

## 🟣 Contracts pallet

The Contract module provides functionality for the runtime to deploy and execute WebAssembly smart-contracts.

The Contracts pallet exposes a set of APIs that the WebAssembly smart contracts must use. This allows any WebAssembly smart contract language to be deployed on Substrate, as long as it utilizes the API.

The smart-contracts are able to interact with the rest of runtime/pallets from inside the contract thanks to the *Chain Extensions*

<aside>
💡 Used along with ink! based smart contracts

</aside>

https://github.com/paritytech/substrate/tree/master/frame/contracts

## 🟣 EVM pallet

The EVM module allows unmodified EVM code to be executed in a Substrate-based blockchain. It uses *SputnikVM* as the underlying EVM engine.

There are a separate set of accounts managed by the EVM module. Substrate based accounts can call the EVM Module to deposit or withdraw balance from the Substrate base-currency into a different balance managed and used by the EVM module. Once a user has populated their balance, they can create and call smart contracts using this module.

Substrate accounts and EVM external accounts are mapped via customisable conversion functions.

Furthermore, EVM contracts may utilize Substrate pallets via custom precompiles.

https://github.com/paritytech/frontier/tree/master/frame/evm

Dependancies:

### ⚫ Base Fee

Helper module to configure Gas to Fee transformation. BaseFee is the more used option that follows the EIP-1559 standard. BaseFee calculates the fees based on the current block weights (network congestion).

https://github.com/paritytech/frontier/tree/master/frame/base-fee

### ⚫ Dynamic Fee

Helper module to configure Gas to Fee transformation. Allows the Node(s) to vote on what the gas price should be (using inherents). Unlike the BaseFee option, DyamicFee does not rely on the current block weight to decide the gas cost.

https://github.com/paritytech/frontier/tree/master/frame/dynamic-fee

## 🟣 Ethereum pallet

The Ethereum pallet enables full Ethereum block emulation, allowing Ethereum RPCs to be activated. The Ethereum pallet provides the compatibility layer, powering tools like block explorers and Metamask.

The Ethereum pallet will convert received Ethereum transactions into Substrate transactions. This allows Ethereum transactions to be executed and stored within the Substrate environment.

https://github.com/paritytech/frontier/tree/master/frame/ethereum