EIP 7702 - proposed changes breakout session

Current 7702 spec

Before 7702 EIP ethereum had 2 types of accounts

1. EOAs: an account that is tightly coupled to a ECDSA key pair holding user assets, signature from private key is required to move assets
2. SCAs: smart contract acting as a user account that holds assets, successful execution of code is required to move assets

SCAs are preferred option over EOAs because they have 3 great UX properties.

1. Batching
2. Paymasters
3. Security (multi-sig, social recovery)

The current 7702 spec defines a third type of account:

• Migrated EOA: an account with smart contract code which can move assets both after successful code execution or transaction from a private key

Note, the 7702 spec remains in active development. The change from ephemeral to persistant was merged 2 weeks ago and our conversations with wallet teams showed half of them were not aware of these changes.

It is important to make sure the 7702 proposal is mindful of the needs of the stakeholders it aims to serve.

Short falls of the current EIP-7702:

1. Bypassing on-chain policies: Since the EOA private key is still the super user, it means that we get 2 of 3 benefits of SCA (batching, paymasters). But cannot get security aspects i.e. multi-sig, social recovery or cross-chain features eg resource locks.
2. Network DOS: The mempool DOS properties for EOAs and smart contract are robust, but some DOS vectors of a new account type still exist. Several mitigations have been suggested, but will require additional work before considered robust.

Proposed changes

The core of the suggested changes is to remove the ability of EOAs to make transactions when the account has code. So instead of creating a new type of account, have a mechanism to cleanly switch between EOA and SCA account types.

The following changes would be made to the EIP:

1. Disable EOA transaction origination (enable 3607): Continue to prevent an account with code from originating a transaction, as specified in EIP-3607.
2. CODERESET opcode: The account can return to acting as an EOA through a CODERESET OPCODE which deletes its code. CODERESET only removes code and not the state of the account. The SCA needs to call the CODERESET method via a contract call to enable switching back to EOA.
3. Optional calldata: An optional calldata field should be added to the signed 7702 transaction. This is so that the user can properly initialize the storage variables of the SCA.

Wallet teams who support the above proposal are: Argent, Chainsafe, Fireblocks, Metamask, OneBalance, Rabby, Safe, Trustwallet, Walletconnect, Zerion, 4337 team. Note, many wallet teams are suffering from 7702 fatigue. Whilst they support these proposed changes, the most important is not to delay 7702 from its inclusion in Pectra.

Benefits of the suggested changes

1. DOS resistance for free
2. Policy compatibility
3. Timelock compatibility
4. Ephemerality compatibility

In defense of enabling 3607 (disable EOA txn origination)

There are 2 main arguments against enabling 3607:

1. erecover based permits exist and this means that migrated EOA wallets can still have their assets lost if they leak their private keys. "it's difficult to communicate to a user that even though they have "upgraded" their EOA to a scw their original pk is still toxic"
2. In-protocol revocation If an EOA delegates to a buggy or malicious contract, they can now delegate to a new implementation, or if they want to return to being a pure EOA, they can simply delegate to the zero address or their own address.

ERECOVER
There are 3 points against this issue:

1. In the last 365 days, 99.85% of transactions are not impacted by erecover based permits ref. More than 99.9% of L1 FDV belongs to tokens who dont support permits ref. Most notable are ARB and ENS (>500M Mcap) (USDC and stETH support 1271).
2. If the private key of an account leaks then more funds are at risk if EOA is root user vs if only assets with Permit are at risk.
3. This is an education issue. We cannot expect retail users to understand all intricacies of how clicking a button will effect their account. 50% of the wallet teams dont know what is the latest version of 7702, we cannot expect this level of detail from the user. The best place to educate the user is on the wallet layer by showing them a big red box saying "please keep your private keys secure" before clicking the migrate button.

In-protocol revocation
This is a valid argument, and at the root of the debate. Who should have the root power. Is is the private key or the smart contract code? There are good arguments on both the sides. We hope to come to some conclusion at this breakout.

In defense of CODERESET

The Codereset OPCODE can be called from inside the smart contract to delete code and not its storage. There are 2 main arguments against this:

1. New OPCODE: Adding a new OPCODE increases complexity and might push back the development time.
2. Storage slot collisions: Being able to switch to a new implementation means there will be storage collisions. There will be issues similar to Parity hack.

New OPCODE
We propose to reuse the SELFDESTRUCT OPCODE in context of a migrated EOA, such that it can only delete the code pointer and not storage. This means that this is not a new opcode but reusing of an old one.

Storage slot collisions
Storage slot collisions exist in all smart contract upgrades. Any smart contract wallet implementations have to deal with this issue. Two mitigation paths have been proposed for this, which need to be implemented regardless of 7702.

In defense of optional calldata

Main reason for opposing optional calldata is that it increases complexity of the EIP.
Increases complexity
Wallet teams will have to manage two different versions of wallet code one which is 7702 compatible and one which is not.