clarity edit from adonesky1

Co-authored-by: Alex Donesky <alex.donesky@consensys.net>

CAIPs/caip-25.md

@@ -41,7 +41,7 @@ Each `scopeObject` in these arrays can be keyed to a specific [CAIP-2][] network
 An empty or absent `scopes` array SHOULD NOT be interpreted as a namespace-wide authorization (i.e. authorization for ANY network therein), but rather as a null authorization of 0 specified `chainId`s within that namespace.
 (See [CAIP-217][] for more details on the structure of the typed objects included in these arrays.)
 
-The distinction between `requiredScopes` and `optionalScopes` is ultimately semantic, since a wallet can still choose to establish a connection authorizing a subset of requested networks or requested capabilities on each; the primary function of the distinction is to offer callers a signaling mechanism for primary and secondary requests, to better inform the logic of the respondent.
+The distinction between `requiredScopes` and `optionalScopes` is ultimately semantic, since a wallet may still choose to establish a connection authorizing a subset of requested networks or requested capabilities from each; the primary function of the distinction is to offer callers a mechanism for signaling which scopes they consider primary and which they consider secondary to their request, in order to better inform the authorization logic of the respondent.
 
 If a connection is being rejected, whether on the basis of end-user input or on the basis of evaluating `requiredScopes` against available capabilities, the respondent SHOULD choose its response based on trust:
 e.g., one or more specific failure states MAY be sent (see [#### failure states](#failure-states) below) for trusted counterparties, but an `undefined` response (or no response, depending on implementation) MAY also be sent to prevent incentivizing unwanted requests and to minimize the surface for fingerprinting of public web traffic (See Privacy Considerations below).