feat: implement feedback

ERCS/erc-7579.md

@@ -1,7 +1,7 @@
 ---
 eip: 7579
 title: Minimal Modular Smart Accounts
-description: Minimally required interfaces and behavior for modular smart accounts and modules
+description: Modular smart account interfaces and behavior for interoperability with minimal standardization for accounts and modules
 author: zeroknots (@zeroknots), Konrad Kopp (@kopy-kat), Taek Lee (@leekt), Fil Makarov (@filmakarov), Elim Poon (@yaonam), Lyu Min (@rockmin216)
 discussions-to: https://ethereum-magicians.org/t/erc-7579-minimal-modular-smart-accounts/17336
 status: Draft
@@ -13,15 +13,17 @@ requires: 165, 1271, 2771, 4337
 
 ## Abstract
 
-This proposal outlines the minimally required interfaces and behavior for modular smart accounts and modules to ensure interoperability across implementations.
+This proposal outlines the minimally required interfaces and behavior for modular smart accounts and modules to ensure interoperability across implementations. For accounts, the standard specifies execution, config and fallback interfaces as well as compliance to [ERC-165](./eip-165.md) and [ERC-1271](./eip-1271.md). For modules, the standard specifies a core interface, module types and type-specific interfaces.
 
 ## Motivation
 
-Contract accounts are gaining adoption with many accounts being built using a modular architecture. These modular contract accounts (hereafter smart accounts) move functionality into external contracts (modules) in order to increase the speed and potential of innovation, to future-proof themselves and to allow customizability by developers and users. However, currently these smart accounts are built in vastly different ways, creating module fragmentation and vendor lock-in.
+Contract accounts are gaining adoption with many accounts being built using a modular architecture. These modular contract accounts (hereafter smart accounts) move functionality into external contracts (modules) in order to increase the speed and potential of innovation, to future-proof themselves and to allow customizability by developers and users. However, currently these smart accounts are built in vastly different ways, creating module fragmentation and vendor lock-in. There are several reasons for why standardizing smart accounts is very beneficial to the ecosystem, including:
 
-To solve these problems, we need to standardize the core interfaces for smart accounts and modules. However, it is highly important that this standardization is done with minimal impact on the implementation logic of the accounts, so that smart account vendors can continue to innovate, while also allowing a flourishing, multi-account-compatible module ecosystem.
+- Interoperability for modules to be used across different smart accounts
+- Interoperability for smart accounts to be used across different wallet applications and sdks
+- Preventing significant vendor lock-in for smart account users
 
-The goal of this standard is to define the smart account and module interfaces and behavior that is as minimal as possible while ensuring interoperability between accounts and modules.
+However, it is highly important that this standardization is done with minimal impact on the implementation logic of the accounts, so that smart account vendors can continue to innovate, while also allowing a flourishing, multi-account-compatible module ecosystem. As a result, the goal of this standard is to define the smart account and module interfaces and behavior that is as minimal as possible while ensuring interoperability between accounts and modules.
 
 ## Specification
 
@@ -112,7 +114,7 @@ interface IExecutionUnsafe {
 
 To comply with this standard, smart accounts MUST implement the entire interface below. If an account implementation elects to not support any of the configuration methods, it MUST revert, in order to avoid unpredictable behavior with fallbacks.
 
-When installing or uninstalling a module on a smart account, the smart account
+When installing or uninstalling a module on a smart account, the smart account:
 
 - MUST enforce authorization control on the relevant install or uninstall function for the module type
 - MUST call the relevant `onInstall` or `onUninstall` function on the module
@@ -184,9 +186,9 @@ interface IAccountConfig_Hook {
 }
 ```
 
-#### [ERC-1271](./eip-1271.md) Forwarding
+#### ERC-1271 Forwarding
 
-The smart account MUST implement the [ERC-1271](./eip-1271.md) interface. The `isValidSignature` function calls MAY be forwarded to a validator. If ERC-1271 forwarding is implemented, the validator MUST be called with `isValidSignatureWithSender(address sender, bytes32 hash, bytes signature)`, where the sender is the `msg.sender` of the call to the smart account.
+The smart account MUST implement the ERC-1271 interface. The `isValidSignature` function calls MAY be forwarded to a validator. If ERC-1271 forwarding is implemented, the validator MUST be called with `isValidSignatureWithSender(address sender, bytes32 hash, bytes signature)`, where the sender is the `msg.sender` of the call to the smart account.
 
 Should the smart account implement any validator selection encoding in the `bytes signature` parameter, the smart account MUST sanitize the parameter, before forwarding it to the validator.
 
@@ -202,9 +204,9 @@ If the smart account has a fallback handler installed, it:
 - MUST use `call` 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
 
-#### [ERC-165](./eip-165.md)
+#### ERC-165
 
-Smart accounts MUST implement [ERC-165](./eip-165.md). However, for every interface function that reverts instead of implementing the functionality, the smart account MUST return `false` for the corresponding interface id.
+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.
 
 ### Modules
 
@@ -280,14 +282,6 @@ interface IHook {
 
 ## Rationale
 
-### Standardization
-
-As mentioned above, there are several reasons for why standardizing smart accounts is very beneficial to the ecosystem. The most important of these are:
-
-- Interoperability for modules to be used across different smart accounts
-- Interoperability for smart accounts to be used across different wallet applications and sdks
-- Preventing significant vendor lock-in for smart account users
-
 ### Minimal approach
 
 Smart accounts are a new concept and we are still learning about the best ways to build them. Therefore, we should not be too opinionated about how they are built. Instead, we should define the most minimal interfaces that allow for interoperability between smart accounts and modules to be used across different account implementations.
@@ -333,7 +327,7 @@ Smart accounts that have already been deployed will most likely be able to imple
 
 ## Reference Implementation
 
-A full interface of a smart account can be found in [`IMSA.sol`](../assets/eip-7579/IMSA.sol). A reference implementation will follow soon.
+A full interface of a smart account can be found in [`IMSA.sol`](../assets/eip-7579/IMSA.sol).
 
 ## Security Considerations
 

assets/erc-7579/IMSA.sol

@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: MIT
+// SPDX-License-Identifier: CC0-1.0
 pragma solidity ^0.8.21;
 
 /**
@@ -25,11 +25,7 @@ interface IExecution {
      * @param callData The call data to be sent to the contract.
      * @return result The return data of the executed contract call.
      */
-    function execute(
-        address target,
-        uint256 value,
-        bytes calldata callData
-    )
+    function execute(address target, uint256 value, bytes calldata callData)
         external
         payable
         returns (bytes memory result);
@@ -44,10 +40,7 @@ interface IExecution {
      * @param executions An array of struct Execution (address target, uint value, bytes callData)
      * @return results The return data of the executed contract call.
      */
-    function executeBatch(Execution[] calldata executions)
-        external
-        payable
-        returns (bytes[] memory results);
+    function executeBatch(Execution[] calldata executions) external payable returns (bytes[] memory results);
 
     /**
      *
@@ -60,11 +53,7 @@ interface IExecution {
      * @param callData The call data to be sent to the contract.
      * @return result The return data of the executed contract call.
      */
-    function executeFromExecutor(
-        address target,
-        uint256 value,
-        bytes calldata callData
-    )
+    function executeFromExecutor(address target, uint256 value, bytes calldata callData)
         external
         payable
         returns (bytes memory);
@@ -102,10 +91,7 @@ interface IExecutionUnsafe {
      * @param callData The call data to be sent to the contract.
      * @return result The return data of the executed contract call.
      */
-    function executeDelegateCall(
-        address target,
-        bytes calldata callData
-    )
+    function executeDelegateCall(address target, bytes calldata callData)
         external
         payable
         returns (bytes memory result);
@@ -123,10 +109,7 @@ interface IExecutionUnsafe {
      * @param callData The call data to be sent to the contract.
      * @return result The return data of the executed contract call.
      */
-    function executeDelegateCallFromExecutor(
-        address target,
-        bytes memory callData
-    )
+    function executeDelegateCallFromExecutor(address target, bytes memory callData)
         external
         payable // gas bad
         returns (bytes memory result);