diff --git a/EIPS/eip-6492.md b/EIPS/eip-6492.md
index f7aecce1bcab2..6a136b6fec633 100644
--- a/EIPS/eip-6492.md
+++ b/EIPS/eip-6492.md
@@ -13,7 +13,7 @@ requires: 1271
 
 ## Abstract
 
-Contracts can sign verifyable messages via [ERC-1271](./eip-1271.md).
+Contracts can sign verifiable messages via [ERC-1271](./eip-1271.md).
 
 However, if the contract is not deployed yet, [ERC-1271](./eip-1271.md) verification is impossible, as you can't call the `isValidSignature` function on said contract.
 
@@ -117,7 +117,7 @@ contract UniversalSigValidator {
   ) public returns (bool) {
     uint contractCodeLen = address(_signer).code.length;
     bytes memory sigToValidate;
-    // The order here is striclty defined in https://eips.ethereum.org/EIPS/eip-6492
+    // The order here is strictly defined in https://eips.ethereum.org/EIPS/eip-6492
     // - ERC-6492 suffix check and verification first, while being permissive in case the contract is already deployed; if the contract is deployed we will check the sig against the deployed version, this allows 6492 signatures to still be validated while taking into account potential key rotation
     // - ERC-1271 verification if there's contract code
     // - finally, ecrecover
@@ -245,7 +245,7 @@ Furthermore, it is likely that this ERC will be more frequently used for off-cha
 
 One out-of-scope security consideration worth mentioning is whether the contract is going to be set-up with the correct permissions at deploy time, in order to allow for meaningful signature verification. By design, this is up to the implementation, but it's worth noting that thanks to how CREATE2 works, changing the bytecode or contructor callcode in the signature will not allow you to escalate permissions as it will change the deploy address and therefore make verification fail.
 
-It must be noted that contract accounts can dynamically change their methods of authentication. This issue is mitigated by design in this EIP - even when validating counterfactual signatures, if the contract is already deployed, we will still call it, checking against the current live versoin of the contract.
+It must be noted that contract accounts can dynamically change their methods of authentication. This issue is mitigated by design in this EIP - even when validating counterfactual signatures, if the contract is already deployed, we will still call it, checking against the current live version of the contract.
 
 As per usual with signatures, replay protection should be implemented in most use cases. This proposal adds an extra dimension to this, because it may be possible to validate a signature that has been rendered invalid (by changing the authorized keys) on a different network as long as 1) the signature was valid at the time of deployment 2) the wallet can be deployed with the same factory address/bytecode on this different network.