Ethereum has two kinds of accounts and treats them as fundamentally different. Most user guides skip past this distinction because it sounds technical, but the distinction shapes what every wallet, every dApp, and every future upgrade can do. If you have ever wondered why your wallet needs ETH to move any other token, or why "smart wallets" are a category at all, this is the answer.
The two families
Every Ethereum account has an address. Behind each address is one of two things:
**Externally-Owned Account (EOA)**: an address controlled by a private key. When you use MetaMask, Rabby, or a hardware wallet, you are controlling an EOA. There is no code at that address — just a balance and a nonce. Every user wallet you have ever set up with a seed phrase is an EOA.
**Smart Contract Account**: an address with code deployed at it. When you send a transaction to a Uniswap pool, a Aave lending market, an ENS registry — you are sending to a smart contract account. The code at that address defines what happens when the account receives a message. There is no private key controlling it; the code is the controller.
The two account types are indistinguishable at first glance — same address format, both can hold ETH and tokens, both appear as regular entries on Etherscan. But they behave very differently.
What an EOA can do
An EOA can:
- Initiate transactions (only EOAs can start a transaction sequence; contracts respond to transactions, they don't initiate)
- Sign messages with the associated private key
- Hold ETH and any tokens
- Receive ETH and tokens
An EOA cannot:
- Execute logic beyond "transfer" and "call another address"
- Enforce any conditions on when it spends
- Have multiple signers (multisig requires a smart contract)
- Automatically pay gas from something other than ETH
- Do anything if you lose the private key
The last point is the big one. EOAs have exactly one authorization mechanism: the private key. Lose the key, lose access forever. There is no recovery, no reset, no "forgot password" flow.
What a smart-contract account can do
A smart-contract account executes arbitrary logic on receiving a message. Depending on how it's written, it can:
- Require multiple signers (multisig)
- Allow social recovery (a set of trusted parties can rotate the owner)
- Pay gas in tokens other than ETH (via a paymaster)
- Batch multiple operations into one transaction
- Enforce spending limits, daily caps, whitelists of allowed destinations
- Grant temporary "session keys" to specific dApps for specific actions
- Rotate its own signing keys without losing the address
None of this is optional or bolt-on — it is all in the contract's code. Different smart wallets implement different subsets. Gnosis Safe multisig, Argent social recovery, Coinbase Smart Wallet, and various ERC-4337 implementations all belong to this category with different feature sets.
Smart-contract accounts cannot initiate transactions. They can only respond to a message from an EOA. This is a fundamental limitation of the base protocol — but ERC-4337 works around it, as covered later.
Why every wallet needed ETH for gas (until recently)
Because only EOAs can initiate transactions, and EOAs pay gas in ETH, every transaction on Ethereum historically required the sender to hold ETH — even if the transaction only moved USDC or interacted with a token contract that had nothing to do with ETH.
This is a real UX problem. A new user given $50 in USDC to try DeFi discovers they cannot do anything until they also acquire some ETH for gas. On mainnet, that means finding an exchange or bridge, on-ramping ETH, and dealing with the base-fee auction. On L2s the cost is lower but the requirement is the same.
Smart-contract accounts, via paymasters (see next section), can pay gas in any token — USDC, DAI, whatever. This is one of the killer features driving adoption of smart wallets.
The paymaster mechanism
A paymaster is a smart contract that agrees to pay gas on behalf of another user, usually in exchange for something (tokens transferred to the paymaster, off-chain payment, sponsorship by an application).
Under ERC-4337, a UserOperation can specify a paymaster address. When the bundler executes the operation, the paymaster pays the gas cost in ETH, and the paymaster's own logic decides how to charge the user. Common patterns:
- User pays in USDC; paymaster takes USDC and pays gas in ETH
- Application sponsors a set number of transactions per user (onboarding UX)
- User has a subscription that covers gas up to a cap
This dramatically lowers the friction of new users. A wallet built on ERC-4337 with a paymaster integration can let a new user do their first swap, first mint, first anything without needing to touch ETH.
Recovery: the strongest argument for smart wallets
The most compelling reason to use a smart-contract account is recovery. Losing an EOA's private key means losing the funds — full stop. Losing a smart-contract wallet's active key can be recovered if the contract implements social recovery.
Argent pioneered this in 2018: your wallet has an active signing key (like an EOA's private key) plus a set of "guardians" — trusted addresses controlled by other people or devices. If you lose your active key, a threshold of guardians can vote to rotate it to a new key. No seed phrase to lose, no paper backup that can be destroyed.
Coinbase Smart Wallet (2024) uses passkeys as the primary signing mechanism, backed by biometrics on the device. Recovery goes through Coinbase's account infrastructure.
Neither is perfect. Social recovery assumes your guardians remain available and honest. Passkey wallets assume the platform (Apple, Google, Coinbase) continues to operate. But both remove the "single point of failure" problem of an EOA seed phrase.
Trade-offs of smart wallets
Smart-contract accounts are not universally better. The tradeoffs:
- **Deployment cost**: creating a smart wallet costs gas (though ERC-4337 defers this until first use)
- **Complexity**: more surface area for bugs; well-audited contracts (Gnosis Safe) are safe, brand-new ones are less proven
- **Compatibility**: some dApps still assume EOA senders and don't handle smart-contract-account signatures correctly
- **Ecosystem lag**: hardware wallets, browser extensions, and some tools have taken time to properly support smart wallets
For power users comfortable with self-custody, an EOA with a hardware wallet remains a reasonable choice. For onboarding users or use cases requiring specific features (multisig, sponsored gas, session keys), smart wallets are the right answer.
ERC-4337 and the direction of travel
ERC-4337 (activated on Ethereum in 2023) is the protocol layer that makes smart-contract wallets first-class citizens without requiring changes to Ethereum's base protocol. Instead of new transaction types, it defines a UserOperation format that gets bundled by third-party services (bundlers) into normal Ethereum transactions.
The consequence is that smart wallets can be built and deployed today without waiting for a hard fork. Every major wallet infrastructure company is building on ERC-4337. Coinbase Smart Wallet, Safe{Core}, Zerodev, and Biconomy are the current infrastructure players.
Longer term, EIP-7702 (added in Ethereum's Pectra upgrade) lets existing EOAs temporarily "upgrade" to smart-contract behavior for a single transaction. This bridges the gap: users don't have to migrate their addresses to get smart-wallet features. Your existing MetaMask address can be augmented with smart-wallet capabilities without giving up its history.
Practical takeaway
If you use MetaMask, Rabby, a hardware wallet, or any wallet backed by a seed phrase, you're using an EOA. Fine for the vast majority of cases; you're in charge of key security and there's no third-party dependency.
If you use Argent, Safe (Gnosis), Coinbase Smart Wallet, Zerodev, or anything advertising "account abstraction" or "smart wallet," you're using a smart-contract account. You get features like recovery, gas abstraction, and multisig — at the cost of some additional complexity and dependence on the contract's design.
The direction of the ecosystem is toward smart-contract accounts becoming the norm, especially for new users. EOAs will remain the mode for power users and cold storage where you specifically want a purely-cryptographic key relationship. Both will coexist indefinitely.
