diff --git a/EIPS/eip-8052.md b/EIPS/eip-8052.md
index 9a6bb7acdd1627..dbe5394930e6d4 100644
--- a/EIPS/eip-8052.md
+++ b/EIPS/eip-8052.md
@@ -346,7 +346,7 @@ The following requirements MUST be checked by the precompiled contract to verify
 * Verify that the salt in the signature is 40-bytes long.
 
 **Gas burning on error**
-if one of the above condition is not met then all the gas supplied along with a CALL or STATICCALL is burned.
+if one of the above conditions is not met then all the gas supplied along with a CALL or STATICCALL is burned.
 it shall also be burned if an error happens during decompression (incorrect encodings).
 
 
diff --git a/EIPS/eip-8061.md b/EIPS/eip-8061.md
index af7cf7f6b651dc..de36862c5c653e 100644
--- a/EIPS/eip-8061.md
+++ b/EIPS/eip-8061.md
@@ -99,7 +99,7 @@ def compute_weak_subjectivity_period(state: BeaconState) -> uint64:
 
 ### Deposit processing
 
-The only modification is replacing `get_activation_exit_churn_limit` with `get_activation_churn_limit`, maintaing the current cap on deposit churn respects, while removing the cap from exits. This reverts to the pre-Electra status quo, when activations were capped but exits were not.
+The only modification is replacing `get_activation_exit_churn_limit` with `get_activation_churn_limit`, maintaining the current cap on deposit churn respects, while removing the cap from exits. This reverts to the pre-Electra status quo, when activations were capped but exits were not.
 
 ```python
 def process_pending_deposits(state: BeaconState) -> None:
diff --git a/EIPS/eip-8068.md b/EIPS/eip-8068.md
index 63c108da7a1eea..d9700f21b7df89 100644
--- a/EIPS/eip-8068.md
+++ b/EIPS/eip-8068.md
@@ -128,7 +128,7 @@ The blue line is compounding `0x02` validators, which on average will have 0.75
 
 The red lines capture `0x02` validators that repeatedly withdraw down to the downward hysteresis threshold at $-0.25$ relative to an integer EB, thus achieving a surplus 0.25 EB relative to their actual balance. They let the balance grow until it is optimal to withdraw it, accounting for a partial withdrawal costing 84500 gas. So for example, starting at 32.75 ETH and with a 0.5 gwei base fee, that works out to making the withdrawal at around 32.80 ETH. The staker then earns 0.56% more staking yield than the baseline, factoring in a 4.5 days delay between when the withdrawn ETH stops earning yield and when it is available at the EL (dashed red line). This delay accounts for a 256 epoch withdrawal eligibility period and an average wait time until the sweep hits of 3.4 days (at a hypothetical future 770 000 active validators). Without the delay, that figure is 0.60%. When the base is 0 and there is a 4.5 days delay, the validator instead earns 0.72% more staking yield (full red line).
 
-The green circles are sweeped `0x01` validators. They earn slightly less than the baseline due to the accruing balance in excess of 32 ETH and 2048 ETH not counting toward the EB, and being delayed by around 3.4 days.  (in this specific example where the delay )
+The green circles are swept `0x01` validators. They earn slightly less than the baseline due to the accruing balance in excess of 32 ETH and 2048 ETH not counting toward the EB, and being delayed by around 3.4 days.  (in this specific example where the delay )
 
 This comparison could be nuanced further by potentially accounting for a deposit delay, but the ETH does not necessarily need to be deposited directly into the staking contract to bring value to its holder. Another nuance is that a slashing is driven by EB and not validator balance.
 
diff --git a/EIPS/eip-8077.md b/EIPS/eip-8077.md
index a1f03e910d91e3..c84c159b118a0e 100644
--- a/EIPS/eip-8077.md
+++ b/EIPS/eip-8077.md
@@ -44,7 +44,7 @@ At the receiver side of `NewPooledTransactionHashes` messages the extra informat
 
 ## Rationale
 
-To solve the transaction propagation issues mentioned in the Motivation section, nodes require more information about a transaction then its hash, size, and type. By adding the source and the nonce, the receiver has enough information to make better fetch decisions.
+To solve the transaction propagation issues mentioned in the Motivation section, nodes require more information about a transaction than its hash, size, and type. By adding the source and the nonce, the receiver has enough information to make better fetch decisions.
 
 ### Overhead