Pluggable paymasters

[ediskandarov-cur]

Hi there,

I'm curious if it's possible to support 3rd party pluggable paymasters?

So that local communities can benefit from paymaster options better suitable for them.

[jhfnetboy]

Yeah, we have a plan to support the tertiary paymaster. SoulWallet wants to contribute an open-source wallet and modular components for the Ethereum ecosystem, not just a wallet. So, we should be composable.

[jayden-sudo]

Yes, we hope to achieve that as well. However, we are currently encountering some problems and hope to get some suggestions from you:

1. Different paymasters have different operational logics:
   1. The required gas is different, and this gas needs to be specified in advance. Therefore, the description file pointing to each paymaster needs to define a verificationGasLimit.
   2. Some paymasters depend on signature verification, and this signature logic needs to be defined in the description file so that the wallet frontend can sign according to the definition.
      1. Concerning signatures, one very important factor is security. The message that the paymaster needs to sign must not conflict with other possible signatures. Of course, a simple solution is that all paymaster signature messages must contain the {'paymastersign'}{paymasterAddress} data header.
      2. Another engineering implementation difficulty is changing the threshold of wallet frontend execution logic dynamically based on the description file. This is both for engineering feasibility and security. For example, consider whether to support only a few specific pre-supported signature formats for the paymaster.
   3. The frontend UI may encounter some difficulties, such as some paymasters collecting the user's tokens and converting them into ETH to pay for gas. The user must have the right to see the price of this paymaster collecting tokens in advance in the UI. This also requires a standard.

The mentioned "standard/description file" not only deals with contract-related details but also needs to define specific UI implementation (how to show token prices to users) and logic implementation (how the wallet frontend should interact with a centralized API if a paymaster relies on it).

[ediskandarov-cur]

How about allowing for dapps to set paymaster and paymaster data in advance? - bypassing wallet UI?

Use cases for this may vary. For instance, a web application subsidize fees for their users.
If a user has a specific NFT from the web application collection - then paymaster subsidizes the operation.

From tech perspective it may look like, the web application sends an unsigned user operation object with paymasterAndData field set to the wallet application(we need an extension of eip-1193 ?).

The wallet application behavior is defined in Client behavior upon receiving a UserOperation

The paymasterAndData is either empty, or start with the paymaster address, which is a contract that (i) currently has nonempty code on chain, (ii) has a sufficient deposit to pay for the UserOperation, and (iii) is not currently banned. During simulation, the paymaster’s stake is also checked, depending on its storage usage

In that case, paymasterAndData would only contain paymaster address and data would an empty string, because payment verification logic is in the paymaster contract, which only checks the owner has required NFT.

[jayden-sudo]

Yes, extending EIP-1193 is feasible (wallet clients can directly receive UserOp).
In addition, in the section 'Client behavior upon receiving a UserOperation', the 'client' should refer to the Bundler Client.