diff --git a/docs/getting-started/guides/libs/data-structures/incremental-merkle-tree.md b/docs/getting-started/guides/libs/data-structures/incremental-merkle-tree.md
index 5bbb7b0..4b7d6f4 100644
--- a/docs/getting-started/guides/libs/data-structures/incremental-merkle-tree.md
+++ b/docs/getting-started/guides/libs/data-structures/incremental-merkle-tree.md
@@ -17,7 +17,7 @@ In the example below, the tree is nearly full, utilizing all `branches`. Initial
 
 The next attempt to add a new element to the tree will result in tree growth. As we complete a tree with four elements, it will attempt to add the element at index 3 to the branches array. If the array size is insufficient, the element will simply be pushed there.
 
-in general, to retrieve the Merkle Tree Root, we need to iterate over each level of the tree. The `leavesCount` field determines which pair of elements should be hashed to obtain the parent node hash. The algorithm is as follows:
+In general, to retrieve the Merkle Tree Root, we need to iterate over each level of the tree. The `leavesCount` field determines which pair of elements should be hashed to obtain the parent node hash. The algorithm is as follows:
 
 ```python
 root: int = zeroHashes[0]
diff --git a/docs/getting-started/guides/libs/zkp/verifier-helper.md b/docs/getting-started/guides/libs/zkp/verifier-helper.md
index 62f2d8a..eb6aabd 100644
--- a/docs/getting-started/guides/libs/zkp/verifier-helper.md
+++ b/docs/getting-started/guides/libs/zkp/verifier-helper.md
@@ -6,7 +6,7 @@ The Verifier Helper library is designed to simplify working with auto-generated
 
 ## Implementation
 
-Verifier contracts have a function `verifyProof(uint256[2] a_, uint256[2][2][2] b_, uint256[2] c_, uint256[<number-of-public-inputs>] inputs_)` where the `inputs_` is a static array with a length that depends on the circom circuit for which the verifier contract was generated. If the developer needs to develop one contract that will interact with **verifiers** for different circom circuits, i.e. with different lengths of `inputs_` arrays in the `verifyProof` function, then it will be necessary to create many interfaces, which will clearly complicate the task. The `VerifierHelper` library will help to solve this problem.
+Verifier contracts have a function `verifyProof(uint256[2] a_, uint256[2][2] b_, uint256[2] c_, uint256[<number-of-public-inputs>] inputs_)` where the `inputs_` is a static array with a length that depends on the circom circuit for which the verifier contract was generated. If the developer needs to develop one contract that will interact with **verifiers** for different circom circuits, i.e. with different lengths of `inputs_` arrays in the `verifyProof` function, then it will be necessary to create many interfaces, which will clearly complicate the task. The `VerifierHelper` library will help to solve this problem.
 
 The solution to this problem is quite simple, `staticcall` is used inside the `VerifierHelper` library, and the signature of the function to be called is generated dynamically. The length of the static array `inputs_` inside the `verifyProof` function is determined by the length of the dynamic array that was passed to the library function.