Sponsorship Policies

Spend controls for gas

Sponsoring gas shouldn't mean writing blank checks. Define exactly who gets sponsored, for how much, and for how long, like card spend controls but for transactions.

100M+transactions sponsored
100+chains

sp_onboarding_q3

New-user onboarding

Active
Sponsor first5 transactions / user
Max per transaction$1.00
Max per user$3.00
Campaign budget$5,000.00
ChainsBase, Arbitrum, Optimism
Budget used$1,860 / $5,000

The rules

Express your growth budget as policy

Every rule your growth team wants, enforced at the infrastructure layer.

First N free

Sponsor the first 5 transactions for every new user. It is the classic onboarding policy that turns signups into active users.

Per-transaction caps

Only sponsor transactions under $1. Small interactions stay free for users; whales pay their own way.

Per-user limits

Cap total sponsored spend per user so no single account drains your budget.

Campaign budgets

Give a launch, quest, or promotion its own hard budget. When it is spent, sponsorship stops on its own.

Chain & contract targeting

Sponsor only on specific chains or for specific contracts, so the budget goes exactly where the strategy says.

Instant changes

Tune limits in the dashboard mid-campaign. Changes apply to the very next transaction, with no redeploys.

For developers

One line in code, everything else in the dashboard

Attach a policy ID at transaction time and Pimlico enforces the rules at sponsorship time. Your growth team iterates on budgets and limits in the dashboard while your code stays untouched.

Every sponsored transaction is itemized against its policy, so finance knows exactly where the gas budget went.

policy.ts
// Attach a sponsorship policy created in the dashboard:
// "Sponsor the first 5 transactions per user, up to $1 each,
//  with a $5,000 campaign budget"
const txHash = await smartAccountClient.sendTransaction({
  to: "0x...",
  data: "0x...",
  paymasterContext: {
    sponsorshipPolicyId: "sp_first_five_free",
  },
})

Webhooks

When the rules need your backend

Some rules don't fit a form: KYC state, fraud scores, allowlists that live in your database. Add a webhook to a policy and Pimlico calls your server before each sponsorship, so you approve or reject every request with logic you own.

Read the webhook guide

webhook.ts
// Pimlico calls your endpoint before sponsoring. You decide.
export async function POST(req: Request) {
  const { data } = await req.json()
  const { userOperation, chainId, sponsorshipPolicyId } = data.object

  // Your rules: KYC status, fraud signals, allowlists — anything
  const user = await lookupUser(userOperation.sender)

  return Response.json({
    sponsor: user.verified && !user.flagged,
  })
}

Operations

Run policies like production infrastructure

Policies aren't set-and-forget. Everything you need to monitor, automate, and stretch them is built in.

Spend tracking per policy

Every sponsored transaction is itemized by policy, chain, and time in the dashboard, so each campaign answers for its own budget.

Custom alerts

Set alerts on budgets and limits and get notified before they are hit, so sponsorship never stops by surprise.

Manage policies via API

Create, update, and audit policies programmatically with the sponsorship policy API, so every campaign launch can spin up its own policy automatically.

Learn more

Sponsorships valid for 24h

Extend how long a sponsorship stays valid, long enough to collect multisig signatures or schedule transactions for later.

Learn more

At the cap

When the budget caps out, your app keeps working

Every budget owner asks the same question: what happens when the money runs out? A cap is a clean stop, not an outage. Sponsorship ends exactly where you set the limit, with no errors and no stuck users.

And because one client and one policy engine cover both sponsorship and the fallback, switching users to paying their own fees is a config change, not a migration.

ERC20 Gas SponsorshipsGas Sponsorship

1

A policy hits its cap

Sponsorship stops cleanly, exactly where you set the limit.

2

Nothing breaks

Transactions outside the policy simply are not sponsored. No errors, no stuck users.

3

The same client falls back

Users pay fees in USDC, USDT, or 300+ other tokens, or cover their own gas.

Proven at scale

The rules behind 100M+ sponsored transactions

Every sponsorship Pimlico processes runs through a policy. This is the scale of the engine that enforces yours.

100M+
transactions sponsored
250M+
total transactions processed
100+
chains supported
<2s
inclusion time on L2s
SOC 2 Type 1 certifiedOFAC sanctions screening24/7 supportAudited by OpenZeppelin & QuantstampCo-authors of ERC-4337, ERC-7677 & ERC-7679

Frequently asked questions

What rules can a policy express?

Per-user transaction counts (e.g. first 5 free), dollar caps per transaction, dollar caps per user, total campaign budgets, time windows, and chain or contract targeting. Rules combine, so "first 5 transactions under $1 each, capped at $5,000 total" is one policy.

Do policy changes require a deploy?

No. Policies live in your dashboard and are evaluated by Pimlico at sponsorship time. Edit a limit and it applies to the next transaction.

What happens when a budget runs out?

Sponsorship stops cleanly at the cap. Transactions outside the policy simply are not sponsored, so you can fall back to ERC20 gas payments or user-paid gas. You can also set alerts before limits are hit.

What does each sponsored transaction cost us?

Pimlico fronts the gas on-chain and bills you the actual cost plus a 10% surcharge on mainnet (none on testnets). Every sponsored transaction is itemized against its policy in the dashboard, and Enterprise plans get lower pre-negotiated rates.

Can I run multiple policies at once?

Yes. Run separate policies per campaign, per user segment, or per chain, each with its own budget and rules, and attach the right policy ID at transaction time.

Start sponsoring gas in minutes

Free on testnets, pay-as-you-go in production. Or talk to us about enterprise rates and ecosystem programs.