# Wallet Infrastructure Roles (Privy) What does it actually mean to be dangerous at the boundary between protocols and product? That's the real job at a Privy- or Stripe-adjacent wallet-infrastructure company — not protocol research, but fluency in what the protocol guarantees paired with judgment about what the product may safely hide. This note collects everything in the vault that points at that boundary. ## The five things to know cold ### 1. Wallet onboarding The product problem, stated honestly: give a person a wallet without requiring them to learn what a wallet is. - Embedded wallets - Passkeys / WebAuthn - Email, SMS, and social auth - Account linking - Key recovery - Session keys - Device migration The foundation is [[07 Wallets and Account Abstraction]]. The tension worth holding: every convenience on that list moves key material or signing authority *somewhere*, and that somewhere joins the [[Trust Assumptions|trust model]]. The craft is knowing which moves are sound engineering and which are a custodian wearing a costume — and being able to explain the difference to a customer. ### 2. Transaction lifecycle From click to [[Finality]]: ```text User action -> app constructs transaction -> wallet signs -> transaction broadcast -> mempool/RPC -> block inclusion -> confirmations/finality -> indexer observes -> app updates UI ``` Know where each arrow fails, and what the user should see when it does — the full treatment is in [[06 Transaction Lifecycle and MEV]]. A useful heuristic: support tickets are written by the arrows. ### 3. Account abstraction ERC-4337 is why wallets can behave like modern app accounts: programmable validation, sponsored gas, session keys, recovery. Know smart accounts, bundlers, paymasters, and UserOperations — the mechanics are in [[07 Wallets and Account Abstraction]], and the hands-on version is Project 4 in [[Projects to Build]]. The strategic view worth carrying into interviews: account abstraction is the bridge from crypto wallets to normal consumer accounts, and companies in this space are betting the bridge holds. ### 4. Rollups and L2 UX Users don't want to know which chain they're on, how gas works, which bridge to use, or why funds are delayed — and yet the system must handle every one of those facts on their behalf. Know sequencer confirmations, L1 settlement, withdrawal delays, [[Data Availability]], bridges, and chain abstraction: [[09 Scaling - Rollups and Data Availability]] and [[10 Bridges and Interoperability]]. The product skill hiding in there: choosing which finality stage each feature waits for, and never showing a checkmark the settlement layer wouldn't endorse. ### 5. Security UX A wallet product's core duty is preventing catastrophic mistakes by people who can't evaluate what they're signing: - Malicious signatures and approval drains - Transaction simulation and human-readable signing - Domain binding, replay protection - Phishing resistance - Recovery flows Foundations in [[07 Wallets and Account Abstraction]] and [[12 Security and Incentive Design]]. The slightly uncomfortable summary: the user's mental model is part of the attack surface, and the product is the only layer positioned to defend it. ## Reading Privy's docs like a staff engineer Read the product documentation end to end — not casually, but the way you'd review an API design. Look for: - The auth model and session handling - Wallet creation and embedded-wallet key architecture - Account linking - Signing APIs and their error model - SDK ergonomics - Recovery assumptions And keep a running list of questions as you go: ```text What is the state machine? What does the SDK hide? What must remain explicit? Where are the security boundaries? Where could a developer misuse this? What would I improve? ``` Do the same pass over WalletConnect (the wallet-app session protocol) and WebAuthn (the credential layer under passkeys). ## The interview questions that matter For any wallet product, be ready to answer: ```text Where are keys created? Where are keys stored? How are keys recovered? What can the app sign without the user? What can the user actually understand? What happens if a device is lost? What happens if the backend is compromised? What happens if the frontend is compromised? What happens if the RPC lies? ``` Notice something pleasing: these are the vault's eight questions from [[Blockchain Home]], specialized to wallets. That's not a coincidence — it's the method, and it works on any product in this space. ## The portfolio piece One polished demo outweighs many toy repos: an embedded wallet playground. Features: - Next.js + TypeScript - Login/auth flow - Embedded wallet or wallet-connect flow - Transaction signing with simulation and human-readable preview - Approval warnings - Event indexer into Postgres - Reorg-safe confirmation model - A small dashboard showing the transaction lifecycle end to end And the part that does the arguing for you — a written architecture doc: ```text 1. Product goal 2. User state machine 3. Wallet/key assumptions 4. Transaction lifecycle 5. Failure modes 6. Security boundaries 7. Data model 8. Observability 9. API design 10. Future account-abstraction path ``` The doc matters as much as the code, because it demonstrates the thing the role actually requires: knowing what the protocol guarantees, what the product hides, and where the boundary between them safely sits. --- Back to [[Blockchain Home]] · Build the pieces first: [[Projects to Build]]