# Bundler Sponsored Operations

> Learn how to use bundler sponsorship to cover gas fees for user operations without an onchain paymaster.

> For the complete documentation index, see [llms.txt](/docs/llms.txt).

## What is Bundler Sponsorship?

Bundler sponsorship is a beta feature that allows the bundler to sponsor gas fees for user operations directly, eliminating the need for an onchain paymaster contract. This approach provides a streamlined way to abstract gas costs from your users while reducing the complexity and overhead associated with deploying and managing paymaster contracts.

## Supported chains

Because BSOs are a bundler feature, they're supported on every chain that has **both** bundler and gas sponsorship support, with the exception of MegaETH (coming soon). 

See the full [Wallet APIs supported chains](/docs/wallets/supported-chains) matrix to confirm which chains qualify.

## How it differs from paymaster sponsorship

Traditional gas sponsorship in ERC-4337 relies on paymaster contracts deployed onchain. These contracts:

* Need to be deployed and funded on each network
* Require onchain verification logic
* Add additional gas overhead to user operations
* Require management of separate balances per chain

Bundler sponsorship, in contrast:

* Operates offchain at the bundler level
* Uses your Gas Manager policy to control spending
* Reduces gas overhead by eliminating paymaster contract calls
* Simplifies multi-chain deployments

<Info>
  Bundler sponsorship is currently in **beta**. While it's production-ready, features and pricing may evolve based on user feedback.

  For beta access, please reach out to [account-abstraction@alchemy.com](mailto:account-abstraction@alchemy.com).
</Info>

## Policy setup

To use bundler sponsorship, create a Gas Manager policy of type **Bundler Sponsored Operations** in your dashboard.

### Required policy configuration

When creating a Bundler Sponsored Operations policy, you must configure:

* **Policy Type**: Select "Bundler Sponsored Operations"
* **Max Spend Per UO**: Set the maximum amount the bundler can spend per user operation (required field)

This policy type differs from standard Gas Manager policies and is specifically designed for offchain bundler sponsorship.

## Compute unit costs

When using bundler sponsorship with `eth_sendUserOperation`:

| Configuration | CU Cost |
| ------------- | ------- |
| With bundler sponsorship header (`x-alchemy-policy-id`) | 3000 |
| Standard (without sponsorship) | 1000 |

For more details, see the [Compute Unit Costs documentation](/docs/reference/compute-unit-costs#gas-manager--bundler-apis).

## How to use bundler sponsorship

To enable bundler sponsorship, you need to:

1. **Create a Bundler Sponsored Operations policy** in your dashboard with the required Max Spend Per UO configuration
2. **Include the policy ID** in your requests via the `x-alchemy-policy-id` header on the bundler transport
3. **Zero out `maxFeePerGas`, `maxPriorityFeePerGas`, and `preVerificationGas`** on the user operation

### Example implementation

Below is the low-level (viem) pattern. The policy ID rides on the bundler transport's `fetchOptions.headers`; the bundler fills in the actual gas values server-side when it sees the zeroed fields.

```ts
import { createClient, type Hex } from "viem";
import { createBundlerClient } from "viem/account-abstraction";
import { privateKeyToAccount } from "viem/accounts";
import { worldchain } from "viem/chains";
import { alchemyTransport } from "@alchemy/common";
import { toModularAccountV2 } from "@alchemy/smart-accounts";
import { estimateFeesPerGas } from "@alchemy/aa-infra";

const ALCHEMY_API_KEY = process.env.ALCHEMY_API_KEY!;
const POLICY_ID = process.env.POLICY_ID!;
const PRIVATE_KEY = process.env.PRIVATE_KEY! as Hex;

// The policy ID rides on the transport's fetch options.
const transport = alchemyTransport({
  apiKey: ALCHEMY_API_KEY,
  fetchOptions: {
    headers: { "x-alchemy-policy-id": POLICY_ID },
  },
});

const rpcClient = createClient({ chain: worldchain, transport });

const account = await toModularAccountV2({
  client: rpcClient,
  owner: privateKeyToAccount(PRIVATE_KEY),
});

const bundlerClient = createBundlerClient({
  account,
  client: rpcClient,
  chain: worldchain,
  transport,
  userOperation: { estimateFeesPerGas },
});

// Zero ALL three gas fields — the bundler fills them in.
const hash = await bundlerClient.sendUserOperation({
  calls: [{ to: "0x000000000000000000000000000000000000dEaD", data: "0x" }],
  maxFeePerGas: 0n,
  maxPriorityFeePerGas: 0n,
  preVerificationGas: 0n,
});

const receipt = await bundlerClient.waitForUserOperationReceipt({ hash });
console.log("Tx:", receipt.receipt.transactionHash);
```

### Key configuration points

1. **Policy Type**: Ensure you've created a policy of type "Bundler Sponsored Operations" with Max Spend Per UO configured.

2. **Transport Configuration**: The `x-alchemy-policy-id` header must be included on the **bundler** transport via `fetchOptions.headers`. No `createPaymasterClient` needed — BSO does not use a paymaster contract.

3. **Gas Fee Overrides**: Set `maxFeePerGas`, `maxPriorityFeePerGas`, **and** `preVerificationGas` to `0n` on the user operation. All three must be zero — the bundler treats that as the signal to cover gas under the BSO policy.

## Requirements

* A valid API key with Bundler API access
* A configured Gas Manager policy of type **Bundler Sponsored Operations** with Max Spend Per UO set
* Wallet APIs SDK or equivalent setup for creating and signing user operations

<Warning>
  Ensure your Bundler Sponsored Operations policy has sufficient balance and that the Max Spend Per UO limit is set appropriately. If the policy balance is insufficient or the operation exceeds the spending limit, the user operation fails.
</Warning>

## Benefits

* **Simplified Architecture**: No need to deploy or manage paymaster contracts
* **Lower Onchain Gas Costs**: Eliminates the gas overhead of paymaster verification and contract calls
* **Reduced Latency**: Fewer network calls and onchain interactions result in faster user operation processing
* **Easier Multi-Chain Support**: Use the same policy type across multiple chains
* **Centralized Policy Management**: Control spending limits and rules from the dashboard

## Limitations (beta)

As this feature is currently in beta, be aware of:

* Features and API surface may change based on feedback
* BSOs are supported on chains with both bundler and gas sponsorship, with the exception of MegaETH (coming soon). See [Supported chains](#supported-chains) for details.
* Compute unit costs are subject to change
* Requires a specific policy type with mandatory Max Spend Per UO configuration

## Related documentation

* [Bundler API Quickstart](/docs/reference/bundler-api-quickstart)
* [Gas Manager Admin API](/docs/wallets/api-reference/gas-manager-admin-api/admin-api-endpoints/get-policy)
* [Compute Unit Costs](/docs/reference/compute-unit-costs)
* [Wallet APIs documentation](/docs/wallets)