CDK Reviewing PR#484

Author: EmpieichO

docs/pos/get-started/building-on-polygon.md

@@ -4,9 +4,9 @@ comments: true
 
 Ethereum developers are by default Polygon developers. Welcome. Simply switch to the [Polygon RPC](https://polygon-rpc.com/) and get started. All familiar tools used on Ethereum are supported on Polygon. Whether it is Truffle, Remix or Web3.js, Polygon offers the same UX as Ethereum.
 
-Connect your wallet and deploy any decentralized application to either Polygon Mainnet or Polygon Mumbai Testnet.
+Connect your wallet and deploy any decentralized application to either PoS mainnet or Amoy testnet.
 
-Polygon Mumbai Testnet connects to Ethereum Goërli Testnet, which acts as its ParentChain, a testnet layer 1 (L1).
+Polygon Amoy testnet connects to Ethereum Sepolia testnet, which acts as its parent chain, a testnet layer 1 (L1).
 
 Find all the network-related details in the [network documentation](../reference/rpc-endpoints.md).
 
@@ -61,7 +61,7 @@ const { Alchemy, Network } = require("alchemy-sdk");
 
 const settings = {
   apiKey: "demo", // Can replace with your API Key from https://www.alchemy.com
-  network: Network.MATIC_MAINNET, // Can replace with MATIC_MUMBAI
+  network: Network.MATIC_MAINNET, // Can replace with MATIC_AMOY for testnet config
 };
 
 const alchemy = new Alchemy(settings);

docs/pos/governance/governance-fundamentals.md

@@ -49,7 +49,7 @@ Assuming that the change or upgrade agreed upon via community consensus requires
 1. The protocol decision is made on a PPGC, and implementation begins in the form of modifications to the relevant GitHub repositories.
 2. Core developers create pull requests containing the changes, which can then be merged into the respective code base, and a new [tag](https://github.com/maticnetwork/bor/tags) is created.
 3. Core developers test new releases by deploying them on local devnets. If everything continues to function normally, the tag is marked as "**beta**", which is essentially the "**pre-release**" state.
-4. The modifications and upgrades are rolled out to the Mumbai testnet, and left out to soak for at least one week. Currently, the [Mumbai Testing Committee](https://forum.polygon.technology/t/introducing-mumbai-testing-committee/12970) reports on the stability of the release in the PPGC.
+4. The modifications and upgrades are rolled out to the Amoy testnet, and left out to soak for at least one week. Currently, the Amoy Testing Committee reports on the stability of the release in the PPGC.
 5. Finally, once confirmed that the upgrade doesn't break anything, it is scheduled to be released to mainnet on a PPGC. At this point, the tag version is marked as "**final**".
 6. Validators upgrade their nodes to the latest version after considering the changes. The upgrade is now made canonical via on-chain consensus of the validating stake, including that delegated by token holders. 
 

docs/pos/how-to/bridging/ethereum-polygon/ethereum-to-matic.md

@@ -12,15 +12,15 @@ The Sender and Receiver contract are required to be mapped on Ethereum — [Stat
 
 ---
 
-In the following walkthrough, we'll be deploying a Sender contract on Goerli (Ethereum testnet) and a Receiver contract on Mumbai (Polygon's testnet) and then we'll be sending data from Sender and reading data on Receiver via web3 calls in a node script.
+In the following walkthrough, we'll be deploying a Sender contract on Sepolia (Ethereum testnet) and a Receiver contract on Amoy (Polygon testnet). Then, we'll be sending data from Sender and reading data on Receiver via web3 calls in a node script.
 
 ### 1. Deploy Sender contract
 
 The sole purpose of Sender contract is to be able to call [syncState](https://github.com/maticnetwork/contracts/blob/e999579e9dc898ab6e66ddcb49ee84c2543a9658/contracts/root/stateSyncer/StateSender.sol#L33) function on the StateSender contract — which is Matic's state syncer contract - the StateSynced event of which Heimdall is listening to.
 
 Deployed at:
 
-`0xEAa852323826C71cd7920C3b4c007184234c3945` on Goerli
+`0x49E307Fa5a58ff1834E0F8a60eB2a9609E6A5F50` on Sepolia
 
 `0x28e4F3a7f651294B9564800b2D01f35189A5bFbE` on Ethereum Mainnet
 
@@ -48,7 +48,7 @@ function sendState(bytes calldata data) external {
 }
 ```
 
-In the above function, `stateSenderContract` is the address of the StateSender on the network you'll be deploying `Sender` on. (eg., we'll be using `0xEAa852323826C71cd7920C3b4c007184234c3945` for Goerli), and `receiver` is the contract that will receive the data we send from here.
+In the above function, `stateSenderContract` is the address of the StateSender on the network you'll be deploying `Sender` on. (eg., we'll be using `0x49E307Fa5a58ff1834E0F8a60eB2a9609E6A5F50` for Sepolia), and `receiver` is the contract that will receive the data we send from here.
 
 It is recommended to use constructors to pass in variables, but for the purpose of this demo, we'll simply hardcode these two addresses:
 
@@ -113,7 +113,7 @@ contract receiver {
 
 The function simply assigns the last received State Id and data to variables. [StateId](https://github.com/maticnetwork/contracts/blob/239a91045622ddcf9ebec2cec81fdc6daa3a33e3/contracts/root/stateSyncer/StateSender.sol#L36) is a simple unique reference to the transferred state (a simple counter).
 
-Deploy  your Receiver.sol on Polygon's testnet and keep a note of the address and ABI
+Deploy your `Receiver.sol` to Amoy testnet and keep a note of the address and ABI
 
 ### 3. Getting your Sender and Receiver mapped
 
@@ -133,7 +133,7 @@ We'll first initialise our web3 objects, wallet to make the transactions and con
 const Web3 = require('web3')
 const Network = require("@maticnetwork/meta/network")
 
-const network = new Network ('testnet', 'mumbai')
+const network = new Network ('testnet', 'amoy')
 
 const main = new Web3(network.Main.RPC)
 const matic = new Web3 (network.Matic.RPC)
@@ -243,7 +243,7 @@ This is how our test script looks like:
 const Web3 = require('web3')
 const Network = require("@maticnetwork/meta/network")
 
-const network = new Network ('testnet', 'mumbai')
+const network = new Network ('testnet', 'amoy')
 
 const main = new Web3(network.Main.RPC)
 const matic = new Web3 (network.Matic.RPC)

docs/pos/how-to/bridging/ethereum-polygon/index.md

@@ -1,6 +1,6 @@
 Polygon brings you a trustless two-way transaction channel between Polygon PoS and Ethereum by introducing the cross-chain bridge. The official bridge allows you to transfer tokens between Ethereum and Polygon PoS without incurring third-party risks and market liquidity limitations. 
 
-The official bridge is available on both Mumbai Testnet as well as Polygon PoS Mainnet, and provides a near-instant, low-cost, and flexible bridging option for both users and dApp developers. You can access it and bridge assets from Ethereum over to Polygon PoS using [Polygon Portal](https://portal.polygon.technology).
+The official bridge is available on both PoS Amoy testnet as well as mainnet, and provides a near-instant, low-cost, and flexible bridging option for both users and dApp developers. You can access it and bridge assets from Ethereum over to Polygon PoS using [Polygon Portal](https://portal.polygon.technology).
 
 !!! tip "Polygon Portal"
 

docs/pos/how-to/bridging/ethereum-polygon/matic-to-ethereum.md

@@ -4,7 +4,7 @@ comments: true
 
 Mechanism for transferring data from Polygon to Ethereum is a little different from doing the same for Ethereum to Polygon. The **checkpoint** transactions created by the Validators on the Ethereum chain are used for achieving this. Basically a transaction is initially created on Polygon. While creating this transaction it has to be ensured that an **event is emitted** and the **event logs includes the data we wish to transfer** from Polygon to Ethereum.
 
-In a period of time ( about 10-30 mins ), this transaction is check-pointed on the Ethereum chain by the validators. Once checkpointing is done, the hash of the transaction created on the Polygon chain can be submitted as a proof on the **RootChainManager** contract on the Ethereum chain. This contract, validates the transaction, verifies that this transaction is included in the checkpoint and finally decodes the event logs from this transaction.
+Within a timeframe of approximately 10 to 30 minutes, this transaction is check-pointed on the Ethereum chain by the validators. Once checkpointing is complete, the hash of the transaction created on the Polygon chain can be submitted as a proof on the **RootChainManager** contract on the Ethereum chain. This contract, validates the transaction, verifies that this transaction is included in the checkpoint and finally decodes the event logs from this transaction.
 
 Once this phase is over, we can use the **decoded event log data to perform any change** on the root contract deployed on the Ethereum chain. For this we also need to ensure that, the change of state on Ethereum is only done in a secure way. Hence, we make use of a **Predicate** contract which is a special type of contract that can be only triggered by the **RootChainManager** contract. This architecture ensures that the state changes on Ethereum happens only when the transaction on Polygon is check pointed and verified on the Ethereum chain by the **RootChainManager** contract.
 

docs/pos/how-to/bridging/l1-l2-communication/state-transfer.md

@@ -27,43 +27,44 @@ Use the `FxBaseChildTunnel` contract from [here](https://github.com/jdkanani/fx-
 
 - You need to inherit `FxBaseRootTunnel` contract in your root contract on Ethereum. As an example, you can follow this [contract](https://github.com/jdkanani/fx-portal/blob/main/contracts/examples/state-transfer/FxStateRootTunnel.sol) . Similarly, inherit `FxBaseChildTunnel` contract in your child on Polygon. Follow this [contract](https://github.com/jdkanani/fx-portal/blob/main/contracts/examples/state-transfer/FxStateChildTunnel.sol) as an example.
 - While deploying your root contract on
-  - **Goerli Testnet**, pass the address of `_checkpointManager` as **0x2890bA17EfE978480615e330ecB65333b880928e** and `_fxRoot` as **0x3d1d3E34f7fB6D26245E6640E1c50710eFFf15bA**.
+  - **Sepolia testnet**, pass the address of `_checkpointManager` as **0xbd07D7E1E93c8d4b2a261327F3C28a8EA7167209** and `_fxRoot` as **0x0E13EBEdDb8cf9f5987512d5E081FdC2F5b0991e**.
 
   - **Ethereum Mainnet**, `_checkpointManager` is **0x86e4dc95c7fbdbf52e33d563bbdb00823894c287** and `_fxRoot` is **0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2**.
-- For deploying the child contract on **Mumbai testnet**, pass **0xCf73231F28B7331BBe3124B907840A94851f9f11** as `_fxChild` in constructor. For **Polygon mainnet,** `_fxChild` will be **0x8397259c983751DAf40400790063935a11afa28a**.
-- Call `setFxChildTunnel` on deployed root tunnel with the address of child tunnel. Example: [0x79cd30ace561a226258918b56ce098a08ce0c70707a80bba91197f127a48b5c2](https://goerli.etherscan.io/tx/0x79cd30ace561a226258918b56ce098a08ce0c70707a80bba91197f127a48b5c2)
-- Call `setFxRootTunnel` on deployed child tunnel with address of root tunnel. Example: [0xffd0cda35a8c3fd6d8c1c04cd79a27b7e5e00cfc2ffc4b864d2b45a8bb7e98b8](https://mumbai.polygonscan.com/tx/0xffd0cda35a8c3fd6d8c1c04cd79a27b7e5e00cfc2ffc4b864d2b45a8bb7e98b8/internal-transactions)
+- For deploying the child contract on **Amoy testnet**, pass **0xE5930336866d0388f0f745A2d9207C7781047C0f** as `_fxChild` in constructor. For **Polygon mainnet,** `_fxChild` will be **0x8397259c983751DAf40400790063935a11afa28a**.
+- Call `setFxChildTunnel` on deployed root tunnel with the address of child tunnel. Example: [0x97482d379e397329ac1ee2a34eeb9aceb06bd4a91ec17c7d7d3da4a1e96c165c](https://sepolia.etherscan.io/tx/0x97482d379e397329ac1ee2a34eeb9aceb06bd4a91ec17c7d7d3da4a1e96c165c)
+- Call `setFxRootTunnel` on deployed child tunnel with address of root tunnel. Example: [0xae30445301bd7c902bf373fb890faf5658bd3a9437131c9408d5ecbc41af3fc0](https://amoy.polygonscan.com/tx/0xae30445301bd7c902bf373fb890faf5658bd3a9437131c9408d5ecbc41af3fc0)
 
-## Example Contracts of State Transfer Bridge
+## State tunnel sample contracts
 
 - **Contracts**: [Fx-Portal Github Repository](https://github.com/jdkanani/fx-portal/tree/main/contracts/tunnel)
-- **Goerli:** [0xc4432e7dab6c1b43f4dc38ad2a594ca448aec9af](https://goerli.etherscan.io/address/0xc4432e7dab6c1b43f4dc38ad2a594ca448aec9af)
-- **Mumbai:** [0xa0060Cc969d760c3FA85844676fB654Bba693C22](https://mumbai.polygonscan.com/address/0xa0060Cc969d760c3FA85844676fB654Bba693C22/transactions)
+- **Sepolia:** [0x1707157b9221204869ED67705e42fB65e026586c](https://sepolia.etherscan.io/address/0x1707157b9221204869ED67705e42fB65e026586c)
+- **Amoy:** [0xf5D2463d0176462d797Afcd57eC477b7B0CcBE70](https://amoy.polygonscan.com/address/0xf5D2463d0176462d797Afcd57eC477b7B0CcBE70)
 
 ## State Transfer from Ethereum → Polygon
 
-- You need to call `_sendMessageToChild()` internally in your root contract and pass the data as an argument to be sent to Polygon. Example: [0x28705fcae757a0c88694bd167cb94a2696a0bc9a645eb4ae20cff960537644c1](https://goerli.etherscan.io/tx/0x28705fcae757a0c88694bd167cb94a2696a0bc9a645eb4ae20cff960537644c1)
+- You need to call `_sendMessageToChild()` internally in your root contract and pass the data as an argument to be sent to Polygon. Example: [0x00a1aa71593fec825b4b1ce1081b5a9848612fb21f9e56def2914b483f5f34f5](https://sepolia.etherscan.io/tx/0x00a1aa71593fec825b4b1ce1081b5a9848612fb21f9e56def2914b483f5f34f5)
 - In your child contract, implement `_processMessageFromRoot()` virtual function in `FxBaseChildTunnel` to retrieve data from Ethereum. The data will be received automatically from the state receiver when the state is synced.
 
 ## State Transfer from Polygon → Ethereum
 
-1. Call `_sendMessageToRoot()` internally in your child contract with data as a parameter to be sent to Ethereum. Example: [0x3cc9f7e675bb4f6af87ee99947bf24c38cbffa0b933d8c981644a2f2b550e66a](https://mumbai.polygonscan.com/tx/0x3cc9f7e675bb4f6af87ee99947bf24c38cbffa0b933d8c981644a2f2b550e66a/logs)
+1. Call `_sendMessageToRoot()` internally in your child contract with data as a parameter to be sent to Ethereum. Note down the transaction hash as it will be used to generate the proof after the transaction has been included as a checkpoint.
 
-  Note the transaction hash as it will be used to generate proof after it has been included as a checkpoint.
+2. **Proof Generation to complete the exit on root chain**: Generate the proof using the **tx hash** and **MESSAGE_SENT_EVENT_SIG**. To generate the proof, you can either use the proof generation API hosted by Polygon, or you can also spin up your own proof generation API by following the instructions [here](https://github.com/maticnetwork/proof-generation-api).
 
-2. **Proof Generation to complete the exit on root chain**: Generate the proof using the **tx hash** and **MESSAGE_SENT_EVENT_SIG**. To generate the proof, you can either use the proof generation API hosted by Polygon or you can also spin up your own proof generation API by following the instructions [here](https://github.com/maticnetwork/proof-generation-api).
+  The proof generation endpoint hosted by Polygon is available here:
+  
+  - [Mainnet](https://proof-generator.polygon.technology/api/v1/matic/exit-payload/{burnTxHash}?eventSignature={eventSignature})
+  - [Testnet](https://proof-generator.polygon.technology/api/v1/amoy/exit-payload/{burnTxHash}?eventSignature={eventSignature})
 
-  The proof generation endpoint hosted by Polygon is available [here](https://proof-generator.polygon.technology/api/v1/matic/exit-payload/{burnTxHash}?eventSignature={eventSignature}).
+Here, 
 
-    - `burnTxHash` is the transaction hash of the `_sendMessageToRoot()` transaction you initiated on Polygon.
-    - `eventSignature` is the event signature of the event emitted by the `_sendMessageToRoot()` function. The event signature for the MESSAGE_SENT_EVENT_SIG is `0x8c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036`.
+- `burnTxHash` is the transaction hash of the `_sendMessageToRoot()` transaction you initiated on Polygon.
+- `eventSignature` is the event signature of the event emitted by the `_sendMessageToRoot()` function. The event signature for the MESSAGE_SENT_EVENT_SIG is `0x8c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036`.
 
-  The proof generation API usage examples for the Mainnet and Testnet are as follows:-
-
-  → [Mumbai Testnet Proof generation](https://proof-generator.polygon.technology/api/v1/mumbai/exit-payload/0x4756b76a9611cffee3d2eb645819e988c34615621ea256f818ab788d81e1f838?eventSignature=0x8c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036)
+  Here's an example of how to use the proof generation API:
 
   → [Polygon Mainnet Proof generation](https://proof-generator.polygon.technology/api/v1/matic/exit-payload/0x70bb6dbee84bd4ef1cd1891c666733d0803d81ac762ff7fdc4726e4525c1e23b?eventSignature=0x8c5261668696ce22758910d05bab8f186d6eb247ceac2af2e82c7dc17669b036)
 
-3. Implement `_processMessageFromChild()` in your root contract.
+1. Implement `_processMessageFromChild()` in your root contract.
 
-4. Use the generated proof as an input to `receiveMessage()` to retrieve data sent from child tunnel into your contract. Example: [0x436dcd500659bea715a09d9257295ddc21290769daeea7f0b666166ef75e3515](https://goerli.etherscan.io/tx/0x436dcd500659bea715a09d9257295ddc21290769daeea7f0b666166ef75e3515) )
+2. Use the generated proof as an input to `receiveMessage()` to retrieve data sent from child tunnel into your contract.