ERC4337 Paymaster Security: Sponsorship, Prefund and Settlement

Choose the sponsorship boundary

The sponsorship decision commits someone else's gas budget.

ERC4337 paymaster security therefore starts with the permitted operation and the maximum financial exposure, rather than the promise of a gasless interface. A valid account signature can authorize a user action while the sponsor's own policy still needs to reject its destination, timing or cost.

A paymaster supplies the gas-paying deposit for an accepted sponsored UserOperation. The account and paymaster have distinct validation responsibilities. In the sponsored path, the account's missing-funds argument is zero because its deposit is not the selected payment source. That separation prevents a useful account authorization check from being mistaken for approval to spend the sponsor's funds.

Choose the deployment and EntryPoint version before specifying policy. Our arithmetic below uses the fixed v0.8.0 account-abstraction implementation. The currently retrieved ERC4337 standard contains later details, including an optional paymaster signature suffix. We do not project those features backward into the pinned source. Mixing versions can produce a message-binding explanation that is wrong for the deployed verifier.

These are policy choices, not one universal paymaster design. A product sponsoring a tightly bounded onboarding action has a different risk appetite from a general-purpose token-charging service. Specify who can change the policy, what revokes an outstanding sponsorship and which component pays when the user operation fails. The operational owner needs those answers before increasing the budget.

The current ERC4337 source supplies the protocol boundary. Our smart contract threat modeling guide helps turn that boundary into an application-specific review scope. Neither a successful simulation nor a marketing description establishes a sponsor's maximum loss.

Original prefund grid from EntryPoint source

Method

We extracted the required-prefund expression from the pinned EntryPoint source and evaluated its full declared integer input grid. Its gas sum includes account verification, account execution, paymaster verification, paymaster post-operation and pre-verification allocations. Multiplying that sum by maxFeePerGas gives the reservation used by this source path.

Source and retrieval

Account-abstraction v0.8.0 EntryPoint.sol and StakeManager.sol, fetched on October 11, 2026.

Population

64 fictional allocation fixtures from both values on each of six axes.

Gas axes

Verification 20000/40000, execution 50000/200000, paymaster verification 10000/30000, post-operation 0/40000 and pre-verification 21000/50000.

Fee-cap axis

1000000000/3000000000 wei per gas. These are artificial fixture values, not current network prices.

Deposit boundary

Each fixture was tested with a deposit one wei below, exactly at and one wei above required prefund, giving 192 cases. No fixture was excluded.

Artifacts

seo/research/integration-boundaries-2026-10-11/support-signatures/measurements.py, results.json, paymaster-prefund-grid.csv and paymaster-deposit-boundaries.csv; retained in the repository, not public downloads.

Results

Omitted reservation is positive precisely where our post-operation allocation is nonzero. Its two nonzero values are 40000000000000 and 120000000000000 wei, reflecting the two fixture fee caps. This is an arithmetic difference, not an observed sponsor loss. The full prefund range in the grid is 101000000000000 through 1080000000000000 wei.

Limits

• No UserOperation executed in an EVM. The input allocations and fee caps were invented for a complete finite boundary test.
• A passing deposit subtraction is only that predicate's result. It does not imply valid signatures, accepted time ranges, sufficient validation gas or bundler acceptance.
• Reserved prefund differs from actual settlement cost. The grid is not a quotation, a gas estimate or a recommendation for production limits.

This decision implication is practical: an approval record must use the full deployed-version reservation expression. An account-execution budget alone can omit a sponsor's own validation or settlement allocation. A larger deposit makes that arithmetic easier to satisfy, but does not correct an overbroad sponsorship policy.

Separate deposit, stake and settlement

The gas-paying deposit and locked stake serve different purposes. The current ERC4337 text explicitly states that stake is never slashed and provides no slashing mechanism. Treating stake as a pool that automatically absorbs malicious sponsorship confuses an admission or reputation condition with payment. A sponsor's gas exposure belongs to the deposit and the implemented policy.

Bundlers enforce applicable stake and validation rules during simulation. The standard also allows unstaked entities under its stated restrictions. The retrieved ERC7562 document is in Review, so its detailed policy is a review-stage reference rather than a blanket statement about every deployed bundler. Our arithmetic does not test any bundler's mempool policy.

Deposit

Funds selected for gas payment and checked against required prefund.

Stake

Locked funds associated with applicable entity admission rules and withdrawal delay.

Settlement

The implemented accounting that charges actual operation cost and handles unused reservation.

In the fixed source, reservation occurs before paymaster validation. A failed reservation produces AA31. Paymaster validation has its own gas allocation; excessive consumption produces AA36. Keeping those errors separate helps an operator decide whether to replenish a budget, correct an estimate or investigate validation logic. Raising both limits indiscriminately can hide the actual cause.

The actual gas-price expression also differs from blindly using the maximum fee cap. This version takes the minimum of the cap and the priority fee plus base fee. Its operation fee argument is distinct from the bundler transaction's tx.gasprice. A settlement design should use the fields actually supplied by the deployed EntryPoint.

Unused reserved prefund returns to the relevant deposit under the source's accounting. That refund does not mean the failed user action was free. A sponsor may pay for a reverted operation, so budget approval needs to include plausible rejection and failure traffic as well as successful application usage.

Withdrawal authority is another independent control. The fixed stake manager requires a positive unstaking delay when stake is added and prevents shortening an existing delay through that call. Withdrawal of stake depends on the recorded withdrawal time having arrived. Those mechanics should not be used to describe ordinary gas-deposit access: the two balances and their available operations have different roles.

Preserve both balances in an operator's inventory with their actual authority paths. A label such as sponsor funds can hide whether an amount is available for gas, locked as stake or already reserved for an accepted operation. During reconciliation, identify the relevant EntryPoint and compare its records with the service's own ledger. A balance on a different deployment cannot satisfy this deployment's reservation check.

Bind sponsorship to the intended operation

A sponsorship signature is useful only if changing a material operation field changes what the sponsor approves. Define the authorized sender, EntryPoint, chain, target action and cost bounds for the actual design. If the paymaster relies on backend eligibility, specify how that decision is encoded and which on-chain checks enforce its consequences.

Use the deployed version's hashing rules. In v0.8.0, UserOperationLib hashes the complete paymasterAndData value in its encoded operation. The current standard's optional signature-suffix treatment is a different detail. A verifier design must explain its own signing construction rather than copying a later standard paragraph into an older implementation.

This fixed packed prefix contains the paymaster address followed by its verification and post-operation gas fields. Paymaster-specific bytes follow that prefix. Source validation rejects a nonempty prefix with a zero paymaster address. Encoding tests should inspect the decoded fields and verify the intended values, rather than merely asserting that a serialization round trip returns some bytes.

1. Pin the EntryPoint address, source release and paymaster implementation used by the deployment.
2. Write the sponsor's eligibility and budget conditions as explicit acceptance criteria. Assign an owner to changes in those conditions.
3. Mutate each material field in an otherwise accepted operation and verify that sponsorship cannot be reused beyond its intended scope.
4. Test the deployed EntryPoint as caller, then an unrelated caller. A settlement or validation entrypoint must not expose the sponsor's authority to an arbitrary address.
5. Revoke or expire a sponsorship fixture under the implemented policy, then confirm that the unchanged original operation no longer receives approval.

The fixed BasePaymaster requires its configured EntryPoint to call validation and settlement. Its EntryPoint reference is immutable. A custom paymaster that replaces those guards needs an equally explicit authority argument. The mere presence of familiar function names does not make their caller relationship safe.

Eligibility services can also approve a request that later becomes unaffordable or undesirable. Decide whether an outstanding approval has a bounded lifetime, whether changes invalidate it and how retries are treated. These are application acceptance criteria; the standard does not automatically create a sponsor-specific daily budget or business quota. A backend counter that never reaches an enforced on-chain condition needs its own race and availability analysis.

Separate cryptographic key rotation from policy rotation. Changing the signing key can affect which sponsorship proofs the paymaster recognizes. Changing recipients or gas caps can affect the meaning of an otherwise valid proof. The review packet should identify the exact change and the outstanding messages it affects, rather than declaring that a single rotation necessarily revoked every earlier approval.

For an engagement covering these controls, Pharos Production describes smart contract access-control, logic and gas review as part of its security audit service. That scope matches caller restrictions, sponsorship logic and gas allocations. Ask for the paymaster and EntryPoint version to be named in the review packet; the service description itself does not establish that this particular deployment has been tested.

A packed prefix is a useful compatibility fixture. It contains 20 bytes of address followed by two 16-byte gas fields, with paymaster-specific data starting at byte 52. Test an empty value, a short nonempty value, the minimum complete prefix and a complete prefix carrying a zero address. These shapes do not all mean no sponsorship: the source gives malformed nonempty values and a zero paymaster their own rejection paths.

Keep those encoding tests separate from budget tests. A complete prefix can still declare allocations outside the source's accepted numeric bounds or carry data the paymaster rejects. A passing serialization fixture establishes that the fields arrived as intended; it does not approve their economic consequences.

Test settlement and sponsor failure

The user action can fail after sponsorship was accepted. The paymaster must handle that outcome according to its settlement design. In this fixed implementation, a nonempty validation context leads to the external post-operation call after main execution. The argument supplied as actual gas cost excludes the cost of that post-operation call itself, so a token-charging formula needs to account for the meaning of the supplied value.

postOpReverted deserves careful wording. The v0.8.0 interface describes it as an internal cleanup mode that is never passed into the paymaster's external postOp call. The implementation skips that external invocation during cleanup. Treating it as an ordinary third callback mode would create a misleading test matrix.

Test token collection separately from application execution. A token-charging design can face insufficient balances, changed allowances or token behavior its settlement logic did not expect. These are review scenarios, not claims that every paymaster collects a token. Include an accepted collection fixture and a deliberately failing fixture so accounting consequences can be inspected.

Oversizing gas allocations also has a version-specific consequence. Our separate 15-case integer model reproduces the pinned unused-gas penalty expression. With unused allocation exactly 40000, penalty is zero; at 40001, the modeled penalty is 4000 gas units. The source applies its 10 percent calculation to the entire unused allocation above the threshold, with integer rounding. This is not a current transaction-cost quotation.

A bundler assembling a bundle must account for aggregate paymaster deposit usage. Passing one isolated reservation check does not establish that all accepted operations fit together. Preserve bundle assumptions and compare expected consumption with the actual settlement records. Our fixture grid tests no ordering, bundling or concurrency behavior.

Rehearse sponsor unavailability as a product condition. A service that cannot obtain sponsorship should explain whether the user can pay directly, wait or cancel. That fallback must preserve the intended action and account authorization. Automatically broadening sponsor eligibility to make an error disappear changes the approved policy. Record such a change as a decision instead of treating it as routine retry logic.

Finally, inspect the evidence for a settlement failure at the right boundary. A user interface may display the application revert while omitting the sponsor's accounting effect. Retrieve the operation outcome and deposit movement together. If either observation is unavailable, preserve the gap so the financial ledger does not silently assume that an unsuccessful business action incurred no payment responsibility.

The smart contract monitoring guide supplies a broader framework for observing failed calls and changed controls. Alerts should name the violated sponsorship condition. A generic failed-transaction count cannot tell an operator whether the sponsor's deposit, policy or token collection caused the problem.

Approve a bounded sponsorship budget

Approval should identify the deployed source, allowed operation population, reservation formula and settlement tests. Assign separate owners to policy changes, deposit funding and incident response. Combining those responsibilities can be convenient, but the evidence record should still show which authority made each decision.

Set change triggers before launch. A new EntryPoint version, broader recipient list, revised token-charging formula or changed paymaster signing key can invalidate an earlier review assumption. Budget growth alone is also a decision: more funds support more traffic while enlarging the consequences of an overly permissive rule.

Use the security provider directory and Pharos Production's member profile when selecting a reviewer, then request evidence specific to sponsorship. An audit title does not reveal whether the engagement included backend policy, bundler compatibility or deposit operations.

The reservation study establishes a bounded arithmetic result: omitting post-operation gas understates required prefund in 32 of our 64 fictional fixtures. The next accountable decision is to verify the full expression and failure accounting in the actual deployment. A sponsor can then approve a budget whose assumptions are visible and whose changes require a named review.