final edits

docs/general/chain-state-values.md

@@ -192,6 +192,13 @@ The **signed reward base** on Polkadot is <RPC network="polkadot" path="consts.e
 
 The maximum number of submission for a staking miner on Polkadot is <RPC network="polkadot" path="consts.electionProviderMultiPhase.signedMaxSubmissions" defaultValue={16}/>.
 
+#### Staking Reward Retention
+
+Polkadot staking rewards are kept available for 84 eras. The following calculation can be used to
+approximate this length in days:
+
+`84 eras` × `24 hours in a single era` ÷ `24 hours in a day` = `84 days`
+
 #### Total Issuance
 
 Polkadot's total issuance is  <RPC network="polkadot" path="query.balances.totalIssuance" defaultValue="14883815224560918110" filter= "humanReadable"/> in the era <RPC network="polkadot" path="query.staking.currentEra" defaultValue="1553"/>.
@@ -378,6 +385,13 @@ The **signed reward base** on Kusama is <RPC network="kusama" path="consts.elect
 
 The maximum number of submission for a staking miner on Kusama is <RPC network="kusama" path="consts.electionProviderMultiPhase.signedMaxSubmissions" defaultValue={16}/>.
 
+#### Staking Reward Retention
+
+Kusama staking rewards are kept available for 84 eras. The following calculation can be used to
+approximate this length in days:
+
+`84 eras` × `6 hours in a single era` ÷ `24 hours in a day` = `21 days`
+
 #### Total Issuance
 
 Kusama's total issuance is  <RPC network="kusama" path="query.balances.totalIssuance" defaultValue="15410382600026732448" filter= "humanReadable"/> in the era <RPC network="kusama" path="query.staking.currentEra" defaultValue="7061"/>.

docs/learn/archive/learn-governance.md

@@ -158,12 +158,11 @@ unless they are the only ones in the pipeline.
 
 In (2), the proposal is selected for a referendum. Proposals initiated by the public will become a
 [public referendum](#public-referenda), while those initiated by the council will become
-[council referenda](#council-referenda). The voting period lasts
-{{ polkadot: 28 days :polkadot }}{{ kusama: 7 days :kusama }}, after which, if the proposal is
-approved, it will go through an enactment period. Rejected proposals will need to start from (1).
-Note that Governance V1 uses an [alternating voting timeline](#alternating-voting-timetable) where
-voters can vote either for a public proposal or a council motion every
-{{ polkadot: 28 days :polkadot }}{{ kusama: 7 days :kusama }}.
+[council referenda](#council-referenda). The voting period lasts 28 days (7 days on Kusama), after
+which, if the proposal is approved, it will go through an enactment period. Rejected proposals will
+need to start from (1). Note that Governance V1 uses an
+[alternating voting timeline](#alternating-voting-timetable) where voters can vote either for a
+public proposal or a council motion every 28 days (7 days on Kusama).
 
 In (3), the proposal is approved and moves through the [enactment period](#enactment) that can be of
 different lengths depending on who initiated the proposal in the first place, with emergency
@@ -177,8 +176,7 @@ they will require a heavy supermajority of _aye_ votes to pass at low turnouts b
 increases towards 100%, it will require a simple majority of _aye_ votes to pass (i.e. 51% wins).
 
 Note that the bonded tokens will be released once the proposal is tabled (that is, brought to a
-vote), and a maximum of {{ polkadot: 100 :polkadot }} {{ kusama: 100 :kusama }} public proposals can
-be in the proposal queue.
+vote), and a maximum of 100 public proposals can be in the proposal queue.
 
 :::info turnout
 
@@ -214,18 +212,17 @@ in the same period, excluding emergency referenda. An emergency referendum occur
 time as a regular referendum (either public- or council-proposed) is the only time multiple
 referenda can be voted on.
 
-Every {{ polkadot: 28 :polkadot }} {{ kusama: 7 :kusama }} days, a new referendum will come up for a
-vote, assuming there is at least one proposal in one of the queues. There is a queue for
-Council-approved proposals and a queue for publicly-submitted proposals. The referendum to be voted
-upon alternates between the top proposal in the two queues, where the proposals' rank is based on
+Every 28 days (7 days on Kusama), a new referendum will come up for a vote, assuming there is at
+least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue
+for publicly-submitted proposals. The referendum to be voted upon alternates between the top
+proposal in the two queues, where the proposals' rank is based on
 [endorsement](#endorsing-proposals) (i.e. bonded tokens).
 
 ### Adaptive Quorum Biasing
 
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} introduces the concept of **Adaptive
-Quorum Biasing**, which is used to alter the effective super-majority required to make it easier or
-more difficult for a proposal to pass depending on voting power (turnout) and origin (Council or
-public).
+Polkadot introduces the concept of **Adaptive Quorum Biasing**, which is used to alter the effective
+super-majority required to make it easier or more difficult for a proposal to pass depending on
+voting power (turnout) and origin (Council or public).
 
 Adaptive Quorum Biasing creates three tallying mechanisms: majority carry, super-majority approve,
 and super-majority against. They all equate to a simple majority-carry system at 100% turnout. Their
@@ -276,28 +273,24 @@ To know more about where these above formulas come from, please read the
 
 #### Example of Adaptive Quorum Biasing
 
-Let's assume we only have {{ polkadot: 1,500 DOT :polkadot }}{{ kusama: 1_50 :kusama }} tokens in
-total and that this is a public proposal.
+Let's assume we only have 1,500 DOT tokens in total and that this is a public proposal.
 
-- John: {{ polkadot: 500 DOT :polkadot }}{{ kusama: 50 KSM :kusama }}
-- Peter: {{ polkadot: 100 DOT :polkadot }}{{ kusama: 10 KSM :kusama }}
-- Lilly: {{ polkadot: 150 DOT :polkadot }}{{ kusama: 15 KSM :kusama }}
-- JJ: {{ polkadot: 150 DOT :polkadot }}{{ kusama: 15 KSM :kusama }}
-- Ken: {{ polkadot: 600 DOT :polkadot }}{{ kusama: 60 KSM :kusama }}
+- John: 500 DOT
+- Peter: 100 DOT
+- Lilly: 150 DOT
+- JJ: 150 DOT
+- Ken: 600 DOT
 
-John: Votes `Yes` for a 4 week lock period =>
-{{ polkadot: 500 x 1 = 500 Votes :polkadot }}{{ kusama: 50 x 1 = 50 Votes :kusama }}
+John: Votes `Yes` for a 4 week lock period => 500 x 1 = 500 Votes
 
-Peter: Votes `Yes` for a 4 week lock period =>
-{{ polkadot: 100 x 1 = 100 Votes :polkadot }}{{ kusama: 10 x 1 = 10 Votes :kusama }}
+Peter: Votes `Yes` for a 4 week lock period => 100 x 1 = 100 Votes
 
-JJ: Votes `No` for a 16 week lock period =>
-{{ polkadot: 150 x 3 = 450 Votes :polkadot }}{{ kusama: 150 x 3 = 450 Votes :kusama }}
+JJ: Votes `No` for a 16 week lock period => 150 x 3 = 450 Votes
 
-- approve = {{ polkadot: 600 :polkadot }}{{ kusama: 60 :kusama }}
-- against = {{ polkadot: 450 :polkadot }}{{ kusama: 45 :kusama }}
-- turnout = {{ polkadot: 750 :polkadot }}{{ kusama: 75 :kusama }}
-- electorate = {{ polkadot: 1500 :polkadot }}{{ kusama: 150 :kusama }}
+- approve = 600 Votes
+- against = 450 Votes
+- turnout = 750 Votes
+- electorate = 1500 Votes
 
 ![\Large \frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}}](https://latex.codecogs.com/svg.latex?\large&space;\frac{450}{\sqrt{750}}&space;<&space;\frac{600}{\sqrt{1500}})
 

docs/learn/learn-polkadot-opengov.md

@@ -305,21 +305,14 @@ the tokens are locked.
 
 See below an example that shows how voluntary locking works.
 
-Peter: Votes `No` with
-{{ polkadot: 10 DOT for a 32-week :polkadot }}{{ kusama: 1 KSM for a 32-week :kusama }} lock period
-=> {{ polkadot: 10 x 6 = 60 Votes :polkadot }}{{ kusama: 1 x 6 = 6 Votes :kusama }}
+Peter: Votes `No` with 10 DOT for a 32-week lock period => 10 x 6 = 60 Votes
 
-Logan: Votes `Yes` with
-{{ polkadot: 20 DOT for one week :polkadot }}{{ kusama: 2 KSM for one week :kusama }} lock period =>
-{{ polkadot: 20 x 1 = 20 Votes :polkadot }}{{ kusama: 2 x 1 = 2 Votes :kusama }}
+Logan: Votes `Yes` with 20 DOT for one week lock period => 20 x 1 = 20 Votes
 
-Kevin: Votes `Yes` with
-{{ polkadot: 15 DOT for a 2-week :polkadot }}{{ kusama: 1.5 KSM for a 2-week :kusama }} lock period
-=> {{ polkadot: 15 x 2 = 30 Votes :polkadot }}{{ kusama: 1.5 x 2 = 3 Votes :kusama }}
+Kevin: Votes `Yes` with 15 DOT for a 2-week lock period => 15 x 2 = 30 Votes
 
-Even though both Logan and Kevin vote with more
-{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} than Peter, the lock period for both of them
-is less than Peter’s, leading to their voting power counting as less.
+Even though both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is
+less than Peter’s, leading to their voting power counting as less.
 
 :::info Staked tokens can be used in governance
 

docs/learn/learn-staking.md

@@ -378,11 +378,8 @@ timeline. See the page on [Validator Payout Guide](../maintain/maintain-guides-v
 The distribution of staking rewards to the nominators is not automatic and needs to be triggered by
 someone. Typically the validators take care of this, but anyone can permissionlessly trigger rewards
 payout for all the nominators whose stake has backed a specific validator in the active set of that
-era. Staking rewards are kept available for 84 eras. The following calculation can be used to
-approximate this length in days:
-
-{{ polkadot: `84 eras` × `24 hours in a single era` ÷ `24 hours in a day` = `84 days` :polkadot }}
-{{ kusama: `84 eras` × `6 hours in a single era` ÷ `24 hours in a day` = `21 days` :kusama }}
+era. Staking rewards are kept available for
+[a limited amount of time](../general/chain-state-values.md#staking-reward-retention).
 
 For more information on why this is so, see the page on [simple payouts](learn-staking-advanced.md).
 

docs/learn/learn-transactions.md

@@ -12,11 +12,10 @@ from "@theme/TabItem"; import DocCardList from '@theme/DocCardList';
 
 ## Pallets and Extrinsics
 
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} is built using
-[Substrate](https://substrate.io/), a modular framework to efficiently build blockchains.
-Substrate's 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. You
-can explore Substrate's FRAME pallets on
+Polkadot is built using [Substrate](https://substrate.io/), a modular framework to efficiently build
+blockchains. Substrate's 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. You can explore Substrate's FRAME pallets on
 [this dedicated page](https://docs.substrate.io/reference/frame-pallets/).
 
 Within each functional **pallet** on the blockchain, one can **call** its functions and execute them
@@ -42,24 +41,21 @@ really are. Extrinsics can be one of 3 distinct types:
 - **Inherents:** are a special type of unsigned transaction made by block authors which carry
   information required to build a block such as timestamps, storage proofs and uncle blocks.
 
-Signed transactions is the way that most users will interact with
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}. Signed transactions come from an
-account that has funds, and therefore {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}
-can charge a transaction fee as a way to prevent spam.
+Signed transactions is the way that most users will interact with Polkadot. Signed transactions come
+from an account that has funds, and therefore Polkadot can charge a transaction fee as a way to
+prevent spam.
 
 Unsigned transactions are for special cases where a user needs to submit an extrinsic from a key
 pair that does not control funds. For example, validator's [session keys](learn-cryptography.md)
-never control funds. Unsigned transactions are only used in special cases because, since
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} cannot charge a fee for them, each
-one needs its own, custom validation logic.
+never control funds. Unsigned transactions are only used in special cases because, since Polkadot
+cannot charge a fee for them, each one needs its own, custom validation logic.
 
 Inherents are pieces of information that are not signed or included in the transaction queue. As
 such, only the block author can add inherents to a block. Inherents are assumed to be "true" simply
 because a sufficiently large number of validators have agreed on them being reasonable. For example,
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} blocks include a timestamp inherent.
-There is no way to prove that a timestamp is true the way one proves the desire to send funds with a
-signature. Rather, validators accept or reject the block based on how reasonable they find the
-timestamp. In {{ polkadot: Polkadot, :polkadot }}{{ kusama: Kusama, :kusama }} it must be within
+the relay chain blocks include a timestamp inherent. There is no way to prove that a timestamp is
+true the way one proves the desire to send funds with a signature. Rather, validators accept or
+reject the block based on how reasonable they find the timestamp. In Polkadot, it must be within
 some acceptable range of their own system clocks.
 
 Here are some key differences between the different types of extrinsics:
@@ -74,16 +70,15 @@ Here are some key differences between the different types of extrinsics:
 ### Mortal and Immortal Extrinsics
 
 Transactions are generally irreversible once confirmed and added to the blockchain, an immutable
-ledger of all transactions. This means users must exercise caution, as mistakes such as sending
-{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} to the wrong address cannot be reverted. The
-permanence of transactions highlights the importance of careful verification before signing any
-transaction on a blockchain network. It is usually a
+ledger of all transactions. This means users must exercise caution, as mistakes such as sending DOT
+to the wrong address cannot be reverted. The permanence of transactions highlights the importance of
+careful verification before signing any transaction on a blockchain network. It is usually a
 [good practice not to blind sign transactions](../general/transaction-attacks.md) to avoid being
 victim of an attack.
 
 In blockchain terms, transactions can be **mortal** extrinsics (i.e. valid within a defined block
 interval, usually short), or **immortal** extrinsics (i.e. always valid). It is possible to make
-immortal transactions on {{ polkadot: Polkadot. :polkadot }}{{ kusama: Kusama. :kusama }} However,
+immortal transactions on Polkadot. However,
 [for security reasons](../general/transaction-attacks.md#replay-attack), it is highly recommended
 not to do so and most wallet software will not allow you to make an immortal extrinsic.
 
@@ -94,10 +89,10 @@ of transfer.
 
 ### Vested Transfers
 
-{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} may have a lock to account for vesting funds.
-Like other types of [locks](./learn-account-balances.md#locks), these funds cannot be transferred
-but can be used in other parts of the protocol such as voting in governance or being staked as a
-validator or nominator.
+DOT may have a lock to account for vesting funds. Like other types of
+[locks](./learn-account-balances.md#locks), these funds cannot be transferred but can be used in
+other parts of the protocol such as voting in governance or being staked as a validator or
+nominator.
 
 Vesting funds are on a release schedule that unlocks a constant number of tokens at each block
 (**linear vesting**) or the full amount after a specific block number (**cliff vesting**). In all
@@ -120,8 +115,7 @@ funds to the desired destination account.
 ## Transaction Fees
 
 Storage and computation are limited resources in a blockchain network. Transaction fees prevent
-individual users from consuming too many resources.
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} uses a **weight-based fee model** as
+individual users from consuming too many resources. Polkadot uses a **weight-based fee model** as
 opposed to a gas-metering model. As such, fees are charged before transaction execution. Once the
 fee is paid, nodes will execute the transaction.
 
@@ -160,13 +154,12 @@ details.
 
 ### Fee Multiplier
 
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} can add an additional fee to
-transactions if the network becomes too busy and starts to decelerate the system. This additional
-fee is known as the `Fee Multiplier` and its value is defined by the
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} runtime. The multiplier compares the
-saturation of blocks; if the previous block is less saturated than the current block (implying an
-uptrend in usage), the fee is slightly increased. Similarly, the fee is decreased if the previous
-block is more saturated than the current block (implying a downtrend in usage).
+Polkadot can add an additional fee to transactions if the network becomes too busy and starts to
+decelerate the system. This additional fee is known as the `Fee Multiplier` and its value is defined
+by the runtime. The multiplier compares the saturation of blocks; if the previous block is less
+saturated than the current block (implying an uptrend in usage), the fee is slightly increased.
+Similarly, the fee is decreased if the previous block is more saturated than the current block
+(implying a downtrend in usage).
 
 The multiplier can create an incentive to avoid the production of low-priority or insignificant
 transactions. In contrast, those additional fees will decrease if the network calms down and
@@ -200,11 +193,10 @@ transactions warrant limiting resources with other strategies. For example:
 
 ## Parachain Transactions
 
-The transactions that take place within
-{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}'s parachains do not incur relay chain
-transaction fees. Users of shard applications do not even need to hold DOT tokens, as each shard has
-its own economic model and may or may not have a token. There are, however, situations where shards
-themselves make transactions on the relay chain.
+The transactions that take place within parachains do not incur relay chain transaction fees. Users
+of shard applications do not even need to hold DOT tokens, as each shard has its own economic model
+and may or may not have a token. There are, however, situations where shards themselves make
+transactions on the relay chain.
 
 [Parachains](learn-parachains.md) have a dedicated slot on the relay chain for execution, so their
 collators do not need to own DOT in order to include blocks. The parachain will make some
@@ -215,11 +207,10 @@ parachain's behalf.
 
 ## Block Limits and Transaction Priority
 
-Blocks in {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} have both a maximum length
-(in bytes) and a maximum weight. Block producers will fill blocks with transactions up to these
-limits. A portion of each block - currently 25% - is reserved for critical transactions that are
-related to the chain's operation. Block producers will only fill up to 75% of a block with normal
-transactions. Some examples of operational transactions:
+Relay chain blocks have both a maximum length (in bytes) and a maximum weight. Block producers will
+fill blocks with transactions up to these limits. A portion of each block - currently 25% - is
+reserved for critical transactions that are related to the chain's operation. Block producers will
+only fill up to 75% of a block with normal transactions. Some examples of operational transactions:
 
 - Misbehavior reports
 - Council operations