Address reviewers comments

immutable · Jul 9, 2024 · f6f8f10 · f6f8f10
1 parent d00eab3
commit f6f8f10
Showing 1 changed file with 6 additions and 5 deletions.
diff --git a/docs/manual-bridging.md b/docs/manual-bridging.md
@@ -11,7 +11,7 @@
       * [Depositing Token](#depositing-token)
     * [Depositing ETH](#depositing-eth)
   * [Withdrawing Assets](#withdrawing-assets)
-    * [ERC-20 Token](#erc-20-token)
+    * [Withdrawing ERC-20 Token](#withdrawing-erc-20-token)
     * [Withdrawing IMX](#withdrawing-imx)
   * [Estimating Bridge Fee](#estimating-bridge-fee)
   * [Resources](#resources)
@@ -99,10 +99,10 @@ The process outlined below is for the withdrawal step of the transaction.
     - `childToken` : Address of ERC-20 contract on L2
     - `amount`: Amount to transfer in the base unit of the token e.g. 10ETH would be represented as `10000000000000000000`, because ETH uses 18 decimals, whereas 10USDC would be represented as `10000000`, because USDC uses 6 decimals.
    - `native IMX`: Bridge fee estimate in ETH (see [Estimating Bridge Fee](#estimating-bridge-fee) for details)
-    - **Note:** The `withdraw()` function will transfer funds to the same address on L2 as the sender executing this transaction on L1. If however, you’d like to deposit to a different address use the `withdrawTo` function, which will take an additional parameter `receiver` which is the address of the receiver on L2.
-- The transaction will first transfer and burn (except for wIMX) the specified amount of ERC-20 from the user to the bridge and perform a cross-chain call to the L1 to unlock a corresponding amount of tokens to the intended receiver address.
+    - **Note:** The `withdraw()` function will transfer funds to the same address on L1 as the sender executing this transaction on L2. If, however, you would like to withdraw to a different address, use the `withdrawTo` function, which will take an additional parameter `receiver` which is the address of the receiver on L1.
+- The transaction will burn (except for wIMX) the specified amount of ERC-20 from the user's balance and perform a cross-chain call to the L1 to unlock a corresponding amount of tokens to the intended receiver address.
 - This process can take about 20 minutes to complete on the destination chain. You can track the progress of this cross-chain call by going to Axelarscan ([mainnet](https://axelarscan.io/), [testnet](https://testnet.axelarscan.io/)) and providing the transaction hash in the search field at the top right.
-- Additionally, for newly mapped tokens or tokens for which bridge flow rate parameters have not been configured, the token will be queued for an additional 24 hours before it can be claimed by the user. See [here](https://github.com/immutable/zkevm-bridge-contracts/blob/main/docs/high-level-architecture.md#withdrawal-delays) for more details. After the delay has elapsed a user will have to claim their funds on the L1 bridge by calling `finaliseQueuedWithdrawal()` on the [root bridge proxy contract](https://github.com/immutable/zkevm-bridge-contracts/blob/main/docs/high-level-architecture.md#withdrawal-delays), and providing the `receiver` address used during the withdrawal and an index number of the queued withdrawal (starting from 0 for the first queued withdrawal for the specific recipient).
+- Additionally, for newly mapped tokens for which [bridge flow rate parameters](https://github.com/immutable/zkevm-bridge-contracts?tab=readme-ov-file#flow-rate-parameters) have not been configured, the token will be queued for an additional 24 hours before it can be claimed by the user. Similarly, if the withdrawal exceeds the defined [flow rate thresholds](https://github.com/immutable/zkevm-bridge-contracts?tab=readme-ov-file#flow-rate-parameters) for the bridge, the withdrawal will be queued. See [here](https://github.com/immutable/zkevm-bridge-contracts/blob/main/docs/high-level-architecture.md#withdrawal-delays) for more details. After the delay has elapsed a user will have to claim their funds on the L1 bridge by calling `finaliseQueuedWithdrawal()` on the [root bridge proxy contract](https://github.com/immutable/zkevm-bridge-contracts/blob/main/docs/high-level-architecture.md#withdrawal-delays), and providing the `receiver` address used during the withdrawal and an index number of the queued withdrawal (starting from 0 for the first queued withdrawal for the specific recipient). You can use the `getPendingWithdrawalsLength()` and the `getPendingWithdrawals()` functions to get the number of pending withdrawals for a given receiver address and the details of each pending withdrawal respectively.
 
 ### Withdrawing IMX
 - Navigate to the Child bridge contract on Blockscout ([mainnet](https://explorer.immutable.com/address/0xBa5E35E26Ae59c7aea6F029B68c6460De2d13eB6), [testnet](https://explorer.testnet.immutable.com/address/0x0D3C59c779Fd552C27b23F723E80246c840100F5))
@@ -114,7 +114,8 @@ The process outlined below is for the withdrawal step of the transaction.
       - Bridge fee estimate in ETH (see [Estimating Bridge Fee](#estimating-bridge-fee) for details)
     - **Note:** The `withdrawIMX()` function will transfer funds to the same address on L1 as the sender executing this transaction on L2. If however, you’d like to deposit to a different address use the `withdrawToIMX`function, which will take an additional parameter `receiver` which is the address of the receiver on L1.
 - This process can take ~20minutes to be completed on the destination chain. You can track the progress of this cross-chain call by going to Axelarscan ([mainnet](https://axelarscan.io/), [testnet](https://testnet.axelarscan.io/)) and providing the transaction hash in the search field at the top right.
-- Once completed, the funds will be available in the recipient's address on L1. Note that whether you deposit native IMX using this method or wrapped IMX via the ERC-20 token deposit method, the same IMX token will be received on L1.
+- Once completed, the funds will be available in the recipient's address on L1. Note that whether you withdraw native IMX using this method or wrapped IMX via the ERC-20 token withdraw method, the same IMX token will be received on L1.
+- Note that if the withdrawal exceeds the defined [flow rate thresholds](https://github.com/immutable/zkevm-bridge-contracts?tab=readme-ov-file#flow-rate-parameters) for the bridge, the withdrawal will be queued for 24 hours before it can be claimed by the user. See [here](https://github.com/immutable/zkevm-bridge-contracts/blob/main/docs/high-level-architecture.md#withdrawal-delays) for more details. After the delay has elapsed a user will have to claim their funds on the L1 bridge by calling `finaliseQueuedWithdrawal()` on the [root bridge proxy contract](https://github.com/immutable/zkevm-bridge-contracts/blob/main/docs/high-level-architecture.md#withdrawal-delays), and providing the `receiver` address used during the withdrawal and an index number of the queued withdrawal (starting from 0 for the first queued withdrawal for the specific recipient). You can use the `getPendingWithdrawalsLength()` and the `getPendingWithdrawals()` functions to get the number of pending withdrawals for a given receiver address and the details of each pending withdrawal respectively.
 
 ## Estimating Bridge Fee
 Estimates for bridge fees are obtained through Axelar's API. These fees encompass the costs for Axelar validators to validate transactions, as well as the gas costs incurred when executing a transaction on the destination chain.