ZKsync does account abstraction differently from Ethereum. Where Ethereum adds it on top through ERC-4337, ZKsync builds it into the protocol: every account can be a smart contract account, and paymasters are a native part of how transactions are processed. There is no separate bundler or EntryPoint; any transaction can name a paymaster that pays its fees.
How ZKsync Paymasters Work
- A transaction includes a paymaster address and paymaster input that tells the paymaster what the user wants.
- The paymaster's validation function decides whether to pay and transfers the fee to the system.
- After execution, an optional post-transaction function lets the paymaster settle, for example refunding unused fees.
The protocol defines two standard flows for the paymaster input. The general flow carries arbitrary data and suits sponsorship based on your own rules. The approval-based flow tells the paymaster that the user approves a token amount, which suits paying fees in an ERC-20 token such as USDC.
What We Build
- Sponsorship paymasters that pay fees for your users under rules you set, comparable to gas sponsorship on other chains.
- Token paymasters using the approval-based flow, with reliable pricing, see token paymasters.
- Integration in your app through the ZKsync SDKs, so transactions include the right paymaster parameters.
- Funding and monitoring: keeping the paymaster funded and alerting on unusual usage.
Differences to Keep in Mind
Code written for ERC-4337 paymasters cannot be deployed unchanged on ZKsync; the interfaces and validation rules differ. ZKsync also compiles Solidity with its own compiler and has some differences in EVM behaviour, so contracts need to be tested on ZKsync itself, not only on an Ethereum testnet.
Frequently Asked Questions about ZKsync Paymasters
Do users need a special wallet?
No. On ZKsync, paymasters work for regular accounts too, because account abstraction is native. Users can keep their existing wallet.
Can we reuse our ERC-4337 paymaster?
The logic, yes; the contract, no. The paymaster has to be adapted to ZKsync's native interfaces and tested on ZKsync.
Does this work on other ZK chains?
Chains built on the same ZKsync stack share the native account abstraction model, so the same approach applies there.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Part of our paymaster development and account abstraction work.
Go Gasless on ZKsync
Tell us about your app on ZKsync and how fees should be handled. We will build a native paymaster that fits.