EIP-7702 vs ERC-4337: What the Chain Actually Shows

TL;DR

Account abstraction is real and it is small. I sampled Ethereum mainnet and Base directly over JSON-RPC on 14 September 2026, around 15:00 UTC. On mainnet, across 25 blocks and 9,116 transactions, EIP-7702 type-4 setcode transactions were 0.76% of traffic and ERC-4337 EntryPoint calls were 1.404%. A second mainnet sample of 25 blocks and 8,442 transactions put type-4 at 1.20%. On Base, across 40 blocks and 11,723 transactions, EntryPoint calls ran 3.105% against 0.26% type-4 — about 12 times more 4337 than 7702 on the chain where both are cheap.

The "EIP-7702 killed ERC-4337" story fails on the measurements. So does the adoption story built on cumulative counters: 5,336,879 setcode transactions on mainnet, 1,280,867,896 lifetime UserOperations, 66,518,891 accounts with at least one UserOp. None of those is a user count, and the first two are inflated by contracts that re-authorize constantly.

Pick by who signs and who pays, not by which standard is newer. The rest of this article is the measurement method and that decision.

EIP-7702 vs ERC-4337 in 2026: the measured traffic split

Here is what I got. Two mainnet samples and two Base samples, taken with eth_getBlockByNumber against public nodes on 14 September 2026 between roughly 14:56 and 15:05 UTC. I have not published the block ranges or the per-block counts, so nothing in this table can be re-derived from this article. Treat it as one person's undocumented spot check, and re-run the commands in the next section against a window you pick yourself before you rely on any of it.

Source: Ethereum public RPC↗ and Base public RPC↗, sampled 2026-09-14. The third decimal place in these percentages is arithmetic, not precision: the mainnet EntryPoint figure rests on 128 observed calls and the Base figure on 364, so both carry roughly a tenth of a percentage point of counting error. Read them as 0.8%, 1.4%, 0.3% and 3.1%.

Three things fall out of that table immediately.

Both standards together are a rounding error in blockspace. On mainnet, 7702 plus 4337 is a bit over 2% of transactions. Ninety-eight percent of what lands in an Ethereum block in September 2026 is neither a setcode transaction nor an EntryPoint call. That is not the same as ninety-eight percent being plain EOAs. A bundler submission is itself an ordinary EOA transaction signed with a secp256k1 key, and a delegated EOA sends ordinary type-2 transactions that land inside the same ninety-eight percent — which is why the sender-side check in the next section matters more than this one. If you are building on the assumption that smart accounts are the default and EOAs are legacy, the chain disagrees with you.

On Base, EntryPoint calls outnumber type-4 setcode transactions by roughly 12 to 1. That is not a like-for-like ratio and I will not present it as one. An EntryPoint call fires on every 4337 operation; a type-4 setcode transaction fires once in an account's life and never again. The ratio measures ongoing 4337 activity against one-off 7702 enrolment, so it cannot tell you which standard has more accounts behind it. The one roughly comparable figure I have — 4% of distinct Base senders returning delegated code, against 3.105% of Base transactions hitting an EntryPoint — does not support a twelve-to-one gap in either direction. What the ratio does establish is that 4337 is still carrying real, recurring traffic on Base, which is enough to refute "EIP-7702 killed ERC-4337" without inventing a multiple. The common narrative after EIP-7702 shipped was that native delegation would eat the ERC-4337 stack, because you no longer need a separate account contract to get batching and sponsorship. On Base — cheap execution, a large consumer wallet base, and four chains in the table below that are cheaper still — EntryPoint traffic runs at 3.1% of transactions against 0.3% type-4. That is not 4337 winning. It is 4337 still working.

The two mainnet type-4 numbers disagree by more than half. 0.76% in one 25-block window and 1.20% in the next. That is sampling noise, and I am reporting it rather than picking the flattering one. Treat mainnet 7702 setcode traffic as roughly 1% of transactions, not as a precise figure.

The share of senders is a better proxy than the share of transactions

Counting type-4 transactions undercounts EIP-7702, and the reason is structural. Setcode is a one-time act. Once an EOA has delegated, it sends perfectly ordinary type-2 transactions that execute the delegate's code. It never emits another type-4 transaction unless it re-delegates.

So I cross-checked by looking at senders instead of transactions. For each distinct sending address in the sample window, call eth_getCode. A delegated EOA returns code beginning 0xef0100, followed by the address it points at. Between 3% and 9% of distinct mainnet senders in those windows came back delegated. On Base it was 4%.

That 3-to-9 spread is wide because I checked about a hundred distinct sending addresses per window rather than all of them. A 25-block mainnet window holding 9,116 transactions contains thousands of distinct senders; I sampled a subset of them, which is why the confidence interval is this loose. The honest statement is single-digit percent, and I will not pretend to more precision than a hundred-address sample supports.

How to measure 7702 and 4337 adoption yourself

You do not need a Dune account or an indexer for this. Two RPC methods and jq will do it. I would rather you re-run this than trust my sample.

Count type-4 transactions in the latest block:

curl -s https://ethereum-rpc.publicnode.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber",
       "params":["latest",true]}' \
| jq '{total: (.result.transactions | length),
       type4: ([.result.transactions[] | select(.type=="0x4")] | length)}'

Check whether a specific address is a live delegated EOA:

curl -s https://ethereum-rpc.publicnode.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode",
       "params":["0xYOUR_ADDRESS","latest"]}' \
| jq -r '.result | if startswith("0xef0100")
         then "delegated to 0x" + .[8:] else "not delegated" end'

For the ERC-4337 side, take the canonical EntryPoint address for each version from the official deployment record — I am deliberately not quoting the addresses from memory here, because a wrong address quietly returns zero and you will believe it. Filter each block's transactions by to matching those addresses, and bucket the counts by version. That is how I got the v0.6 / v0.7 / v0.8 split below.

Run it across a hundred blocks, not one. Run it at a few different times of day. A single block is meaningless and a single hour is close to it — which is a fair criticism of my own samples above, none of which exceeds 40 blocks and all four of which came from the same ten-minute window.

My numbers are four point samples of 25 to 40 blocks each, 120 blocks in total, taken inside a ten-minute window on one day. They are not daily averages, and I am not going to present them as such. The method is the durable part; the exact percentages will have moved by the time you read this.

Why the cumulative counters everyone quotes are inflated

Every article on this subject leads with the same three numbers. BundleBear↗, read on 14 September 2026, reports 1,280,867,896 total UserOperations, 841,608,996 bundle transactions and 66,518,891 accounts with at least one UserOp. The Dune dashboard for EIP-7702↗ reports 5,336,879 setcode transactions across 5,351 distinct authorized contract addresses.

Those are real counters. They are not adoption, and here is the arithmetic that shows why.

The top three delegate contracts on that Dune dashboard hold 3,296,489, 2,982,749 and 1,287,933 authorizations. Add them: 7,567,171. That is more authorizations in three contracts than there are setcode transactions in the entire dataset. It is not an error. One type-4 transaction can carry several authorizations — my second mainnet sample had 168 authorizations packed into 101 type-4 transactions — and the same EOA can re-delegate without limit.

That is the mechanism. Sweeper contracts, the things that drain compromised keys the moment funds arrive, re-authorize constantly. They are a large share of the cumulative count and they represent zero wallet users. Wintermute, which decompiled the most reused variant and republished it as verified Solidity under the name CrimeEnjoyor, put the share of EIP-7702 delegations routed through sweeper contracts at 97% in its analysis published weeks after Pectra shipped the feature in 2025. I could not re-resolve that post at a live URL while writing this, and it is a 2025 snapshot rather than a September 2026 measurement, so take it as evidence that sweepers dominated the early delegation count, not as today's share.

Compare the named wallet implementations on the same dashboard: Metamask7702Delegator at 270,842 authorizations, AmbireAccount7702 at 189,099, WhiteBitAccount at 181,846. Those are the ones that correspond to somebody actually using a wallet. They are an order of magnitude below the top three anonymous contracts.

A cumulative counter measures events since genesis of the feature. Share of live blockspace measures whether people are using it today. They answer different questions, and only one of them tells you whether to build on it.

The paymaster number that reframes the whole category

BundleBear's least-quoted figure is the most useful one in it: total paymaster volume, meaning gas actually covered by sponsors, is $14,118,556 across the entire life of ERC-4337.

Divide that by the roughly 1.01 billion UserOperations that BundleBear's paymaster page attributes to paymasters and you get about $0.014 of sponsored gas per sponsored operation, lifetime. Dividing by the full 1,280,867,896 would give $0.011, but that denominator includes operations no paymaster ever touched.

Gas sponsorship is the headline feature in every account abstraction pitch deck. "Your users never need to hold ETH." Measured against the whole history of the standard, sponsors are covering roughly a cent and a half per sponsored operation. That is a small per-operation subsidy, not a small feature: on BundleBear's own paymaster page↗, paymasters account for roughly 1.01 billion UserOperations — Alchemy 650.9 million, Coinbase 110.2 million, an unlabelled 91.9 million, Pimlico 81.3 million, Thirdweb 39.2 million and eleven smaller names — which is about 79% of the lifetime total. Most UserOperations are sponsored. What is thin is the amount sponsored per operation, not the share of operations sponsored.

That has a direct consequence for your architecture. If you are choosing ERC-4337 primarily so you can run a paymaster, you are choosing a heavy stack for a feature that the market has priced at roughly one cent per operation. That can still be the right call for onboarding, where the first transaction is the one that matters. It is a bad reason to put an EntryPoint in the path of every subsequent transaction a user makes.

What EIP-7702 delegation actually gives you

EIP-7702 adds a transaction type that lets an EOA set its own code to point at a contract. The account keeps its address, its history, its token balances and its approvals. It gains the ability to execute a contract's logic when someone transacts with it.

What that buys you:

• Batching. Approve and swap in one transaction, from an address that already has the approvals and the balance.
• Sponsorship, if you build the path for it. The delegate can accept a signed intent and let a third party pay.
• Alternative signature schemes. The delegate decides what counts as a valid authorization, so the account can check a passkey signature instead of, or alongside, the original key. I cover that stack in passkey wallets on mainnet.
• No migration. This is the real one. There is no "move your funds to your new smart account" step, which is where every 4337 onboarding flow lost people.

What it does not buy you:

• A second layer of key security. The original EOA private key still controls the account completely. It can re-delegate to anything, including a sweeper. A 7702 delegation on top of a leaked key is not a recovery mechanism.
• A counterfactual address. The account has to exist and sign an authorization before anything can run. It does not have to pay for that: EIP-7702 specifies that "the transaction sender will pay for all authorization tuples", so a relayer can fund the delegation of a zero-balance EOA. What you cannot do is compute an address for an account that does not exist yet and receive funds at it.
• Anything on a chain where 7702 is not live. Check per chain before you design around it.

The answer to "why is my EIP-7702 account showing as a contract" is the 0xef0100 prefix. eth_getCode on a delegated EOA returns non-empty code, so anything doing a naive code.length > 0 check to distinguish contracts from EOAs will now classify your users as contracts. If you have that check in a deployed contract, in a subgraph, or in a KYC flow, it is already wrong. The same applies to wallet-based login flows that branch on whether the signer is a contract.

What ERC-4337 gives you that 7702 does not

ERC-4337 keeps the account entirely in contract-land. The account is a deployed contract with its own validation logic; users sign UserOperations, bundlers pack them into a call to the EntryPoint, and the EntryPoint runs validation and execution with strict rules about what each phase may touch.

The things it does that 7702 does not:

• Counterfactual deployment. You can compute the address, show it to the user, receive funds at it, and deploy the contract on first use. There is no chicken-and-egg with gas.
• A validation phase the protocol enforces. The EntryPoint separates validation from execution and constrains what validation may read. That is what makes a bundler able to accept an operation without trusting it.
• A working sponsorship market. Paymasters, bundler RPCs and the surrounding infrastructure exist and have been running for years. The plumbing is there even if the volume through it is thin.
• Key schemes with no EOA underneath. There is no original secp256k1 key that can override the account's rules, because there never was one.

The cost is that it is a second system. You are running or paying for a bundler, you are handling a non-standard mempool, and every wallet, block explorer and analytics tool has to understand UserOperations to show your users what they did. The multi-signature wallet patterns I have shipped before 4337 had the same problem in a smaller form: a contract account is invisible to tooling that only understands transactions.

The decision: pick by who signs and who pays

Here is the framework I use. Two questions decide it in most cases.

The last row matters more than the other six. Account abstraction is infrastructure, and infrastructure you do not need is a liability. If your product is a swap interface for people who already have MetaMask, delegation buys you a batched approve-and-swap and nothing else. Price that against maintaining a delegate contract.

The second question is who pays. If the answer is "the user, out of their own balance," 7702 delegation is almost always the shorter path. If the answer is "us, at least for the first transaction," you want a paymaster, and the paymaster ecosystem lives on ERC-4337.

The combination nobody markets

7702 and 4337 are not exclusive. A delegated EOA can point its code at an implementation that speaks the EntryPoint's validation interface. That gives you the existing address and the existing balance, plus access to bundlers and paymasters. EntryPoint v0.8 exists partly to make that combination work.

That is the shape I would build today for a consumer wallet with existing users. It is also, based on the version split below, the shape the market is adopting slowly and unevenly.

What each one costs

Start with the base rate. On 14 September 2026 the Ethereum L1 base fee sat between 1.5 and 1.9 gwei across the fee-history window, with ETH trading in a $2,468-$2,527 range and around $2,504 at the time of my sample (CoinGecko↗). A 21,000-gas transfer is therefore about $0.09 of execution gas. Across 36 real mainnet transactions in the same window the median fee was $0.39 and the 90th percentile $2.70 — real transactions do more than transfer ETH. I am not quoting a 10th percentile: 36 observations cannot support one, and the value I got was below the cost of a bare transfer at the base fees I recorded, which means the sample is too thin at the low end to trust.

L2 execution gas for the same 21,000-gas transfer, measured the same day:

Those figures exclude the L1 data fee that OP-stack chains add per transaction. One OP Mainnet sample gave an all-in median fee of $0.001115. Treat the table as execution cost only. Cheapness is not the only axis — the risk profile of each of those chains differs sharply, and I go through it in what Stage 1 and Stage 2 actually mean. Cross-check against growthepie's transaction cost data↗, which lists Arbitrum Nova at a $0.06 median transaction cost. That number is not reconcilable with the table above or with my own OP Mainnet all-in median of $0.001115 — it is more than fifty times higher than the cheapest all-in cost I measured — so the two methodologies are counting different things and I have not established which. Use my table as a relative ordering of execution gas, not as an absolute cost.

Now the structural costs on top.

EIP-7702 costs you one setcode transaction, then nothing. After delegation, the account sends ordinary type-2 transactions. The overhead is the delegate's own execution, which is your code and therefore your problem to optimise. The usual gas optimisation techniques apply directly.

ERC-4337 costs you EntryPoint overhead on every operation, plus a bundler. Validation and execution both run through the EntryPoint, and the bundler takes a margin for submitting the bundle. I did not measure per-operation gas overhead in this sample set, and I am not going to quote a number I did not verify — check it against your own account implementation on a fork before you budget for it.

A paymaster costs you whatever you sponsor. The lifetime figure across the whole standard is $14.1 million. If you are sponsoring at scale, model it per user acquired, not per transaction.

On the cheap L2s in that table, the gas argument between the two standards is close to irrelevant — fractions of a cent either way. The argument is about infrastructure you have to run and tooling that has to understand your accounts. That is a headcount cost, not a gas cost.

EntryPoint version drift: v0.6 is not dead

This is the part that will bite you in an integration. The EntryPoint version split is different on every chain.

On mainnet, v0.8 is about 38% of EntryPoint flow. On Base it is about 7%, and v0.6 — the first audited version, on mainnet since March 2023 — is about 44%. The second Base sample of 30 blocks gave the same shape: 117 v0.6, 149 v0.7, 18 v0.8.

So the chain where account abstraction has the most traffic is the chain furthest behind on EntryPoint versions. If you are writing a bundler client, an indexer or a block explorer integration and you only handle v0.8, you are ignoring most of Base's account abstraction traffic. If you are writing an ERC-4337 EntryPoint v0.8 migration and your test fixtures assume everyone has moved, they have not.

Support all three, detect the version from the address you are calling, and do not assume the newest one is the common one.

What I could not verify

Search results for this topic are badly polluted. A large share of top-ranking "2026" Web3 articles are generated content that backdates 2025 events and invents magnitudes. Four specific claims that circulate widely, that I tried and failed to confirm from a primary source:

• That the top three bundlers processed 78% of UserOperations in Q1 2026.
• That 40 million smart accounts had been deployed by 2026.
• That ERC-7683 orders make up 88% of Across volume.
• That MetaMask added native ERC-7683 support in v12.4 in March 2026.

All four trace back to SEO content with no primary citation. I am flagging them as unverified rather than repeating them. If you find a primary source for any of them, that source is worth more than this article's estimate.

Two limits on my own numbers, again, plainly. The samples are four windows of 25 to 40 blocks each, 120 blocks in total, inside a ten-minute window on one day, not daily averages. And the 3.3% versus 9.0% spread on delegated senders is sampling noise on about a hundred addresses — read it as single-digit percent and nothing tighter.

Where this ends: EIP-8141 Frame Transactions

Both of these standards look transitional to me. The Ethereum Foundation has not said that, but the direction of its tier list points the same way.

On 7 September 2026 the EF published its grading of all 62 EIP candidates for the Hegotá fork: 2 S-tier, 15 A-tier, 8 B-tier, 7 C-tier, 28 declined for inclusion and 2 to be decided. Only two items were graded must-ship. One is FOCIL (EIP-7805), the consensus-layer censorship-resistance headliner. The other is EIP-8141 Frame Transactions↗, the execution-layer headliner, and the EF calls it the locked-in execution-layer headliner, justifying it on security grounds as native account abstraction and as "a path to PQ signature schemes without a fork per scheme, aggregation so PQ verification can be priced, and a route to retiring k1 keys".

That is a strong signal about direction. Native account abstraction at the protocol level makes both the EntryPoint contract and the 7702 delegation indicator into compatibility layers rather than the destination.

It is not a reason to wait. Hegotá follows Glamsterdam, and Glamsterdam has slipped repeatedly and still has no announced date. The tier-list post gives no date for either fork. As of mid-September 2026 Glamsterdam has no announced mainnet date: ethereum.org still lists it as TBD, and the Ethereum Foundation's most recent scheduling post — announcing the Platåberget testnet on 17 August 2026 — says that testnet runs for a few months before Glamsterdam reaches Sepolia and Hoodi. Client developers have floated a Q4 2026 window. Nothing is locked in. The Fusaka upgrade and its blob economics activated on 3 December 2025, holding the date core developers had locked in five weeks earlier, but forks after it have not held theirs. Build on what is live, keep your account implementation replaceable, and expect the migration path to be worth taking when Frames arrive.

Key Takeaways

• Account abstraction is about 2% of mainnet blockspace by transaction count. Measured 14 September 2026: type-4 transactions 0.8% and EntryPoint calls 1.4% across 9,116 mainnet transactions, a combined 2.2%. A second window put type-4 at 1.2%, so read mainnet setcode traffic as roughly 1%, not as a precise figure.
• On Base, EntryPoint calls outnumber type-4 setcode transactions by roughly 12 to 1. 3.1% EntryPoint against 0.3% type-4 across 11,723 transactions. It is not a like-for-like ratio — setcode fires once per account, an EntryPoint call fires on every operation — but it is enough to refute the "7702 replaced 4337" narrative.
• Cumulative counters are not user counts. The top three delegate contracts hold 7.57 million authorizations against 5,336,879 total setcode transactions, because one transaction carries many authorizations and sweepers re-authorize constantly.
• Paymaster sponsorship is $14,118,556 across roughly 1.01 billion sponsored UserOperations — about 1.4 cents each, and about 79% of all lifetime operations carry a paymaster. What is thin is the subsidy per operation, not the share of operations sponsored.
• EntryPoint v0.6 still carries about 44% of Base EntryPoint traffic while v0.8 carries about 7%. Support all three versions or you will miss most of the traffic.
• Choose by who signs and who pays. Existing EOA users with balances go to 7702 delegation; users who must transact before funding go to 4337 with a paymaster.
• Measure it yourself. Two RPC calls — eth_getBlockByNumber for type-4 counts, eth_getCode for the 0xef0100 delegation prefix — will settle an adoption argument, provided you run them across a hundred blocks at several times of day rather than in one ten-minute window like mine.

About the Author

I'm Uvin Vindula — a Web3 and AI engineer based between Sri Lanka and the UK. I have shipped production smart contracts and wallet integrations, and I sampled the mainnet and Base numbers in this article myself rather than taking them from a dashboard, because the dashboards were answering a different question. Those samples are my own spot checks and I have not published the underlying block data, so the reproduction commands above — not my word — are the part worth relying on. You can see my work at iamuvin.com or reach out about a project at hello@iamuvin.com↗.

If you're deciding between EIP-7702 delegation and an ERC-4337 account for a product with real users, let's talk about your project.