diff --git a/EIPS/eip-7702.md b/EIPS/eip-7702.md
index b04782b4d2bfcd..107d284c7b9f09 100644
--- a/EIPS/eip-7702.md
+++ b/EIPS/eip-7702.md
@@ -8,12 +8,12 @@ status: Review
 type: Standards Track
 category: Core
 created: 2024-05-07
-requires: 2718, 2929, 2930
+requires: 2718, 2929, 2930, 3541, 3607
 ---
 
 ## Abstract
 
-Add a new transaction type that adds a list of `[address, y_parity, r, s]` authorization tuples, and converts the signing accounts (not necessarily the same as the `tx.origin`) into smart contract wallets for the duration of that transaction.
+Add a new transaction type that adds a list of `[address, nonce, y_parity, r, s]` authorization tuples, and converts the signing accounts (not necessarily the same as the `tx.origin`) into smart contract wallets for the duration of that transaction.
 
 ## Motivation
 
@@ -40,38 +40,47 @@ 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, 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 set in their EOA temporarily. The third element is a list item mimicking an optional value. When the list length is zero, consider the authorization nonce to be null. When the list length is one, consider the single integer value to be the provided nonce authorization. Other lengths and value types in this optional are invalid.
+The `authorization_list` is a list of tuples that store the address to code which the signer desires to set in their EOA temporarily.
 
 The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`.
 
 #### 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, y_parity, r, s]` tuple:
 
-1. `authority = ecrecover(keccak(MAGIC || rlp([chain_id, [nonce], address])), y_parity, r, s]`
+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 empty.
-4. If nonce list item is length one, verify the nonce of `authority` is equal to `nonce`.
-5. Set the code of `authority` to code associated with `address`.
-6. Add the `authority` account to `accessed_addresses` (as defined in [EIP-2929](./eip-2929.md).)
+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 `0xef01 || 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).)
 
 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 first occurrence.
 
-At the end of the transaction, set the code of each `authority` back to empty.
-
 Note that the signer of an authorization tuple may be different than `tx.origin` of the transaction.
 
+##### Delegation Designation
+
+The delegation designation uses the banned opcode `0xef` from [EIP-3541](./eip-3541) 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`.
+
 #### Gas Costs
 
 The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-2930.md), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`. Additionally, we add a cost of `PER_CONTRACT_CODE_BASE_COST * authorization list length`.
 
 The transaction sender will pay for all authorization tuples, regardless of validity or duplication.
 
+#### Transaction Origination
+
+Modify the restriction put in place by [EIP-3607](./eip-3607.md) to allow EOAs whose code is a valid delegation designation, i.e. `0xef01 || address`, to continue to originate transactions. Accounts with any other code values may not originate transactions.
+
 ## Rationale
 
 ### No initcode
@@ -108,9 +117,7 @@ An alternative to adding chain ID could be to sign over the code the address poi
 
 #### In-protocol revocation
 
-A hotly debated element of this EIP is the need for in-protocol revocation. Although it is possible to implement revocation logic within delegated code, for some this isn't sufficient and it is the duty of the protocol to provide a revocation option of last resort.
-
-For this reason, the proposal provides two separate schemes. The first is an eternal delegation to a smart contract. At the protocol level, it is not possible to revoke. However, the contract you delegate to is one which can expect to use in your account for perpetuity; similar to how smart contract wallet users deploy proxy contracts to their account and point the target at a wallet implementation. The second is a scoped delegation with a revocation mechanism based on the EOA's nonce. This is a safer to begin using smart contract code in the context of your EOA without potentially committing to a specific piece of code forever.
+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.
 
 ### Self-sponsoring: allowing `tx.origin` to set code