Ethereum devs propose new transaction type with EIP-7702

Share this article

A group of prominent Ethereum developers, including Vitalik Buterin, has proposed a new transaction type (EIP-7702) to enhance the functionality and security of Externally Owned Accounts (EOAs). The proposal aims to address common issues such as transaction batching, sponsorship, and privilege de-escalation.

According to the EIP-7702 draft, the new transaction type “adds a contract_code field and a signature, and converts the signing account (not necessarily the same as the tx.origin) into a smart contract wallet for the duration of that transaction.” The proposal is intended to offer similar functionality to EIP-3074.

The motivation behind EIP-7702 is to provide short-term functionality improvements to EOAs, increasing the usability of applications and, in some cases, allowing for improved security. The proposal outlines three particular applications: batching, sponsorship, and privilege de-escalation.

While EIP-3074 solves these use cases, the authors of EIP-7702 believe it has forward-compatibility concerns. They state that EIP-3074 “introduces two opcodes, AUTH and AUTHCALL, that would have no use in an ‘endgame account abstraction’ world where eventually all users are using smart contract wallets.”

Additionally, they argue that EIP-3074 “leads to the development of an ‘invoker contract’ ecosystem that would be separate from the ‘smart contract wallet’ ecosystem, leading to possible fragmentation of effort.”

The specification of EIP-7702 details the transaction payload format and the process of executing the transaction, which involves setting the contract code of the signing account temporarily and reverting it back to empty at the end of the transaction.

The authors provide a rationale for how EIP-7702 can convert EIP-3074 use cases, stating that “it requires fairly little work to convert an existing EIP-3074 workflow.”

They also argue that EIP-7702 is designed to be forward-compatible with future account abstraction, avoiding the creation of separate code ecosystems and the need for new opcodes that may become obsolete.

Despite the potential benefits, the authors acknowledge that EIP-7702 breaks the invariant that an account balance can only decrease as a result of transactions originating from that account, which may have consequences for mempool design and other EIPs.

As with any proposal requiring users to sign contract code, the authors emphasize the importance of user wallets being cautious about which contract_code they sign, highlighting the shared security considerations with EIP-3074.

Share this article