Ultimate Guide to EIP-3074 & EIP-7702

What is EIP-3074?

EIP-3074 was initially proposed as a way to extend the functionality of EOAs without converting them into full smart contracts. It introduced two new EVM opcodes, AUTH and AUTHCALL, allowing a user to sign a message authorizing a contract, called an invoker, to perform transactions on their behalf.

This would enable gasless transactions, delegated permissions, and multi-action batching within a single signature flow. In effect, it allowed EOAs to outsource functionality to smart contracts temporarily, achieving many benefits of account abstraction without changing the account type itself.

However, EIP-3074 came with notable architectural risks. Introducing new EVM opcodes increases the complexity of Ethereum’s virtual machine, adding maintenance overhead and long-term rigidity.

More critically, the security model of EIP-3074 relies heavily on the invoker contract. Since multiple users might rely on the same invoker logic, a vulnerability or exploit in one invoker could compromise the assets or permissions of many users simultaneously. This shared-risk model limited the flexibility and futureproofing potential of 3074.

What is EIP-7702?

EIP-7702, a newer proposal authored by Vitalik Buterin, builds upon the goals of 3074 while addressing its shortcomings. Unlike 3074, EIP-7702 does not require any changes to the Ethereum Virtual Machine (EVM). Instead, it leverages Ethereum’s existing transaction framework to allow an EOA to temporarily behave like a smart contract for the duration of a single transaction.

Under EIP-7702, a user can attach a piece of executable smart contract code to a transaction. This code is run as if it were deployed at the user’s address, meaning the user can execute advanced logic, perform batched actions, or pay gas using tokens.

Crucially, once the transaction completes, the EOA’s address returns to its original state, with no residual contract code left behind. This stateless approach avoids the overhead of deploying a smart wallet while providing most of the benefits of one.

One of the defining characteristics of EIP-7702 is its per-transaction modularity. Because the logic is temporary, each transaction can be tailored to execute a unique flow—be it trading, bridging, or even session-based access control—without affecting the user’s broader wallet setup.

This provides an elegant, future-proof foundation for wallet abstraction that avoids protocol bloat and invites seamless integration by wallet providers and developers.

What Problems Do EIP-3074 and EIP-7702 Solve?

The Ethereum community has long talked about the drawbacks of Externally Owned Accounts (EOAs), which are the most common account type used by most users. EOAs are widely supported, easy to use, and safe, however, they don't have programmable features. To avoid the requirement for a separate smart contract wallet, EIPs 3074 and 7702 were proposed. These will allow user accounts to offer smart features like batching, gas sponsorship, and delegated authority.

In order to improve EOA capabilities without compromising compatibility, EIP-3074 and EIP-7702 were developed. With the use of two new opcodes, EIP-3074 gives EOAs the ability to assign transaction privileges to a contract. In the meantime, EIP-7702 enables EOAs to set a code pointer to operate as smart contracts for the duration of a single transaction. Through ERC-4337, both EIPs aim to provide wallet functionality without exposing users to the full complexity of account abstraction.

Implications for Users, Wallets, and Contracts

For End Users: A considerably smoother UX is offered by these EIPs. Users have the option to have a dApp sponsor their gas or approve and submit in a single step. For example, EIP-7702 has enabled users to pay for gas in tokens (such as stablecoins) instead of ETH using Trust Wallet. 

A user may assign a spending-limit key to a buddy or service, or they may sign a single message allowing a series of operations. Users are able to "upgrade" their existing addresses at any time, maintaining their accounts and balances. Users must be aware, nevertheless, that they are depending on new mechanisms, such as relying on the safety of delegate code in 702 or an invoker contract in 3074. 

In order to prevent phishing, wallet interfaces must make it obvious when this type of delegation is taking place. Several developers have cautioned that EIP-7702 may create a new channel for phishing attacks if users are duped into giving up control.

For Wallet Providers: To accommodate the new functions, wallet software must be updated. The unique batch message that an invoker uses for EIP-3074 is generated and signed by wallets. It will be necessary for wallets to create the new set-code transaction for EIP-7702 (containing the delegation tuples) and maybe provide the user the code-ptr. On launch day, the self-custodial Ambire (formerly AdEx) and Trust Wallet announced support for Pectra/EIP-7702, demonstrating how swiftly some wallets are evolving in practice. The ability for users to "temporarily act as smart contracts" with their current keys is highlighted by these wallets. It is anticipated that large wallets will eventually include these functionalities (probably as opt-in), allowing for sophisticated actions and token payments without the need for new addresses for transactions.

For Smart Contracts and dApps: Transactions with an EOA with code inserted into msg.sender may be seen by contracts. When using an EOA's address as the caller in a sophisticated manner, developers should test the behavior of their contracts. As previously indicated, it may be necessary to evaluate any tests that depend on tx.origin to be the original EOA (the reasoning behind EIP-7702 points out that current msg.sender == tx.origin checks might break in deeper calls). While certain contracts may additionally take into account sponsoring flows or enabling meta-transactions, 3074/7702 allows the logic to mostly be contained in an invoker or delegate contract. In general, dApp developers acquire new design patterns, such as the ability to instantly establish applications that combine user transactions into sponsored transactions. Security audits must take into account the new "authorization" flows.

Net Effect: The distinction between EOAs and smart contracts is essentially blurred by these approaches. EOAs will be able to safely transfer transaction approval to contracts (through 3074) or execute code-driven logic (through 7702). This is a significant step toward the long-term goal of native account abstraction, even though it is still in its early phases. (A more difficult objective for the future is full account abstraction, in which all transactions are sender-driven logic.)

Comparing EIP-3074 vs EIP-7702

• Common Objective: To increase flexibility and user experience, both seek to expand EOAs with smart-contract-like capabilities (batching, sponsorship, and delegated authority). The same account-abstraction environment (post-ERC-4337) gave rise to them.
• Mechanism: 3074 gives contracts the ability to use the two new EVM opcodes (AUTH/AUTHCALL) for proxy calls at runtime. A code pointer is set (written) into the EOA's account for that transaction via the new transaction type introduced in 7702. The EOA's code is temporarily changed in 7702, therefore, no new opcodes are required. In summary, 7702 is one-shot code injection through a transaction, whereas 3074 is call delegation using opcodes.

• Persistence: The authorization granted by 3074 is strictly per-transaction and temporary; the EOA remains unchanged when the transaction is completed. Although 7702 was initially intended to target just one transaction, the final design permits the delegation reference to remain in place until it is specifically deleted. Accordingly, an EOA may continue to be "smart" under 7702 for some activities until the user revokes it.
• New Protocol Features: The strategy used in 3074 would have included opcodes, a change to the EVM that is incompatible with the past. By avoiding opcodes, 7702 simplifies toolchains and prevents the addition of "dead" instructions in the future. One of the main reasons for choosing 7702 was this difference: it produces comparable results using "no new opcodes" and simplified static analysis. 
• Security Trade-offs: 3074 mandates that you trust an external invoker contract every time. (Wallets are likely to whitelist trusted invokers.) 7702 instead has the EOA carry the logic, however, at its own risk (the EOA's code is updated). Some experts believe 7702 is safer because it does not require a central invoker pattern and integrates more cleanly into the protocol. (For example, Safe Global claims that 3074 "raised concerns" about user experience and security, but 7702 addressed those problems while maintaining the original objective.)
• Complementary Use: 3074 was specifically proposed to be replaced by 7702 in practice. The developers on core-dev calls observed that 7702 "achieves comparable results to EIP-3074, but with the advantage of not generating new opcodes." Galaxy Research indicates that the intention is to eliminate 3074 if 7702 is implemented, as it is capable of delivering the same capabilities more efficaciously. As a result, 7702 supersedes 3074, rather than being used in conjunction. They would have a significant overlap in purpose if they were both operational. Some multi-party flows that 7702 does not expressly enable may be permissible under 3074's invoker model; however, these flows can typically be implemented with 7702 through contract code.

Both EIPs target the same problem space (account abstraction), but 7702 is a more recent, streamlined solution. It is compatible with ERC-4337 entrypoint schemes and was designed to avoid technical debt. Indeed, Ethereum core dev discussions in mid-2025 treated 7702 as the preferred path forward, essentially sidelining 3074.

Status (as of Mid-2025) & Timeline

• EIP-3074 – Withdrawn: Sam Wilson, along with others, introduced EIP-3074 in 2020. As a proposal for Ethereum's Prague/Pectra upgrade (2025), it garnered momentum and underwent test implementations. By the second quarter of 2024–2025, its future was uncertain. According to the notes of the Core Dev meeting, 3074 encountered sufficient opposition to impede its implementation following intensive discussion. During the May 2025 core-dev "Execution" call (#187), developers consented to maintain 3074's functionality on early development networks, but they were already planning to supplant it with 7702. "Withdrawn" is the current status of EIP-3074 in the official monitoring system. Therefore, it will not be activated in the mainnet (as of mid-2025, it is not an option). 7702 and related proposals continue to embody their concepts.
• EIP-7702 – Last Call / Pectra (May 2025) Upgrade: Vitalik Buterin introduced EIP-7702 on May 7, 2024, and it was reportedly drafted in 22 minutes. It achieved "Last Call" status on the EIP repo (peer review) after discussion and refinement through late 2024. It was scheduled for incorporation in the forthcoming Pectra network upgrade by early 2025. ("Pectra" bundles Prague + Electra EIPs; originally scheduled for February 2025, but subsequently rescheduled for May 7, 2025.) Pectra's incorporation of account-abstraction EIPs, particularly EIP-7702, is confirmed by the Paxos support article. Teams prepared implementations on devnets: By May 2025, Galaxy reports that the majority of clients had implemented Pectra code, and EF testers were composing test cases for EIP-3074 and other products (with 3074 initially enabled but 7702 in flight).

EIP-7702 is anticipated to be operational with Pectra by mid-2025. Major wallets (Ambire, Trust) have already implemented support for Pectra features, and all client teams have been engaged in the project. Safe.7702 is "planned for inclusion" in Pectra and is currently undergoing refinement, according to a global analysis. In conclusion, EIP-7702 is currently in the final phases of review and is expected to be activated on the mainnet during the scheduled Pectra fork in May 2025.

• Key Discussions: There was a significant amount of community discourse during the development of both EIPs. Vitalik's 7702 post is one example of the threads on 3074 and 7702 in the Ethereum Magicians forums. These topics were extensively discussed in Core Dev conversations #187 and others (as summarized by Galaxy/EF). In May 2025, developers acknowledged that 7702 replaced 3074, as it "achieves similar outcomes... without creating new opcodes." These notes underscore this fact. In conclusion, the official EIP pages (ethereum.org) indicate that 3074 has been withdrawn and 7702 has been marked as the last call. As Pectra approaches, Ethereum blog posts and etherscan trackers will be updated.

Timeline Recap: EIP-3074 was first proposed in October 2020, deliberated from 2021 to 2024, and then withdrawn in 2024–2025. EIP-7702 was first proposed in May 2024, improved upon in late 2024, went into Last Call in early 2025, and is scheduled to be activated in Pectra on May 7, 2025. (The final status and timeline will be confirmed in future "all EC" calls.)

Conlusion

EIP-3074 and EIP-7702 are notable improvements in Ethereum's richer account abstraction. They allow EOAs to benefit from smart-wallet capabilities (delegated authority, gasless transactions, and batching) without requiring users to switch to completely new contract accounts. 

Since 7702 employs a new transaction carrying code and 3074 uses new opcodes and invoker contracts, the two EIPs offer similar benefits. 7702 is the best option, achieving 3074's goals. EIP-7702, which has replaced 3074, is planned to be incorporated in the Pectra upgrade by mid-2025 (check our blog on the current Pectra upgrade), offering EOAs a "smart account" option. ERC-4337 and beyond are still in development, but these improvements connect existing accounts to the future of fully programmable, user-friendly wallets.

As Ethereum evolves toward greater usability and flexibility, staying ahead of these protocol upgrades isn’t just a technical necessity; it’s a strategic advantage. Codiste’s team will help you with such nuances, be it custom blockchain development, wallets, dApp development, or developer tooling. integrating with EIP-7702 early means you're not just keeping up, you're leading.

Want expert help aligning your product with Ethereum’s smart account future? Let’s talk.