ERC-7677: Paymaster Web Service Capability

[lsr]

Hey, thanks for your reply!

@DavidKim

1. 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.

Yeah we allude to this in the security considerations section but can make it more explicit. Will add something more clear to the spec.

@DavidKim

2. 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.

In practice we found that paymaster services were just not reliable enough to provide gas estimations. The wallet ultimately knows which bundler will be used to submit user ops, so gas estimates should come from that bundler to provide the most accurate gas estimates. This is not just a design opinion either, the paymaster services providing insufficient gas estimates completely blocks successfully submitting user ops. Therefore I believe the flow in the spec is a must. Happy to discuss if you have something else in mind though.

@DavidKim

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)

I wouldn’t say this enforces EIP-5792 for communication. Anyone is free to suggest other proposals for initiating this flow . I can imagine other use cases for the paymaster RPC methods, and I’m sure there could be other ways to go about this from the wallet’s perspective. This proposal is just focused on the EIP-5792 approach.