Update ERC-6900: wording simplification and corrections

Merged by EIP-Bot.

ERCS/erc-6900.md

@@ -463,17 +463,10 @@ interface IExecutionHookModule is IModule {
 }
 ```
 
-### Validation Functions and Their Installation/Uninstallation
-
-- An account can have more than one validation module/function installed.
-- An account can have the same validation module installed more than once.
-- The entity ID of a validation function installed on an account MUST be unique.
-- Validation installation MAY be deferred until a later time, such as upon first use.
+### Validation Functions
 
 #### Installation
 
-During validation installation, the account MUST correctly set flags and other fields based on the incoming data provided by the user.
-
 - The account MUST install all validation hooks specified by the user and SHOULD call `onInstall` with the user-provided data on the hook module to initialize state if specified by the user.
 - The account MUST install all execution hooks specified by the user and SHOULD call `onInstall` with the user-provided data on the hook module to initialize state if specified by the user.
 - The account MUST configure the validation function to validate all of the selectors specified by the user.
@@ -492,17 +485,13 @@ During validation uninstallation, the account MUST correctly clear flags and oth
 - The account SHOULD call `onUninstall` on the validation module to clean up state if specified by the user.
 - The account MUST emit `ValidationUninstalled` as defined in the interface for all uninstalled validation functions.
 
-### Execution Functions and Their Installation/Uninstallation
-
-- An account can install any number of execution functions.
-- An execution function selector MUST be unique in the account.
-- An execution function selector MUST not conflict with native ERC-4337 and ERC-6900 functions.
+### Execution Functions
 
 #### Installation
 
-During execution installation, the account MUST correctly set flags and other fields based on the incoming data and module manifest provided by the user.
-
 - The account MUST install all execution functions and set flags and fields as specified in the manifest.
+    - An execution function selector MUST be unique in the account.
+    - An execution function selector MUST not conflict with native ERC-4337 and ERC-6900 functions.
 - The account MUST add all execution hooks as specified in the manifest.
 - The account SHOULD add all supported interfaces as specified in the manifest.
 - The account SHOULD call `onInstall` on the execution module to initialize state if specified by the user.
@@ -524,10 +513,10 @@ During execution uninstallation, the account MUST correctly clear flags and othe
 
 For accounts that implement execution hooks, accounts MUST conform to these execution hook formats:
 
-1. For `executeUserOp` calls, for execution hooks associated with a validation function, accounts MUST send the full `msg.data`, including the `executeUserOp` selector.
+1. For `executeUserOp` calls, for execution hooks associated with a validation function, accounts MUST send the full calldata (`msg.data` in solidity), including the `executeUserOp` selector.
 2. For `executeUserOp` calls, for execution hooks associated with a selector, accounts MUST send `PackedUserOperation.callData` for `executeUserOp` calls, excluding `executeUserOp.selector` and the rest of the `PackedUserOperation`.
-3. For `executeWithRuntimeValidation` calls, for all execution hooks, accounts MUST send the inner `data`.
-4. For all other calls, for execution hooks associated with a selector, accounts MUST send over `msg.data`.
+3. For `executeWithRuntimeValidation` calls, for all execution hooks, accounts MUST send the inner `data` field.
+4. For all other calls, for execution hooks associated with a selector, accounts MUST send over the full calldata (`msg.data` in solidity).
 
 #### Hook Execution Order
 
@@ -541,9 +530,9 @@ For each of these validation types, an account implementation MAY specify its ow
 
 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 (See [Checking Validation Applicability](#checking-validation-applicability)). Then, the account MUST execute all validation hooks of the corresponding type associated with the validation function in use. After the execution of validation hooks, the account MUST invoke the validation function of the corresponding type. If any of the validation hooks or the validation function reverts, 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 account MUST define a way to pass data separately for each validation hook and the validation function itself. This data SHOULD 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 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 MUST 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.