w3f · CrackTheCode016 · Sep 8, 2023 · Jun 2, 2023 · Jun 8, 2023 · Jun 10, 2023
diff --git a/docs/build/build-integrate-assets.md b/docs/build/build-integrate-assets.md
@@ -106,8 +106,8 @@ Here are the available public instances:
   and
 - [Sidecar connected to Kusama Asset Hub](https://kusama-asset-hub-public-sidecar.parity-chains.parity.io)
 
-The purpose of these instances is to allow anyone to check and get a quick
-overview of the info that the asset-related endpoints provide.
+The purpose of these instances is to allow anyone to check and get a quick overview of the info that
+the asset-related endpoints provide.
 
 :::caution
 

diff --git a/docs/build/build-tools-index.md b/docs/build/build-tools-index.md
@@ -55,7 +55,8 @@ Please see the [Wallets](./wallets) page.
 - [Panic](https://github.com/SimplyVC/panic) - A node monitoring and alert server for validators.
 - [OpenWeb3/Guardian](https://github.com/open-web3-stack/guardian) - A CLI tool and JS library to
   monitor on chain states and events.
-- [Ocelloids SDK](https://github.com/sodazone/ocelloids) - Typescript SDK for multi-chain monitoring that supports domain-specific logic for different pallets.
+- [Ocelloids SDK](https://github.com/sodazone/ocelloids) - Typescript SDK for multi-chain monitoring
+  that supports domain-specific logic for different pallets.
 
 ## Clients
 

diff --git a/docs/general/contributing.md b/docs/general/contributing.md
@@ -75,8 +75,8 @@ There are a few basic ground-rules for contributors:
 8. Care should be taken to remain as objective and informative as possible. There should be no
    editorializing, and external bias should not be present.
 9. We use a plugin called Prettier to standardize the style across documents. You can run this on
-   your local copy with `npx lint-staged`, but for simplicity we also have a bot which
-   runs this for us in your PRs.
+   your local copy with `npx lint-staged`, but for simplicity we also have a bot which runs this for
+   us in your PRs.
 
 ## Heritage
 

diff --git a/docs/general/faq.md b/docs/general/faq.md
@@ -172,7 +172,7 @@ use TPS as a measure for the network performance if all the transactions carry t
 [Performance benchmark tests](https://twitter.com/gavofyork/status/1270025498580656134) show that
 Substrate-based blockchains can achieve over 1000 TPS for balance transfer transactions. Assuming
 Polkadot is running over 100 parachains; the projected TPS is well over 100,000. With
-[asynchronous backing upgrade](../learn/learn-async-backing), the TPS is expected to increase
+[asynchronous backing upgrade](../learn/learn-async-backing.md), the TPS is expected to increase
 tenfold to 1,000,000.
 
 It is essential to realize that TPS is inherently a subjective measurement with numerous factors

diff --git a/docs/learn/learn-async-backing.md b/docs/learn/learn-async-backing.md
@@ -0,0 +1,116 @@
+---
+id: learn-async
+title: Asynchronous Backing
+sidebar_label: Asynchronous Backing
+description: A brief overview of asynchronous backing, and how it affects Polkadot's scalability.
+keywords: [parachains, slots, backing, parablock]
+slug: ../learn-async
+---
+
+Asynchronous backing is a feature that introduces
+[pipelining](https://www.techtarget.com/whatis/definition/pipelining) to the parachain block
+generation and validation process. It is analogous to the logical pipelining of processor
+instruction in "traditional" architectures, where some instructions may be executed before others
+are complete. Instructions may also be executed in parallel, enabling multiple parts of the
+processor to be working on potentially different instructions at the same time.
+
+Bundles of state transitions represented as blocks may be processed similarly. In the context of
+Polkadot, it aims to overall increase the throughput of the entire network.
+
+:::info
+
+In order to realize which exact processes this upgrade improves, it is recommended to be familiar
+with the stages of parablock validation, which you may [read here](./learn-parachains-protocol.md).
+
+:::
+
+Asynchronous backing enables logical pipelining over the parablock 
+[**generation**](https://wiki.polkadot.network/docs/learn-parachains-protocol#collators),
+[**backing**](https://wiki.polkadot.network/docs/learn-parachains-protocol#parachain-phase), and
+[**inclusion**](https://wiki.polkadot.network/docs/learn-parachains-protocol#inclusion-pipeline)
+processes. A parablock may be at different stages, but multiple blocks should be able to process
+simultaneously (in parallel) if needed. Most notably, parablock N + 1 can be generated and backed during the same time in which its predecessor, parablock N, is undergoing inclusion on the relay chain.
+processes can occur while their ancestors are included on the relay chain.
+
+This pipeline will allow [collators](./learn-parachains-protocol.md#collators) to include an
+estimated ~3-5x more transactions/data while speeding up parachain block times from 12 to 6 seconds.
+In short, Polkadot with asynchronous backing will deliver an estimated ~6-10x more blockspace to its parachains.
+to Polkadot parachains.
+
+Asynchronous Backing has three overarching goals:
+
+1. Decrease parachain block (parablock) validation time to **6 seconds** from **12 seconds**
+2. Increase the amount of usable blockspace as per above, meaning more state changes are allowed per
+   relay chain block.
+3. Allow for parablocks to be re-proposed to the network if they are not included successfully on the
+   first attempt.
+
+Asynchronous backing provides a form of **contextual execution**, which allows for more time for
+parachain collators to fit more transactions and ready block candidates for backing and inclusion.
+**Contextual execution** refers to how a parablock can begin being built earlier using the context
+provided by an _unincluded segment_ of recent block ancestors.
+
+**Unincluded segments** are chains of candidate blocks that are not yet included in the relay chain.
+Parablocks can be added to this unincluded segment and no longer have to wait for the latest
+included parent block of the relay chain. The core functionality that asynchronous backing brings is
+the ability to build on these unincluded segments of block ancestors rather than ancestors included in the relay
+chain state.
+
+Currently, parablocks rely on the most recent relay chain block (often referred to as the **parent**
+block, as the parablock anchors itself to it). Each parablock must be generated and go through the
+entire backing process in a single relay block. It then proceeds through availability + inclusion
+process during the next block.
+
+:::info
+
+It is important to note two following clarifications:
+
+1. The parablock is not placed on the relay chain in its entirety, but rather the **paraheader**
+2. The relay chain does not validate the entire state of a parachain, but only the state transitions
+   within that block.
+
+:::
+
+For more information on the validity and availability process, be sure to visit the
+[parachain protocol](../learn/learn-parachains-protocol.md) page.
+
+## Synchronous Backing on Polkadot
+
+With synchronous backing, there was only about a single relay chain block, or 6-second window, to
+complete the parablock candidate generation and backing process. This was tightly coupled to the
+relay chain's progress, where blocks had to be created within this window.
+
+The main limitation of synchronous backing is that parablock validation is tightly coupled to the
+relay chain's progression on a 1-1 basis, meaning every parablock must be generated and backed
+within six seconds. This time limit reduces the amount of data a collator has time to add to each
+block.
+
+A particular parablock, `P1`, would **only** be valid for backing at relay chain parent `R1 + 1` and
+subsequently, be included at `R1 + 2` should it be backed successfully. Essentially, a parablock is
+rushing to be backed and included within this two-block window due to the inherent synchrony between
+the parachain and relay chain.
+
+## Asynchronous Backing on Polkadot
+
+With asynchronous backing, the window of time is customizable and will most likely sit around the
+6-18 second range. It also introduces a parameter to aid in defining the maximum amount of ancestor
+blocks, which allows for a parablock to be backed later in the future, enabling more computational
+and storage time per block. The context for the latest parablock is derived from the unincluded
+segment of block ancestors upon which the newest parablock is built.
+
+These blocks can be prepared in anticipation of being included later rather than keeping in sync
+with the relay chain's progress 1-1. The block can be in a different stage from another block being
+built, as long as it abides by the parameters set forth by the asynchronous backing configuration.
+
+This combination of lower latency, higher storage per block, and a logical pipeline spanning
+Polkadot's networking, runtime, and collation aspects will allow for higher, more robust throughput.
+
+## Learn More
+
+This topic is evolving and being implemented at the moment, keep up to date using the following
+resources:
+
+- [Polkadot Roadmap Roundup](https://polkadot.network/blog/polkadot-roadmap-roundup) - Article by
+  Rob Habermeier, Polkadot founder, details the plans for Polkadot for 2023.
+- [Asynchronous Backing Spec & Tracking Issue](https://github.com/paritytech/polkadot/issues/3779) -
+  The implementation tracking issue for asynchronous backing
diff --git a/docs/learn/learn-parachains.md b/docs/learn/learn-parachains.md
@@ -182,7 +182,8 @@ maintain the stronger property of single block composability.
 
 ## Parachain Slot Acquisition
 
-There are several ways to allocate parachain slots on {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}:
+There are several ways to allocate parachain slots on
+{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}:
 
 - Governance granted parachains, or "system parachains"
 - Auction granted parachains

diff --git a/docs/maintain/maintain-guides-polkadot-opengov.md b/docs/maintain/maintain-guides-polkadot-opengov.md
@@ -229,19 +229,24 @@ from the treasury at once.
 
 ### Submitting a Preimage
 
-The act of creating a proposal is split from submitting the preimage for the proposal since the storage cost of submitting a large preimage could be expensive. Allowing the preimage submission to come as a separate transaction means that another account could submit the preimage for you and pay the fee. The example below demonstrates the creation of a preimage to propose and approve a spend of treasury funds.
+The act of creating a proposal is split from submitting the preimage for the proposal since the
+storage cost of submitting a large preimage could be expensive. Allowing the preimage submission to
+come as a separate transaction means that another account could submit the preimage for you and pay
+the fee. The example below demonstrates the creation of a preimage to propose and approve a spend of
+treasury funds.
 
 ![submit preimage](../assets/governance/opengov-submit-preimage.png)
 
 Follow the steps below to submit a preimage as shown in the screenshot above.
 
 1. Navigate to Governance -> Referenda.
 2. Click on the "Add preimage" button.
-3. From the *propose* drop-down field, select `treasury`.
-4. From the unlabeled drop-down field to the right of the *propose* drop-down field, select `spend(amount, beneficiary)`.
+3. From the _propose_ drop-down field, select `treasury`.
+4. From the unlabeled drop-down field to the right of the _propose_ drop-down field, select
+   `spend(amount, beneficiary)`.
 5. In the `amount: Compact<u128> (BalanceOf)` text field, enter the spend amount.
-6. The `beneficiary: MultiAddress (AccountIdLookupOf)` drop-down field will have `Id` selected by default. Select the beneficiary from the `Id: AccountId` drop-down field.
-
+6. The `beneficiary: MultiAddress (AccountIdLookupOf)` drop-down field will have `Id` selected by
+   default. Select the beneficiary from the `Id: AccountId` drop-down field.
 
 :::info
 
@@ -252,10 +257,7 @@ Copy the `preimage hash` value before clicking the "Submit preimage" button.
 7. Click the "Submit preimage" button.
 
 After the preimage is submitted successfully on-chain, Polkadot-JS UI lists it under the tab of
-Governance -> Preimages.  
-
-
-
+Governance -> Preimages.
 
 ### Submitting a Proposal
 

diff --git a/polkadot-wiki/sidebars.js b/polkadot-wiki/sidebars.js
@@ -403,6 +403,7 @@ module.exports = {
           items: [
             'learn/learn-spree',
             "learn/learn-parathreads",
+            "learn/learn-async",
           ],
         },
         {