From EOAs to Smart Accounts: Where Ethereum Wallets Stand in 2026

If you stepped away from Ethereum development for a year or two and came back, the wallet layer is where you will feel the most drift. The account model every tutorial taught you, one private key controlling one address, is no longer the only shape a wallet can take. Two protocol changes have rewired what an account can do, and if the last thing you touched was a basic gas subsidy, the gap between then and now is wide enough to be worth closing properly.

So this is a teaching piece, not a changelog. I assume you know what an EOA is, what gas is and roughly how a transaction gets included, and I explain everything past that. To keep it concrete, I am going to carry one running example the whole way through: onboarding a player into a small on-chain game I built, where you earn coins (an ERC-20 token) and spend them on booster items (ERC-1155 tokens). Follow that one player through each era and the abstractions stop being acronyms. If you want the account model from first principles, I covered that in my primer on the Ethereum whitepaper.

Two account types, one bottleneck

Ethereum has shipped with exactly two account types since day one. Externally owned accounts (EOAs) are controlled by a private key. Contract accounts are controlled by their code. The asymmetry that matters is simple: only an EOA can originate a transaction. A contract account does nothing until something that began at an EOA calls it. Nearly a decade of wallet engineering has been spent working around that one rule.

The EOA is pure cryptography. A 256-bit private key produces a public key on the secp256k1 elliptic curve, and the address is the last 20 bytes of the Keccak-256 hash of that public key. Authorization is an ECDSA signature over that same curve, checked on-chain by the ecrecover precompile (a built-in function living at a fixed address, 0x01, that recovers the signer of a message). A per-account nonce (a counter that increments with each transaction) orders your transactions and stops someone from replaying an old one. At the protocol level, validity is fixed and non-negotiable: a correct ECDSA signature, the expected nonce and enough ETH for gas. There is no seam to insert your own logic.

Contract accounts have code and storage but no key, and cannot start anything. So the account where your assets live and the signer authorized to move them are welded together into one hardcoded relationship. Every limitation below falls out of that weld.

What an EOA cannot do, and what it costs your users

Bring our new player in with a plain EOA and here is their first ten minutes:

• They install a wallet and are handed 12 or 24 words to write down. If they lose those words, their account is gone forever. If they paste them into the wrong site, it is drained. There is no reset, no recovery and no support desk.
• They cannot do anything until they acquire ETH, because the account must pay its own gas. A player who has coins from the game but no ETH cannot even spend them.
• Buying a booster is two separate signatures, not one. First an approve transaction to let the shop contract move their coins, then the buy transaction. Two popups, two confirmations, one confused user.
• Every signature is an ECDSA signature over secp256k1. No Face ID, no "any two of my three devices," no "this key may spend at most 50 coins." The verification rule is hardcoded.

None of this is a wallet bug. It is the account model. Fixing it meant changing what an account is.

The first workaround: make the wallet a contract

The obvious move was to stop using an EOA as the account and use a contract instead, because a contract can hold arbitrary logic. The first Solidity I ever shipped was exactly this, a multi-signature wallet that requires a majority of designated admin addresses to approve a transaction before it executes. Instead of one key being a single point of failure, control is spread across several. Safe (formerly Gnosis Safe) turned that pattern into the standard for treasuries and DAOs and remains the largest smart contract wallet by value secured, with audits going back to 2018 [10]. A typical company setup is "3 of 5 signers," so no single compromised laptop can move funds.

Argent took a friendlier version to consumers with social recovery. Vitalik Buterin laid out the design in January 2021: a single signing key for everyday use, plus a set of at least three guardians, a majority of whom can cooperate to change the signing key after a delay of one to three days, with guardians who need not know each other's identities [9]. Concretely: your guardians might be your other phone, a hardware wallet and a friend's wallet. Lose your daily key, and the three of them together assign you a new one. Nobody can spend your funds, they can only help you recover access, and only after a delay long enough for you to cancel an attempt you did not authorize.

Contract wallets hit the account bottleneck immediately, though. A contract cannot start its own transaction, so every action still had to be kicked off by an EOA holding ETH, which dragged the gas problem right back in. The bridge was the meta-transaction: the user signs a message off-chain (no gas, no ETH needed), a relayer submits it on-chain and pays the gas, then gets reimbursed by the app. EIP-2771 standardized the "trusted forwarder" pattern so the destination contract could recover the real user from data appended to the call. It worked, but every team ran its own relayers and the patterns did not interoperate. What everyone actually wanted was account abstraction, meaning the account rules themselves become programmable, and that turned out to be hard at the protocol level.

It had been attempted before, through proposals that all changed Ethereum's consensus rules and none of which shipped. The blocker was denial of service. A node cannot know whether an abstracted transaction will pay for itself without executing it first, and a single malicious one could invalidate a pile of pending mempool transactions at no cost to the attacker. The most recent consensus-level attempt, EIP-3074, got far and was then withdrawn in favour of the approach that finally shipped [3]. That approach stopped asking the protocol for permission and built the whole thing one layer up.

ERC-4337: account abstraction without touching consensus

ERC-4337 delivers account abstraction with zero protocol changes, which is why it runs on any EVM chain. The reference EntryPoint contract (version 0.6) went live on Ethereum mainnet on 1 March 2023, announced by Yoav Weiss of the Ethereum Foundation at WalletCon in Denver after an OpenZeppelin audit [6]. If you want the lighter conceptual version of this section, I wrote a standalone introduction to account abstraction. Here I will show it doing real work.

The core idea is to replace "a user sends a transaction" with "a user signs an intent" and to build a separate pipeline that carries that intent. Walk our player through buying a booster on a modern 4337 setup and every part shows up in order:

1. The UserOperation. The player taps "buy." The wallet builds a UserOperation, a struct describing what they want to do (which account, what call data, gas limits, fee settings, who is paying and the signature). This is not an Ethereum transaction. It is a request that something will turn into one.
2. The alt-mempool. The UserOperation goes into a separate peer-to-peer mempool that only 4337 infrastructure watches, not Ethereum's normal transaction pool.
3. The bundler. A bundler (an off-chain server, the only participant that still needs an ordinary EOA) picks the UserOperation up, simulates it to confirm it will pay, packs it together with others into a single real transaction and submits it.
4. The EntryPoint. That transaction calls the EntryPoint, one singleton contract deployed at the same address on every chain (v0.6 sits at 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789). It runs a strict loop for each UserOperation: validate, then execute, then settle up the gas [10].
5. The paymaster. Here is the part you already met as "gas subsidy," now generalized. A paymaster is a contract that agrees to pay the gas. In our game, I fund a paymaster and give it a rule: sponsor any booster purchase. The player pays zero gas and never needed to hold ETH. A different policy could instead let them pay gas in the game's own coins, with the paymaster taking coins and covering the ETH behind the scenes.

Two capabilities fall out of this pipeline that the EOA player could not have:

• Batching. Without it: approve then buy, two signatures. With it: the account's execute function runs both in one atomic UserOperation, so the allowance and the purchase either both happen or both revert, on one confirmation.
• Programmable verification. The account is a contract, so its validateUserOp function decides what a valid signature is. That can be an ECDSA key, a multisig threshold, a passkey or a temporary scoped key. The rule is now code you write, not a protocol constant.

That last point unlocks the feature I get asked about most, session keys. Without them, an on-chain game has to interrupt the player for a wallet signature on every single move. With them, the player signs once to install a temporary key that is allowed to act only within limits I define: only the game's contracts, only up to some spend, only until it expires this evening. The game then plays smoothly under that key, and the player's main key never signs again until the session ends. The scary version of this ("a key that can act for me") is made safe by the scoping, which is enforced by the account's own code.

One more mechanic worth understanding, because it feels like magic the first time: counterfactual deployment. A 4337 account can be referenced at its address before the contract actually exists on-chain. The address is computed deterministically with CREATE2 (an opcode that derives a contract address from its code and a chosen value, so you know the address in advance). The player can be handed an address, receive coins at it, and the account contract itself only gets deployed on their first UserOperation, paid for like everything else. You do not pay to create wallets for users who never show up.

EntryPoint has moved since 2023. Version 0.7 (0x0000000071727De22E5E9d8BAf0edAc6f37da032) pushed simulation off-chain, repacked the UserOperation to save calldata and penalized wildly over-quoted gas limits [7]. By Alchemy's figures, ERC-4337 had crossed 40 million smart accounts and 100 million UserOperations by the end of 2024, with adoption led by Base, Polygon and Optimism [10].

EIP-7702: giving your existing EOA code

ERC-4337 has one hard ceiling. It expects users to move to a new contract account at a new address. Our returning player who has an EOA with two years of history, some reputation and assets already sitting there is not going to abandon that address to get batching. Hundreds of millions of existing EOAs were never going to migrate. EIP-7702 fixes that by letting an EOA run contract code in place, keeping its address, its nonce and its history.

It shipped in the Pectra hard fork, which activated on Ethereum mainnet at epoch 364032 on 7 May 2025 at 10:05:11 UTC [1]. Mechanically it adds a new transaction type, SET_CODE_TX_TYPE (type 0x04), carrying an authorization_list of tuples [chain_id, address, nonce, y_parity, r, s], each signed by the EOA that is delegating [3]. For each valid tuple, the EVM writes a 23-byte delegation designator into that EOA's code field: the fixed prefix 0xef0100 followed by the 20-byte address of an implementation contract. After that, any call to the EOA runs the implementation's code, but in the EOA's own storage and balance. That "run someone else's code as if it were mine, using my storage" behavior is delegatecall, the same primitive upgradeable proxy contracts have used for years [8]. The EOA is now, in effect, a smart account, without changing address.

Made concrete: our player signs one 7702 authorization pointing their existing address at a smart-account implementation. From then on that same address can batch an approve and a buy, route a UserOperation through a paymaster for sponsored gas and hand out session keys, all the 4337 features, with none of the migration. This is the piece that turned account abstraction from "for new wallets" into "for everyone who already has a wallet."

A handful of behaviors are worth committing to memory before you build on it:

• The delegation persists across transactions until you replace it or clear it. To revoke, you send another 0x04transaction pointing at the zero address, and you are a plain EOA again.
• Code inspection gets subtle. EXTCODESIZE on a delegated EOA returns 23, the length of the designator, not the size of the real logic [3]. Any contract that used "this address has no code, so it must be a real user" as a security check is now wrong, and auditors specifically look for the 0xef0100 prefix.
• The private key still has full control of the account. That is the whole appeal (no migration, nothing lost) and the sharp edge in one sentence.
• A chain_id of 0 in the authorization makes it valid on every 7702 chain at once, handy for setting up the same delegation across mainnet and L2s with one signature, and a replay risk, so wallets default to per-chain authorizations.

The danger is the mirror image of the convenience. A single signed authorization hands full control of the account to the delegate's code, so a phishing signature can install a drainer that needs no further interaction from the victim. The first wave of 7702 delegations was dominated by copy-paste "sweeper" contracts built to empty an account the instant a tricked user signed. There is also a quieter failure mode: delegating does not wipe existing storage, so re-pointing an account at a contract that interprets the same storage slots differently can corrupt it. That is why real implementations use namespaced storage (ERC-7201) and why ERC-7779 exists as a draft process for safe re-delegation [8].

Where 4337 and 7702 meet, and the hardware-wallet question

These two are complementary, and the common 2026 pattern uses both: point a 7702 delegation at an implementation that also satisfies 4337's validateUserOp, and one account can either sign a normal transaction that runs its delegated code, or sign a UserOperation routed through a bundler. EntryPoint v0.8 (0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108) added native 7702 support: the UserOperation hash now includes the delegation address, the API accepts an eip7702Authparameter, the validation rules gained an AUTH category and the release ships an audited Simple7702Account you can delegate to [7].

The other change in v0.8 is the one that caught you off guard in the last draft, and it deserves a real explanation. First the two words: a hardware wallet keeps your private key on a dedicated physical device (a Ledger or Trezor) that never exposes the key and shows you what you are about to sign on its own small screen, so malware on your computer cannot secretly change the recipient or amount. A hot wallet keeps the key in software, usually a browser extension, which is convenient and fully exposed to whatever else is running on that machine.

The catch is that a hardware wallet can only sign data in formats it understands and can display. It knows normal Ethereum transactions, and it knows ERC-712, a standard for signing structured "typed data" so the device can show you human-readable fields ("swap 50 coins for 1 booster") instead of an unreadable hash. Early ERC-4337 UserOperations were hashed in a custom way that hardware wallets did not recognize, so a Ledger would show a meaningless blob or refuse outright. The practical effect was that smart-account users were nudged toward hot keys, which is the weaker setup smart accounts were supposed to move people away from. EntryPoint v0.8 restructured the UserOperation hash to be ERC-712 compatible, so a hardware wallet can display and sign it natively [7].

The tradeoff, since you asked what it cost to get here: ERC-712 hashing is slightly more calldata and a little more complexity than a raw custom hash. That is the price paid to let people keep their keys on a device that shows them what they are approving. For most consumer flows it is worth it, and for high-value accounts it is close to mandatory.

The current stack, mid-2026

Passkeys and P-256. Our player would rather use Face ID than a seed phrase, and that is now buildable. Phones and laptops have secure hardware (Apple's Secure Enclave, Android Keystore, anything FIDO2 or WebAuthn) that signs with a curve called secp256r1, also known as P-256. WebAuthn is the browser and OS standard behind passkeys, the thing that pops up Face ID or a fingerprint prompt. The snag is that P-256 is a different curve from Ethereum's secp256k1, and verifying a P-256 signature in pure Solidity costs roughly 200,000 to 330,000 gas, which is too expensive to do on every action [12]. RIP-7212 solved that on L2s first by adding a P256VERIFY precompile (a built-in verifier) at address 0x100 for 3,450 gas, live on chains like Polygon and zkSync from 2024 and OP Stack chains after Pectra [5]. Its mainnet successor, EIP-7951, ships the same precompile at 0x100 for 6,900 gas (raised from RIP-7212's number to prevent abuse, and with an edge-case bug fixed), and it went live on L1 in the Fusaka upgrade, which activated at slot 13,164,544 on 3 December 2025 [4][2]. The result: a wallet where the player logs in with a fingerprint, the account verifies that passkey signature on-chain cheaply and there is no seed phrase anywhere.

Modular accounts. Once smart accounts were everywhere, a new problem appeared. Each vendor built its own way of adding features, so a session-key module written for one wallet would not run on another. Two standards fixed the fragmentation by defining a common plugin interface. Think of the account as a baseplate and the features as parts that snap on: validators (how a signature is checked), executors (how a call is run), hooks (checks that fire before or after execution) and fallback handlers. ERC-6900 (Alchemy, April 2023) is the prescriptive version, mandating strict storage rules and a manifest of how modules depend on each other. ERC-7579 (Rhinestone, Biconomy, ZeroDev and OKX, December 2023) is deliberately minimal, standardizing only the interfaces needed for modules to interoperate (installModule, uninstallModule, isModuleInstalled) and leaving the rest to the builder [11]. The smaller surface won: ERC-7579 is the default for new projects, including Safe through an adapter, ZeroDev's Kernel and OpenZeppelin's account preset. In practice this is how you would ship the session-key feature from earlier. You install a session-key validator module that enforces "only these contracts, only this much, only until this time," and because it follows the standard, the same module works across every compliant wallet instead of being rebuilt per vendor.

L2s split two ways. ERC-4337 runs on every EVM L2 (Base, Arbitrum, Optimism and Polygon) because it needs no protocol changes, and those chains added 7702 after Pectra. zkSync Era and Starknet went further with native account abstraction, where there is no EOA-versus-contract distinction at all: every account is a smart contract with its own validation and execution logic. On those chains the entire first half of this article is just how things work by default, which is where Ethereum L1 is slowly heading.

What I would build today, and what I would wait on

If I were starting a consumer wallet or dApp from scratch, I would build on ERC-4337 with a modular ERC-7579 account, passkey signing wherever the chain has the 0x100 precompile and a paymaster for gasless or token-based gas onboarding, sitting on top of an established bundler and paymaster provider rather than running that infrastructure myself. For a product with a large existing EOA base, like a game with players who already have addresses, I would reach for EIP-7702 delegation to an implementation that also satisfies validateUserOp, so those players keep their addresses and gain the features. For a treasury I would still use Safe.

On security, three habits are not optional. Treat validateUserOp as the security boundary and audit it like one. For 7702, only ever delegate to audited, verified implementations, default to per-chain authorizations and check storage-slot compatibility before re-delegating. And stop using "this address has no code" as a way to tell humans from contracts, because after 7702 that assumption is simply false.

The one thing I would not architect around yet is native, protocol-level account abstraction. The proposal for it, EIP-7701, depends on a separate EVM change (the EVM Object Format) and sits stagnant and unscheduled as of mid-2026. The saving grace is that the migration path is forward-compatible: build on ERC-4337 and EIP-7702 now and you are not building something you will have to rip out when native AA eventually lands. If you want the wider argument for why self-custody is worth this much engineering in the first place, that is what I made in Core Pillars of Web3.

The short version for someone coming back after time away: the one-key EOA has gone from being the whole story to being the fallback option. The interesting surface now is the code you can attach to an account, and as of mid-2026 that code is standardized, audited and running in production.

Glossary

• EOA (externally owned account). An account controlled by a private key. The classic Ethereum wallet. Can start transactions.
• Contract account. An account controlled by its code, with storage but no private key. Cannot start a transaction on its own.
• secp256k1 / secp256r1 (P-256). Elliptic curves used for signatures. Ethereum uses secp256k1; phones and passkeys use secp256r1.
• ecrecover. Ethereum's built-in function for recovering who signed a message, living at address 0x01.
• nonce. A per-account counter that orders transactions and prevents replays.
• precompile. A built-in contract at a fixed low address that does something in native code far cheaper than Solidity could, for example P256VERIFY at 0x100.
• delegatecall. Running another contract's code in your own account's storage and balance context. The mechanism behind both upgradeable proxies and EIP-7702.
• CREATE2 / counterfactual deployment. Deriving a contract's address in advance from its code, so the address can receive funds before the contract is actually deployed.
• meta-transaction / relayer. A user signs a message off-chain and a relayer submits it on-chain and pays the gas, so the user needs no ETH.
• UserOperation. In ERC-4337, a struct describing a user's intent. Not an Ethereum transaction until a bundler wraps it in one.
• bundler. An off-chain server that collects UserOperations, packs them into a real transaction and submits it. The only 4337 participant that needs an EOA.
• EntryPoint. The single canonical ERC-4337 contract that validates and executes every UserOperation.
• paymaster. A contract that pays gas on a user's behalf, either fully sponsored or in exchange for a token.
• session key. A temporary key with scoped permissions (specific contracts, spend caps, an expiry) so an app can act without prompting for every action.
• ERC-712 (typed data). A signing format that shows human-readable fields, which is what lets hardware wallets display and sign structured requests.
• hardware wallet vs hot wallet. Key on a dedicated offline-ish device with its own screen, versus key held in software and exposed to the host machine.
• WebAuthn / passkey. The browser and OS standard behind Face ID and fingerprint login, which signs with the P-256 curve.
• module (validator, executor, hook, fallback). A plug-in that snaps onto a modular smart account (ERC-7579 or ERC-6900) to add a signature scheme, an execution path or a pre/post check.

#Citations

• [1] Ethereum Foundation, "Pectra Mainnet Announcement", blog.ethereum.org, 23 April 2025, https://blog.ethereum.org/2025/04/23/pectra-mainnet
• [2] Ethereum Foundation, "Protocol Announcements" (Fusaka mainnet activation, slot 13,164,544, 3 December 2025), blog.ethereum.org, 6 November 2025, https://blog.ethereum.org/category/protocol
• [3] V. Buterin, S. Wilson, A. Dietrichs, M. Garnett, "EIP-7702: Set Code for EOAs", Ethereum Improvement Proposals no. 7702, eips.ethereum.org, 2024, https://eips.ethereum.org/EIPS/eip-7702
• [4] "EIP-7951: Precompile for secp256r1 Curve Support", Ethereum Improvement Proposals no. 7951, eips.ethereum.org, 2025, https://eips.ethereum.org/EIPS/eip-7951
• [5] U. Doğan et al., "RIP-7212: Precompile for secp256r1 Curve Support", ethereum/EIPs pull request #7212, github.com, 2023, https://github.com/ethereum/EIPs/pull/7212/files
• [6] S. Kessler, "Ethereum Activates Account Abstraction (ERC-4337)", CoinDesk, 1 March 2023, https://www.coindesk.com/tech/2023/03/01/ethereum-activates-account-abstraction-touted-by-founder-buterin-as-key-advance
• [7] eth-infinitism, "account-abstraction Releases" (EntryPoint v0.7 and v0.8, EIP-7702 support, ERC-712 UserOperation hashing, Simple7702Account), github.com, 2024–2025, https://github.com/eth-infinitism/account-abstraction/releases
• [8] OpenZeppelin, "EOA Delegation" (EIP-7702), docs.openzeppelin.com, 2025, https://docs.openzeppelin.com/contracts/5.x/eoa-delegation
• [9] V. Buterin, "Why we need wide adoption of social recovery wallets", vitalik.eth.limo, 11 January 2021, https://vitalik.eth.limo/general/2021/01/11/recovery.html
• [10] Alchemy, "What Is Account Abstraction? (ERC-4337)", alchemy.com, January 2026, https://www.alchemy.com/overviews/what-is-account-abstraction
• [11] zeroknots, K. Kopp, T. Lee, F. Makarov et al., "ERC-7579: Minimal Modular Smart Accounts", Ethereum Improvement Proposals no. 7579, eips.ethereum.org, December 2023, https://eips.ethereum.org/EIPS/eip-7579
• [12] Avalanche, "ACP-204: Precompile Secp256r1" (pure-Solidity P-256 verification gas range), build.avax.network, 2025, https://build.avax.network/docs/acps/204-precompile-secp256r1