Zksync
Zksync paymasters pay gas fees under programmable contract rules
Zksync paymasters pay gas fees in ETH for transactions that their validation rules accept on Zksync Era. Applications can cover those fees or charge an accepted ERC-20 token. The paymaster needs enough ETH to fund the transaction, even when the sender pays in tokens.
Updated:
Can a paymaster cover gas without ETH in the sender's wallet?
If an application funds the fee and the paymaster accepts its request, a sender can submit the transaction without ETH for gas. Full sponsorship moves the expense to the sponsor's ETH balance. An application can subsidize access to its contracts, including onboarding or selected interactions. Availability follows the rules of the actual paymaster: protocol support for sponsorship does not make every application call eligible.
Token-based fee payment leaves a user charge. The paymaster accepts a token and funds the gas in ETH. This changes the payment asset, while full sponsorship changes who bears the expense.
The bootloader's validation and fee payment path
Before execution, the sender's account validates the transaction and prepares any required paymaster interaction. The bootloader, the protocol component that coordinates transaction processing, then invokes the paymaster's validateAndPayForPaymasterTransaction method. The contract checks whether it agrees to pay and returns the validation result. It can also return context for later settlement.
An accepting paymaster must transfer the required ETH fee to the bootloader before execution.
This payment belongs to the fee-handling stage, so acceptance of sponsorship does not establish that the application call will succeed.
The transaction identifies the contract through its paymaster address and supplies encoded instructions in paymasterInput. Those instructions travel with the native EIP-712 transaction. The input may carry authorization data that the contract requires, but the address alone supplies no permission to use its funds. An integration must match the paymaster's expected encoding and validation policy.
Common implementations prepay gasLimit * maxFeePerGas. With gas price expressed in wei per gas, the product is in wei. That upfront amount can exceed the final fee after refunds.
When does a transaction need the approval-based flow?
A transaction needs the approval-based flow when its account must establish an ERC-20 allowance for the paymaster before the contract can collect payment. The standardized input includes the token address, a minimum allowance, and an additional byte payload for contract-specific data. An allowance authorizes spending from the sender's token balance; it is separate from the balance itself. The default account ensures that the allowance reaches at least the requested minimum. The paymaster must independently verify the actual allowance and every prerequisite that its payment logic relies on.
The general flow applies when the paymaster requires no preliminary action from the account. Its byte payload can carry data that the paymaster interprets, including an authorization signature. General identifies a preparation pattern, and its paymaster can enforce sponsorship conditions. Native account abstraction also permits custom interactions beyond these standardized flows. An integration using a custom account needs that account's preparation logic to match the paymaster's requirements, including any token approval that the payment arrangement needs.
A sponsored call beside a token-paid call
Consider a hypothetical comparison of the same contract call under full sponsorship and token reimbursement. Assume compatible accounts, successful validation and execution, sufficient balances, and any required allowances.
The sponsored version uses the general flow with no token charge in the assumed contract policy. Its paymaster supplies ETH, so the sender pays no gas fee for that call. The token-paid version uses the approval-based flow. Its paymaster collects the accepted token under the assumed payment terms and supplies the ETH fee from its own balance. Both calls have the same fee payer at the protocol boundary: the paymaster. The application absorbs the first cost, and the sender reimburses the second.
These outcomes hold only while the stated funding and acceptance conditions remain true. The sender's token balance cannot by itself satisfy the bootloader's ETH funding requirement.
Estimate the full paymaster transaction
Gas estimation must include the selected paymaster and its input to reflect the transaction that the application intends to submit. The estimate covers validation work, fee payment, and execution through a shared gas budget. A paymaster adds computations and may add token transfers or allowance updates. Those storage changes can affect pubdata charges, which are costs for data that the rollup publishes. Estimating only the application call omits the paymaster's work and can understate the needed gas limit. No single overhead figure applies to every implementation.
After execution, the protocol can refund ETH for unused gas to the paymaster that funded the fee. A token refund to the sender requires logic in that paymaster; an ETH refund does not automatically reverse a token charge. The optional postTransaction hook receives execution information and can implement additional settlement.
The postTransaction hook does not run when transaction execution ends with an out-of-gas error.
Refund accounting must therefore handle cases in which that hook never runs, alongside the cases in which it performs settlement.
Execution failure and sponsorship rejection occur at different stages. A paymaster that rejects validation stops the transaction before inclusion. A contract call that reverts after successful validation can still consume gas and appear as a failed transaction in a block. The paymaster's settlement terms determine how that cost affects any token charge. An integration should distinguish the execution status from the token amount charged and the ETH refunded to the paymaster.
Contract eligibility and direct ETH payment
Eligibility comes from the contract's rules, which may use a signed sponsorship authorization or a check of on-chain holdings. An NFT-gated design can condition sponsorship on the sender owning an NFT from a specified collection. A signature-based design can restrict which transactions its signer authorizes. These are implementation choices, so a general-flow transaction may still need extra authorization. Rules that admit arbitrary calls can expose a sponsor's balance to unwanted spending; limits need to cover the actual transactions that the contract agrees to fund.
Using a native paymaster requires an integration that can construct and authorize its transaction. Zksync Era's native account abstraction allows externally owned accounts to use paymasters. That protocol capability does not ensure that every wallet interface exposes the required transaction fields. Smart accounts can provide custom preparation for token payments. Direct ETH payment removes the dependency on a sponsor's eligibility rules and funding. Full sponsorship assigns the gas expense to an application budget, while token reimbursement retains a user charge in the asset that the paymaster accepts.
Zksync paymasters: quick answers
Does fee sponsorship replace the sender's transaction signature?
Gas sponsorship leaves the sender's account authorization requirement in place. For a default account, the sender signs the transaction that includes its paymaster data. A sponsorship signature from an application's authorized signer approves use of the sponsor's funds; it serves a different purpose from the sender's transaction signature.
Can a paymaster supply the ETH value that a contract call transfers?
Fee sponsorship alone does not supply the ETH value that an application call transfers. The sending account must cover any ETH that it sends with the call. A paymaster's fee payment goes to the bootloader, while transaction value goes to the called contract.
What limits an approval-based paymaster's token spending?
The token's remaining allowance limits what an approval-based paymaster can spend through that authorization. A larger allowance permits more spending than a smaller fee quote, unless the paymaster enforces the quoted charge in its own logic. An allowance is spending permission, so its value need not equal the amount actually collected.
Why does the testnet paymaster use a token rate unrelated to market prices?
The built-in paymaster on Zksync Sepolia uses a demonstration rate of one token base unit per wei of ETH. That rate compares raw integer units, without pricing the token at its market value. Token decimals affect the quantity that a wallet displays. Mainnet token charges follow the particular paymaster's pricing logic, so the testnet conversion does not establish a production exchange rate.
Can I change the gas limit after obtaining a sponsorship signature?
Changing the gas limit invalidates a sponsorship signature if the paymaster binds that signature to the exact gas limit. Such contracts may also bind the maximum fee per gas, sender, and target, or enforce signed expiry and nonce limits. The submitted transaction must satisfy every signed value or bound that the contract checks.
Is a successful gas estimate proof that sponsorship will be accepted?
A successful gas estimate does not establish that the paymaster will accept the submitted transaction. Estimation can measure validation work without enforcing the returned success value. Mainnet validation enforces that value, and funding or authorization conditions can also differ between estimation and submission.
Must an application deploy a separate paymaster for its users?
An application can use a shared paymaster when that contract supports its fee policy and integration requirements. A shared signature-based design can associate a funded sponsor balance with registered signers, allowing applications to authorize their own sponsored transactions. Deployment of a dedicated paymaster remains an alternative for custom rules.
Will an NFT-gated paymaster transfer the NFT to pay for gas?
An ownership-gated paymaster can check an NFT balance without taking ownership of the NFT. Its eligibility rule concerns the collection that the contract recognizes, so holding an unrelated NFT does not satisfy that rule. Charging an asset as payment would require separate transfer logic; ownership gating alone does not perform that transfer.