EIP-7702: Native Account Abstraction for EOAs (2026)

EIP-7702 is an Ethereum transaction type, introduced in the Pectra upgrade, that lets an ordinary externally owned account (EOA) sign an authorization pointing its code field at a smart-contract implementation, so a plain address can execute smart-account logic without becoming a new account. The address, private key and balance stay exactly as they are, and the delegation can be repointed or cleared at any time, which makes it a reversible upgrade rather than a migration. With a suitable implementation behind it, an EOA gains batched atomic transactions, sponsored or non-native gas payment, and scoped session keys. It does not replace ERC-4337: a 7702-delegated account can adopt ERC-4337-compatible logic and use the same EntryPoint, bundler and paymaster infrastructure. The everyday payoff — never having to hold each chain's native gas coin — is what the WATS Hot Wallet already delivers non-custodially through an ERC-4337 paymaster on EVM, charging fees in a single token, ATS, instead of ETH, POL or BNB.

The gap: why your EOA can't do smart-account things

Most people on Ethereum hold an externally owned account (EOA) — an address controlled by a single private key. EOAs are simple and battle-tested, but they are also rigid. They cannot batch several actions into one atomic transaction, cannot let someone else pay their gas, and cannot delegate limited signing power to a temporary key. Those conveniences belong to account abstraction, and historically they required moving your funds to a smart-contract account — a different address, with migration friction and its own trust assumptions.

That is the gap EIP-7702 was designed to close: giving existing EOAs access to smart-account behavior without asking users to abandon the address they already own.

What EIP-7702 is

EIP-7702 defines a new transaction type that lets an EOA delegate to contract code, so the account can behave like a smart account while remaining, at the protocol level, an EOA. It shipped as part of Ethereum's Pectra upgrade in 2025, and as of 2026 it is live on mainnet and supported across major EVM networks and wallet infrastructure. The transaction carries one or more signed authorizations, and each one attaches a delegation to an ordinary account. Crucially, your keys, balance, nonce and address stay exactly the same; the account simply gains the ability to run programmable logic.

This is a meaningful shift. Before EIP-7702, "upgrade to a smart account" meant "create and fund a new account," with every app, exchange withdrawal address and payment link pointing at the old one. After it, the account you already have can opt into smart-account features and, just as easily, opt back out.

How it works: the delegation designator

EIP-7702 works through a delegation designator — a small pointer stored in the account's code field that says, in effect, "run this contract's code as if it were mine." The user signs an authorization tuple naming a chain ID (or 0, meaning any EVM chain that honors it), the implementation contract address, and a nonce. When a 7702 transaction carrying that authorization is executed, the account's code field is set to a short marker — 0xef0100 followed by the implementation address. From then on, calls to the EOA run the delegated contract's logic, while the account keeps its own storage, balance and nonce, and its own private key still signs its own transactions. What any other caller is allowed to trigger is decided by the implementation's rules, which is why the choice of implementation matters.

One consequence is easy to miss and genuinely useful: because the authorization is signed separately from the transaction that carries it, the signer does not have to be the sender. Someone else can submit the transaction and pay for it, which means an account holding zero ETH can be upgraded and then sponsored from its very first action.

Delegation is also persistent rather than automatically temporary. It stays in place until you change it: signing a fresh authorization repoints the account at different code, and signing one that names the zero address clears the pointer and returns the account to a plain EOA. That reversibility is the safety valve of the design, and it is why "what is my account currently delegated to?" is a question a wallet should be able to answer at a glance.

EIP-7702 vs ERC-4337: complementary, not competing

ERC-4337 is the account-abstraction standard that introduced UserOperations, bundlers, a singleton EntryPoint contract, and paymasters — an off-chain-friendly pipeline for smart accounts that never touched Ethereum's core protocol. EIP-7702, by contrast, is a protocol-level change that upgrades EOAs directly.

It is easy to frame these as rivals, but as of 2026 they are best understood as complementary. EIP-7702 answers "how does a plain EOA gain a code-defined identity?" ERC-4337 answers "how do smart accounts get bundled execution, sponsored fees and a shared verification pipeline?" An EIP-7702-delegated account can delegate to an ERC-4337-compatible implementation and plug straight into the same EntryPoint, bundlers and paymasters. The two standards stack rather than replace each other, which is why wallets can ship 4337-style fee sponsorship today and extend it to delegated EOAs without rebuilding the plumbing.

What it unlocks for existing wallets

For a wallet developer, EIP-7702 turns previously "smart-account only" features into things an ordinary user's address can use:

Batching. Approve and swap in a single atomic transaction, so a step can't half-complete and strand you between an approval and a trade — and the same batch can approve an exact amount, or revoke afterwards, instead of leaving an open allowance sitting on-chain.

Gas sponsorship. A paymaster (or an equivalent fee-payer on non-EVM chains) can cover the gas, or let the user pay fees in a token other than the chain's native asset — no separate ETH-for-gas buffer required. The chain is still paid its native gas in full underneath; what changes is which token leaves your wallet.

Session keys. Grant a temporary, scoped key that can sign a limited set of actions within set bounds, then expires — useful for games, trading UIs and recurring flows without re-signing every step.

Risks and considerations

Delegation is powerful, which is exactly why it deserves care. The implementation contract you delegate to effectively defines what your account can do, so a malicious or buggy implementation is a serious risk — delegate only to audited, reputable code. Signed authorizations must be handled carefully by wallets to avoid phishing that tricks a user into pointing their account at attacker-controlled logic; a chain ID of 0 makes an authorization replayable across EVM chains, which is convenient and, in the wrong hands, dangerous. And because EIP-7702 is still relatively new, tooling, indexers and security assumptions are maturing as of 2026. None of this is a reason to avoid it; it is a reason to expect wallets to show the delegation target explicitly, make clearing it a one-step action, and treat "what am I delegating to?" as a first-class security question.

Where WATS fits

The end-user reason to care about EIP-7702 is not the opcode detail — it is not having to keep five native gas balances alive just to move your own money. WATS delivers that today without waiting on delegation support to land everywhere. The WATS Hot Wallet charges every transfer, swap or stake in a single token, ATS — on EVM through an ERC-4337 paymaster, and via an equivalent fee-payer on Solana and TON — so you never need ETH, POL, BNB, SOL and Toncoin sitting in separate buffers. Because ATS is a LayerZero OFT, that is one balance across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON rather than eight. WATS is the first and only wallet to combine ERC-4337 + OFT single-token fees, charged instead of native gas, with a burn that draws collected ATS from 100M toward a 30M floor — all while you keep your keys, since WATS never holds one.

Be precise about what that changes: paying in ATS is not a discount, exactly as sponsorship under EIP-7702 or ERC-4337 is not a discount. The network still collects its native gas in full; only the token you spend is different. So if the parts of EIP-7702 you actually want are the practical ones — one fee token, no native-gas errands, keys that stay yours — the concrete step is to install the WATS Hot Wallet, keep a single ATS balance, and let it cover your activity across all eight supported chains while the standards keep maturing underneath.