Ethereum Wallets

Part 1: What a Wallet Is (Execution-Layer Precise)

An Ethereum wallet is primarily a key-management and signing system, not an on-chain account itself.

At the execution layer (EL), the chain processes signed transactions and state transitions. Wallet software does three core jobs:

1. Manages signing authority (private keys or equivalent signing shares).
2. Builds/signs transaction payloads (or UserOperations for ERC-4337 flows).
3. Broadcasts data to the appropriate network path (public txpool, private relay, or ERC-4337 bundler path).

Important distinction:

• Wallet: off-chain software/hardware/service that controls signing.
• Account: on-chain state object (EOA or contract account).

Part 2: Wallet Types in Ethereum

1. EOA Wallets

EOA wallets control secp256k1 private keys directly.

• EOAs sign execution-layer transaction envelopes supported by the active fork and client tooling (commonly type-0/1/2/3, and type-0x04 where EIP-7702 is active).
• Nonce is consumed by each sent transaction.
• Native behavior is simple and widely supported.

Examples: MetaMask (EOA mode), Ledger with EOA account, Trezor with EOA account.

2. Smart Contract Wallets (Smart Accounts)

Smart contract wallets are contract accounts with programmable authorization and policy logic.

• Signature checks and spending rules are implemented in contract code.
• Features can include multisig, session keys, spending limits, social recovery, and batched calls.
• Execution semantics depend on wallet contract implementation.

Examples: Safe smart accounts and other contract wallet frameworks.

3. Account Abstraction (ERC-4337 Model)

ERC-4337 is an application-layer account abstraction system (not native protocol replacement of EL tx format).

Core objects and actors:

• UserOperation: wallet intent object (not an EL transaction by itself).
• Bundler: service that collects UserOperations and submits an EL transaction.
• EntryPoint: on-chain contract that validates and executes UserOperations.
• Paymaster (optional): can sponsor gas under policy constraints.

Flow (simplified):

1. User signs a UserOperation.
2. Bundler simulates and selects UserOperations.
3. Bundler submits a transaction calling EntryPoint.
4. EntryPoint verifies and executes wallet logic.

Part 3: Seed Phrases, HD Derivation, and Addressing

1. Standards and Scope

• BIP-32: hierarchical deterministic key tree.
• BIP-39: mnemonic-to-seed process.
• BIP-44: multi-account derivation path structure.

Ethereum commonly uses:

$$m / 44' / 60' / account' / change / index$$

Where coin type 60 is Ethereum (SLIP-44 registry).

2. Bitcoin Standards Often Confused with Ethereum

BIP-49 and BIP-84 describe Bitcoin SegWit address/script standards. They are not Ethereum address formats.

3. Public Key and Address Relationship

For EOAs, the Ethereum address is derived from the public key hash truncation process. Practically:

• Private key -> public key -> keccak256(public key without 0x04 prefix) -> last 20 bytes.

One-way implication:

• Public key can produce address.
• Address alone cannot recover the public key for arbitrary accounts before a signature reveals needed data.

4. MetaMask: Create Additional Accounts After Unlock

After unlocking MetaMask, users can create additional accounts without generating a new Secret Recovery Phrase.

• Extension (high level):
  1. Unlock MetaMask.
  2. Open the account selector.
  3. Choose “Add account or hardware wallet” (label can vary by version).
  4. Select “Create account.”
• Mobile (high level):
  1. Unlock the MetaMask app.
  2. Open the account switcher.
  3. Tap “Add account.”
  4. Select “Create new account.”

Technical model:

• MetaMask follows HD derivation based on BIP-39 (mnemonic), BIP-32 (key tree), and BIP-44 (path convention).
• Accounts created this way are child keys from the same mnemonic root, typically at increasing address indices.
• A common Ethereum path form is m/44'/60'/0'/0/n, where n increments for each added account.

Example:

• Account 1: m/44'/60'/0'/0/0
• Account 2: m/44'/60'/0'/0/1

               [ Your 12-Word Master Seed Phrase ]
                               │
         ┌─────────────────────┼─────────────────────┐
         ▼                     ▼                     ▼
   [ Account 1 ]         [ Account 2 ]         [ Account 3 ]
   Address: 0xAbc...     Address: 0xDef...     Address: 0xGhi...

Security and privacy caveats:

• These accounts are independent on-chain addresses (separate balances/nonces).
• They are not guaranteed to be unlinkable in practice; transaction graph overlap and funding patterns can still reveal relationships.
• This account-indexing behavior is unrelated to validator keys and consensus participation.

Part 4: Custody and Key-Control Models

1. Self-Custody

User controls signing authority.

Typical implementations:

• Software wallet (desktop/mobile, optionally OS enclave-backed).
• Hardware wallet.
• Air-gapped signing device.

2. Custodial Wallets

Service provider controls keys/signing.

Typical implementations:

• Exchange custody accounts.
• Managed wallet infrastructure providers.

3. Institutional Patterns

• HSM-backed signing infrastructure.
• MPC/threshold signing architectures.
• Policy engines with role-based approval workflows.

Security note: custody model determines who can actually authorize movement of funds.

Part 5: MPC, Multisig, and Threshold Control

These are related but different:

• Multisig: on-chain policy requiring multiple signatures/approvals according to contract/script rules.
• MPC/threshold signing: off-chain cryptographic protocol producing a valid signature without reconstructing a full private key in one place.

Clarification:

• Multisig concept is broadly portable, but each chain implements it differently at protocol/contract level.
• MPC is not automatically safer than multisig; security depends on implementation, key ceremonies, operational controls, and failure assumptions.

Part 6: Execution-Layer Fee and Transaction Context

Wallets that submit EL transactions should be explicit about modern fee types:

• Type-2 (EIP-1559): base fee + priority fee with max fee caps.
• Type-3 (EIP-4844): execution gas fee plus blob gas fee caps.

For reliable UX, wallets should:

1. Distinguish includability constraints from final charged fee.
2. Handle replacement/cancel behavior via nonce + fee bumping policy.
3. Detect and explain failures (underpriced replacement, nonce too low, insufficient funds, execution revert).

Part 7: Practical Wallet Taxonomy

A compact classification useful for architecture decisions:

1. Signer model:

• Single-key EOA.
• Contract wallet policy engine.
• MPC/threshold signer set.

2. Custody model:

• Self-custody.
• Custodial.
• Hybrid/enterprise governance.

3. Submission path:

• Public EL mempool.
• Private orderflow channels.
• ERC-4337 bundler path.

4. Security envelope:

• Hot software key.
• Hardware-backed key.
• Distributed signing with operational controls.

Part 8: Common Mistakes to Avoid

1. Treating wallet app UI as equivalent to account semantics.
2. Mixing Bitcoin derivation/address conventions into Ethereum explanations.
3. Assuming ERC-4337 UserOperations are native EL transactions.
4. Ignoring type-3 blob fee caps in post-Dencun fee logic.
5. Assuming address alone proves key ownership without valid signature context.

Part 9: References

• Ethereum Accounts
• Ethereum Transactions
• ERC-4337 Specification
• ERC-4337 Docs
• MetaMask Smart Accounts Overview
• MetaMask: Add Accounts in Your Wallet
• Safe Smart Account Docs
• BIP-32
• BIP-39
• BIP-44

Part 10: DIY Implementation Page

If you want a hands-on implementation tutorial (Python + local signing + raw tx broadcast), see:

• DIY Ethereum Wallet