EIP-7702 in 2026: Native AA Splits, the Bridge Stays

Native account abstraction just split in two

For most of its life, EIP-7702 has carried a single adjective: temporary. It was the stopgap, the patch, the bridge that gave ordinary Ethereum wallets smart-account powers while the network built something more permanent underneath. On 15 September 2026, that something more permanent came apart in public. Developers who had spent months trying to reconcile the two leading proposals for native account abstraction, Base’s EIP-8130 and Ethereum’s EIP-8141, confirmed that they had given up on merging them into one standard and would ship separate designs instead, as reported by The Block and The Defiant.

The timing matters because of what it says about the bridge. If native account abstraction were weeks away, EIP-7702 would be a footnote. Instead, the protocol-level replacement is now two competing designs on two different timelines, one of them freshly bumped off Base’s release calendar, and the next scheduled Ethereum hard fork, Glamsterdam, does not include native account abstraction at all. What Glamsterdam does include is a gas-repricing package that changes the cost of exactly the operations 7702 accounts perform most. The temporary fix is not being retired. It is being repriced and left in place.

This piece is a plain-language explainer of what EIP-7702 is and how it works, wrapped around the more useful 2026 question: if the thing meant to replace it just fractured, what does a wallet, an exchange, or a self-custody user actually need to understand about the standard they are now stuck with?

EIP-7702 in one minute

EIP-7702, titled Set EOA Account Code, lets a normal externally owned account (an EOA, the plain private-key address most people mean when they say wallet) borrow the code of a smart contract without changing its address. Sign one special authorization, and your account behaves like a smart contract for as long as the delegation stands: it can batch several actions into one transaction, let someone else pay the gas, and grant scoped permissions to a game or an agent. Stop the delegation, and it is an ordinary EOA again. The specification was written by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett, and it went live on Ethereum mainnet in the Pectra hard fork on 7 May 2025.

The appeal was never novelty. ERC-4337 had already delivered smart accounts two years earlier. The appeal was that 7702 required no migration: the hundreds of millions of EOAs that already exist, with their funding history, their ENS names, and their exchange whitelists, could gain smart-account features in place, keeping the same address. That single design decision is why 7702 spread faster than any account-abstraction standard before it, and it is also why it is now hard to dislodge.

A concrete example makes the appeal obvious. Approving a token and then swapping it once took two separate transactions, two signatures, and two gas payments; with a delegated account, a wallet can batch the approval and the swap into a single atomic action that either fully succeeds or fully reverts. The same machinery lets a paymaster cover the gas so a newcomer can transact without first buying ETH, and lets a game grant a temporary session key that signs routine moves without a pop-up for every click. None of that requires a new address or a migration, which is the whole point.

Inside a set-code transaction

Under the hood, 7702 adds a new transaction type, 0x04, sometimes called the set-code transaction. What makes it distinct is a field called the authorization_list. Each entry is a signed tuple that names a chain, a contract address, and a nonce, and the account holder signs it with a dedicated prefix (the magic byte 0x05) so a 7702 authorization can never be mistaken for an ordinary transaction signature. When the transaction lands, the network writes a short pointer into the account: the three bytes 0xef0100 followed by the 20-byte address of the contract the account now delegates to, 23 bytes in total. Every wallet, indexer, and exchange that wants to know whether an address is delegated reads those 23 bytes.

Two details in that design do most of the security work, for better and worse. First, a delegation is reset by signing a new authorization that points at the zero address, which clears the code; there is no separate revoke button at the protocol level. Second, if an authorization is signed with a chain id of 0, it is valid on every chain, which is convenient for multi-chain setups and dangerous if the signer did not intend it. The table below is the field-by-field version.

From EIP-3074 to 7702, and where native AA was supposed to go

EIP-7702 did not appear from nowhere; it was the survivor of a long argument about how to give EOAs superpowers. The earlier attempt, EIP-3074, added new opcodes and a trusted invoker model and was ultimately abandoned as too invasive. ERC-4337 took the opposite route in 2023, building account abstraction entirely above the protocol with its own mempool of UserOperations, its bundlers, its paymasters, and a shared EntryPoint contract, all without a consensus change. 7702 split the difference: no new opcodes, no separate mempool for basic use, no new address, just a way to point an existing account at contract code.

The catch, understood from the start, was that none of these was the endgame. ERC-4337 depends on bundlers and relays to get user operations included, which Ethereum researchers have repeatedly called a source of fragility. 7702 leans on the same infrastructure for its fancier features. The clean answer was always native account abstraction: build the whole thing into the protocol so no external bundler, relay, or side mempool is required. That is the destination the two proposals now heading in different directions were both trying to reach. The comparison below shows where each model sits.

The bridge that was meant to be temporary

To understand why the September split is a big deal, you have to see how confidently the roadmap treated 7702 as scaffolding. When Buterin fielded the proposal, MetaMask senior product manager Alex Jupiter described it to DL News as part of “one unified Account Abstraction roadmap.” His counterpart on Ethereum’s core-development side, Marius van der Wijden, was more cautious in the same reporting, calling 7702 “still a very early proposal, so we need to evaluate all the rough edges.” The shared assumption was that the rough edges would eventually be sanded down by something native.

Ethereum’s history with contentious upgrades should have set expectations. Bitcoin has not managed a consensus change since Taproot, a paralysis we covered in our look at Bitcoin’s upgrade crisis, and Ethereum’s own account-abstraction debate has run since 2016. Native AA was supposed to break that pattern with an omnibus design. Buterin has said EIP-8141 wraps up and solves effectively every remaining problem account abstraction was meant to address, and that it could happen within roughly a year. In September, the roughly-a-year plan met the same force that has slowed every big upgrade: two well-resourced teams could not agree on priorities.

Timing is the part worth watching. EIP-8141 is being framed as a must-ship item for Hegota, the Ethereum upgrade expected to follow Glamsterdam, but must-ship is a priority label, not a calendar date, and Glamsterdam itself is still on test networks. That leaves a gap of at least two upgrade cycles between now and any native design reaching Ethereum mainnet, and the September split means that even when one arrives, it may not be the same design Base ships on its own chains. For anyone building a wallet or an exchange integration today, planning around a native replacement means planning around a moving target that just multiplied.

The convergence that fell apart: EIP-8130 versus EIP-8141

The two proposals were not small variations on one idea; they encoded different values. EIP-8141, the frame-transaction design favored on the Ethereum side, splits a transaction into separate frames that validate the sender, authorize the gas payment, and execute the actions, using EVM code to define validation. That buys maximum flexibility, arbitrary signature schemes including post-quantum ones, and no reliance on outside infrastructure, at the cost of validation whose gas cost is dynamic and harder to predict. EIP-8130, Base’s design, adds a transaction type plus an on-chain keystore that lists an account’s approved signers and authenticators, which nodes can check before execution. That buys predictable validation costs and a straightforward compliance story, at the cost of flexibility.

Derek Chiang, a developer who worked on the reconciliation effort and founded the smart-account toolkit ZeroDev, put the failure plainly. Every technical bridge the group found, he told The Block, “required one side or the other to compromise at least a little” on priorities neither camp would give up: Ethereum on censorship resistance, privacy, and security; Base on scale, customization, and compliance. The upshot, he told The Defiant, is “putting the burden on wallets to deal with the fragmentation that ensues.” His one hopeful note was that if both designs ship, the “wallet community can bridge over the fragmentation” and users might still “end up with the best possible UX.”

The split had already shown up in code. A pull request merged on 8 September moved EIP-8130’s activation out of Base’s Cobalt upgrade and into a new fork the team calls Zenith, whose activation timestamp is set to none on every live chain, meaning it is confined to a devnet with no mainnet date. Base has said the design can cut transfer costs by around 63% relative to the existing ERC-4337 model, an attractive number, but a design goal is not a shipping date. The table lays out the two roads that no longer meet.

Glamsterdam does not bring native AA; it reprices the gas your smart account spends

While native account abstraction slips, the fork that is actually coming carries no replacement for 7702, but it does change the ground 7702 stands on. Glamsterdam, the next Ethereum hard fork after Pectra and last December’s Fusaka upgrade, is led by two features: enshrined proposer-builder separation (EIP-7732), which builds the proposer-builder handshake into the protocol and removes the trusted relays that today sit between them, and block-level access lists (EIP-7928), which let a block declare in advance which state it will touch so clients can execute transactions in parallel. ePBS matters to account abstraction indirectly: the relay dependence it targets is the same class of infrastructure fragility that native AA was meant to remove, and it reshapes the block-building economics that validators and stakers live on.

There is a deeper connection worth drawing out. The relays that ePBS removes are the same category of trusted middleman that smart-account infrastructure relies on today: ERC-4337 bundlers and the relays that carry blocks are both intermediaries a user must trust to get a transaction included. Ethereum researchers have long argued that this dependence is a fragility, since a user with no alternative path to inclusion is at the mercy of whoever runs the relay. ePBS attacks that problem at the base layer for block production, and native account abstraction was meant to attack it for account validation. With native AA now split and delayed, ePBS ships first while the account side keeps leaning on the very intermediaries the roadmap wanted to retire.

The part that touches 7702 directly is the gas repricing, documented under EIP-8007. Two of its components, EIP-8037 and EIP-8038, raise and harmonize the cost of creating new state (new accounts, new storage slots, deployed bytecode) and of accessing state (storage reads and writes, cold account access, external code checks). Ethereum’s own developers have warned that contracts with hardcoded gas assumptions, fixed stipends, or logic that branches on gasleft() may break, and that cached gas constants in wallets and RPC providers “will underestimate and lead to failed transactions.”

Why does that land on 7702 accounts specifically? Because they do more of the newly repriced work than a plain EOA does: they install and read delegation designators, they batch multiple calls that touch multiple storage slots, and they lean on paymasters that write and settle state. The repricing even revisits the flat 21,000-gas cost that a simple transfer has paid since genesis, so that sending value to a brand-new account can cost more than sending it to an existing one, a change Crypto Briefing described as rewriting a rule wallets have relied on since day one. The upgrade is being rehearsed on Plataberget, an unusually long-lived public test network that forked to Glamsterdam on 20 August precisely so wallets and tools can find these breakages before mainnet.

What the split means for wallet fragmentation

Native account abstraction was not only a performance story; it was supposed to end wallet fragmentation by putting one account model in the protocol. The September split does the opposite. If EIP-8130 and EIP-8141 both ship, wallets may have to support two native transaction formats on top of everything they already handle, and the burden Chiang described lands squarely on the software users touch.

7702 already offers a preview of how messy fragmentation gets. Because each wallet points delegated accounts at its own implementation contract, the same address can behave differently depending on which wallet upgraded it, and when wallets began routing EOAs through delegations, the change quietly broke integrations that assumed an address was either a plain EOA or a contract: event tracking, analytics, and points programs all had to adapt. The debate among developers this month, recapped in the same roundup, kept circling one question: can standardized permissions ever work across all wallets, or will each keep supporting only its own version? A shared upgrade path fixes batching and gas, not identity and permissions.

Buterin’s proposed answer is that a user should keep exactly one master recovery root for their entire on-chain life across Ethereum and its layer 2s, then layer social recovery, timelocks, multisig, and zk-email on top of it. Critics in the thread noted the obvious tension: a single root is also a single point of failure. That unresolved argument is the human core of the fragmentation problem, and it is bigger than any transaction format. For everyday users, the practical fallout is the one we flagged in our guide to wallet UX in 2026: the account model is getting more capable and less legible at the same time.

Adoption: a temporary fix carrying permanent traffic

For a standard that is theoretically on its way out, 7702 is carrying a lot of weight. Data from BundleBear in mid-September showed more than 57 million accounts with a live delegation and over 104 million set-code transactions to date. A larger headline number, more than 247 million cumulative authorizations, is real but misleading, because a large share of those authorizations were mass-produced by sweeper bots rather than requested by users; the live-delegation count is the more honest measure of adoption.

The interoperability is part of why the number keeps climbing. Rather than competing with ERC-4337, 7702 slots into it: an account can delegate to a contract that speaks the 4337 EntryPoint, so the same wallet can batch, sponsor gas, and use session keys through infrastructure that already exists. For an exchange or a wallet vendor, adding 7702 support is an upgrade to what they run, not a rebuild, which lowers the cost of adoption and raises the cost of ever walking it back.

The wallet lineup has settled. Ambire shipped the first 7702 support, and MetaMask made 7702 the primary upgrade path for its Smart Accounts, joined by Rabby, Trust Wallet, and Safe, with exchange-linked wallets such as OKX and WhiteBIT early to authorize. On the tooling side, the account-abstraction reference stack folded 7702 in directly: the EntryPoint v0.8 release added native 7702 support so that ERC-4337 infrastructure and 7702 accounts interoperate rather than compete. Every month native AA slips, that installed base grows and gets harder to migrate, which is the quiet mechanism by which a bridge becomes a destination. ETH itself was trading just under $2,400 in the days around the split, per CoinDesk, a reminder that all of this plumbing sits under a live, liquid asset.

The security ledger is still about keys, not code

The most important thing to understand about 7702 security is also the least technical: the risk is almost entirely in the signature, not the protocol. A single authorization can hand full control of an account to a contract, so the same feature that lets a good wallet batch your transactions lets a malicious contract sweep your balance the instant you sign. That is why, weeks after Pectra, the trading firm Wintermute found that more than 97% of early delegations pointed at the same copy-pasted sweeper bytecode, nicknamed CrimeEnjoyor, aimed at wallets whose keys were already leaked; the campaign authorized around 79,000 addresses yet turned little profit, because it was draining empty or already-compromised accounts, not breaking 7702.

The broader data tells the same story with more rigor. A peer-reviewed USENIX Security 2026 study analyzed more than 3.6 million authorizations across seven chains and found over 63% tied to malicious contracts, with 924 distinct malicious contracts confirmed and roughly $2.36 million in realized losses plus about $10.14 million in further exposure. That 63% counts transactions, not victims or dollars, because attacker contracts get reused heavily, but the direction is clear. The single worst individual case remains a phishing victim who lost about $1.54 million in one signature to a fake DeFi interface in August 2025. The encouraging counterpoint: overall wallet-drainer losses fell about 83% in 2025 to roughly $83.85 million, per Scam Sniffer data reported by Cointelegraph. None of this is a chain-level bug, and there is no undo: unlike a disputed oracle price where a community can at least debate a rollback, a signed 7702 authorization that drains you is final.

How exchanges and custodians treat a delegated address

For trading venues and custodians, 7702 turned a simple question, is this address an EOA or a contract, into a screening task. The answer now lives in those 23 bytes: a deposit address that carries the 0xef0100 designator is delegated, and its behavior depends on a contract the exchange did not choose. The specific worry is the deposit-address sweep: if an exchange assigns a user a deposit address and that address, or the user’s withdrawal address, is delegated to a hostile contract, an incoming balance can be swept the moment it arrives. So compliance and security desks have added designator screening to the checks they run on deposits and withdrawals.

Custodians have taken a cautious line. Fireblocks, writing on its security-first approach to 7702, argued that because a single malicious delegation is all it takes, institutions should delegate only to fully audited, trusted contracts, keep the feature to hot wallets and limited-value accounts, and prefer smaller-footprint implementations, while pairing 7702 with multi-party computation so no single key can authorize a delegation alone. On the regulatory side, US users retain a helpful clarity: SEC staff have said that software that merely lets people transact from self-hosted wallets is not itself a broker, which keeps non-custodial 7702 wallets outside broker-dealer registration even as the wider rulebook keeps shifting around the CLARITY Act and the Fed. The trade-off for that self-custody freedom is the absence of a chargeback: no venue can reverse a delegation you signed.

How to read, revoke, or migrate your delegation

Because the protocol has no revoke button, managing a delegation is a skill worth having. The good news is that the steps are quick and free, and every 7702 wallet exposes them. The essential moves:

1. Check whether your account is delegated. Look up your address on a block explorer’s authorization view, or use a dedicated checker such as eip7702.app, and read the delegation designator; the 23-byte 0xef0100 pointer names the contract you are trusting.
2. Confirm the contract is one you meant to trust. A designator pointing at your own wallet provider’s audited contract is expected; one pointing at an address you do not recognize is a red flag.
3. To stop a delegation, sign a reset. From your wallet, authorize a new delegation to the zero address, which clears the code and returns the account to a plain EOA.
4. Know what tools cannot do. Services like revoke.cash can display a 7702 delegation but cannot remove it; the reset has to be signed from the wallet that controls the key.
5. If you may be compromised, move rather than reset. If your key could be leaked, resetting is false comfort; transfer assets to a freshly generated wallet instead.
6. Migrate carefully between wallets. Switching your delegation from one provider’s contract to another can trigger storage collisions; the draft ERC-7779 standard exists to make re-delegation safer, and reputable wallets follow it.

The bottom line: a bridge with no scheduled off-ramp

Add the September developments together and the picture is coherent, if not what anyone planned. The protocol-level replacement for 7702 is now two rival proposals with different values and different timelines; Base’s version has been pushed to an unscheduled fork, and Ethereum’s is aimed at an upgrade that comes after the one currently in testing. Glamsterdam, the fork that is actually near, reprices the gas that 7702 accounts spend and retires assumptions the whole tooling stack was built on, without offering a native alternative. And adoption keeps compounding, which raises the switching cost every month.

For users, the honest takeaway is to stop treating 7702 as a preview and start treating it as the standard it has become. Learn to read your delegation, delegate only to contracts your wallet vendor has audited, insist on clear signing over blind approval, and remember that the one signature is the whole game. The bridge that was supposed to be temporary is carrying the traffic, and for the foreseeable future there is no exit ramp on the map. As van der Wijden said of the proposal when it was young, the rough edges still need evaluating; the difference in late 2026 is that we may be living with them a good deal longer than expected.

Frequently Asked Questions

Is EIP-7702 still a temporary fix?

EIP-7702 was introduced as a bridge to native account abstraction, but as of September 2026 that destination has no schedule. The two leading native proposals, Base’s EIP-8130 and Ethereum’s EIP-8141, split into separate efforts on 15 September 2026, EIP-8130 was moved to an unscheduled fork called Zenith, and the next mainnet upgrade, Glamsterdam, does not include native account abstraction at all. In practice, EIP-7702 is the standard wallets and exchanges have to support for the foreseeable future.

What is the difference between EIP-8130 and EIP-8141?

EIP-8130 is Base’s proposal, which adds a new transaction type and an on-chain keystore that lists an account’s approved signers, favoring predictable validation costs and compliance. EIP-8141 is the Ethereum-side proposal, which splits a transaction into frames that use EVM code to validate the sender and pay for gas, favoring flexibility, censorship resistance, and post-quantum readiness. Developers tried to merge the two into a single standard and abandoned the effort in September 2026, so wallets may have to support both.

Does the Glamsterdam upgrade replace EIP-7702?

No. Glamsterdam, the next Ethereum hard fork after Pectra and Fusaka, leads with enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928), plus a gas-repricing package. It does not ship native account abstraction, so EIP-7702 remains the way ordinary accounts gain smart-wallet features. Glamsterdam does change the gas that 7702 accounts spend and removes some long-standing gas assumptions, so wallets and tools must update.

Is it safe to keep an EIP-7702 delegation on my wallet?

A delegation is only as safe as the contract it points to and the signature that created it. A single signed authorization can hand full control of an account to a contract, which is why more than 97% of early delegations were copy-pasted sweeper code aimed at already-compromised wallets. Delegating to a well-audited contract from a reputable wallet is considered safe; signing an authorization from an unknown site is how people lose everything in one transaction.

How do I remove an EIP-7702 delegation?

You reset a delegation by signing a new authorization that points your account at the zero address, which clears the code. You can inspect your current delegation on a block explorer or a checker such as eip7702.app; tools like revoke.cash can show a delegation but cannot remove it, so the reset has to come from your wallet. If your keys may be compromised, moving funds to a fresh wallet is safer than resetting.

Marcus Okafor is a senior editor at HOGE Wire covering wallets, account abstraction, and Ethereum protocol development.