Wiki Reorg: standardize relay chain mentions (#6285)

* standardize relay chain

remove relay-chain and replace with relay chain

* Remove "relay-chain", "Relay-chain", "Relay chain", "Relay Chain"

docs/build/build-integrate-assets.md

@@ -224,21 +224,21 @@ then tracing back the origin of these deposits. However, the process of tracking
 (hence the events to look for) may vary based on the direction of the XCM message. Here are some
 examples to showcase the slight differences:
 
-1. For an XCM transfer from a Parachain to a Relay chain
+1. For an XCM transfer from a Parachain to a relay chain
    _([example](https://polkadot.subscan.io/xcm_message/polkadot-3effaf637dd2a3ac5a644ccc693cbf58a6957d84))_:
 
    - The [event](https://hydradx.subscan.io/extrinsic/5136464-2?event=5136464-7) to look for in the
      Parachain side is called `parachainsystem (UpwardMessageSent)`, and the parameter
      `message_hash` in this event identifies the XCM transfer.
    - The [event](https://polkadot.subscan.io/block/20810935?tab=event&&event=20810935-4) to track in
-     the Relay chain side is called `messagequeue (Processed)`, and the parameter `id` of the event
+     the relay chain side is called `messagequeue (Processed)`, and the parameter `id` of the event
      should be the same as the `message_hash` found in the Parachain event.
 
-2. For an XCM transfer from a Relay chain to a Parachain
+2. For an XCM transfer from a relay chain to a parachain
    _([example](https://polkadot.subscan.io/xcm_message/polkadot-b2f455ed6ca1b4fdea746dfe8d150c10ec74440e))_:
 
    - The [event](https://polkadot.subscan.io/extrinsic/20810793-2?event=20810793-53) to look for in
-     the Relay chain side is called `xcmPallet (sent)`, and the parameter `message_id` in this event
+     the relay chain side is called `xcmPallet (sent)`, and the parameter `message_id` in this event
      identifies the XCM transfer.
    - The [event](https://moonbeam.subscan.io/extrinsic/6174523-0?event=6174523-5) to look for in the
      Parachain side is called `dmpqueue (ExecutedDownward)`, and the parameter that identifies the
@@ -259,7 +259,7 @@ examples to showcase the slight differences:
 In case that an XCM transfer fails to complete successfully, then we will notice some different
 parameters in the events emitted or different events. Below are some examples:
 
-1. From a Relay chain to a System Parachain
+1. From a relay chain to a System Parachain
    _([example](https://polkadot.subscan.io/xcm_message/polkadot-c8d7186edb43a592d65b3b5a87c4ecaac38c5aa2))_:
 
    - We will see the

docs/general/dune-analytics/polkadot-ecosystem-overview.md

@@ -28,7 +28,7 @@ For example, following are some of topics you might be interested in:
 
 - For **stablecoins**, visit
   [Asset Hub Dashboards](dune-analytics/parachain-dashboards/assethub-dashboards)
-- For Polkadot relay-chain **treasury**, visit
+- For Polkadot relay chain **treasury**, visit
   [Polkadot Dashboards Governance](dune-analytics/polkadot-dashboards/polkadot-dashboards-governance)
 - For Polkadot **staking**, visit
   [Polkadot Dashboards Staking](dune-analytics/polkadot-dashboards/polkadot-dashboards-staking)

docs/general/polkadot-direction.md

@@ -99,7 +99,7 @@ of those options. The topic is currently under discussion. For more information,
 
 Polkadot 1.0 was a chain-centric paradigm consisting of isolated chains able to exchange messages.
 This was not fundamentally different from having completely different chains connected to bridges,
-with the only difference of having the relay-chain securing the network, providing message-passing
+with the only difference of having the relay chain securing the network, providing message-passing
 capability, and doing some extra tasks such as [staking](../learn/learn-staking.md),
 [accounts](./learn-accounts-index), [balances](../learn/learn-transactions.md#balance-transfers),
 and [governance](../learn/learn-polkadot-opengov.md). Having a chain-centric system will ultimately
@@ -109,9 +109,9 @@ The true innovation of Polkadot is about leveraging the unique value proposition
 different chains and using those chains’ collaborative potential to build inter-chain applications
 to solve real-world problems. Those applications will thus need to span across chains.
 
-**Increasingly fewer tasks will be handled by the relay-chain** that will focus efforts only on
+**Increasingly fewer tasks will be handled by the relay chain** that will focus efforts only on
 primary tasks: securing the network and providing secure message-passing capability.
-[System parachains](../learn/learn-system-chains.md) will be used to take over secondary relay-chain
+[System parachains](../learn/learn-system-chains.md) will be used to take over secondary relay chain
 tasks such as staking, governance, etc.
 
 ### XCM and Accords

docs/general/polkadot-v1.md

@@ -146,7 +146,7 @@ Polkadot has been designed around those core blockspace principles. However, its
 further improved such that the tasks which are currently managed on the relay chain, such as
 balances transfers, staking, and governance, can be delegated to
 [system parachains](../learn/learn-system-chains.md) to increase flexibility and to focus the use of
-the relay-chain to provide shared security and interoperability. Blockspace is only accessible
+the relay chain to provide shared security and interoperability. Blockspace is only accessible
 through auctions, but an auction winner has access to a "freighter of blocks" regardless it is
 needed or not. This creates high entry barriers and it can lead to waste of energy and resources.
 

docs/learn/learn-comparisons-avalanche.md

@@ -17,9 +17,9 @@ To keep the content on this page factually correct and up-to-date,
 :::
 
 Polkadot and Avalanche both have an architecture that allows for application-specific blockchains to
-be designed and connected to a primary network. In Polkadot, the primary network is the Relay-chain
+be designed and connected to a primary network. In Polkadot, the primary network is the relay chain
 and Avalanche does this with 3 main chains - the P-chain, X-chain, and C-chain. Similar to how
-Polkadot has its Parachains that connect to the Relay-chain, Avalanche has what’s called
+Polkadot has its Parachains that connect to the relay chain, Avalanche has what’s called
 [subnets](https://docs.avax.network/subnets). Similar to Polkadot, Avalanche also uses a PoS
 mechanism for achieving consensus. The validators stake their AVAX tokens in order to participate in
 the PoS system and secure the network.
@@ -185,7 +185,7 @@ environment in which protocol engineers can have the freedom to create their own
 include them in the Avalanche ecosystem via subnets. The trade-offs are that the autonomy of design
 is limited and blockchains have to buy into the design decisions of Avalanche's main chains. Unlike
 parachains on Polkadot, Subnets are not able to share the security of the main chains. In addition
-to utilizing block finality and security of the Relay-chain, parachains on Polkadot use
+to utilizing block finality and security of the relay chain, parachains on Polkadot use
 [XCM](learn-xcm) to pass native trustless messages, instead of having to rely on multiple bridging
 solutions. However, Subnets are easy to launch when compared to parachains, given that they only
 need a recommended minimum of 5 validators, which make the costs of launch predictable. Avalanche

docs/learn/learn-comparisons.md

@@ -59,5 +59,5 @@ and has much stronger economic security.
 
 Scalability based on bridges relies on each bridged chain finding its own set of validators,
 therefore duplicate resources are required. Scalability on Polkadot is based on the security of the
-Relay Chain, and as the number of validators in the active set on Polkadot are increased, more
+relay chain, and as the number of validators in the active set on Polkadot are increased, more
 parachains can be supported.

docs/learn/learn-guides-assets-create.md

@@ -18,7 +18,7 @@ The Asset Hub is a generic assets system parachain which provides functionality
 transferring assets — both Fungible and Non-Fungible Tokens (NFTs). The native token of the Asset
 hub is the same as the relay chain's native asset (DOT or KSM). The Existential Deposit (ED),
 transaction fees, and the deposits for proxy/multisig operations are about
-[1/10th of the values on the Relay chains](../general/chain-state-values.md#existential-deposit-2).
+[1/10th of the values on the relay chains](../general/chain-state-values.md#existential-deposit-2).
 Apart from the native token, the assets held on the Asset Hub can be broadly categorized as
 
 - Assets backed by an on-chain protocol’s utility

docs/learn/learn-parachains-protocol.md

@@ -94,7 +94,7 @@ the [Inclusion Pipeline](#inclusion-pipeline) and two within the
 
 - **Inclusion Pipeline**
   1.  [Parachain phase](#parachain-phase)
-  2.  [Relay Chain submission phase](#relay-chain-submission-phase)
+  2.  [Relay chain submission phase](#relay-chain-submission-phase)
   3.  [Availability and unavailability phase](#availability-and-unavailability-phase)
 - **Approval Process**
   1.  [Assignments and secondary (validity) checks](#assignments--secondary-checks)
@@ -300,11 +300,11 @@ that parablock.
 :::info Parablocks vs. relay chain Blocks
 
 It is important to understand that a relay chain block does not contain parablocks, but
-para-headers. Parachain blocks are within the parachain. Thus, it makes more sense to think of
-relay-chain blocks as having been approved instead of parablocks that have been approved. A
-relay-chain block containing information about approved parablocks can be considered approved as
-long as its parent relay-chain block is also approved. Thus, the validity of a relay-chain block
-depends on the validity of its ancestry.
+para-headers. Parachain blocks are within the parachain. Thus, it makes more sense to think of relay
+chain blocks as having been approved instead of parablocks that have been approved. A relay chain
+block containing information about approved parablocks can be considered approved as long as its
+parent relay chain block is also approved. Thus, the validity of a relay chain block depends on the
+validity of its ancestry.
 
 :::
 

docs/learn/learn-parachains.md

@@ -36,7 +36,7 @@ Parachains are maintained by a network maintainer known as a [collator](learn-co
 of the collator node is to maintain a full node of the parachain, retain all necessary information
 about the parachain, and produce new block candidates to pass to the relay chain validators for
 verification and inclusion in the shared state. The incentivization of a collator node is an
-implementation detail of the parachain. They are not required to be staked on the Relay Chain or own
+implementation detail of the parachain. They are not required to be staked on the relay chain or own
 the native token unless stipulated by the parachain implementation.
 
 ### State Transitions
@@ -191,11 +191,12 @@ DOT (or KSM on Kusama).
 
 ### Coretime Expiration
 
-The DOT (or KSM on Kusama) used to purchase coretime are burned. Before the coretime expires, parachains
-can renew it at a fixed cost through a bulk coretime purchase. If the parachain does not purchase bulk coretime, it has an option to purchase coretime on-demand (at a variable price per block,
-depending on the demand and other market conditions) when they need to access the relay chain.
-Parachains without coretime to extend time on a relay chain core will be deprecated to the status of
-a parathread (i.e., a chain with a registered `ParaID` but without access to a core).
+The DOT (or KSM on Kusama) used to purchase coretime are burned. Before the coretime expires,
+parachains can renew it at a fixed cost through a bulk coretime purchase. If the parachain does not
+purchase bulk coretime, it has an option to purchase coretime on-demand (at a variable price per
+block, depending on the demand and other market conditions) when they need to access the relay
+chain. Parachains without coretime to extend time on a relay chain core will be deprecated to the
+status of a parathread (i.e., a chain with a registered `ParaID` but without access to a core).
 
 ## System Parachains
 

docs/learn/learn-system-chains.md

@@ -10,7 +10,7 @@ slug: ../learn-system-chains
 import RPC from "./../../components/RPC-Connection"; import Tabs from "@theme/Tabs"; import TabItem
 from "@theme/TabItem";
 
-The primary functionality of the Relay chain is to secure the parachains and facilitate secure
+The primary functionality of the relay chain is to secure the parachains and facilitate secure
 communication between them. All other functionalities like asset transfers, governance, identities
 and bridging (a potentially resource intensive task) can benefit from operating separately on system
 chains. System chains are responsible for delegating functionality away from the relay chain for
@@ -20,8 +20,8 @@ provides.
 ## Overview
 
 System parachains are those that contain core Polkadot protocol features, but in parachains rather
-than the relay chain. Rather than purchasing coretime on a marketplace, execution cores for system chains are allocated
-through the network [governance](./learn-guides-polkadot-opengov.md).
+than the relay chain. Rather than purchasing coretime on a marketplace, execution cores for system
+chains are allocated through the network [governance](./learn-guides-polkadot-opengov.md).
 
 By hosting core protocol logic in parachains instead of the relay chain, Polkadot uses its own
 scaling technology -- namely, parallel execution -- to host _itself_. System parachains remove

docs/learn/learn-xcm-transport.md

@@ -38,9 +38,9 @@ XCM is related to XCMP in the same way that REST is related to RESTful.
 _Cross-Consensus Message Passing_ secure message passing between parachains. There are two variants:
 _Direct_ and _Relayed_.
 
-- With _Direct_, message data goes direct between parachains and is O(1) on the side of the
-  Relay-chain and is very scalable.
-- With _Relayed_, message data is passed via the Relay-chain, and piggy-backs over VMP. It is much
+- With _Direct_, message data goes direct between parachains and is O(1) on the side of the relay
+  chain and is very scalable.
+- With _Relayed_, message data is passed via the relay chain, and piggy-backs over VMP. It is much
   less scalable, and on-demand parachains in particular may not receive messages due to excessive
   queue growth.
 
@@ -61,16 +61,16 @@ For detailed information about VMP see dedicated section in
 
 ### VMP (Vertical Message Passing)
 
-_Vertical Message Passing_ message passing between the Relay-chain itself and a parachain. Message
-data in both cases exists on the Relay-chain and are interpreted by the relay chain according to
+_Vertical Message Passing_ message passing between the relay chain itself and a parachain. Message
+data in both cases exists on the relay chain and are interpreted by the relay chain according to
 [XCM](./learn-xcm.md/#cross-consensus-message-format-xcm) standards. This includes:
 
 - #### UMP (Upward Message Passing)
 
-  _Upward Message Passing_ message passing from a parachain to the Relay-chain.
+  _Upward Message Passing_ message passing from a parachain to the relay chain.
 
 - #### DMP (Downward Message Passing)
-  _Downward Message Passing_ message passing from the Relay-chain to a parachain.
+  _Downward Message Passing_ message passing from the relay chain to a parachain.
 
 :::info
 

docs/learn/xcm/journey/origins.md

@@ -88,5 +88,5 @@ The AliasOrigin instruction is similar to the UniversalOrigin instruction, but i
 for account IDs. When executed, it switches out the current origin for the given MultiLocation. THe
 AliasOrigin instruction would allow to remove certain prefix patterns such as Parent/Parachain(X)/
 for certain values of X (thereby allowing sibling chains to use the same account IDs) or
-Parachain(X)/ (allowing a Relay-chain to use the account IDs native to its child parachains) or just
-Parent/ (allowing parachains to use AccountIds of the Relay-chain).
+Parachain(X)/ (allowing a relay chain to use the account IDs native to its child parachains) or just
+Parent/ (allowing parachains to use AccountIds of the relay chain).

docs/maintain/maintain-guides-async-backing.md

@@ -80,7 +80,7 @@ collator side of Async Backing and establish a basic understanding of the change
 
 ## Prerequisite
 
-The relay chain needs to have async backing enabled so double-check that the relay-chain
+The relay chain needs to have async backing enabled so double-check that the relay chain
 configuration contains the following three parameters (especially when testing locally e.g. with
 zombienet):