[{"data":1,"prerenderedAt":19},["ShallowReactive",2],{"blog-content-en-eip-7702-native-account-abstraction":3},{"slug":4,"title":5,"excerpt":6,"description":7,"bodyHtml":8,"faqItems":9},"eip-7702-native-account-abstraction","EIP-7702: Native Account Abstraction for EOAs (2026)","EIP-7702 lets a regular Ethereum EOA temporarily act like a smart account. Here's how the Pectra-era delegation mechanism works, how it pairs with ERC-4337, and what it unlocks.","EIP-7702 explained for 2026: how EOAs delegate to contract code for batching, gas sponsorship and session keys, and how it complements ERC-4337.","\u003Ch2>The gap: why your EOA can't do smart-account things\u003C\u002Fh2>\n\u003Cp>Most people on Ethereum hold an \u003Cem>externally owned account\u003C\u002Fem> (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 \u003Ca href=\"\u002Fblog\u002Fwhat-is-account-abstraction\">account abstraction\u003C\u002Fa>, and historically they required moving your funds to a \u003Ca href=\"\u002Fblog\u002Fsmart-accounts-vs-eoa\">smart-contract account\u003C\u002Fa> — a different address, with migration friction and its own trust assumptions.\u003C\u002Fp>\n\u003Cp>That is the gap EIP-7702 was designed to close: giving existing EOAs access to smart-account behavior \u003Cem>without\u003C\u002Fem> asking users to abandon the address they already own.\u003C\u002Fp>\n\u003Ch2>What EIP-7702 is\u003C\u002Fh2>\n\u003Cp>EIP-7702 is a mechanism that lets an EOA temporarily delegate to contract code so it can behave like a smart account. It shipped as part of Ethereum's \u003Cem>Pectra\u003C\u002Fem> upgrade in 2025, and as of 2026 it is live on mainnet and widely supported by wallet infrastructure. It introduces a new transaction type that attaches a piece of code — a delegation — to an ordinary account. Crucially, your keys, balance and address stay exactly the same; the account simply gains the ability to run programmable logic when it wants to.\u003C\u002Fp>\n\u003Cp>This is a meaningful shift. Before EIP-7702, \"upgrade to a smart account\" meant \"create and fund a new account.\" After it, the account you have can opt into smart-account features and, just as easily, opt back out.\u003C\u002Fp>\n\u003Ch2>How it works: the delegation designator\u003C\u002Fh2>\n\u003Cp>At a high level, EIP-7702 works through a \u003Cem>delegation designator\u003C\u002Fem> — a small pointer stored in the account that says, in effect, \"run this contract's code as if it were mine.\" The user signs an authorization naming a specific implementation contract, and the account's code slot is set to a marker referencing that contract. From then on, calls to the EOA execute the delegated logic while transactions are still authorized by the account's own key.\u003C\u002Fp>\n\u003Cp>Because the delegation is set by a signed authorization, it can also be cleared or repointed. As of 2026 the practical model is: the EOA remains an EOA, but it can wear a smart-account \"outfit\" defined by whatever implementation it delegates to. That implementation is where features like batching or spending policies actually live.\u003C\u002Fp>\n\u003Ch2>EIP-7702 vs ERC-4337: complementary, not competing\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"\u002Fblog\u002Fwhat-is-erc-4337\">ERC-4337\u003C\u002Fa> is the account-abstraction standard that introduced \u003Cem>UserOperations\u003C\u002Fem>, bundlers, a singleton \u003Cem>EntryPoint\u003C\u002Fem> 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.\u003C\u002Fp>\n\u003Cp>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 adopt ERC-4337-compatible logic and plug into the same EntryPoint and paymaster infrastructure. The two standards stack rather than replace each other.\u003C\u002Fp>\n\u003Ch2>What it unlocks for existing wallets\u003C\u002Fh2>\n\u003Cp>For a wallet developer, EIP-7702 turns previously \"smart-account only\" features into things an ordinary user's address can use:\u003C\u002Fp>\n\u003Cp>\u003Cem>Batching.\u003C\u002Fem> Approve and swap in a single atomic transaction, so a step can't half-complete and strand you between an approval and a trade.\u003C\u002Fp>\n\u003Cp>\u003Cem>Gas sponsorship.\u003C\u002Fem> 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.\u003C\u002Fp>\n\u003Cp>\u003Cem>Session keys.\u003C\u002Fem> 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.\u003C\u002Fp>\n\u003Ch2>Risks and considerations\u003C\u002Fh2>\n\u003Cp>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 — users should 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. And because EIP-7702 is relatively new, tooling, indexers and security assumptions are still maturing as of 2026. None of this is a reason to avoid it; it is a reason to expect wallets to make the delegation target explicit and revocable, and to treat \"what am I delegating to?\" as a first-class security question.\u003C\u002Fp>\n\u003Ch2>How WATS uses this\u003C\u002Fh2>\n\u003Cp>The everyday payoff of account abstraction — no native-gas juggling, one predictable fee — is already what the \u003Ca href=\"\u002Fhot-wallet\">WATS Hot Wallet\u003C\u002Fa> delivers, non-custodially. Every transfer, swap or stake is charged in a single token, \u003Cem>ATS\u003C\u002Fem> — on EVM through an ERC-4337 paymaster, and via an equivalent fee-payer on Solana and TON — and because ATS is a LayerZero OFT, one balance works across all three. WATS is the first and only wallet to combine ERC-4337 + OFT single-token fees, charged instead of native gas, with a \u003Ca href=\"\u002Fats-fee\">burn\u003C\u002Fa> that draws collected ATS from 100M toward a 30M floor — all while you keep your keys, since WATS never holds one.\u003C\u002Fp>",[10,13,16],{"q":11,"a":12},"Does EIP-7702 turn my EOA into a smart contract account permanently?","No. EIP-7702 attaches a delegation designator that points your account at implementation code, but your address, keys and balance stay the same. The delegation can be repointed or cleared, so the account can opt into smart-account behavior and opt back out. It is a temporary, reversible upgrade rather than a permanent migration to a new account.",{"q":14,"a":15},"Is EIP-7702 a replacement for ERC-4337?","No, they are complementary as of 2026. EIP-7702 is a protocol-level change that lets an EOA delegate to contract code, while ERC-4337 provides the UserOperation pipeline, EntryPoint contract, bundlers and paymasters for smart accounts. A 7702-delegated account can adopt ERC-4337-compatible logic and use the same paymaster infrastructure, so the standards stack together.",{"q":17,"a":18},"What can an EOA do with EIP-7702 that it couldn't before?","With a suitable delegated implementation, an ordinary EOA can batch multiple actions into one atomic transaction, have gas sponsored by a paymaster or paid in a non-native token, and grant scoped, expiring session keys. These were previously smart-account-only features. The main caveat is that the account is only as safe as the contract it delegates to, so users should delegate only to audited code.",1784634269177]