Update ERC-7579: executeUserOp + multitype module onInstall/onUninstall

Merged by EIP-Bot.

ERCS/erc-7579.md

@@ -91,6 +91,13 @@ 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. 
+
+Example:
+```
+(bool success, bytes memory innerCallRet) = address(this).delegatecall(userOp.callData[4:]);
+```
+
 The execution mode is a `bytes32` value that is structured as follows:
 
 - callType (1 byte): `0x00` for a single `call`, `0x01` for a batch `call`, `0xfe` for `staticcall` and `0xff` for `delegatecall`
@@ -223,6 +230,9 @@ If the smart account has a fallback handler installed, it:
 - MUST route to fallback handlers based on the function selector of the calldata
 - 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.
+
 #### ERC-165
 
 Smart accounts MUST implement ERC-165. However, for every interface function that reverts instead of implementing the functionality, the smart account MUST return `false` for the corresponding interface id.
@@ -268,6 +278,17 @@ 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 {
+    // ...
+    (uint256 moduleTypeId, bytes memory otherData) = abi.decode(data, (uint256, bytes));
+    // ...
+}
+```
+
 #### Validators
 
 Validators MUST implement the `IModule` and the `IValidator` interface and have module type id: `1`.