Router chain to Router Chain

.github/CONTRIBUTING.md

@@ -1,6 +1,6 @@
 The following information provides a set of guidelines for contributing to the Router Docs repo. Use your best judgment, and, if you see room for improvement, please propose changes to this document.
 
-Contributions come in the form of writing documentation, raising issues, and any other actions that help develop the Router chain documentation.
+Contributions come in the form of writing documentation, raising issues, and any other actions that help develop the Router Chain documentation.
 
 ## Just want to ask a question?
 

docs/develop/README.mdx

@@ -82,7 +82,7 @@ the best cross-chain framework for your dApp.
   />
  <Card
     title="Router Chain Guides"
-    description="Learning how to execute different types of cross-chain requests from or to Router chain"
+    description="Learning how to execute different types of cross-chain requests from or to Router Chain"
     to="/develop/message-transfer-via-crosstalk/router-chain-guides"
     icon={<ModulesIcon />}
   />
@@ -126,7 +126,7 @@ the best cross-chain framework for your dApp.
   />
   <Card
   title="Router Chain"
-  description="Understanding the crosstalk functions for Router chain"
+  description="Understanding the crosstalk functions for Router Chain"
   to="/develop/message-transfer-via-crosstalk/router-chain-guides/iDapp-functions"
   icon={<RouterIcon />}
   />

docs/develop/asset-transfer-via-nitro/building-cross-chain-tokens/building-a-cross-chain-token-using-router.md

@@ -47,4 +47,4 @@ Once you have deployed the token on Chain A and you want to integrate this token
 2. Mint the required supply of the deployed token.
 3. For each chain on which you want to integrate the token, create wrapped tokens or mirror tokens.
 4. Whitelist the token on the source chain AssetBridge contract.
-5. Reach out to the Router team [here](https://t.me/Alpie01). The Router team will handle the AssetBridge contract configuration on the Router chain. Additionally, the Router team will set up the pathfinder Nitro API configurations and update the user interface (UI) as well as the Router Explorer to incorporate the new token.
+5. Reach out to the Router team [here](https://t.me/Alpie01). The Router team will handle the AssetBridge contract configuration on the Router Chain. Additionally, the Router team will set up the pathfinder Nitro API configurations and update the user interface (UI) as well as the Router Explorer to incorporate the new token.

docs/develop/asset-transfer-via-nitro/building-cross-chain-tokens/building-an-xerc20-compatible-cross-chain-token.md

@@ -12,4 +12,4 @@ Deploy an xERC20 contract on one chain (any chain based on your preference) and
 2. Mint the required supply of the deployed token.
 3. For each chain on which you want to integrate the token, create wrapped tokens or mirror tokens.
 4. Whitelist the token on the source chain AssetBridge contract.
-5. Reach out to the Router team [here](https://t.me/Alpie01). The Router team will handle the AssetBridge contract configuration on the Router chain. Additionally, the Router team will set up the pathfinder Nitro API configurations and update the user interface (UI) as well as the Router Explorer to incorporate the new token.
+5. Reach out to the Router team [here](https://t.me/Alpie01). The Router team will handle the AssetBridge contract configuration on the Router Chain. Additionally, the Router team will set up the pathfinder Nitro API configurations and update the user interface (UI) as well as the Router Explorer to incorporate the new token.

docs/develop/asset-transfer-via-nitro/building-cross-chain-tokens/extending-an-existing-token-to-multiple-chains.md

@@ -28,4 +28,4 @@ For example, consider that ROUTE token is natively present on Ethereum and Polyg
 To facilitate the cross-chain transfer of the token, it must be whitelisted on the AssetBridge contracts. This will allow the bridge to recognize and handle the token transfer.
 
 ### 5. Further Configurations
-Reach out to the Router team [here](https://t.me/Alpie01). The Router team will handle the AssetBridge contract configuration on the Router chain. Additionally, the Router team will set up the pathfinder Nitro API configurations and update the user interface (UI) as well as the Router Explorer to incorporate the new token.
+Reach out to the Router team [here](https://t.me/Alpie01). The Router team will handle the AssetBridge contract configuration on the Router Chain. Additionally, the Router team will set up the pathfinder Nitro API configurations and update the user interface (UI) as well as the Router Explorer to incorporate the new token.

docs/develop/asset-transfer-via-nitro/different-flows/transfer-usdc-with-instruction-via-circle.md

@@ -78,8 +78,8 @@ function depositUsdcMessage(
 
 1. **iSend Fee**
 
-   - **Description:** A very small fee to prevent sybil attack on Router chain via the source Gateway contract.
-   - **Purpose:** To prevent sybil attack on Router chain.
+   - **Description:** A very small fee to prevent sybil attack on Router Chain via the source Gateway contract.
+   - **Purpose:** To prevent sybil attack on Router Chain.
    - **Calculation:** This is a very low amount just to deter fake request creators.
    - **Denomination:** It is paid in native token of the source chain.
 

docs/develop/asset-transfer-via-nitro/high-level-workflow.md

@@ -21,23 +21,23 @@ In the case of Nitro, under the reverse verification flow, we use permissionless
 
 **Step 3a)** A forwarder will listen to the `CrosschainTransferRequest` event
 
-**Step 3b)** Orchestrators on the Router chain will also listen to the `CrosschainTransferRequest` event and submit it to the Router chain with their attestation.
+**Step 3b)** Orchestrators on the Router Chain will also listen to the `CrosschainTransferRequest` event and submit it to the Router Chain with their attestation.
 
 **Step 4)** The forwarder will create a hash of the fields included in the event and submit a transaction to the destination chain Nitro contract. The hash acts as a unique identifier for the `CrosschainTransferRequest`.
 
-**Step 4b)** After 2/3+1 validation, the Router chain will invoke the middleware Nitro contract with the event info. Upon receiving the `CrosschainTransferRequest` event, the middleware contract will persist the request (mapping to the request will be maintained using the hash of the fields included in the event).
+**Step 4b)** After 2/3+1 validation, the Router Chain will invoke the middleware Nitro contract with the event info. Upon receiving the `CrosschainTransferRequest` event, the middleware contract will persist the request (mapping to the request will be maintained using the hash of the fields included in the event).
 
 **Step 5)** Upon receiving the tx, the Nitro contract on the destination chain will (a) transfer the defined amount from the forwarder address to the receiver address; (b) persist the hash in the status map (to skip the replays); (c) emit a `CrosschainTransferExecuted` event confirming the execution. The event includes: 
 - `ChainId`
 - `EventNonce`
 - `hash`
 - `ForwarderAddress`
 
-**Step 6)** Orchestrators on the Router chain listen to the `CrosschainTransferExecuted` event from the destination chain Nitro contract and submit it to the Router chain with their attestation.
+**Step 6)** Orchestrators on the Router Chain listen to the `CrosschainTransferExecuted` event from the destination chain Nitro contract and submit it to the Router Chain with their attestation.
 
-**Step 7)** Upon 2/3+1 validation, the Router chain will invoke the middleware Nitro contract with the event info. Upon receiving the `CrosschainTransferExecuted` event, the middleware contract will mark the request as **Completed** and persist the Forwarder address and amount.
+**Step 7)** Upon 2/3+1 validation, the Router Chain will invoke the middleware Nitro contract with the event info. Upon receiving the `CrosschainTransferExecuted` event, the middleware contract will mark the request as **Completed** and persist the Forwarder address and amount.
 
-**Step 8)** Once the request is marked as completed, the forwarder can claim its (funds + reward) by triggering an outbound request. The outbound request gets processed via the Router chain and existing Gateway contracts. The Gateway contract will invoke the source chain Nitro contract, which will settle the funds for forwarder.
+**Step 8)** Once the request is marked as completed, the forwarder can claim its (funds + reward) by triggering an outbound request. The outbound request gets processed via the Router Chain and existing Gateway contracts. The Gateway contract will invoke the source chain Nitro contract, which will settle the funds for forwarder.
 
 ## Burn and Mint Flow
 
@@ -47,11 +47,11 @@ In the case of Nitro, under the reverse verification flow, we use permissionless
 
 **Step 2)** The Nitro contract will validate the request, deduct funds from the user's account, burn them, and invoke the `iSend()` function on the Router Gateway contract.
 
-**Step 3)** The Gateway contract on the source chain emits an event that is listened to by the orchestrators on the Router chain.
+**Step 3)** The Gateway contract on the source chain emits an event that is listened to by the orchestrators on the Router Chain.
 
-**Step 4)** Orchestrators on the Router chain will listen to the `CrosschainRequest` event and submit it to the Router chain with their attestation.
+**Step 4)** Orchestrators on the Router Chain will listen to the `CrosschainRequest` event and submit it to the Router Chain with their attestation.
 
-**Step 5)** After 2/3+1 validation, the Router chain will invoke the middleware Nitro contract with the event info. Upon receiving the `CrosschainRequest` event, the middleware contract will validate the request, generate an outgoing request from the Router chain to the destination chain, and pay the fees associated with the outgoing request.
+**Step 5)** After 2/3+1 validation, the Router Chain will invoke the middleware Nitro contract with the event info. Upon receiving the `CrosschainRequest` event, the middleware contract will validate the request, generate an outgoing request from the Router Chain to the destination chain, and pay the fees associated with the outgoing request.
 
 **Step 6)** Once the outbound request initiated by the Nitro bridge contract is validated by the orchestrators, a Nitro relayer picks it up and forwards the event to the Router Gateway contract on the destination chain.
 

docs/develop/message-transfer-via-crosstalk/README.mdx

@@ -72,7 +72,7 @@ This section of the documentation will provide an in-depth view of the CrossTalk
   />
  <Card
     title="Router-chain-Guides"
-    description="Learning how to execute different types of cross-chain requests from or to Router chain"
+    description="Learning how to execute different types of cross-chain requests from or to Router Chain"
     to="message-transfer-via-crosstalk/router-chain-guides"
     icon={<ModulesIcon />}
   />
@@ -117,7 +117,7 @@ This section of the documentation will provide an in-depth view of the CrossTalk
 
   <Card
   title="Router Chain Guide"
-  description="Understanding the crosstalk functions for Router chain"
+  description="Understanding the crosstalk functions for Router Chain"
   to="message-transfer-via-crosstalk/router-chain-guides/iDapp-functions"
   icon={<RouterIcon />}
   />

docs/develop/message-transfer-via-crosstalk/evm-guides/asm-implementation/README.md

@@ -36,11 +36,11 @@ In this function selector, there are 6 arguments. Within this function, any poss
 
 **1) `requestIdentifier` -** A unique identifier of the request. It is added by the source chain's Gateway contract.
 
-**2) `requestTimestamp` -** Timestamp when a request is added/verified on the Router chain.
+**2) `requestTimestamp` -** Timestamp when a request is added/verified on the Router Chain.
 
 **3) `requestSender` -** Address of the application's contract on the source chain in string format.
 
-**4) `srcChainId` -** Network ID of the chain from which the request to the Router chain was initiated.
+**4) `srcChainId` -** Network ID of the chain from which the request to the Router Chain was initiated.
 
 **5) `packet` -** This is the payload, i.e., the data to be transferred to the destination chain.
 

docs/develop/message-transfer-via-crosstalk/evm-guides/asm-implementation/sample-delayed-execution-asm-contract.md

@@ -54,7 +54,7 @@ contract DelayASM is IAdditionalSecurityModule {
 }
 ```
 
-- The owner of the ASM contract can set the `delayPeriod`, which is the period that must pass before transactions can be executed on the destination contract once they have been validated on the Router chain.
+- The owner of the ASM contract can set the `delayPeriod`, which is the period that must pass before transactions can be executed on the destination contract once they have been validated on the Router Chain.
 
 ```javascript
   function setDelayPeriod(uint256 _delayPeriod) external {

docs/develop/message-transfer-via-crosstalk/evm-guides/cross-chain-read-requests/sample-read-request-contract.md

@@ -76,7 +76,7 @@ function setDappMetadata(
   }
 ```
 
-To allow your dApp to send cross-chain transactions, you must specify the fee payer address on the Router chain. This can be done by calling the `setDappMetadata` function on the Gateway contract, and passing the fee payer address as a parameter. Once the fee payer address is set, the fee payer must provide approval on the Router chain to confirm their willingness to pay fees for your dApp.
+To allow your dApp to send cross-chain transactions, you must specify the fee payer address on the Router Chain. This can be done by calling the `setDappMetadata` function on the Gateway contract, and passing the fee payer address as a parameter. Once the fee payer address is set, the fee payer must provide approval on the Router Chain to confirm their willingness to pay fees for your dApp.
 
 It's important to note that any fee refunds will be credited to the fee payer address specified in the `setDappMetadata` function.
 

docs/develop/message-transfer-via-crosstalk/evm-guides/iDapp-functions/iSend.md

@@ -137,13 +137,13 @@ function getRequestMetadata(
    });
    ```
 
-   To avoid the need for calculation, it can be passed as 0. The Router chain will then estimate the real-time gas price for them.
+   To avoid the need for calculation, it can be passed as 0. The Router Chain will then estimate the real-time gas price for them.
 
 **5.3) `ackGasLimit` -** Gas limit required for the execution of the acknowledgment on the source chain. This can be calculated using tools like [hardhat-gas-reporter](https://www.npmjs.com/package/hardhat-gas-reporter).
 
-**5.4) `ackGasPrice` -** Gas price of the source chain. This can be calculated using the RPC of source chain as shown in the above [snippet](#5-requestmetadata). To avoid the need for calculation, it can be passed as 0. The Router chain will then estimate the real-time gas price for them.
+**5.4) `ackGasPrice` -** Gas price of the source chain. This can be calculated using the RPC of source chain as shown in the above [snippet](#5-requestmetadata). To avoid the need for calculation, it can be passed as 0. The Router Chain will then estimate the real-time gas price for them.
 
-**5.5) `relayerFees` -** This parameter functions similarly to the priority fees on other blockchain networks. Since the Router chain relayers handle the execution of cross-chain requests on the destination chain, setting a higher `relayerFees` will increase the likelihood of your request being prioritized by relayers. If a very low `relayerFees` is provided, the Router chain will automatically adjust it to the minimum required amount to ensure that it is executed. If it is passed as 0, the Router chain will default it to the minimum set Relayer fee value. 
+**5.5) `relayerFees` -** This parameter functions similarly to the priority fees on other blockchain networks. Since the Router Chain relayers handle the execution of cross-chain requests on the destination chain, setting a higher `relayerFees` will increase the likelihood of your request being prioritized by relayers. If a very low `relayerFees` is provided, the Router Chain will automatically adjust it to the minimum required amount to ensure that it is executed. If it is passed as 0, the Router Chain will default it to the minimum set Relayer fee value. 
 
 Minimum relayer fees based on network is given below -
 <RelayerAPIData
@@ -154,7 +154,7 @@ Minimum relayer fees based on network is given below -
 <p style={{ marginBottom: '30px' }}></p>
 
 
-**5.6) `ackType` -** When the contract calls have been executed on the destination chain, the destination chain Gateway contract sends an acknowledgent back to the Router chain. iDapps have the option to get this acknowledgment from the Router chain to the source chain and execute some operations based on the ack.
+**5.6) `ackType` -** When the contract calls have been executed on the destination chain, the destination chain Gateway contract sends an acknowledgent back to the Router Chain. iDapps have the option to get this acknowledgment from the Router Chain to the source chain and execute some operations based on the ack.
    - If `ackType` = 0, the user doesn't want the acknowledgment to be forwarded back to the source chain.
    - If `ackType` = 1, the acknowledgment is expected to be received only if the calls were successfully executed on the destination chain, and the user intends to perform some operation on the source chain after receiving the ack.
    - If `ackType` = 2, an acknowledgment is needed only in case of an error occurring on the destination chain. This options also allows for execution of certain operations after receiving the ack.

docs/develop/message-transfer-via-crosstalk/evm-guides/iDapp-functions/setDappMetadata.md

@@ -11,6 +11,6 @@ function setDappMetadata(
     ) external returns (uint64)
 ```
 
-- To facilitate cross-chain transactions, it is necessary to pay the fees on the Router chain. This can be achieved using the `setDappMetadata` function available in the Gateway contracts. The function takes a `feePayerAddress` parameter, which represents the account responsible for covering the transaction fees for any cross-chain requests originating from the dApp.
-- Once the `feePayerAddress` is set, the designated fee payer must approve the request to act as the fee payer on the Router chain. Without this approval, dApps will not be able to execute any cross-chain transactions.
-- It's important to note that any fee refunds resulting from these transactions will be credited back to the dApp's `feePayerAddress` on the Router chain.
+- To facilitate cross-chain transactions, it is necessary to pay the fees on the Router Chain. This can be achieved using the `setDappMetadata` function available in the Gateway contracts. The function takes a `feePayerAddress` parameter, which represents the account responsible for covering the transaction fees for any cross-chain requests originating from the dApp.
+- Once the `feePayerAddress` is set, the designated fee payer must approve the request to act as the fee payer on the Router Chain. Without this approval, dApps will not be able to execute any cross-chain transactions.
+- It's important to note that any fee refunds resulting from these transactions will be credited back to the dApp's `feePayerAddress` on the Router Chain.

docs/develop/message-transfer-via-crosstalk/evm-guides/your-first-crosschain-nft-contract/deploying-your-nft-contract.md

@@ -108,7 +108,7 @@ Lets say if you want to deploy your contract on Polygon Mumbai and Avalanche Fuj
 />
 
 :::info
-You can pass your own address (either your `0x` address or the corresponding Router chain address) as the `feePayerAddress`. Just make sure you have funds on the Router chain testnet. If not, you can get funds from our [faucet](https://faucet.routerprotocol.com/).
+You can pass your own address (either your `0x` address or the corresponding Router Chain address) as the `feePayerAddress`. Just make sure you have funds on the Router Chain testnet. If not, you can get funds from our [faucet](https://faucet.routerprotocol.com/).
 :::
 
 <p style={{ marginBottom: '50px' }}></p>

docs/develop/message-transfer-via-crosstalk/helpful-repositories.md

@@ -6,6 +6,6 @@ sidebar_position: 9
 Some repos have been provided below for reference to ease your development efforts while building an iDapp:
 
 * [This repo](https://github.com/router-protocol/cw-bridge-contracts) contains some examples to create outbound requests in different scenarios.
-* [This repo](https://github.com/router-protocol/generic-cc-data-transfer) contains a generic cross-chain data transfer example. Both the dApp implementation on external chains and application bridge contract (middleware contract) implementation on the Router chain have been provided in this repo.
+* [This repo](https://github.com/router-protocol/generic-cc-data-transfer) contains a generic cross-chain data transfer example. Both the dApp implementation on external chains and application bridge contract (middleware contract) implementation on the Router Chain have been provided in this repo.
 * [This repo](https://github.com/router-protocol/cw-bridge-contract-template) includes a template for an application bridge contract.