Apply suggestions from code review

hsutaiyu · kmurphypolygon · web-flow · commit 6cd58d800753 · 2024-06-03T18:39:16.000+04:00
Co-authored-by: Dra Murphy &lt;149679879+kmurphypolygon@users.noreply.github.com&gt;
diff --git a/docs/pos/architecture/heimdall/key-management.md b/docs/pos/architecture/heimdall/key-management.md
@@ -1,4 +1,4 @@
-Each validator uses two keys to manage validator related activities on Polygon. The *signer* key is kept on the node and is generally considered a *hot* wallet, whereas the Owner key is supposed to kept very secure, is used infrequently, and is generally considered a *cold* wallet. The staked funds are controlled by the *owner* key.
+Each validator uses two keys to manage validator related activities on Polygon. The *signer* key is kept on the node and is generally considered a *hot* wallet, whereas the owner key is supposed to kept very secure, is used infrequently, and is generally considered a *cold* wallet. The staked funds are controlled by the *owner* key.
 
 This separation of responsibilities has been done to ensure an efficient tradeoff between security and ease of use. Both keys are Ethereum compatible addresses and work exactly the same manner. And yes, it is possible to have same owner and signer keys.
 
diff --git a/docs/pos/concepts/tokens/index.md b/docs/pos/concepts/tokens/index.md
@@ -1,4 +1,4 @@
-The *Tokens* subsection focuses on the proposed Polygon PoS's native token POL and the soon to be replaced native token MATIC.
+This section focuses on the proposed Polygon PoS's native token POL and the soon to be replaced native token MATIC.
 
 The *POL* subsection defines the POL token and continues to present, in a question-and-answer (Q&A) format, all the information that users need to know about the proposed transition.
 
diff --git a/docs/pos/get-started/becoming-a-validator.md b/docs/pos/get-started/becoming-a-validator.md
@@ -21,7 +21,7 @@ In return for their efforts, validators are rewarded with incentives, encouragin
 Polygon consists of the three following layers:
 
 * Ethereum layer: A set of contracts on the Ethereum mainnet.
-* Heimdall layer:  A set of proof-of-stake Heimdall nodes running in parallel to the Ethereum mainnet, monitoring the set of staking contracts deployed on the Ethereum mainnet, and committing the Polygon PoS network checkpoints to the Ethereum mainnet. Heimdall is based on Tendermint.
+* Heimdall layer: A set of proof-of-stake Heimdall nodes running in parallel to the Ethereum mainnet, monitoring the set of staking contracts deployed on the Ethereum mainnet, and committing the Polygon PoS network checkpoints to the Ethereum mainnet. Heimdall is based on Tendermint.
 * Bor layer: A set of block-producing Bor nodes shuffled by Heimdall nodes. Bor is based on Go Ethereum.
 
 To be a validator on the Polygon PoS network, you must do the following:
@@ -67,7 +67,7 @@ Bor is the block producing node and layer for the Polygon PoS network. It is bas
 
     Keep up with the latest node and validator updates from the Polygon team and the community by keeping an eye on the [announcements posed to Polygon forums](https://forum.polygon.technology/c/announcement/6).
 
-A blockchain validator is someone who is responsible for validating transactions within a blockchain. On the Polygon PoS network, any participant can be qualified to become a Polygon's validator by running a **Validator Node (Sentry + Validator)** to earn rewards and collect transaction fees. To ensure the good participation by validators, they lock up at least 1 MATIC token as a stake in the ecosystem.
+A blockchain validator is someone who is responsible for validating transactions within a blockchain. On the Polygon PoS network, any participant can be qualified to become a Polygon's validator by running a validator node (sentry + validator) to earn rewards and collect transaction fees. To ensure the good participation by validators, they lock up at least 1 MATIC token as a stake in the ecosystem.
 
 !!! info "Active validator limit"
     
@@ -119,7 +119,7 @@ The following technical node operations are **done automatically by the nodes:**
 
 The node uptime on the Polygon PoS network is based on the number of checkpoint transactions that the validator node has signed.
 
-Approximately every 34 minutes a proposer submits a checkpoint transaction to the Ethereum mainnet. The checkpoint transaction must be signed by every validator on the Polygon PoS network. **Failure to sign a checkpoint transaction results in the decrease of your validator node performance**.
+Approximately every 34 minutes a proposer submits a checkpoint transaction to the Ethereum mainnet. The checkpoint transaction must be signed by every validator on the Polygon PoS network. Failure to sign a checkpoint transaction results in the decrease of your validator node performance.
 
 The process of signing the checkpoint transactions is automated. To ensure your validator node is signing all valid checkpoint transactions, you must maintain and monitor your node health.
 
diff --git a/docs/pos/how-to/bridging/ethereum-polygon/ethereum-to-matic.md b/docs/pos/how-to/bridging/ethereum-polygon/ethereum-to-matic.md
@@ -12,7 +12,7 @@ The sender and receiver contracts are required to be mapped on Ethereum — [Sta
 
 ---
 
-In the following walkthrough, we'll be deploying a sender contract on Sepolia (Ethereum testnet) and a Receiver contract on Amoy (Polygon testnet). Then, we'll be sending data from the sender and reading data on the receiver via web3 calls in a node script.
+In the following walkthrough, we'll be deploying a sender contract on Sepolia (Ethereum testnet) and a receiver contract on Amoy (Polygon testnet). Then, we'll be sending data from the sender and reading data on the receiver via web3 calls in a node script.
 
 ### 1. Deploy sender contract
 
@@ -51,7 +51,7 @@ In the above function, `stateSenderContract` is the address of the `StateSender`
 
 It is recommended to use constructors to pass in variables, but for the purpose of this demo, we'll simply hardcode these two addresses:
 
-Following is how our `Sender.sol` looks like:
+Following is what our `Sender.sol` looks like:
 
 ```jsx title="Sender.sol"
 
@@ -84,7 +84,7 @@ Use Remix to deploy the contract and keep a note of the address and ABI.
 
 The receiver contract is the one that is invoked by a validator when the `StateSynced` event is emitted. The validator invokes the function `onStateReceive`on the receiver contract to submit the data. To implement it, we first import [StateReceiver](https://github.com/maticnetwork/contracts/blob/release-betaV2/contracts/child/bor/StateReceiver.sol) interface and write down our custom logic — to interpret the transferred data inside onStateReceive.
 
-Following is how our `Receiver.sol` looks like:
+The following is what our `Receiver.sol` looks like:
 
 ```jsx title="Receiver.sol"
 
diff --git a/docs/pos/how-to/bridging/l1-l2-communication/state-transfer.md b/docs/pos/how-to/bridging/l1-l2-communication/state-transfer.md
@@ -42,12 +42,12 @@ You need to inherit `FxBaseRootTunnel` contract in your root contract on Ethereu
 - Sepolia: [0x1707157b9221204869ED67705e42fB65e026586c](https://sepolia.etherscan.io/address/0x1707157b9221204869ED67705e42fB65e026586c)
 - Amoy: [0xf5D2463d0176462d797Afcd57eC477b7B0CcBE70](https://amoy.polygonscan.com/address/0xf5D2463d0176462d797Afcd57eC477b7B0CcBE70)
 
-## State Transfer from Ethereum to Polygon
+## State transfer from Ethereum to Polygon
 
 - You need to call `_sendMessageToChild()` internally in your root contract and pass the data as an argument to be sent to Polygon. Example: [0x00a1aa71593fec825b4b1ce1081b5a9848612fb21f9e56def2914b483f5f34f5](https://sepolia.etherscan.io/tx/0x00a1aa71593fec825b4b1ce1081b5a9848612fb21f9e56def2914b483f5f34f5)
 - In your child contract, implement `_processMessageFromRoot()` virtual function in `FxBaseChildTunnel` to retrieve data from Ethereum. The data will be received automatically from the state receiver when the state is synced.
 
-## State Transfer from Polygon to Ethereum
+## State transfer from Polygon to Ethereum
 
 1. Call `_sendMessageToRoot()` internally in your child contract with data as a parameter to be sent to Ethereum. Note down the transaction hash as it will be used to generate the proof after the transaction has been included as a checkpoint.
 
diff --git a/docs/pos/how-to/full-node/full-node-ansible.md b/docs/pos/how-to/full-node/full-node-ansible.md
@@ -6,13 +6,13 @@ An [Ansible playbook](https://docs.ansible.com/ansible/latest/user_guide/playboo
 
 ## Prerequisites
 
-- Install Ansible on your local machine with Python3.x. The setup will not work if you have Python 2.x.
+- Install Ansible on your local machine with Python3.x. The setup doesn't run on Python 2.x.
     - To install Ansible with Python 3.x, you can use pip. If you do not have pip on your machine,
       follow the steps outlined [here](https://pip.pypa.io/en/stable/). Run `pip3 install ansible` to install
       Ansible.
 - Check the [Polygon PoS Ansible repository](https://github.com/maticnetwork/node-ansible#requirements) for
   requirements.
-- You will also need to ensure that Go is *not installed* in your environment. You will run into issues if you attempt to set up your full node through Ansible with Go installed as Ansible requires specific packages of Go to be installed.
+- You also need to ensure that Go is *not installed* in your environment. You will run into issues if you attempt to set up your full node through Ansible with Go installed as Ansible requires specific packages of Go.
 - You will also need to make sure that your VM / Machine does not have any previous setups for Polygon Validator or Heimdall or Bor. You will need to delete them as your setup will run into issues.
 
 !!! info "Heimdall source enhancements"
diff --git a/docs/pos/how-to/full-node/full-node-binaries.md b/docs/pos/how-to/full-node/full-node-binaries.md
@@ -61,7 +61,7 @@ Hex Byte representation - [171 205 18 52]
 Length in byte format - 4
 ```
 
-To install *Heimdall*, run the below commands:
+To install *Heimdall*, run the following commands:
 
 ```bash
 curl -L https://raw.githubusercontent.com/maticnetwork/install/main/heimdall.sh | bash -s -- <heimdall_version> <network_type> <node_type>
diff --git a/docs/pos/how-to/full-node/full-node-docker.md b/docs/pos/how-to/full-node/full-node-docker.md
@@ -380,7 +380,7 @@ At this point, we should be ready to start Bor. We’re going to use this comman
 docker run -p 30303:30303 -p 8545:8545 -v /mnt/data/bor:/bor-home:rw --net polygon --name bor -d --restart unless-stopped  0xpolygon/bor:1.1.0 server --config /bor-home/config.toml
 ```
 
-If everything went well, you should see log entries that look like this:
+If everything goes well, you should see log entries that look like this:
 
 ```bash
 2022-12-14T19:53:51.989897291Z INFO [12-14|19:53:51.989] Fetching state updates from Heimdall     fromID=4 to=2020-05-30T23:47:46Z
diff --git a/docs/pos/how-to/operate-validator-node/change-signer-address.md b/docs/pos/how-to/operate-validator-node/change-signer-address.md
@@ -6,7 +6,7 @@ For more information on what a signer address is, see
 
 Make sure your new validator node is fully synced and is running with the new signer address.
 
-## Change the signer Address
+## Change the signer address
 
 This guide refers to your current validator node as Node 1 and your new validator node as Node 2.
 
diff --git a/docs/pos/how-to/operate-validator-node/topup-heimdall-fee.md b/docs/pos/how-to/operate-validator-node/topup-heimdall-fee.md
@@ -6,7 +6,7 @@ This document provides instructions on how to top up the Heimdall fee for a PoS
 
 The easiest way is via the [Polygon Staking UI](https://staking.polygon.technology/account).
 
-You can also do it manually by following the steps below. This requires basic Etherscan knowledge and key details like the Validator signer address.
+You can also do it manually by following the steps below. This requires basic Etherscan knowledge and key details like the validator signer address.
 
 1. Head over to [Etherscan.io](https://etherscan.io)
 
diff --git a/docs/pos/how-to/operate-validator-node/validator-performance.md b/docs/pos/how-to/operate-validator-node/validator-performance.md
@@ -51,7 +51,7 @@ The **Public Notices** page shows the recent notices and messages sent to the co
 
 ![Figure: Topup Heimdall fee](../../../img/pos/public-notices.png)
 
-This is how a notice message should look like:
+This is what a notice message should look like:
 
 <center>
 ![Figure: Notice](../../../img/pos/notice.png){width=60%}
diff --git a/docs/pos/how-to/troubleshoot/technical-faqs.md b/docs/pos/how-to/troubleshoot/technical-faqs.md
@@ -123,7 +123,7 @@ ps -aux | grep bor
 sudo kill -9 PID
 ```
 
-##### For Binaries
+##### For binaries
 
 Go to 
 ```bash
@@ -152,7 +152,7 @@ This error occurs because the path for the `password.txt` and Keystore file is i
 3. Make sure you have added correct address in `/etc/bor/metadata`.
 
 
-##### For Binaries
+##### For binaries
 
 1. Copy the Bor keystore file to:
 
@@ -200,11 +200,11 @@ Bor:
 
 ```$ sudo dpkg -i matic-bor```
 
-And delete Bor Directory using:
+And delete Bor directory using:
 
 ```$ sudo rm -rf /etc/bor```
 
-##### For Binaries
+##### For binaries
 
 ```$ sudo rm -rf /etc/bor```
 
@@ -215,7 +215,7 @@ And then run:
 
 ### 8. How many validators can be active concurrently?
 
-There will be up to 100 active validators at a time. We will bring in more participants if the limit is reached mid-way through the event as well. Note that active validators is mostly those whose uptime is high. Participants with high downtime will be forced out.
+There can be up to 100 active validators at a time. We bring in more participants if the limit is reached mid-way through the event as well. Note that active validators is mostly those whose uptime is high. Participants with high downtime are forced out.
 
 ### 9. How much should I stake?
 
@@ -235,7 +235,7 @@ heimdallcli stake --staked-amount 400000000000000000000  --fee-amount 1000000000
 
 If you have access to the ETH address that you submitted earlier then you can transfer the test tokens from that account to the current account. And then you can initiate your process of setting up your nodes.
 
-If you don't have access to that ETH address, we won't be transferring you tokens separately. You can  re-register in the form again with the correct ETH address.
+If you don't have access to that ETH address, we won't be transferring you tokens separately. You can re-register in the form again with the correct ETH address.
 
 ### 11. I'm getting an error starting the bridge
 
@@ -366,7 +366,7 @@ Stop Bor: `sudo service bor stop` or
 1. `ps -aux | grep bor`. Get the PID for Bor and then run the following command.
 2. `sudo kill -9 PID`
 
-##### For Binaries
+##### For binaries
 
 Stop Heimdall: `pkill heimdalld`
 
@@ -382,7 +382,7 @@ Delete Heimdall: `sudo rm -rf /etc/heimdall/*`
 
 Delete Bor: `sudo rm -rf /etc/bor/*`
 
-##### For Binaries
+##### For binaries
 
 Delete Heimdall: `sudo rm -rf /var/lib/heimdall/`
 
diff --git a/docs/pos/how-to/validator/prerequisites.md b/docs/pos/how-to/validator/prerequisites.md
@@ -2,7 +2,7 @@
 comments: true
 ---
 
-## Before setting up the calidator node
+## Before setting up the validator node
 
 !!! warning "Caution"
     
@@ -18,9 +18,9 @@ Validator nodes require an Ethereum-based RPC endpoint. You may use your own Eth
 
 ### Open necessary ports
 
-- Port `26656`: Heimdall service will connect your node to another node's Heimdall service using this port.
+- Port `26656`: Heimdall service connects your node to another node's Heimdall service using this port.
 
-- Port `30303`: Bor service will connect your node to another node's Bor service using this port.
+- Port `30303`: Bor service connects your node to another node's Bor service using this port.
 
 - Port `22`: For the validator to be able to SSH from wherever they are.
 
@@ -46,13 +46,13 @@ See the doc on [validator best practices](../operate-validator-node/validator-be
 
     | Checklist               | Binaries                                       | Ansible                                                                 | Packages                                       |
     | ----------------------- | ---------------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------- |
-    | Machines Required   | 2 Machines - *Sentry* & *Validator*        | 3 Machines - *Local Machine*, *Sentry* and *Validator*            | 2 Machines - *Sentry* & *Validator*        |
-    | Install Go Packages | Yes                                            | No                                                                      | No                                             |
-    | Install Python      | No                                             | Yes (only on the *Local Machine* where the *Ansible Playbook* runs) | No                                             |
+    | Machines required   | 2 Machines - *sentry* & *validator*        | 3 Machines - *local machine*, *sentry* and *validator*            | 2 Machines - *sentry* & *validator*        |
+    | Install Go packages | Yes                                            | No                                                                      | No                                             |
+    | Install Python      | No                                             | Yes (only on the local machine where the Ansible Playbook runs) | No                                             |
     | Install Ansible     | No                                             | Yes (only on one machine)                                               | No                                             |
     | Install Bash        | No                                             | No                                                                      | Yes                                            |
     | Run Build Essential | Yes                                            | No                                                                      | No                                             |
-    | Node Setup          | [Using Binaries](../validator/validator-binaries.md) | [Using Ansible](../validator/validator-ansible.md)                            | [Using Packages](../validator/validator-packages.md) |
+    | Node setup          | [Using binaries](../validator/validator-binaries.md) | [Using Ansible](../validator/validator-ansible.md)                            | [Using packages](../validator/validator-packages.md) |
 
 2. Once your sentry and validator nodes are synced and running, head over to our [Discord server](https://discord.com/invite/0xPolygon) and ask the community to health-check your nodes. You may check the logs by using the following commands:
 
@@ -177,7 +177,7 @@ This document gives some additional details for setting up a new node based on [
 
 ### 2. Why do I have to keep ETH in my signer account?
 
-ETH is required on your signer account because for submitting checkpoints to Ethereum, all transactions require ETH to be used as Gas. Hence, ETH is required in your signer Account.
+ETH is required on your signer account because for submitting checkpoints to Ethereum, all transactions require ETH to be used as Gas. Hence, ETH is required in your signer account.
 
 ### 3. For a Polygon PoS validator, do I need to setup a sentry and validator node or can I just run the Validator node by itself?
 
diff --git a/docs/pos/reference/commit-chain-multisigs.md b/docs/pos/reference/commit-chain-multisigs.md
@@ -41,7 +41,7 @@ The primary role of multi-signature wallets (multisigs) is to facilitate contrac
 
 ### Permissionless mapping
 
-| Multisig Address  | Permissionless Mapping of Standard ChildERC20 Tokens (No Multisig Required) |
+| Multisig address  | Permissionless mapping of standard ChildERC20 tokens (no multisig required) |
 |:----------------:|--------------------------------------------------------------------------------|
 | Purpose          | FxPortal supports permissionless token mapping of standard ChildERC20 for any ERC20 token on Ethereum. |
 | Chain            | Permissionless                                                                 |
diff --git a/docs/pos/reference/contracts/stakingmanager.md b/docs/pos/reference/contracts/stakingmanager.md

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-Each validator uses two keys to manage validator related activities on Polygon. The signer key is kept on the node and is generally considered a hot wallet, whereas the Owner key is supposed to kept very secure, is used infrequently, and is generally considered a cold wallet. The staked funds are controlled by the owner key.`
	`1`	`+Each validator uses two keys to manage validator related activities on Polygon. The signer key is kept on the node and is generally considered a hot wallet, whereas the owner key is supposed to kept very secure, is used infrequently, and is generally considered a cold wallet. The staked funds are controlled by the owner key.`
`2`	`2`
`3`	`3`	`This separation of responsibilities has been done to ensure an efficient tradeoff between security and ease of use. Both keys are Ethereum compatible addresses and work exactly the same manner. And yes, it is possible to have same owner and signer keys.`
`4`	`4`
Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-The Tokens subsection focuses on the proposed Polygon PoS's native token POL and the soon to be replaced native token MATIC.`
	`1`	`+This section focuses on the proposed Polygon PoS's native token POL and the soon to be replaced native token MATIC.`
`2`	`2`
`3`	`3`	`The POL subsection defines the POL token and continues to present, in a question-and-answer (Q&A) format, all the information that users need to know about the proposed transition.`
`4`	`4`