Implementing ERC-4337 Account Abstraction in Mobile Wallets

We implement ERC-4337 in mobile crypto wallets to remove barriers of seed phrases and mandatory ETH for gas. The ERC-4337 standard (described in EIP-4337) replaces EOA with smart contract wallets. The user gains gasless transactions, social recovery, and biometric signing—without storing a seed phrase. For developers, integration involves working with UserOperation, Bundler, and Paymaster. The result is a Web2-level UX: users log in with Face ID, and transactions are free for them. Contact us to discuss your project.

Traditional EOA wallets require managing private keys and having ETH for gas. This creates a barrier to mass DeFi adoption. ERC-4337 solves this through smart accounts that can sponsor gas and be recovered without a seed phrase. The mobile app becomes just a client that signs operations with biometrics.

Which ERC-4337 components are used in a mobile wallet?

Smart Account

Instead of an EOA, the user gets a smart contract wallet (SimpleAccount, SafeAccount, LightAccount by Alchemy, Kernel by ZeroDev). The contract address is deterministic via CREATE2—it can be computed before deployment. The mobile client stores the ownerPrivateKey (signer key) in Secure Enclave (iOS) / Android Keystore, not the wallet itself.

EntryPoint Contract

(0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789—same address on all EVM networks)—a global singleton that accepts UserOperation[] from Bundlers.

Bundler

A node that collects UserOperations from the mempool, simulates them, and packs them into a regular on-chain transaction. SDKs to use: @alchemy/aa-core, permissionless.js, viem/account-abstraction. In the mobile app, the Bundler is an HTTP endpoint where the client sends eth_sendUserOperation. Alchemy's bundler processes operations 2x faster than the public mempool.

Paymaster

An optional contract that sponsors gas. Verifying Paymaster signs a permission on the server; ERC-20 Paymaster allows payment in USDC. In the mobile client, before sending a UserOperation, we request pm_sponsorUserOperation from the Paymaster API (Alchemy, Pimlico, Biconomy). Gas savings for the user can reach 90%.

How does ERC-4337 change mobile wallet UX?

Signing UserOperation. The smart account verifies the signature via isValidSignature (ERC-1271). The owner (owner EOA) signs. On iOS—SecKeyCreateSignature with kSecKeyAlgorithmECDSASignatureMessageX962SHA256 via Secure Enclave (key never leaves the chip). On Android—KeyPairGenerator with AndroidKeyStore provider, signature via Signature.getInstance("SHA256withECDSA").

Biometric authentication before signing—LocalAuthentication (iOS) / BiometricPrompt (Android). The private key is only accessible after biometric verification—the key is marked with kSecAccessControlBiometryCurrentSet (iOS) or setUserAuthenticationRequired(true) (Android Keystore).

Session Keys. ERC-4337 allows delegating limited signing rights. Example: a mobile game requests a session key with permission to spend up to 5 USDC per transaction—the user signs once, subsequent micro-transactions proceed without confirmation. Implementation via ISessionKeyPlugin (ERC-6900) or analogous in Kernel (ZeroDev).

Social Recovery. The smart account can support recovery through guardians—trusted addresses (e.g., email-recovery via ZeroDev Email Recovery or phone via social login through Web3Auth). The user loses their key → contacts guardians → after a timelock (usually 48 h) gets a new owner. For mobile UX: in the app—a "Recovery" section where guardians can be added and threshold configured.

Case Study: DeFi mobile wallet (our client)

Smart Account based on LightAccount v1.1, Bundler—Alchemy, Paymaster sponsors first 10 transactions for new users. Signing via Secure Enclave (iOS) and Android Keystore. Onboarding without a seed phrase: user creates an account via Apple Sign In → ECDSA keypair generated in Secure Enclave → smart account address computed via getCounterFactualAddress → on first deposit, account is deployed via initCode in UserOperation. The user never sees a private key or seed phrase. Smart Account reduces user confirmations by 3x compared to EOA wallets.

What challenges arise when implementing ERC-4337?

Frontrunning UserOperations. The ERC-4337 mempool is public—Bundlers see unconfirmed UserOperations. For confidential operations, use a private bundler (Flashbots, MEV Blocker) or a Paymaster with encrypted data.

Multi-chain. EntryPoint v0.6 and v0.7 have different addresses on different networks. The wallet must support both. SmartAccountClient from @alchemy/aa-core abstracts this, but configuration per network is separate.

Gas estimation on Optimism/Base. The L2 gas model differs: the L1 data fee is added to L2 gas. eth_estimateUserOperationGas from the Bundler accounts for this, but verification on different networks separately is recommended.

What stages does ERC-4337 wallet development involve?

Timelines and Costs

Cost is calculated individually after analyzing smart contract requirements, supported networks, and onboarding UX flow.

We have 10+ years of experience in mobile development and 50+ completed projects integrating blockchain technologies. Get a consultation on implementing ERC-4337 in your mobile app—contact us to discuss the project and create a RoadMap.

Mobile App Architecture

The app is built in a single ViewController with 2000 lines. Network calls, business logic, UI updates—all in one place. Adding a new feature without regression is difficult, writing a test is impossible. This isn’t “bad code”—it’s a lack of architecture. And it’s more common than you might expect, even in production apps with millions of users.

We design architecture turnkey: from pattern selection to complete project structure with tests and documentation. In 7–10 days you get clean, modular code ready for scaling.

Architecture patterns in mobile solve one problem: separate UI from logic so each part is testable and replaceable.

MVVM: Basic Pattern

Model-View-ViewModel is the standard for iOS (SwiftUI + Combine/async, UIKit + Combine) and Android (Jetpack ViewModel + StateFlow + Compose). The ViewModel holds UI state and business logic. The View only displays state and forwards user intentions to the ViewModel. The Model represents data and its source.

Key rule: ViewModel knows nothing about UIKit or Android View classes. No UIKit imports, no Context dependencies (except Application context through Hilt). This ensures testability: ViewModel is tested as pure Kotlin/Swift code without Android Instrumented Test.

MVVM covers 70% of needs. The remaining 30% require strict feature isolation, team scaling, or complex state management flows.

Clean Architecture: When MVVM Isn’t Enough

Adds layers on top of MVVM:

• Domain layer — business logic, platform-independent. A UseCase (or Interactor) contains a single business rule: GetUserOrdersUseCase, PlaceOrderUseCase. Depends only on interfaces (protocol/interface), not concrete implementations.
• Data layer — repository implementations. OrderRepositoryImpl implements OrderRepository from domain. Knows about Retrofit, Room, UserDefaults. The ViewModel doesn’t know where data comes from—network or cache.
• Presentation layer — ViewModel + View. Knows about Domain, not Data.

Dependency rule: dependencies point inward only. Domain depends on nothing. Data and Presentation depend on Domain.

Presentation → Domain ← Data

This allows swapping implementations: tests use an in-memory repository instead of network, the interface remains the same.

Practical caveat: Clean Architecture adds files and layers. For small apps, this is overhead. It’s justified starting from ~15 features and teams of 3+ developers.

BLoC for Flutter: Predictable State Flow

BLoC (Business Logic Component) is the standard pattern in the Flutter community. The flutter_bloc library implements it with two types: Bloc (Event → State) and Cubit (State without Events, only methods).

Bloc processes Event and emits a new State via on<EventType> handlers. State is immutable—a new object for each change. BlocBuilder re-renders only the part of the tree where state changed.

// Event
abstract class CartEvent {}
class AddItemToCart extends CartEvent {
  final String productId;
  AddItemToCart(this.productId);
}

// State
abstract class CartState {}
class CartLoaded extends CartState {
  final List<CartItem> items;
  CartLoaded(this.items);
}

// Bloc
class CartBloc extends Bloc<CartEvent, CartState> {
  CartBloc(this._cartRepository) : super(CartLoaded([])) {
    on<AddItemToCart>(_onAddItem);
  }

  Future<void> _onAddItem(AddItemToCart event, Emitter<CartState> emit) async {
    final current = state as CartLoaded;
    final updated = await _cartRepository.addItem(event.productId);
    emit(CartLoaded(updated));
  }
}

The advantage of BLoC is testability. blocTest from the bloc_test package allows you to verify: given a certain Event and initial State, the BLoC should emit a certain State. No UI, no mocks for the Flutter framework.

VIPER: For Large iOS Projects

VIPER (View, Interactor, Presenter, Entity, Router) is the strictest separation of responsibilities for iOS. Each component has a protocol and concrete implementation.

• View — UI only, delegates everything to Presenter
• Interactor — business logic, network and data operations
• Presenter — mediator between View and Interactor, formats data for View
• Entity — data models (pure structures)
• Router — navigation between modules

Each module (screen or feature) is a separate VIPER module. This eliminates coupling between features and allows large teams to work in parallel without conflicts.

The cost: many files, many protocols. Boilerplate is generated via Sourcery or custom Xcode templates. VIPER is justified for apps with 10+ developers and 50+ screens.

TCA (The Composable Architecture)

TCA by Point-Free is a more modern alternative to VIPER for iOS/macOS. Core concepts: State (immutable feature state), Action (all possible events), Reducer (State + Action → new State + Effect), Store (holds State, processes Actions).

Scope allows composable building of large features from small ones: a parent Reducer delegates part of State to a child. Each feature is tested in isolation via TestStore with precise control over Effects.

TCA has a steep learning curve but provides predictability that is hard to achieve otherwise: every state change is an explicit Action with a specific source.

Which Pattern to Choose for Your Project?

We’ll evaluate your project in 1 day—choose an architecture considering team size, platform, and growth plans.

There is no universal answer. Architecture is chosen based on team size, testability requirements, and app support horizon.

What Components Are Included in Our Architecture Work?

• Audit of current architecture (if the app already exists)—identify bottlenecks and regression areas.
• Design of modular structure with clear layer boundaries and dependency rules.
• Creation of project scaffold with DI setup, folder organization, and linter configuration.
• Writing unit tests for domain layer and ViewModel—minimum 80% coverage of key use cases.
• Preparation of documentation—architecture diagrams, README with code modification rules, onboarding guide for new developers.
• Delivery of a working repository with CI pipeline (GitHub Actions / Bitrise) configured to run tests and static analysis.

All this is included in the design cost. Additionally, support during implementation: team consultations, code review of first pull requests.

How Does Lack of Architecture Affect Development Speed?

Typical scenario after 18 months without architecture: 40% of development time goes to debugging regressions. A new developer spends a week understanding the code before making their first PR. Tests aren’t written “because it’s hard to mock.” Adding a new feature requires understanding half the codebase.

Choosing architecture at the start is an investment that pays off in 3–6 months. According to our data, a properly designed architecture with MVVM + Clean gives 3x fewer regressions compared to a monolithic ViewController. And the cost of implementation is recouped in 2–3 sprints.

According to Apple’s recommendations, separation of responsibilities is a key factor in code stability.

Why Trust Our Team with Architecture?

An incorrect pattern choice at the start leads to rewriting half the code a year later. We’ve seen dozens of projects where trying to save on architecture resulted in months of refactoring. With over 10 years of commercial development experience and work on apps from 1 to 50 developers, we help avoid common mistakes:

• Overengineering for a simple MVP (we assign MVVM, not VIPER).
• Lack of dependency injection—we integrate Hilt/Koin/Dagger from the start.
• Ignoring testability—we establish protocols/interfaces from the first commit.

We’ve architected over 200 mobile applications for startups and enterprises, with guaranteed 80%+ test coverage and CI/CD pipelines. Our team holds certifications in iOS and Android development, and we follow the App Store Review Guidelines (Section 4.2/5.1) to ensure smooth store approvals.

Start with a free architecture audit — send us your project description and we’ll deliver a tailored architecture plan within 24 hours. Reach out via Telegram or email to get started.