Zksync

Zksync paymasters pay Era gas fees with ETH while enabling sponsorship or ERC-20 reimbursement

Zksync paymasters pay Era gas fees from their ETH balance, allowing applications to sponsor eligible transactions or accept supported ERC-20 tokens from users. The selected contract determines token support, authorization, and charging rules. A user can avoid supplying ETH for gas when that contract approves and funds the transaction. Choosing a paymaster therefore means checking who bears the cost, what spending permission it needs, and how its settlement rules handle failed execution and unused gas.

Bottom line: A token allowance authorizes spending, while the paymaster’s charging and refund logic determines the user’s eventual token cost.

Sponsorship and ERC-20 payment choices

Gas sponsorship covers the network fee from a sponsor’s budget, while token payment reimburses a paymaster under its contract’s terms. Both models use Era’s native account abstraction. Direct ETH payment remains an alternative when sponsorship is unavailable and the sender can fund gas.

An application’s choice of flow controls account preparation. The general flow carries data for the paymaster without a predefined token-approval operation. The approval-based flow supplies token and allowance instructions. Custom accounts can implement different interactions, so native paymaster support does not automatically establish compatibility with every standardized flow.

Why do paymasters need ETH when users pay in tokens?

Paymasters need ETH because Era’s bootloader collects the sponsored network fee in ETH. The bootloader coordinates transaction validation and execution. ERC-20 reimbursement follows the agreement between the user and the paymaster. Token collection alone does not replenish the contract’s ETH balance. A paymaster can include conversion logic, or retain tokens while its operator supplies ETH separately. Its funding arrangement must deliver enough ETH during validation, before the application call executes.

Common implementations prepay gasLimit * maxFeePerGas wei, providing fee capacity that can exceed the eventual network charge.

Token allowances inside the sponsored transaction

Account preparation

An ordinary Era account can establish the requested token allowance during preparation for an approval-based paymaster transaction. A separate approval transaction is not inherently necessary. The account reads the token and minimum allowance from the encoded input. The additional payload carries data for the paymaster’s own validation logic.

Custom accounts choose how to implement preparation. Their integration must provide the permissions that the selected paymaster actually requires. A token-charging paymaster needs its own allowance checks and must handle token transfer failures. An input that names a minimum allowance cannot substitute for those checks.

Permission left after payment

A token allowance authorizes a spender to transfer tokens up to the approved amount without moving tokens by itself. The amount that a paymaster collects follows its charging logic, so an allowance ceiling can exceed the settled token charge. Token balances, remaining allowance, and transfer records describe different parts of that payment.

View image file

Unused permission can survive when a paymaster does not consume the entire allowance. A later revocation changes future spending authority, subject to the token’s behavior. It cannot undo a completed transfer. The spender address and requested allowance therefore matter before signing the sponsored transaction.

Gas estimates with paymaster validation

Gas estimation needs the intended paymaster address and input because sponsorship adds validation and payment work to the target contract call. ERC-20 transfers and allowance changes can add further cost. Era uses one transaction gas limit across these operations, and publishing public rollup data, called pubdata, can affect it. A quote for a call without the paymaster omits the chosen payment path. Some designs also bind authorization to fee parameters, creating a dependency between signing and estimation. Their estimation logic needs to preserve relevant work without treating incomplete authorization as valid sponsorship.

What does a paymaster validation error mean?

A paymaster validation error means that the sponsored transaction failed acceptance checks before the application call could execute.

Validation rejection

Validation rejection leaves the target call unexecuted and prevents the transaction from entering a block or incurring a network fee. Possible causes include unsupported input, inadequate token allowance, invalid authorization, or insufficient paymaster ETH. More gas cannot repair a rejected signature or make an unsupported token acceptable.

Gas estimation can report the same rejection because it runs the paymaster’s validation logic. Repeatedly increasing the gas limit can therefore leave the underlying failure unchanged. A transaction hash from submission alone establishes neither inclusion nor successful execution.

Execution reverts

An execution revert happens after successful validation and fee payment. Era can include that failed transaction in a block and charge gas for the work performed. The target call’s failure does not erase every action from the earlier validation phase, including token collection that a paymaster performed.

The receipt’s execution status and the paymaster’s token settlement describe separate outcomes. Transfer records identify tokens actually collected or returned; application state establishes what the target call changed. A sponsorship confirmation cannot establish either outcome before execution.

Network refunds and token reimbursement

ETH returned to the payer

Era sends its unused-gas refund to the paymaster when that contract paid the transaction fee. That refund replenishes the paymaster’s native balance. It does not, by itself, reverse the user’s ERC-20 payment or establish the token amount that the user should receive.

View image file

Contract-defined token refunds

A paymaster can implement token refunds through its settlement logic. The postTransaction hook lets a contract examine execution and perform follow-up accounting. The protocol does not guarantee that it will invoke this hook; an out-of-gas execution can prevent it. Refund designs that rely entirely on the hook must account for that failure condition.

The hook also consumes gas, which can reduce the eventual native refund. A fixed token charge, proportional charge, or refund policy describes the selected contract’s economics. Era’s ETH refund mechanism does not impose a matching token tariff or refund policy on every paymaster.

Testnet pricing and production limits

The built-in paymaster on Era’s Sepolia testnet supports only the approval-based flow and does not use the inner payload, which should be empty. Its encoded token charge must cover at least gasLimit * maxFeePerGas token base units, with sufficient allowance from the sender. The contract collects that encoded amount and leaves its post-transaction hook empty, so it does not reimburse surplus tokens through that hook.

Production paymasters choose their supported tokens, charging logic, and authorization requirements. Sponsorship remains conditional on available ETH and accepted transaction rules. Operators need authorization controls that constrain access to the gas budget. Noncompliant paymasters can stop working if the protocol tightens enforcement of its verification rules.

Testnet fee calculations use raw token quantities, so different decimal precision produces different whole-token charges. The Sepolia testnet paymaster sets the minimum token charge at 1 token base unit per wei of prepaid ETH.

View image file

Zksync paymasters: quick answers