Introduction The purpose of this document is to: bring attention to concerns brought up over “code introspection” behavior for EIP-7702 delegated Externally Owned Accounts (EOAs) relate the rationale for this current spec to the EVM Object Format (EOF) upgrade propose a slight behavior change to EIP-7702 as a result of this analysis Both upgrades, especially EOF, are complex. We encourage readers to research them independently, but this document will attempt to explain “code introspection” as it relates to each upgrade, and separate out a notion of “delegation introspection” from that of “code introspection”.

Introduction EIP-7702, scheduled for inclusion in the Pectra hard fork (Q1 2025), is arguably the most powerful Account Abstraction proposal for Ethereum to date. While the EIP was first drafted only 3 months ago, it has seen significant changes over its lifetime and has attracted impassioned debate from across the ecosystem. The current version of EIP-7702 (thanks to the work of Matt Garnett, aka lightclient, and many others) is an elegant revision of the original proposal that solves almost all concerns—notably in-protocol revocation for EIP-7702 delegations. However, additional counter-proposals have started to emerge that aim to radically and unnecessarily alter the EIP. The EIP Process Ethereum is decentralized by design, with no central-planning body—no one “owns” the EIP process. This is undoubtedly a good thing, but it means reaching consensus can be very difficult. Of course, there is nothing stopping contributors from presenting new proposals to replace existing ones. However, counter-proposals may have drawbacks—they: may be written by a single organization or small group, resulting in narrow proposals that don’t represent the needs of the broader ecosystem may not actually solve outstanding issues with existing proposals

[EIP-7702] Response to CODERESET Proposal + Reflection on the Current Spec’s State Introduction The recent proposal “CODERESET for EIP 7702” brings a new set of suggested changes to EIP-7702. These changes are unlikely to seem necessary or appeal to all teams building products on the proposed protocol changes. More importantly, this proposal highlights the need for balance between safety and keeping the design space open to allow for innovation. Like most teams building on EIP-7702 and contributing to the discussions around it, we are a for-profit business that wants to bring new products to the ecosystem. We see new opportunities to make Ethereum useful for people. As much as it would make sense from a business standpoint, we do not want EIP-7702 tailored to our specific needs. We want these changes to be open-ended enough such that people can innovate and new things can be built. We think this is the correct approach for a decentralized ecosystem. Our Stance We are in favor of: