Update EIP-5792: Fine-tune the "capability" rhetoric of EIP-5792 (plus non-normative wordsmithing as a bonus) #8396
Conversation
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
eth-bot
changed the title
|
marking as draft to prevent any auto-merging-- but ready for review! |
EIPS/eip-5792.md
Outdated
| The capabilities field is how an app can communicate with a wallet about capabilities a wallet supports. For example, this is where an app can specify a paymaster service URL from which an [ERC-4337](./eip-4337.md) wallet can request a `paymasterAndData` input for a user operation. | ||
| The optional `capabilities` property enable an app to grant to a wallet its own relevant capabilities as objects. For example, this is where an app can specify a paymaster service URL from which an [ERC-4337](./eip-4337.md) wallet can request a `paymasterAndData` input for a given user operation. |
There was a problem hiding this comment.
can we remove this change? think the original was more clear.
There was a problem hiding this comment.
please re-review after newest commit. here too an OCap diehard might want "grant" rather than "communicate"?
EIPS/eip-5792.md
Outdated
| For each chain on which a wallet can submit multiple calls atomically, the wallet SHOULD include an `atomicBatch` capability with a `supported` field equal to `true`. | ||
| For each chain on which a wallet can submit multiple calls atomically, the wallet SHOULD include an `atomicBatch` capability with a `supported` field equal to `true`. For each chain where it cannot, it SHOULD return the same field as `false`. Unspecified support for a given, named chain SHOULD be interpreted as not exposing this information to the application, and as such, applications SHOULD NOT interpret an absent value as equivalent to `false`. |
There was a problem hiding this comment.
i disagree with this. can we change to ...For each chain where it cannot, it MAY return the same field as 'false'. Unspecified support for a given, named chain SHOULD be interpreted as equivalent to 'false'.
i dont think the wallet should have to be so explicit about this
There was a problem hiding this comment.
Good point, I think this was worded badly. Please rereview after latest commit.
(Sidenote, if we are really going full OCap, would authorized make more sense than supported as the name for that boolean?)
|
tysm! |
|
bumblefudge:bumblefudge/wordsmithing-eip-5792 |
This PR:
wallet_getCapabilitiesRPC method to the END of the EIP, and adds a little guidance (some normative, some non-) for implementers to use it safely