Build wallets that users don't need to understand to use.

Every user who abandons Web3 onboarding at "write down your 12-word seed phrase" is a user account abstraction could have kept.

The two biggest barriers to mainstream Web3 adoption are: (1) seed phrases — users must write down 12-24 words and never lose them or their funds are permanently gone, and (2) gas tokens — users must hold ETH or the native token to pay transaction fees before they can do anything. ERC-4337 account abstraction solves both. Smart contract wallets can implement social recovery (trusted contacts can help recover access) or email/passkey login without a seed phrase. Paymasters can sponsor gas fees so users transact without holding ETH. Session keys allow games and dApps to batch in-app actions without requiring a wallet signature for every interaction. These are not incremental UX improvements — they are the foundation of consumer Web3 adoption.

The ERC-4337 stack.

System Layers

• Smart Wallet Layer: Account contract (EntryPoint interface), validation logic, execution logic, upgrade mechanism
• Bundler Layer: UserOperation mempool, gas estimation, bundle submission, MEV protection
• Paymaster Layer: Gas sponsorship, ERC-20 gas payment, voucher/quota systems
• Recovery Layer: Social recovery, guardian management, time-locked recovery, passkey support
• Session Key Layer: Limited-permission session keys, expiry, dApp-specific permissions

Core Technical Capabilities

• Smart Contract Wallet

  ERC-4337 compliant account contract with custom validation (passkey, multi-sig, ECDSA), arbitrary execution logic, upgrade via UUPS proxy and EntryPoint integration.

• Paymaster Engineering

  Verifying paymaster (sponsor specific UserOps), token paymaster (accept ERC-20 for gas), deposit paymaster (deduct from user balance). Paymaster deposit management and monitoring.

• Session Keys

  Limited-permission session keys that allow dApps or games to execute specific actions (e.g., "spend up to 10 USDC on in-game items") without requiring a wallet signature for each action. Expiry, scope limiting and revocation.

• Social Recovery

  Guardian-based social recovery — trusted contacts (other wallets) can vote to replace the signing key after a time delay. Guardian management UI, recovery initiation flow and time-lock protection against malicious recovery.

• Bundler Integration

  Integration with Pimlico, Alchemy Bundler or Stackup for UserOperation submission. Gas estimation for UserOps (preVerificationGas, verificationGasLimit, callGasLimit). Fallback bundler configuration.

• Passkey & WebAuthn

  Passkey-based wallet authentication — use Face ID, Touch ID or hardware security key as the wallet signing key. P256 signature verification in contract via RIP-7212 precompile or via FreshCryptoLib.

How we think about account abstraction.

ERC-4337 is not just a wallet improvement. It is a new smart contract execution model that enables business logic in the wallet layer itself.

• The UX problem is the adoption problem

  Every successful consumer Web3 application will need to abstract the blockchain complexity from users. "You need MetaMask and 0.01 ETH to continue" is not acceptable for mainstream products. Account abstraction via ERC-4337 is the technical foundation — passkey login, gas sponsorship, session keys — that makes Web3 UX competitive with Web2.

  Axiom:

• Paymasters change the monetisation model

  With paymasters, the dApp can sponsor gas for users and recover the cost via: in-app subscription, transaction fee percentage, token staking requirement or direct subsidy during onboarding. This allows "gasless" UX while the gas cost is still paid — just by the application, not the user.

  Axiom:

• Session keys change the dApp interaction model

  Every Web3 game that requires a MetaMask popup for every in-game action has failed UX. Session keys allow the game to receive a limited, time-scoped permission from the wallet: "this session key can spend up to 10 USDC on in-game items for the next 24 hours." The game signs transactions with the session key without further user confirmation.

  Axiom:

• EntryPoint is the security boundary

  The ERC-4337 EntryPoint contract is a singleton that all smart wallets interact with. It enforces the UserOperation lifecycle — validation, execution, paymaster verification. The EntryPoint is audited by OpenZeppelin and widely deployed. Custom validation logic in smart wallets must be designed carefully to not introduce vulnerabilities that the EntryPoint cannot protect against.

  Axiom:

Account abstraction architecture decisions.

• Build custom smart wallet vs use Safe/ZeroDev?

  Impact: ZeroDev Kernel for most applications — lightweight, session keys, well-audited, active development. Safe for institutional or multi-sig requirements. Custom only if specific validation logic cannot be implemented as a module.

  • Safe (Gnosis Safe) — battle-tested, most audited, large ecosystem, module system
  • ZeroDev (Kernel) — lightweight, session keys built-in, ERC-4337 optimised
  • Biconomy Smart Account — developer-friendly, modular, hosted infrastructure
  • Custom from scratch — maximum control, full audit responsibility

• Bundler provider?

  Impact: Pimlico for most applications — good documentation, paymaster service, reasonable pricing. Alchemy if already on Alchemy RPC. Self-hosted only for applications with very high UserOp volume where bundler fees are significant.

  • Pimlico — comprehensive, good documentation, paymaster service bundled
  • Alchemy Bundler — integrated with Alchemy RPC, simple setup
  • Stackup — open-source compatible, self-hostable
  • Self-hosted bundler — full control, significant operational burden

• Gas sponsorship strategy?

  Impact: Tiered: full sponsorship for first transaction (critical for conversion), partial sponsorship for active users, ERC-20 gas payment for power users who hold your token.

  • Full sponsorship — sponsor all gas, maximum UX, highest cost
  • New user onboarding only — sponsor first N transactions
  • Staking-based — sponsor gas for users who stake tokens
  • ERC-20 payment — users pay gas in your token, not ETH

• Recovery mechanism?

  Impact: Passkey + social recovery combination: passkey as primary (biometric, familiar UX), social recovery as backup (email contacts as guardians). Neither alone is sufficient for mainstream consumer wallets.

  • Social recovery (guardians) — trusted humans can recover access
  • Passkey backup — biometric secondary key backed up to iCloud/Google
  • Multi-device — key sharded across user's devices
  • No recovery — user's responsibility, not acceptable for mainstream

• Which chains?

  Impact: Base for new consumer applications — Coinbase distribution, low gas, growing ecosystem, ERC-4337 natively supported. Arbitrum for DeFi. Multi-chain via same contract address deployment if users need assets on multiple chains.

  • Ethereum mainnet — most credibility, highest gas even with 4337
  • Arbitrum/Optimism/Base — EVM, low gas, ERC-4337 supported
  • Polygon — established, low gas, 4337 supported
  • Multi-chain — same wallet on all EVM chains

• Login method?

  Impact: Passkey for new applications — truly non-custodial, biometric UX, backed up by platform (iCloud Keychain, Google Password Manager), no server key custody.

  • Email + OTP (managed key) — familiar but custodial server key generation
  • Passkey (WebAuthn) — biometric, non-custodial, iCloud/Google backed up
  • Social login (Google/Apple OAuth) — familiar, third-party dependency
  • Traditional EOA seed phrase — eliminates the UX improvement purpose of 4337

What PROPELOO builds with account abstraction.

• Consumer Web3 App

  dApp with passkey login, gasless onboarding (sponsored first transactions), session keys for in-app actions and social recovery.

• Web3 Game

  Mobile game where users sign in with Face ID, session keys allow in-game asset usage without per-action confirmations, and gas is sponsored by the game studio.

• DeFi Frontend

  DeFi protocol frontend with smart wallet for batched operations (approve + swap in one UserOp), ERC-20 gas payment in the protocol token and per-dApp session keys.

• White-label Wallet SDK

  Embeddable wallet SDK for apps — ERC-4337 smart wallet, email or passkey login, gas sponsorship configuration, React Native + web components.

• Enterprise Web3 App

  Corporate multi-sig smart wallet with role-based signing policies, spending limits, audit trail and hardware key support for high-value transactions.

• NFT Platform

  NFT marketplace where users log in with email, minting is gasless (creator pays via paymaster), and transfers require only biometric confirmation.

The ERC-4337 stack.

• Smart Wallets

  Stack: ZeroDev Kernel, Safe{Core}, Biconomy Smart Account, Custom ERC-4337 contract

• Bundlers

  Stack: Pimlico, Alchemy Bundler, Stackup, Alto (open-source)

• Paymasters

  Stack: Pimlico Paymaster, Alchemy Gas Manager, Custom verifying paymaster

• Frontend SDKs

  Stack: permissionless.js, ZeroDev SDK, Biconomy SDK, wagmi + viem (ERC-4337 actions)

• Auth

  Stack: Passkey (WebAuthn), Dynamic.xyz, Privy, Magic.link

• Chains

  Stack: Base, Arbitrum, Optimism, Polygon, Ethereum mainnet

Smart wallet security is a superset of EOA security.

• Validation logic vulnerabilities

  Custom validation logic in smart wallets (signature validation, access control) is a new attack surface. Every validation bypass allows transaction execution without owner authorization. Validation logic must be audited independently from the account contract.

• Paymaster manipulation

  Malicious UserOps can attempt to drain paymaster deposits by crafting operations that pass validation but consume maximum gas. Paymaster contracts must validate UserOp calldata and implement per-user/per-day spending limits.

• Session key scope

  Session keys with overly broad permissions are essentially separate full-access keys. Session keys must have minimal scope: specific contract addresses, specific function selectors, maximum token amounts, expiry time.

• Social recovery attacks

  Social recovery with insufficient guardian requirements is a social engineering attack surface. Minimum 2-of-3 guardian requirement, time delay between recovery initiation and execution (48-72 hours minimum), and guardian revocation capability.

• Bundler trust

  Bundlers submit UserOperations on behalf of users. A malicious bundler could censor UserOps or frontrun them. Bundler selection matters for applications where liveness is critical. Consider self-hosted bundler for high-value applications.

• Upgrade mechanism

  Upgradeable smart wallets (UUPS or beacon proxy) have upgrade functions that must be strictly access-controlled. An exploited upgrade function can replace the wallet logic with a malicious implementation that redirects all funds.

From traditional wallet to account abstraction.

1. 01. Architecture Design

   Smart wallet selection, bundler provider, paymaster strategy, recovery mechanism and login method.

2. 02. Smart Wallet Setup

   Account contract deployment (or SDK integration), EntryPoint integration, factory contract.

3. 03. Paymaster Integration

   Paymaster contract or managed paymaster service, sponsorship policy configuration, deposit monitoring.

4. 04. Auth Integration

   Passkey/email login, key generation, account deployment flow for new users.

5. 05. Session Keys

   Session key validation module, dApp permission configuration, expiry enforcement.

6. 06. Recovery

   Guardian contract, recovery initiation UI, time-lock verification.

7. 07. Testing & Launch

   Testnet end-to-end testing, gas estimation validation, security review, mainnet deployment.

Account Abstraction Engagements

ERC-4337 smart wallets and gasless transaction infrastructure built for production.

• ERC-4337 Consumer Wallet with Social Recovery

  Challenge: Consumer app needed Web2-level UX — no seed phrases, no gas management — while retaining self-custody.

  Architecture: ERC-4337 smart wallet with passkey (WebAuthn) as primary signer. Social recovery with 3-of-5 guardian scheme. Paymaster contract sponsoring gas for all user operations. Session keys for dApp interactions without per-transaction approval.

  Outcome: Onboarding time reduced to 90 seconds with no seed phrase exposure. User retention 40% higher than prior EOA wallet implementation. Paymaster costs offset by in-app revenue model.

• Enterprise Gasless Transaction Layer

  Challenge: B2B SaaS platform needed to abstract all gas costs from enterprise customers — 50,000 daily transactions across 200 business accounts.

  Architecture: Alto bundler with custom mempool prioritisation. Per-account paymaster with monthly budget enforcement via Redis counter. Emergency pause mechanism for paymaster spending anomalies. ERC-20 token support for alternative gas payment where needed.

  Outcome: Enterprise customers operate with zero ETH holdings. Gas sponsorship costs predictable within 5% of monthly budget. Zero failed transactions due to gas estimation errors.

• Institutional Multi-sig Treasury Wallet

  Challenge: DAO treasury with $50M assets needed multi-signature control with time-locks and hardware wallet integration.

  Architecture: Smart wallet requiring M-of-N hardware wallet signatures via ERC-4337 validation. 48-hour timelock for transfers above $100K. Role-based access for operational vs treasury transactions. On-chain governance integration for policy updates.

  Outcome: Treasury secured with zero single-point-of-failure. Timelock mechanism prevented two attempted social engineering attacks. All hardware wallet signers verified on-chain.

Frequently Asked Questions