As we continue #scalingthemission, we want to highlight our Paymaster feature and how it can improve user experience.
🧵1/8
🧵1/8
A paymaster is a smart contract that can pay for transactions for its users, executing any logic to decide whether it should forward a transaction. For example, developers can allow users to run transactions for free or pay in your application's ERC-20 token instead.
2/8
2/8
The paymaster feature was first included as an extension of the Account Abstraction EIP (EIP-4337). zkSync supports AA natively, although our implementation has some core differences from the original proposal. Read more about them here: v2-docs.zksync.io/dev/developer-….
3/8
3/8
The main goal of our customized approach is to keep the following properties:
• Security and good UX for the user
• Flexibility for the paymasters and developers
• DoS safety
4/8
• Security and good UX for the user
• Flexibility for the paymasters and developers
• DoS safety
4/8
Paymasters implement our IPaymaster interface with the following methods:
• validateAndPayForPaymasterTransaction: decides if the paymaster approves paying for the transaction
• postOp: called after the transaction is executed (ex: to refund sender for unused ergs)
5/8
• validateAndPayForPaymasterTransaction: decides if the paymaster approves paying for the transaction
• postOp: called after the transaction is executed (ex: to refund sender for unused ergs)
5/8
If you want to try out how paymasters work, we provide a testnet paymaster on zkSync 2.0. You can find all the details here: v2-docs.zksync.io/dev/developer-…
6/8
6/8
For mainnet, we will not provide a default paymaster, as we want the ecosystem to evolve fairly. To build your paymaster, you can follow the tutorial here: v2-docs.zksync.io/dev/tutorials/…
7/8
7/8
You can learn more about paymasters and account abstraction in the zkSync documentation: v2-docs.zksync.io/dev/developer-…
8/8
8/8
• • •
Missing some Tweet in this thread? You can try to
force a refresh
