zkEVM: fix remaining errors

Author: nadimkobeissi

.cache/plugin/git-committers/page-authors.json

@@ -171,7 +171,7 @@ Before getting into a transaction flow in L2, users need some funds to perform a
   - Aggregator will take pending transactions to be verified and build a Proof in order to achieve finality on L1
   - Once the Proof is validated, user's transactions will attain L1 finality (important for withdrawals). This is called the **consolidated state**.
 
-The above process is a summarized version of how transactions are processed in zkEVM. We recommend you to take a look at the complete [transaction life cycle](../protocol/submit-transaction.md) document.
+The above process is a summarized version of how transactions are processed in zkEVM. We recommend you to take a look at the complete [transaction life cycle](protocol/transaction-life-cycle/submit-transaction.md) document.
 
 ## Design characteristics
 

docs/img/zkEVM/03msm-state-transition-gen-regs.png

@@ -10,7 +10,7 @@ The 10-day delay allows users to carefully assess the proposed changes and decid
 
 Another smart contract called _Timelock Contract_ is responsible for enabling the 10-day delay.
 
-An outline of the _upgrade process_ is outlined [here](zkevm-upgrades-process.md).
+An outline of the _upgrade process_ is outlined [here](upgrade-process.md).
 
 ## Admin contract in detail
 
@@ -45,7 +45,7 @@ The Admin can schedule and commit maintenance operations transactions in L1 usin
 
 **The Polygon zkEVM team has decided to use the [OpenZeppelin's TimelockController.sol contract](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/TimelockController.sol) to inherit security as well to avoid the lengthy and complicated audit process**. We have changed the `getMinDelay` method in the contract and this modified implementation is named **PolygonZkEVMTimelock.sol** contract.
 
-In the event that the zkEVM contract system is in [Emergency Mode](emergency-state.md), the new `getMinDelay` will set the time `minDelay` to 0. This is when the Security Council Multisig takes control.
+In the event that the zkEVM contract system is in [Emergency Mode](malfunction-resistance/emergency-state.md), the new `getMinDelay` will set the time `minDelay` to 0. This is when the Security Council Multisig takes control.
 
 The zKEVM Protocol’s Admin role is set to an instance of **PolygonZkEVMTimelock.sol** contract address since the deployment of the zk-rollup.
 

docs/img/zkEVM/04msm-simple-state-transition.png

@@ -29,7 +29,7 @@ Version-1 consists mainly of three (3) smart contracts;
 - the Global Exit Root manager contract ([PolygonZkEVMGlobalExitRoot.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVMGlobalExitRoot.sol)), which facillitates synchronization of state-info between the L2 and the L1.
 - the Polygon zkEVM Consensus contract ([PolygonZkEVM.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVM.sol)), which handles the sequencing and verification of transactions in the form of batches.
 
-Interaction of these three contracts has been detailed [here](flow-of-assets.md).
+Interaction of these three contracts has been detailed [here](zkevm-bridge/flow-of-assets.md).
 
 ### Global Exit Trees Review
 

docs/img/zkEVM/05msm-addr-reg-contexts.png

@@ -13,7 +13,7 @@ The _security council_ is a committee that oversees the security of the Polygon
 
 The _security council_ of a rollup has a two-fold responsibility,
 
-- Seeing to it that the system is timeously halted in case of the [_emergency state_](emergency-state.md), and
+- Seeing to it that the system is timeously halted in case of the [_emergency state_](malfunction-resistance/emergency-state.md), and
 - Ensuring that _emergency upgrades_ are implemented as soon as it is practically possible.
 
 The _security council_ therefore utilises a special _multisig_ contract that overrides the usual _Admin Multisig Contract_ and the _Timelock Contract_.

docs/zkEVM/architecture/index.md

@@ -11,9 +11,10 @@ Once a transaction is added to the L2 State, it is broadcast to all other zkEVM
 Users will typically interact with trusted L2 State. However, due to certain protocol characteristics, the verification process for L2 transactions (on Layer 1 to enable withdrawals) can take a long time, typically around 30 minutes but up to a week in rare cases.
 
 !!!note
+
      What is the rare case scenario?
      Verification of transactions on L1 will take 1 week only in the case when an **Emergency State is activated** or the **aggregator does not batch any proofs at all**.
 
-     Additionally, the emergency mode is activated if a sequenced batch is not aggregated in 7 days. Please refer to [<ins>this guide</ins>](emergency-state.md) to understand more about the Emergency State.
+     Additionally, the emergency mode is activated if a sequenced batch is not aggregated in 7 days. Please refer to [this guide](../malfunction-resistance/emergency-state.md) to understand more about the Emergency State.
 
 As a result, users should be mindful of the potential risks associated with high-value transactions, particularly those that cannot be reversed, such as off-ramps, over-the-counter transactions, and alternative bridges.

docs/zkEVM/architecture/protocol/admin-role.md

@@ -40,6 +40,6 @@ Consider now the case where a user commits to bridging some assets from L2 to L1
 
     For example, the interaction between the Consensus Contract and the Sequencer is omitted in the figure.
 
-    For a more wholistic view of the interaction between the Consensus Contract and the Sequencer, the reader is referred to earlier subsections of this documentation, specifically on the [<ins>Consensus Contract</ins>](../architecture/index.md).
+    For a more wholistic view of the interaction between the Consensus Contract and the Sequencer, the reader is referred to earlier subsections of this documentation, specifically on the consensus contract.
 
 ![A end-to-end flow of assets between L1 and L2](../../../../img/zkEVM/06pzb-complete-asset-flow-l1-l2.png)