Update ERC-7699: Update erc-7699.md - suggested minor fixes

Merged by EIP-Bot.

ERCS/erc-7699.md

@@ -49,15 +49,15 @@ These `transfer` and `transferFrom` functions, in addition to the standard trans
 
 The corresponding ERC-20 `Transfer` event MUST be emitted following the `TransferReference` event, ideally immediately afterwards for the client to be able to seek the associated `Transfer` event log record. 
 
-Emitted `loggedReference` MIGHT be the exact copy of the `transferReference` (when less then 33 bytes) or the derived data from the rich `transferReference` structure and other processing. This is up to the implementer. One MUST NOT expect the `transferReference` and `loggedReference` data are equal.
+Emitted `loggedReference` MAY be the exact copy of the `transferReference` (when less then 33 bytes) or the derived data from the rich `transferReference` structure and other processing. This is up to the implementer. One MUST NOT expect the `transferReference` and `loggedReference` data to be equal.
 
 The `loggedReference` parameter MAY contain any data of bytes32 type.
 
 The `transferReference` parameter MAY be empty. In this case and only in this case the `TransferReference` event MUST NOT be emitted, effectively mimicking the regular ERC-20 transfer without any transfer reference. 
 
 The `transferReference` parameter is not limited in length by design, users are motivated to keep it short due to calldata and execution gas costs.
 
-The `TransferReference` event MUST NOT be anonymous. This is to ensure that the event signature is logged and can be used as a filter.
+The `TransferReference` event MUST NOT be declared with the `anonymous` specifier. This is to ensure that the event signature is logged and can be used as a filter.
 
 Transfers of 0 amount MUST be treated as normal transfers and fire the `TransferReference` event alike.
 
@@ -195,7 +195,7 @@ contract ERC20TransferReference is ERC20, IERC7699 {
 
 ### Privacy Considerations
 
-Reference data privacy: Including payment references in token transfers may expose sensitive information about the transaction or the parties involved. Implementers and users SHOULD carefully consider the privacy implications and ensure that payment references do not reveal sensitive information. To mitigate this risk, implementers can consider using encryption or other privacy-enhancing techniques to protect payment reference data.
+Reference data privacy: Including payment references in token transfers may expose sensitive information about the transaction or the parties involved. Implementers and users should carefully consider the privacy implications and ensure that payment references do not reveal sensitive information. To mitigate this risk, implementers can consider using encryption or other privacy-enhancing techniques to protect payment reference data.
 
 Example: With reference 0x20240002 logged, transaction is publicly exposing that this is related to the second invoice of the recipient in 2024.