Ethereum Accounts
Ethereum has two account types — Externally Owned Accounts (EOAs) controlled by private keys and Contract Accounts controlled by code — each with a balance, nonce, and optional storage, forming the foundation of Ethereum's state model.
Every Ethereum address is one of two account types. EOAs are controlled by a private key holder who signs transactions. They have a balance (in wei) and a nonce (transaction count) but no code. Contract Accounts are controlled by their deployed bytecode — they cannot initiate transactions, only respond to them. They have balance, nonce (number of contracts created), code hash, and storage root (a Merkle Patricia trie of key-value storage). Both account types share the same 20-byte address space. Account Abstraction (ERC-4337, EIP-7702) is blurring this distinction by allowing smart contract wallets to act like EOAs with features like social recovery, gas sponsorship, and batched transactions.
Tradeoffs
Strengths
- Two-account model is simple and well-understood
- EOAs provide direct cryptographic ownership
- Contract accounts enable programmable money and complex logic
- CREATE2 enables deterministic addressing across chains
Weaknesses
- EOA key loss means permanent fund loss — no recovery mechanism
- EOAs cannot batch transactions or customize validation logic
- State grows unboundedly, increasing node requirements over time
- Contract-EOA distinction creates UX friction that account abstraction aims to resolve
Likely Follow-Up Questions
- What are the security implications of using tx.origin vs msg.sender?
- How does ERC-4337 account abstraction change the transaction flow?
- Explain storage layout in Solidity and why it matters for proxy upgrades.
- What is CREATE2 and why is it important for counterfactual deployments?
- How would you design a smart contract wallet with social recovery?
- What happens to an account's state when SELFDESTRUCT is called post-Dencun?
Source: editorial — Synthesized from Ethereum Yellow Paper, ERC-4337 specification, and EIP-7702