diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md
index 086da297339f29..a6bf54ffc1506e 100644
--- a/EIPS/eip-7702.md
+++ b/EIPS/eip-7702.md
@@ -61,14 +61,14 @@ The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([sta
 
 #### Behavior
 
-At the start of executing the transaction, for each `[chain_id, address, nonce, y_parity, r, s]` tuple:
+At the start of executing the transaction, after incrementing the sender's nonce, for each `[chain_id, address, nonce, y_parity, r, s]` tuple do the following:
 
 1. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]`
 2. Verify the chain id is either 0 or the chain's current ID.
 3. Add `authority` to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).)
 4. Verify the code of `authority` is either empty or already delegated.
 5. Verify the nonce of `authority` is equal to `nonce`.
-6. Refund the sender `PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST` gas if `authority` exists in the trie.
+6. Add `PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST` gas to the global refund counter if `authority` exists in the trie.
 7. Set the code of `authority` to be `0xef0100 || address`. This is a delegation designation.
 8. Increase the nonce of `authority` by one.
 
@@ -80,7 +80,7 @@ Note that the signer of an authorization tuple may be different than `tx.origin`
 
 The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541.md) to designate the code has a special purpose. This designator requires all code retrieving operations follow the address pointer to fill the accounts observable code. The following instructions are impacted: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, `CALL`, `CALLCODE`, `STATICCALL`, `DELEGATECALL`.
 
-For example, `EXTCODESIZE` would return the size of the code pointed to by `address` instead of `24` which would represent the delegation designation. `CALL` would similarly load the code from `address` and execute it in the context of `authority`.
+For example, `EXTCODESIZE` would return the size of the code pointed to by `address` instead of `23` which would represent the delegation designation. `CALL` would similarly load the code from `address` and execute it in the context of `authority`.
 
 In case a delegation designator points to another designator, creating a potential chain or loop of designators, clients must retrieve only the first code and then stop following the designator chain.
 
@@ -90,7 +90,7 @@ The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-293
 
 The transaction sender will pay for all authorization tuples, regardless of validity or duplication.
 
-If a code reading instruction accesses a cold account during the resolution of delegated code, assess an additional [EIP-2929](eip-2929.md) `COLD_ACCOUNT_READ_COST` cost of `2600` gas to the normal cost. Otherwise, assess a `WARM_STORAGE_READ_COST` cost of `100`.
+If a code reading instruction accesses a cold account during the resolution of delegated code, add an additional [EIP-2929](eip-2929.md) `COLD_ACCOUNT_READ_COST` cost of `2600` gas to the normal cost and add the account to `accessed_addresses`. Otherwise, assess a `WARM_STORAGE_READ_COST` cost of `100`.
 
 #### Transaction Origination
 
@@ -215,6 +215,8 @@ With this EIP, it becomes possible to cause transactions from other accounts to
 
 While there are a few mitigations for this, the authors recommend that clients do not accept more than one pending transaction for any EOA with a non-zero delegation designator. This minimizes the number of transactions that can be invalidated by a single transaction. Another alternative would be to expand the EIP-7702 transaction with a list of accounts the caller wishes to "hydrate" during the transaction. Those accounts behave as the delegated code *only* for EIP-7702 transactions which include them in such a list, thus returning to clients the ability to statically analyze and reason about pending transactions.
 
+A related issue is that an EOA's nonce maybe incremented more than once per transaction. Because clients already need to be robust in a worse scenario (described above), it isn't a major security concern. However, clients should be aware this behavior is possible and design their transaction propagation accordingly.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).