matter-labs · kelemeno · Oct 26, 2024 · Oct 26, 2024 · Oct 26, 2024 · Oct 26, 2024
diff --git a/docs/other/L1 ecosystem contracts.md b/docs/other/L1 ecosystem contracts.md
@@ -227,19 +227,15 @@ This step ensures that the baseToken will be backed 1-1 on L1.
 
 If the transaction is successful, the `request.l2Value`  will be minted on the `request.l2Contract` address (it can potentially transfer these funds within the transaction).   The rest are minted to the `request.refundRecipient`  address. In case the transaction is not successful, all of the base token will be minted to the `request.refundRecipient` address. These are the same rules as for the zkSync Era.
 
-FIXME: the diagrams below are not relevant
+***Diagram of the L1→L2 transaction flow on L1 for direct user calls, the baseToken can be ETH or an ERC20:***
 
-***Diagram of the L1→L2 transaction flow on L1 when the baseToken is ETH:***
-
-![requestL2TransactionDirect (ETH) (2).png](./L1%20smart%20contracts/requestL2TransactionDirect-ETH.png)
-
-***Diagram of the L1→L2 transaction flow on L1 when the baseToken is an ERC20:***
-
-![requestL2TransactionDirect (ERC20) (3).png](./L1%20smart%20contracts/requestL2TransactionDirect.png)
+![requestL2TransactionDirect (ETH) (2).png](./L1%20smart%20contracts/requestL2TransactionDirect.png)
 
 ***Diagram of the L1→L2 transaction flow on L2 (it is the same regardless of the baseToken):***
 
-![L1-_L2 tx processing on L2.png](./L1%20smart%20contracts/L1-L2%20tx%20processing%20on%20L2.png)
+![requestL2TransactionTwoBridges](./L1%20smart%20contracts/requestL2TransactionTwoBridges_token.png)
+
+![L1-_L2 tx processing on L2.png](./L1%20smart%20contracts/L1_L2_tx_processing_on_L2.png)
 
 ### Limitations of custom base tokens in the first release
 
@@ -306,9 +302,7 @@ This call will return the parameters to call the l2 contract with (the address o
 
 ***Diagram of a depositing ETH onto a chain with USDC as the baseToken. Note that some contract calls (like `USDC.transerFrom` are omitted for the sake of consiceness):***
 
-FIXME: the following diagram is outdated.
-
-![requestL2TransactionTwoBridges (SharedBridge) (1).png](./L1%20smart%20contracts/requestL2TransactionTwoBridges-depositEthToUSDC.png)
+![requestL2TransactionTwoBridges (SharedBridge) (1).png](./L1%20smart%20contracts/requestL2TransactionTwoBridges_depositEthToUSDC.png)
 
 ## Generic usage of `BridgeHub.requestL2TransactionTwoBridges`
 

diff --git a/docs/other/L1 smart contracts/L1-L2 tx processing on L2.png b/docs/other/L1 smart contracts/L1-L2 tx processing on L2.png
diff --git a/docs/other/L1 smart contracts/L1_L2_tx_processing_on_L2.png b/docs/other/L1 smart contracts/L1_L2_tx_processing_on_L2.png
diff --git a/docs/other/L1 smart contracts/Rollup_DA.png b/docs/other/L1 smart contracts/Rollup_DA.png
diff --git a/docs/other/L1 smart contracts/newChain.png b/docs/other/L1 smart contracts/newChain.png
diff --git a/docs/other/L1 smart contracts/requestL2TransactionDirect.png b/docs/other/L1 smart contracts/requestL2TransactionDirect.png
diff --git a/docs/other/L1 smart contracts/requestL2TransactionTwoBridges-depositEthToUSDC.png b/docs/other/L1 smart contracts/requestL2TransactionTwoBridges-depositEthToUSDC.png
diff --git a/docs/other/L1 smart contracts/requestL2TransactionTwoBridges_depositEthToUSDC.png b/docs/other/L1 smart contracts/requestL2TransactionTwoBridges_depositEthToUSDC.png
diff --git a/docs/other/L1 smart contracts/requestL2TransactionTwoBridges_token.png b/docs/other/L1 smart contracts/requestL2TransactionTwoBridges_token.png
diff --git a/docs/other/Rollup DA.md b/docs/other/Rollup DA.md
@@ -23,6 +23,9 @@ Let's see an example of how the approach above works in rollup DA validators.
 
 ## RollupL2DAValidator
 
+![RollupL2DAValidator.png](./L1%20smart%20contracts/Rollup_DA.png)
+
+
 `RollupL2DAValidator` accepts the preimages for the data to publishes as well as their compressed format. After verifying the compression, it forms the `_totalPubdata` bytes array, which represents the entire blob of data that should be published to L1.
 
 It calls the `PubdataChunkPublisher` system contract to split this pubdata into multiple "chunks" of size `4096 * 31` bytes and return the `keccak256` hash of those, These will be the `blobHash` of from the section before.