Update EIP-7880: fix typos

EIPS/eip-7880.md

@@ -23,7 +23,7 @@ One example is a managed proxy contract. Such a contract may want to ensure secu
 
 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.
 
-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 though it is a code executing instruction.
 
 ## Rationale
 

EIPS/eip-7910.md

@@ -111,7 +111,7 @@ Future forks MUST define the list of system contracts in their meta-EIPs.
 
 The purpose of this specification is to enable nodes to advertise, prior to a fork, that they have the correct configurations loaded and ready. Past testnet and mainnet forks have revealed clients with incorrect precompile sets, chain IDs, deposit contract addresses, and other configuration errors.
 
-For precompiles in particular there has been discussion about removing or replacing precomiles in future forks, so a full enumeration of precompiles will reflect removal.
+For precompiles in particular there has been discussion about removing or replacing precompiles in future forks, so a full enumeration of precompiles will reflect removal.
 
 Generally, if a configurable variable or constant causes a client to diverge at a fork—whether on mainnet, a testnet, a devnet, or a public rollup—that variable or constant is a candidate for inclusion in the reportable configuration.