Update EIP-5792: Fine-tune the "capability" rhetoric of EIP-5792 (plus non-normative wordsmithing as a bonus)

EIPS/eip-5792.md

@@ -36,7 +36,7 @@ We also define one capability expression for use with the fourth method, which f
 
 Requests that a wallet submits a batch of calls. `from` and `chainId` are top-level properties rather than per-call properties because all calls should be sent from the same sender and on the same chain, identified by [EIP-155](./eip-155.md) integers expressed in hexidecimal notation. The items in the `calls` field are only those that are shared by all transaction types. Any other fields that a wallet may need to submit a transaction should be handled by the wallet.
 
-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.
+The capabilities field is how an app can communicate with a wallet about its own capabilities, which a wallet may or may not support. 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 if the wallet supports that kind of paymaster service.
 
 The wallet:
 
@@ -256,9 +256,9 @@ type AtomicBatchCapability = {
 };
 ```
 
-The only valid JSON-RPC values for this capability are `true` or `false`; if a returned value for "supported" value is typed as a string or number, it SHOULD be treated as malformed.
+The only valid JSON-RPC values for this capability's only member, `supported`, are `true` or `false`; if a returned value for `supported` is typed as a string or number, it SHOULD be considered malformed.
 
-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`.
+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` to authorize the caller to use this capability. For each chain where it cannot, it MAY return the same field as `false`, or MAY return no capability object at all. An application SHOULD NOT interpret any `atomicBatch` object as an authorization without a `supported` of `true`.
 
 #### `wallet_getCapabilities` Example Return Value including `atomicBatch`
 
@@ -288,7 +288,7 @@ We also debated whether the methods should be called `wallet_sendTransaction`, `
 
 The `wallet_sendCalls` method accepts an array of `calls`. However, this proposal does not require that these calls be executed as part of a single transaction. It enables EOA wallets to accept multiple calls as well over the same interface. That said, we expect that in some cases app developers might want to submit batched calls if and only if they will be executed atomically. This would reduce the number of error cases an app developer would need to handle, while still contributing to the unification over time of interfaces across wallets types.
 
-We initially proposed that multiple calls be executed atomically, but after some debate we ultimately decided this was too opinionated. Instead, we are including a specification for an `atomicBatch` capability. This allows for EOA wallets to accept multiple calls and still gives developers the option to only submit batched calls if they are executed atomically.
+We initially proposed that multiple calls must be executed atomically, but after some debate we ultimately decided this was too opinionated. Instead, we are including a specification for an `atomicBatch` capability. This allows for EOA wallets to accept multiple calls and still gives developers the option to only submit batched calls if they are executed atomically.
 
 ### Call Gas Limit