From f6b938b9d31e6a51770179a07beb666c8a5ad11a Mon Sep 17 00:00:00 2001
From: Maxim Evtush <154841002+maximevtush@users.noreply.github.com>
Date: Sat, 8 Feb 2025 22:44:56 +0100
Subject: [PATCH 1/3] Update integrate-da.md

---
 docs/cdk/how-to/integrate-da.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/cdk/how-to/integrate-da.md b/docs/cdk/how-to/integrate-da.md
index 28ae6b2ad..1521882ad 100644
--- a/docs/cdk/how-to/integrate-da.md
+++ b/docs/cdk/how-to/integrate-da.md
@@ -33,7 +33,7 @@ This section shows you how to create a custom CDK validium DAC contract.
         - Use the Polygon DAC implementation contract: [PolygonDataCommittee.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/v8.0.0-rc.3-fork.12/contracts/v2/consensus/validium/PolygonDataCommittee.sol) as a guide.
         - The contract supports custom smart contract implementation and, through this, DACs can add their custom on-chain verification logic.
 
-6. You can leave the `verifyMessage` function empty but make sure the `getProcotolName` function returns a unique name (such as Avail, Celestia, etc). The following example code comes from the [PolygonDataCommitee.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/v8.0.0-rc.3-fork.12/contracts/v2/consensus/validium/PolygonDataCommittee.sol) implementation.
+6. You can leave the `verifyMessage` function empty but make sure the `getProtocolName` function returns a unique name (such as Avail, Celestia, etc). The following example code comes from the [PolygonDataCommitee.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/v8.0.0-rc.3-fork.12/contracts/v2/consensus/validium/PolygonDataCommittee.sol) implementation.
 
     ```solidity
     // Name of the data availability protocol
@@ -44,7 +44,7 @@ This section shows you how to create a custom CDK validium DAC contract.
     /**
      * @notice Return the protocol name
      */
-    function getProcotolName() external pure override returns (string memory) {
+    function getProtocolName() external pure override returns (string memory) {
         return _PROTOCOL_NAME;
     }
     ```

From 07c5803f24a5313210633e281d3434d3c5e6b8ff Mon Sep 17 00:00:00 2001
From: Maxim Evtush <154841002+maximevtush@users.noreply.github.com>
Date: Sat, 8 Feb 2025 22:45:30 +0100
Subject: [PATCH 2/3] Update t1-ctl-protocol.md

---
 docs/cdk/architecture/type-1-prover/t1-ctl-protocol.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/cdk/architecture/type-1-prover/t1-ctl-protocol.md b/docs/cdk/architecture/type-1-prover/t1-ctl-protocol.md
index 12cb25027..97a574438 100644
--- a/docs/cdk/architecture/type-1-prover/t1-ctl-protocol.md
+++ b/docs/cdk/architecture/type-1-prover/t1-ctl-protocol.md
@@ -12,7 +12,7 @@ However, there are input and output values shared among the tables. These values
 
 ## How CTLs work
 
-The CTL protocol is based on the [logUP argment](https://eprint.iacr.org/2022/1530.pdf), which works similar to how range-checks work. Range-checks are discussed in a subsequent document to this one.
+The CTL protocol is based on the [logUP argument](https://eprint.iacr.org/2022/1530.pdf), which works similar to how range-checks work. Range-checks are discussed in a subsequent document to this one.
 
 ### Example (CTL)
 
@@ -116,4 +116,4 @@ On the other side, and for the same STARK table $S$, the verifier:
   
 - Computes the sum $Z = \sum_j Z_{j}^l$.
 - Checks equality, $Z =?\ Z_0^S$.
-- Checks whether each of the running sums $Z_{j}^l$ and $Z^S$ were correctly constructed. 
\ No newline at end of file
+- Checks whether each of the running sums $Z_{j}^l$ and $Z^S$ were correctly constructed. 

From c0c1bfadd573d25c60436755eb229298d9ea903c Mon Sep 17 00:00:00 2001
From: Maxim Evtush <154841002+maximevtush@users.noreply.github.com>
Date: Sat, 8 Feb 2025 22:46:00 +0100
Subject: [PATCH 3/3] Update forkid-9-12.md

---
 docs/cdk/how-to/migrate/forkid-9-12.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/cdk/how-to/migrate/forkid-9-12.md b/docs/cdk/how-to/migrate/forkid-9-12.md
index 420f68769..c13b05981 100644
--- a/docs/cdk/how-to/migrate/forkid-9-12.md
+++ b/docs/cdk/how-to/migrate/forkid-9-12.md
@@ -172,7 +172,7 @@ go run ./zk/debug_tools/datastream-host \
 4. Start CDK-Erigon Sequencer
     - On a fork upgrade, once the upgrade Tx is finalized you can start the sequencer. Once started, check logs and ensure new blocks are generated with new forkid.
         - You would expect to see starting block #5796790 as forkid 12. If you see the starting block 5796790 as fork id 9 there is a problem.
-        If the new block is on the old fork id 9, you need to resync sequencer from scratch or get one of the rpc datadirs (that were synced till the halt and are currenctly stopped) and replace it to become the new sequencer.
+        If the new block is on the old fork id 9, you need to resync sequencer from scratch or get one of the rpc datadirs (that were synced till the halt and are currently stopped) and replace it to become the new sequencer.
 6. Verify in the sequencer’s logs that new blocks are being generated with fork ID 12.
 7. Start the Pool Manager (if used/needed).
 8. Start CDK-Erigon RPCs (if used/needed).