diff --git a/beacon_chain/consensus_object_pools/README.md b/beacon_chain/consensus_object_pools/README.md
index ecc16080ac..b054883c02 100644
--- a/beacon_chain/consensus_object_pools/README.md
+++ b/beacon_chain/consensus_object_pools/README.md
@@ -15,7 +15,7 @@ After "gossip validation" the consensus objects can be rebroadcasted as they are
 For blocks, this means verifying state transition and all contained cryptographic signatures (instead of just the proposer signature).
 For other consensus objects, it is possible that gossip validation is a superset of consensus verification (TODO).
 
-The pools presenet in this folder are:
+The pools present in this folder are:
 - block_pools:
   - block_quarantine: for seemingly valid blocks that are on a fork unknown to us.
   - block_clearance: to verify (state_transition + cryptography) candidate blocks.
diff --git a/beacon_chain/consensus_object_pools/attestation_pool.nim b/beacon_chain/consensus_object_pools/attestation_pool.nim
index ff70a1f437..91bb8882e5 100644
--- a/beacon_chain/consensus_object_pools/attestation_pool.nim
+++ b/beacon_chain/consensus_object_pools/attestation_pool.nim
@@ -37,7 +37,7 @@ type
     proc(data: electra.Attestation) {.gcsafe, raises: [].}
 
   Validation[CVBType] = object
-    ## Validations collect a set of signatures for a distict attestation - in
+    ## Validations collect a set of signatures for a distinct attestation - in
     ## eth2, a single bit is used to keep track of which signatures have been
     ## added to the aggregate meaning that only non-overlapping aggregates may
     ## be further combined.
@@ -696,7 +696,7 @@ func score(
     doAssert aggregation_bits.len() == xxx[].len(),
       "check_attestation ensures committee length"
 
-    # How many votes were in the attestation minues the votes that are the same
+    # How many votes were in the attestation minus the votes that are the same
     return bitsScore - aggregation_bits.countOverlap(xxx[])
 
   # Not found in cache - fresh vote meaning all attestations count
@@ -958,7 +958,7 @@ proc getElectraAttestationsForBlock*(
 
       #TODO: Merge candidates per block structure with the candidates one
       # and score possible on-chain attestations while collecting candidates
-      # (previous loop) and reavaluate cache key definition
+      # (previous loop) and reevaluate cache key definition
       let
         entry2 = block:
           var e2 = entry.data
@@ -1197,7 +1197,7 @@ proc selectOptimisticHead*(
 proc prune*(pool: var AttestationPool) =
   if (let v = pool.forkChoice.prune(); v.isErr):
     # If pruning fails, it's likely the result of a bug - this shouldn't happen
-    # but we'll keep running hoping that the fork chocie will recover eventually
+    # but we'll keep running hoping that the fork choice will recover eventually
     error "Couldn't prune fork choice, bug?", err = v.error()
 
 func validatorSeenAtEpoch*(pool: AttestationPool, epoch: Epoch,
diff --git a/beacon_chain/consensus_object_pools/block_clearance.nim b/beacon_chain/consensus_object_pools/block_clearance.nim
index 2792f6d4d5..1d010acec8 100644
--- a/beacon_chain/consensus_object_pools/block_clearance.nim
+++ b/beacon_chain/consensus_object_pools/block_clearance.nim
@@ -266,7 +266,7 @@ proc addHeadBlockWithParent*(
   var cache = StateCache()
 
   # We've verified that the slot of the new block is newer than that of the
-  # parent, so we should now be able to create an approriate clearance state
+  # parent, so we should now be able to create an appropriate clearance state
   # onto which we can apply the new block
   let clearanceBlock = BlockSlotId.init(parent.bid, signedBlock.message.slot)
   if not updateState(
diff --git a/beacon_chain/consensus_object_pools/block_pools_types.nim b/beacon_chain/consensus_object_pools/block_pools_types.nim
index d7f4c34d58..6235ea2bf3 100644
--- a/beacon_chain/consensus_object_pools/block_pools_types.nim
+++ b/beacon_chain/consensus_object_pools/block_pools_types.nim
@@ -89,7 +89,7 @@ type
     ## instantiated: sync from genesis or checkpoint, and therefore, what
     ## features we can offer in terms of historical replay.
     ##
-    ## Beacuse the state transition is forwards-only, checkpoint sync generally
+    ## Because the state transition is forwards-only, checkpoint sync generally
     ## allows replaying states from that point onwards - anything earlier
     ## would require a backfill of blocks and a subsequent replay from genesis.
     ##