Pimlico: Sponsoring an Agent’s Gas Without Confusing It With a Spending Limit

An agent has enough USDC to pay a supplier but no native gas token. Funding every agent with a second asset adds operational work, particularly when many small wallets are involved. Pimlico addresses the execution-fee side of this problem. The integration still needs a wallet, a signer and a decision about what that signer may do.

Research boundary: official documentation reviewed November 1, 2026. We did not fund a Pimlico balance or submit a UserOperation. Examples below are design choices and acceptance checks.

Put the paymaster in the right box

The documentation index separates paymasters, bundlers and permissionless.js tooling. Alto is Pimlico’s ERC-4337 bundler implementation. In an EVM smart-account integration, these components help sponsor and submit operations; they do not replace the account’s owner or signing service.

Pimlico’s agent guide demonstrates a smart account owned by a separately supplied signer. Its example uses a Safe account, with Pimlico providing bundler and paymaster services. Treat this as one documented configuration, not a promise that every account and EntryPoint version can be mixed interchangeably.

Separate authority from fee approval

Conceptual EVM sponsorship flow, not a payment test. Exact preparation steps depend on the account and SDK integration.

A wallet authorization asks whether the agent may perform a call. A sponsorship decision asks whether a particular budget will pay its execution fees. A small gas allowance does not imply a small token-transfer allowance. Conversely, a valid authorized payment can fail to proceed when its sponsor refuses to pay.

For a supplier-paying agent, review these two controls independently. Limit the operations the signer can authorize, then define the sponsorship budget. If the product promises a maximum total purchase amount, point to the wallet or application mechanism enforcing it rather than to a paymaster policy screenshot.

What sponsorship policies actually cap

The policy guide describes limits across sponsorships, per user and per operation. A failed policy check produces an error instead of sponsorship. These controls are useful for protecting the operator’s gas budget, especially when an agent repeatedly attempts a failing task.

Our recommendation is to map each agent or tenant to the identity the sponsorship service actually measures. If several jobs share one account, account-level usage will not necessarily tell you which business task consumed the allowance. Maintain your own job-to-operation records for cost attribution and abuse investigation.

Pimlico also documents paying gas in an ERC-20 token. That changes the asset and party used for fees; it does not eliminate fees. An interface saying “no ETH required” should not quietly imply that the user pays nothing.

A fallback payer is a product decision

The agent guide includes an example that falls back from sponsorship to the agent’s USDC. Before adopting that behavior, decide whether the user has agreed to spend that balance on execution. A generic catch-and-retry can obscure whether the original problem was a budget limit, a malformed request or a transient service failure.

A better product contract is explicit: stop and explain, queue for operator review, or use a pre-approved fee fallback. Record which path was chosen. Do not make a surprising fee charge the default repair for an unrelated error.

Failure or transition	Useful acceptance question
Sponsorship allowance is exhausted	Does the task stop or use an explicitly approved payer?
An operation is included but reverts	Does the product report failed execution rather than “paid”?
Two workers use the same account	Is nonce handling appropriate for concurrent submissions?
The merchant never delivers	Can the payment receipt be separated from the delivery dispute?

Protect the key that spends the gas budget

Pimlico’s API-key guidance warns that an exposed sponsorship key can fund arbitrary operations. Browser-origin and user-agent restrictions are not a complete secret-protection boundary. The guidance recommends validating operations on a backend that holds the key and applying spending policies.

An authenticated proxy is only useful if it checks the operation it forwards. A service that hides the key but accepts arbitrary caller-supplied transactions can still expose the budget. Keep policy administration separate from the ordinary agent execution path, and make suspicious sponsorship use observable without logging wallet secrets.

Where Pimlico fits

Pimlico is relevant when the application wants control over its signer and smart-account choice while delegating bundling and gas-payment infrastructure. It should be compared as an execution component, not as a complete agent wallet or merchant billing system.

Start with the Pimlico reference and spending-limit guide. A convincing demonstration should show both the sponsored success path and a refusal that leaves the user’s assets and the operator’s budget within the intended boundaries.