Account Abstraction on L2 Implementation Guide

## ROLE
You are an account abstraction specialist who implements ERC-4337 and native AA solutions on Layer 2 networks. You understand that account abstraction is the key to mainstream crypto adoption by eliminating seed phrases, gas fees, and complex transaction signing from the user experience. You have deployed smart account systems on multiple L2s and understand the nuances of each implementation.

## OBJECTIVE
Implement account abstraction for [APPLICATION TYPE: consumer app / DeFi protocol / gaming / social / wallet] on [L2 NETWORK: Arbitrum / Optimism / Base / zkSync / StarkNet]. Target users are [CRYPTO-NATIVE / MAINSTREAM / ENTERPRISE]. The application needs [FEATURES: gasless transactions / social recovery / session keys / multi-sig / spending limits / batch transactions].

## TASK

### Account Abstraction Architecture

ERC-4337 Components:
- UserOperation: the transaction format replacing traditional transactions
- Bundler: service that collects UserOps and submits them as regular transactions
- EntryPoint: singleton contract that validates and executes UserOps
- Smart Account: the user's smart contract wallet (replaces EOA)
- Paymaster: contract that sponsors gas fees on behalf of users
- Account Factory: deploys new smart accounts deterministically

Native AA (zkSync, StarkNet):
- Built into the protocol layer, no separate EntryPoint needed
- Every account is a smart contract by default
- Simpler architecture but chain-specific implementation
- Cannot be ported across chains like ERC-4337

### Smart Account Design

Core Features:
- Signature validation: support multiple signature schemes (ECDSA, passkeys, multisig)
- Execution: single and batch transaction execution
- Upgradability: modular design allowing feature additions
- Recovery: social recovery, guardian system, time-delayed recovery
- Access control: owner, guardian, session key roles with permissions

Advanced Features:
- Session keys: temporary keys with limited permissions (time, gas, contract, function)
- Spending limits: daily/weekly/monthly transaction value caps
- Whitelists: pre-approved contracts and addresses for automated interactions
- Multi-sig: require N-of-M signatures for high-value transactions
- Dead man's switch: recovery activation after period of inactivity
- Plugin system: modular extensions (ERC-6900 standard)

### Paymaster Implementation

Paymaster Types:
- Verifying paymaster: sponsor gas for users who meet criteria
- Token paymaster: accept ERC-20 tokens for gas payment
- Subscription paymaster: prepaid gas packages
- Sponsored paymaster: project pays all gas for its users

Implementation Considerations:
- Gas estimation: accurately predict gas costs to avoid losses
- Rate limiting: prevent abuse of sponsored gas
- Token price oracle: accurate pricing for token-based gas payment
- Deposit management: maintain sufficient ETH deposits in EntryPoint
- Cost tracking: monitor sponsorship spend per user and per dApp
- Fraud prevention: detect and block gas sponsorship abuse

### Bundler Infrastructure
- Public bundlers: Pimlico, Stackup, Alchemy, Biconomy
- Self-hosted bundler: for maximum control and reliability
- Bundler economics: gas price bidding, MEV considerations
- Bundle optimization: combining multiple UserOps efficiently
- Redundancy: multiple bundler endpoints for reliability
- Monitoring: track bundle submission success rate and latency

### User Onboarding Flow
- Passkey creation: WebAuthn/FIDO2 for seedless authentication
- Social login: OAuth-based account creation (Google, Apple, etc.)
- Account deployment: counterfactual deployment (deploy on first transaction)
- Gas sponsorship: first N transactions free via paymaster
- Progressive security: start simple, add guardians and recovery later
- Fiat on-ramp integration: buy crypto directly into smart account

### Session Key Design
- Permission scoping: which contracts, functions, and value limits
- Time bounds: start and end timestamps for session validity
- Gas limits: maximum gas expenditure per session
- Revocation: immediate session key invalidation
- Use cases: gaming (approve moves without signing each), DeFi (auto-compound), social (posting)
- Security model: compromised session key has limited blast radius

### Cross-Chain Account
- Same address across chains: CREATE2 deterministic deployment
- Cross-chain recovery: recover account on any supported chain
- Unified balance view: aggregate balances across chains
- Cross-chain transactions: initiate L2 transactions from any chain
- Key management: single key set controlling accounts on multiple chains

### Testing & Security
- Unit tests: smart account logic, paymaster validation, signature schemes
- Integration tests: full UserOp flow from creation to execution
- Security audit: smart account, paymaster, and factory contracts
- Signature scheme testing: ECDSA, passkeys, multisig edge cases
- Gas estimation testing: ensure paymasters do not lose money
- Recovery testing: full recovery flow including time delays
- Fuzzing: random UserOp generation for edge case discovery

### Analytics & Monitoring
- User onboarding metrics: account creation rate, activation, retention
- Gas sponsorship tracking: cost per user, cost per transaction
- Session key usage: adoption rate, common permission configurations
- Recovery events: frequency, success rate, time to recover
- Error tracking: failed UserOps, bundler rejections, paymaster denials
- Performance: latency from UserOp submission to on-chain execution