7702: fixup some prose

Author: lightclient

EIPS/eip-7702.md

@@ -1,7 +1,7 @@
 ---
 eip: 7702
-title: Set EOA account code for one transaction
-description: Add a new tx type that sets the code for an EOA during one transaction execution
+title: Set EOA account code
+description: Add a new tx type that sets the code for an EOA during execution
 author: Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), Matt Garnett (@lightclient)
 discussions-to: https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923
 status: Review
@@ -13,7 +13,7 @@ requires: 2718, 2929, 2930, 3541, 3607
 
 ## Abstract
 
-Add a new transaction type that adds a list of `[address, nonce, y_parity, r, s]` authorization tuples, and deploy a delegation designator to the signing accounts so calls into the accounts execute the code at associated `address`.
+Add a new transaction type that adds a list of `[chain_id, address, nonce, y_parity, r, s]` authorization tuples. For each tuple, write a delegation designator `(0xef0000 ++ address)` to the signing account's code. All code reading operations must load the pointed to by the designator.
 
 ## Motivation
 
@@ -45,7 +45,7 @@ authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
 
 The fields `chain_id`, `nonce`, `max_priority_fee_per_gas`, `max_fee_per_gas`, `gas_limit`, `destination`, `value`, `data`, and `access_list` of the outer transaction follow the same semantics as [EIP-1559](./eip-1559.md).
 
-The `authorization_list` is a list of tuples that store the address to code which the signer desires to point to from their EOA.
+The `authorization_list` is a list of tuples that store the address to code which the signer desires to execute in the context of their EOA.
 
 The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`.
 
@@ -155,7 +155,7 @@ Specifically:
 * The "code pathways" that are used are code pathways that would, in many cases (though perhaps not all), continue to "make sense" in a pure-smart-contract-wallet world.
 * Hence, it avoids the problem of "creating two separate code ecosystems", because to a large extent they would be the same ecosystem. There would be some workflows that require kludges under this solution that would be better done in some different "more native" under "endgame AA", but this is relatively a small subset.
 * It does not require adding any opcodes, that would become dangling and useless in a post-EOA world.
-* It allows EOAs to temporarily convert themselves into contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`.
+* It allows EOAs to masquerade as contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`.
 * Once this is implemented, allowing EOAs to migrate permanently is "only one line of code": just add a flag to not set the code back to empty at the end.
 
 ## Backwards Compatibility