Bundler compatibility

Introduction

Bundler compatibility determines whether a provider can admit and execute sponsored operations for your Swig deployment.

Use when: you are enabling sponsorship or changing the provider for an existing account.
For: app integrators coordinating account support with their bundler operator.

How it works

Confirm support for the chain, canonical EntryPoint v0.9, and your Swig account implementation.
Have the operator register the account under its supported validation policy.
Check the endpoint’s EntryPoint list, then verify an actual sponsored operation in your environment.
During fleet upgrades, coordinate pending operations and prepare fresh authorizations afterward.

Compatibility checks

Check	Meaning
EntryPoint	Endpoint lists v0.9; necessary but not proof of account acceptance
Account validation	Provider supports Swig’s shared-beacon account architecture
Registration	Your specific config address is admitted by that provider
Sponsorship	Paymaster accepts the account, operation, chain, and EntryPoint

Swig’s shared beacon enables fleet upgrades without individual wallet upgrades. It also requires a compatible bundler policy. The SDK’s tested Rundler configuration uses an explicit account-scoped validation exception; support by a hosted provider must be confirmed separately. A successful local SDK test does not establish public-mempool acceptance.

SDK example

Check the EntryPoints exposed by a proposed endpoint using the Viem dependency from Environment setup:

import { createBundlerClient, entryPoint09Address } from "viem/account-abstraction";
import { http, isAddressEqual } from "viem";

export async function checkEntryPoint(bundlerUrl: string) {
  const bundler = createBundlerClient({ transport: http(bundlerUrl) });
  const entryPoints = await bundler.getSupportedEntryPoints();
  return {
    entryPoints,
    supportsV09: entryPoints.some((address) => isAddressEqual(address, entryPoint09Address)),
  };
}

Then run the sponsored transfer flow against your admitted account and check the operation result.

During an upgrade

Pause new submissions while the operator handles affected pending operations.
A queued operation may become invalid when the shared implementation changes.
Once the operator confirms readiness, prepare and sign fresh operations against current state.
Check the original operation’s status before retrying; the SDK does not automatically manage provider registration or reputation.

Getting started

Guides

Reference