links mainly

Author: kmurphypolygon

docs/cdk/concepts/admin-upgradeability.md

@@ -1,6 +1,6 @@
 # Admin upgradeability
 
-As L2s work through the [stages of training wheels](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) to become fully decentralized, chains that opt in to the [AggLayer](../glossary.md/#agglayer-v1-al1) implement shared security mechanisms with other AggLayer chains including the [Polygon zkEVM](../../zkEVM/architecture/protocol/upgradability.md) to ensure the safety of users.
+As L2s work through the [stages of training wheels](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) to become fully decentralized, chains that opt in to the [AggLayer](../glossary/index.md#agglayer-v1-al1) implement shared security mechanisms with other AggLayer chains including the [Polygon zkEVM](../../zkEVM/architecture/protocol/upgradability.md) to ensure the safety of users.
 
 Chains opted into the AggLayer share the following upgradeability controls:
 
@@ -14,5 +14,5 @@ Chains opted into the AggLayer share the following upgradeability controls:
 - [zkEVM admin role and governance](../../zkEVM/architecture/protocol/admin-role.md).
 - [zkEVM upgrade process](../../zkEVM/architecture/protocol/upgrade-process.md).
 - [zkEVM security council](../../zkEVM/architecture/protocol/security-council.md).
-- [zkEVM emergency state](../../zkEVM/architecture/protocol/malfunction-resistance/.emergency-state.md).
+- [zkEVM emergency state](../../zkEVM/architecture/protocol/malfunction-resistance/emergency-state.md).
 - [L2Beat - Polygon zkEVM](https://l2beat.com/scaling/projects/polygonzkevm?selectedChart=activity).

docs/cdk/concepts/architecture.md

@@ -1,14 +1,14 @@
 # Architecture
 
-While each chain built with the CDK is unique, they all share a common high-level architecture. Before diving into the specifics of how [transactions](./transaction-lifecycle.md) are processed, it’s helpful to first understand the role of each component in the system.
+While each chain built with the CDK is unique, they all share a common high-level architecture. Before diving into the specifics of how [transactions](./transaction-lifecycle.md) are processed, it is helpful to first understand the role of each component in the system.
 
 Below is the high-level architecture of a chain built with the CDK, showing how transactions sent by users are processed and finalized on the L1:
 
 ![CDK Architecture](../../img/cdk/architecture-overview.png)
 
 ## Users
 
-Chains built with the CDK are EVM-compatible by default. Although the [type of ZK-EVM](https://docs.polygon.technology/cdk/architecture/type-1-prover/intro-t1-prover/#type-definitions) you choose to implement is customizable, CDK chains are designed to be compatible with existing Ethereum tools and libraries.
+Chains built with the CDK are EVM-compatible by default. Although the [type of ZK-EVM](../architecture/type-1-prover/intro-t1-prover.md/#type-definitions) you choose to implement is customizable, CDK chains are designed to be compatible with existing Ethereum tools and libraries.
 
 This means both users and developers can use the same wallets (such as MetaMask) and libraries (such as Ethers.js) to interact with CDK-built chains as they do with Ethereum.
 
@@ -27,18 +27,18 @@ In the background, the sequencer periodically creates batches of transactions an
 
 ## L1 smart contracts
 
-Multiple smart contracts, deployed on the L1 (Ethereum), work together to finalize transactions received from the L2 on the L1. Typically there is a main “rollup” smart contract that is responsible for:
+Multiple smart contracts, deployed on the L1 (Ethereum), work together to finalize transactions received from the L2 on the L1. Typically there is a main *rollup* smart contract that is responsible for:
 
-1. Receiving and storing batches of transactions from the L2 (depending on the design of the L2, it may not use Ethereum for [data availability](https://docs.polygon.technology/cdk/glossary/#data-availability)).
+1. Receiving and storing batches of transactions from the L2 (depending on the design of the L2, it may not use Ethereum for [data availability](../glossary/index.md#data-availability).
 
 2. Receiving and verifying ZK-proofs from the aggregator to prove the validity of the transactions.
 
 ## Aggregator and prover
 
 The aggregator is responsible for periodically reading batches of L2 transactions that have not been verified yet, and generating ZK-proofs for them to prove their validity.
 
-To do this, the aggregator sends the batches of transactions to a **prover**. The prover generates ZK proofs and sends them back to the aggregator, which then posts the proof back to the L1 smart contract.
+To do this, the aggregator sends the batches of transactions to a prover. The prover generates ZK proofs and sends them back to the aggregator, which then posts the proof back to the L1 smart contract.
 
 ## Further reading
 
-- [zkEVM architecture overview](https://docs.polygon.technology/zkEVM/architecture/high-level/overview/)
+- [zkEVM architecture overview](../../zkEVM/architecture/index.md)

docs/cdk/concepts/blocks.md

@@ -1,8 +1,8 @@
 # Batches, blocks, and transactions
 
-The following concepts are key to understanding how transactions are handled on L2s built with the CDK:
+The following definition are key to understanding how transactions are handled on L2s built with the CDK:
 
-- Transaction: Signed instruction to perform an action on the blockchain.
+- 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.
 
@@ -16,15 +16,15 @@ A transaction is a cryptographically signed instruction from an account to updat
 
 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.
 
-![Transaction with Block Number](../../img/cdk/transaction-block.png)
+![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).
 
 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`:
 
-![Block and Batch](../../img/cdk/block-batch.png)
+![Block and batch](../../img/cdk/block-batch.png)
 
 ## Batch
 
@@ -43,14 +43,14 @@ By inspecting the transactions in the batch, we can see:
 
 ![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](https://docs.polygon.technology/cdk/glossary/#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.
+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.
 
 ![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:
 
-![Last Batch Sequenced](../../img/cdk/last-batch-sequenced.png)
+![Last batch sequenced](../../img/cdk/last-batch-sequenced.png)
 
 ## Further reading
 
-- [Blocks in the zkEVM Etrog Upgrade](https://docs.polygon.technology/zkEVM/architecture/protocol/etrog-upgrade/?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

@@ -2,33 +2,34 @@
 
 [Bridges](https://ethereum.org/en/developers/docs/bridges/) are a fundamental component of L2s that allow users to deposit and withdraw assets to and from your chain.
 
-CDK-built chains come with a built-in bridge service and customizable UI out of the box, with the option to have a standalone [LxLy bridge](#lxly-bridge) or alternatively opt-in to the AggLayer and use the [Unified Bridge](#unified-bridge) to enable cross-chain L2-to-L2 interoperability.
+CDK-built chains come with a built-in bridge service and customizable UI out of the box, with the option to have a standalone [LxLy bridge](#lxly-bridge) or alternatively opt-in to the AggLayer and use the [unified bridge](#unified-bridge) to enable cross-chain L2-to-L2 interoperability.
 
 ## LxLy bridge
 
 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](https://docs.polygon.technology/zkEVM/architecture/protocol/unified-LxLy/lxly-bridge/) 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/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.
 
-Deploying an individual instance of the LxLy means interoperability with other L2 chains via the [AggLayer](https://polygon.technology/blog/aggregated-blockchains-a-new-thesis) 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](#unified-bridge).
+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).
 
-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.
+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)
+![LxLy bridge](../../img/cdk/lxly.png)
 
 ## Unified bridge
 
-A single, shared instance of the LxLy bridge, called the [unified bridge](https://docs.polygon.technology/cdk/architecture/staking-the-bridge/) 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](../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.
 
-Chains that integrate with the Unified Bridge can benefit from the network effect of the AggLayer, as their chain can therefore access the users and liquidity of other chains that are also part of the AggLayer.
+Chains that integrate with the unified bridge can benefit from the network effect of the AggLayer, as their chain can therefore access the users and liquidity of other chains that are also part of the AggLayer.
 
-This option is suited to chains that want a standard bridging experience and do not require customization of the bridge’s operation. The shared bridge is also not directly managed by the chain operator, instead, it shares the governance outlined in the [admin upgradeability](./admin-upgradeability.md) section.
+This option is suited to chains that want a standard bridging experience and do not require customization of the bridge's operation. The shared bridge is also not directly managed by the chain operator, instead, it shares the governance outlined in the [admin upgradeability](./admin-upgradeability.md) section.
 
-![Unified Bridge](../../img/cdk/unified-bridge.png)
+![Unified bridge](../../img/cdk/unified-bridge.png)
 
 ## Further reading
 
-- [Aggregated Blockchains: A New Thesis](https://polygon.technology/blog/aggregated-blockchains-a-new-thesis)
-- [Unified Bridge Overview](https://docs.polygon.technology/zkEVM/architecture/protocol/unified-LxLy/lxly-bridge/)
+- [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).

docs/cdk/concepts/gas-fees.md

@@ -8,4 +8,4 @@ By default, gas fees on the L2 are determined by a combination of several factor
 
 ## Further reading
 
-- [zkEVM gas fees documentation](https://docs.polygon.technology/zkEVM/architecture/effective-gas/)
+- [zkEVM gas fees documentation](../../zkEVM/architecture/effective-gas/index.md).

docs/cdk/concepts/layer2s.md

@@ -8,17 +8,17 @@ Under the hood, L2s create "batches" of transactions, and periodically submit ma
 
 Typically, L2s deploy smart contracts to Ethereum that handle the verification of these batches, ensuring that the transactions are valid. Since this verification process occurs on Ethereum, it is often said that L2s inherit the security of Ethereum.
 
-![L2 Batching Overview](../../img/cdk/l2-overview-diagram.svg)
+![L2 batching overview](../../img/cdk/l2-overview-diagram.svg)
 
 ## Types of layer 2s
 
 L2s come in different shapes and sizes in terms of their relationship with Ethereum: Each design decision comes with trade-offs in terms of security, scalability, or decentralization.
 
-For example, some L2s, such as the [Polygon zkEVM](https://docs.polygon.technology/zkEVM/) send all transaction data to Ethereum, whereas other L2s only send information about the state differences, or choose not to send transaction data to Ethereum; instead relying on different data availability mechanisms.
+For example, some L2s, such as the [Polygon zkEVM](../../zkEVM/) send all transaction data to Ethereum, whereas other L2s only send information about the state differences, or choose not to send transaction data to Ethereum; instead relying on different data availability mechanisms.
 
-Since storing information on Ethereum is expensive, (see [gas and fees](https://ethereum.org/en/developers/docs/gas/)), building an L2 chain means making tradeoffs between security, decentralization and scalability. The CDK provides developers with the tools to make these trade-offs and build a chain that meets their specific needs depending on their use case.
+Since storing information on Ethereum is expensive, (see [gas and fees](https://ethereum.org/en/developers/docs/gas/)), building an L2 chain means making tradeoffs between security, decentralization, and scalability. The CDK provides developers with the tools to make these trade-offs and build a chain that meets their specific needs depending on their use case.
 
 ## Further reading
 
-- [Ethereum documentation: Layer 2s](https://ethereum.org/en/layer-2/)
-- [Ethereum documentation: Scaling](https://ethereum.org/en/developers/docs/scaling/)
+- [Ethereum documentation: Layer 2s](https://ethereum.org/en/layer-2/).
+- [Ethereum documentation: Scaling](https://ethereum.org/en/developers/docs/scaling/).