EIP-7702 changed what your frontend can assume about a wallet

For most of the years I spent wiring swap and bridge frontends, one assumption held and I never questioned it. An address was one of two things. Either an EOA, a plain account controlled by a private key, or a contract with code living at it. You could tell them apart with a single call, and a lot of app logic hung off that answer. EIP-7702 quietly deleted that clean split, and most frontend code has not caught up. If you build anything that touches a wallet, the way your EIP-7702 frontend reasons about accounts needs a rethink, because a normal-looking address can now carry code and behave like a smart account.

This is not a proposal on a whiteboard. It shipped with Ethereum's Pectra upgrade back in May 2025, and by now the mainstream wallets support it. So this is live, on the chains your users are already on, whether or not your app knows about it.

What EIP-7702 actually does

The trick is small and a little sneaky. An EOA can sign an authorization that points at a contract, and after that the account stores a tiny marker in its code slot. The marker is the bytes 0xef0100 followed by the contract address it delegates to. When someone sends a transaction to that account, the EVM runs the delegate's code with the account's own storage and balance. So the key holder is still in charge, but for the length of that call the account acts like a smart wallet. It can batch several actions into one signature, let a paymaster cover gas, or run custom checks before it moves funds.

The part that trips people up is that this is not a one-time thing that resets after the transaction. The delegation sits in the account until the owner replaces it or clears it. I have seen more than one person assume it is per-transaction and build on that assumption. It is not. Once an address is delegated, it stays delegated, and your app should treat that as the normal steady state, not a blip.

The assumption that quietly breaks

Here is where it bites. Plenty of frontends and helper libraries have some version of an isContract check. You fetch the code at an address, and if there is any code you branch one way, if it is empty you branch the other. That branch decides how you show the account, whether you expect a smart contract wallet flow, or how you word a warning before a transfer.

A delegated EOA now returns code from that same call. So a check that was really asking "is this a human with a key" starts answering "yes, this is a contract" for accounts that are still very much controlled by one person with a seed phrase. If your logic assumed empty code meant a simple EOA, it is now wrong for a growing slice of real users, and the failure is quiet. Nothing throws. The UI just makes a bad decision and moves on.

Detecting a delegated account in the frontend

The good news is that detection is cheap once you know the shape. You still call eth_getCode on the address. If the returned bytes start with 0xef0100, you are looking at a 7702 delegation, and the next 20 bytes are the contract it points to. That prefix is reserved for exactly this, so it is a reliable signal rather than a guess.

So the real fix is to stop treating "has code" as one category. You now have three: an empty EOA, a full contract account, and a delegated EOA that is a key holder wearing a smart-account coat. Once you can name the delegate address, you can also show the user what their account is pointing at, which matters more than it sounds like, and I will get to why in a minute.

Batching is the feature users will feel

The upside is real, and it lands right in the spots that used to make swap UIs feel clumsy. The classic one is approve then swap. For years that was two separate signatures with a confusing gap in the middle, and I wrote about how much grief that pattern causes in my notes on token swap frontend pitfalls. With 7702, a delegated account can bundle the approve and the swap into a single signed action. One prompt, one confirmation, done.

It stacks nicely with the gas work too. If a paymaster is covering fees, a first-time user can do something useful without holding the native token at all, which removes the most common dead end in onboarding. I still think the frontend has to be honest about what is being signed in that bundle, the same way I argued in building a gas-aware frontend. Batching hides steps from the user by design, and hidden steps are exactly the ones a careful app should surface in plain language.

The new phishing surface you inherit

This is the part I would not skip. Because a signed authorization can point an account at any contract, a user who signs the wrong thing can hand full control of their account to an attacker's code, and it sticks around after the signature. Security researchers have already documented 7702 phishing that works this way. It is not a reason to avoid the standard, but it does change the frontend's job.

If you can read the delegate address, you can check it against a list of known-good implementations and warn loudly when an account is delegated to something you do not recognize. This is the same reliability mindset I lean on for RPC reliability in web3 apps, where you assume the data you are shown could be stale or hostile and you design the UI so a bad input cannot quietly do damage. An address that carries code is now a thing your app should inspect, not just render.

What I would do today

None of this is a rewrite, it is a shift in defaults. Stop equating empty code with a safe simple EOA. Add a real check for the 0xef0100 prefix and treat a delegated account as its own case. Read the delegate address and show the user what they are pointing at, especially before a signature that changes it. Where the standard is supported, offer the batched flow, because your users will feel the difference on the very first swap. And keep the warning path honest, since the same feature that removes friction is the one an attacker wants to abuse. If you want more of how I think about the wallet-facing layer, it is collected in my Web3 and on-chain notes, and the rest of the work is on the homepage.