Why EOAs Are Obsolete: What a Smart Account Actually Does

As of April 2026, BundleBear shows over 1.07 billion ERC-4337 UserOperations and 56.7 million smart accounts that have transacted at least once across Ethereum and the major L2s. That is no longer a niche. The single-key, secp256k1-only Externally Owned Account that Ethereum launched with in 2015 is being routed around at scale, and the on-chain numbers are catching up to a quieter protocol-level fact: the account itself is now programmable.

This is Part 1 of a five-part series on smart accounts. The goal here is narrow and load-bearing: explain what an EOA actually is, what a smart account actually is, and why "smart account vs EOA" is no longer a UX preference but a structural choice about how your self-custody is enforced.

What an EOA actually is, in protocol terms

Ethereum's Yellow Paper defines two account types: Externally Owned Accounts and Contract Accounts. The only state-level difference between them is the codeHash field. For an EOA, codeHash is the hash of the empty string. For a contract account, it points to executable EVM bytecode. That is the entire distinction at the protocol layer.

An EOA is therefore not a "wallet" in any meaningful sense. It is an address derived from the last 20 bytes of keccak256(public key), with the keypair fixed to the secp256k1 curve. MetaMask, Ledger, and Zelcore are user interfaces that hold the key. They are not the account. If you have not seen the underlying mechanic before, our primer on public and private keys, and how an address is derived covers it end to end.

Until ERC-4337 shipped in 2023, every transaction on Ethereum had to originate from an EOA, and the protocol enforced exactly one validation rule: a valid secp256k1 signature over the transaction hash. Hold a balance, sign one ECDSA signature per transaction, pay gas in ETH from the same account. That is the full surface area of an EOA. There is nothing else it can do.

The structural limits that matter for users

These are not UX papercuts. They are the structural reason behind the bulk of self-custody losses we still see in 2026.

• Single point of failure. One private key controls everything. Lose it, lose the account. Leak it, lose the funds, irreversibly. There is no recovery primitive in the protocol, which is precisely why a single seed phrase is the dominant point of failure in self-custody.
• Single curve. secp256k1 is hard-coded. You cannot use a passkey (P-256), an Ed25519 key, BLS, or a post-quantum scheme.
• No native multisig. Every "multisig" on Ethereum, from the original Gnosis Multisig to Safe, is a contract that an EOA calls. The EOA itself can never require two signatures.
• No batching. An EOA does one thing per transaction. Approving a token and then swapping it is two signed transactions, two confirmations, two gas payments.
• No spending policy. The protocol has no concept of "this key can spend up to $500/day" or "this key can only call Uniswap."
• Gas must be paid in ETH by the same account doing the action. There is no native sponsorship and no native paying-in-USDC.

This is the container every Ethereum user has been forced into for a decade.

What a smart account actually is

A smart account is, in the literal protocol sense, a contract account: an address whose codeHash points to bytecode. The bytecode defines, in code, the rules under which the account will accept an action.

Where an EOA's validation rule is the one fixed secp256k1 check, a smart account's validation rule is whatever the contract says it is. It can be a 2-of-3 multisig, a passkey signature verified on the secp256r1 curve, a hardware-attested key, a time-lock, a daily limit, a whitelisted call target, or any combination of these. Smart contract accounts validate signatures via the EIP-1271 standard rather than a fixed protocol-level secp256k1 check, which is what makes alternative signature schemes possible in the first place.

Because the rules are code, they are upgradeable, composable, and revocable. Smart accounts have existed on Ethereum since 2018 (Safe is the canonical example). What was missing was a way to make them the default, a way to send transactions without first having an EOA pay the gas. ERC-4337 and EIP-7702 closed that gap.

How we got here: a short history of account abstraction

The idea of unifying EOAs and contracts is as old as Ethereum itself. Vitalik's EIP-86, drafted in 2016, was the first detailed proposal. The path from there to today's deployed standards took five attempts.

• EIP-2938 (September 2020) proposed protocol-level account abstraction. It was abandoned, too invasive, and Ethereum was deep in the proof-of-stake transition.
• EIP-3074 (October 2020) introduced the AUTH and AUTHCALL opcodes, letting an EOA delegate to an invoker contract. It was withdrawn over security concerns and replaced.
• ERC-4337 went live on Ethereum mainnet on 1 March 2023. It is application-layer only, no hard fork, and routes pseudo-transactions called UserOperations through a separate mempool, a Bundler, and a singleton EntryPoint contract.
• EIP-7702 shipped with the Pectra upgrade on 7 May 2025. It introduces transaction type 0x04, in which an EOA signs an authorization tuple (chain_id, address, nonce, y_parity, r, s) that points the account at delegated contract code via the 0xef0100 || address indicator. The EOA temporarily behaves as a smart account without migrating funds.
• ERC-6900 standardises the modular plug-in architecture under which smart accounts compose validation, execution, and hook modules.

The takeaway: account abstraction is no longer an experiment. It is a deployed, layered standard with a clean ERC-4337 path for greenfield smart accounts and an EIP-7702 path that lets every existing EOA opt in.

The five capabilities a smart account adds

If an EOA is "one key, one signature, one transaction," a smart account is the strict superset.

• Programmable validation. Any signature scheme (passkey, P-256, hardware HSM), any quorum (2-of-3, 3-of-5), any condition (block height, oracle price). The account decides what "authorized" means.
• Atomic batching. Approve, swap, and deposit in one signed action. Either all of it executes or none of it does. This directly retires the approval debt and the multisig pattern in Zelcore workarounds users have had to manage by hand.
• Gas abstraction via paymasters. A third-party contract pays gas on the user's behalf, or the user pays in USDC, USDT, or any ERC-20 the paymaster accepts. For a deeper view of how gas, approvals, and DeFi mechanics fit together, the DeFi fundamentals piece is the prerequisite.
• Session keys. Scoped, time-boxed, app-specific signing keys. "This key can spend up to 100 USDC on Uniswap for the next 24 hours." Compromise of a session key is bounded by policy, not by the size of the account.
• Recovery. Social recovery, hardware recovery, time-locked recovery. The account can be recovered without the original signing key, which is what finally retires the seed phrase as a single-point-of-failure artefact.

Why this is now load-bearing for self-custody

The adoption curve is no longer a debate. EIP-7702 racked up over 11,000 authorizations in its first week post-Pectra and crossed 25,000 wallets shortly after, with OKX and MetaMask leading. BundleBear's running totals (1.07B UserOps, 56.7M smart accounts) are the rest of the story.

What actually shifts is the threat model. With an EOA, the user's job is "protect the seed phrase forever, never sign a malicious transaction, never get phished, never reuse the wrong device." That is a job humans demonstrably fail at. With a smart account, the user's job is "configure a recovery quorum and a spending policy once." That is a job code can enforce.

A smart account does not replace a hardware wallet. It lets a hardware wallet do more, and in fact narrows the role a hardware wallet still does for a smart account to its highest-leverage use: signing the high-value, low-frequency master operations, while session keys handle the day-to-day.

What's next in this series

This was the framing. The rest of the series is the operational substance.

• Part 2 unpacks the ERC-4337 stack: UserOperations, Bundlers, EntryPoint, Paymasters, and where each one can fail.
• Part 3 covers EIP-7702 delegation in detail: the authorization tuple, the 0xef0100 indicator, and the security considerations of pointing your EOA at someone else's code.
• Part 4 is a comparison of the major smart account implementations (Coinbase Smart Wallet, Safe, Argent, Ambire) and what each one actually defaults to.
• Part 5 is the operational capstone: how to configure recovery, session keys, and spending policy on a real account without giving up self-custody.

The single sentence to carry into Part 2: an EOA is a key with an address; a smart account is a contract that decides what its key is allowed to do.