fix conflicts

Author: kmurphypolygon

README.md

@@ -71,6 +71,7 @@ docker compose up
 
 ## The team
 
-- Anthony Matlala (@EmpieichO)
-- Katharine Murphy (@kmurphypolygon)
-- Hans (@hsutaiyu) 
+- Anthony Matlala [(@EmpieichO)](https://github.com/EmpieichO)
+- Hans Bodani [(@hsutaiyu)](https://github.com/hsutaiyu)
+- Katharine Murphy [(@kmurphypolygon)](https://github.com/kmurphypolygon)
+ 

docs/cdk/concepts/blocks.md

@@ -1,56 +1,64 @@
 # Batches, blocks, and transactions
 
-The following definition are key to understanding how transactions are handled on L2s built with the CDK:
+The following definitions are key to understanding how transactions are handled on L2s built with the CDK:
 
 - Transaction: A signed instruction to perform an action on the blockchain.
 - Block: A group of transactions and a hash of the previous block in the chain.
 - Batch: A group of many transactions from multiple blocks.
 
-See the figure below to best understand how these concepts relate to each other. We follow a real transaction from the Polygon zkEVM to track how it first gets included in a block on the L2, then a batch, and finally, a sequence sent to Ethereum.
+Transactions are included in blocks, and these blocks fill batches, which are then sequenced. See the figure below to best understand how these elements relate to each other. 
 
 ![Batches, blocks, transactions](../../img/cdk/sequence-batch-block-transaction.png)
 
 ## Transaction
 
-A transaction is a cryptographically signed instruction from an account to update the state of the blockchain. Users can leverage familiar tools and libraries, like MetaMask and Ethers.js, typically used for interacting with Ethereum, to send these transactions to CDK-built L2 chains.
+A transaction is a cryptographically signed instruction from an account to update the state of the blockchain. 
 
-Transactions are included in blocks, and these blocks fill batches. Consider a Polygon zkEVM transaction as an example, [`0xdd`](https://zkevm.polygonscan.com/tx/0xdd3f79c24886310ddf868ad1d36aadc6a3b6495048f68aad765c658c42426ef8), which performs a `Simple Swap` function call, and is included in block number [`12952601`](https://zkevm.polygonscan.com/block/12952601) on the L2.
+Let's take a look at a real transaction in the Polygon zkEVM (which is in a way a CDK rollup), and inspect how the transaction is recorded in the [explorer](https://zkevm.polygonscan.com/) as part of a block, then a batch, and ultimately in a sequence.
+
+Consider the Polygon zkEVM transaction with the transaction hash, [`0xdd ... 6ef8`](https://zkevm.polygonscan.com/tx/0xdd3f79c24886310ddf868ad1d36aadc6a3b6495048f68aad765c658c42426ef8), which performs a `Simple Swap` function call, and is included in block number [`12952601`](https://zkevm.polygonscan.com/block/12952601) on the L2.
 
 ![Transaction with block number](../../img/cdk/transaction-block.png)
 
 ## Block
 
-To link blocks together, blocks contain multiple transactions as well as the hash of the previous block in the chain. Following the transaction example from above, the `0xdd` transaction is included in block [`12952601`](https://zkevm.polygonscan.com/block/12952601), which contains [2 transactions in total](https://zkevm.polygonscan.com/txs?block=12952601).
+Each block must include the hash of the previous block, along with multiple transactions, to establish a link to the block before it. 
+
+Continuing with the above transaction, identified by the hash `0xdd ... 6ef8` and contained in block [`12952601`](https://zkevm.polygonscan.com/block/12952601), we observe that this block contains [2 transactions in total](https://zkevm.polygonscan.com/txs?block=12952601).
 
-We can see this `0xdd` transaction is included in both a block and a batch, specifically, it is included in the block `12952601` and the batch `2041736`:
+Also, as depicted in the figure below, block `12952601` is in turn contained in batch `2041736`.
 
 ![Block and batch](../../img/cdk/block-batch.png)
 
 ## Batch
 
-Batches contain multiple transactions from multiple blocks. The two transactions from our example block `12952601` are included in batch [`2041736`](https://zkevm.polygonscan.com/batch/2041736), which contains [10 total transactions](https://zkevm.polygonscan.com/txs?batch=2041736).
+Batches contain multiple transactions from multiple blocks.
 
-This means the batch `2041736` includes the two transactions from block `12952601` as well as eight transactions from other blocks.
+The two transactions from our example block `12952601` are included in batch [`2041736`](https://zkevm.polygonscan.com/batch/2041736), which contains [10 transactions](https://zkevm.polygonscan.com/txs?batch=2041736) in total.
 
-The presence of the `Sequence Tx Hash` field, associated with this batch, indicates that this batch has been sent to Ethereum along with other batches in a single transaction.
+This means batch `2041736` includes the two transactions from block `12952601` as well as eight transactions from other blocks.
+
+As observed in the figure below, the presence of the `Sequence Tx Hash` field associated indicates that the batch has been sent to Ethereum along with other batches in a single transaction.
 
 ![Batch of transactions](../../img/cdk/batch-overview.png)
 
-By inspecting the transactions in the batch, we can see:
+Further inspection of the transactions in the batch, as depicted in the figure below, reveals that:
 
-- Our original transaction example is included in this batch.
-- The batch contains many transactions from different blocks.
+- Our transaction example, with hash `0xdd ... 6ef8`, is included in this batch.
+- The batch contains several transactions from different blocks.
 
 ![Transaction found inside batch](../../img/cdk/transaction-in-batch.png)
 
-If the L2 is a [rollup](./layer2s.md) (meaning it uses Ethereum for it’s [data availability](../glossary/index.md#data-availability), it sends an array of batches to Ethereum, by providing the array as an argument to the `sequenceBatches` function of a smart contract on Ethereum.
+Since Polygon zkEVM is a [rollup](./layer2s.md) (that is, it uses Ethereum for [data availability](../glossary/index.md#data-availability)), it sends an array of batches to Ethereum, by providing the array as an argument to the `sequenceBatches()` function of a smart contract on Ethereum.
 
 ![Sequence Transaction](../../img/cdk/sequence-transaction.png)
 
-By inspecting the `Sequence Tx Hash` transaction, we can see that the `sequenceBatches` function is called with the array of batches as an argument. One of these batches is the batch we have been following, `2041736`, which contains our original transaction example:
+We can inspect the `Sequence Tx Hash` transaction to ascertain if batch `2041736`, containing our original transaction example, was indeed part of the argument to the `sequenceBatches()` function. 
+
+In this case, batch `2041736` happens to be the last batch to be sequenced, as depicted in the figure below.
 
 ![Last batch sequenced](../../img/cdk/last-batch-sequenced.png)
 
 ## Further reading
 
-- [Blocks in the zkEVM Etrog upgrade](../../zkEVM/architecture/protocol/etrog-upgrade.md/?h=blocks#etrog-blocks).
+- [Blocks in the zkEVM Etrog upgrade](../../zkEVM/architecture/protocol/etrog-upgrade.md/?h=blocks#etrog-blocks).

docs/cdk/concepts/bridging.md

@@ -8,17 +8,17 @@ CDK-built chains come with a built-in bridge service and customizable UI out of
 
 The LxLy bridge contracts carry out deposit and withdrawal of assets between L2 and L1.
 
-Chains looking to run their own bridge infrastructure can choose to deploy a new instance of the [LxLy bridge](../../zkEVM/architecture/protocol/unified-LxLy/lxly-bridge.md) that allows users to move assets (both native and [ERC20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) tokens) from L1 to the L2 and vice versa.
+Chains looking to run their own bridge infrastructure can choose to deploy a new instance of the [LxLy bridge](../../zkEVM/architecture/unified-LxLy/index.md) that allows users to move assets (both native and [ERC20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) tokens) from L1 to the L2 and vice versa.
 
-Deploying an individual instance of the LxLy means interoperability with other L2 chains via the [AggLayer](../agglayer/overview.md) is not possible. To enable cross-chain interoperability (i.e. L2-to-L2 cross-chain transactions), chains can opt-in to the AggLayer and use the [unified bridge](../agglayer/unified-bridge.md).
+Deploying an individual instance of the LxLy means interoperability with other L2 chains via the [AggLayer](../../innovation-design/agglayer/overview.md) is not possible. To enable cross-chain interoperability (i.e. L2-to-L2 cross-chain transactions), chains can opt-in to the AggLayer and use the [unified bridge](../../innovation-design/agglayer/unified-bridge.md).
 
 This option is suited to chains that may want to customize how the bridge is managed and operated, or maintain control of the bridge's funds; as the [upgradeability](./admin-upgradeability.md) of the bridge contracts are managed by the chain operator.
 
 ![LxLy bridge](../../img/cdk/lxly.png)
 
 ## Unified bridge
 
-A single, shared instance of the LxLy bridge, called the [unified bridge](../agglayer/unified-bridge.md) is available to use for all CDK chains that opt-in to the AggLayer. 
+A single, shared instance of the LxLy bridge, called the [unified bridge](../../innovation-design/agglayer/unified-bridge.md) is available to use for all CDK chains that opt-in to the AggLayer. 
 
 It is a shared smart contract deployed on Ethereum, responsible for enabling interoperability between chains in the form of cross-chain transactions and L2-to-L2 transfers.
 
@@ -31,5 +31,5 @@ This option is suited to chains that want a standard bridging experience and do
 ## Further reading
 
 - [Aggregated blockchains: A new thesis](https://polygon.technology/blog/aggregated-blockchains-a-new-thesis).
-- [LxLy bridge](../../zkEVM/architecture/protocol/unified-LxLy/lxly-bridge.md).
-- [Unified bridge Ooverview](../agglayer/unified-bridge.md).
+- [LxLy bridge](../../zkEVM/architecture/unified-LxLy/index.md).
+- [Unified bridge overview](../../innovation-design/agglayer/unified-bridge.md).

docs/cdk/getting-started/cdk-erigon/chain-config.md

@@ -0,0 +1,31 @@
+To use chains other than the [defaults](releases.md#current-chainfork-support-status), supply a set of custom configuration files.
+
+1. Ensure the chain name starts with the word `dynamic` e.g. `dynamic-mynetwork`.
+
+2. Create the following files for dynamic configs. The examples for Cardona are in `zk/examples/dynamic-configs` and can be edited as required:
+
+    - `dynamic-{network}-allocs.json` - the allocs file.
+    - `dynamic-{network}-chainspec.json` - the chainspec file.
+    - `dynamic-{network}-conf.json` - an additional configuration file.
+    - `dynamic-{network}.yaml` - the run config file for erigon.  
+    
+    You can use any of the example yaml files at the root of the repo as a base and edit as required, but ensure the `chain` field is in the format `dynamic-mynetwork` and matches the names of the config files above.
+
+3. Put the erigon config file, along with the other files, in the directory of your choice. For example `dynamic-mynetwork`.
+
+    !!! tip
+        - If you have allocs in the Polygon format from the original network launch, save this file to the root of the `cdk-erigon` code base and run `go run cmd/hack/allocs/main.go [your-file-name]` to convert it to the format needed by erigon. 
+        - This creates the `dynamic-{network}-allocs.json` file.
+
+    !!! tip
+        Find the following contract addresses for the `dynamic-{network}.yaml` in the output files created at network launch:
+
+        - `zkevm.address-sequencer` => `create_rollup_output.json` => `sequencer`
+        - `zkevm.address-zkevm` => `create_rollup_output.json` => `rollupAddress`
+        - `zkevm.address-admin` => `deploy_output.json` => `admin`
+        - `zkevm.address-rollup` => `deploy_output.json` => `polygonRollupManagerAddress`
+        - `zkevm.address-ger-manager` => `deploy_output.json` => `polygonZkEVMGlobalExitRootAddress`
+
+4. Mount the directory containing the config files on a Docker container. For example `/dynamic-mynetwork`.
+
+5. To use the new config when starting erigon, use the `--config` flag with the path to the config file e.g. `--config="/dynamic-mynetwork/dynamic-mynetwork.yaml"`.