Parallelizable Paymasters in EntryPoint v0.9

If you’ve ever clicked “Swap” or “Send” in an AA wallet and stared at a spinner, you’ve mostly been waiting on one thing: the Paymaster.

In EntryPoint v0.7 and v0.8, the Paymaster sat right in the middle of the critical path. The app had to talk to the Paymaster service, wait for it to sign, and only then could the user’s account sign the final UserOperation hash. That made UX tightly coupled to Paymaster latency and made it hard to scale auth and sponsorship as independent services.

EntryPoint v0.9 changes that.

The new version introduces a paymasterSignature mechanism so the account and the Paymaster can sign the same UserOperation in parallel. Openfort’s v9 Paymaster is built around this idea and adds token-based sponsorship on top, so you get both:

• Async signing between user and Paymaster.
• ETH and ERC-20 support for gas sponsorship.

The rest of this post walks through what that actually means for your stack.

1. What a Paymaster actually does

In ERC-4337, the Paymaster is a contract that pays gas on behalf of the user under whatever rules you encode.

The user’s account decides what should happen – it owns callData, nonces, and permissions. The Paymaster decides under which conditions that action is sponsored – who is allowed, how often, with which limits or token balance checks, and so on.

When a UserOperation includes a non-empty paymasterAndData, the EntryPoint runs the Paymaster during validation, and again after execution in postOp for final accounting. So every sponsored operation runs through two questions:

1. Should this be sponsored?
2. Who actually pays for the gas, in what asset, and how much?

In earlier versions of EntryPoint, these questions were intertwined with user signing in a way that forced everything into a single serialized flow.

2. Why older Paymasters slowed down UX

Before v0.9, the entire paymasterAndData blob – including any Paymaster signature you packed into it – was part of the userOpHash. That detail drove the whole UX.

A typical flow looked something like this:

1. The user triggers an action in your app.
2. The frontend prepares a draft UserOperation and sends it to your Paymaster backend.
3. The backend evaluates policies, decides whether to sponsor, and returns paymasterAndData with its signature already embedded.
4. Only now can the client compute userOpHash, show a confirmation UI, and ask the user’s account to sign.
5. The final signed UserOperation is sent to a bundler.

The user is effectively waiting for the Paymaster before they even see the final confirmation screen. If the Paymaster is slow – or you’re doing real work there (risk checks, rate limits, KYC, pricing) – that latency leaks straight into UX.

In Openfort’s earlier Paymaster versions, this meant:

• The whole flow was synchronous: user signature after Paymaster decision.
• Sponsorship was ETH-only, which kept things simple but limited “pay gas with token X” models like USDC or in-app credits.

It worked, but it wasn’t the architecture you’d pick if you were optimizing for responsiveness and independent scaling of services.

3. What EntryPoint v0.9 changes under the hood

EntryPoint v0.9 keeps ABI-compatibility with v0.7 and v0.8 – so you don’t have to rewrite your accounts or Paymaster just to upgrade – but it adds a few important capabilities for high-throughput apps.

The main ones relevant here are:

3.1 paymasterSignature and parallel signing

The key idea is that paymasterAndData can now have a signature tail (the paymasterSignature) that is not included in the userOpHash, much like the main signature field.

In practice:

• You build a base paymasterAndData without the Paymaster’s own signature.
• The UserOperation hash is computed from that base payload.
• The account and the Paymaster both sign this same hash independently.
• The Paymaster signature is appended later in a tail that EntryPoint knows how to parse.

The result is that user signing and Paymaster signing no longer depend on each other’s roundtrip time. They’re just two services agreeing on the same payload.

3.2 Cleaner validity and deployment behaviour

Two other v0.9 changes matter when you start pushing throughput:

• Block-based validity windows validAfter and validUntil can be interpreted as block numbers when the high bit is set, so you can express “valid for the next N blocks” instead of “valid until timestamp T”.

• Safer initCode handling If an account already exists and you still send non-empty initCode, v0.9 ignores it and emits an IgnoredInitCode event instead of reverting. That makes it easier to use parallel nonces around onboarding without surprising failures.

There are a few more ergonomics (like getCurrentUserOpHash for contracts that need the hash during execution, and a cleaner BasePaymaster owner pattern), but the big UX lever is paymasterSignature.

4. Where this fits in the Openfort stack

In the broader Openfort stack, v9 Paymaster and EntryPoint v0.9 give you:

• A faster path to “tx confirmed” UX, because user signing is no longer blocked by Paymaster latency.
• A clean separation between auth and sponsorship, so each can be deployed, monitored, and scaled on its own.
• The flexibility to decide who pays gas and in what currency, without leaving the canonical ERC-4337 flow.

If you’re already running AA with a Paymaster and are feeling the pain of serialized flows or ETH-only sponsorship, v0.9 plus Openfort’s v9 Paymaster is the path to making that architecture feel more like a modern, modular backend service and less like a single long blocking call.