Vitalik Buterin's proposal of Ethereum Improvement Proposal (EIP) 7702 has sent ripples across the world of blockchain and beyond, as it directly influences every wallet and externally owned account (EOA). But does it make sense for every use case? In this post, we’re exploring why it matters, the most important technical intricacies, and the broader implications — with a particular eye on costs, assumptions around trust assumptions, and flexibility.

Ultimately, we believe that it comes down to the use case: While EIP-7702 may make sense for fully self-custodial models, EIP-3074 is generally the right choice for hybrid models that already inherit some trust, like embedded wallets.

Putting EIP-7702 in context

‍

As the table shows, EIP-7702 is notably feature-rich, and has some interesting trade-offs to consider around cost and trustworthiness.

In terms of the technical details, EIP-7702 introduces a novel transaction type: It transiently sets an EOA's code to a contract code during the execution of a transaction. This functionality mirrors EIP-3074 — but in a more forward-compatible fashion. The transaction type involves fields for contract_code and a signature. Upon execution, it temporarily sets the EOA's code to contract_code, performs the transaction according to this code, and then reverts the code to empty.

Understanding gas costs

A critical aspect of EIP-7702 is its gas costs. Here’s one example:

1000 + 16 * nonzero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count + 16 * nonzero calldata bytes + 4 * zero calldata bytes over each contract_code + PER_CONTRACT_CODE_BASE_COST * len(contract_code array)

Let’s assume a minimal proxy contract bytecode size of 50 bytes, no address or storage key access list, and 56 non-zero calldata bytes. In this case, an EIP-7702 erc20 transfer would get to a base cost of ~50% against its EOA transfer. This is already significantly higher.

And if we include nonce verification enforcement and other safety checks for important things like permission revocation, we pretty much double gas fees against the same transactions directly from the EOA — and would in theory far exceed EIP-3074 if the invoker moves a lot of the additional safety checks off-chain.

The benefits for complex scenarios and composability

While EIP-7702 is more expensive for simple transfers, its benefits are more readily apparent for complex scenarios. For example, batching multiple operations in a single transaction mitigates some of the base costs, rendering it more gas-efficient than executing each operation separately. On top of this, EIP-7702 facilitates sponsored transactions, enabling fee payment from an account distinct from tx.origin — which offers additional flexibility in cost optimization.

This flexibility allows EOAs to opt for the cheaper option whenever possible, depending on the use case. In other words, EOAs could still go for a cheaper EIP-3074 if costs are the main concern. That's one of the most important benefits of this EIP: composability with other powerful features like 3074.

Navigating trust

One important consideration is that trust assumptions still mostly reside within wallets. EOA owners must diligently audit any contract code they endorse if they want to thwart potential vulnerabilities, malicious code that could drain funds, or other unintended actions during execution. But given the complexity of smart contract bytecode, most users simply won’t do this.

And that means users are reliant on wallets and interfaces to manage and present the information accurately, if they do so at all. When taken all together, this underscores the real need for robust safety tools and solutions.

Revocation and costs

Revocation mechanisms in EIP-7702 are less straightforward than EIP-3074's native nonce-based approach. Some solutions to this include signing over account nonce or integrating nonce management into the contract code. EIP-3074, on the other hand, is simpler and remains cheaper if the user is comfortable delegating trust to an invoker. The user can always bump their account nonce to revoke the permission delegation, providing a more straightforward revocation mechanism.

The choice of revocation method in EIP-7702 depends on the specific use case and risk tolerance. The proposal itself leans towards allowing the authorized code to handle its own replay protection and access control rather than enforcing it at the protocol level.

Nonce management & permission revocation is now the biggest topic of conversation as there are different ways to tackle it including introducing a max nonce that would represent an expiration, allowing many transactions to be routed through the smart contract inside a nonce window. Signing over a max nonce would introduce large trust issues as getting a user to sign a large max nonce would essentially render the wallet forever compromised.

Custom logic, checks, and restrictions can be added beyond simple contract calls to add layers of safety. While there would be a large gas overhead compared to direct-from-wallet operations, EIP-7702 enables advanced use cases and can be more gas-efficient for complex operations that would otherwise require multiple transactions.

EIP-7702 gas cost overhead compared to EIP-3074 would scale with the size of the contract bytecode, forcing relayers to carefully consider safety features.

Putting it all together

Ultimately, deciding whether or not to use EIP-7702 comes down to a clear understanding of the tradeoffs and your own use case: That often means weighing flexibility and functionality against increased base costs and trust assumptions.

There may still be some fragmentation between EIP-7702 and the full ERC-4337 smart contract wallet ecosystem — but overall it should play nicely with most existing paymaster infrastructure, without the commitment of dedicated long-lived contracts to manage.

Costs remain the primary concern, but there are optimization conversations happening, specifically pointing at an existing deployed contract (direct to address instead of code), delegatecall forwarders, and ERC-1167 minimal proxies.

Taken all together, EIP-7702 fills an important gap in the matrix of options, striking the balance between complexity, costs, flexibility, and composability. EOAs will be able to decide if they want to use direct transactions, EIP-3074, EIP-7702, or full-blown ERC-4337. It’s all about the specific use case and tradeoffs. And in general, that means that for self-custody solutions, EIP-7702 may have more benefits — but for embedded wallets, EIP-3074 makes the most sense.