Markdown linter (#1309)

* Add markdown linting - add linter default rules - adapt rules to current code - fix the code for linting to pass - add CI check fix #1243 * Fix markdown for Substrate * Fix tooling install * Fix workflow * Add documentation * Remove trailing spaces * Update .github/.markdownlint.yaml Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Fix mangled markdown/lists * Fix captalization issues on known words
2026-06-12 19:21:13 +00:00 · 2023-09-04 11:02:32 +02:00
parent 830fde2a60
commit a30092ab42
271 changed files with 6289 additions and 4450 deletions
@@ -1,11 +1,12 @@
 # FRAME

-The FRAME development environment provides modules (called "pallets") and support libraries that you can use, modify, and extend to build the runtime logic to suit the needs of your blockchain.
+The FRAME development environment provides modules (called "pallets") and support libraries that you can use, modify,
+and extend to build the runtime logic to suit the needs of your blockchain.

-### Documentation
+## Documentation

 https://docs.substrate.io/reference/frame-pallets/

-### Issues
+## Issues

 https://github.com/orgs/paritytech/projects/40
@@ -4,21 +4,21 @@ A simple, secure module for dealing with fungible assets.

 ## Overview

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

 * Asset Issuance
 * Asset Transfer
 * Asset Destruction

-To use it in your runtime, you need to implement the assets [`assets::Config`](https://docs.rs/pallet-assets/latest/pallet_assets/pallet/trait.Config.html).
+To use it in your runtime, you need to implement the assets
+[`assets::Config`](https://docs.rs/pallet-assets/latest/pallet_assets/pallet/trait.Config.html).

-The supported dispatchable functions are documented in the [`assets::Call`](https://docs.rs/pallet-assets/latest/pallet_assets/pallet/enum.Call.html) enum.
+The supported dispatchable functions are documented in the
+[`assets::Call`](https://docs.rs/pallet-assets/latest/pallet_assets/pallet/enum.Call.html) enum.

 ### Terminology

-* **Asset issuance:** The creation of a new asset, whose total supply will belong to the
-  account that issues the asset.
+* **Asset issuance:** The creation of a new asset, whose total supply will belong to the account that issues the asset.
 * **Asset transfer:** The action of transferring assets from one account to another.
 * **Asset destruction:** The process of an account removing its entire holding of an asset.
 * **Fungible asset:** An asset whose units are interchangeable.
@@ -30,20 +30,19 @@ The assets system in Substrate is designed to make the following possible:

 * Issue a unique asset to its creator's account.
 * Move assets between accounts.
-* Remove an account's balance of an asset when requested by that account's owner and update
-  the asset's total supply.
+* Remove an account's balance of an asset when requested by that account's owner and update the asset's total supply.

 ## Interface

 ### Dispatchable Functions

 * `issue` - Issues the total supply of a new fungible asset to the account of the caller of the function.
-* `transfer` - Transfers an `amount` of units of fungible asset `id` from the balance of
-the function caller's account (`origin`) to a `target` account.
-* `destroy` - Destroys the entire holding of a fungible asset `id` associated with the account
-that called the function.
+* `transfer` - Transfers an `amount` of units of fungible asset `id` from the balance of the function caller's account
+(`origin`) to a `target` account.
+* `destroy` - Destroys the entire holding of a fungible asset `id` associated with the account that called the function.

-Please refer to the [`Call`](https://docs.rs/pallet-assets/latest/pallet_assets/enum.Call.html) enum and its associated variants for documentation on each function.
+Please refer to the [`Call`](https://docs.rs/pallet-assets/latest/pallet_assets/enum.Call.html) enum and its associated
+variants for documentation on each function.

 ### Public Functions
 <!-- Original author of descriptions: @gavofyork -->
@@ -51,7 +50,8 @@ Please refer to the [`Call`](https://docs.rs/pallet-assets/latest/pallet_assets/
 * `balance` - Get the asset `id` balance of `who`.
 * `total_supply` - Get the total supply of an asset `id`.

-Please refer to the [`Pallet`](https://docs.rs/pallet-assets/latest/pallet_assets/pallet/struct.Pallet.html) struct for details on publicly available functions.
+Please refer to the [`Pallet`](https://docs.rs/pallet-assets/latest/pallet_assets/pallet/struct.Pallet.html) struct for
+details on publicly available functions.

 ## Usage

@@ -111,11 +111,10 @@ pub mod pallet {

 ## Assumptions

-Below are assumptions that must be held when using this module.  If any of
-them are violated, the behavior of this module is undefined.
+Below are assumptions that must be held when using this module.  If any of them are violated, the behavior of this
+module is undefined.

-* The total count of assets should be less than
-  `Config::AssetId::max_value()`.
+* The total count of assets should be less than `Config::AssetId::max_value()`.

 ## Related Modules

@@ -16,8 +16,8 @@ claimed within a specified duration of time, the sender may cancel it.

 ### Dispatchable Functions

-* `create_swap` - called by a sender to register a new atomic swap
-* `claim_swap` - called by the target to approve a swap
-* `cancel_swap` - may be called by a sender after a specified duration
+- `create_swap` - called by a sender to register a new atomic swap
+- `claim_swap` - called by the target to approve a swap
+- `cancel_swap` - may be called by a sender after a specified duration

 License: Apache-2.0
@@ -23,6 +23,7 @@ consensus rounds (via `slots`).
 If you're interested in hacking on this module, it is useful to understand the interaction with
 `substrate/primitives/inherents/src/lib.rs` and, specifically, the required implementation of
 [`ProvideInherent`](https://docs.rs/sp-inherents/latest/sp_inherents/trait.ProvideInherent.html) and
-[`ProvideInherentData`](https://docs.rs/sp-inherents/latest/sp_inherents/trait.ProvideInherentData.html) to create and check inherents.
+[`ProvideInherentData`](https://docs.rs/sp-inherents/latest/sp_inherents/trait.ProvideInherentData.html) to create and
+check inherents.

 License: Apache-2.0
@@ -1,6 +1,6 @@
-# Authority discovery module.
+# Authority discovery module

 This module is used by the `client/authority-discovery` to retrieve the
 current set of authorities.

-License: Apache-2.0
+License: Apache-2.0
@@ -2,4 +2,4 @@ Authorship tracking for FRAME runtimes.

 This tracks the current author of the block and recent uncles.

-License: Apache-2.0
+License: Apache-2.0
@@ -1,4 +1,4 @@
 Consensus extension module for BABE consensus. Collects on-chain randomness
 from VRF outputs and manages epoch transitions.

-License: Apache-2.0
+License: Apache-2.0
@@ -21,49 +21,48 @@ The Balances module provides functions for:

 ### Terminology

- **Existential Deposit:** The minimum balance required to create or keep an account open. This prevents
-"dust accounts" from filling storage. When the free plus the reserved balance (i.e. the total balance)
-  fall below this, then the account is said to be dead; and it loses its functionality as well as any
-  prior history and all information on it is removed from the chain's state.
-  No account should ever have a total balance that is strictly between 0 and the existential
-  deposit (exclusive). If this ever happens, it indicates either a bug in this module or an
-  erroneous raw mutation of storage.
+- **Existential Deposit:** The minimum balance required to create or keep an account open. This prevents "dust accounts"
+from filling storage. When the free plus the reserved balance (i.e. the total balance) fall below this, then the account
+  is said to be dead; and it loses its functionality as well as any prior history and all information on it is removed
+  from the chain's state. No account should ever have a total balance that is strictly between 0 and the existential
+  deposit (exclusive). If this ever happens, it indicates either a bug in this module or an erroneous raw mutation of
+  storage.

 - **Total Issuance:** The total number of units in existence in a system.

- **Reaping an account:** The act of removing an account by resetting its nonce. Happens after its
-total balance has become zero (or, strictly speaking, less than the Existential Deposit).
+- **Reaping an account:** The act of removing an account by resetting its nonce. Happens after its total balance has
+become zero (or, strictly speaking, less than the Existential Deposit).

- **Free Balance:** The portion of a balance that is not reserved. The free balance is the only
-  balance that matters for most operations.
+- **Free Balance:** The portion of a balance that is not reserved. The free balance is the only balance that matters for
+  most operations.

- **Reserved Balance:** Reserved balance still belongs to the account holder, but is suspended.
-  Reserved balance can still be slashed, but only after all the free balance has been slashed.
+- **Reserved Balance:** Reserved balance still belongs to the account holder, but is suspended. Reserved balance can
+  still be slashed, but only after all the free balance has been slashed.

- **Imbalance:** A condition when some funds were credited or debited without equal and opposite accounting
-(i.e. a difference between total issuance and account balances). Functions that result in an imbalance will
-return an object of the `Imbalance` trait that can be managed within your runtime logic. (If an imbalance is
-simply dropped, it should automatically maintain any book-keeping such as total issuance.)
+- **Imbalance:** A condition when some funds were credited or debited without equal and opposite accounting (i.e. a
+difference between total issuance and account balances). Functions that result in an imbalance will return an object of
+the `Imbalance` trait that can be managed within your runtime logic. (If an imbalance is simply dropped, it should
+automatically maintain any book-keeping such as total issuance.)

- **Lock:** A freeze on a specified amount of an account's free balance until a specified block number. Multiple
-locks always operate over the same funds, so they "overlay" rather than "stack".
+- **Lock:** A freeze on a specified amount of an account's free balance until a specified block number. Multiple locks
+always operate over the same funds, so they "overlay" rather than "stack".

 ### Implementations

-The Balances module provides implementations for the following traits. If these traits provide the functionality
-that you need, then you can avoid coupling with the Balances module.
+The Balances module provides implementations for the following traits. If these traits provide the functionality that
+you need, then you can avoid coupling with the Balances module.

- [`Currency`](https://docs.rs/frame-support/latest/frame_support/traits/trait.Currency.html): Functions for dealing with a
-fungible assets system.
+- [`Currency`](https://docs.rs/frame-support/latest/frame_support/traits/trait.Currency.html): Functions for dealing
+with a fungible assets system.
 - [`ReservableCurrency`](https://docs.rs/frame-support/latest/frame_support/traits/trait.ReservableCurrency.html):
 Functions for dealing with assets that can be reserved from an account.
- [`LockableCurrency`](https://docs.rs/frame-support/latest/frame_support/traits/trait.LockableCurrency.html): Functions for
-dealing with accounts that allow liquidity restrictions.
+- [`LockableCurrency`](https://docs.rs/frame-support/latest/frame_support/traits/trait.LockableCurrency.html): Functions
+for dealing with accounts that allow liquidity restrictions.
 - [`Imbalance`](https://docs.rs/frame-support/latest/frame_support/traits/trait.Imbalance.html): Functions for handling
-imbalances between total issuance in the system and account balances. Must be used when a function
-creates new funds (e.g. a reward) or destroys some funds (e.g. a system fee).
- [`IsDeadAccount`](https://docs.rs/frame-support/latest/frame_support/traits/trait.IsDeadAccount.html): Determiner to say whether a
-given account is unused.
+imbalances between total issuance in the system and account balances. Must be used when a function creates new funds
+(e.g. a reward) or destroys some funds (e.g. a system fee).
+- [`IsDeadAccount`](https://docs.rs/frame-support/latest/frame_support/traits/trait.IsDeadAccount.html): Determiner to
+say whether a given account is unused.

 ## Interface

@@ -113,10 +112,11 @@ fn update_ledger<T: Config>(

 ## Genesis config

-The Balances module depends on the [`GenesisConfig`](https://docs.rs/pallet-balances/latest/pallet_balances/pallet/struct.GenesisConfig.html).
+The Balances module depends on the
+[`GenesisConfig`](https://docs.rs/pallet-balances/latest/pallet_balances/pallet/struct.GenesisConfig.html).

 ## Assumptions

-* Total issued balanced of all accounts should be less than `Config::Balance::max_value()`.
+- Total issued balanced of all accounts should be less than `Config::Balance::max_value()`.

 License: Apache-2.0
@@ -1,99 +1,86 @@
 # Substrate Runtime Benchmarking Framework

-This crate contains a set of utilities that can be used to benchmark and weigh FRAME pallets that
-you develop for your Substrate Runtime.
+This crate contains a set of utilities that can be used to benchmark and weigh FRAME pallets that you develop for your
+Substrate Runtime.

 ## Overview

-Substrate's FRAME framework allows you to develop custom logic for your blockchain that can be
-included in your runtime. This flexibility is key to help you design complex and interactive
-pallets, but without accurate weights assigned to dispatchables, your blockchain may become
-vulnerable to denial of service (DoS) attacks by malicious actors.
+Substrate's FRAME framework allows you to develop custom logic for your blockchain that can be included in your runtime.
+This flexibility is key to help you design complex and interactive pallets, but without accurate weights assigned to
+dispatchables, your blockchain may become vulnerable to denial of service (DoS) attacks by malicious actors.

-The Substrate Runtime Benchmarking Framework is a tool you can use to mitigate DoS attacks against
-your blockchain network by benchmarking the computational resources required to execute different
-functions in the runtime, for example extrinsics, `on_initialize`, `verify_unsigned`, etc...
+The Substrate Runtime Benchmarking Framework is a tool you can use to mitigate DoS attacks against your blockchain
+network by benchmarking the computational resources required to execute different functions in the runtime, for example
+extrinsics, `on_initialize`, `verify_unsigned`, etc...

-The general philosophy behind the benchmarking system is: If your node can know ahead of time how
-long it will take to execute an extrinsic, it can safely make decisions to include or exclude that
-extrinsic based on its available resources. By doing this, it can keep the block production and
-import process running smoothly.
+The general philosophy behind the benchmarking system is: If your node can know ahead of time how long it will take to
+execute an extrinsic, it can safely make decisions to include or exclude that extrinsic based on its available
+resources. By doing this, it can keep the block production and import process running smoothly.

 To achieve this, we need to model how long it takes to run each function in the runtime by:

 * Creating custom benchmarking logic that executes a specific code path of a function.
-* Executing the benchmark in the Wasm execution environment, on a specific set of hardware, with a
-  custom runtime configuration, etc...
-* Executing the benchmark across controlled ranges of possible values that may affect the result of
-  the benchmark (called "components").
+* Executing the benchmark in the Wasm execution environment, on a specific set of hardware, with a custom runtime
+  configuration, etc...
+* Executing the benchmark across controlled ranges of possible values that may affect the result of the benchmark
+  (called "components").
 * Executing the benchmark multiple times at each point in order to isolate and remove outliers.
 * Using the results of the benchmark to create a linear model of the function across its components.

-With this linear model, we are able to estimate ahead of time how long it takes to execute some
-logic, and thus make informed decisions without actually spending any significant resources at
-runtime.
+With this linear model, we are able to estimate ahead of time how long it takes to execute some logic, and thus make
+informed decisions without actually spending any significant resources at runtime.

-Note that we assume that all extrinsics are assumed to be of linear complexity, which is why we are
-able to always fit them to a linear model. Quadratic or higher complexity functions are, in general,
-considered to be dangerous to the runtime as the weight of these functions may explode as the
-runtime state or input becomes too complex.
+Note that we assume that all extrinsics are assumed to be of linear complexity, which is why we are able to always fit
+them to a linear model. Quadratic or higher complexity functions are, in general, considered to be dangerous to the
+runtime as the weight of these functions may explode as the runtime state or input becomes too complex.

 The benchmarking framework comes with the following tools:

-* [A set of macros](./src/lib.rs) (`benchmarks!`, `add_benchmark!`, etc...) to make it easy to
-  write, test, and add runtime benchmarks.
+* [A set of macros](./src/lib.rs) (`benchmarks!`, `add_benchmark!`, etc...) to make it easy to write, test, and add
+  runtime benchmarks.
 * [A set of linear regression analysis functions](./src/analysis.rs) for processing benchmark data.
-* [A CLI extension](../../utils/frame/benchmarking-cli/README.md) to make it easy to execute benchmarks on your
-  node.
+* [A CLI extension](../../utils/frame/benchmarking-cli/README.md) to make it easy to execute benchmarks on your node.

-The end-to-end benchmarking pipeline is disabled by default when compiling a node. If you want to
-run benchmarks, you need to enable it by compiling with a Rust feature flag `runtime-benchmarks`.
-More details about this below.
+The end-to-end benchmarking pipeline is disabled by default when compiling a node. If you want to run benchmarks, you
+need to enable it by compiling with a Rust feature flag `runtime-benchmarks`. More details about this below.

 ### Weight

-Substrate represents computational resources using a generic unit of measurement called "Weight". It
-defines 10^12 Weight as 1 second of computation on the physical machine used for benchmarking. This
-means that the weight of a function may change based on the specific hardware used to benchmark the
-runtime functions.
+Substrate represents computational resources using a generic unit of measurement called "Weight". It defines 10^12
+Weight as 1 second of computation on the physical machine used for benchmarking. This means that the weight of a
+function may change based on the specific hardware used to benchmark the runtime functions.

-By modeling the expected weight of each runtime function, the blockchain is able to calculate how
-many transactions or system level functions it will be able to execute within a certain period of
-time. Often, the limiting factor for a blockchain is the fixed block production time for the
-network.
+By modeling the expected weight of each runtime function, the blockchain is able to calculate how many transactions or
+system level functions it will be able to execute within a certain period of time. Often, the limiting factor for a
+blockchain is the fixed block production time for the network.

-Within FRAME, each dispatchable function must have a `#[weight]` annotation with a function that can
-return the expected weight for the worst case scenario execution of that function given its inputs.
-This benchmarking framework will result in a file that automatically generates those formulas for
-you, which you can then use in your pallet.
+Within FRAME, each dispatchable function must have a `#[weight]` annotation with a function that can return the expected
+weight for the worst case scenario execution of that function given its inputs. This benchmarking framework will result
+in a file that automatically generates those formulas for you, which you can then use in your pallet.

 ## Writing Benchmarks

-Writing a runtime benchmark is much like writing a unit test for your pallet. It needs to be
-carefully crafted to execute a certain logical path in your code. In tests you want to check for
-various success and failure conditions, but with benchmarks you specifically look for the **most
-computationally heavy** path, a.k.a the "worst case scenario".
+Writing a runtime benchmark is much like writing a unit test for your pallet. It needs to be carefully crafted to
+execute a certain logical path in your code. In tests you want to check for various success and failure conditions, but
+with benchmarks you specifically look for the **most computationally heavy** path, a.k.a the "worst case scenario".

-This means that if there are certain storage items or runtime state that may affect the complexity
-of the function, for example triggering more iterations in a `for` loop, to get an accurate result,
-you must set up your benchmark to trigger this.
+This means that if there are certain storage items or runtime state that may affect the complexity of the function, for
+example triggering more iterations in a `for` loop, to get an accurate result, you must set up your benchmark to trigger
+this.

-It may be that there are multiple paths your function can go down, and it is not clear which one is
-the heaviest. In this case, you should just create a benchmark for each scenario! You may find that
-there are paths in your code where complexity may become unbounded depending on user input. This may
-be a hint that you should enforce sane boundaries for how a user can use your pallet. For example:
-limiting the number of elements in a vector, limiting the number of iterations in a `for` loop,
-etc...
+It may be that there are multiple paths your function can go down, and it is not clear which one is the heaviest. In
+this case, you should just create a benchmark for each scenario! You may find that there are paths in your code where
+complexity may become unbounded depending on user input. This may be a hint that you should enforce sane boundaries for
+how a user can use your pallet. For example: limiting the number of elements in a vector, limiting the number of
+iterations in a `for` loop, etc...

-Examples of end-to-end benchmarks can be found in the [pallets provided by Substrate](../), and the
-specific details on how to use the `benchmarks!` macro can be found in [its
-documentation](./src/lib.rs).
+Examples of end-to-end benchmarks can be found in the [pallets provided by Substrate](../), and the specific details on
+how to use the `benchmarks!` macro can be found in [its documentation](./src/lib.rs).

 ## Testing Benchmarks

-You can test your benchmarks using the same test runtime that you created for your pallet's unit
-tests. By creating your benchmarks in the `benchmarks!` macro, it automatically generates test
-functions for you:
+You can test your benchmarks using the same test runtime that you created for your pallet's unit tests. By creating your
+benchmarks in the `benchmarks!` macro, it automatically generates test functions for you:

 ```rust
 fn test_benchmark_[benchmark_name]<T>::() -> Result<(), &'static str>
@@ -101,19 +88,18 @@ fn test_benchmark_[benchmark_name]<T>::() -> Result<(), &'static str>

 Simply add these functions to a unit test and ensure that the result of the function is `Ok(())`.

-> **Note:** If your test runtime and production runtime have different configurations, you may get
-different results when testing your benchmark and actually running it.
+> **Note:** If your test runtime and production runtime have different configurations, you may get different results
+when testing your benchmark and actually running it.

-In general, benchmarks returning `Ok(())` is all you need to check for since it signals the executed
-extrinsic has completed successfully. However, you can optionally include a `verify` block with your
-benchmark, which can additionally verify any final conditions, such as the final state of your
-runtime.
+In general, benchmarks returning `Ok(())` is all you need to check for since it signals the executed extrinsic has
+completed successfully. However, you can optionally include a `verify` block with your benchmark, which can additionally
+verify any final conditions, such as the final state of your runtime.

 These additional `verify` blocks will not affect the results of your final benchmarking process.

-To run the tests, you need to enable the `runtime-benchmarks` feature flag. This may also mean you
-need to move into your node's binary folder. For example, with the Substrate repository, this is how
-you would test the Balances pallet's benchmarks:
+To run the tests, you need to enable the `runtime-benchmarks` feature flag. This may also mean you need to move into
+your node's binary folder. For example, with the Substrate repository, this is how you would test the Balances pallet's
+benchmarks:

 ```bash
 cargo test -p pallet-balances --features runtime-benchmarks
@@ -123,19 +109,20 @@ cargo test -p pallet-balances --features runtime-benchmarks
 > ```
 > error: --features is not allowed in the root of a virtual workspace`
 > ```
-> To solve this, navigate to the folder of the node (`cd bin/node/cli`) or pallet (`cd frame/pallet`) and run the command there.
+> To solve this, navigate to the folder of the node (`cd bin/node/cli`) or pallet (`cd frame/pallet`) and run the
+> command there.

-This will instance each linear component with different values. The number of values per component is set to six and can be changed with the `VALUES_PER_COMPONENT` environment variable.
+This will instance each linear component with different values. The number of values per component is set to six and can
+be changed with the `VALUES_PER_COMPONENT` environment variable.

 ## Adding Benchmarks

-The benchmarks included with each pallet are not automatically added to your node. To actually
-execute these benchmarks, you need to implement the `frame_benchmarking::Benchmark` trait. You can
-see an example of how to do this in the [included Substrate
-node](../../bin/node/runtime/src/lib.rs).
+The benchmarks included with each pallet are not automatically added to your node. To actually execute these benchmarks,
+you need to implement the `frame_benchmarking::Benchmark` trait. You can see an example of how to do this in the
+[included Substrate node](../../bin/node/runtime/src/lib.rs).

-Assuming there are already some benchmarks set up on your node, you just need to add another
-instance of the `add_benchmark!` macro:
+Assuming there are already some benchmarks set up on your node, you just need to add another instance of the
+`add_benchmark!` macro:

 ```rust
 ///  configuration for running benchmarks
@@ -147,22 +134,20 @@ add_benchmark!(params, batches, pallet_balances, Balances);
 ///            the `struct` created for your pallet by `construct_runtime!`
 ```

-Once you have done this, you will need to compile your node binary with the `runtime-benchmarks`
-feature flag:
+Once you have done this, you will need to compile your node binary with the `runtime-benchmarks` feature flag:

 ```bash
 cd bin/node/cli
 cargo build --profile=production --features runtime-benchmarks
 ```

-The production profile applies various compiler optimizations.  
-These optimizations slow down the compilation process *a lot*.  
+The production profile applies various compiler optimizations.
+These optimizations slow down the compilation process *a lot*.
 If you are just testing things out and don't need final numbers, don't include `--profile=production`.

 ## Running Benchmarks

-Finally, once you have a node binary with benchmarks enabled, you need to execute your various
-benchmarks.
+Finally, once you have a node binary with benchmarks enabled, you need to execute your various benchmarks.

 You can get a list of the available benchmarks by running:

@@ -183,24 +168,24 @@ Then you can run a benchmark like so:
    --output <path> \              # Output benchmark results into a folder or file
 ```

-This will output a file `pallet_name.rs` which implements the `WeightInfo` trait you should include
-in your pallet. Double colons `::` will be replaced with a `_` in the output name if you specify a directory. Each blockchain should generate their own benchmark file with their custom
-implementation of the `WeightInfo` trait. This means that you will be able to use these modular
-Substrate pallets while still keeping your network safe for your specific configuration and
+This will output a file `pallet_name.rs` which implements the `WeightInfo` trait you should include in your pallet.
+Double colons `::` will be replaced with a `_` in the output name if you specify a directory. Each blockchain should
+generate their own benchmark file with their custom implementation of the `WeightInfo` trait. This means that you will
+be able to use these modular Substrate pallets while still keeping your network safe for your specific configuration and
 requirements.

-The benchmarking CLI uses a Handlebars template to format the final output file. You can optionally
-pass the flag `--template` pointing to a custom template that can be used instead. Within the
-template, you have access to all the data provided by the `TemplateData` struct in the
-[benchmarking CLI writer](../../utils/frame/benchmarking-cli/src/writer.rs). You can find the
-default template used [here](../../utils/frame/benchmarking-cli/src/template.hbs).
+The benchmarking CLI uses a Handlebars template to format the final output file. You can optionally pass the flag
+`--template` pointing to a custom template that can be used instead. Within the template, you have access to all the
+data provided by the `TemplateData` struct in the [benchmarking CLI
+writer](../../utils/frame/benchmarking-cli/src/writer.rs). You can find the default template used
+[here](../../utils/frame/benchmarking-cli/src/template.hbs).

 There are some custom Handlebars helpers included with our output generation:

-* `underscore`: Add an underscore to every 3rd character from the right of a string. Primarily to be
-used for delimiting large numbers.
-* `join`: Join an array of strings into a space-separated string for the template. Primarily to be
-used for joining all the arguments passed to the CLI.
+* `underscore`: Add an underscore to every 3rd character from the right of a string. Primarily to be used for delimiting
+large numbers.
+* `join`: Join an array of strings into a space-separated string for the template. Primarily to be used for joining all
+the arguments passed to the CLI.

 To get a full list of available options when running benchmarks, run:

@@ -8,7 +8,7 @@ With child bounties, a large bounty proposal can be divided into smaller chunks,
 for parallel execution, and for efficient governance and tracking of spent funds.
 A child bounty is a smaller piece of work, extracted from a parent bounty.
 A curator is assigned after the child bounty is created by the parent bounty curator,
-to be delegated with the responsibility of assigning a payout address once 
+to be delegated with the responsibility of assigning a payout address once
 the specified set of tasks is completed.

 ## Interface
@@ -5,7 +5,7 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

-The semantic versioning guarantees cover the interface to the substrate runtime which
+The semantic versioning guarantees cover the interface to the Substrate runtime which
 includes this pallet as a dependency. This module will also add storage migrations whenever
 changes require it. Stability with regard to offchain tooling is explicitly excluded from
 this guarantee: For example adding a new field to an in-storage data structure will require
@@ -9,66 +9,68 @@ The Contracts module provides functionality for the runtime to deploy and execut

 ## Overview

-This module extends accounts based on the [`frame_support::traits::fungible`] traits to have smart-contract functionality. It can
-be used with other modules that implement accounts based on [`frame_support::traits::fungible`]. These "smart-contract accounts"
-have the ability to instantiate smart-contracts and make calls to other contract and non-contract accounts.
+This module extends accounts based on the [`frame_support::traits::fungible`] traits to have smart-contract
+functionality. It can be used with other modules that implement accounts based on [`frame_support::traits::fungible`].
+These "smart-contract accounts" have the ability to instantiate smart-contracts and make calls to other contract and
+non-contract accounts.

-The smart-contract code is stored once, and later retrievable via its `code_hash`.
-This means that multiple smart-contracts can be instantiated from the same `code`, without replicating
-the code each time.
+The smart-contract code is stored once, and later retrievable via its `code_hash`. This means that multiple
+smart-contracts can be instantiated from the same `code`, without replicating the code each time.

-When a smart-contract is called, its associated code is retrieved via the code hash and gets executed.
-This call can alter the storage entries of the smart-contract account, instantiate new smart-contracts,
-or call other smart-contracts.
+When a smart-contract is called, its associated code is retrieved via the code hash and gets executed. This call can
+alter the storage entries of the smart-contract account, instantiate new smart-contracts, or call other smart-contracts.

-Finally, when an account is reaped, its associated code and storage of the smart-contract account
-will also be deleted.
+Finally, when an account is reaped, its associated code and storage of the smart-contract account will also be deleted.

 ### Weight

-Senders must specify a [`Weight`](https://paritytech.github.io/substrate/master/sp_weights/struct.Weight.html) limit with every call, as all instructions invoked by the smart-contract require weight.
-Unused weight is refunded after the call, regardless of the execution outcome.
+Senders must specify a [`Weight`](https://paritytech.github.io/substrate/master/sp_weights/struct.Weight.html) limit
+with every call, as all instructions invoked by the smart-contract require weight. Unused weight is refunded after the
+call, regardless of the execution outcome.

-If the weight limit is reached, then all calls and state changes (including balance transfers) are only
-reverted at the current call's contract level. For example, if contract A calls B and B runs out of weight mid-call,
-then all of B's calls are reverted. Assuming correct error handling by contract A, A's other calls and state
-changes still persist.
+If the weight limit is reached, then all calls and state changes (including balance transfers) are only reverted at the
+current call's contract level. For example, if contract A calls B and B runs out of weight mid-call, then all of B's
+calls are reverted. Assuming correct error handling by contract A, A's other calls and state changes still persist.

 One `ref_time` `Weight` is defined as one picosecond of execution time on the runtime's reference machine.

 ### Revert Behaviour

-Contract call failures are not cascading. When failures occur in a sub-call, they do not "bubble up",
-and the call will only revert at the specific contract level. For example, if contract A calls contract B, and B
-fails, A can decide how to handle that failure, either proceeding or reverting A's changes.
+Contract call failures are not cascading. When failures occur in a sub-call, they do not "bubble up", and the call will
+only revert at the specific contract level. For example, if contract A calls contract B, and B fails, A can decide how
+to handle that failure, either proceeding or reverting A's changes.

 ### Off-chain Execution

-In general, a contract execution needs to be deterministic so that all nodes come to the same
-conclusion when executing it. To that end we disallow any instructions that could cause
-indeterminism. Most notable are any floating point arithmetic. That said, sometimes contracts
-are executed off-chain and hence are not subject to consensus. If code is only executed by a
-single node and implicitly trusted by other actors is such a case. Trusted execution environments
-come to mind. To that end we allow the execution of indeterminstic code for off-chain usages
-with the following constraints:
+In general, a contract execution needs to be deterministic so that all nodes come to the same conclusion when executing
+it. To that end we disallow any instructions that could cause indeterminism. Most notable are any floating point
+arithmetic. That said, sometimes contracts are executed off-chain and hence are not subject to consensus. If code is
+only executed by a single node and implicitly trusted by other actors is such a case. Trusted execution environments
+come to mind. To that end we allow the execution of indeterminstic code for off-chain usages with the following
+constraints:

-1. No contract can ever be instantiated from an indeterministic code. The only way to execute
-the code is to use a delegate call from a deterministic contract.
-2. The code that wants to use this feature needs to depend on `pallet-contracts` and use [`bare_call()`](https://paritytech.github.io/substrate/master/pallet_contracts/pallet/struct.Pallet.html#method.bare_call)
+1. No contract can ever be instantiated from an indeterministic code. The only way to execute the code is to use a
+delegate call from a deterministic contract.
+2. The code that wants to use this feature needs to depend on `pallet-contracts` and use
+[`bare_call()`](https://paritytech.github.io/substrate/master/pallet_contracts/pallet/struct.Pallet.html#method.bare_call)
 directly. This makes sure that by default `pallet-contracts` does not expose any indeterminism.

 #### How to use

-An indeterministic code can be deployed on-chain by passing `Determinism::Relaxed`
-to [`upload_code()`](https://paritytech.github.io/substrate/master/pallet_contracts/pallet/struct.Pallet.html#method.upload_code). A deterministic contract can then delegate call into it if and only if it
-is ran by using [`bare_call()`](https://paritytech.github.io/substrate/master/pallet_contracts/pallet/struct.Pallet.html#method.bare_call) and passing [`Determinism::Relaxed`](https://paritytech.github.io/substrate/master/pallet_contracts/enum.Determinism.html#variant.Relaxed) to it. **Never use
-this argument when the contract is called from an on-chain transaction.**
+An indeterministic code can be deployed on-chain by passing `Determinism::Relaxed` to
+[`upload_code()`](https://paritytech.github.io/substrate/master/pallet_contracts/pallet/struct.Pallet.html#method.upload_code).
+A deterministic contract can then delegate call into it if and only if it is ran by using
+[`bare_call()`](https://paritytech.github.io/substrate/master/pallet_contracts/pallet/struct.Pallet.html#method.bare_call)
+and passing
+[`Determinism::Relaxed`](https://paritytech.github.io/substrate/master/pallet_contracts/enum.Determinism.html#variant.Relaxed)
+to it. **Never use this argument when the contract is called from an on-chain transaction.**

 ## Interface

 ### Dispatchable functions

-Those are documented in the [reference documentation](https://paritytech.github.io/substrate/master/pallet_contracts/index.html#dispatchable-functions).
+Those are documented in the [reference
+documentation](https://paritytech.github.io/substrate/master/pallet_contracts/index.html#dispatchable-functions).

 ### Interface exposed to contracts

@@ -99,43 +101,43 @@ The documentation of all importable functions can be found

 ## Usage

-This module executes WebAssembly smart contracts. These can potentially be written in any language
-that compiles to Wasm. However, using a language that specifically targets this module
-will make things a lot easier. One such language is [`ink!`](https://use.ink). It enables
-writing WebAssembly-based smart-contracts in the Rust programming language.
+This module executes WebAssembly smart contracts. These can potentially be written in any language that compiles to
+Wasm. However, using a language that specifically targets this module will make things a lot easier. One such language
+is [`ink!`](https://use.ink). It enables writing WebAssembly-based smart-contracts in the Rust programming language.

 ## Debugging

-Contracts can emit messages to the client when called as RPC through the [`debug_message`](https://paritytech.github.io/substrate/master/pallet_contracts/api_doc/trait.Current.html#tymethod.debug_message)
+Contracts can emit messages to the client when called as RPC through the
+[`debug_message`](https://paritytech.github.io/substrate/master/pallet_contracts/api_doc/trait.Current.html#tymethod.debug_message)
 API. This is exposed in [ink!](https://use.ink) via
 [`ink_env::debug_message()`](https://paritytech.github.io/ink/ink_env/fn.debug_message.html).

-Those messages are gathered into an internal buffer and sent to the RPC client.
-It is up the the individual client if and how those messages are presented to the user.
+Those messages are gathered into an internal buffer and sent to the RPC client. It is up the the individual client if
+and how those messages are presented to the user.

-This buffer is also printed as a debug message. In order to see these messages on the node
-console the log level for the `runtime::contracts` target needs to be raised to at least
-the `debug` level. However, those messages are easy to overlook because of the noise generated
-by block production. A good starting point for observing them on the console is using this
-command line in the root directory of the substrate repository:
+This buffer is also printed as a debug message. In order to see these messages on the node console the log level for the
+`runtime::contracts` target needs to be raised to at least the `debug` level. However, those messages are easy to
+overlook because of the noise generated by block production. A good starting point for observing them on the console is
+using this command line in the root directory of the Substrate repository:

 ```bash
 cargo run --release -- --dev -lerror,runtime::contracts=debug
 ```

-This raises the log level of `runtime::contracts` to `debug` and all other targets
-to `error` in order to prevent them from spamming the console.
+This raises the log level of `runtime::contracts` to `debug` and all other targets to `error` in order to prevent them
+from spamming the console.

-`--dev`: Use a dev chain spec
-`--tmp`: Use temporary storage for chain data (the chain state is deleted on exit)
+`--dev`: Use a dev chain spec `--tmp`: Use temporary storage for chain data (the chain state is deleted on exit)

 ## Host function tracing

-For contract authors, it can be a helpful debugging tool to see which host functions are called, with which arguments, and what the result was. 
+For contract authors, it can be a helpful debugging tool to see which host functions are called, with which arguments,
+and what the result was.

-In order to see these messages on the node console, the log level for the `runtime::contracts::strace` target needs to be raised to the `trace` level. 
+In order to see these messages on the node console, the log level for the `runtime::contracts::strace` target needs to
+be raised to the `trace` level.

-Example: 
+Example:

 ```bash
 cargo run --release -- --dev -lerror,runtime::contracts::strace=trace,runtime::contracts=debug
@@ -143,18 +145,16 @@ cargo run --release -- --dev -lerror,runtime::contracts::strace=trace,runtime::c

 ## Unstable Interfaces

-Driven by the desire to have an iterative approach in developing new contract interfaces
-this pallet contains the concept of an unstable interface. Akin to the rust nightly compiler
-it allows us to add new interfaces but mark them as unstable so that contract languages can
-experiment with them and give feedback before we stabilize those.
+Driven by the desire to have an iterative approach in developing new contract interfaces this pallet contains the
+concept of an unstable interface. Akin to the rust nightly compiler it allows us to add new interfaces but mark them as
+unstable so that contract languages can experiment with them and give feedback before we stabilize those.

 In order to access interfaces marked as `#[unstable]` in [`runtime.rs`](src/wasm/runtime.rs) one need to set
-`pallet_contracts::Config::UnsafeUnstableInterface` to `ConstU32<true>`. **It should be obvious
-that any production runtime should never be compiled with this feature: In addition to be
-subject to change or removal those interfaces might not have proper weights associated with
-them and are therefore considered unsafe**.
+`pallet_contracts::Config::UnsafeUnstableInterface` to `ConstU32<true>`. **It should be obvious that any production
+runtime should never be compiled with this feature: In addition to be subject to change or removal those interfaces
+might not have proper weights associated with them and are therefore considered unsafe**.

-New interfaces are generally added as unstable and might go through several iterations
-before they are promoted to a stable interface.
+New interfaces are generally added as unstable and might go through several iterations before they are promoted to a
+stable interface.

 License: Apache-2.0
@@ -1,9 +1,8 @@
 # Benchmarks

-This directory contains real world ([ink!](https://use.ink), [solang](https://github.com/hyperledger/solang)) contracts which are used in macro benchmarks.
-Those benchmarks are not used to determine weights but rather to compare different contract
-languages and execution engines with larger wasm modules.
-
-Files in this directory are used by `#[extra]` benchmarks in `src/benchmarking`. The json
-files are for informational purposes only and are not consumed by the benchmarks.
+This directory contains real world ([ink!](https://use.ink), [solang](https://github.com/hyperledger/solang)) contracts
+which are used in macro benchmarks. Those benchmarks are not used to determine weights but rather to compare different
+contract languages and execution engines with larger wasm modules.

+Files in this directory are used by `#[extra]` benchmarks in `src/benchmarking`. The json files are for informational
+purposes only and are not consumed by the benchmarks.
@@ -1,3 +1,3 @@
 A crate that hosts a common definitions that are relevant for the pallet-contracts.

-License: Apache-2.0
+License: Apache-2.0
@@ -1,3 +1,3 @@
 # Core Fellowship

-Logic specific to the core Polkadot Fellowship.
+Logic specific to the core Polkadot Fellowship.
@@ -1,64 +1,58 @@
-# Phragmén Election Module.
+# Phragmén Election Module

 An election module based on sequential phragmen.

-### Term and Round
+## Term and Round

-The election happens in _rounds_: every `N` blocks, all previous members are retired and a new
-set is elected (which may or may not have an intersection with the previous set). Each round
-lasts for some number of blocks defined by `TermDuration` storage item. The words _term_ and
-_round_ can be used interchangeably in this context.
+The election happens in _rounds_: every `N` blocks, all previous members are retired and a new set is elected (which may
+or may not have an intersection with the previous set). Each round lasts for some number of blocks defined by
+`TermDuration` storage item. The words _term_ and _round_ can be used interchangeably in this context.

-`TermDuration` might change during a round. This can shorten or extend the length of the round.
-The next election round's block number is never stored but rather always checked on the fly.
-Based on the current block number and `TermDuration`, the condition `BlockNumber % TermDuration
-== 0` being satisfied will always trigger a new election round.
+`TermDuration` might change during a round. This can shorten or extend the length of the round. The next election
+round's block number is never stored but rather always checked on the fly. Based on the current block number and
+`TermDuration`, the condition `BlockNumber % TermDuration == 0` being satisfied will always trigger a new election
+round.

-### Voting
+## Voting

-Voters can vote for any set of the candidates by providing a list of account ids. Invalid votes
-(voting for non-candidates) are ignored during election. Yet, a voter _might_ vote for a future
-candidate. Voters reserve a bond as they vote. Each vote defines a `value`. This amount is
-locked from the account of the voter and indicates the weight of the vote. Voters can update
-their votes at any time by calling `vote()` again. This keeps the bond untouched but can
-optionally change the locked `value`. After a round, votes are kept and might still be valid for
-further rounds. A voter is responsible for calling `remove_voter` once they are done to have
-their bond back and remove the lock.
+Voters can vote for any set of the candidates by providing a list of account ids. Invalid votes (voting for
+non-candidates) are ignored during election. Yet, a voter _might_ vote for a future candidate. Voters reserve a bond as
+they vote. Each vote defines a `value`. This amount is locked from the account of the voter and indicates the weight of
+the vote. Voters can update their votes at any time by calling `vote()` again. This keeps the bond untouched but can
+optionally change the locked `value`. After a round, votes are kept and might still be valid for further rounds. A voter
+is responsible for calling `remove_voter` once they are done to have their bond back and remove the lock.

-Voters also report other voters as being defunct to earn their bond. A voter is defunct once all
-of the candidates that they have voted for are neither a valid candidate anymore nor a member.
-Upon reporting, if the target voter is actually defunct, the reporter will be rewarded by the
-voting bond of the target. The target will lose their bond and get removed. If the target is not
-defunct, the reporter is slashed and removed. To prevent being reported, voters should manually
-submit a `remove_voter()` as soon as they are in the defunct state.
+Voters also report other voters as being defunct to earn their bond. A voter is defunct once all of the candidates that
+they have voted for are neither a valid candidate anymore nor a member. Upon reporting, if the target voter is actually
+defunct, the reporter will be rewarded by the voting bond of the target. The target will lose their bond and get
+removed. If the target is not defunct, the reporter is slashed and removed. To prevent being reported, voters should
+manually submit a `remove_voter()` as soon as they are in the defunct state.

-### Candidacy and Members
+## Candidacy and Members

-Candidates also reserve a bond as they submit candidacy. A candidate cannot take their candidacy
-back. A candidate can end up in one of the below situations:
-  - **Winner**: A winner is kept as a _member_. They must still have a bond in reserve and they
-    are automatically counted as a candidate for the next election.
-  - **Runner-up**: Runners-up are the best candidates immediately after the winners. The number
-    of runners_up to keep is configurable. Runners-up are used, in order that they are elected,
-    as replacements when a candidate is kicked by `[remove_member]`, or when an active member
-    renounces their candidacy. Runners are automatically counted as a candidate for the next
-    election.
-  - **Loser**: Any of the candidate who are not a winner are left as losers. A loser might be an
-    _outgoing member or runner_, meaning that they are an active member who failed to keep their
-    spot. An outgoing will always lose their bond.
+Candidates also reserve a bond as they submit candidacy. A candidate cannot take their candidacy back. A candidate can
+end up in one of the below situations:
+  - **Winner**: A winner is kept as a _member_. They must still have a bond in reserve and they are automatically
+    counted as a candidate for the next election.
+  - **Runner-up**: Runners-up are the best candidates immediately after the winners. The number of runners_up to keep is
+    configurable. Runners-up are used, in order that they are elected, as replacements when a candidate is kicked by
+    `[remove_member]`, or when an active member renounces their candidacy. Runners are automatically counted as a
+    candidate for the next election.
+  - **Loser**: Any of the candidate who are not a winner are left as losers. A loser might be an _outgoing member or
+    runner_, meaning that they are an active member who failed to keep their spot. An outgoing will always lose their
+    bond.

-##### Renouncing candidacy.
+### Renouncing candidacy

-All candidates, elected or not, can renounce their candidacy. A call to [`Module::renounce_candidacy`]
-will always cause the candidacy bond to be refunded.
+All candidates, elected or not, can renounce their candidacy. A call to [`Module::renounce_candidacy`] will always cause
+the candidacy bond to be refunded.

-Note that with the members being the default candidates for the next round and votes persisting
-in storage, the election system is entirely stable given no further input. This means that if
-the system has a particular set of candidates `C` and voters `V` that lead to a set of members
-`M` being elected, as long as `V` and `C` don't remove their candidacy and votes, `M` will keep
-being re-elected at the end of each round.
+Note that with the members being the default candidates for the next round and votes persisting in storage, the election
+system is entirely stable given no further input. This means that if the system has a particular set of candidates `C`
+and voters `V` that lead to a set of members `M` being elected, as long as `V` and `C` don't remove their candidacy and
+votes, `M` will keep being re-elected at the end of each round.

-### Module Information
+## Module Information

 - [`election_sp_phragmen::Config`](https://docs.rs/pallet-elections-phragmen/latest/pallet_elections_phragmen/trait.Config.html)
 - [`Call`](https://docs.rs/pallet-elections-phragmen/latest/pallet_elections_phragmen/enum.Call.html)
@@ -9,7 +9,7 @@ Run `cargo doc --package pallet-example-basic --open` to view this pallet's docu

 **This pallet serves as an example and is not meant to be used in production.**

-### Documentation Guidelines:
+## Documentation Guidelines

 <!-- Original author of paragraph: Various. Based on collation of review comments to PRs addressing issues with -->
 <!-- label 'S3-FRAME' in https://github.com/paritytech/substrate-developer-hub/issues -->
@@ -3,7 +3,7 @@
 A simple example of a FRAME pallet demonstrating the ability to split sections across multiple
 files.

-Note that this is purely experimental at this point. 
+Note that this is purely experimental at this point.

 Run `cargo doc --package pallet-example-split --open` to view this pallet's documentation.

@@ -1,13 +1,13 @@
 # Executive Module

-The Executive module acts as the orchestration layer for the runtime. It dispatches incoming
-extrinsic calls to the respective modules in the runtime.
+The Executive module acts as the orchestration layer for the runtime. It dispatches incoming extrinsic calls to the
+respective modules in the runtime.

 ## Overview

-The executive module is not a typical pallet providing functionality around a specific feature.
-It is a cross-cutting framework component for the FRAME. It works in conjunction with the
-[FRAME System module](https://docs.rs/frame-system/latest/frame_system/) to perform these cross-cutting functions.
+The executive module is not a typical pallet providing functionality around a specific feature. It is a cross-cutting
+framework component for the FRAME. It works in conjunction with the [FRAME System
+module](https://docs.rs/frame-system/latest/frame_system/) to perform these cross-cutting functions.

 The Executive module provides functions to:

@@ -26,7 +26,8 @@ The Executive module provides the following implementations:

 ## Usage

-The default Substrate node template declares the [`Executive`](https://docs.rs/frame-executive/latest/frame_executive/struct.Executive.html) type in its library.
+The default Substrate node template declares the
+[`Executive`](https://docs.rs/frame-executive/latest/frame_executive/struct.Executive.html) type in its library.

 ### Example

@@ -46,9 +47,8 @@ pub type Executive = executive::Executive<

 ### Custom `OnRuntimeUpgrade` logic

-You can add custom logic that should be called in your runtime on a runtime upgrade. This is
-done by setting an optional generic parameter. The custom logic will be called before
-the on runtime upgrade logic of all modules is called.
+You can add custom logic that should be called in your runtime on a runtime upgrade. This is done by setting an optional
+generic parameter. The custom logic will be called before the on runtime upgrade logic of all modules is called.

 ```rust
 #
@@ -4,6 +4,9 @@

 # Glutton Pallet

-The `Glutton` pallet gets the name from its property to consume vast amounts of resources. It can be used to push para-chains and their relay-chains to the limits. This is good for testing out theoretical limits in a practical way.
+The `Glutton` pallet gets the name from its property to consume vast amounts of resources. It can be used to push
+para-chains and their relay-chains to the limits. This is good for testing out theoretical limits in a practical way.

-The `Glutton` can be set to consume a fraction of the available unused weight of a chain. It accomplishes this by utilizing the `on_idle` hook and consuming a specific ration of the remaining weight. The rations can be set via `set_compute` and `set_storage`. Initially the `Glutton` needs to be initialized once with `initialize_pallet`.
+The `Glutton` can be set to consume a fraction of the available unused weight of a chain. It accomplishes this by
+utilizing the `on_idle` hook and consuming a specific ration of the remaining weight. The rations can be set via
+`set_compute` and `set_storage`. Initially the `Glutton` needs to be initialized once with `initialize_pallet`.
@@ -9,4 +9,4 @@ finality notifications.
 For full integration with GRANDPA, the `GrandpaApi` should be implemented.
 The necessary items are re-exported via the `fg_primitives` crate.

-License: Apache-2.0
+License: Apache-2.0
@@ -28,27 +28,27 @@ no state-bloat attack is viable.
 ### Dispatchable Functions

 #### For general users
-* `set_identity` - Set the associated identity of an account; a small deposit is reserved if not
+- `set_identity` - Set the associated identity of an account; a small deposit is reserved if not
  already taken.
-* `clear_identity` - Remove an account's associated identity; the deposit is returned.
-* `request_judgement` - Request a judgement from a registrar, paying a fee.
-* `cancel_request` - Cancel the previous request for a judgement.
+- `clear_identity` - Remove an account's associated identity; the deposit is returned.
+- `request_judgement` - Request a judgement from a registrar, paying a fee.
+- `cancel_request` - Cancel the previous request for a judgement.

 #### For general users with sub-identities
-* `set_subs` - Set the sub-accounts of an identity.
-* `add_sub` - Add a sub-identity to an identity.
-* `remove_sub` - Remove a sub-identity of an identity.
-* `rename_sub` - Rename a sub-identity of an identity.
-* `quit_sub` - Remove a sub-identity of an identity (called by the sub-identity).
+- `set_subs` - Set the sub-accounts of an identity.
+- `add_sub` - Add a sub-identity to an identity.
+- `remove_sub` - Remove a sub-identity of an identity.
+- `rename_sub` - Rename a sub-identity of an identity.
+- `quit_sub` - Remove a sub-identity of an identity (called by the sub-identity).

 #### For registrars
-* `set_fee` - Set the fee required to be paid for a judgement to be given by the registrar.
-* `set_fields` - Set the fields that a registrar cares about in their judgements.
-* `provide_judgement` - Provide a judgement to an identity.
+- `set_fee` - Set the fee required to be paid for a judgement to be given by the registrar.
+- `set_fields` - Set the fields that a registrar cares about in their judgements.
+- `provide_judgement` - Provide a judgement to an identity.

 #### For super-users
-* `add_registrar` - Add a new registrar to the system.
-* `kill_identity` - Forcibly remove the associated identity; the deposit is lost.
+- `add_registrar` - Add a new registrar to the system.
+- `kill_identity` - Forcibly remove the associated identity; the deposit is lost.

 [`Call`]: ./enum.Call.html
 [`Config`]: ./trait.Config.html
@@ -1,4 +1,4 @@
 An index is a short form of an address. This module handles allocation
 of indices for a newly created accounts.

-License: Apache-2.0
+License: Apache-2.0
@@ -1,25 +1,27 @@
 # DO NOT USE IN PRODUCTION

-The produced values do not fulfill the cryptographic requirements for random numbers. Should not be used for high-stake production use-cases.
+The produced values do not fulfill the cryptographic requirements for random numbers. Should not be used for high-stake
+production use-cases.

 # Randomness Module

-The Randomness Collective Flip module provides a [`random`](https://docs.rs/pallet-insecure-randomness-collective-flip/latest/pallet_insecure_randomness_collective_flip/struct.Module.html#method.random)
-function that generates low-influence random values based on the block hashes from the previous
-`81` blocks. Low-influence randomness can be useful when defending against relatively weak
-adversaries. Using this pallet as a randomness source is advisable primarily in low-security
-situations like testing.
+The Randomness Collective Flip module provides a
+[`random`](https://docs.rs/pallet-insecure-randomness-collective-flip/latest/pallet_insecure_randomness_collective_flip/struct.Module.html#method.random)
+function that generates low-influence random values based on the block hashes from the previous `81` blocks.
+Low-influence randomness can be useful when defending against relatively weak adversaries. Using this pallet as a
+randomness source is advisable primarily in low-security situations like testing.

 ## Public Functions

-See the [`Module`](https://docs.rs/pallet-insecure-randomness-collective-flip/latest/pallet_insecure_randomness_collective_flip/struct.Module.html) struct for details of publicly available functions.
+See the
+[`Module`](https://docs.rs/pallet-insecure-randomness-collective-flip/latest/pallet_insecure_randomness_collective_flip/struct.Module.html)
+struct for details of publicly available functions.

 ## Usage

 ### Prerequisites

-Import the Randomness Collective Flip module and derive your module's configuration trait from
-the system trait.
+Import the Randomness Collective Flip module and derive your module's configuration trait from the system trait.

 ### Example - Get random seed for the current block

@@ -18,10 +18,10 @@ not available or desired.

 ### Dispatchable Functions

-* `as_multi` - Approve and if possible dispatch a call from a composite origin formed from a
+- `as_multi` - Approve and if possible dispatch a call from a composite origin formed from a
  number of signed origins.
-* `approve_as_multi` - Approve a call from a composite origin.
-* `cancel_as_multi` - Cancel a call from a composite origin.
+- `approve_as_multi` - Approve a call from a composite origin.
+- `cancel_as_multi` - Cancel a call from a composite origin.

 [`Call`]: ./enum.Call.html
 [`Config`]: ./trait.Config.html
@@ -1,6 +1,8 @@
-### Lock NFT
+# Lock NFT

 Lock an NFT from `pallet-nfts` and mint fungible assets from `pallet-assets`.

-The NFT gets locked by putting a system-level attribute named `Locked`. This prevents the NFT from being transferred further.
-The NFT becomes unlocked when the `Locked` attribute is removed. In order to unify the fungible asset and unlock the NFT, an account must hold the full issuance of the asset the NFT was fractionalised into. Holding less of the fungible asset will not allow the unlocking of the NFT. 
+The NFT gets locked by putting a system-level attribute named `Locked`. This prevents the NFT from being transferred
+further. The NFT becomes unlocked when the `Locked` attribute is removed. In order to unify the fungible asset and
+unlock the NFT, an account must hold the full issuance of the asset the NFT was fractionalised into. Holding less of the
+fungible asset will not allow the unlocking of the NFT.
@@ -13,9 +13,11 @@ The NFTs pallet provides functionality for non-fungible tokens' management, incl
 * Attributes Management
 * NFT Burning

-To use it in your runtime, you need to implement [`nfts::Config`](https://paritytech.github.io/substrate/master/pallet_nfts/pallet/trait.Config.html).
+To use it in your runtime, you need to implement
+[`nfts::Config`](https://paritytech.github.io/substrate/master/pallet_nfts/pallet/trait.Config.html).

-The supported dispatchable functions are documented in the [`nfts::Call`](https://paritytech.github.io/substrate/master/pallet_nfts/pallet/enum.Call.html) enum.
+The supported dispatchable functions are documented in the
+[`nfts::Call`](https://paritytech.github.io/substrate/master/pallet_nfts/pallet/enum.Call.html) enum.

 ### Terminology

@@ -24,8 +26,9 @@ The supported dispatchable functions are documented in the [`nfts::Call`](https:
 * **NFT transfer:** The action of sending an item from one account to another.
 * **Atomic swap:** The action of exchanging items between accounts without needing a 3rd party service.
 * **NFT burning:** The destruction of an item.
-* **Non-fungible token (NFT):** An item for which each unit has unique characteristics. There is exactly
-  one instance of such an item in existence and there is exactly one owning account (though that owning account could be a proxy account or multi-sig account).
+* **Non-fungible token (NFT):** An item for which each unit has unique characteristics. There is exactly one instance of
+  such an item in existence and there is exactly one owning account (though that owning account could be a proxy account
+  or multi-sig account).
 * **Soul Bound NFT:** An item that is non-transferable from the account which it is minted into.

 ### Goals
@@ -35,10 +38,8 @@ The NFTs pallet in Substrate is designed to make the following possible:
 * Allow accounts to permissionlessly create nft collections.
 * Allow a named (permissioned) account to mint and burn unique items within a collection.
 * Move items between accounts permissionlessly.
-* Allow a named (permissioned) account to freeze and unfreeze items within a
-  collection or the entire collection.
-* Allow the owner of an item to delegate the ability to transfer the item to some
-  named third-party.
+* Allow a named (permissioned) account to freeze and unfreeze items within a collection or the entire collection.
+* Allow the owner of an item to delegate the ability to transfer the item to some named third-party.
 * Allow third-parties to store information in an NFT _without_ owning it (Eg. save game state).

 ## Interface
@@ -71,7 +72,8 @@ The NFTs pallet in Substrate is designed to make the following possible:
 * `clear_all_transfer_approvals`: Clears all transfer approvals set by calling the `approve_transfer`.
 * `lock_collection`: Prevent all items within a collection from being transferred (making them all `soul bound`).
 * `lock_item_properties`: Lock item's metadata or attributes.
-* `transfer_ownership`: Alter the owner of a collection, moving all associated deposits. (Ownership of individual items will not be affected.)
+* `transfer_ownership`: Alter the owner of a collection, moving all associated deposits. (Ownership of individual items
+  will not be affected.)
 * `set_team`: Alter the permissioned accounts of a collection.
 * `set_collection_max_supply`: Change the max supply of a collection.
 * `update_mint_settings`: Update the minting settings for collection.
@@ -94,8 +96,8 @@ The NFTs pallet in Substrate is designed to make the following possible:
 * `force_collection_config`: Change collection's config.
 * `force_set_attribute`: Set an attribute.

-Please refer to the [`Call`](https://paritytech.github.io/substrate/master/pallet_nfts/pallet/enum.Call.html) enum
-and its associated variants for documentation on each function.
+Please refer to the [`Call`](https://paritytech.github.io/substrate/master/pallet_nfts/pallet/enum.Call.html) enum and
+its associated variants for documentation on each function.

 ## Related Modules

@@ -14,10 +14,10 @@ have not been designed to be economically secure. Do not use this pallet as-is i

 ### Dispatchable Functions

-* `set_name` - Set the associated name of an account; a small deposit is reserved if not already
+- `set_name` - Set the associated name of an account; a small deposit is reserved if not already
  taken.
-* `clear_name` - Remove an account's associated name; the deposit is returned.
-* `kill_name` - Forcibly remove the associated name; the deposit is lost.
+- `clear_name` - Remove an account's associated name; the deposit is returned.
+- `kill_name` - Forcibly remove the associated name; the deposit is lost.

 [`Call`]: ./enum.Call.html
 [`Config`]: ./trait.Config.html
@@ -2,4 +2,4 @@

 Provides a non-interactiove variant of staking.

-License: Apache-2.0
+License: Apache-2.0
@@ -1,3 +1,3 @@
 Runtime API definition for nomination-pools pallet.

-License: Apache-2.0
+License: Apache-2.0
@@ -2,4 +2,4 @@

 Tracks reported offences

-License: Apache-2.0
+License: Apache-2.0
@@ -1,3 +1,3 @@
 Offences pallet benchmarking.

-License: Apache-2.0
+License: Apache-2.0
@@ -1,4 +1,4 @@
-# Ranked collective system.
+# Ranked collective system

 This is a membership pallet providing a `Tally` implementation ready for use with polling
 systems such as the Referenda pallet. Members each have a rank, with zero being the lowest.
@@ -16,11 +16,11 @@ friends are needed to give another account access to the recoverable account.

 The recovery process for each recoverable account can be configured by the account owner.
 They are able to choose:
-* `friends` - The list of friends that the account owner trusts to protect the
+- `friends` - The list of friends that the account owner trusts to protect the
  recovery process for their account.
-* `threshold` - The number of friends that need to approve a recovery process for
+- `threshold` - The number of friends that need to approve a recovery process for
  the account to be successfully recovered.
-* `delay_period` - The minimum number of blocks after the beginning of the recovery
+- `delay_period` - The minimum number of blocks after the beginning of the recovery
  process that need to pass before the account can be successfully recovered.

 There is a configurable deposit that all users need to pay to create a recovery
@@ -84,20 +84,20 @@ It is important to note that this is a powerful pallet that can compromise the
 security of an account if used incorrectly. Some recommended practices for users
 of this pallet are:

-* Configure a significant `delay_period` for your recovery process: As long as you
+- Configure a significant `delay_period` for your recovery process: As long as you
  have access to your recoverable account, you need only check the blockchain once
  every `delay_period` blocks to ensure that no recovery attempt is successful
  against your account. Using off-chain notification systems can help with this,
  but ultimately, setting a large `delay_period` means that even the most skilled
  attacker will need to wait this long before they can access your account.
-* Use a high threshold of approvals: Setting a value of 1 for the threshold means
+- Use a high threshold of approvals: Setting a value of 1 for the threshold means
  that any of your friends would be able to recover your account. They would
  simply need to start a recovery process and approve their own process. Similarly,
  a threshold of 2 would mean that any 2 friends could work together to gain
  access to your account. The only way to prevent against these kinds of attacks
  is to choose a high threshold of approvals and select from a diverse friend
  group that would not be able to reasonably coordinate with one another.
-* Reset your configuration over time: Since the entire deposit of creating a
+- Reset your configuration over time: Since the entire deposit of creating a
  recovery configuration is returned to the user, the only cost of updating
  your recovery configuration is the transaction fees for the calls. Thus,
  it is strongly encouraged to regularly update your recovery configuration
@@ -110,25 +110,25 @@ of this pallet are:

 #### For General Users

-* `create_recovery` - Create a recovery configuration for your account and make it recoverable.
-* `initiate_recovery` - Start the recovery process for a recoverable account.
+- `create_recovery` - Create a recovery configuration for your account and make it recoverable.
+- `initiate_recovery` - Start the recovery process for a recoverable account.

 #### For Friends of a Recoverable Account
-* `vouch_recovery` - As a `friend` of a recoverable account, vouch for a recovery attempt on the account.
+- `vouch_recovery` - As a `friend` of a recoverable account, vouch for a recovery attempt on the account.

 #### For a User Who Successfully Recovered an Account

-* `claim_recovery` - Claim access to the account that you have successfully completed the recovery process for.
-* `as_recovered` - Send a transaction as an account that you have recovered. See other functions below.
+- `claim_recovery` - Claim access to the account that you have successfully completed the recovery process for.
+- `as_recovered` - Send a transaction as an account that you have recovered. See other functions below.

 #### For the Recoverable Account

-* `close_recovery` - Close an active recovery process for your account and reclaim the recovery deposit.
-* `remove_recovery` - Remove the recovery configuration from the account, making it un-recoverable.
+- `close_recovery` - Close an active recovery process for your account and reclaim the recovery deposit.
+- `remove_recovery` - Remove the recovery configuration from the account, making it un-recoverable.

 #### For Super Users

-* `set_recovered` - The ROOT origin is able to skip the recovery process and directly allow
+- `set_recovered` - The ROOT origin is able to skip the recovery process and directly allow
  one account to access another.

 License: Apache-2.0
@@ -1,6 +1,6 @@
 # Remark Storage Pallet

-Allows storing arbitrary data off chain. 
+Allows storing arbitrary data off chain.


 License: Apache-2.0
@@ -2,4 +2,4 @@

 Pallet that allows the root to create an offence.

-NOTE: This pallet should only be used for testing purposes.
+NOTE: This pallet should only be used for testing purposes.
@@ -2,4 +2,4 @@

 Pallet that contains extrinsics that can be usefull in testing.

-NOTE: This pallet should only be used for testing purposes and should not be used in production runtimes!
+NOTE: This pallet should only be used for testing purposes and should not be used in production runtimes!
@@ -1,3 +1,3 @@
 # Salary

-Make periodic payment to members of a ranked collective according to rank.
+Make periodic payment to members of a ranked collective according to rank.
@@ -23,12 +23,12 @@ then those filter will not be used when dispatching the schedule call.

 ### Dispatchable Functions

-* `schedule` - schedule a dispatch, which may be periodic, to occur at a
+- `schedule` - schedule a dispatch, which may be periodic, to occur at a
  specified block and with a specified priority.
-* `cancel` - cancel a scheduled dispatch, specified by block number and
+- `cancel` - cancel a scheduled dispatch, specified by block number and
  index.
-* `schedule_named` - augments the `schedule` interface with an additional
+- `schedule_named` - augments the `schedule` interface with an additional
  `Vec<u8>` parameter that can be used for identification.
-* `cancel_named` - the named complement to the cancel function.
+- `cancel_named` - the named complement to the cancel function.

 License: Apache 2.0
@@ -1,7 +1,7 @@
 # Session Pallet

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

 - [`session::Trait`](https://docs.rs/pallet-session/latest/pallet_session/trait.Config.html)
 - [`Call`](https://docs.rs/pallet-session/latest/pallet_session/enum.Call.html)
@@ -12,34 +12,31 @@ the session length, and handles session rotation.
 ### Terminology
 <!-- Original author of paragraph: @gavofyork -->

- **Session:** 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. The block where a session is
-ended is determined by the `ShouldEndSession` trait. When the session is ending, a new validator set
-can be chosen by `OnSessionEnding` implementations.
- **Session key:** 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.
- **Validator ID:** Every account has an associated validator ID. For some simple staking systems, this
-may just be the same as the account ID. For staking systems using a stash/controller model,
-the validator ID would be the stash account ID of the controller.
- **Session key configuration process:** Session keys are set using `set_keys` for use not in
-the next session, but the session after next. They are stored in `NextKeys`, a mapping between
-the caller's `ValidatorId` and the session keys provided. `set_keys` allows users to set their
-session key prior to being selected as validator.
-It is a public call since it uses `ensure_signed`, which checks that the origin is a signed account.
-As such, the account ID of the origin stored in `NextKeys` may not necessarily be associated with
-a block author or a validator. The session keys of accounts are removed once their account balance is zero.
- **Session length:** This pallet does not assume anything about the length of each session.
-Rather, it relies on an implementation of `ShouldEndSession` to dictate a new session's start.
-This pallet provides the `PeriodicSessions` struct for simple periodic sessions.
- **Session rotation configuration:** Configure as either a 'normal' (rewardable session where rewards are
-applied) or 'exceptional' (slashable) session rotation.
- **Session rotation process:** At the beginning of each block, the `on_initialize` function
-queries the provided implementation of `ShouldEndSession`. If the session is to end the newly
-activated validator IDs and session keys are taken from storage and passed to the
-`SessionHandler`. The validator set supplied by `SessionManager::new_session` and the corresponding session
-keys, which may have been registered via `set_keys` during the previous session, are written
-to storage where they will wait one session before being passed to the `SessionHandler`
-themselves.
+- **Session:** 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. The block where a session is ended is determined by
+the `ShouldEndSession` trait. When the session is ending, a new validator set can be chosen by `OnSessionEnding`
+implementations.
+- **Session key:** 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.
+- **Validator ID:** Every account has an associated validator ID. For some simple staking systems, this may just be the
+same as the account ID. For staking systems using a stash/controller model, the validator ID would be the stash account
+ID of the controller.
+- **Session key configuration process:** Session keys are set using `set_keys` for use not in the next session, but the
+session after next. They are stored in `NextKeys`, a mapping between the caller's `ValidatorId` and the session keys
+provided. `set_keys` allows users to set their session key prior to being selected as validator. It is a public call
+since it uses `ensure_signed`, which checks that the origin is a signed account. As such, the account ID of the origin
+stored in `NextKeys` may not necessarily be associated with a block author or a validator. The session keys of accounts
+are removed once their account balance is zero.
+- **Session length:** This pallet does not assume anything about the length of each session. Rather, it relies on an
+implementation of `ShouldEndSession` to dictate a new session's start. This pallet provides the `PeriodicSessions`
+struct for simple periodic sessions.
+- **Session rotation configuration:** Configure as either a 'normal' (rewardable session where rewards are applied) or
+'exceptional' (slashable) session rotation.
+- **Session rotation process:** At the beginning of each block, the `on_initialize` function queries the provided
+implementation of `ShouldEndSession`. If the session is to end the newly activated validator IDs and session keys are
+taken from storage and passed to the `SessionHandler`. The validator set supplied by `SessionManager::new_session` and
+the corresponding session keys, which may have been registered via `set_keys` during the previous session, are written
+to storage where they will wait one session before being passed to the `SessionHandler` themselves.

 ### Goals

@@ -57,8 +54,8 @@ The Session pallet is designed to make the following possible:

 ### Public Functions

- `rotate_session` - Change to the next session. Register the new authority set. Queue changes
-for next session rotation.
+- `rotate_session` - Change to the next session. Register the new authority set. Queue changes for next session
+rotation.
 - `disable_index` - Disable a validator by index.
 - `disable` - Disable a validator by Validator ID

@@ -66,7 +63,8 @@ for next session rotation.

 ### Example from the FRAME

-The [Staking pallet](https://docs.rs/pallet-staking/latest/pallet_staking/) uses the Session pallet to get the validator set.
+The [Staking pallet](https://docs.rs/pallet-staking/latest/pallet_staking/) uses the Session pallet to get the validator
+set.

 ```rust
 use pallet_session as session;
@@ -1,3 +1,3 @@
 Benchmarks for the Session Pallet.

-License: Apache-2.0
+License: Apache-2.0
@@ -11,16 +11,16 @@ and maintain a membership society.
 ### User Types

 At any point, a user in the society can be one of a:
-* Bidder - A user who has submitted intention of joining the society.
-* Candidate - A user who will be voted on to join the society.
-* Suspended Candidate - A user who failed to win a vote.
-* Member - A user who is a member of the society.
-* Suspended Member - A member of the society who has accumulated too many strikes
+- Bidder - A user who has submitted intention of joining the society.
+- Candidate - A user who will be voted on to join the society.
+- Suspended Candidate - A user who failed to win a vote.
+- Member - A user who is a member of the society.
+- Suspended Member - A member of the society who has accumulated too many strikes
 or failed their membership challenge.

 Of the non-suspended members, there is always a:
-* Head - A member who is exempt from suspension.
-* Defender - A member whose membership is under question and voted on again.
+- Head - A member who is exempt from suspension.
+- Defender - A member whose membership is under question and voted on again.

 Of the non-suspended members of the society, a random set of them are chosen as
 "skeptics". The mechanics of skeptics is explained in the
@@ -201,28 +201,28 @@ future payouts slashed.

 #### For General Users

-* `bid` - A user can make a bid to join the membership society by reserving a deposit.
-* `unbid` - A user can withdraw their bid for entry, the deposit is returned.
+- `bid` - A user can make a bid to join the membership society by reserving a deposit.
+- `unbid` - A user can withdraw their bid for entry, the deposit is returned.

 #### For Members

-* `vouch` - A member can place a bid on behalf of a user to join the membership society.
-* `unvouch` - A member can revoke their vouch for a user.
-* `vote` - A member can vote to approve or reject a candidate's request to join the society.
-* `defender_vote` - A member can vote to approve or reject a defender's continued membership
+- `vouch` - A member can place a bid on behalf of a user to join the membership society.
+- `unvouch` - A member can revoke their vouch for a user.
+- `vote` - A member can vote to approve or reject a candidate's request to join the society.
+- `defender_vote` - A member can vote to approve or reject a defender's continued membership
 to the society.
-* `payout` - A member can claim their first matured payment.
-* `unfound` - Allow the founder to unfound the society when they are the only member.
+- `payout` - A member can claim their first matured payment.
+- `unfound` - Allow the founder to unfound the society when they are the only member.

 #### For Super Users

-* `found` - The founder origin can initiate this society. Useful for bootstrapping the Society
+- `found` - The founder origin can initiate this society. Useful for bootstrapping the Society
 pallet on an already running chain.
-* `judge_suspended_member` - The suspension judgement origin is able to make
+- `judge_suspended_member` - The suspension judgement origin is able to make
 judgement on a suspended member.
-* `judge_suspended_candidate` - The suspension judgement origin is able to
+- `judge_suspended_candidate` - The suspension judgement origin is able to
 make judgement on a suspended candidate.
-* `set_max_membership` - The ROOT origin can update the maximum member count for the society.
+- `set_max_membership` - The ROOT origin can update the maximum member count for the society.
 The max membership count must be greater than 1.

 License: Apache-2.0
@@ -8,25 +8,24 @@ The Staking module is used to manage funds at stake by network maintainers.

 ## Overview

-The Staking module is the means by which a set of network maintainers (known as _authorities_ in
-some contexts and _validators_ in others) are chosen based upon those who voluntarily place
-funds under deposit. Under deposit, those funds are rewarded under normal operation but are held
-at pain of _slash_ (expropriation) should the staked maintainer be found not to be discharging
-its duties properly.
+The Staking module is the means by which a set of network maintainers (known as _authorities_ in some contexts and
+_validators_ in others) are chosen based upon those who voluntarily place funds under deposit. Under deposit, those
+funds are rewarded under normal operation but are held at pain of _slash_ (expropriation) should the staked maintainer
+be found not to be discharging its duties properly.

 ### Terminology
 <!-- Original author of paragraph: @gavofyork -->

- Staking: The process of locking up funds for some time, placing them at risk of slashing
-  (loss) in order to become a rewarded maintainer of the network.
- Validating: The process of running a node to actively maintain the network, either by
-  producing blocks or guaranteeing finality of the chain.
- Nominating: The process of placing staked funds behind one or more validators in order to
-  share in any reward, and punishment, they take.
+- Staking: The process of locking up funds for some time, placing them at risk of slashing (loss) in order to become a
+  rewarded maintainer of the network.
+- Validating: The process of running a node to actively maintain the network, either by producing blocks or guaranteeing
+  finality of the chain.
+- Nominating: The process of placing staked funds behind one or more validators in order to share in any reward, and
+  punishment, they take.
 - Stash account: The account holding an owner's funds used for staking.
 - Controller account: The account that controls an owner's funds for staking.
- Era: A (whole) number of sessions, which is the period that the validator set (and each
-  validator's active nominator set) is recalculated and where rewards are paid out.
+- Era: A (whole) number of sessions, which is the period that the validator set (and each validator's active nominator
+  set) is recalculated and where rewards are paid out.
 - Slash: The punishment of a staker by reducing its funds.

 ### Goals
@@ -42,91 +41,90 @@ The staking system in Substrate NPoS is designed to make the following possible:

 #### Staking

-Almost any interaction with the Staking module requires a process of _**bonding**_ (also known
-as being a _staker_). To become *bonded*, a fund-holding account known as the _stash account_,
-which holds some or all of the funds that become frozen in place as part of the staking process,
-is paired with an active **controller** account, which issues instructions on how they shall be
-used.
+Almost any interaction with the Staking module requires a process of _**bonding**_ (also known as being a _staker_). To
+become *bonded*, a fund-holding account known as the _stash account_, which holds some or all of the funds that become
+frozen in place as part of the staking process, is paired with an active **controller** account, which issues
+instructions on how they shall be used.

-An account pair can become bonded using the [`bond`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.bond) call.
+An account pair can become bonded using the
+[`bond`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.bond) call.

 Stash accounts can update their associated controller back to their stash account using the
-[`set_controller`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.set_controller)
-call. 
+[`set_controller`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.set_controller) call.

-Note: Controller accounts are being deprecated in favor of proxy accounts, so it is no longer
-possible to set a unique address for a stash's controller.
+Note: Controller accounts are being deprecated in favor of proxy accounts, so it is no longer possible to set a unique
+address for a stash's controller.

-There are three possible roles that any staked account pair can be in: `Validator`, `Nominator`
-and `Idle` (defined in [`StakerStatus`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.StakerStatus.html)). There are three
+There are three possible roles that any staked account pair can be in: `Validator`, `Nominator` and `Idle` (defined in
+[`StakerStatus`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.StakerStatus.html)). There are three
 corresponding instructions to change between roles, namely:
 [`validate`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.validate),
-[`nominate`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.nominate), and [`chill`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.chill).
+[`nominate`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.nominate), and
+[`chill`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.chill).

 #### Validating

-A **validator** takes the role of either validating blocks or ensuring their finality,
-maintaining the veracity of the network. A validator should avoid both any sort of malicious
-misbehavior and going offline. Bonded accounts that state interest in being a validator do NOT
-get immediately chosen as a validator. Instead, they are declared as a _candidate_ and they
-_might_ get elected at the _next era_ as a validator. The result of the election is determined
-by nominators and their votes.
+A **validator** takes the role of either validating blocks or ensuring their finality, maintaining the veracity of the
+network. A validator should avoid both any sort of malicious misbehavior and going offline. Bonded accounts that state
+interest in being a validator do NOT get immediately chosen as a validator. Instead, they are declared as a _candidate_
+and they _might_ get elected at the _next era_ as a validator. The result of the election is determined by nominators
+and their votes.

 An account can become a validator candidate via the
 [`validate`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.validate) call.

 #### Nomination

-A **nominator** does not take any _direct_ role in maintaining the network, instead, it votes on
-a set of validators  to be elected. Once interest in nomination is stated by an account, it
-takes effect at the next election round. The funds in the nominator's stash account indicate the
-_weight_ of its vote. Both the rewards and any punishment that a validator earns are shared
-between the validator and its nominators. This rule incentivizes the nominators to NOT vote for
-the misbehaving/offline validators as much as possible, simply because the nominators will also
-lose funds if they vote poorly.
+A **nominator** does not take any _direct_ role in maintaining the network, instead, it votes on a set of validators  to
+be elected. Once interest in nomination is stated by an account, it takes effect at the next election round. The funds
+in the nominator's stash account indicate the _weight_ of its vote. Both the rewards and any punishment that a validator
+earns are shared between the validator and its nominators. This rule incentivizes the nominators to NOT vote for the
+misbehaving/offline validators as much as possible, simply because the nominators will also lose funds if they vote
+poorly.

-An account can become a nominator via the [`nominate`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.nominate) call.
+An account can become a nominator via the
+[`nominate`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.nominate) call.

 #### Rewards and Slash

-The **reward and slashing** procedure is the core of the Staking module, attempting to _embrace
-valid behavior_ while _punishing any misbehavior or lack of availability_.
+The **reward and slashing** procedure is the core of the Staking module, attempting to _embrace valid behavior_ while
+_punishing any misbehavior or lack of availability_.

-Rewards must be claimed for each era before it gets too old by `$HISTORY_DEPTH` using the
-`payout_stakers` call. Any account can call `payout_stakers`, which pays the reward to the
-validator as well as its nominators. Only the [`Config::MaxNominatorRewardedPerValidator`]
-biggest stakers can claim their reward. This is to limit the i/o cost to mutate storage for each
-nominator's account.
+Rewards must be claimed for each era before it gets too old by `$HISTORY_DEPTH` using the `payout_stakers` call. Any
+account can call `payout_stakers`, which pays the reward to the validator as well as its nominators. Only the
+[`Config::MaxNominatorRewardedPerValidator`] biggest stakers can claim their reward. This is to limit the i/o cost to
+mutate storage for each nominator's account.

-Slashing can occur at any point in time, once misbehavior is reported. Once slashing is
-determined, a value is deducted from the balance of the validator and all the nominators who
-voted for this validator (values are deducted from the _stash_ account of the slashed entity).
+Slashing can occur at any point in time, once misbehavior is reported. Once slashing is determined, a value is deducted
+from the balance of the validator and all the nominators who voted for this validator (values are deducted from the
+_stash_ account of the slashed entity).

 Slashing logic is further described in the documentation of the `slashing` module.

-Similar to slashing, rewards are also shared among a validator and its associated nominators.
-Yet, the reward funds are not always transferred to the stash account and can be configured. See
-[Reward Calculation](https://docs.rs/pallet-staking/latest/pallet_staking/#reward-calculation) for more details.
+Similar to slashing, rewards are also shared among a validator and its associated nominators. Yet, the reward funds are
+not always transferred to the stash account and can be configured. See [Reward
+Calculation](https://docs.rs/pallet-staking/latest/pallet_staking/#reward-calculation) for more details.

 #### Chilling

-Finally, any of the roles above can choose to step back temporarily and just chill for a while.
-This means that if they are a nominator, they will not be considered as voters anymore and if
-they are validators, they will no longer be a candidate for the next election.
+Finally, any of the roles above can choose to step back temporarily and just chill for a while. This means that if they
+are a nominator, they will not be considered as voters anymore and if they are validators, they will no longer be a
+candidate for the next election.

-An account can step back via the [`chill`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.chill) call.
+An account can step back via the
+[`chill`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.chill) call.

 ### Session managing

-The module implement the trait `SessionManager`. Which is the only API to query new validator
-set and allowing these validator set to be rewarded once their era is ended.
+The module implement the trait `SessionManager`. Which is the only API to query new validator set and allowing these
+validator set to be rewarded once their era is ended.

 ## Interface

 ### Dispatchable Functions

-The dispatchable functions of the Staking module enable the steps needed for entities to accept
-and change their role, alongside some helper functions to get/set the metadata of the module.
+The dispatchable functions of the Staking module enable the steps needed for entities to accept and change their role,
+alongside some helper functions to get/set the metadata of the module.

 ### Public Functions

@@ -134,7 +132,7 @@ The Staking module contains many public storage items and (im)mutable functions.

 ## Usage

-### Example: Rewarding a validator by id.
+### Example: Rewarding a validator by id

 ```rust
 use pallet_staking::{self as staking};
@@ -169,7 +167,8 @@ pub mod pallet {
 ### Era payout

 The era payout is computed using yearly inflation curve defined at
-[`T::RewardCurve`](https://docs.rs/pallet-staking/latest/pallet_staking/trait.Config.html#associatedtype.RewardCurve) as such:
+[`T::RewardCurve`](https://docs.rs/pallet-staking/latest/pallet_staking/trait.Config.html#associatedtype.RewardCurve) as
+such:

 ```nocompile
 staker_payout = yearly_inflation(npos_token_staked / total_tokens) * total_tokens / era_per_year
@@ -184,37 +183,38 @@ The remaining reward is send to the configurable end-point

 ### Reward Calculation

-Validators and nominators are rewarded at the end of each era. The total reward of an era is
-calculated using the era duration and the staking rate (the total amount of tokens staked by
-nominators and validators, divided by the total token supply). It aims to incentivize toward a
-defined staking rate. The full specification can be found
+Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era
+duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total
+token supply). It aims to incentivize toward a defined staking rate. The full specification can be found
 [here](https://research.web3.foundation/en/latest/polkadot/economics/1-token-economics.html#inflation-model).

-Total reward is split among validators and their nominators depending on the number of points
-they received during the era. Points are added to a validator using
+Total reward is split among validators and their nominators depending on the number of points they received during the
+era. Points are added to a validator using
 [`reward_by_ids`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.reward_by_ids) or
 [`reward_by_indices`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.reward_by_indices).

 [`Module`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Module.html) implements
-[`pallet_authorship::EventHandler`](https://docs.rs/pallet-authorship/latest/pallet_authorship/trait.EventHandler.html) to add reward
-points to block producer and block producer of referenced uncles.
+[`pallet_authorship::EventHandler`](https://docs.rs/pallet-authorship/latest/pallet_authorship/trait.EventHandler.html)
+to add reward points to block producer and block producer of referenced uncles.

 The validator and its nominator split their reward as following:

 The validator can declare an amount, named
-[`commission`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.ValidatorPrefs.html#structfield.commission), that does not get shared
-with the nominators at each reward payout through its
-[`ValidatorPrefs`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.ValidatorPrefs.html). This value gets deducted from the total reward
-that is paid to the validator and its nominators. The remaining portion is split among the
-validator and all of the nominators that nominated the validator, proportional to the value
-staked behind this validator (_i.e._ dividing the
+[`commission`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.ValidatorPrefs.html#structfield.commission),
+that does not get shared with the nominators at each reward payout through its
+[`ValidatorPrefs`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.ValidatorPrefs.html). This value gets
+deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among
+the validator and all of the nominators that nominated the validator, proportional to the value staked behind this
+validator (_i.e._ dividing the
 [`own`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Exposure.html#structfield.own) or
 [`others`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Exposure.html#structfield.others) by
-[`total`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Exposure.html#structfield.total) in [`Exposure`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Exposure.html)).
+[`total`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Exposure.html#structfield.total) in
+[`Exposure`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Exposure.html)).

 All entities who receive a reward have the option to choose their reward destination through the
 [`Payee`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.Payee.html) storage item (see
-[`set_payee`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.set_payee)), to be one of the following:
+[`set_payee`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.set_payee)), to be one of the
+following:

 - Controller account, (obviously) not increasing the staked value.
 - Stash account, not increasing the staked value.
@@ -225,32 +225,33 @@ All entities who receive a reward have the option to choose their reward destina
 Any funds already placed into stash can be the target of the following operations:

 The controller account can free a portion (or all) of the funds using the
-[`unbond`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.unbond) call. Note that the funds are not immediately
-accessible. Instead, a duration denoted by [`BondingDuration`](https://docs.rs/pallet-staking/latest/pallet_staking/trait.Config.html#associatedtype.BondingDuration)
-(in number of eras) must pass until the funds can actually be removed. Once the
-`BondingDuration` is over, the [`withdraw_unbonded`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.withdraw_unbonded)
+[`unbond`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.unbond) call. Note that the funds
+are not immediately accessible. Instead, a duration denoted by
+[`BondingDuration`](https://docs.rs/pallet-staking/latest/pallet_staking/trait.Config.html#associatedtype.BondingDuration)
+(in number of eras) must pass until the funds can actually be removed. Once the `BondingDuration` is over, the
+[`withdraw_unbonded`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.withdraw_unbonded)
 call can be used to actually withdraw the funds.

-Note that there is a limitation to the number of fund-chunks that can be scheduled to be
-unlocked in the future via [`unbond`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.unbond). In case this maximum
-(`MAX_UNLOCKING_CHUNKS`) is reached, the bonded account _must_ first wait until a successful
-call to `withdraw_unbonded` to remove some of the chunks.
+Note that there is a limitation to the number of fund-chunks that can be scheduled to be unlocked in the future via
+[`unbond`](https://docs.rs/pallet-staking/latest/pallet_staking/enum.Call.html#variant.unbond). In case this maximum
+(`MAX_UNLOCKING_CHUNKS`) is reached, the bonded account _must_ first wait until a successful call to `withdraw_unbonded`
+to remove some of the chunks.

 ### Election Algorithm

-The current election algorithm is implemented based on Phragmén. The reference implementation
-can be found [here](https://github.com/w3f/consensus/tree/master/NPoS).
+The current election algorithm is implemented based on Phragmén. The reference implementation can be found
+[here](https://github.com/w3f/consensus/tree/master/NPoS).

-The election algorithm, aside from electing the validators with the most stake value and votes,
-tries to divide the nominator votes among candidates in an equal manner. To further assure this,
-an optional post-processing can be applied that iteratively normalizes the nominator staked
-values until the total difference among votes of a particular nominator are less than a
-threshold.
+The election algorithm, aside from electing the validators with the most stake value and votes, tries to divide the
+nominator votes among candidates in an equal manner. To further assure this, an optional post-processing can be applied
+that iteratively normalizes the nominator staked values until the total difference among votes of a particular nominator
+are less than a threshold.

 ## GenesisConfig

-The Staking module depends on the [`GenesisConfig`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.GenesisConfig.html). The
-`GenesisConfig` is optional and allow to set some initial stakers.
+The Staking module depends on the
+[`GenesisConfig`](https://docs.rs/pallet-staking/latest/pallet_staking/struct.GenesisConfig.html). The `GenesisConfig`
+is optional and allow to set some initial stakers.

 ## Related Modules

@@ -16,8 +16,8 @@ Only one account can be the sudo key at a time.

 Only the sudo key can call the dispatchable functions from the Sudo module.

-* `sudo` - Make a `Root` call to a dispatchable function.
-* `set_key` - Assign a new account to be the sudo key.
+- `sudo` - Make a `Root` call to a dispatchable function.
+- `set_key` - Assign a new account to be the sudo key.

 ## Usage

@@ -68,7 +68,7 @@ You need to set an initial superuser account as the sudo `key`.

 ## Related Modules

-* [Democracy](https://docs.rs/pallet-democracy/latest/pallet_democracy/)
+- [Democracy](https://docs.rs/pallet-democracy/latest/pallet_democracy/)

 [`Call`]: ./enum.Call.html
 [`Config`]: ./trait.Config.html
@@ -1,3 +1,3 @@
 Support code for the runtime.

-License: Apache-2.0
+License: Apache-2.0
@@ -1386,7 +1386,7 @@ fn metadata() {
 		}
 	}

-	let readme = "Support code for the runtime.\n\nLicense: Apache-2.0";
+	let readme = "Support code for the runtime.\n\nLicense: Apache-2.0\n";
 	let expected_pallet_doc = vec![" Pallet documentation", readme, readme];

 	let pallets = vec![
@@ -1889,7 +1889,7 @@ fn metadata_ir_pallet_runtime_docs() {
 		.find(|pallet| pallet.name == "Example")
 		.expect("Pallet should be present");

-	let readme = "Support code for the runtime.\n\nLicense: Apache-2.0";
+	let readme = "Support code for the runtime.\n\nLicense: Apache-2.0\n";
 	let expected = vec![" Pallet documentation", readme, readme];
 	assert_eq!(pallet.docs, expected);
 }
@@ -1919,7 +1919,7 @@ fn extrinsic_metadata_ir_types() {
 #[test]
 fn test_pallet_runtime_docs() {
 	let docs = crate::pallet::Pallet::<Runtime>::pallet_documentation_metadata();
-	let readme = "Support code for the runtime.\n\nLicense: Apache-2.0";
+	let readme = "Support code for the runtime.\n\nLicense: Apache-2.0\n";
 	let expected = vec![" Pallet documentation", readme, readme];
 	assert_eq!(docs, expected);
 }
@@ -1,20 +1,20 @@
 # System Module

-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.
+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.

 - [`system::Config`](https://docs.rs/frame-system/latest/frame_system/pallet/trait.Config.html)

 ## Overview

-The System module defines the core data types used in a Substrate runtime.
-It also provides several utility functions (see [`Pallet`](https://docs.rs/frame-system/latest/frame_system/pallet/struct.Pallet.html)) for other FRAME pallets.
+The System module defines the core data types used in a Substrate runtime. It also provides several utility functions
+(see [`Pallet`](https://docs.rs/frame-system/latest/frame_system/pallet/struct.Pallet.html)) 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.
+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.

-It also handles low-level tasks like depositing logs, basic set up and take down of
-temporary storage entries, and access to previous block hashes.
+It also handles low-level tasks like depositing logs, basic set up and take down of temporary storage entries, and
+access to previous block hashes.

 ## Interface

@@ -24,26 +24,22 @@ The System module does not implement any dispatchable functions.

 ### Public Functions

-See the [`Pallet`](https://docs.rs/frame-system/latest/frame_system/pallet/struct.Pallet.html) struct for details of publicly available functions.
+See the [`Pallet`](https://docs.rs/frame-system/latest/frame_system/pallet/struct.Pallet.html) struct for details of
+publicly available functions.

 ### Signed Extensions

 The System module defines the following extensions:

-  - [`CheckWeight`]: Checks the weight and length of the block and ensure that it does not
-    exceed the limits.
-  - [`CheckNonce`]: Checks the nonce of the transaction. Contains a single payload of type
-    `T::Nonce`.
+  - [`CheckWeight`]: Checks the weight and length of the block and ensure that it does not exceed the limits.
+  - [`CheckNonce`]: Checks the nonce of the transaction. Contains a single payload of type `T::Nonce`.
  - [`CheckEra`]: Checks the era of the transaction. Contains a single payload of type `Era`.
-  - [`CheckGenesis`]: Checks the provided genesis hash of the transaction. Must be a part of the
-    signed payload of the transaction.
-  - [`CheckSpecVersion`]: Checks that the runtime version is the same as the one used to sign the
-    transaction.
-  - [`CheckTxVersion`]: Checks that the transaction version is the same as the one used to sign the
+  - [`CheckGenesis`]: Checks the provided genesis hash of the transaction. Must be a part of the signed payload of the
    transaction.
+  - [`CheckSpecVersion`]: Checks that the runtime version is the same as the one used to sign the transaction.
+  - [`CheckTxVersion`]: Checks that the transaction version is the same as the one used to sign the transaction.

-Lookup the runtime aggregator file (e.g. `node/runtime`) to see the full list of signed
-extensions included in a chain.
+Lookup the runtime aggregator file (e.g. `node/runtime`) to see the full list of signed extensions included in a chain.

 ## Usage

@@ -1 +1 @@
-License: Apache-2.0
+License: Apache-2.0
@@ -2,4 +2,5 @@ These runtimes are used for benchmarking the `set_code` intrinsic.

 **Don't use them in production environments!**

-To update the just copy the new runtime from `target/release/wbuild/kitchensink-runtime/kitchensink_runtime.compact.compressed.wasm` to here.
+To update the just copy the new runtime from
+`target/release/wbuild/kitchensink-runtime/kitchensink_runtime.compact.compressed.wasm` to here.
@@ -4,4 +4,4 @@ This API should be imported and implemented by the runtime,
 of a node that wants to use the custom RPC extension
 adding System access methods.

-License: Apache-2.0
+License: Apache-2.0
@@ -22,16 +22,16 @@ because of cumulative calculation errors and hence should be avoided.

 ### Dispatchable Functions

-* `set` - Sets the current time.
+- `set` - Sets the current time.

 ### Public functions

-* `get` - Gets the current time for the current block. If this function is called prior to
+- `get` - Gets the current time for the current block. If this function is called prior to
 setting the timestamp, it will return the timestamp of the previous block.

 ### Config Getters

-* `MinimumPeriod` - Gets the minimum (and advised) period between blocks for the chain.
+- `MinimumPeriod` - Gets the minimum (and advised) period between blocks for the chain.

 ## Usage

@@ -78,6 +78,6 @@ the Timestamp module for session management.

 ## Related Modules

-* [Session](https://docs.rs/pallet-session/latest/pallet_session/)
+- [Session](https://docs.rs/pallet-session/latest/pallet_session/)

 License: Apache-2.0
@@ -11,7 +11,7 @@ entered where any remaining members can declare their tip amounts also. After th
 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.

-### Terminology
+## Terminology

 - **Tipping:** The process of gathering declarations of amounts to tip and taking the median amount
  to be transferred from the treasury to a beneficiary account.
@@ -30,4 +30,4 @@ any finders fee, in case of a public (and bonded) original report.
 - `tip_new` - Report an item worthy of a tip and declare a specific amount to tip.
 - `tip` - Declare or redeclare an amount to tip for a particular reason.
 - `close_tip` - Close and pay out a tip.
- `slash_tip` - Remove and slash an already-open tip.
+- `slash_tip` - Remove and slash an already-open tip.
@@ -2,8 +2,9 @@

 Indexes transactions and manages storage proofs.

-Allows storing arbitrary data on the chain. Data is automatically removed after `StoragePeriod` blocks, unless the storage is renewed.
-Validators must submit proof of storing a random chunk of data for block `N - StoragePeriod` when producing block `N`.
+Allows storing arbitrary data on the chain. Data is automatically removed after `StoragePeriod` blocks, unless the
+storage is renewed. Validators must submit proof of storing a random chunk of data for block `N - StoragePeriod` when
+producing block `N`.

 # Running a chain

@@ -15,8 +16,9 @@ Start with generating a chain spec.
 cargo run --release -- build-spec --chain=local > sc_init.json
 ```

-Edit the json chain spec file to customise the chain. The storage chain genesis params are configured in the `transactionStorage` section.
-Note that `storagePeriod` is specified in blocks and changing it also requires code changes at the moment.
+Edit the json chain spec file to customise the chain. The storage chain genesis params are configured in the
+`transactionStorage` section. Note that `storagePeriod` is specified in blocks and changing it also requires code
+changes at the moment.

 Build a raw spec from the init spec.

@@ -31,11 +33,11 @@ cargo run --release -- --chain=sc.json -d /tmp/alice --storage-chain --keep-bloc
 cargo run --release -- --chain=sc.json -d /tmp/bob --storage-chain --keep-blocks=100800 --ipfs-server --validator --bob
 ```

-`--storage-chain` enables transaction indexing.
-`--keep-blocks=100800` enables block pruning. The value here should be greater or equal than the storage period.
-`--ipfs-server` enables serving stored content over IPFS.
+`--storage-chain` enables transaction indexing. `--keep-blocks=100800` enables block pruning. The value here should be
+greater or equal than the storage period. `--ipfs-server` enables serving stored content over IPFS.

-Once the network is started, any other joining nodes need to sync with `--sync=fast`. Regular sync will fail because block pruning removes old blocks. The chain does not keep full block history.
+Once the network is started, any other joining nodes need to sync with `--sync=fast`. Regular sync will fail because
+block pruning removes old blocks. The chain does not keep full block history.

 ```bash
 cargo run --release -- --chain=sc.json -d /tmp/charlie --storage-chain --keep-blocks=100800 --ipfs-server --validator --charlie --sync=fast
@@ -43,7 +45,8 @@ cargo run --release -- --chain=sc.json -d /tmp/charlie --storage-chain --keep-bl

 # Making transactions

-To store data use the `transactionStorage.store` extrinsic. And IPFS CID can be generated from the Blake2-256 hash of the data.
+To store data use the `transactionStorage.store` extrinsic. And IPFS CID can be generated from the Blake2-256 hash of
+the data.

 ```js
 const util_crypto = require('@polkadot/util-crypto');
@@ -76,7 +79,8 @@ ipfs block get /ipfs/<CID> > kitten.jpeg
 ```

 To renew data and prevent it from being disposed after the storage period, use `transactionStorage.renew(block, index)`
-where `block` is the block number of the previous store or renew transction, and index is the index of that transaction in the block.
+where `block` is the block number of the previous store or renew transction, and index is the index of that transaction
+in the block.


 License: Apache-2.0
@@ -13,9 +13,11 @@ The Uniques module provides functionality for non-fungible tokens' management, i
 * Attributes Management
 * Item Burning

-To use it in your runtime, you need to implement [`uniques::Config`](https://paritytech.github.io/substrate/master/pallet_uniques/pallet/trait.Config.html).
+To use it in your runtime, you need to implement
+[`uniques::Config`](https://paritytech.github.io/substrate/master/pallet_uniques/pallet/trait.Config.html).

-The supported dispatchable functions are documented in the [`uniques::Call`](https://paritytech.github.io/substrate/master/pallet_uniques/pallet/enum.Call.html) enum.
+The supported dispatchable functions are documented in the
+[`uniques::Call`](https://paritytech.github.io/substrate/master/pallet_uniques/pallet/enum.Call.html) enum.

 ### Terminology

@@ -23,8 +25,8 @@ The supported dispatchable functions are documented in the [`uniques::Call`](htt
 * **Item minting:** The action of creating a new item within a collection.
 * **Item transfer:** The action of sending an item from one account to another.
 * **Item burning:** The destruction of an item.
-* **Non-fungible token (NFT):** An item for which each unit has unique characteristics. There is exactly
-  one instance of such an item in existence and there is exactly one owning account.
+* **Non-fungible token (NFT):** An item for which each unit has unique characteristics. There is exactly one instance of
+  such an item in existence and there is exactly one owning account.

 ### Goals

@@ -33,10 +35,8 @@ The Uniques pallet in Substrate is designed to make the following possible:
 * Allow accounts to permissionlessly create NFT collections.
 * Allow a named (permissioned) account to mint and burn unique items within a collection.
 * Move items between accounts permissionlessly.
-* Allow a named (permissioned) account to freeze and unfreeze unique items within a
-  collection or the entire collection.
-* Allow the owner of an item to delegate the ability to transfer the item to some
-  named third-party.
+* Allow a named (permissioned) account to freeze and unfreeze unique items within a collection or the entire collection.
+* Allow the owner of an item to delegate the ability to transfer the item to some named third-party.

 ## Interface

@@ -27,10 +27,10 @@ filtered by any proxy.
 ### Dispatchable Functions

 #### For batch dispatch
-* `batch` - Dispatch multiple calls from the sender's origin.
+- `batch` - Dispatch multiple calls from the sender's origin.

 #### For pseudonymal dispatch
-* `as_derivative` - Dispatch a call from a derivative signed origin.
+- `as_derivative` - Dispatch a call from a derivative signed origin.

 [`Call`]: ./enum.Call.html
 [`Config`]: ./trait.Config.html