ERC-4337 Paymasters: How Validation, Sponsorship, and Settlement Actually Work

ERC-4337 introduced the paymaster as a way to decouple who submits a transaction from who pays for it. Understanding how that actually works end to end, from validation through settlement, makes it easier to evaluate any paymaster infrastructure, including the tradeoffs different providers make.

Step one: the UserOperation

Under ERC-4337, a smart account constructs a UserOperation instead of a standard transaction. This includes the call data, signature, gas limits, and, if sponsorship is in play, a paymaster field. A bundler collects UserOperations and submits them to the EntryPoint contract as a batch.

Step two: validation

When the EntryPoint processes a UserOperation with a populated paymaster field, it calls into that paymaster contract to check eligibility. This is where policy lives: which operations qualify for sponsorship, whether the sender is within its usage limits, and whether the request matches the rules the application has configured. In Trustware's system, this authorization step runs through an offchain signer that checks the client's own rules before a sponsored UserOperation is approved.

Step three: sponsorship and settlement

Once validated, the EntryPoint deducts the gas cost from the paymaster's deposit rather than the sender's balance, and the operation executes. Because gas sponsorship under ERC-4337 only applies to UserOperations, which originate from smart accounts, this whole flow depends on the sending wallet operating through a smart account layer, not a plain EOA.

Where this connects to more than gas

A paymaster on its own answers one question: will this transaction's gas get covered? For applications handling any-asset, any-chain transaction flows, that's only part of what needs to happen. The transaction also needs to route through the right liquidity and settle into the asset and destination the application actually needs.

This is why Trustware built its paymaster to plug directly into its Route Handler, the layer that normalizes different route providers and selects the best available path for a given user intent. The paymaster sponsors the gas that gets a transaction confirmed; the Route Handler makes sure the transaction itself lands where it needs to. Both layers are built non-custodially: funds move peer-to-contract-to-peer, and Trustware never takes custody at any point in the flow.

Validation, sponsorship, and settlement are three separate technical steps, but for an application, they need to feel like one connected system, not three separate vendors bolted together.