Auditing ERC-4337 Paymasters: Little Code, Big Risk

Transcript

All right. Hello everyone. My name is Reuben and I'm uh going to talk about ESC 4337 Pay Masters today. Um we've audited most of the heavily used Pay Masters out there. So um our client list includes Alchemy, Pimlicico, Trust Wallet, and many more. Um I want to give a mini overview over ERC 4337, but it's going to be extremely challenging in the time window. So basically, it's an additional abstraction layer on top of the Ethereum transactions. uh users no longer submit Ethereum transactions but so-called user operation strcts uh they send these to bundlers which bundle many of these user operations into a single Ethereum transaction with the target contract being the entry point and the

entry point is this canonical contract which basically uh orchestrates the validation phase and the execution phase of each user operation in the validation phase essentially the onchain interaction gets unlocked the account wants to do basically on the account side with a signature validation mainly and optionally in step three if a pay master is used the pay master validation is invoked followed in step four by the actual execution phase um where the on-chain interaction happens an optional posttop call after the execution phase and uh at the very end the bundler gets compensated either by the account or if a pay master was used by the pay master in order u compensated for putting the action on chain

um there's generally two types of payers So there's ERC20 token pay masters which enable user up inclusion in exchange for equivalent ERC20 token gas payment. Um and there's verifying pay masters which are usually used in sponsoring settings uh where just there where it's just an signature check being performed onchain uh after a series of offchain checks to determine if a user op is uh eligible to be uh sponsored. Think of for example like a launch campaign where some uh someone wants to sponsor all the gas cost with some D5 protocol. Um ERC20 token pay masters which are the ones I'm going to be mainly talking about have to ask themselves the question when to charge the user. So it will either be as

part of the validation phase in step three or as part of the posttop call in step five where they transfer out the tokens from the user to the pay master or to some other entity. Um naturally you would first think to do it in the posttop call um because that's actually when you know how much gas was being consumed. Um but uh there's some problems here because the posttop call is after the execution phase of the user operation. Uh and the exeu ex execution phase is inherently nondeterministic. A lot of restrictions are put in place in 4337 on the validation phase to have deterministic outcome of the validation phase. But that does not apply to the execution phase. In case uh the post op transfer would fail, the pay master

would still be required to pay because the validation has already passed. So if a user for example would revoke the approval as part of the execution phase, the pay master would not be compensated for the efforts. the pay master can roll back the execution phase of the user operation but still has to pay. So this is a very real gas griefing attack. Um and what's interesting is that the logic essentially uh or the error happens like within the context of 4337 and not so much in the logic of the smart contract code but requires the context of the standard. Um so you can also transfer in the validation phase which is a better approach because then you have guaranteed payment. Um however there's in total five user op gas limits based on the arrows I showed earlier. Um and

you have to nail the math between the gas limit ETH and then the ERC20 token conversion. So all the typical oracle and decimal issues apply we see in all audits and also on a side note I don't have time to go into this much but uh please do not revert due to stale Oracle data but encode it as part of the return validity window. If you have any questions on that send me a DM. I don't have time to talk about this more. Um, basically what you end up doing is you end up overcharging the user in the validation phase based on the gas limit specified. Um, uh, so basically you specify the maximum amount of gas a user operation can use and the actual usage might have been significantly lower than that. So you can return the excess change in the posttop call. Um, however,

you should be aware that there's an gas penalty of 10% of all the unused gas. That's basically the difference between the actual gas the user operation consumed and the limits that the user specified. And if the pay master does not account for that limit correctly, then it either ends up undercharging the user or overcharging the user. Either way, there's a financial loss happening there. There's many more I would have liked to talk about, but I'm extremely constrained on time. Uh, so here's a list. You can find most of these issues on our public audit uh website certificate.stant.com.

And also feel free to DM me on X or Telegram for more. >> Thank you so much. >> [applause]