# 07 — Wallets and Account Abstraction Quick question: where do your coins live? If the answer that comes to mind is "in my wallet," it's worth looking closer — because they don't, and the difference turns out to matter enormously. Coins live in chain state — they're entries in the replicated map we've been building up since module 01. A wallet holds no assets at all. It holds *keys*, and keys are the ability to sign. A wallet is an authorization device that happens to be wearing a bank's clothing, and most of wallet engineering follows from taking that seriously. ## What a wallet is | **Wallet type** | **Control model** | |---|---| | EOA wallet | **Externally Owned Account** — one private key controls the address | | Hardware wallet | Key isolated in dedicated hardware | | Smart contract wallet | A contract's code decides what's permitted | | MPC wallet | **Multi-Party Computation** — key shares split across parties; no whole key exists anywhere | | Embedded wallet | An app creates and manages the wallet invisibly | Whatever the type, the job list is the same: generate or import keys, display balances, construct transactions, estimate fees, request signatures, protect the user from signing something malicious, recover access, link accounts. Read that list again and notice which item is unlike the others. *Protect the user from signing something malicious.* Everything else is engineering. That one is the product — and arguably the hardest problem on the list. ## Signing is not logging in Recall the warning from [[02 Cryptographic Primitives]]: a signature can authorize irreversible movement of assets. Now consider the user's experience — "please sign this" arrives looking nearly identical for wildly different requests: | **Action** | **Risk** | |---|---| | Sign login message | Usually low | | Sign permit/approval | Off-chain approval a contract submits for you — can be high | | Sign transaction | Can move assets | | Sign arbitrary typed data (EIP-712) | Structured format wallets can display field-by-field — risk depends on content | The same gesture — click, confirm — spans everything from "prove you're you" to "hand over everything you own." A good wallet makes that difference legible *before* the click, and most of wallet security UX is the ongoing struggle to answer one question honestly in one screen: what am I about to authorize? There's a deeper asymmetry underneath, worth naming because it explains the stakes. In the systems you've built, authorization mistakes get caught in review, rolled back, compensated. Here, the signature *is* the review, and settlement is final. No undo. That's why wallet UX is security-critical rather than cosmetic — the confirmation dialog is the last line of defense, and often the only one. ## Account abstraction Now consider the traditional Ethereum account (EOA) as a product, and it starts looking rough. One key, one account, no policy. Lose the key: everything gone. Leak it: everything gone. No spending limits, no recovery, no second factor. The failure modes are silent and total — for most humans, that's a disqualifying design. Which invites a genuinely interesting question: what if an account were a *program* instead of a key? That's account abstraction. Once accounts are programmable, a lot of missing product surface appears at once: - Social recovery (lose a device without losing everything) - Spending limits - Session keys (approve a game for an hour, not forever) - Gas sponsorship (the app pays fees; the user never sees gas) - Batched actions - Multi-factor validation - App-specific permissions ERC-4337 achieves this without changing Ethereum's base protocol, by adding a parallel lane — an alternate mempool so smart accounts can be validated by custom logic before entering a normal block: ```text UserOperation -> bundler -> EntryPoint contract -> smart account validates -> smart account executes ``` The pieces, briefly: a `UserOperation` is an intent-to-act, waiting in an alternate mempool. A **bundler** packages many of them into one real transaction. The **EntryPoint** contract dispatches each to its smart account, whose own code decides what counts as valid — any policy the account cares to program. A **paymaster** can pay the gas on the user's behalf. The quiet significance, easy to miss in the mechanics: validation logic moves from the protocol into account code. "Whoever holds the key is the account" becomes "whatever the account's code accepts is authorized." That's the bridge from crypto wallets to something an ordinary person could safely use — accounts that behave like modern app accounts and settle like blockchains. ## Learning outcomes Questions worth trying on: - Could you explain to a newcomer why "my coins are in my wallet" is wrong — and give a concrete case where the distinction bites? - Could you rank the wallet types by what an attacker would have to compromise to steal funds? - Why is "sign this message" sometimes harmless and sometimes total loss? Could you sketch the screen that makes the difference legible? - Could you walk the ERC-4337 flow, saying what each component adds — and which new parties the user now trusts? ([[Trust Assumptions]], as ever.) - And the thread to pull forward: wallets talk to chains through RPCs, and apps learn what happened through indexers. What is all that infrastructure, and when does it lie? ## Checkpoint 1. What can a smart contract wallet do that an EOA categorically cannot? *(If unsure, revisit "Account abstraction".)* 2. In an MPC wallet, where does the private key live? *(It's a trick question — if unsure, revisit the wallet-types table.)* 3. What does a paymaster pay for, and why would it want to? *(If unsure, revisit the 4337 flow; the business logic gets fleshed out in [[Wallet Infrastructure Roles (Privy)]].)* **Exercise.** Build a minimal wallet-signing demo: connect a wallet, sign a plain message, then sign a typed-data payload. Display exactly what was signed, byte by byte. Then try writing the one-paragraph explanation a non-technical user would need before each signature. You'll find the second half is much harder than the first — which is precisely the lesson. ## Resources - **ERC-4337 documentation** — the spec and its reference flow; the practical center of modern account abstraction. - **Mastering Ethereum** — the wallets and keys chapters, for EOA foundations. - **WalletConnect docs** — how wallets and apps establish sessions and exchange signing requests. - **Passkeys / WebAuthn material** — origin-bound credentials, authenticators, recovery; increasingly the substrate under embedded wallets. - For the product-side view: [[Wallet Infrastructure Roles (Privy)]]. --- Next: the wallet broadcast a transaction and the app showed a checkmark. What machinery stands between the chain and that checkmark — and when does it lie? → [[08 Nodes, RPCs, and Indexers]]