EIP-3074 vs EIP-7702 vs ERC-4337: Complete Developer Guide
Written by Usman Asim
Ethereum’s wallet ecosystem is constantly evolving, sprinting toward a programmable future, with EIP-7702 as a key step towards full account abstraction (ERC-4337). But to understand why 7702 is poised to reshape how we interact with Ethereum through smart wallets, we need to tip our hats to EIP-3074, a proposal that laid critical groundwork for 7702 to be what it is.
If you’re a developer building dApps, you’ve likely grappled with the limits of Externally Owned Accounts (EOAs) - Ethereum’s traditional wallets controlled by private keys. EIP-3074 introduced a way for EOAs to delegate control to smart contracts (invokers), enabling features like gas sponsorship and batch transactions. EIP-7702 takes this further, offering a sleeker, safer path to account abstraction.
For developers, this concept simplifies adding advanced functionality to dApps while keeping users on familiar EOAs. For users, it means a smoother experience; think third-party gas payments or executing multiple DeFi trades in one click.
In this guide, we will unpack 3074’s mechanics for context, showcasing 7702’s advancements with code, and comparing both to ERC-4337. Let’s dive in and get technical.
The Problem EIP-3074 Aimed to Solve
EOAs are straightforward: they sign transactions with a private key and send them to the Ethereum network. But they’re limited. They can’t execute code, batch actions, or recover lost keys natively. Smart contract wallets (enabled by ERC-4337) offer more flexibility, but they require users to manage new addresses and often incur higher gas costs. EIP-3074 proposed a fix by introducing two EVM opcodes: AUTH and AUTHCALL, to let EOAs delegate control to invoker contracts, adding smart contract-like features without wallet migration.
EIP-3074 was a proof of concept that shaped Ethereum’s account abstraction roadmap: from EOAs to Smart EOAs (EIP-7702) and ultimately full Smart Wallets (ERC-4337). Let’s explore 3074’s mechanics to understand how it paved the way.
EIP-3074’s Core Components: The Foundation for 7702
EIP-3074 revolves around three pieces: the AUTH opcode, the AUTHCALL opcode, and invoker contracts. These are worth understanding because 7702 builds on their principles.
1. The AUTH Opcode
The AUTH opcode (hex 0xf6) verifies an ECDSA signature from an EOA, proving it has authorized a specific invoker to act on its behalf. The EOA signs a message containing the invoker’s address and a commitment (a hash of the actions to be performed). If the signature is valid, the EVM sets an authorized context.
Here’s a Solidity snippet mimicking AUTH’s signature verification:
*// Invoker contract: Verify EOA authorization*
function authenticate(bytes memory signature, address eoa, bytes32 commitment) public pure returns (bool) {
*// Hash the message the EOA signed*
bytes32 messageHash = keccak256(abi.encodePacked(eoa, commitment));
*// Recover the signer from the signature*
address signer = recoverSigner(messageHash, signature);
*// Check if the signer matches the EOA*
return signer == eoa;
}
*// Helper function to recover signer*
function recoverSigner(bytes32 messageHash, bytes memory signature) internal pure returns (address) {
bytes32 r; bytes32 s; uint8 v;
assembly {
r := mload(add(signature, 32))
s := mload(add(signature, 64))
v := byte(0, mload(add(signature, 96)))
}
return ecrecover(messageHash, v, r, s);
}This code validates the EOA’s intent to delegate control. Once authorized, the invoker can act as the EOA.
2. The AUTHCALL Opcode
AUTHCALL (hex 0xf7) lets the invoker execute transactions as the EOA, using the EOA’s address as the caller while the invoker can pay gas. This enabled gas sponsorship and batching in 3074.
Here’s how you might use AUTHCALL in assembly:
// Invoker contract: Execute a call as the EOA
function executeAsEOA(address target, bytes memory data) public {
// Assumes prior AUTH verification
assembly {
// AUTHCALL: gas, target, value, argsOffset, argsSize, retOffset, retSize
let success := authcall(gas(), target, 0, add(data, 32), mload(data), 0, 0)
if iszero(success) {
revert(0, 0)
}
}
}This snippet calls a target contract (e.g., a DeFi protocol) as the EOA. The gas() function allocates remaining gas, and AUTHCALL ensures the action reflects the EOA’s identity.
3. Invoker Contracts
Invokers are smart contracts EOAs delegate to. EIP-3074’s invokers were persistent, raising security concerns that 7702 addresses. Here’s a 3074-style invoker for gas sponsorship and batching:
⚠️ Security Note: Invokers must be audited and carefully constructed. A flawed invoker can misuse signatures or replay actions.
// EIP-3074 invoker for gas sponsorship and batching
contract LegacyInvoker {
address public authorizedEOA;
// Set authorized EOA
function setAuthorizedEOA(address eoa, bytes memory signature, bytes32 commitment) external {
require(authenticate(signature, eoa, commitment), "Invalid signature");
authorizedEOA = eoa;
}
// Execute batch transactions, optionally sponsored
function executeBatch(
address[] memory targets,
bytes[] memory datas,
uint256[] memory values,
bool sponsored
) external payable {
require(msg.sender == authorizedEOA || sponsored, "Not authorized");
if (sponsored) {
require(msg.value >= estimateGas(targets, datas), "Insufficient gas funds");
}
for (uint i = 0; i < targets.length; i++) {
assembly {
let success := authcall(
gas(),
mload(add(targets, add(32, mul(i, 32)))),
mload(add(values, add(32, mul(i, 32)))),
add(mload(add(datas, add(32, mul(i, 32)))), 32),
mload(mload(add(datas, add(32, mul(i, 32))))),
0,
0
)
if iszero(success) { revert(0, 0) }
}
}
}
// Estimate gas for sponsored transactions
function estimateGas(address[] memory targets, bytes[] memory datas) internal view returns (uint256) {
uint256 totalGas = 21000; // Base transaction gas
for (uint i = 0; i < targets.length; i++) {
totalGas += 10000; // Approximate per call
}
return totalGas;
}
}💡 Implementation Tip: EIP-3074 invokers needed audits to prevent signature replays. EIP-7702 avoids persistent invokers, reducing risks.
EIP-3074 vs. EIP-7702: Why 7702 Wins
EIP-3074 was a bold experiment, but EIP-7702 and ERC-4337 are the future. Here’s a quick comparison:
EIP-3074 vs. ERC-4337
EIP-3074: Added
AUTHandAUTHCALLto the EVM, worked with EOAs but required invokers.ERC-4337: No protocol changes; uses a separate mempool and bundlers for smart contract wallets.
Takeaway: 3074 was simpler for EOAs, but 4337’s flexibility makes it ideal for full abstraction.
EIP-3074 vs. EIP-7702
EIP-3074: Persistent invokers posed security risks and lacked forward compatibility.
EIP-7702: Enables per-transaction smart contract features, aligning with 4337.
Takeaway: 7702 refines 3074’s ideas, offering a safer, more scalable path more closely aligned to the Ethereum AA roadmap.
EIP-3074 introduced ideas that 7702 perfect, leading to an ecosystem aligned with the Ethereum roadmap for full account abstraction.
Gas Sponsorship: dApps pay gas for users, lowering onboarding barriers.
Batch Transactions: Users combine actions (e.g., token swaps and staking) in one transaction.
Recovery Mechanisms: Users recover lost EOAs via trusted delegates.
Start building with Smart Wallets
EIP-3074 walked so EIP-7702 could run. While 3074 introduced groundbreaking ideas for EOA delegation, 7702 refines them into a safer, scalable solution, bringing us closer to Ethereum’s account abstraction endgame alongside ERC-4337. EIP-7702 is in Ethereum’s Pectra upgrade, with testnets active as of April 2025. Mainnet activation is live as of May 7, 2025, pending client adoption (Geth, Nethermind, etc.). Meanwhile, ERC-4337 is already live, offering full account abstraction for smart contract wallets.
Whether you’re optimizing dApp UX or crafting seamless user experiences, now’s the time to dive into 7702 and 4337. Try the demo, dive into the docs, and start building!
Reach out to us anytime for questions. We're here to chat integration strategy, technical implementation questions, trade-offs, and help you find the best solution for your app. Happy building!
Related overviews
Learn the Function of Paymaster Smart Contracts in ERC-4337
Learn How ERC-4337 Compliant Smart Contract Wallets Work
Learn How this Piece of AA Infrastructure Bundles User Operations to Unlock the Full Power of ERC-4337