fixed link to video connect-wallet.md

Author: EmpieichO

docs/cdk/concepts/dac.md

@@ -1,4 +1,4 @@
-Data availability in blockchain technology refers to whether or not transaction data is available on-chain or off-chain. 
+Data availability in blockchain technology refers to whether or not transaction data is available on-chain or off-chain.
 
 If data is available on-chain, then each node has to store every piece of data related to every transaction. This can be costly for node operators as hardware and storage requirements are high. Moving data off-chain streamlines node architecture and operations.
 
@@ -14,13 +14,13 @@ A DAC is an off-chain network of nodes that implements a data storage layer in a
 - **Lower transaction fees**: Reduced computational requirements lead to lower fees and faster finality on the main network.
 - **Privacy and security**: The DAC stores secure and private transaction data.
 - **Trustless**: Data owners do not have to trust the blockchain operator.
-- **Scalable**: Decoupling data storage from the main chain supports more scalable networks. 
+- **Scalable**: Decoupling data storage from the main chain supports more scalable networks.
 
 DACs store the data required to reconstruct the state of the blockchain and make that data accessible so that, if the main blockchain network goes down, users can still access their assets and data.
 
 Setting up a DAC can be costly and therefore DACs mostly support Enterprise use cases which require cheap and fast transactions with a private and secure data layer.
 
-The CDK validium DAC is a secure consortium of nodes that ensures off-chain data access. 
+The CDK validium DAC is a secure consortium of nodes that ensures off-chain data access.
 
 ## DAC data flow
 
@@ -40,4 +40,4 @@ The DAC works together with the sequencer to control the flow of data. The proce
 
 6. **Verification on Ethereum**: A designated smart contract on Ethereum verifies the submitted signatures against a list of valid DAC members and confirms that sufficient approval has been provided for the batch hash.
 
-7. **Final settlement with zero-knowledge proof**: The aggregator prepares a proof for the batch via the prover and submits it to Ethereum. This proof confirms the validity of the batch's transactions without revealing their details. The chain state updates on Ethereum.
+7. **Final settlement with zero-knowledge proof**: The aggregator prepares a proof for the batch via the prover and submits it to Ethereum. This proof confirms the validity of the batch's transactions without revealing their details. The chain state updates on Ethereum.

docs/cdk/concepts/index.md

@@ -0,0 +1 @@
+Welcome to Concepts

docs/cdk/concepts/rollup.md

@@ -1,6 +1,6 @@
-Rollups are blockchain layer 2 scaling solutions that speed up the network by *rolling up* multiple transactions into batches which are eventually committed to the layer 1. 
+Rollups are blockchain layer 2 scaling solutions that speed up the network by *rolling up* multiple transactions into batches which are eventually committed to the layer 1.
 
 CDK provides zkEVM rollup solutions.
 
 !!! info "Recommended resource"
-    See Ethereum.org's detailed [description of zero-knowledge rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/).
+    See Ethereum.org's detailed [description of zero-knowledge rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/).

docs/cdk/concepts/validium.md

@@ -1,4 +1,4 @@
-Validiums are blockchain scaling solutions that do not store transaction data. 
+Validiums are blockchain scaling solutions that do not store transaction data.
 
 !!! info "Recommended resource"
-    See Ethereum.org's detailed [description of validiums](https://ethereum.org/en/developers/docs/scaling/validium/).
+    See Ethereum.org's detailed [description of validiums](https://ethereum.org/en/developers/docs/scaling/validium/).

docs/cdk/get-started/deploy-rollup.md

@@ -4,4 +4,3 @@
 ## Deploy a CDK rollup locally
 
 The [zkEVM deployment quickstart documentation](../../zkEVM/get-started/deploy-zkevm/index.md) shows you how to deploy a zkEVM rollup on your local machine.
-

docs/cdk/get-started/deploy-validium.md

@@ -7,17 +7,16 @@ Follow the steps below to deploy a CDK validium instance.
 
 First, deploy the relevant contracts.
 
-Follow the steps in the [CDK validium contracts repository's README</ins>](https://github.com/0xPolygon/cdk-validium-contracts).
+Follow the steps in the [CDK validium contracts repository's README](https://github.com/0xPolygon/cdk-validium-contracts).
 
 ## 2. Run the CDK validium node
 
-Next, set up and run the CDK validium node. 
+Next, set up and run the CDK validium node.
 
 Follow the instructions in the [CDK validium node repository's README](https://github.com/0xPolygon/cdk-validium-node).
 
-
 ## 3. Run the data availability (DA) node (optional step)
 
-Finally, once the CDK validium node is operational, set up and run the data availability node. 
+Finally, once the CDK validium node is operational, set up and run the data availability node.
 
-Check for instructions here: [<ins>CDK DA Node GitHub running instructions</ins>](https://github.com/0xPolygon/cdk-data-availability/blob/main/docs/running.md).
+Check for instructions here: [CDK DA Node GitHub running instructions](https://github.com/0xPolygon/cdk-data-availability/blob/main/docs/running.md).

docs/cdk/welcome.md docs/cdk/get-started/index.mddocs/cdk/welcome.md renamed to docs/cdk/get-started/index.md

@@ -5,16 +5,16 @@ This section documents the two most popular deployments currently supported by C
 - Validium
 - Rollup
 
-Users select a chain architecture specific to their needs from a set of supported, open source options. Alternatively, users can select custom components for specific requirements. 
+Users select a chain architecture specific to their needs from a set of supported, open source options. Alternatively, users can select custom components for specific requirements.
 
 !!! important "Why are there zkEVM docs in the CDK section?"
      Several of the docs point to zkEVM specific deployment documentation because the rollup flavor of CDK uses zkEVM deployment defaults.
 
 The diagram below shows the two supported configuration options for data availability (DA), rollup or validium. Rollups post transaction data from the CDK directly onto Ethereum whereas validiums only post the transaction hash.
 
-![CDK architecture choices](../img/cdk/cdk-architecture.png)
+![CDK architecture choices](../../img/cdk/cdk-architecture.png)
 
-Check out the [data availability docs](concepts/dac.md) for more information.
+Check out the [data availability docs](../concepts/dac.md) for more information.
 
 !!! important
     The documentation describes standard deployments. You can edit the configuration files to implement your own custom set ups.

docs/cdk/get-started/quickstart-validium.md

@@ -26,6 +26,7 @@ cd zkValidium-quickstart
 ```
 
 Create the `.env` file by copying the example:
+
 ```bash
 cp .env.example .env
 ```
@@ -93,6 +94,7 @@ zkevm-bridge-service             /bin/sh -c /app/zkevm-brid ...   Up
                                                                                  0.0.0.0:9090->9090/tcp,:::9090->9090/tcp                     
 zkevm-bridge-ui                  /bin/sh /app/scripts/deploy.sh   Up             0.0.0.0:8088->80/tcp,:::8088->80/tcp 
 ```
+
 </details>
 
 2.3.1 If a service isn't running (i.e. it is in `Exit 1` state), investigate further using the logs:
@@ -123,7 +125,7 @@ sudo make restart
 
 ## 3. Test validium
 
-3.1 Verify the block explorer is running by navigating to [localhost:4001](http://localhost:4001/). 
+3.1 Verify the block explorer is running by navigating to [localhost:4001](http://localhost:4001/).
 
 You should see a page similar to this:
 
@@ -135,8 +137,8 @@ You should see a page similar to this:
 
 4.1 Follow MetaMask's instructions on [how to set up a network manually](https://support.metamask.io/hc/en-us/articles/360043227612-How-to-add-a-custom-network-RPC).
 
-- Set the chain ID to **1001**. 
-- The currency symbol can be anything but we will use **POL** by default. 
+- Set the chain ID to **1001**.
+- The currency symbol can be anything but we will use **POL** by default.
 - The RPC node and block explorer containers can be found at ports **8123** and **4001**, respectively.
 
 <div align="center">
@@ -191,7 +193,7 @@ CDK has a native bridge with UI that allows you to transfer funds between the L1
 
 5.1.2 Switch to the L1 network and you will see the previously imported account with ~999 POL on the L1 chain.
 
-5.1.3 Verify the bridge UI by navigating to [localhost:8088](http://localhost:8088/). 
+5.1.3 Verify the bridge UI by navigating to [localhost:8088](http://localhost:8088/).
 
 5.1.4 Click on **Connect a wallet > MetaMask**.
 
@@ -205,7 +207,7 @@ CDK has a native bridge with UI that allows you to transfer funds between the L1
   <img src="/img/cdk/cdk-bridge-connected.png" alt="bridge" width="90%" height="30%" />
 </div>
 
-5.1.6 Enter the amount (e.g. 5) to bridge and click **Continue**, you will see the **Confirm Bridge** page. 
+5.1.6 Enter the amount (e.g. 5) to bridge and click **Continue**, you will see the **Confirm Bridge** page.
 
 5.1.7 Click **Bridge** and approve the transaction on the MetaMask pop-up:
 
@@ -221,7 +223,7 @@ CDK has a native bridge with UI that allows you to transfer funds between the L1
 
 ### 5.2 L2 to L1
 
-5.2.1 Switch network on MetaMask to your validium chain and navigate back to [localhost:8088](http://localhost:8088/). 
+5.2.1 Switch network on MetaMask to your validium chain and navigate back to [localhost:8088](http://localhost:8088/).
 
 5.2.2 You should see both the updated L1 and L2 balances:
 
@@ -244,4 +246,4 @@ The L2->L1 bridging is slightly different than L1->L2 and you will see the **Act
 
 <div align="center">
   <img src="/img/cdk/cdk-bridge-l2-to-l1-completed.png" alt="bridge" width="90%" height="30%" />
-</div>
+</div>

docs/cdk/how-to/index.md

@@ -0,0 +1 @@
+This introduction to the how to section is being written.

docs/cdk/how-to/manage-allowlists.md docs/cdk/how-to/manage-policies.mddocs/cdk/how-to/manage-allowlists.md renamed to docs/cdk/how-to/manage-policies.md

@@ -5,7 +5,7 @@ Managing allowlists, denylists, and ACLs is done with policies.
 
 ## Policy overview
 
-A **policy** is a set of rules that govern what actions are allowed or denied in the transaction pool. 
+A **policy** is a set of rules that govern what actions are allowed or denied in the transaction pool.
 
 - **Fine-grained control**: Developers can specify policies at a granular level, allowing or denying specific actions for specific addresses.
 - **Dynamic updates**: Policies and ACLs can be updated on-the-fly without requiring a node restart.
@@ -21,7 +21,7 @@ Currently, there are two defined policies:
 - **SendTx**: governs whether an address may send transactions to the pool.
 - **Deploy**: governs whether an address may deploy a contract.
 
-The CDK validium node offers policy management features that include allowlisting[^1], denylisting[^2], and access control lists (ACLs)[^3]. These features are beneficial for validium-based app-chains that require fine-grained control over transaction pools. 
+The CDK validium node offers policy management features that include allowlisting[^1], denylisting[^2], and access control lists (ACLs)[^3]. These features are beneficial for validium-based app-chains that require fine-grained control over transaction pools.
 
 ### Code definitions
 
@@ -83,7 +83,6 @@ docker exec -it cdk-validium-aggregator /app/cdk-validium-node policy describe -
 docker exec -it cdk-validium-aggregator /app/cdk-validium-node policy describe
 ```
 
-
 [^1]: **Allowlisting**: The process of explicitly allowing addresses to perform certain actions.
 [^2]: **Denylisting**: The process of explicitly denying addresses from performing certain actions.
-[^3]: **ACL (access control list)**: A list of addresses that are exceptions to a given policy.
+[^3]: **ACL (access control list)**: A list of addresses that are exceptions to a given policy.