Beyond ERC-4337: Shipping Smart Accounts with EIP-7702 Delegation

Guess what? EIP-7702 is officially live on the Ethereum mainnet as of May 7, 2025 (thanks, Pectra)! This cool update lets every Externally Owned Account (EOA) easily switch to a smart account without the hassle of changing addresses. Super convenient, right? In this post, we’re going to explore what’s been set up so far, how EIP-7702 links up with EIP-4337, and we’ll also map out a clear plan for rolling out production-ready smart accounts on Layer 1 and the big Layer 2 platforms. Let’s get into it! Hey, if you want the scoop, you can find all the details over here: blog.ethereum.org. Dive in!

TL;DR (for decision‑makers)

So, EIP-7702 is rolling out a new transaction type, which is labeled as type 0x04. This cool update lets an Externally Owned Account (EOA) essentially pass on its execution to some trusted smart-account code for good. Pretty neat, right? It does this by adding a unique “delegation indicator” straight into the code of the EOA. And hey, if you ever change your mind, no worries! You can totally take back or tweak that delegation whenever you want. (eips.ethereum.org). Just to clear things up, EIP-7702 is meant to work alongside ERC-4337, not take its place. You can totally switch 7702 to a setup that works with 4337, and you'll still get to enjoy all the bundlers, paymasters, and everything else in that ecosystem you've come to rely on. (docs.cdp.coinbase.com).

What actually shipped in Pectra

Mainnet activation: Don't forget to save the date--May 7, 2025 (epoch 364032) is the big day! If you want all the juicy details, head over to blog.ethereum.org and check it out!
EIP‑7702 (Setting EOA account code) is included in Pectra's final scope, and it's actually a part of the larger Meta-EIP 7600. If you want to explore this further, check out eips.ethereum.org. It's a great resource for digging into the details!
Transaction Type: Alright, let’s dive into 0x04, which is what we like to call the "set-code" transaction. So, there's this cool new feature called authorizationList. It’s made up of tuples that are signed by the EOA, and each tuple contains: [chain_id, address, nonce, y_parity, r, s]. Pretty neat, right? If you want to dive deeper, check out more info at eips.ethereum.org. There's plenty to explore!
Delegation indicator: So, when a client sends some code bytes like 0xef0100 along with the address to the EOA (Externally Owned Account), it means that all the CALL-like operations will run that code right from the EOA's perspective. For all the details, swing by eips.ethereum.org. It's all there waiting for you!
Sticking around and letting go: Once you delegate something, it stays that way until you decide to change it. If you need to reset it, just delegate it to the null address, and you're all set! Find more here: ethereum.org.

Why This Matters

What's really awesome is that you can effortlessly add features such as batching, sponsorship, alternate authentication, and recovery to any existing EOA. And the coolest thing? You won't have to deal with moving around your funds, changing addresses, or getting any approvals. How great is that? This change could really help reduce those annoying user experience issues and make things run a lot smoother. You can find more info about it here! Take a look!

7702 vs. 4337 today (and why you’ll likely use both)

ERC‑4337 Update: We're excited to share that we've built a solid production-ready setup featuring a singleton EntryPoint! It's officially at version 0! So, version 7 is already out there making waves at 0x000000007172…, and you’ll soon start spotting version 0 popping up as well. There are 8 new bundlers set to launch soon! Just a quick reminder: bundlers are there to mimic operations, paymasters are handling the gas fees, and the alternative mempool is managing user operations. Check it out here.
7702 Status: Exciting news! Delegation is officially up and running at the protocol level on Layer 1. Plus, we’re seeing some cool rollouts happening on Layer 2s, like Arbitrum's ArbOS 40 “Callisto.” It’s a great time to keep an eye on these developments! Hey! If you’re looking for the nitty-gritty, just hop over to the forum here. You’ll find all the info you need!
Fit: What’s really neat about 7702 is that it takes any Externally Owned Account (EOA) and gives it a boost. This means you can run a 4337-compatible setup from the same address without any hassle! Feel free to stick with your bundlers and paymasters, but you can finally wave goodbye to the hassle of setting up new accounts and jumping through all those proxy hoops! If you're looking for more details, you can check it out here. There's plenty of info waiting for you!

So, here’s the deal: if you're considering greenfield or brownfield wallets, pairing 7702 with 4337 is really the way to go. It’s going to provide you with the best user experience and make sure everything works smoothly together when 2025 rolls around. Trust me, you won’t want to miss out on that combo!

The 7702 transaction--precise mechanics you’ll actually use

Type: 0x04
Fields: So, this is kind of like the EIP‑4844-style transaction, but there's a cool little twist to it--it comes with an authorizationList. So, the outer transaction gets signed just like you'd imagine it would. Oh, you mean each authorization tuple? Yeah, that's signed by ECDSA using the EOA that's about to have its code updated. If you want to dive deeper into the details, just click here! Hey, just a heads up about the gas constants you should keep in mind! So, PER_AUTH_BASE_COST is set at 12,500, and for PER_EMPTY_ACCOUNT_COST, it's 25,000. Make sure to jot those down! So, the intrinsic cost is based on the guidelines from EIP-2930, but just a heads up: you might also run into some extra charges related to "delegated code resolution." These could come with either cold or warm access fees, so it's good to keep that in mind! Dive deeper here.
Mempool nuances: Just a quick reminder--it's best for clients to avoid accepting multiple pending transactions for a delegated EOA. You might notice that the nonce jumps up more than once in a single transaction, and that’s usually because of those internal creations happening. Be sure to think ahead when you’re planning your transaction queue! It’ll save you some headaches down the road. Want to dive deeper? Check out all the details here!

Here's a key point to keep in mind: wallets really should verify that the initialization data is signed by the Externally Owned Account (EOA) using ecrecover. It's an important step for security! This step is really crucial if you want to steer clear of front-running when you're delegating for the first time. (eips.ethereum.org).

Practical patterns that work now

Pattern 1 -- “One‑click swap” (batch approve + swap) from an existing EOA

Why not consider handing off your EOA to a smart account that’s been audited? It’s a sleek setup that has a multicall feature and supports ERC-1271. It could make your life a lot easier! With this approach, you can handle both the approval and swap all in one step. Super convenient, right? Take a look at this: (etherspot.io). You’ll want to see what’s new!

Alright, so why should you think about 7702? Well, it saves you from the headache of setting up a dedicated smart account, which can really drain your wallet--seriously, we're talking over 500k in gas fees! Plus, it keeps things simple by eliminating the need for those extra proxies. Oh, and the best part? You get to stick with your current address without any fuss. More details here: (docs.biconomy.io).

Hey, what’s the deal with 4337 on top? You can still use paymasters to handle those gas fees in stablecoins, and keep your bundler pipeline running smoothly. Dive deeper here: (github.com).

Code (Viem) - Authorize and Initialize in One Step:

If you want to simplify your process, you can easily authorize and initialize everything in just one step using Viem! Here's how you can get it done:

Step-by-Step Guide

1. Set Up Your Project. To kick things off, make sure you’ve got Viem all set up in your project. If you haven't gotten it installed yet, don't worry! You can easily do it by following these steps:

npm install viem

2. Connect to Your Provider. Alright, it's time to link up with your go-to provider effortlessly! Here's a simple way to get that done:

import { createClient, configureChains, Chain } from 'viem';
import { mainnet, polygon } from 'viem/chains';
import { publicProvider } from 'viem/providers/public';

const { chains, provider } = configureChains([mainnet, polygon], [publicProvider()]);

const client = createClient({
  autoConnect: true,
  provider,
});

Authorize and Initialize
Now that you've got your client all set up, you can go ahead and authorize and initialize everything in one smooth step! Here's a simple example:.

async function initialize() {
  try {
    const accounts = await client.request({ method: 'eth_requestAccounts' });
    console.log('Accounts:', accounts);
  } catch (error) {
    console.error('Authorization failed:', error);
  }
}

initialize();

Done!

And just like that, you’re all set! This approach not only helps you save time but also keeps your code nice and tidy. It’s a win-win! Happy coding!.

import { createWalletClient, http, privateKeyToAccount } from 'viem';
import { mainnet } from 'viem/chains';
import { signAuthorization } from 'viem/experimental';

const account = privateKeyToAccount(process.env.PRIVKEY!);
const client = createWalletClient({ account, chain: mainnet, transport: http() });

const implementation = '0x...YourSmartAccountImpl'; // audited, 4337-compatible

// IMPORTANT: executor: 'self' when the same EOA both signs the authorization and sends the tx
const authorization = await signAuthorization(client, {
  contractAddress: implementation,
  executor: 'self',
});

const hash = await client.writeContract({
  abi: yourAbi,
  address: account.address,          // your EOA address (now delegated)
  functionName: 'initialize',        // e.g., set validators/owners
  authorizationList: [authorization] // EIP-7702 field
});
console.log('Delegated init tx:', hash);

Viem dives into how tuple construction works along with the executor, and it’s important to point out the whole 'self' nonce detail, especially when it comes to 7702. It’s a little nuance that really makes a difference! If you want to get into the nitty-gritty, feel free to check out viem.sh. There's plenty of info waiting for you there!

Pattern 2 -- Gasless checkout with paymasters

Two Options:

Option One:
Here’s your first option, where you can dive into a bunch of features and benefits that are tailored just for you.
Option Two:
Or, take a look at the second option! It comes with its own perks that could be a better fit for you.

7702-only: With this option, you can have a relayer take care of your 0x04 transaction, plus they'll cover the gas fees for you. Pretty convenient, right? It's just right for simple, app-driven pipelines! Want to dive deeper into it? You can find all the details here.
7702+4337: With this setup, you can easily tap into a 4337 implementation while still taking advantage of your current paymaster on L1/L2. This lets you handle stuff like token gas sponsorship, manage rate limits, and keep an eye on everything with better visibility. You can totally use this setup with EntryPoint v0! You’ll also come across some early v0. 7 in there. 8 bundlers out there. If you want to dive deeper into the topic, check out this link for more information!

Pattern 3 -- Session keys and spend limits (without scary popups)

If you’re using MetaMask, there’s a great way to simplify things! By pairing your 7702 smart accounts with ERC‑7715 permissions, you can really streamline your experience. It's a pretty handy tip! With this setup, apps can request permissions in a way that's super clear and easy to get, like saying “spend up to 10 USDC a day.” No more confusing jargon or complicated delegations that leave you scratching your head! If you want to dive deeper into the details, feel free to swing by the MetaMask support page. It’s a great resource!

Implementation guide: choosing and deploying your delegate

Choose your implementation If you're looking for something straightforward, you might want to check out the Minimal Simple7702Account. It's been fully audited, and it's compatible with ERC‑165, 721, 1155, and 1271 standards, so you should be in good shape there. But if you're feeling like you want something a bit more feature-packed, the Coinbase Smart Wallet could be a great pick too! If you're interested, be sure to take a look at etherspot.io for more details! Coinbase’s EIP‑7702 Proxy is pretty cool! It provides a reliable ERC‑1967 wrapper that makes it super easy to initialize and upgrade everything smoothly. On top of that, it features external nonce tracking and validator hooks to boost security. Pretty cool, right? Check out the full scoop over on GitHub. You’ll find all the juicy details you need!

Ensure that it can’t be changed and is safe to replay. When it comes to delegating, it’s best to stick with immutable code deployed using CREATE2--so, definitely skip the proxies. Alternatively, if you prefer the trusted proxy route, make sure it has a solid validator and that the init payloads are signed. Keeping things straightforward will save you headaches down the line! With this approach, you can easily avoid those pesky front-running and replay attacks. (ethereum.org).

3. Namespaced Storage

To avoid any storage hiccups when you have different delegate implementations, it’s smart to use ERC-7201 as the foundation for your state. Lately, this pattern has really taken off and become the standard in the newest toolchains, especially with OZ 5. x). Take a look at it here: (eips.ethereum.org).

4. Tooling and Client Support

Hey there! Just a quick update: execution clients have officially added support for version 7702! This update brings some cool new features, including Geth's improved way of managing authorization lists. Exciting stuff! On top of that, libraries like Viem are really coming through with some amazing first-class tools to help out. Plus, we've got ethers.js v6 coming our way in 2025! If you're looking for more info, feel free to swing by our GitHub page. There's plenty to explore there!

5. Wallet UX

Hey there! Just wanted to share some awesome end-user wallets that are already making waves. There’s MetaMask Smart Accounts--definitely take a look at the 7702 quickstart if you haven't yet. And then there’s Ambire, which is a nifty extension that works well with Pectra/7702. You’re gonna want to check these out! When you're working on your user experience, remember that wallets usually won't let dapps just sneak in and install code without a heads-up. "Just make sure to clearly display the delegate's address!" If you're curious and want to dive deeper, check out metamask.io for more info!

6. Networks

The L1 mainnet is officially live! At the same time, the L2s are launching some awesome new Pectra features, like the Arbitrum ArbOS 40. Exciting times ahead! Before you dive into the rollout, just take a moment to double-check that your chosen L2 has 7702 activated. It’s always better to be safe than sorry! If you want to dive deeper into the details, just check it out here.

Security and risk management (what to mandate in design reviews)

Initialization signatures: When you make that first call to the delegate, just double-check that it’s signed off by the Externally Owned Account (EOA) using ecrecover. This really helps to keep any sketchy pre-init writes at bay. Take a look at it right here: (eips.ethereum.org).
Phishing guardrails:
Avoid passing tasks to someone else if you can’t keep an eye on what they’re doing. You’ve got a couple of options here: you can either stick with immutable code or try out a validated proxy paired with a validator. It really depends on your needs and what you're comfortable with! Make sure to link your authorization to the chain (chain_id) and, if you’d like, you can also use the current EOA nonce. Hey, just a quick heads-up: try not to set the chain_id to 0 for all the chains, alright? It could cause some issues down the line. Just a heads-up--make sure the delegate address is easy to see! More info here: (ethereum.org).
Mempool vibes: After you delegate, anyone can jump in and make calls to your account. Just a heads up: clients usually only let one pending transaction slide through for each delegated EOA. So, make sure to keep an eye on your transaction queue and monitor things closely! Check out the details right here: (eips.ethereum.org).
Storage setup: Make sure to use ERC-7201 namespaces to steer clear of any version or module clashes. Hey, just a quick reminder to make sure you document those namespaces in NatSpec! It’ll help keep everything organized and clear. Thanks! You can find more details about that right here: (eips.ethereum.org).
Keeping an eye on things and knowing when to hit the brakes: Let’s add a “panic” button that lets us redelegate to 0x0, just in case things go sideways. Also, it’d be super helpful to put together a runbook for handling incidents when they pop up. If you want to dive deeper, check it out here: ethereum.org. There's a ton of great info waiting for you!

Cost and performance notes (with hard numbers)

7702 authorization processing baseline: So, when you're running the numbers, each authorization is gonna cost you about 12,500 gas. That’s your PER_AUTH_BASE_COST right there. And if the accounts were empty before, you’ll need to tack on an additional 25,000 gas.
The intrinsic gas operates based on the EIP-2930 logic. Take a look at this link: (eips.ethereum.org). You’ll find some interesting info there!

Think about it this way: when you roll out a new smart account, it often costs you over 500k in gas fees. But with the 7702 option, you get a much cheaper way to "upgrade" your existing externally owned account (EOA). Plus, you can skip all the hassle that comes with moving addresses. Sounds pretty good, right? Dive deeper here: (docs.biconomy.io).

4337 overhead: Just a heads up, when you're dealing with entry point validation and execution, you're going to see some extra overhead. We're talking about tens of thousands of gas for every UserOperation here, so it's definitely something to keep in mind! No need to stress! The 7702 really helps simplify things by reducing those annoying cross-contract hops you usually have to deal with for the same flow, especially when it comes to batched calls. More details here: (buildbear.io).
4337 v0. In version 7, there's now a 10% penalty if you end up with any unused execution gas. This change is aimed at preventing those overly generous limits that we've been seeing. Then, v0. Version 8 has worked out some of the little quirks we’ve been dealing with and introduced a ton of quality-of-life upgrades. It’s definitely worth checking out, especially if you're planning to adjust your gas estimates! You can take a look here: (github.com). Happy exploring!

How 7702 + 4337 lands in enterprise stacks (reference architecture)

Wallet Layer: Picture those user EOAs you see in MetaMask or with big custodians. Basically, you’ll need to do a one-time 7702 delegation to get your audited account setup running smoothly. Check it out here.
Orchestration: We're all about those 4337 bundlers, and right now, we're on version 0. Just a heads-up: keep your eyes peeled for v0! 8). On top of that, we've got paymasters for tokenized gas and ERC-7715, which really help with permissions and automation. If you're curious and want to learn more, check out the details here. It's a good read!
Policy: How about we set daily spending limits and create some allowlists during the rollout? Storing the policy state in ERC‑7201 namespaces is a clever move! It helps ensure everything stays secure during upgrades. More info here.
Networks: We're looking to launch on the mainnet and some L2s where we've already got Pectra activations confirmed. Just a friendly reminder to make sure you check 7702 on the staging chains before moving forward. Thanks! Get the scoop here.

Example: production-ready “upgrade my EOA” flow

1. The user goes ahead and signs the 7702 Authorization. This basically focuses on your audited setup and connects to the chain_id along with the current nonce. Feel free to take a look at it here: eips.ethereum.org. 2. Alright, so your next step is to submit a type-0x04 transaction. Just make sure to include the authorization list along with the initialize() calldata.
Your validator has to check the EOA signature and the initialization parameters to make sure everything is in order. If you want to dive deeper into the details, check it out here: GitHub - EIP-7702 Proxy. There’s a lot of great info waiting for you! 3. Next up, you'll want to activate the 4337 route. After that, any future interactions will be handled by UserOps and the paymaster. Just so you know, the address will stay the same. For more details, just take a look at this link: GitHub. It should have everything you need! 4. If you think it's necessary, go ahead and include a simple one-click option to “Revoke/Reset” to 0x0. If you’re curious to learn more about this, just check it out here: ethereum.org.

Testing and ops checklists

Test Vectors Take a look at the way we encode authorization tuples (you know, the whole y_parity, r, s thing) and don't forget to check out the 'self' nonce rule for executors! If you're looking for more details, just check this out here. Alright, when you're working on delegation loops, just remember to stick to the first delegation. Avoid creating any looping chains, okay? It's all about keeping it straightforward! If you're interested, you can check out all the details on this page. Hey, just a quick reminder--when you're dealing with replay attacks, make sure to include those nonce-bound checks in your delegate. It's super important! If you're working with a proxy pattern, you might want to think about including an external NonceTracker. If you're looking for more details, check out GitHub. There’s a lot of info waiting for you there!
Monitoring
Be on the lookout for any code changes at EOAs by keeping an eye out for that 0xef0100 prefix. Make sure to set up alerts for any unauthorized redelegations. It'll help you keep track of things and stay on top of any unexpected changes! If you're looking for some helpful guidelines, check it out here. It's got some good info that could really come in handy!
Wallet Compatibility Hey, just a quick reminder to check that everything's working well with MetaMask Smart Accounts, plus the Delegation Toolkit and Ambire flows in QA. Let’s make sure they’re all running smoothly! If you want to dive deeper into the details, you can find everything you need right here.

Roadmap watch: native AA on L2s (RIP‑7560)

RIP‑7560 is introducing a cool new AA transaction type just for rollups. So basically, we're diving into a canonical mempool here, which helps cut down on the overhead. Plus, we're sticking to the concepts outlined in 4337. Pretty cool, right? Even though it’s still a work in progress, it's definitely worth keeping in mind for the 2026 plans and those "write once, run anywhere on L2s" setups. Take a look at the details right here: docs.erc4337.io. You’ll find all the info you need!

Decision guide: when to choose what

So, you've got a bunch of EOAs and you're stuck with your current addresses? No sweat! Just use 7702 to upgrade it all right from where you are. It’s super easy! You should definitely team that up with 4337 for paymasters, plus it'll give you some great support within the ecosystem. Take a look at it over at blog.ethereum.org. You won’t want to miss it!

Hey there! So, you've got 4337 infrastructure up and running? That's fantastic! If you throw in 7702, it'll really help lower those cold-start costs and make everything smoother for your users. It's a great way to enhance their experience! And hey, feel free to stick with your current bundlers and paymasters if that’s what you prefer! If you’re looking for more details, check out github.com. There’s plenty of info waiting for you!

Are you on the hunt for some clever automation that's both independent and permissioned? You know, like subscriptions or background trades? Well, just add a little sprinkle of ERC‑7715 permissions to your 7702 smart accounts, and you’re all set! This makes your permissions super clear and really easy to get. If you’re looking for more info, just hop over to docs.metamask.io. You’ll find all the details you need there!

The 7Block Labs playbook (concise)

Consider going for a well-reviewed audited 7702 implementation--or if you're curious, check out Coinbase's cool 7702 Proxy wrapper. Just remember to lock things down by securing the initialization with signed payloads. (github.com). Hey, just a quick reminder to make sure you’re using ERC-7201 for all your storage namespaces. It’s super important! (eips.ethereum.org). Don’t forget to set up a revocation path! And it’s a good idea to whip up a nice incident runbook too (you know, just in case you need to redelegate to 0x0). (ethereum.org).

Let's go with 4337 v0. Alright, we’ve got 7 infrastructure pieces ready for now. Let’s go ahead and give v0 a try! 8 in canaries first. Just a heads up--make sure to watch those L2 Pectra rollouts before you start tweaking the default routes. It's worth keeping an eye on! (github.com). Alright, so if you want to create a seamless experience for users with delegated permissions, go ahead and use ERC-7715. Just a quick heads-up though--make sure you don’t have users signing any raw, unrestricted delegations directly in the app. Keep it user-friendly! (docs.metamask.io).

Appendix: concrete specs reference

Hey! Don’t forget to take a look at the EIP‑7702 spec. It covers a bunch of important stuff like the type (0x04), the authorization list, gas constants, and even the delegation indicator. Definitely worth your time! If you want to dive into all the info, just check it out here. Hey, have you heard all the chatter about Pectra activation from the EF blog? Plus, there's also a lot of talk about the meta-EIP (that's EIP-7600, for those who might not know). It's definitely got people buzzing! Check out the post right here! Hey developers! Make sure you check out the Viem 7702 dev docs and examples. You’ll find some great stuff there, like signAuthorization and using executor: 'self'. Don’t miss it! Check them out here. So, let's talk about the ERC‑4337 EntryPoint v0. Hey everyone, guess what? Version 7** has officially dropped! 🎉 This update comes with some tweaks regarding address and bundler requirements. Check it out! Check out the latest updates on GitHub! You can find all the details right here. Happy exploring! Hey there! If you’re looking for some info on the Coinbase Smart Wallet 7702 FAQ, like the implementation address and proxy details, you can check it all out right here. Happy reading! Oh, and make sure you keep ERC‑7201 in mind! It's got this cool feature that adds namespaced storage, which really helps prevent any mix-ups between delegates. If you want to dive deeper into the topic, you can check out more details here.

Quick Overview: So, EIP-7702 has been up and running since May 7, 2025, and it’s pretty cool! It lets any Externally Owned Account (EOA) run some audited smart-account code right from the same address. When you team this up with ERC-4337, you can bring paymasters and bundlers into the picture, which helps cut down on deployment costs. Plus, it allows you to launch wallets that are not only safer but also way more powerful, whether you’re working on Layer 1 or Layer 2. Hey, why not take a look at blog.ethereum.org? You might find it interesting!