Update EIP-7377: Fix some nits

Merged by EIP-Bot.

EIPS/eip-7377.md

@@ -21,9 +21,9 @@ Smart contract wallets have long been touted as the solution to Ethereum's user
 
 Today, account abstraction is still an important goal in Ethereum and there are many efforts attempting to realize it. We're getting closer to succeeding at this, but unfortunately the years of failure have caused many users to simply rely on EOA.
 
-After a user as accumulated enough assets in an EOA, it is not tenable to migrate each individual asset to a new address. This is due both to the cost and to needing to manually sign and verify potentially hundreds of transactions.
+After a user has accumulated enough assets in an EOA, it is not tenable to migrate each individual asset to a new address. This is due both to the cost and to needing to manually sign and verify potentially hundreds of transactions.
 
-This is an overlooked piece of the problem. Converting *existing* users to smart contract wallets efficiently, will expedite adoption and push forward better support and integrations for smart contract wallets. They will no longer be dismissed as a niche use case.
+This is an overlooked piece of the problem. Converting *existing* users to smart contract wallets efficiently will expedite adoption and push forward better support and integrations for smart contract wallets. They will no longer be dismissed as a niche use case.
 
 Therefore, we must provide a mechanism, embedded in the protocol, to migrate EOAs to smart contracts. This EIP proposes such mechanism.
 
@@ -42,7 +42,7 @@ At the fork block `X`, introduce the migration transaction type.
 | `maxFeePerGas`         | `int256`  |
 | `maxPriorityFeePerGas` | `int256`  |
 | `gasLimit`             | `uint64`  |
-| `codeAddr`              | `address` |
+| `codeAddr`             | `address` |
 | `storage`              | `List[Tuple[uint256, uint256]]` |
 | `data`                 | `bytes`   |
 | `value`                | `int256`  |
@@ -51,9 +51,9 @@ At the fork block `X`, introduce the migration transaction type.
 | `r`                    | `uint256` |
 | `s`                    | `uint256` |
 
-The EIP-2718 `TransactionType` is `0x04` and the `TransactionPayload` is `rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storageTuples, data, value, accessList, yParity, r, s])`.
+The EIP-2718 `TransactionType` is `0x04` and the `TransactionPayload` is `rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storage, data, value, accessList, yParity, r, s])`.
 
-The transaction's signature hash is `keccak256(0x04 || rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storageTuples, data, value, accessList])`
+The transaction's signature hash is `keccak256(0x04 || rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storage, data, value, accessList])`
 
 #### Validation
 
@@ -67,7 +67,7 @@ The intrinsic gas calculation modified from [EIP-1559](./eip-1559.md) to be `210
 
 #### Processing
 
-Executing a migration transaction transaction has two parts.
+Executing a migration transaction has two parts.
 
 ##### Contract Deployment
 
@@ -101,7 +101,7 @@ Additionally, the EOA already exists because it has enough balance for the migra
 
 ### Manipulating transaction origin
 
-Many applications have a security check `caller == origin` to verify the caller is an EOA. This is done to "protect" assets. While it is usually more of a bandage than an actual fix, we attempt to placate these projects by modifying the origin of the transaction so the check will continue performing it's duty.
+Many applications have a security check `caller == origin` to verify the caller is an EOA. This is done to "protect" assets. While it is usually more of a bandage than an actual fix, we attempt to placate these projects by modifying the origin of the transaction so the check will continue performing its duty.
 
 ### One-time migration
 
@@ -113,7 +113,7 @@ No backward compatibility issues found.
 
 ## Security Considerations
 
-As with all sufficiently sophisticated account designs, if a user can be convinced to sign an arbitrary message, that message could be MigrationTransaction which is owned by a malicious actor instead of the user. This can generally be avoided if wallets treat these transactions with *extreme* care and create as much friction and verification as possible before completing the signature.
+As with all sufficiently sophisticated account designs, if a user can be convinced to sign an arbitrary message, that message could be a migration transaction which is owned by a malicious actor instead of the user. This can generally be avoided if wallets treat these transactions with *extreme* care and create as much friction and verification as possible before completing the signature.
 
 ## Copyright