diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md
index 27db6fc8..2b61818f 100644
--- a/standard/ERCs/erc-6900.md
+++ b/standard/ERCs/erc-6900.md
@@ -533,11 +533,11 @@ Modular accounts support three different calls flows for validation: user op val
 
 For each of these validation types, an account implementation may specify its own format for selecting which validation function to use, as well as any per-hook data for validation hooks.
 
-Within the implementation of each type of validation function, the modular account MUST check that the provided validation function applies to the given function selector intended to be run. Then, the account MUST execute all pre validation hooks of the corresponding type associated with the validation function in use. These hooks MUST be executed in the order specified during installation. After the execution of pre validation hooks, the account MUST invoke the validation function of the corresponding type. If any pre validation hooks or the validation function revert, the account MUST revert. It SHOULD include the module's revert data within its revert data.
+Within the implementation of each type of validation function, the modular account MUST check that the provided validation function applies to the given function selector intended to be run. Then, the account MUST execute all validation hooks of the corresponding type associated with the validation function in use. These hooks MUST be executed in the order specified during installation. After the execution of validation hooks, the account MUST invoke the validation function of the corresponding type. If any validation hooks or the validation function revert, the account MUST revert. It SHOULD include the module's revert data within its revert data.
 
 The account MUST define a way to pass data separately for each validation hook and the validation function itself. This data MUST be sent as the `userOp.signature` field for user op validation, the `authorization` field for runtime validation, and the `signature` field for signature validation.
 
-The result of user op validation SHOULD be the intersection of time bounds returned by the pre validation hooks and the validation function. If any validation hooks or the validation functions returns a value of `1` for the authorizer field, indicating a signature verification failure by the ERC-4337 standard, the account MUST return a value of `1` for the authorizer portion of the validation data.
+The result of user op validation SHOULD be the intersection of time bounds returned by the validation hooks and the validation function. If any validation hooks or the validation functions returns a value of `1` for the authorizer field, indicating a signature verification failure by the ERC-4337 standard, the account MUST return a value of `1` for the authorizer portion of the validation data.
 
 The set of validation hooks run MUST be the hooks specified by account state at the start of validation. In other words, if the set of applicable hooks changes during validation, the original set of hooks MUST still run, and only future invocations of the same validation should reflect the changed set of hooks.
 
@@ -547,7 +547,7 @@ To enforce module permission isolation, the modular account MUST check validatio
 
 User op validation and runtime validation functions have a configurable range of applicability to functions on the account. This can be configured with selectors installed to a validation. Alternatively, a validation installation may specify the `isGlobal` flag as true, which means the account MUST consider it applicable to any module execution function with the `allowGlobalValidation` flag set to true, or for any account native function that the account MAY allow for global validation.
 
-If the selector being checked is `execute` or `executeBatch`, the modular account MUST perform additional checking. If the target of `execute` is the modular account's own address, validation MUST revert, to prevent privilege escalation. If the target of any `Call` within `executeBatch` is the account, the selector of the `Call` MUST also be checked to apply for the given validation. If the batch self-call's selector is again either `execute` or `executeBatch`, validation MUST revert, to prevent privilege escalation without requiring arbitrary-depth calldata decoding.
+If the selector being checked is `execute` or `executeBatch`, the modular account MUST perform additional checking. If the target of `execute` is the modular account's own address, or if the target of any `Call` within `executeBatch` is the account, validation MUST either revert, or check that validation applies to the selector(s) being called.
 
 Installed validations have two flag variables indicating what they may be used for. If a validation is attempted to be used for user op validation and the flag `isUserOpValidation` is set to false, validation MUST revert. If the validation is attempted to be used for signature validation and the flag `isSignatureValidation` is set to false, validation MUST revert.