Apply suggestions from code review

Co-authored-by: Dra Murphy <149679879+kmurphypolygon@users.noreply.github.com>

Author: EmpieichO

docs/zkEVM/architecture/protocol/incentive-mechanism.md

@@ -72,7 +72,7 @@ function _updateBatchFee(uint64 newLastVerifiedBatch) internal
 The admin defines two storage variables that are used to **tune the fee adjustment function**:
 
 - `veryBatchTimeTarget`, which is **the targeted time of the verification of a batch**, so the `batchFee` variable is updated to achieve this target, and
-- `multiplierBatchFee`, which is the batch fee multiplier, with 3 decimals **ranging from 1000 to 1024**.
+- `multiplierBatchFee`, which is the batch fee multiplier, with 3 decimals ranging from 1000 to 1024.
 
 The function `_updateBatchFee` first determines how many of the aggregated batches are late. That is, those who are in the sequence but have not yet been aggregated.
 

docs/zkEVM/architecture/protocol/malfunction-resistance/aggregator-resistance.md

@@ -15,7 +15,7 @@ function verifyBatches(
 ) public ifNotEmergencyState
 ```
 
-As previously stated, the `verifyBatches` function accepts the same arguments as the `trustedVerifyBatches` function. However, the `verifyBatches` function adds two additional constraints for a sequence to be aggregated, as well as a new L2 state stage called Pending state.
+As previously stated, the `verifyBatches` function accepts the same arguments as the `trustedVerifyBatches` function. However, the `verifyBatches` function adds two additional constraints for a sequence to be aggregated, as well as a new L2 pending state.
 
 Along with the conditions required in the `trustedVerifyBatches` function, the following conditions must also be met in `verifyBatches`:
 

docs/zkEVM/architecture/protocol/transaction-life-cycle/batch-sequencing.md

@@ -31,7 +31,7 @@ Similarly, the number of batches in a sequence is limited by the contract's publ
 
 Only the trusted sequencer's Ethereum account can access the `sequencedBatches` mapping. The contract must not be in an emergency state.
 
-The function call is reverted if the above conditions are not met.
+The function call reverts if the above conditions are not met.
 
 ## Batch validity & L2 state integrity
 
@@ -43,7 +43,7 @@ The `sequencedBatches` function iterates over every batch of the sequence, check
 
 If one block is not valid, the transaction reverts, discarding the entire sequence. Otherwise, if all blocks in the batches that are to be sequenced are valid, the sequencing process continues as normal.
 
-A storage variable called `lastBatchSequenced` is used as a batch counter, and it is thus incremented each time a batch is sequenced. It gives a specific index number to each batch that is to be used as a position value in the batch chain.
+A storage variable called `lastBatchSequenced` is used as a batch counter, and it is thus incremented each time a batch is sequenced. It gives a specific index number to each batch that is used as a position value in the batch chain.
 
 The same hashing mechanism used in blockchains to link one block to the next is used in batches to ensure the cryptographic integrity of the batch chain. That is, including the previous batch's digest among the data used to compute the next batch's digest.
 
@@ -93,7 +93,7 @@ struct SequencedBatchData {
 - `sequencedTimestamp` is the timestamp of the block where the sequencing L1 transaction is executed.
 - `previousLastBatchSequenced` is the index of the last sequenced batch before the first batch of the current sequence (i.e., the last batch of the previous sequence).
 
-The index number of the last batch in the sequence is used as key and the `SequencedBatchData` struct is used as value when the sequence is entered into `sequencedBatches` mapping.
+The index number of the last batch in the sequence is the key, and the `SequencedBatchData` struct is the value, in the `sequencedBatches` mapping.
 
 ## Batch data minimal storage
 
@@ -112,7 +112,7 @@ As previously stated, the hash digest becomes a commitment of the entire batch c
 
 The data availability of the L2 transactions is guaranteed because the data of each batch can be recovered from the calldata of the sequencing transaction, which is not part of the contract storage but is part of the L1 state.
 
-Finally a `SequenceBatches` event is emitted.
+Finally a `SequenceBatches` event emits.
 
 ```solidity
 event SequenceBatches (uint64 indexed numBatch)

docs/zkEVM/architecture/protocol/zkevm-bridge/exit-tree.md

@@ -1,6 +1,6 @@
-The zkEVM's bridge SC utilizes a special Merkle tree called Exit Tree for each of the networks participating in the communication or asset-exchange.
+The zkEVM's bridge SC utilizes a special Merkle tree called an exit tree for each of the networks participating in the communication or asset-exchange.
 
-The term `exit tree refers to an append-only Sparse Merkle tree (SMT) whose leaf nodes record information about assets being transferred out of the network. Exit trees of depth 32 are used by Polygon zkEVM.
+The term exit tree refers to an append-only sparse Merkle tree (SMT) whose leaf nodes record information about assets being transferred out of the network. Exit trees of depth 32 are used by Polygon zkEVM.
 
 From now on, a leaf of an exit tree is referred to as a exit leaf. Exit leaves are classified into two types: type 0 for recording asset(s) information and Type 1 for recording messaging information.
 
@@ -14,7 +14,7 @@ An exit leaf, in particular, is a Keccak256 hash of the ABI encoded packed struc
 - uint256 amount: Amount of tokens/ether to bridge.
 - bytes32 metadataHash: Hash of the metadata. This metadata contains information about asset transferred or the message payload.
 
-When a user commits to transferring assets from one network to another, the bridge SC must add an exit leaf to that network's exit tree.
+When a user commits to transferring assets from one network to another, the bridge contract adds an exit leaf to that network's exit tree.
 
 The Merkle root of an exit tree is known as the exit tree root, and it is the fingerprint of all the information recorded in the exit tree's leaf nodes.
 
@@ -63,7 +63,7 @@ To claim the bridged assets on the destination L2 network, the global exit root
 
 ### Transfer from rollup L2 to L1
 
-Transfers can also occur from an L2 Rollup to the Mainnet L1. In this scenario, the same procedure outlined in the previous example is followed, but in the reverse direction.
+Transfers can also occur from an L2 Rollup to the L1 mainnet. In this scenario, the same procedure outlined in the previous example is followed, but in the reverse direction.
 
 That is, once a user commits to a transfer, an exit leaf is added to the L2 exit tree with corresponding transfer information. The transfer data in this case looks as follows:
 

docs/zkEVM/architecture/protocol/zkevm-bridge/index.md

@@ -1,4 +1,4 @@
-The ability of a blockchain to exchange data with other blockchains is crucial for its participation in a broader ecosystem, a concept known as Interoperability. Various solutions have been developed to enable interoperability, each offering unique advantages and disadvantages.
+The ability of a blockchain to exchange data with other blockchains is crucial for its participation in a broader ecosystem, a concept known as interoperability. Various solutions have been developed to enable interoperability, each offering unique advantages and disadvantages.
 
 The Polygon team has developed an interoperability solution in the form of a bridge for the Polygon zkEVM network. This zkEVM bridge facilitates communication and asset migration between the Polygon zkEVM network and other networks, such as the L1 (Ethereum Mainnet) or any L2 built on Ethereum.
 
@@ -10,15 +10,15 @@ In zk-rollups like the Polygon zkEVM, L1 smart contracts manage L2 state transit
 
 To better understand the zkEVM bridge protocol design, let's use an analogy. Refer to the illustration below for a clearer explanation of the protocol.
 
-![Polygon zkEVM bridge Schema](../../../../img/zkEVM/01pzb-polygon-zkevm-schema.png)
+![Polygon zkEVM bridge schema](../../../../img/zkEVM/01pzb-polygon-zkevm-schema.png)
 
 Consider two networks, L1 and L2. To bridge an asset between L1 and L2, a user must lock the asset on the origin network (L1). The bridge smart contract then mints an equivalent representative asset on the destination network (L2). This minted asset is called a Wrapped Token.
 
 Once minting is complete, the asset can be claimed by the user or recipient in the destination network (L2).
 
 The operation can also be performed in reverse. After burning the Wrapped Token, the bridge smart contract unlocks the original asset on the origin network.
 
-As mentioned earlier, there is also a third option where the bridge smart contract facilitates cross-chain messaging. This allows data payloads to be sent from one network to another using the bridge smart contract's Bridge and Claim operations.
+As mentioned earlier, there is also a third option where the bridge smart contract facilitates cross-chain messaging. This allows data payloads to be sent from one network to another using the bridge smart contract's bridge and claim operations.
 
 ## Comparing with Ethereum 2.0 deposit contract
 
@@ -36,9 +36,9 @@ As a result, as stated in this document, every transfer is protected by smart co
 
 ## Features
 
-The Polygon zkEVM bridge smart contract's main feature is the use of Exit Trees and the Global Exit Tree, with the Global Exit Tree Root serving as the primary source of state truth.
+The Polygon zkEVM bridge smart contract's main feature is the use of exit trees and the global exit tree, with the global exit tree root serving as the primary source of state truth.
 
-The use of two distinct Global Exit Root managers for L1 and L2, as well as separate logic for the bridge SC and each of these Global Exit Root managers, allows for extensive network interoperability.
+The use of two distinct global exit root managers for L1 and L2, as well as separate logic for the bridge contract and each of these global exit root managers, allows for extensive network interoperability.
 
 Meanwhile, all asset transfers can be validated by any L1 and L2 nodes due to data availability.
 

docs/zkEVM/how-to/verify-contract.md

@@ -71,7 +71,7 @@ Click on **Verify & Publish** to verify your deployed smart contract.
 
 ## Verify using Remix
 
-We use ready-made `Storage.sol` contract in Remix. Compile the contract and follow the steps provided below.
+We use the ready-made `Storage.sol` contract in Remix. Compile the contract and follow the steps provided below.
 
 1. Deploy the `Storage.sol` contract: