Ethereum defines an externally owned account (EOA) as an account controlled by a private key, with no contract code attached, that can hold ether, hold ERC-20 balances, and originate transactions.
​

This article covers the definition, the key derivation and signing mechanism, the four-field account state on Ethereum, how EOAs differ from smart wallets and contract accounts, the security trade-offs that come with full self-custody, and what EIP-7702 changes about the EOA model in the Pectra hardfork.
​

An EOA is one of two account types defined in the Ethereum Yellow Paper. The other is a contract account. EOAs are externally owned because the authority to spend from them lives outside the chain in a private key held by a person, hardware module, or custody service. Contract accounts are internally controlled by their deployed bytecode.
​

An EOA has no code, an empty storage trie, a balance, and a nonce. It can send ether, transfer tokens, deploy contracts, and call functions on other contracts. It cannot programmatically check conditions, batch operations, or sponsor its own gas. Those behaviors require either a smart contract account, a relayer, or a delegation under EIP-7702.
​

Production wallet software like MetaMask, Ledger, and Trezor exposes EOAs by default. So do most exchange withdrawal addresses, since EOAs are cheap to generate and require no on-chain state.
​

EOAs sit on top of ECDSA over the secp256k1 curve, the same elliptic curve Bitcoin uses. The mechanism has three stages: key generation, address derivation, and transaction signing.
​

A wallet draws a 256-bit integer at random from the curve order. That integer is the private key. The corresponding public key is computed by multiplying the curve generator point by the private key, producing a 512-bit value that is published openly. Generation is offline. Nothing touches the chain.
​

The 20-byte Ethereum address is the rightmost 20 bytes of the keccak-256 hash of the public key. Addresses are conventionally written in EIP-55 mixed-case checksum format, like 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045. The address space is 2^160, large enough that accidental collisions are computationally infeasible.
​

To send a transaction, the wallet RLP-encodes the fields (nonce, max fee, max priority fee, gas limit, recipient, value, calldata, chain ID), hashes the encoding with keccak-256, and signs the hash with the private key. The signature is a triple (v, r, s) that any node can verify against the sender address using ecrecover. The full sequence is specified in EIP-1559 and EIP-2718.
​

Once broadcast, the transaction enters the public mempool, a validator includes it in a block, the protocol increments the EOA's nonce by one, and the resulting state change is final after roughly 12.8 minutes (two epochs, per Ethereum proof-of-stake finality docs).
​

Ethereum stores every account, EOA or contract, as a four-field tuple in the world state trie. The four fields are nonce, balance, storage root, and code hash. EOAs and contracts differ only in the values of the last two.
​

Nonce. A counter incremented after every outgoing transaction. The nonce prevents replay: a signed transaction with nonce 7 is valid exactly once. The protocol rejects anything with the same nonce after the first inclusion.
​

Balance. The wei balance of the account. One ether equals 10^18 wei. Token balances are not stored here; ERC-20 holdings live in the token contract's storage trie, indexed by EOA address.
​

Storage root. The root hash of the account's storage trie. For an EOA this is always the empty trie hash, since EOAs cannot persist data. Contract accounts use this field to commit to the entire contents of their storage.
​

Code hash. The keccak-256 hash of the account's bytecode. For an EOA it is always the hash of the empty string. Since EIP-7702 activated with Pectra, an EOA can authorize a delegation that writes a delegation indicator (0xef0100 plus a contract address) as its code, so this slot no longer has to hold the empty-string hash.
​

The terms get used loosely. The distinction worth holding is that "contract account" is a chain-level concept and "smart wallet" is a product concept. A smart wallet is built from one or more contract accounts, often paired with a bundler and paymaster following ERC-4337.
​

EOAs are controlled by a private key. Contract accounts are controlled by their bytecode, which can implement multisig, daily spend limits, social recovery, session keys, or whatever else the developer encodes. Smart wallets like Safe, Argent, Coinbase Smart Wallet, and Privy embedded wallets sit on top of contract accounts and surface UX features that pure EOAs cannot deliver.
​

For a fuller comparison, see the dedicated piece on account abstraction and the ERC-4337 reference.
​

The table compares the two account models on the dimensions that matter for builders and users: how transactions are authorized, whether the account can be recovered, who pays for gas, and live production examples. Sources: Ethereum.org accounts spec and ERC-4337.

Ethereum has exactly two account types at the protocol level, as the ethereum.org accounts documentation lays out. An EOA is controlled by a private key. A contract account is a smart contract deployed to the network and controlled by its code. Both can receive, hold, and send ETH and tokens. The architectural difference sits in two of the four state fields: an EOA has no code and an empty storage trie, while a contract account carries deployed bytecode and persistent storage.
​

An EOA transaction is valid only if its ECDSA signature recovers to the sender address. Every EOA on Ethereum validates the same way, and nothing about that rule can be changed per account.
​

A contract account has no private key. It validates by running its own code. A Safe account requires a set threshold of its owners to confirm a transaction. An ERC-4337 account implements validateUserOp, which can check a passkey, a session key, or a spending policy before anything executes.
​

Only EOAs can initiate transactions. A contract account can only send messages in response to a transaction it receives, so every chain of contract calls traces back to an EOA signature. ERC-4337 keeps that rule intact: a bundler packs user operations into an ordinary transaction that calls the EntryPoint contract.
​

Creating an EOA costs nothing, since the key pair is generated offline. Creating a contract costs gas because it uses network storage. A contract address comes from either CREATE, which hashes the creator address and nonce, or CREATE2 from EIP-1014, which hashes the creator address, a salt, and the init code hash. CREATE2 addresses can be computed before deployment and reproduced on other chains when the same factory and parameters are used.
​

For an EOA, the nonce counts transactions sent. For a contract account, it counts contracts that account has created, which is why CREATE can derive a fresh child address each time.
​

EIP-161, activated in the Spurious Dragon hard fork at block 2,675,000, requires account creation transactions and CREATE to increment the new account nonce by one before the init code runs. A newly deployed contract therefore starts at nonce 1, not 0. The same EIP defines an empty account as one with no code, zero nonce, and zero balance, and starting at 1 keeps a contract from counting as empty partway through its own creation.
​

Sources: ethereum.org accounts, EIP-161, EIP-1014, and EIP-7702.

EOAs are the lowest-friction way to access Ethereum. They cost nothing to create, work on every EVM-compatible chain, and integrate with every existing wallet, exchange, RPC provider, and dapp. The downsides are the inverse: every weakness is structural, not configurable.
​

Free creation. No deployment transaction, no gas. A wallet can generate millions of EOAs offline.
​

Universal compatibility. Every EVM chain derives addresses the same way, so a single private key controls the same address on Ethereum, Arbitrum, Base, Polygon, Optimism, and roughly 200 other EVM networks.
​

Direct origination. EOAs can submit transactions to the public mempool without needing a relayer or paymaster. That matters for time-sensitive use cases like liquidations, MEV, or arbitrage.
​

Minimal trust surface. The only thing standing between an attacker and your funds is the private key. There is no upgradable contract logic to audit.
​

Single point of failure. A leaked or lost private key is permanent. There is no recovery path. Chainalysis estimated in a 2017 lost-coin analysis that 17% to 23% of all mined bitcoin had been irreversibly lost; the analogous figure for ether is harder to measure but non-trivial.
​

No batched operations. An approval and a swap are two separate signed transactions, each consuming gas and a nonce. Smart wallets bundle these into one user operation.
​

Native gas only. An EOA must pay for gas in ETH (or the chain's native token). It cannot pay in USDC or any other ERC-20 without an out-of-protocol relayer.
​

No programmable policy. Daily spend caps, session keys, and multisig require contract logic. EOAs do exactly what the private key tells them to.
​

Until 2024, no. EOAs and contract accounts were strictly separated by their code hash. EIP-7702, included in the Pectra hardfork that activated on Ethereum mainnet on May 7, 2025, changes that.
​

Under 7702, an EOA can sign a special authorization message that points to a contract address. The EOA's code is set to a delegation indicator that points at that contract, and any call to the EOA executes the target contract's code. The delegation stays in place until the EOA signs a new authorization, and delegating to the zero address clears it, per the EIP-7702 specification. The EOA still keeps its address, balance, and nonce.
​

The practical result is that an existing wallet address can opt into smart-wallet features (gas sponsorship, batching, session keys) without migrating funds to a new contract address. Wallets like MetaMask and infrastructure providers like ZeroDev have rolled out 7702 delegations through 2025.
​

For the deep dive, see What is EIP-7702 and the 2026 account abstraction guide.
​

Most EOA losses come from one of three causes: private-key exposure, signature phishing, and approval abuse. Each has a concrete mitigation.
​

Hardware-backed keys. A Ledger or Trezor device keeps the private key inside a secure element. The host computer never sees it. Sign verification happens on the device screen, so malware cannot silently swap a destination address.
​

EIP-712 typed data review. Phishing sites trick users into signing opaque hex blobs that authorize transfers. EIP-712 structured data shows the wallet what is actually being signed. Modern wallets render fields like recipient, amount, and contract.
​

Approval hygiene. An ERC-20 approval is unbounded by default, often set to 2^256 - 1. Tools like Revoke and Etherscan's token approval checker let users audit and revoke standing approvals. The 2023 Ledger Connect Kit incident drained roughly $610,000 from EOAs that had old approvals to compromised contracts.
​

Cold-storage architecture. Operational EOAs hold day-to-day funds. Cold EOAs hold long-term reserves on hardware that never connects to a hot host. Treasuries split deposits between several cold EOAs to avoid concentration risk.
​

Phishing resistance. Bookmark dapp URLs. Verify wallet popups against the visible domain. Treat any unsolicited message that says "claim airdrop" or "your wallet was compromised" as hostile.
​

EOAs are universal but local: a single key controls the same address on every EVM chain, but moving balances between chains still requires bridging, swapping, and signing on each side. Eco is the stablecoin execution network that absorbs that complexity. A team integrates Eco's intent API once and gets unified stablecoin routing across chains: a user signs an intent from any EOA, and Eco's solver network selects between CCTP, Hyperlane, LayerZero, and Wormhole rails to settle on the destination chain. Eco's stablecoin routing layer pairs with EOAs to make multi-chain stablecoin operations one signature instead of five. The EOA stays in the user's hands. The orchestration sits behind the API.
​

Not exactly. An EOA is the on-chain account; a wallet is the software or hardware that manages the private key controlling one or more EOAs. MetaMask is a wallet that exposes many EOAs derived from one seed phrase. Each EOA is a distinct account on chain.
​

No. The address is derived deterministically from the public key, which is derived from the private key. Two distinct private keys map to two distinct addresses with overwhelming probability. Address collisions are computationally infeasible.
​

No. Generating a private key, deriving the public key, and computing the address are all offline operations. The EOA only appears on chain after it sends or receives its first transaction. Smart contract accounts, by contrast, require a deployment transaction.
​

Yes. EOAs hold ERC-721 and ERC-1155 tokens the same way they hold ERC-20s: the token contract's storage maps the EOA address to the token IDs it owns. Marketplaces like OpenSea read those mappings to display holdings.
​

An EOA can sign an authorization that attaches contract code to its address until the delegation is replaced or cleared, letting it execute batched operations, sponsored gas, and session-key flows without changing the address. The private key still controls everything. EIP-7702 is the most material EOA change in Ethereum's history.
​

An EOA is controlled by a private key, has no code, and can start transactions. A contract account is controlled by deployed code, can implement any validation rule, and only acts when a transaction or call reaches it. Both hold ETH and tokens the same way.
​

Since EIP-161 in the Spurious Dragon hard fork, contract creation increments the new account nonce by one before the init code runs. A fresh contract starts at nonce 1, and the nonce then rises by one for each contract it creates.
​

A contract account. The contract enforces the signature threshold. The individual signers are usually EOAs, often with keys held on hardware wallets, but the multisig address itself is a contract.
​