EIP-7702 and EIP-7702 Set Code for EOAs: Account Abstraction Beyond EIP-4337

EIP‑7702 is a total game-changer for those using legacy EOAs. It's all about letting you run smart-account code right at the same address, making things way smoother. We’re looking at this big rollout happening on the Ethereum mainnet with the Pectra hard fork on May 7, 2025.

For anyone making decisions, here’s the scoop: pairing 7702 with ERC‑4337 can really help cut down on user experience hiccups and costs, and the best part? No need to move user addresses around. If you want to dive deeper, check out the official blog here: (blog.ethereum.org).

---

Who this is for (and what you’ll learn)

If you're the one handling the product, platform, or wallet strategy at a startup or a large company, then you’re in the right place. Here’s what you can look forward to:

• Here's what EIP-7702 brought to Pectra, including dates, transaction types, and gas constants. Check it out here.
• Curious about how EIP-7702 works behind the scenes? It involves authorization tuples, a “delegation indicator,” and some origination rules. Dive deeper here.
• Want to integrate EIP-7702 with your existing ERC‑4337 setup? I've got you covered with tips on EntryPoint versions, bundlers, and paymasters. Find all the info here.
• Looking for reference patterns and detailed implementation notes? You’ll find all the hard numbers you need to plan more effectively here.
• Be aware of the new risks popping up and how businesses are stepping up to protect themselves. Get the scoop here.

---

What actually shipped in Pectra

• Activation: Get ready! The mainnet is set to launch at epoch 364,032 on May 7, 2025, at 10:05:11 UTC. If you want to dive deeper, check out the details here.
• Scope: Meta‑EIP 7600 includes essential EIPs like 7702, plus others such as 7691, which focuses on blob throughput, and 7251, which deals with the staking cap. You can find out more about it here.
• L2 rollout: Arbitrum is rolling out 7702 with ArbOS 40 “Callisto,” and it aligns perfectly with Pectra semantics. Expect to see similar implementations popping up in other rollups soon! For more info, check it out here.

Why This Matters

EIP-7702 is a real game-changer! It’s the first protocol-level bridge that links externally owned accounts (EOAs) to smart-account functionality. This means you won’t need to deploy a new contract for every user, which can save you a ton of time and resources. Even better, it lets you upgrade existing addresses right where they are. If you want to dive deeper into it, check it out here: (eips.ethereum.org)

---

EIP‑7702 in one slide: the Set Code transaction

• There's now a new typed transaction: type 0x04, and it comes with an authorizationList. If you're curious, you can dive deeper here.
• Let’s break down how the authorization tuple works and what the signing process looks like:
  • Each tuple is structured like this: [chain_id, address, nonce, y_parity, r, s].
  • An externally owned account (EOA) signs keccak(MAGIC || rlp([chain_id, address, nonce])), while the actual transaction signs over the RLP payload. For more details, head over here.
• So, what’s going down on-chain?
  • Clients will put a “delegation indicator” into the EOA’s code slot, formatted as 0xef0100 || address. After that, whenever a CALL/CALLCODE/DELEGATECALL/STATICCALL is made to that EOA, it executes the code from the delegate address in the context of the EOA. If you want to dig deeper, check it out here.
  • If you need to clear it, delegating to the zero address will reset the account’s code hash to empty, turning it back into a regular EOA. You can find the specifics here.
  • And here’s something cool: EIP‑3607 has been relaxed, which means that EOAs with a valid delegation indicator can now initiate transactions. More info can be found here.

Developer Gotchas You’ll Want Engineering to Internalize:

1. Magic Numbers
   It might seem easier to toss in a number without saying much about it, but these “magic numbers” can really muddle things up. Make sure to define and comment on them so everyone’s on the same page!
2. Ignoring Error Handling
   It might feel like a time-saver to skip error handling, but trust me, it usually ends up causing more trouble. It's super important for the team to grasp just how crucial it is to anticipate and handle errors.
3. Cutting Corners with Code Quality
   Skipping code reviews or brushing off standards might seem like a time-saver, but it can lead to big problems later on. Let’s not forget how crucial it is to keep our code quality high--it’ll save you a ton of time and hassle in the long run!
4. Not Keeping Dependencies Updated
   Hanging onto old libraries or frameworks can really open up the door to security vulnerabilities and compatibility headaches. It's super important to encourage the team to keep an eye on those updates!
5. Lack of Documentation
   It’s super easy to overlook how crucial solid documentation can be. Make sure the team knows to jot down their thought processes and decisions. Trust me, it really helps when new members come on board!
6. Overcomplicating Solutions
   You know what they say: sometimes, keeping it simple is the way to go. Let's encourage the team to steer clear of over-engineering and concentrate on what really gets the job done.
7. Not Understanding the Business Context
   Remember, code is just one piece of the puzzle. It’s super important to help the team see how their work ties into the bigger business goals. This way, they stay motivated and make decisions that really align with what the company is aiming for.
8. Underestimating Performance Implications
   It's easy to overlook performance when you're deep into development. Just remember to keep the team in the loop about how their decisions can affect speed and efficiency down the line.
9. Assuming Everyone Knows the Tech Stack
   Not everyone on the team is going to be up to speed with your tech stack right away, especially if they're new. So, let’s make sure we're all being patient and offering a helping hand!
10. Not Testing Enough
    Skipping tests can really come back to bite you. It's super important to get the team on board with a testing mindset and make sure quality assurance is a priority throughout the entire process.

With these gotchas in mind, your engineering team can streamline their efforts and make the development process a whole lot smoother!

• The EXTCODESIZE function gives you the 23-byte size of the indicator, while CODESIZE and CODECOPY deal with the actual code at the target during delegated execution. This discrepancy is intentional, so it's a good idea to double-check any assumptions you might have about code size. (eips.ethereum.org)
• Clients are set up to handle just one hop at a time, meaning you won't run into those never-ending delegation chains. If a delegation points to precompiles, it's treated as if it has no code at all. (eips.ethereum.org)

---

Gas, costs, and performance you can plan against

• The intrinsic gas baseline is built on EIP‑2930, with a few extra costs for each authorization:
  • PER_AUTH_BASE_COST is sitting at 12,500 gas, while PER_EMPTY_ACCOUNT_COST is at 25,000 gas.
  • If you need to look up a cold account to get some delegated code, it'll set you back 2,600 gas; but if it's a warm lookup, you're only looking at 100 gas. (eips.ethereum.org)
• Now, when you stack this against the hefty gas prices for deploying a new smart account (which usually goes over 500k gas), EIP-7702 really stands out. It lets you "upgrade in place" for just tens of thousands of gas plus whatever your call data costs, saving you the hassle of moving addresses around. (quicknode.com)
• Just a quick note: you’ll still need to manage ERC‑4337 overhead if you’re using EntryPoint flows, which can add tens of thousands of gas per UserOp depending on your account or paymaster setup. And remember, with EntryPoint v0.7, there’s that 10% unused-gas penalty that could mess with your gas cap estimates, so it’s a good idea to plan with a little wiggle room. (github.com)

Bottom line: If you’re diving into new greenfield wallets or giving a facelift to existing brownfield ones, EIP-7702 really helps lower those cold-start costs. Plus, you can keep using the familiar 4337 routes for sponsorships, batching, and custom validations. Take a look here: (eips.ethereum.org)

---

7702 vs. 4337: how they fit in real stacks

• EIP-7702 is all about making protocol-level delegation a thing. It lets any externally owned account (EOA) link to some audited wallet code, and this setup stays in place until you decide to change or remove it. You can dive into the details here.
• ERC-4337 is like the main infrastructure behind it all. It brings in UserOperations, bundlers, paymasters, and sets up a standard EntryPoint for every network. If you're interested in where to find the deployment addresses: v0.7 is hanging out at 0x0000000071727De22E5E9d8BAf0edAc6f37da032, v0.6 is at 0x5FF1…, and we’re also starting to see some v0.8 rollouts. For more info, check it out on GitHub.

What it means for you

Great news! You can now upgrade your EOAs using 7702 to run a setup compatible with 4337, all at the same address. There’s no need to mess around with changing your bundlers and paymasters; you’ve made things easier by skipping the need to “deploy a fresh account” and avoided a bunch of proxy hops. For more details, take a look here.

---

Practical implementation patterns we recommend

Pattern A -- “4337 inside” at the same address

Go ahead and use 7702 to set up an EOA that’s linked to a smart account compatible with 4337, such as the Simple7702Account or even your own customized wallet version. This way, you get to enjoy all the fantastic features and tools that come with 4337 without the hassle of having to manage new deployments.

• Choose your implementation: you can either go with the Simple7702Account (it's already been audited and supports ERC‑1271) or opt for a more robust production wallet implementation. Take a peek at it here: (docs.candide.dev)
• After that, you'll need to sign an authorization and set up the code using your signer:

  // viem 7702 flow
  const authorization = await walletClient.signAuthorization({
    account: eoa, 
    contractAddress: delegateImpl, 
    executor: 'self' // if the EOA also executes the tx
  })
  
  const hash = await walletClient.writeContract({
    abi, 
    address: eoa.address, // call into the EOA (now delegated)
    functionName: 'initialize',
    args: [initData],
    authorizationList: [authorization],
  })

(viem.sh)

• Keep your EntryPoint v0.7 bundlers and paymasters consistent. If you’re diving into v0.8 pilots, be sure to verify the address and check that your providers are on board with simulation support. (alchemy.com)

When to Choose It

If you’re running a 4337 infrastructure and are searching for sponsorship, session keys, or enterprise policy engines, you’re in the right spot. Dive into the details here.

Pattern B -- Minimal 7702 account for native batching

If you're just looking for the basics like a simple 1-tx approve+use or some straightforward multicalls, you can totally rely on a batched-calls setup. This lets you bypass all the complexities that come with 4337.

• Both Ethers.js and Viem support type: 4 and authorizationList:

  // ethers example: batch ETH transfers via delegated contract at the EOA address
  const auth = await createAuthorization(currentNonce + 1)
  const tx = await delegatedContract["execute((address,uint256,bytes)[])"](calls, {
    type: 4,
    authorizationList: [auth],
  })

• You can definitely keep using 4337 in the future by switching the delegation target to a 4337 wallet implementation. (eips.ethereum.org)
• Want to dive deeper? Take a look at this guide: (quicknode.com)

When to Choose It

Consider taking this approach if you're aiming for big UX improvements without a lot of extra work. Just a heads up: right now, there are no sponsorships or alternative mempools available.

Pattern C -- Policy‑driven automation with wallet‑managed permissions

Add Human-Friendly Permissions to Your 7702 Smart Accounts with ERC-7715 (MetaMask Smart Accounts Kit)

If you're looking to enhance your experience with 7702 smart accounts, you're in for a treat! With the ERC-7715, part of the MetaMask Smart Accounts Kit, you can easily add some user-friendly permissions to your accounts.

Here's what you need to know:

• What is ERC-7715?
  It's a standard that allows you to set permissions on your smart accounts in a way that’s more understandable and transparent for everyone.
• Why use it?
  With ERC-7715, you can give other users or applications specific permissions to interact with your smart accounts without giving away the keys to the kingdom. It's all about fine-tuning access for greater security and control.

Key Features of ERC-7715:

• Custom Permissions: Tailor what others can do with your account.
• Enhanced Security: Reduce the risk of unauthorized access by limiting permissions.
• User-Friendly: Makes it easier for everyone to understand what permissions are granted.

Getting Started:

To add these permissions, you’ll want to dive into the MetaMask Smart Accounts Kit and familiarize yourself with the setup. Here's a quick rundown of the steps:

1. Install MetaMask: Make sure you have the MetaMask extension installed in your browser.
2. Set Up Your Account: Follow the setup process for your 7702 smart account.
3. Implement ERC-7715: Use the ERC-7715 standard to define the permissions you want to set.
4. Test Your Setup: Always a good idea to check and make sure everything works as expected.

Resources:

For more detailed instructions, you can check out the following links:

• MetaMask Smart Accounts Kit
• ERC-7715 Documentation

With these tools at your disposal, managing permissions on your smart accounts will be a breeze!

• When you want to get permissions from the wallet, just use wallet_grantPermissions. This cool feature lets you set spending limits and schedule transfers, but don’t forget that you need a wallet that works with ERC‑7715--right now, that means something like MetaMask Flask. You can read more about it here.
• If your app is handling delegations that other agents need to redeem on behalf of users, you can pair this up with ERC‑7710, also known as the “delegation manager.” There’s more info available here.

When to Choose It: Subscriptions, AI-Agent Automations, Trading Bots with Escrowed Allowances

Figuring out when to choose between different options can be a little confusing, but don’t worry! Here’s a helpful guide:

• Subscriptions: If you want a smooth experience with ongoing services or need steady access to a product without the hassle of buying it over and over, subscriptions are the way to go. They’re ideal for stuff like software tools or premium content.
• AI-Agent Automations: These are super useful for tidying up your tasks and boosting your efficiency. If you're stuck in a loop doing the same boring tasks again and again, AI-agent automations can really lighten your load. This way, you can dedicate your energy to the important stuff that really counts.
• Trading Bots with Escrowed Allowances: If you're diving into the world of trading and looking to automate things while keeping your investments safe, trading bots with escrowed allowances are definitely worth considering. They’re great for managing your trades efficiently while making sure you don’t put all your capital on the line at once.

Each option has its own benefits, so take some time to think about what works best for you and how they align with your lifestyle or business!

---

A concrete migration playbook (brownfield EOAs)

1. Inventory and Target Cohort

• Identify EOA users who might be ideal for an "upgrade." Create a seamless in-wallet process that allows them to easily sign a 7702 authorization, linking to your verified smart-account code. (eips.ethereum.org)

1. Transition to an audited implementation

• Option A: Utilize immutable wallet code deployed via CREATE2.
• Option B: Opt for a tested proxy that includes external nonce tracking and validator hooks (similar to the Coinbase EIP‑7702 Proxy). This helps to dodge replay problems and guarantees a secure setup. (eips.ethereum.org)

1. Initialize safely, atomically

• Always ensure you’re setting up the state in the same transaction where you’re deploying the code. It’s also a good idea to verify that the init payloads are signed by the EOA’s key. This helps you steer clear of any sneaky front-running or replacement actions on those initial values. (eips.ethereum.org)

4) Namespaced Storage to Future-Proof Upgrades

• To avoid any storage conflicts with future delegates, it’s smart to use ERC-7201 for the root state. Don’t forget to document the namespace in NatSpec as well. For more details, you can check this out: (eips.ethereum.org)

1. Keep 4337 infra steady

• Let’s stick with EntryPoint v0.7 routes in production while we give v0.8 a spin in the canaries. And don’t forget to check the bundler simulation toolchain! (github.com)

6) Ship Revocation and Recovery

• Create an easy “restore to EOA” button that sends to a zero address and resets the code. And hey, don’t forget to document those incident playbooks! For more info, take a look here.

7) L2 Rollout Plan

• Make sure to stay updated on the Pectra-compatible releases from all L2s, like Arbitrum's ArbOS 40, before we set 7702 to be enabled by default on that network. For more info, check it out here.

---

Security realities and the controls to adopt

7702 packs a punch, giving you some serious power, but it also ramps up the risk if a signature goes sideways. That’s why it’s super important to ensure you’re aligned on these must-haves:

• Keep it simple: only let delegations pass through a short allowlist of trusted, audited code. Don’t have users signing raw 7702 authorizations straight in the dapp. This aligns with the advice from 7702 to keep those delegation flows within wallets, away from random sites. (eips.ethereum.org)
• Make sure your delegate contract has replay safety and external nonces. If you overlook this, signatures could get replayed, leading to some serious trouble for your sponsor. (eips.ethereum.org)
• Keep an eye on tx.origin invariants. Just a reminder, 7702 changes some assumptions--like using require(msg.sender == tx.origin) for reentrancy protection or to dodge those sandwich attacks. It’s worth taking a close look at those patterns. (eips.ethereum.org)
• Be wary of SOC detections tied to “sweeper” code hashes. After the Pectra incident, researchers uncovered a lot of on-chain delegations associated with sweeper bytecode clusters that could drain compromised EOAs. Stay alert and block any known indicators. (holder.io)
• Inform your users: they should only accept “upgrade to smart account” prompts from their wallet’s native UI, not from random web pop-ups. Also, keep in mind that multi-chain authorizations with chain_id=0 could get replayed on other EVM chains. So, give users a heads-up and encourage them to stick to chain-specific authorizations. (frameworks.securityalliance.org)

Hey wallet and infrastructure creators! If you're handling 7702 transactions, don't forget to request bonds or solid reputations from relayers. It’s a smart move to help you avoid those annoying unreimbursed gas fees when things go sideways during the transaction process. You can dive into the details here: (eips.ethereum.org)

---

Developer details your team will ask about

• EIP constants and validation: Alright, so here’s the scoop: we’ve got SET_CODE_TX_TYPE=0x04 and MAGIC=0x05. Just a heads up--when it comes to tuple bounds and processing order, the nonce is incremented before any authorization processing comes into play. If you want to dive deeper, check it out here.
• Affected opcodes: We’re looking at code-executing operations that load delegate code. And remember, those code-reading mismatches? They’re totally intentional! For more details, take a look at this: eips.ethereum.org.
• Mempool behavior: Once an account gets delegated, watch out! Other pending transactions could go stale. The node propagation rules are designed to handle this, so don't just assume everything stays valid all the time. For a deeper understanding, check this link out: here.
• Tooling support:
  • viem: You’ve got the option to use signAuthorization() and send type-4 with the authorizationList. They’ve got some great guides ready for you, so make sure to check it out! See more.
  • ethers.js: There are some Type 4 examples floating around, plus they’re actively tracking and fixing v6 issues in their repo. For all the deets, head over to QuickNode.
  • Alchemy/Candide SDKs: You can find EntryPoint addresses, Simple7702Account, and deployment references all in one place: docs.candide.dev.

---

Governance context: 7702 replaced 3074

EIP‑3074 (AUTH/AUTHCALL) has been withdrawn, and the core developers are shifting their attention to EIP-7702. This move aims to boost forward compatibility with the “endgame AA” concept while also reducing the opcode surface. If you were relying on the 3074 documentation, be sure to update your roadmaps to highlight 7702. (eips.ethereum.org)

---

Reference architecture: 7702 + 4337 for production

• Delegation Layer (7702): This is where it all begins! Your Externally Owned Account (EOA) gets upgraded into a slick audited wallet setup, like the Simple7702Account or even your very own branded wallet. Check it out here: docs.candide.dev.
• Execution/Validation (4337): Here we’re talking about UserOps running through EntryPoint v0.7, where bundlers come into play to simulate and sponsor things with paymasters. And they stick to the ERC‑7562 validation rules, of course. If you're curious for more, take a look here: docs.erc4337.io.
• Permissions (Optional): Think of ERC‑7715 for wallet-mediated grants and ERC‑7710 for redeemable delegations among different agents. If you want to dig a little deeper, here’s the link: docs.metamask.io.

KPIs to Keep an Eye On After Rollout

Once you’ve rolled out your updates, there are a few important metrics you’ll want to keep an eye on:

• Upgrade Success Rate: Take a look at how well the upgrades are rolling out.
• Median 7702 Authorization Gas: Keep track of the average gas being used for authorization.
• Time-to-First-Sponsored-UserOp: Check out the time it takes for that first sponsored UserOp to show up.
• Paymaster Rejection Reasons: Dig into the reasons why some transactions are getting rejected by the paymaster.
• Sweeper-Hash Detection Rate: Don’t forget to keep an eye on how well you’re spotting sweeper hashes.

These KPIs will really help you gauge how things are running and where you might want to make some tweaks.

---

Example: upgrading an EOA and batching immediately

1. The user signs a 7702 authorization right in their wallet, connecting it to your wallet setup.
2. Your app then fires off a type-4 transaction that has the authorization list and data to start the initialize() function.
3. Right after that, you can bundle the approval and the swap into one single operation within the same delegated call path--no need for a separate approval transaction!

// 1. authorize + 2. initialize delegated account
const auth = await walletClient.signAuthorization({
  account: eoa, contractAddress: walletImpl, executor: 'self'
})
await walletClient.writeContract({
  abi: walletAbi,
  address: eoa.address,
  functionName: 'initialize',
  args: [initParams],
  authorizationList: [auth],
})

// 3. batched approve+swap through the EOA address (now delegated)
const batch = [
  { target: USDC, value: 0n, callData: approveData },
  { target: router, value: 0n, callData: swapData },
]
await walletClient.writeContract({
  abi: walletAbi,
  address: eoa.address,
  functionName: 'executeBatch',
  args: [batch],
})

(viem.sh)

---

Choosing between options (decision matrix)

• Make sure you've got those user addresses close at hand: 7702 is a must-have; just let your favorite smart-account code take over. If you're on the hunt for sponsorship and some cool tools, check out 4337. You can find more details here: (eips.ethereum.org).
• Since you're already rolling with a 4337 stack, why not add 7702 to help out with that pesky cold-start issue? Just remember to stick to bundlers and paymasters. You can dive deeper into this topic right here: (alchemy.com).
• If you're looking for automation that's easy to read and can be revoked when needed, check out ERC-7715 for those permissioned flows. You can get all the details right here: (docs.metamask.io).

---

Final takeaways for decision‑makers

• Pectra launched 7702 on May 7, 2025, and it seems like L2s are really starting to get on board. You can think of 7702 as a handy upgrade rail that keeps your addresses just the way you want them. (blog.ethereum.org)
• Want to get the most out of this? Pair 7702 with 4337. Keep your infrastructure in place (think EntryPoint, bundlers, paymasters), but let’s simplify things when deploying for each user. (alchemy.com)
• And don’t forget about security! Make sure to use wallet-side allowlists, namespaced storage, replay-safe initialization, and SOC detections for any sweeper code you roll out. The perks for user experience are fantastic, but we’ve got to be mindful of the new vulnerabilities that could pop up too. (eips.ethereum.org)

---

Sources and specs worth bookmarking

• Hey, don’t forget to check out the EIP‑7702 spec! It goes over type 0x04, authorizationList, gas constants, and security. You can find all the juicy details here.
• Big news! The EF Pectra mainnet is officially announced, along with the EIP‑7600 meta. If you want to dive into the specifics, click here.
• Make sure you check out the ERC‑4337 spec and the bundler documentation! Plus, there's some cool info about the EntryPoint v0.7 address and provider support. Get all that info here.
• Curious about Viem 7702 APIs? You’ll definitely want to explore the examples and the QuickNode ethers guide. Find it all here.
• Don't forget to look into the Arbitrum ArbOS 40 docs (that’s for 7702 on L2). You can get all the insights here.
• If you’re interested in ERC‑7201, it’s all about namespaced storage, and you can read up on it here.
• And last but not least, we’ve got the lowdown on ERC‑7715 permissions and ERC‑7710 delegation. For all the details, check it out here.

---

7Block Labs: Your Go-To for 7702/4337 Stack Support

At 7Block Labs, we’re focused on supporting teams in planning, shipping, and securing 7702/4337 stacks on all the main Layer 1 and Layer 2 platforms. If you’re looking for a rollout that’s guided by threat modeling and includes audited delegates, migration tools, and ready-to-use SOC detections from day one, we’re here to help!