diff --git a/EIPS/eip-7880.md b/EIPS/eip-7880.md
index a60b03463f43eb..f3f224ec4cfcb7 100644
--- a/EIPS/eip-7880.md
+++ b/EIPS/eip-7880.md
@@ -21,9 +21,9 @@ EOFv1 as scoped in [EIP-7692] removes code introspection capabilities from the E
 
 One example is a managed proxy contract. Such a contract may want to ensure security by not allowing the proxy to be updated to a delegated address. There are also safety concerns with pointing to a delegation, as the contract may be updated to non EOF code and `EXTDELEGATECALL` will no longer be able to call the contract, due to changes outside the control of the managed proxy contract.
 
-Another example are contracts that need to ensure that the delegation has not changed over a limited scope of time, such as sponsorships. This will prevent a transaction from receiving gas sponsorship, changing the delegation, and performing an act different than what was approved. Sponsors can encode the delegation into the transaction data and verify wih this instruction.
+Another example are contracts that need to ensure that the delegation has not changed over a limited scope of time, such as sponsorships. This will prevent a transaction from receiving gas sponsorship, changing the delegation, and performing an act different than what was approved. Sponsors can encode the delegation into the transaction data and verify with this instruction.
 
-Finally, there is the case where contracts may want to de-escalate risks and only accept a small number of delegations for any given contract. To enable this validation contracts will need to be able to resolve the actual address of delegtion, not just know that one exists.
+Finally, there is the case where contracts may want to de-escalate risks and only accept a small number of delegations for any given contract. To enable this validation contracts will need to be able to resolve the actual address of delegation, not just know that one exists.
 
 To address this the essential task of the designation parsing is moved into a new opcode `EXTCODEADDRESS`, where the task of calculating the delegated address will be performed. For non-delegated accounts or empty accounts the address will be the same as the queried address.
 
@@ -52,14 +52,14 @@ EOF code which contains this instruction prior to the fork activating this instr
 - Load the code from `target_address` and refer to it as `loaded_code`
 - If `loaded_code` indicates a delegation designator (for example, prefixed with `0xef0100` as defined in [EIP-7702]) push the address of the designation onto the stack.
   - Notice: if [EIP-7702] delegation designations are updated in a future fork (such as allowing chained delegations), then this section is expected to comply with any such hypothetical changes. 
-- Otherwise, push `target_adress` onto the stack.
+- Otherwise, push `target_address` onto the stack.
 
 
 Note: If `target_address` points to an account with a contract mid-creation, then `target_address` is returned. If delegation designator points to an account with a contract mid-creation, then address of the designation is returned.
 
 Note: Only `target_address` is warmed. If a delegation is found the address that it is delegated to is not added to the `accessed_addresses`. Also, whether the delegated address is in `accessed_addresses` has no impact on the gas charged for the operation.
 
-Note: This operation staddles the line between [EIP-7702] code reading and code executing instructions.  The operation steps work as a code reading instruction, but the value returned is the resolved address as through it is a code executing instruction.
+Note: This operation straddles the line between [EIP-7702] code reading and code executing instructions.  The operation steps work as a code reading instruction, but the value returned is the resolved address as through it is a code executing instruction.
 
 ## Rationale
 
@@ -71,7 +71,7 @@ One alternative is to have a specially limited `EXTCODECOPY` that would return j
 
 ## Backwards Compatibility
 
-`EXTCODEADDRESS` at `0xea` can be introduced in a backwards compatible manner into EOFv1 (no bump to version), because `0xea` has been rejected by EOF validation prior to the actication of this EIP, and there are no EOF contracts on-chain with an `0xea` instruction which would have their behavior altered.
+`EXTCODEADDRESS` at `0xea` can be introduced in a backwards compatible manner into EOFv1 (no bump to version), because `0xea` has been rejected by EOF validation prior to the activation of this EIP, and there are no EOF contracts on-chain with an `0xea` instruction which would have their behavior altered.
 
 ## Security Considerations