Setting up the development environment

A typical workflow starts with a TypeScript project created through Vite or Next.js. After installing ethers-v6 and dotenv for key management, the next dependency is the account-abstraction SDK of choice. Thirdweb relies on an account-factory contract that you deploy once—either immutable or upgradeable—then serves a free infrastructure key that unlocks its hosted bundler and paymaster. The dashboard issues this key immediately after you create a project and enables rate-limited calls on Sepolia, Base, and Polygon zkEVM.

Biconomy follows a similar structure but separates concerns more explicitly. You register a paymaster in the web console, top up a gas tank, and define policies that decide which methods will be sponsored. The SDK then injects the paymaster address and API key into every UserOperation your dApp signs. This design lets consumer apps add “gasless” flows without exposing a private relay server.

Safe’s CLI deploys a proxy wallet that inherits a battle-tested singleton contract; an optional Safe4337Module attaches ERC-4337 hooks so the same vault can enter the alt-mempool without changing its address. Developers can run the CLI in unattended mode to pre-deploy hundreds of proxies for an airdrop or test-net campaign.

Connecting to a smart account from the front end

Once the back-end pieces exist on chain, a React application can expose a single “Connect” button that resolves to a smart-account context. Thirdweb’s <ThirdwebProvider> wrapper takes a client-ID and a factory-address; when the user picks any underlying wallet—MetaMask, an email-based embedded wallet, or a passkey—the provider silently checks whether a contract already exists, then deploys it on the first transaction, funding gas through the integrated paymaster when gasless:true is set.

Biconomy injects its context through the BiconomySmartAccount class, which wraps an ethers Signer. After initialisation, all calls executed through this signer are encoded as UserOperations and forwarded to the bundler. Safe offers a similar abstraction via @safe-global/core-kit, where a SafeAccount instance replaces ethers.Wallet and exposes high-level helpers for batching, signature collection, and on-chain execution.

Customising wallet logic: gasless flows and whitelisting

Smart accounts expose hooks that run before a UserOperation is deemed valid, so adding features such as whitelisted destinations or daily spend limits is as simple as updating contract storage through an owner transaction. For gasless interactions the developer registers a sponsorship paymaster (Biconomy) or flips the gasless flag (thirdweb). Under the hood, the paymaster pre-signs the operation and later claims reimbursement from its gas tank; the user perceives a zero-ETH balance yet completes the action as if they had funded the wallet themselves. Whitelisting works the same way: a validation routine in the wallet checks the calldata against an allowed list and reverts if the call is out of scope, protecting users from malicious contract approvals.

Simulating and signing transactions with bundlers and paymasters

ERC-4337 introduces an alternative mempool in which bundlers collect UserOperations, perform off-chain simulation, and wrap successful sets into ordinary Ethereum transactions. Popular services include Alchemy Rundler, Stackup, Voltaire, and Infinitism; each exposes a JSON-RPC endpoint that mirrors the reference spec. Simulation prevents hopeless operations— for instance, calls that would fail the wallet’s validation—from reaching the chain and wasting gas.

A paymaster can piggy-back on that flow. During simulation the bundler asks the paymaster whether it will cover the fee and, if so, attaches the paymaster’s signature. On-chain the EntryPoint contract validates both the wallet and the paymaster in a single call, merges all batched actions, and distributes gas refunds accordingly. This mechanism lets an exchange sponsor deposits, a game subsidise in-game moves, or a DAO reward contributors without forcing users to hold ETH.

Testing and deploying: best practices for 2025

Local testing now benefits from fork-based networks such as Anvil or Hardhat-foundry, which can impersonate a bundler and paymaster so that the full UserOperation cycle runs in memory. Before pushing to test-net, projects compile with Solidity 0.8.25 and enable optimizer runs to match the bytecode that auditors will review. Continuous integration scripts execute static-analysis passes with Slither or MythX and run differential fuzzing against intended invariants.

Security remains paramount: 2025 audit guidelines emphasise multi-layer reviews that mix automated scans, manual analysis, and live penetration tests. Teams lock the codebase before audit, address critical findings, and publish the final report alongside their deployment metadata. Once the audit is clean, the factory contract is deployed first, followed by the paymaster (if needed) and finally the front-end environment variable updates that point to live bundler endpoints. After launch, monitoring hooks watch for failed UserOperations and reverted paymaster calls, alerting developers before users notice downtime.

With these steps complete, a dApp can present a one-click onboarding flow where newcomers create a wallet, mint an NFT, or enter a DeFi position without buying ETH first. The next and final module will map out real-world deployments of such flows, weigh current limitations, and survey emerging standards like ERC-6900 that promise even greater modularity.