Repository navigation
Add ERC: Paymaster Web Service Capability - #360
Conversation
|
✅ All reviewers have approved. |
eip-review-bot
changed the title
|
The commit cfc41e4 (as a parent of 45e5f03) contains errors. |
7614e96 to
d90e25f
Compare
…nale Expand rationale to include known challenges with stub data
| } | ||
| ``` | ||
|
|
||
| ###### `pm_getPaymasterData` Example Parameters |
There was a problem hiding this comment.
Paymaster services are supposed to detect which account implementation is it from the sender's address?
otherwise how would one decode data based on policy-id?
There was a problem hiding this comment.
detecting the account implementation is not a strict requirement of paymaster services, and it is ultimately up to paymaster services to decide how to validate policy ids or whatever other abstractions they might have.
you could reliably do this without needing to know the implementation though by simulating the incoming user op, no need to decode the calldata (although you could if you know the implementation).
There was a problem hiding this comment.
Shouldn't this be a requirement as it is mentioned that
Paymaster services MUST detect which entrypoint version the account is using and return the correct fields.
how is a paymaster supposed to detect this without knowing the account implementation?
Afaik all smart accounts store the supported entry point on the smart account in a simple variable and reading that might be the best way to know this information.
To make that possible I think the paymaster services should have some knowledge about the implementation
There was a problem hiding this comment.
paymaster knows the version from the entrypoint address (in any case, a paymaster support explicit entrypoint instance, not "any".
it would still be nice if at the API level a "version" field is added..
| type GetPaymasterStubDataParams = [ | ||
| // Below is specific to Entrypoint v0.6 but this API can be used with other entrypoint versions too | ||
| { | ||
| sender: `0x${string}`; |
There was a problem hiding this comment.
these are the fields of UserOperation v0.6.
On v0.7, there are few differences (factory, factoryData, paymaster fields, packed gas fields).
There was a problem hiding this comment.
right, called out in the comment but can add the v0.7 fields to make it more clear that this is for any entrypoint version
| maxFeePerGas: `0x${string}`; | ||
| maxPriorityFeePerGas: `0x${string}`; | ||
| }, // userOp | ||
| `0x${string}`, // EntryPoint |
There was a problem hiding this comment.
it is better to have named parameters instead of indexed.
e.g.
{ userOp: {}, chainId: "0x..", entryPoint: "0x...", version: "0.7", context: {} }And also be better to add "version", instead of rely on entrypoint address
There was a problem hiding this comment.
curious about your reasoning here. i like the clarity of named arguments but most ethereum-related JSON-RPC methods i can think of use positional arguments. is there a reason you think we should stray from that loose convention other than clarity?
There was a problem hiding this comment.
same question for the version arg, is that just for clarity?
| "paymaster": "0x...", | ||
| "paymasterData": "0x...", | ||
| "paymasterVerificationGasLimit": "0x...", | ||
| "paymasterPostOpGasLimit": "0x..." |
There was a problem hiding this comment.
in v0.7, postOpGasLimit cannot be estimated by app/wallet, and must be returned by the serve
verificationGasLimit MAY be estimated, though if the service knows the value, it can place it anyway.
| } | ||
| ``` | ||
|
|
||
| ###### `pm_getPaymasterData` Example Parameters |
There was a problem hiding this comment.
paymaster knows the version from the entrypoint address (in any case, a paymaster support explicit entrypoint instance, not "any".
it would still be nice if at the API level a "version" field is added..
|
|
||
| ```json | ||
| { | ||
| "paymaster": "0x...", |
There was a problem hiding this comment.
There are cases where the stub/final separation is not needed, e.g: when the paymaster is a TokenPaymaster, and the paymasterData doesn't contain "signature".
In such cases, the 2nd RPC call to the paymaster MAY be skipped, by returning isFinal: true by this RPC call.
|
|
||
| Returns values to be used in paymaster-related fields of a signed user operation. These are not stub values and will be used during user operation submission to a bundler. Similar to `pm_getPaymasterStubData`, accepts an unsigned user operation, entrypoint address, chain id, and a context object. | ||
|
|
||
| This method also returns a `sponsor` object with `name` and `icon` fields. The `name` field is the name of the party sponsoring the transaction, and the `icon` field is a URI pointing to an image. Wallet developers MAY choose to display sponsor information to users. The `icon` string MUST be a data URI as defined in [RFC-2397]. The image SHOULD be a square with 96x96px minimum resolution. The image format is RECOMMENDED to be either lossless or vector based such as PNG, WebP or SVG to make the image easy to render on the wallet. Since SVG images can execute Javascript, wallets MUST render SVG images using the `<img>` tag to ensure no untrusted Javascript execution can occur. |
There was a problem hiding this comment.
is the sponsor structure a "MUST" ?
There was a problem hiding this comment.
it is not a "MUST". will clarify.
| maxPriorityFeePerGas: `0x${string}`; | ||
| }, // userOp | ||
| `0x${string}`, // EntryPoint | ||
| `0x${string}`, // Chain ID |
There was a problem hiding this comment.
Is there a specific reason, to prefix 0x in front of chainId, instead of plain string or a number?
There was a problem hiding this comment.
chain ids are uint256 so all possible values could not be represented by a js number, and hex is pretty standardized in such cases vs the number as a decimal string
There was a problem hiding this comment.
If you can replace these with SVGs, we'd appreciate it
eip-review-bot
left a comment
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
15 participants
Defines an EIP-5792 capability for paymaster web services along with a proposal for standardized paymaster web service RPC methods.
https://ethereum-magicians.org/t/add-erc-paymaster-web-service-capability/19530