When gas fee logic for a User Operation is being abstracted, it must contain a
The User Operation
paymasterAndData is simply a hex concatenation of two values:
- The paymaster address.
- Arbitrary data required by the Paymaster during
The data portion of
paymasterAndData has no enforced structure and can be encoded to include anything the paymaster contract requires to pass the validation phase. In the simplest case of a
VerifyingPaymaster.sol implementation, this would include 3 things:
validUntil: The latest time the paymaster will sponsor a User Operation at.
validAfter: The earliest time the paymaster will sponsor a User Operation at.
signature: A signature created by an external service that the paymaster trusts.
This data will be parsed and verified during
validatePaymasterUserOp. If the timestamps and signatures are valid, then they paymaster will accept to pay the User Operation gas. Further gas fee logic can be built on-top of this. For example, the external Paymaster service could have checked that the user has a valid subscription or payment method on file before signing the User Operation.
Note that this is only one example of how the
paymasterAndData could work. By not forcing a structure on the data we can enable more flexibility in use cases for gas fee abstraction.
Updated 12 days ago