Skip to main content

Account Abstraction

Account abstraction (AA) replaces traditional externally owned accounts (EOAs) with programmable smart contract accounts. This unlocks capabilities that EOAs alone cannot provide:
  • Gas sponsorship — let users transact without holding native tokens for gas fees
  • Batched transactions — bundle multiple operations into a single atomic transaction
  • Session keys — grant temporary, scoped permissions without exposing the primary key
  • Custom authorization — implement multi-factor auth, spending limits, or recovery logic at the account level
  • Programmable accounts — create accounts with built-in rules for corporate or multi-user scenarios
Two standards are currently in use for AA on EVM-based chains: Both standards support gas sponsorship and batched transactions.
Learn more about EIP-4337 and EIP-7702 on the Ethereum Improvement Proposals site.

Para Integrations

Para acts as the signer (EOA) that controls smart contract wallets — it is not a smart wallet itself. Para handles secure key management via MPC, while the AA provider deploys and manages the smart contract account on-chain. This means your users’ private keys remain secure and under their control regardless of which provider you choose. Para wraps each provider in a shared SmartAccount interface. Whether you use EIP-4337 or EIP-7702 mode, your application code stays the same — you can swap providers or switch between standards without rewriting transaction logic. Every provider integration is available as an action function (createXxxSmartAccount) — an imperative async function you can call anywhere, including outside React components, inside custom hooks, or in server-side code. React applications also get a hook (useXxxSmartAccount) — a declarative wrapper powered by React Query that handles initialization, caching, and automatic re-creation when config changes. Both return the same SmartAccount object:
When using mode: "7702", the return type narrows to include an optional delegationAddress field — the smart contract the EOA delegates to. When using mode: "4337", smartAccountAddress is the counterfactual smart contract address (different from signer.address).

Provider Comparison

Provider Guides

Select a provider below for installation and usage instructions. Each tab shows two patterns:
  • Custom Hook — a React component pattern that initializes the smart account once in a useEffect and manages send state with useMutation from @tanstack/react-query. Good for screens that need reactive loading and error state out of the box.
  • Action — the raw async function call. Use this directly in event handlers, background tasks, or any state management setup you already have.
You’ll need an initialized and authenticated Para instance before calling any createXxxSmartAccount function. See the for details.
provides modular smart accounts with built-in gas sponsorship via Alchemy’s Gas Manager. Supports both EIP-4337 and EIP-7702 modes.

Setup

  1. Create an and obtain your API key and Gas Policy ID from the Alchemy dashboard.
  2. Install the required dependencies:

Usage

Initializes the smart account once when the component mounts using useEffect, then wraps sendTransaction in a useMutation from React Query for built-in isPending and error state.
AlchemyScreen.tsx
Alchemy requires chains from @account-kit/infra (e.g. sepolia, baseSepolia). Plain viem chains are automatically mapped if an Alchemy equivalent exists. For gasless transactions, set up a Gas Manager Policy in your and pass the policy ID as gasPolicyId.
In EIP-4337 mode, funds must be sent to smartAccount.smartAccountAddress — not to the Para EOA address.

Key Considerations for Mobile

  • Complete authentication with Para before the component mounts — the Para instance must have an active session
  • The useEffect pattern above fires once on mount; add config values to the dependency array if they can change at runtime
  • Wrap sendTransaction calls in useMutation for loading state and error handling in mobile UIs
  • Test on physical devices to verify signing flows, particularly for EIP-7702 delegation transactions