Paymaster Description

Objective: Implement an ERC20GatedPaymaster that covers gas fees for users based on their possession of a specific ERC20 token.

Functionality:

• Before agreeing to pay the gas fee, the ERC20GatedPaymaster will verify if the user holds a certain ERC20 token in their account.
• The user must have a balance greater than 0 of the specified ERC20 token to be eligible.
• If eligible, the paymaster will cover the corresponding gas fees for the user's transaction.

Rationale

1. Extended Utility for Tokens: This paymaster concept augments the utility of governance tokens and other ERC20 tokens. Token holders can engage in platform activities without the concern of gas fees.
2. Innovative Use Cases: Projects can incentivize their communities to hold onto their tokens by offering gas-free transactions.
3. Ease of Adoption: With the proliferation of ERC20 tokens in various projects, a ready-to-use ERC20GatedPaymaster can easily be adopted and integrated, making it a valuable tool for numerous projects.

Additional Information

• Extending Considerations: While the primary check is for a non-zero balance, the contract can potentially be extended to require minimum token thresholds for different tiers of gas fee coverage.

Task deliverable

• Adds ERC20GatedPaymaster contract
• Add to the UI integration
• Add unit tests
• Updates readmes

Paymaster Description

Objective: Implement aSignatureBasedPaymaster contract that covers gas fees for users based on valid signature provided by the signer of the paymaster contract.

Rationale

1. Enhanced user flexibility : Current gated examples Allowlist,ERC20Fixed,ERC721Gated require owner of the paymaster to perform a certain type of on-chain transactions such as setBatchAllowance() in Allowlist, Transferring ERC20 token to user, Transferring ERC721 token to user etc. However, SignatureBasedPaymaster eliminates the necessity for pre-transaction and post-transaction requirements, thus making it more flexible.

2. Efficient short term use : New users onboarding without on-chain transactions from owner providing a one-time speedy and hassle-free process.

3. Secure personalised paymasters : A personalised paymaster that takes care of gas fees of all the user's related addresses with simple off-chain signatures. An application can be build over this use-case; thus expanding mainstream paymaster services.

Additional Information

Functionality:

• This paymaster contract shall validate based on the signature provided through innerInputs whether or not the user's transaction shall be allowed to proceed or not.
• The signer shall have authority to ensure signature is only valid upto particular timestamp.
• The signature shall be EIP712 compliance which is signed on values like (user address, last timestamp, nonces).
• Users are required to provide certain inputs such as signature and last timestamp as innerInputs in paymaster params.
• The paymaster will then check signature based on transaction.from, block.timestamp and nonces to ensure only valid users are allowed to use paymaster.

Security Considerations:

• Paymaster should use nonce for every user in validating signatures which increments on every successful transactions.
• Paymaster should check expiry timestamp of signatures.
• Paymaster should validate signatures based on transaction.from to ensure correct user has sent transaction.
• Paymaster should revert if recovered signer does not match or signature expires.
• Owner can update the paymaster signer.
• Owner should be able to cancel any user's nonce.
• EIP712 compliance signatures support.
• Use of battle-tested standard libraries for ECDSA signature verification (Openzeppelin)

Are you willing to write the paymaster contract?

Yes. Completed below deliverable tasks at PR-22:

• Add SignatureBasedPaymaster contract
• Add unit testing, deploy scripts
• Update readme.
• Update UI (needs more discussion)

Sample deployment on mainnet

Paymaster Description

Objective:

To create a paymaster that facilitates the payment of transaction fees in wETH (wrapped Eth) using the ApprovalBased flow.

Functionality:

1. Paymaster Role: The paymaster should sponsor transactions for users, enabling them to pay transaction fees in wETH.
2. Approval-Based Flow: Implement the ApprovalBased paymaster flow, which requires users to set a certain allowance for the paymaster to operate. The paymaster should ensure that the provided allowance is sufficient for the transaction fees.

Rationale:

Creating a paymaster that pays fees in wETH, we can enhance user experience, security, and flexibility, promoting broader adoption of zkSync's advanced features.

Task Deliverables:

• Paymaster implementation: Develop and test the paymaster that pays fees in wETH using the ApprovalBased flow.
• Documentation: Provide detailed documentation on how the paymaster works, how to integrate it, and any prerequisites required.
• Test Cases: Implement test cases to ensure the paymaster functions as expected and handles edge cases.
• Update readme: Update the readme to reflect new example.