tweaks and move doc

Author: kmurphypolygon

docs/zkEVM/how-to/check-tx-status.md docs/zkEVM/api/check-tx-status.mddocs/zkEVM/how-to/check-tx-status.md renamed to docs/zkEVM/api/check-tx-status.md

@@ -6,6 +6,9 @@ This contract is deployed on L1 and there is also one deployed on every L2 netwo
 
 ![Polygon bridge contracts](../../../../img/zkEVM/bridge-l1-l2.png)
 
+!!! tip
+    - Notice that the L2 bridge content has a function for updating the global exit root: `setGlobalExitRoot(...)`.
+
 ## Bridge and claim
 
 The main functions of the bridge are:
@@ -17,13 +20,13 @@ The main functions of the bridge are:
 
 ### L1 to L2
 
-To bridge assets from L1 to L2, the sender first transfers the token into the bridge by locking the asset on the origin L1 network. 
+To bridge assets from L1 to L2, the sender first transfers the token into the bridge by locking the asset on the origin network (L1). 
 
 The bridge smart contract mints an equivalent asset, called a wrapped token, on the destination network (L2). 
 
 Once minted, the recipient can claim the token on the destination network (L2).
 
-The data below is transaction data represented by a leaf node and comes from an [example L1 to L2 transaction](https://etherscan.io/tx/0xddbff67ac10c27db39c8e49a36871eba319528286752188e1730fbfdcb184f1b) recorded on the L2 zkEVM chain after a successful `bridgeAsset` call.
+The data below is transaction data (represented by a leaf node in an exit tree) and comes from an [example L1 to L2 transaction](https://etherscan.io/tx/0xddbff67ac10c27db39c8e49a36871eba319528286752188e1730fbfdcb184f1b) recorded on the L2 zkEVM chain after a successful `bridgeAsset` call.
 
 | Index | Parameter name                     | Data type   | Example value                              |
 |------|---------------------------|---------|--------------------------------------------|
@@ -40,7 +43,7 @@ To send an asset from L2 to L1, the wrapped token is first burnt on the L2 netwo
 
 The bridge smart contract then unlocks the original asset on the origin network (L1) ready for claiming.
 
-The data below is transaction data represented by a leaf node and comes from an [example L2 to L1 claim transaction](https://etherscan.io/tx/0x70f7f550cded85e21e0893b6ea5aae3dd2b998021ce449770fa78a967bc44f79) which also posts the local and network exit roots and root proofs used for verification on L1.
+The data below is transaction data (represented by a leaf node in an exit tree) and comes from an [example L2 to L1 claim transaction](https://etherscan.io/tx/0x70f7f550cded85e21e0893b6ea5aae3dd2b998021ce449770fa78a967bc44f79) which also posts the local and network exit roots and root proofs used for verification on L1.
 
 | #  | Parameter name                   | Data type        | Example value                                                              |
 |----|------------------------|-------------|--------------------------------------------------------------------|
@@ -54,14 +57,11 @@ The data below is transaction data represented by a leaf node and comes from an
 | 7  | destinationNetwork     | uint32      | 0                                                                  |
 | 8  | destinationAddress     | address     | 0x5251b3304d1bA5834fd227c2842AA82aC50412E6                         |
 | 9  | amount                 | uint256     | 67000000000000000                                                  |
-| 10 | metadata               | (Abi encoded metadata if any, empty otherwise)bytes       |                                                                    |
+| 10 | metadata               | (abi encoded metadata if any, empty otherwise)bytes       |                                                                    |
 
 ## Updating system state
 
-The Polygon bridge smart contract uses exit tree roots to manage state. Leaves of the trees point to transaction data such as detailed above.
-
-!!! tip
-    - For further details on the exit tree architecture, check out the [exit root documentation](exit-roots.md).
+The Polygon bridge smart contract uses a set of [exit tree roots](exit-roots.md) to manage system state. Leaves of the trees point to transaction data such as detailed above.
 
 On a call to the bridge, the bridge contract calls the `updateExitRoot(...)` function on the relevant exit root contract (L1 or L2) which adds an exit leaf to the relevant exit tree. 
 
@@ -70,7 +70,7 @@ On a call to the bridge, the bridge contract calls the `updateExitRoot(...)` fun
 
 Adding a new leaf to the tree triggers an update to the exit tree root which then propagates to an update on the global exit tree root.
 
-Using Merkle tree exit roots in this way, referenced by the bridge contract and accessible to the `PolygonRollupManager` contract with getters, the bridge contract synchronizes data across L1 and L2, the sequencer component, and the state db.
+Using Merkle tree exit roots in this way, referenced by the bridge contracts and accessible to the `PolygonRollupManager` contract with getters, the bridge contract triggers data synchronization across L1 and L2, including at the sequencer and state db level.
 
 The use of two distinct global exit root manager contracts 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.
 
@@ -80,7 +80,7 @@ Meanwhile, all asset transfers can be validated by any L1 and L2 node due to the
 
 ### L1 to L2
 
-1. If a call to the `bridgeAsset` or `bridgeMessage` passes validation, the bridge contract appends an exit leaf to the L1 exit tree and computes the new L1 exit tree root.
+1. If a call to `bridgeAsset` or `bridgeMessage` on L1 passes validation, the bridge contract appends an exit leaf to the L1 exit tree and computes the new L1 exit tree root.
 
 2. The global exit root manager appends the new L1 exit tree root to the global exit tree and computes the global exit root.
 
@@ -94,9 +94,9 @@ Meanwhile, all asset transfers can be validated by any L1 and L2 node due to the
 
 ### L2 to L1
 
-1. If a `bridgeAsset` or `bridgeMessage` call on the L2 bridge contract validates, the bridge contract appends an exit leaf to the L2 exit tree and computes the new L2 exit tree root.
+1. If a call to `bridgeAsset` or `bridgeMessage` on L2 passes validation, the bridge contract appends an exit leaf to the L2 exit tree and computes the new L2 exit tree root.
 
-2. The L2 global exit root manager appends the new L2 exit tree toot to the global exit tree and computes the global exit root. At that point, the caller's bridge transaction is included in one of batches selected and sequenced by the sequencer.
+2. The L2 global exit root manager appends the new L2 exit tree root to the global exit tree and computes the global exit root. At that point, the caller's bridge transaction is included in one of batches selected and sequenced by the sequencer.
 
 3. The aggregator generates a zk-proof attesting to the computational integrity in the execution of sequenced batches which include the transaction.
 
@@ -110,7 +110,7 @@ Meanwhile, all asset transfers can be validated by any L1 and L2 node due to the
 
 ### L2 to L2
 
-1. When a batch of transactions is processed, the bridge contracts appends the L2 exit tree with a new leaf containing the batch information. This updates the L2 exit tree root.
+1. When a batch of transactions is processed, the bridge contract appends the L2 exit tree with a new leaf containing the batch information. This updates the L2 exit tree root.
 
 2. The bridge contracts communicates the L2 exit tree root to the L2 global exit root manager. The L2 global exit root manager, however, does not update the global exit tree at this stage.
 

docs/zkEVM/architecture/high-level/smart-contracts/bridging.md

@@ -1,4 +1,4 @@
-An exit tree is a binary append-only sparse Merkle tree (SMT) whose leaf nodes store bridging data. The exit trees have a depth of 32.
+An exit tree is a binary, append-only, sparse Merkle tree (SMT) whose leaf nodes store bridging data. The exit trees have a depth of 32.
 
 Whenever a token or message is bridged, the bridge contract appends an exit leaf to the exit tree related to the specific network. 
 
@@ -8,7 +8,7 @@ The global exit tree root of the L1 info tree is, therefore, the source of truth
 
 ## Rollup local exit trees
 
-The L2 bridge contract manages a special Merkle tree called a local exit tree for each network that participates in bridging and claiming which is managed and updated by the [PolygonZkEVMGlobalExitRootL2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/etrog/contracts/PolygonZkEVMGlobalExitRootL2.sol) contract.
+The L2 bridge contract manages a special Merkle tree called a local exit tree for each network that participates in bridging and claiming which is updated by the [PolygonZkEVMGlobalExitRootL2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/etrog/contracts/PolygonZkEVMGlobalExitRootL2.sol) contract.
 
 <center>
 ![Local exit tree for network participant](../../../../img/cdk/high-level-architecture/local-exit-tree.png)
@@ -17,17 +17,21 @@ The L2 bridge contract manages a special Merkle tree called a local exit tree fo
 Data from `bridgeAsset()` and `bridgeMessage()` calls on the bridge is stored in leaf nodes on the local exit trees. 
 
 !!! important
-    The following exit tree structures are managed by the [PolygonRollupManager.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonRollupManager.sol), the L1 [PolygonZkEVMBridgeV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMBridgeV2.sol) contract, and the[PolygonZkEVMGlobalExitRootV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMGlobalExitRootV2.sol).
+    The following exit tree structures are managed by:
+
+    - The [PolygonRollupManager.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonRollupManager.sol). 
+    - The L1 [PolygonZkEVMBridgeV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMBridgeV2.sol) contract. 
+    - The[PolygonZkEVMGlobalExitRootV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMGlobalExitRootV2.sol).
 
 ## Exit tree for rollups
 
-The roots of the local exit trees feed into a single exit tree that manages state from all participating L2 rollups.
+The roots of the L2 local exit trees feed into a single exit tree that manages state from all participating L2 rollups.
 
 <center>
 ![Exit tree for rollups](../../../../img/cdk/high-level-architecture/exit-tree-for-rollups.png)
 </center>
 
-The L2 local exit root is accessible on the rollup manager by calling the `getRollupExitRoot()` method.
+The L2 local exit root is accessible on the rollup manager by calling the [`getRollupExitRoot()`](https://github.com/0xPolygonHermez/zkevm-contracts/blob/b2a62e6af5738366e7494e8312184b1d6fdf287c/contracts/v2/PolygonRollupManager.sol#L1620) method.
 
 ## L1 local exit tree
 
@@ -51,7 +55,7 @@ The GER is the fingerprint of the information stored in all trees, and thus repr
 
 ## Exit leaves
 
-Two constants define leaf types in the bridge contract.
+Two constants define transaction leaf types in the bridge contract.
 
 ```solidity
 // Leaf type asset

docs/zkEVM/architecture/high-level/smart-contracts/exit-roots.md

@@ -93,7 +93,6 @@ nav:
         - Deploy a contract with Foundry: zkEVM/how-to/using-foundry.md
         - Deploy a contract with Hardhat: zkEVM/how-to/using-hardhat.md
         - Verify a contract: zkEVM/how-to/verify-contract.md
-        - Check transaction status: zkEVM/how-to/check-tx-status.md
       - Architecture high-level:
         - Overview: zkEVM/architecture/high-level/overview.md
         - Smart contracts: 
@@ -272,6 +271,7 @@ nav:
         - EVM vs. zkEVM: zkEVM/spec/evm-differences.md
       - API: 
         - JSON RPC endpoints: zkEVM/api/json-rpc.md
+        - Check transaction status: zkEVM/api/check-tx-status.md
       - Concepts:
         - Concepts: zkEVM/concepts/index.md
         - EVM basics: zkEVM/concepts/evm-basics.md