Skip to main content

Introduction

UI-SDK is the go-to approach for implementing Account Abstraction (AA) capabilities in Incentiv applications by providing a streamlined interface for communicating with ERC-4337 bundlers. It supports both EOA (Externally Owned Account) and Passkey-based authentication methods for creating AA wallets.

What is Account Abstraction?

Account Abstraction (ERC-4337) allows users to interact with smart contracts using smart contract wallets instead of Externally Owned Accounts (EOAs). This enables features like:
  • Multi-signature requirements
  • Account recovery mechanisms
  • Transaction batching
  • Gas abstraction (sponsored transactions)
  • Custom validation logic
  • Transaction authorization rules
  • Transaction whitelisting/blacklisting
  • Spending limits and quotas
  • Time-based transaction locks
  • Custom security policies
The Incentiv UI-SDK simplifies the implementation of these features by providing a high-level interface built on top of ERC-4337. It acts as a communication layer between your application and the bundler network, handling:
  • UserOperation creation and signing
  • Bundler interaction and submission
  • Gas estimation and optimization
  • Transaction status tracking
  • Account management
  • Signature validation

Browser Compatibility

For Passkey-based authentication:
  • Chrome/Edge: Version 67 or later
  • Safari: Version 14 or later
  • Firefox: Version 60 or later
  • Mobile: iOS 15+ (Safari), Android 7+ (Chrome)

Installation

Account Abstraction Providers

Configuration

Before creating any Account Abstraction provider, you need to configure the SDK with the following required parameters:

Configuration Parameters

  • entryPointAddress: The address of the ERC-4337 EntryPoint contract that handles UserOperations
  • bundlerUrl: The HTTP endpoint of the bundler service that processes and submits UserOperations
  • factoryAddress: The address of the factory contract that creates smart contract accounts

Creating an EOA-based Account Abstraction Provider

An EOA (Externally Owned Account) provider wraps existing wallet providers like MetaMask, WalletConnect, or any other Ethereum wallet to work with Account Abstraction. This allows users to leverage their existing wallets while gaining the benefits of smart contract accounts. The EOA provider:
  • Uses your existing wallet’s signing capabilities
  • Converts regular transactions into UserOperations
  • Handles gas estimation and payment through the smart contract account
  • Maintains compatibility with existing wallet interfaces

Creating a Passkey-based Account Abstraction Provider

A passkey provider enables passwordless authentication using WebAuthn (passkeys). This approach eliminates the need for traditional wallets and provides a more secure, user-friendly experience. The passkey provider:
  • Uses biometric authentication (fingerprint, face recognition, or PIN)
  • Stores cryptographic keys securely in the device’s hardware
  • Provides cross-platform compatibility
  • Enables seamless user experience without browser extensions

WebAuthnCredential Type

The WebAuthnCredential object contains the passkey information needed to create a provider:

Creating a Passkey Account

The passkey account creation process involves registration, server communication, and subsequent authentication. Here’s the complete flow:

Authentication Flow Summary

Registration

  • Call registerPasskey() with challenge from server
  • Extract credentialId and create WebAuthnPublicKey from attestation object
  • Send attestation data to server for verification and storage
  • Sign login challenge using signPasskeyLoginChallenge()
  • Send signature to server for verification
  • Retrieve public key and credential ID from server
  • Create WebAuthnCredential object and initialize provider
  • Use the created provider for all Account Abstraction operations
  • The provider handles WebAuthn signing automatically for transactions
This approach provides a seamless, secure authentication experience while maintaining the full capabilities of Account Abstraction. Let us code these steps:
1

Step 1: Register the Passkey

2

Step 2: Complete Registration Flow

The typical passkey registration and authentication flow works as follows:
3

Step 3: Login with Passkey

Complete Example Usage

Transaction Operations

Single Transactions

The UI-SDK allows sending transactions through Account Abstraction, which means transactions are executed by a smart contract wallet rather than an EOA. Key features of AA transactions:
  • Gas is paid by the smart contract wallet
  • Multiple operations can be batched
  • Custom validation logic can be implemented
  • Transactions can be sponsored by paymasters

Batch Transactions

Batch transactions are a powerful feature of Account Abstraction that allows multiple operations to be executed in a single transaction. This can significantly reduce gas costs and improve UX. Benefits of batch transactions:
  • Atomic execution (all operations succeed or all fail)
  • Reduced gas costs compared to individual transactions
  • Better UX with single signature for multiple operations
  • Simplified error handling

Contract Deployment

The UI-SDK provides a powerful contract deployment system that uses CREATE2 for deterministic addresses and supports both ContractFactory and raw bytecode deployments. All deployments are handled through Account Abstraction, ensuring consistent gas management and transaction handling. Key features:
  • Deterministic addresses using CREATE2
  • Support for both ContractFactory and raw bytecode
  • Address prediction before deployment
  • Customizable salt for address generation
  • Gas estimation utilities
  • Full Account Abstraction integration

Address Prediction

One of the key features is the ability to predict the contract address before deployment:

Salt Parameter

The salt parameter is a unique value that determines the deployed contract’s address when using CREATE2. It allows for:
  • Deterministic address generation
  • Multiple deployments of the same contract with different addresses
  • Address reservation and planning
  • Cross-chain deployment coordination
If not provided, a default salt is used: 0x0000000000000000000000000000000000000000000000000000000000000001

Deployment Methods

The UI-SDK supports two deployment methods:
  1. Using ContractFactory:
  1. Using Raw Bytecode:

Gas Estimation

Before deployment, you can estimate the gas cost:

Deployment Considerations

  • Address Prediction: Always predict the address before deployment to ensure it matches your expectations
  • Salt Management: Use meaningful salts for better deployment organization and address tracking
  • Gas Estimation: Estimate gas costs before deployment, especially for contracts with complex constructors
  • Cross-chain Deployment: The same salt will generate the same address across different chains
  • Verification: After deployment, verify that the deployed bytecode matches your expectations

Gas Management

Gas Estimation

Gas estimation in Account Abstraction is more complex than traditional transactions because it involves multiple components:
  1. Call Gas: Gas used by the actual operation
  2. Verification Gas: Gas used for signature verification and validation
  3. Pre-verification Gas: Gas used for bundler operations

Gas Price Management

The UI-SDK provides methods to fetch and manage gas prices for optimal transaction execution:

Basic Interactions

Common ethers.js interactions through AA provider:
Note: Replace environment variables and placeholder values with your actual configuration. Always ensure proper error handling and input validation in production code.