diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md
index 179290d99c8fd9..58525c25636ef1 100644
--- a/EIPS/eip-7702.md
+++ b/EIPS/eip-7702.md
@@ -40,7 +40,7 @@ We introduce a new [EIP-2718](./eip-2718.md) transaction, "set code transaction"
 ```
 rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
 
-authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
+authorization_list = [[chain_id, address, nonce, tx_origin, 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).
@@ -51,15 +51,16 @@ 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, for each `[chain_id, address, nonce, tx_origin, y_parity, r, s]` tuple:
 
 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. Verify that the code of `authority` is either empty or already delegated.
-4. Verify the nonce of `authority` is equal to `nonce`.
-5. Set the code of `authority` to be `0xef0100 || address`. This is a delegation designation.
-6. Increase the nonce of `authority` by one.
-7. Add the `authority` account to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).)
+3. Verify that `tx_origin` is either `null` (empty bytes) or that `tx_origin` (20 bytes) is the address this transaction originates from.
+4. Verify that the code of `authority` is either empty or already delegated.
+5. Verify the nonce of `authority` is equal to `nonce`.
+6. Set the code of `authority` to be `0xef0100 || address`. This is a delegation designation.
+7. Increase the nonce of `authority` by one.
+8. Add the `authority` account to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).)
 
 If any of the above steps fail, immediately stop processing that tuple and continue to the next tuple in the list. It will In the case of multiple tuples for the same authority, set the code specified by the address in the last occurrence.
 
@@ -121,6 +122,10 @@ An alternative to adding chain ID could be to sign over the code the address poi
 
 Unlike previous versions of this EIP and EIPs similar, the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce. Without such action, a delegation will remain valid in perpetuity.
 
+### Explicit `tx.origin` signing
+
+A signer might desire that only a specific EOA account sends the EIP-7702 transaction. If this is the case, the signer should set the `tx_origin` field of the authority list to that address. If any EOA account is allowed to send the authority transaction, the `tx_origin` field should be set to `null` (empty bytes). Note that without `tx.origin`, once a EIP-7702 transaction enters the transaction pool, this delegation authority is now immediately available to all accounts, and could thus lead to undesired or unwanted results such as being frontran by MEV.
+
 ### Self-sponsoring: allowing `tx.origin` to set code
 
 Allowing `tx.origin` to set code enables simple transaction batching, where the sender of the outer transaction would be the signing account. The ERC-20 approve-then-transfer pattern, which currently requires two separate transactions, could be completed in a single transaction with this proposal.