An Ethereum account is an onchain identity that can hold assets and participate in transactions. A wallet is software or hardware that helps a person control an account, prepare requests, and sign authorizations. Confusing the two leads users to believe their assets live inside an app when the app may only manage access keys.
Ethereum historically distinguished externally owned accounts authorized by cryptographic keys from contract accounts controlled by programmed rules. Pectra added EIP-7702, which lets a key-authorized account delegate execution to contract code without becoming an ordinary contract account. Smart-account patterns can add recovery, spending policies, sponsored fees, and bundled actions, but configuration and supporting infrastructure create additional failure modes.
What you will learn
- Distinguish accounts, addresses, wallets, keys, and seed phrases
- Compare externally owned accounts with contract-based smart accounts
- Interpret transaction, message, and permission requests before signing
- Evaluate recovery, custody, chain support, and smart-account dependencies
Accounts are state; wallets are tools
An externally owned account has an address, ETH balance, transaction counter called a nonce, and associated key authority. The address is public and can receive assets. The private key creates signatures that prove authorization. Ethereum verifies the signature without learning the private key, then applies the requested transaction if all protocol conditions hold.
A wallet may derive many private keys from one recovery phrase, connect to networks, estimate fees, display balances, and encode contract calls. Reinstalling wallet software does not itself move assets because balances remain in network state. Restoring the correct keys in compatible software restores control, while revealing the recovery phrase gives another party equivalent control.
Signing is broader than sending ETH
A transaction signature can transfer ETH, deploy code, call a contract, or grant token permissions. Wallets should decode the request, but unfamiliar contracts and complex batched actions may remain opaque. Users must verify the destination, network, value, function, and permission scope rather than treating every signature prompt as a harmless login.
Offchain message signatures do not directly consume gas, yet they can authorize later actions. Typed-data standards make structured requests more readable, but a signed permit or marketplace order may empower another party to move assets. The safe question is what authority the signature creates, not whether the wallet labels it a message or transaction.
Nonces, pending actions, and multiple networks
For an externally owned account, the transaction nonce orders outgoing transactions and prevents simple replay on the same chain. A transaction with a later nonce waits until earlier nonces are processed. Replacing a pending request generally uses the same nonce with a sufficiently competitive fee, which preserves sequence rather than erasing history.
The same key can correspond to the same-looking address on Ethereum and many compatible networks, but balances and contract deployments are separate. A token address valid on one network may represent nothing or something different on another. Wallet network selection therefore changes the state being viewed and the destination where an action executes.
Choosing control and recovery models
A hardware wallet isolates key operations from a general-purpose computer but cannot protect against every malicious request displayed or approved. A custodian can offer identity-based recovery while controlling withdrawals under its policies. A multisignature or smart account can distribute authority but depends on contract code, signer coordination, and compatible interfaces.
Good account design starts with realistic threats and recovery drills. Users should document backups, signer locations, guardian independence, inheritance plans, spending limits, and procedures for lost devices. Smart accounts also depend on chain deployment, fee payment, bundling or relay infrastructure, and application support, so portability should be tested before substantial reliance.
Common misconceptions
“Crypto assets are physically stored inside a wallet application.”
Balances are recorded in network state; the wallet manages keys and requests that can control those balances.
“One Ethereum account type is optimal for every user and situation.”
Key-only, custodial, multisignature, and smart-account models trade simplicity, recovery, policy control, compatibility, and dependency risk differently.
“Signing a gas-free message cannot put assets at risk.”
Some messages create permits, orders, or other authorizations that another party can later submit onchain.
Risks and limitations
- Lost or exposed private keys and recovery phrases can cause permanent loss of control or immediate unauthorized transfers.
- Smart-account bugs, malicious modules, compromised guardians, or upgrade authorities can bypass intended recovery and spending rules.
- A malicious or defective EIP-7702 delegate can gain broad control of a key-authorized account, and changing delegates can create storage or initialization hazards.
- Blind signatures and deceptive interfaces can authorize token transfers, permits, or contract calls users did not understand.
- Custodial wallets can freeze accounts, suffer insolvency or breaches, and restrict withdrawals according to external policies.
- Uneven application and network support can strand smart-account features or make recovery tools unavailable when urgently needed.
Key takeaways
- Accounts exist in Ethereum state, while wallets manage keys and construct interactions.
- Externally owned accounts use key signatures; contract accounts enforce programmable authorization rules.
- EIP-7702 lets key-authorized accounts delegate execution to code without removing the key's authority.
- Offchain signatures can carry valuable permissions even when they cost no gas.
- The same address across networks does not imply shared balances, tokens, or contract state.
- Recovery design should be tested as carefully as everyday transaction signing.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.