Skip to main content

Introduction to Account Abstraction

Account Abstraction (AA) transforms how users interact with blockchain applications by replacing traditional Externally Owned Accounts (EOAs) with programmable smart accounts. This enables developers to create seamless user experiences with gasless transactions, social recovery, session-based interactions, and flexible authentication.

What You Can Build​

The SCS Account Abstraction toolkit enables you to implement three core patterns that dramatically improve user experience:

Contract Interactions​

Execute smart contract calls with sponsored gas or ERC-20 token payments, eliminating the need for users to hold native tokens. Users can interact with your dApp without worrying about gas fees or token management.

Social Recovery​

Implement secure account recovery using trusted guardians, allowing users to regain access to their accounts without seed phrases. This provides enterprise-grade security with user-friendly recovery options.

Smart Sessions​

Create session-based interactions that reduce signature friction, enabling users to interact with your dApp seamlessly without repeated wallet approvals. Perfect for gaming, trading, or any high-frequency interaction patterns.

Key Benefits​

  • Simplified Onboarding: Users can interact without holding native tokens
  • Enhanced Security: Social recovery and modular security features
  • Better UX: Session management reduces transaction friction
  • Modular Design: Pick and choose AA features for your use case
  • Production Ready: Built on battle-tested ERC-4337 infrastructure

SCS Account Abstraction Infrastructure​

SCS provides a set of infrastructure dedicated to ERC-4337 Account Abstraction (AA), designed to simplify smart account development and enable seamless AA integration into your applications. It allows developers to focus on building applications and enhancing UX — without managing the underlying infrastructure.

The SCS AA tech stack includes:

  • Bundler RPC API (compliant with ERC-4337 specification)
  • Paymaster API
  • Essential on-chain contracts: Paymaster, Smart Accounts, and ERC-7579 Modules

Developers can leverage flexible gas payment options, such as:

  • Sponsored transactions (no native token needed for users)
  • ERC-20 token-based gas fees

Integrating smart accounts into your dApps unlocks:

  • Social logins for easier onboarding
  • Session modules to avoid repeated wallet signature popups
  • Many more modular extensions

These features are explained in detail in later sections.

Bundler API​

The Bundler is a core component of the ERC-4337 AA infrastructure. It operates a dedicated mempool for UserOperations (UOs), which are the primary execution units for smart accounts.

Instead of sending standard transactions to the blockchain, wallets submit UserOperations to the Bundler via its API. The Bundler:

  1. Validates the UO
  2. Simulates it
  3. Packages it into a transaction
  4. Submits it to the EntryPoint contract

This design enables account abstraction without changing the consensus layer on any EVM-compatible chain.

What are UserOperations (UOs)?​

A UserOperation is a data structure defined in ERC-4337 that contains everything needed to execute an action on behalf of a smart account.

Unlike EOAs that sign and send native transactions, smart accounts rely on UOs submitted to the Bundler, which then routes them to the EntryPoint.

Benefits include:

  • Custom signature validation
  • Gas sponsorship
  • Batched execution
  • Native support for smart wallets

Think of UOs as pseudo-transactions, purpose-built for account abstraction.

Paymasters​

Paymasters are on-chain contracts that unlock flexible gas fee payments.

In EOAs, users need to own native tokens (e.g., ETH) to pay gas. This creates onboarding friction.

Paymasters solve this by:

  • Sponsoring gas fees (dApp pays for user)
  • Accepting ERC-20 tokens as gas (Paymaster converts to ETH under the hood)

This improves onboarding, enabling gasless transactions or alternative token payments.

Paymaster API​

The Paymaster API delivers off-chain paymaster data that’s needed for on-chain validation.

To use SCS Paymasters for sponsorship or token-based gas payments:

  1. Request paymaster data via the API
  2. Attach the returned data in your UserOperation
  3. Submit the UserOperation to the Bundler
  4. The Paymaster contract verifies the UO on-chain

Only validated UOs (with correct off-chain paymaster data) are eligible for sponsorship or token-based payment.

Supported Networks​

See full list of supported networks here.