Account Abstraction in Practice: Gasless Onboarding Without Losing Control

Account abstraction lets an application replace the externally owned account, with its seed phrase and its need for native tokens, with a smart contract account that the application can shape. The user experience that results, sign in with a passkey, no gas prompt, no seed phrase, is genuinely better. The engineering behind it introduces new roles and new places to lose money or control. This post describes how we structure the pieces in production and where the policy limits need to sit.

The moving parts

In the ERC-4337 model the components are: a smart account contract that holds assets and validates operations; a bundler that collects user operations and submits them to the entry point contract; a paymaster contract that agrees to pay gas on behalf of a user under conditions it checks; and optional signer abstractions such as passkeys or session keys. Some chains offer native account abstraction that folds the entry point and bundler into the protocol; the design concerns carry over.

Each role is a trust boundary. The account contract's validation logic decides who can act on the account. The paymaster decides what it will sponsor. The bundler decides what gets included and in what order. Confusing these responsibilities produces either a system that leaks sponsor funds or one that quietly reintroduces a custodian.

Smart accounts: keep validation simple

The account's validation function is the security core. It should verify a signature scheme you fully understand, apply a nonce, and nothing else. Every feature added to validation, including allow-lists, spending limits and session keys, should be a module with its own audit surface and an explicit installation and removal path. Prefer accounts built on a modular standard so features can be reviewed independently, and keep the ability to remove a module without the module's cooperation.

Upgradeability is a decision, not a default. An upgradeable account means the upgrade authority can change who controls the funds. If the application holds that authority, you have a custodian. If the user holds it, they need a key that can never be lost. Many teams settle on user-controlled upgrades with a time delay and a guardian-based cancellation path.

Paymasters: policy limits are the product

A paymaster that pays for anything is a faucet with extra steps. The sponsor's exposure is controlled by rules evaluated before the paymaster signs its approval, and those rules need to be at least as rigorous as the fraud controls in a payments product.

• Scope by target: sponsor only calls to your own contracts and specific functions, not arbitrary calls.
• Scope by user: per-account caps on sponsored operations and gas per day, with stricter caps for accounts with no history.
• Scope by value: refuse to sponsor operations whose simulated value transfer exceeds a threshold, or that grant approvals.
• Scope by time: sponsorship windows tied to onboarding steps rather than indefinite.
• Global kill switch: a limit on total sponsored gas per period that pauses the paymaster when exceeded.

Verifying paymasters, where an off-chain service signs each sponsorship after evaluating policy, give the most control. Token paymasters, where the user pays in an ERC-20, need a price oracle and are exposed to token volatility. Whichever you choose, the paymaster's deposit at the entry point is real money and should be monitored like a hot wallet, including alerts on unusual drain rates.

// Off-chain sponsorship policy evaluated before the verifying paymaster signs.
export async function shouldSponsor(op: UserOperation, ctx: PolicyContext): Promise<boolean> {
  if (!ctx.allowedTargets.has(op.target) || !ctx.allowedSelectors.has(op.selector)) return false;
  const sim = await ctx.simulate(op);
  if (sim.valueOut > ctx.maxSponsoredValue || sim.grantsApproval) return false;
  const usage = await ctx.usage(op.sender, '24h');
  if (usage.ops >= ctx.maxOpsPerDay || usage.gas + op.estimatedGas > ctx.maxGasPerDay) return false;
  return ctx.globalBudget.tryReserve(op.estimatedGas);
}

Session keys: scoped, expiring, revocable

Session keys let a user authorise a temporary key to act within limits, so a game or a trading interface does not prompt for every action. The safety of a session key comes entirely from its scope. Define the allowed target contracts and functions, a spending cap per session, an expiry measured in hours rather than days, and a revocation path that the main key can exercise at any time. Session keys should never be able to install modules, change the account's owners or grant token approvals. Store them in the client's secure storage, not in application state, and rotate them on every new session.

Bundlers: availability and ordering

Running your own bundler is optional but often worth it. Third-party bundlers can rate-limit, go down or reorder operations in ways that matter for latency-sensitive applications. A self-hosted bundler is a straightforward service, but it holds a funded key to pay for submissions, so it needs the same key management as any hot wallet. Whether hosted or not, monitor inclusion latency and failure reasons, and keep a fallback bundler configured so an outage at one provider does not stop onboarding.

An onboarding flow that stays honest

1. The user creates a passkey; the account address is derived counterfactually and shown before deployment.
2. The first sponsored operation deploys the account and performs the user's initial action in one step.
3. The wallet prompts the user to add a recovery method before any significant value arrives.
4. Sponsorship narrows automatically after onboarding: fewer operations per day and stricter targets.
5. Session keys are offered only for specific features, with visible scope and expiry.

Gasless is a subsidy. Treat the paymaster budget as marketing spend with fraud controls, not as infrastructure that can be set and forgotten.

What to monitor

Track sponsored gas per user cohort, rejection reasons at the policy layer, paymaster deposit balance and drain rate, session key usage against caps, and the number of accounts with no recovery method configured. The last metric is the one most teams ignore and the one that determines how many users will lose access when a device is lost. Account abstraction removes the seed phrase from onboarding. It does not remove the need for recovery; it only moves the moment when the user has to think about it.