Smart Accounts and Wallet UX

Introduction

Smart accounts replace one-key/one-nonce assumptions with programmable validation and execution. That can improve recovery and scoped authority, while adding modules, bundlers, paymasters, delegates, and wallet interfaces to the trust boundary.

Why It Matters

Users authorize what a wallet presents, not raw bytecode. A secure account must make scope, simulation, replay protection, fees, upgradeability, and recovery legible across both protocol and interface layers.

Mental Model

Separate authentication, authorization policy, execution, gas sponsorship, nonce domains, module lifecycle, and recovery. Each component can fail independently and must not silently widen another component's authority.

Questions This Branch Answers

What can a session key, module, guardian, or delegate actually do?
Which actors can censor or sponsor a UserOperation?
How does wallet UX communicate simulation and finality honestly?

Scope

EOAs versus smart accounts, ERC-4337, EIP-7702, ERC-1271, session keys, paymasters, passkeys, counterfactual deployment, nonces, recovery, and wallet UX.

Out of Scope

Custodial exchange architecture, biometric security claims, production key custody, universal wallet compatibility, and mainnet sponsorship infrastructure.

Dependencies

signatures and standards, call context, and the mutable Standards Registry.

Candidate Note Roadmap

eoa-smart-account-trust-boundary — Compare key, code, module, and recovery authority.
erc-4337-useroperation-flow — Trace validation, bundling, EntryPoint execution, and failure reporting.
eip-7702-delegation-model — Examine delegated code lifecycle and fork/client assumptions.
eip-1271-validation — Integrate contract signatures without assuming permanent validity.
session-keys-and-spending-limits — Constrain calls by target, selector, asset, amount, and time.
passkeys-paymasters-and-sponsorship — Separate authentication UX from gas and policy trust.
counterfactual-deployment-and-nonces — Bind addresses, initialization, deployment, and replay domains.
recovery-modules-and-wallet-ux — Design bounded recovery with explicit user-visible states.

Future Project

A Modular Smart Account with scoped session keys, pluggable signer validation, spending limits, deterministic deployment, bounded guardians, and a transparent operation preview.

Initial Invariants

No module exceeds its declared scope; nonces prevent replay in the correct domain; recovery cannot bypass policy; failed validation cannot execute; upgrades preserve account ownership and escape routes.

Initial Threat Model

Malicious modules, bundler censorship, paymaster griefing, compromised guardians, delegate escalation, nonce collision, phishing through calldata previews, inaccurate simulation, and irreversible recovery mistakes.

Primary Sources

ERC-4337, EIP-7702, ERC-1271, maintained account implementations, and wallet documentation indexed in SOURCES.md.

Connects to: authority and upgrades, intents, and clients/operations.