Update ERC-7579: specify executeFromExecutor return data type

Merged by EIP-Bot.

ERCS/erc-7579.md

@@ -68,6 +68,8 @@ interface IExecution {
      * @param mode The encoded execution mode of the transaction.
      * @param executionCalldata The encoded execution call data.
      *
+     * @return returnData An array with the returned data of each executed subcall
+     *
      * MUST ensure adequate authorization control: i.e. onlyExecutorModule
      * If a mode is requested that is not supported by the Account, it MUST revert
      */
@@ -91,9 +93,10 @@ The account MAY also implement the following function in accordance with ERC-433
 function executeUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash) external;
 ```
 
-If an account chooses to implement `executeUserOp`, this method SHOULD ensure the account executes `userOp.calldata` except 4 most significant bytes, which are reserved for `executeUserOp.selector` as per ERC-4337. Thus the `userOp.callData[4:]` should represent the calldata for a valid call to the account. It is RECOMMENDED that the account executes a `delegatecall` in order to preserve the original `msg.sender` to the account. 
+If an account chooses to implement `executeUserOp`, this method SHOULD ensure the account executes `userOp.calldata` except 4 most significant bytes, which are reserved for `executeUserOp.selector` as per ERC-4337. Thus the `userOp.callData[4:]` should represent the calldata for a valid call to the account. It is RECOMMENDED that the account executes a `delegatecall` in order to preserve the original `msg.sender` to the account.
 
 Example:
+
 ```
 (bool success, bytes memory innerCallRet) = address(this).delegatecall(userOp.callData[4:]);
 ```
@@ -228,7 +231,7 @@ If the smart account has a fallback handler installed, it:
 - MUST use `call` or `staticcall` to invoke the fallback handler
 - MUST utilize [ERC-2771](./eip-2771.md) to add the original `msg.sender` to the `calldata` sent to the fallback handler
 - MUST route to fallback handlers based on the function selector of the calldata
-- MAY implement authorization control, which SHOULD be done via hooks 
+- MAY implement authorization control, which SHOULD be done via hooks
 
 If the account adds features via fallback, these should be considered the same as if the account was implementing those features natively.
 ERC-165 support (see below) is one example of such an approach. Note, that it is only RECOMMENDED to implement view functions via fallback where this can lead to greater extensibility. It is NOT RECOMMENDED to implement core account logic via a fallback.
@@ -280,6 +283,7 @@ interface IModule {
 
 Note: A single module that is of multiple types MAY decide to pass `moduleTypeId` inside `data` to `onInstall` and/or `onUninstall` methods, so those methods are able to properly handle installation/uninstallation for various types.  
 Example:
+
 ```solidity
 // Module.sol
 function onInstall(bytes calldata data) external {
@@ -367,7 +371,7 @@ Our approach has been twofold:
 
 ### Extensions
 
-While we want to be minimal, we also want to allow for innovation and opinionated features. Some of these features might also need to be standardized (for similar reasons as the core interfaces) even if not all smart accounts will implement them. To ensure that this is possible, we suggest for future standardization efforts to be done as extensions to this standard. This means that the core interfaces will not change, but that new interfaces can be added as extensions. These should be proposed as separate ERCs, for example with the title `[FEATURE] Extension for ERC-7579`.
+While we want to be minimal, we also want to allow for innovation and opinionated features. Some of these features might also need to be standardized (for similar reasons as the core interfaces) even if not all smart accounts will implement them. To ensure that this is possible, we suggest for future standardization efforts to be done as extensions to this standard. This means that the core interfaces will not change, but that new interfaces can be added as extensions. These should be proposed as separate ERCs, for example with the title "[FEATURE] Extension for [ERC-7579](./eip-7579.md)".
 
 ### Specification