a few more grammar changes post-edits

EIPS/eip-5630.md

@@ -17,7 +17,7 @@ This EIP proposes a new way to encrypt and decrypt using Ethereum keys. This EIP
 
 ## Motivation
 
-To that discussion, we add a few further motivating examples. In a certain common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain).
+We discuss a few motivating examples. In a certain common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain).
 
 This design pattern allows the dApp/user to bootstrap the security of the _fresh_ secret onto the security of the user's existing HD wallet seed phrase, which the user has already gone through the trouble of safeguarding and storing. This represents a far lower UX burden than forcing the user to store and manage fresh keys directly (which can, and often does, lead to loss of funds). We note that this _exact_ design pattern described above is used today by, e.g., Tornado Cash.
 
@@ -74,7 +74,7 @@ request({
 
 where `account` is as above, and `encryptedMessage` is a JSON object with the properties `version` (an arbitrary string) and `ciphertext` (a `0x`-prefixed, hex-encoded, bytes-like string), the client should operate as follows:
  - perform a `switch` on the value `encryptedMessage.version`. if it equals:
-   - `x25519-xsalsa20-poly1305`, then use [#1098]'s specification;
+   - `x25519-xsalsa20-poly1305`, then use #1098's specification;
    - `secp256k1-sha512kdf-aes256cbc-hmacsha256`, then proceed as described below;
    - if it equals neither, throw an error.
  - find the secret key `sk` corresponding to the Ethereum account `account`, or else return an error if none exists.
@@ -92,7 +92,7 @@ Though this result provides _some level of_ assurance of security of this joint
 ## Backwards Compatibility
 The previous proposal stipulated that encryption and decryption requests contain a `version` string. Our proposal merely adds a case for this string; encryption and decryption requests under the existing scheme will be handled identically. Unfortunately, the previous proposal did _not_ include a version string in `encryptionPublicKey`, and merely returned the `ec25519` public key directly as a string. We thus propose to immediately return the `secp256k1` public key, overwriting the previous behavior. The old behavior can be kept via a legacy method.
 
-We note that other EIPs are _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate.
+We note that the previous EIP is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate.
 
 ### Test Cases