Thread to discuss ERC-7677.
1 Like
Great work on the ERC. At Stackup we’ve been huge advocates for standardisng the Paymaster API. We’ve also thought about what a standardised paymaster API could look like and derived something similar on a high level. Here are some additional thoughts that might also be worth considering.
Removing chainId in method parameters
Have we considered alternatively including a method like pm_chainId or even eth_chainId rather than specifying it in the method parameters?
Requiring a chainId input assumes that the service is multi chain at the method level which breaks consistency with other infrastructure components (e.g. bundlers and nodes). Having eth_chainId may also be ideal since it allows compatibility for a paymaster RPC URL to be used with tools like viem and ethers that will typically call eth_chainId to detect network.
Applications can use different API keys provided by the Paymaster service to route to the relevant network which is the current standard pattern for bundler and node providers.
Challenges with preVerificationGas (pvg)
Generally speaking, I think creating two seperate methods for stub and final paymasterAndData (pnd) makes sense. Although worth calling out some challenges with this approach.
It can be pretty easy for an incorrectly implemented stub to result in an inufficient pvg error due to differences between stub and final pnd. Keeping the length equal in both cases is easy enough. But if for instance, the stub has more zero bytes (0x00) than the final, this will cause upstream problems like an insufficient pvg error.
This was one reason why the current version of Stackup’s pm_sponsorUserOperation also returns gas estimates. Additionally, we also had concerns on wether this flow of making an intermediate dummy pnd value public would be considered a bad API design due to leaky abstraction.
Defined types on the context
Leaving the context open allows for the most amount of flexibility, but have we also considered what a standard context interface could look like based on common paymaster usecases? This might be worth exploring even if they are optional or defined for the simpler use cases since we could reduce even more ambiguity for developers who want to integrate multiple providers.
Adding pm_getAddresses
This should be added to easily link a paymaster service to its canonical onchain contract. The application would need to know this if it is required to encode callData that requires the paymaster’s contract address (e.g. ERC-20 approvals).
This would also allow the paymasters to cleanly rotate their contracts without breaking downstream applications who would otherwise need to hardcode addresses.
Adding pm_quotes
This is useful if a paymaster deals with multiple currencies. For instance, if multiple paymasters are accepting payment in an alternative ERC-20 token, it’s useful for a paymaster to provide quotes for the application to compare against before deciding which service to go with.
Even if the Paymaster service is accepting compensation in non-crypto assets that are settled off-chain (e.g. USD, EURO, etc) it could be valuable to also return these exchange rates too.
Should the ## Rationale section be more detailed or explicit here? I’m generally in support of verbose rationales and non-normative implementer guidelines, tag me if you open a PR on those.
Is this a question for the spec or for reference implementations linked to from the spec? I can imagine reference implementations modeling good behavior by describing the shape and semantics of its Context property in their readme files for quick reference? Not sure if the spec should tell anyone they SHOULD do that, though?
One man’s breakage is another man’s upgrade path 
All joking aside, I think the co-authors of this proposal have discussed the breakage and are OK with it. Would more ## Rationale help here as well?
I think defining a few context types in a reference implementation could be a good start. Especially for common use cases like “sponsor” (PM sponsors the gas and any compensation is handled offchain between application and provider) or “erc20”.
Otherwise I could potentially see how this becomes the main friction point for an application to onboard multiple providers when all of them have slightly different context requirements for essentially the same use case.
Definitely agree this should be added to the rationale. If this is intended to be an upgrade path, I would also like to know what the end goal is? To also play devil’s advocate, does it make sense to include it in this ERC rather than maintaining the status quo and pushing for that in different proposal?
Removing
chainIdin method parameters
I think we agree that we need to specify some constraint that allows for wallets to communicate with the paymaster service about intended chain id. As I see it we have 2 options:
- Require a chain id as part of paymaster service requests (as is specified in the current ERC draft)
- Require that paymaster service URLs are for a single chain (the current loose standard)
In my opinion, option (1) is the correct place for this abstraction. Option (2) seems like an odd constraint to put on service providers. What if someone wants to architect their services such that a single URL can be multichain? Option (1) allows for that with pretty much no downside to providers who use a single URL per chain, they would just need to accept an additional parameter that they can ignore. When an app developer who uses a URL-per-chain provider wants to submit a request to a different chain, they can just swap out the URL accordingly.
Given this, I don’t think I understand the need for the pm_chainId method (or maybe that is a separate point).
Defined types on the
context
Your point on developers integrating multiple providers is interesting, and one I hadn’t considered. My gut feeling is that providers will want to offer too many different additional services-with equally many different abstractions-for this to be feasible. But maybe I haven’t explored here enough, will do some more asking around.
Adding
pm_getAddresses
I admittedly am not as familiar with ERC-20 paymaster flows, but this sounds useful. Is the ERC-20 flow you’re describing the main use case here? Or can you think of other use cases where a wallet would need this information? In any case I’ll read more on the ERC-20 flow and report back with more of an opinion.
Adding
pm_quotes
This seems like a pretty advanced use case and my gut feeling is that this shouldn’t be part of this initial proposal for paymaster service standardization. But again let me read up some more on the ERC-20 flow and maybe will feel differently.
1 Like
I agree it does increase the complexity of the spec. But given a few assumptions I think a case for it could be made. Put aside the ERC-20 use case for a moment and consider a simpler example of a paymaster sponsoring gas for an application and any compensation is settled off-chain in USD.
Assumptions being:
- Applications will want to integrate multiple paymasters for redundancy.
- Applications will want to be able to make comparisons between providers to lock in optimal gas prices.
- Paymaster’s are likely adding a fee for providing their service which can come in the form of a percentage added to the exchange rate of ETH to USD.
Given those conditions, something like pm_quotes allows for a flow where an application can programmatically decide on the best provider based on who is offering the most competitive exchange rate. At Stackup we’ve also worked with wallet teams that are in production who have these exact requirements.
That’s a fair point too and would agree that it may just be too early to converge on a few well defined context types right now. This is probably something worth initially exploring within a reference implementation as @bumblefudge mentioned above.
Yes, in practice the ERC-20 example has been the main use case. Although another use case I can think of is for any indexer that needs to link a paymaster address from a UserOperationEvent back to a known provider.
The more I think about this the more I feel that it should not be included as part of this ERC. I understand the use case and could definitely see it as its own proposal. The goal here is to define the standard necessary for app developers to sponsor their users’ transactions, so ultimately pm_quotes seems out of scope.
pm_getAddresses seems pretty necessary, we can add this.
Great work on the ERC.
Good to see that paymaster API standardization. It was also a topic we at TrustWallet strongly suggested and discussed with Dror and Tom at Denver as well.
Here are some of the thoughts that might be worth being considered:
- The initial architecture(image below) without the Backend of the app validating the UserOp is very dangerous. It will make the fund drain quickly - I think it will be insecure for real world case.
- To have the above model, I think it would be better for the standard to clearly suggest that validation should happen at the Paymaster Serivce level.
- Using a separate gas estimation call without using the paymaster’s estimation. I think the reality atm is that wallets rely on Bundlers/Paymasters for gas estimation of UserOperation. I think there is a room more more consideration whether relying on Wallets for gas estimation actually enhances the efficiency/accuracy.
It has the drawback of making multiple more API calls and interaction just for this.
- there might be risks for Paymasters if they approve for UserOp that doesn’t know how much gas it will consume.
- This will be simplified if the Paymaster just return the gas estimation
But I still understand the point that it potentially provides more options from Wallet perspective, but the trade-offs should be considered - both from Efficiency, Security, Accuracy perspective.
- I understand this standard enforces EIP 5792 for communication, but I think this doesn’t have to be fully bound to that. It can be done much simpler(e.g., injecting js object for wallets to detect, etc)