diff --git a/README.md b/README.md
index b38eb324..869e9f8d 100644
--- a/README.md
+++ b/README.md
@@ -71,7 +71,7 @@ cargo bench --bench mul
 cargo bench --bench inner_product
 ```
 
-These benchmarks use the `criterion` crate to run `create_proof` 10 times for statistical analysis. Note the benchmark circuits perform more than a one multiplication / inner product per circuit.
+These benchmarks use the `criterion` crate to run `create_proof` 10 times for statistical analysis. Note the benchmark circuits perform more than one multiplication / inner product per circuit.
 
 ## halo2-ecc
 
@@ -198,7 +198,7 @@ cargo bench --bench fixed_base_msm
 cargo bench --bench fp_mul
 ```
 
-This run the same proof generation over 10 runs and collect the average. Each circuit has a fixed configuration chosen for optimal speed. These benchmarks are mostly for use in performance optimization.
+This runs the same proof generation over 10 runs and collect the average. Each circuit has a fixed configuration chosen for optimal speed. These benchmarks are mostly for use in performance optimization.
 
 ### Secp256k1 ECDSA
 
@@ -290,7 +290,7 @@ The r6a has a higher clock speed than the r6g. We hypothesize that the Apple Sil
 
 We provide benchmarks of multi-scalar multiplication (MSM, multi-exp) with a batch size of `100` for BN254.
 
-On a M2 Max Macbook Pro (12 CPU cores, 96 GB RAM) we ran the bench using
+On an M2 Max Macbook Pro (12 CPU cores, 96 GB RAM) we ran the bench using
 
 ```
 cargo test --release --no-default-features --features "halo2-axiom, mimalloc" -- --nocapture bench_msm
diff --git a/hashes/zkevm/src/keccak/README.md b/hashes/zkevm/src/keccak/README.md
index 89c838a9..337c54f6 100644
--- a/hashes/zkevm/src/keccak/README.md
+++ b/hashes/zkevm/src/keccak/README.md
@@ -23,7 +23,7 @@ All these items remain consistent across all versions.
 - Every input is padded to be a multiple of RATE (136 bytes). If the length of the logical input already matches a multiple of RATE, an additional RATE bytes are added as padding.
 - Each `keccak_f` absorbs `RATE` bytes, which are splitted into `NUM_WORDS_TO_ABSORB`(17) words. Each word has `NUM_BYTES_PER_WORD`(8) bytes.
 - Each of the first `NUM_WORDS_TO_ABSORB`(17) rounds of each `keccak_f` absorbs a word.
-- `is_final`(anothe name is `is_enabled`) is meaningful only at the first row of the "squeeze" round. It must be true if this is the last `keccak_f` of a logical input.
+- `is_final`(another name is `is_enabled`) is meaningful only at the first row of the "squeeze" round. It must be true if this is the last `keccak_f` of a logical input.
 - The first round of the circuit is a dummy round, which doesn't correspond to any input.
 
 ### Raw inputs
@@ -81,7 +81,7 @@ Keccak component circuits and utilities based on halo2-lib.
 
 ### Motivation
 
-Move expensive Keccak computation into standalone circuits(**Component Circuits**) and circuits with actual business logic(**App Circuits**) can read Keccak results from component circuits. Then we achieve better scalability - the maximum size of a single circuit could be managed and component/app circuits could be proved in paralle.
+Move expensive Keccak computation into standalone circuits(**Component Circuits**) and circuits with actual business logic(**App Circuits**) can read Keccak results from component circuits. Then we achieve better scalability - the maximum size of a single circuit could be managed and component/app circuits could be proved in parallel.
 
 ### Output
 
diff --git a/hashes/zkevm/src/keccak/vanilla/mod.rs b/hashes/zkevm/src/keccak/vanilla/mod.rs
index 8faa6d7b..91fa6d0f 100644
--- a/hashes/zkevm/src/keccak/vanilla/mod.rs
+++ b/hashes/zkevm/src/keccak/vanilla/mod.rs
@@ -266,7 +266,7 @@ impl<F: Field> KeccakCircuitConfig<F> {
         // that allows reusing the same parts in an optimal way for the chi step.
         // We can save quite a few columns by not recombining the parts after rho/pi and
         // re-splitting the words again before chi. Instead we do chi directly
-        // on the output parts of rho/pi. For rho/pi specially we do
+        // on the output parts of rho/pi. For rho/pi especially we do
         // `s[j][2 * i + 3 * j) % 5] = normalize(rot(s[i][j], RHOM[i][j]))`.
         cell_manager.start_region();
         let mut lookup_counter = 0;
@@ -279,7 +279,7 @@ impl<F: Field> KeccakCircuitConfig<F> {
         // extra additional cells or selectors we have to put all `s[i]`'s on the same
         // row. This isn't that strong of a requirement actually because we the
         // words are split into multiple parts, and so only the parts at the same
-        // position of those words need to be on the same row.
+        // position of those words needs to be on the same row.
         let target_word_sizes = target_part_sizes(part_size);
         let num_word_parts = target_word_sizes.len();
         let mut rho_pi_chi_cells: [[[Vec<Cell<F>>; 5]; 5]; 3] = array_init::array_init(|_| {
@@ -357,7 +357,7 @@ impl<F: Field> KeccakCircuitConfig<F> {
         let mut lookup_counter = 0;
         let part_size_base = get_num_bits_per_base_chi_lookup(k);
         for idx in 0..num_columns {
-            // First fetch the cells we wan to use
+            // First fetch the cells we want to use
             let mut input: [Expression<F>; 5] = array_init::array_init(|_| 0.expr());
             let mut output: [Expression<F>; 5] = array_init::array_init(|_| 0.expr());
             for c in 0..5 {
diff --git a/hashes/zkevm/src/sha256/README.md b/hashes/zkevm/src/sha256/README.md
index 23ed9fe3..259a0925 100644
--- a/hashes/zkevm/src/sha256/README.md
+++ b/hashes/zkevm/src/sha256/README.md
@@ -41,7 +41,7 @@ such that the bits in the message are: <original message of length L> 1 <K zeros
     - Only constrained when `q_input` is true.
   - `output` (2): the hash digest the SHA-256 algorithm on the input bytes (32 bytes). We represent this as two field elements in hi-lo form - we split 32 bytes into two 16 byte chunks, and convert them to `u128` as _big endian_.
     - Only constrained when the last row of a block. Should only be considered meaningful when `is_enabled` is true.
-- We convenient store the relevant cells for the above data, per input block, in the struct `AssignedSha256Block`.
+- We conveniently store the relevant cells for the above data, per input block, in the struct `AssignedSha256Block`.
 - This circuit has a hard constraint that the input array has length up to `2^32 - 1` bits, whereas the official SHA-256 spec supports up to `2^64 - 1`. (In practice it is likely impossible to create a circuit that can handle `2^32 - 1` bit inputs.)
 - Details are provided in inline comments.
 
@@ -69,4 +69,4 @@ To illustrate, let's consider `inputs = [[], [0x00, 0x01, ..., 0x37]]`. The corr
 | 163 | 1         | `0x0`        | 56     | false      |         |
 | 215 | 1         | -            | -      | true       | RESULT  | RESULT  |
 
-Here the second input has length 56 (in bytes) and requires two blocks due to padding: `56 * 8 + 1 + 64 > 512`.
+Here the second input has a length of 56 (in bytes) and requires two blocks due to padding: `56 * 8 + 1 + 64 > 512`.