gas, bridging, upgradeability

Author: jarrodwatts

docs/cdk/concepts/admin-upgradeability.md

@@ -0,0 +1,8 @@
+# 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 built with the CDK implement shared security mechanisms with other CDK chains including the [Polygon zkEVM](https://docs.polygon.technology/zkEVM/architecture/protocol/upgradability/) to ensure the safety of users.
+
+CDK chains share the following upgradeability controls:
+
+1. The [security council](https://docs.polygon.technology/zkEVM/architecture/protocol/security-council/) ([contract address](https://etherscan.io/address/0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6)) that can be used to trigger the [emergency state](https://docs.polygon.technology/zkEVM/architecture/protocol/malfunction-resistance/emergency-state/) which can pause bridge functionality, prevent smart contract upgrades, or stop the [sequencer](./architecture.md#sequencer) from [sequencing batches](./transaction-lifecycle.md#sequenced).
+2. The [admin role](https://docs.polygon.technology/zkEVM/architecture/protocol/admin-role/) ([contract address](https://etherscan.io/address/0x242daE44F5d8fb54B198D03a94dA45B5a4413e21)) that can perform upgrades to patch bug fixes or add new features to the system by upgrading smart contracts with a 10-day waiting period (unless [emergency state](https://docs.polygon.technology/zkEVM/architecture/protocol/malfunction-resistance/emergency-state/) is active).

docs/cdk/concepts/bridging.md

@@ -0,0 +1,9 @@
+# Bridging
+
+[Bridges](https://ethereum.org/en/developers/docs/bridges/) are a fundamental component of L2s. They allow users to bridge funds from the L1 (Ethereum) seamlessly, to pay for gas fees or interact with dApps on the L2, and optionally bridge funds back to the L1.
+
+CDK chains come with a built-in bridge service and customizable UI that enables users to move assets (both native and ERC20 tokens) between L1 and L2.
+
+A key benefit to building ZK-powered L2s with the CDK is that there are no challenge periods unlike [optimistic rollups](./zk-vs-optimistic.md#optimistic-rollups), meaning users can move funds from the L2 to the L1 immediately after the [aggregation](./transaction-lifecycle.md#aggregated) process is complete (i.e. a ZK proof is posted & verified).
+
+![Bridge UI for CDK](../../img/cdk/bridge-ui.png)

docs/cdk/concepts/gas-fees.md

@@ -0,0 +1,7 @@
+# Gas Fees
+
+CDK chains have full control over how gas fees are set for users, including what token to use for the native gas fees of the L2 chain, which is set to ETH by default.
+
+Gas fees can also be omitted entirely, allowing users to interact with the chain without needing to pay gas fees for transactions and have the fees covered by the chain operator.
+
+By default, gas fees on the L2 are determined by a combination of several factors, including the current gas price on Ethereum, the complexity of the submitted transaction, and the current demand on the L2 network itself.

docs/img/cdk/bridge-ui.png

@@ -62,8 +62,8 @@ nav:
         - L2 Architecture Overview: cdk/concepts/architecture.md
         - Transaction Lifecycle: cdk/concepts/transaction-lifecycle.md
         - Transaction Finality: cdk/concepts/transaction-finality.md
-        - Bridging: cdk/concepts/bridging.md
         - Gas Fees: cdk/concepts/gas-fees.md
+        - Bridging: cdk/concepts/bridging.md
         - AggLayer & Interoperability: cdk/concepts/agglayer.md
         - Admin Upgradeability: cdk/concepts/admin-upgradeability.md
       - Architecture: