Title: ERC_7579__Minimal_Modular_Smart_Accounts
Category: ERCs

Author: kopykat
Date: 2023-12-14T20:02:42.553Z

Discussion for Add ERC: Minimal Modular Smart Accounts by zeroknots · Pull Request #163 · ethereum/ERCs · GitHub.
The  proposal outlines the minimally required interfaces and behavior for modular smart accounts and modules to ensure interoperability across implementations.

Author: Aboudjem
Date: 2023-12-16T18:02:11.844Z

Hey @kopykat 
Nice work on ERC-7579, I’ve opened a PR proposing a few enhancements aimed at boosting its adaptability and future-proofing the standard:

Added a function for dynamic module type identification: function getModuleTypes(address module) external view returns (uint256[]);.
Added guidelines for module state management during installation and uninstallation.
Emphasized the importance of having at least one active Validation Module for security.
Suggested standardized procedures for module installation/uninstallation.

I have a couple of questions:

Are module types in ERC-7579 meant to be fixed, or could we consider making them more flexible for future module types?
What might be the limitations of adopting a less specific approach to module types?

Author: jhfnetboy
Date: 2023-12-17T04:51:31.884Z

Great job!
It is a good idea to build an extensible model on a minimal modular contract account!
I will follow this discussion.
Thanks!

Author: kopykat
Date: 2023-12-17T10:35:32.083Z

Thanks, I have left some comments on the pr.
To your questions:

What do you mean by fixed? The module types ids already assigned should not be reused and the modules defined should not be given new ids. However, our intention is that if there are further module types in the future then extensions to ERC-7579 should define the next module type ids as the next available integer (eg 5 currently). I see that this is not actually clearly stated in the standard so this is something we could add for further clarity
What do you mean by less specific approach to module types?

Author: Aboudjem
Date: 2023-12-17T14:47:54.892Z

Thanks @kopykat.


By ‘fixed’ I meant whether the module types are rigidly set in the standard or if there’s room for adding new types dynamically in the future.


As for the ‘less specific approach,’ I was considering if having a flexible framework for module types might be beneficial, allowing future expansions without altering the core standard. This could include general functions for module management applicable to all types, enhancing adaptability.


My intention isn’t to overhaul the entire standard, as it’s quite solid already. I’m just considering future adaptability. Let me know if this approach seems feasible and valuable in your view

Author: kopykat
Date: 2023-12-17T20:42:25.134Z

Yes, types should be extended by builders and/or future standards. We could add a note for this on the ERC to make it more explicit
I think module type ids being extensible is already a good step towards this. On the point of more generalized functions, I’ve replied on your pr but tldr is that we got feedback early on that having dedicated functions per module type was preferred for verbosity and because adding a new module type would need an account upgrade anyways, but the main downside I can see with this approach is just the overhead of 2 more functions for every new module type

Author: yaonam
Date: 2023-12-19T03:49:33.410Z

GitHub



Add a second param to `isModuleInstalled()` to support complex and...
[Here module refers to validator, executor, and hooks.] Idea Change function isModuleInstalled(address) external returns (bool) to function isModuleInstalled(address, bytes calldata) external retur...






Linking the discussion about adding a secondary param to module checkers to allow for more flexibility with module handling.

Author: wjmelements
Date: 2023-12-20T20:54:06.654Z

I have a tentative design for modular accounts that would be powered by SETCODE. It would be easy to splice code in and out with SETCODE.

Author: kopykat
Date: 2023-12-20T22:54:20.813Z

Interesting - is there any timeline already for the SETCODE EIP?

Author: wjmelements
Date: 2023-12-20T23:54:54.602Z

I hope it will be in Prague but ACDE priorities are unpredictable.

Author: kopykat
Date: 2024-01-27T12:01:09.259Z

Hey everyone, we wanted to share some updates to the standard. We are considering a simplification of the execution functions and the account config functions to both simplify the standard and make it more future proof. Check out the prototype here: GitHub - erc7579/uMSA

Author: webthethird
Date: 2024-03-08T17:37:17.254Z

@kopykat Re: the dependence on ERC-4337, I am just starting to work on a modular smart account on zkSync using their native AA, and I would like to use this ERC without the dependency. Do you have any recommendations for me?

Author: kopykat
Date: 2024-03-09T19:01:21.850Z

In general, ERC-7579 has two areas of dependency on ERC-4337:

assumption that a tx is split into separate validation and execution phases
the usage of the validateUserOp function

The former is pretty key to ERC-7579 so more work would need to be done there to figure out how to make the standard work for account abstraction solutions where this is not the case (but afaik it is the same in the case of zkSync).
The latter is pretty easy to go around, ie to not use validateUserOp but a validation function with another interface and input args. I’m not super familiar with how zkSyncs AA works but happy to chat more on telegram (@konradkopp).

Author: wjmelements
Date: 2024-04-01T21:56:11.140Z

I don’t want for this ERC to call itself minimal. There is nothing minimal about this design.

Author: kopykat
Date: 2024-04-01T22:15:32.496Z

It is minimal on the context of modular smart accounts, which are quite complex considering both the interoperability and security aspects. Happy to take any feedback on how the standard could be more minimal.

Author: wjmelements
Date: 2024-04-01T22:16:41.564Z

Look into the 2byte ABI.

Author: wjmelements
Date: 2024-04-01T23:20:02.204Z

The 2byte ABI is the minimal modular smart account design. It used to upgrade via CREATE2 and SELFDESTRUCT and I hope to restore it via SETCODE. It is more modular than anything that can be built with solidity because new subprograms can be directly concatenated.
Examples of contracts using the 2byte abi:

https://etherscan.io/address/0x00000000009e50a7ddb7a7b0e2ee6604fd120e49
https://etherscan.io/address/0x0000e0ca771e21bd00057f54a68c30d400000000

A contract using a similar 1byte abi:

https://etherscan.io/address/0x6b75d8af000000e20b7a7ddf000ba900b4009a80

There are more, but I suspect that the number of transactions using the 2byte ABI exceeds the number of transactions using erc-4337.

Author: matthiasgeihs
Date: 2024-06-21T10:25:43.136Z

Hi, why do you require backwards compatibility to ERC-1271?
ERC-1271’s isValidSignature interface feels a bit outdated as it does not receive any metadata (e.g., compared to ERC-4337’s validateUserOp which gets the full userOp).
Wouldn’t it be fine if compatibility with ERC-1271 would be just optional?

Author: kopykat
Date: 2024-06-21T12:18:54.859Z

As far as I know, 1271 is the only at least somewhat widely used way to have contracts sign messages. Are there any other ways that are adopted?
You could also add additional data into the 1271 data and then have the validator decode it but dapps would need to know how to encode this.

Author: 0xlynett
Date: 2024-08-24T11:17:56.660Z

nitpick: supportsAccountMode should be supportsExecutionMode, as that function is not mentioned anywhere except here:

Accounts are NOT REQUIRED to implement all execution modes. The account MUST declare what modes are supported in supportsAccountMode (see below) and if a mode is requested that is not supported by the account, the account MUST revert.

Author: kopykat
Date: 2024-08-24T13:05:59.036Z

Thanks for spotting this. We renamed supportsAccountMode to supportsExecutionMode but seems like we forgot to change this occurrence. Should be fixed now

Author: peersky
Date: 2024-10-17T07:58:34.238Z

Would using ERC-7746: Composable Security Middleware Hooks instead of built in hooks be useful to encapsulate some of the functionality of this ERC?

Author: kopykat
Date: 2024-10-17T08:20:28.026Z

Whats the upside here? There are around 6 ERC-7579 hooks already in prod and more being developed atm and 5+ accounts using these hooks with the interfaces. Also many hooks will decode the calldata to see what executions are doing so they will anyways need to be aware of ERC-7579 interfaces

Author: peersky
Date: 2024-10-18T05:39:17.140Z

kopykat:

Whats the upside here?


Interoperability,  encapsulation of specifications, kind of makes sense for me that this had to be figured out before doing 4337 (also has hooks for paymaster validation) and 7579… but it wasn’t, so Im proposing.

Author: ernestognw
Date: 2024-11-27T23:13:28.752Z

Heads-up that the return value of executeFromExecutor is not documented. Although it seems obvious that it’s the array of return data resulting from execution, I don’t think it hurts to specify.
I’d suggest:
/**
 * @dev ...
 * ...
 * @return returnData An array with the returned data of each executed subcall
 */
function executeFromExecutor(
    bytes32 mode,
    bytes calldata executionCalldata
) external returns (bytes[] memory returnData);

All other return values seem to be already specified, though

Author: kopykat
Date: 2024-11-28T03:31:06.437Z

good shout - thanks! updated this here: Update ERC-7579: specify executeFromExecutor return data type by kopy-kat · Pull Request #736 · ethereum/ERCs · GitHub

Author: arr00
Date: 2025-01-29T19:54:53.561Z

ERC-7579 and ERC-6900 both specify an interface called IModule. To increase clarity and avoid file/interface confusion, can we prepend all interfaces defined in this ERC with ERC7579 (such as IERC7579Module? I will be posting the same to the ERC-6900 discussion.
ERC-7579 IModule
ERC-6900 IModule