ERC-7579: Minimal Modular Smart Accounts

EIPs
1

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.

10 Likes
2

Hey @kopykat :wave:

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?

:+1:

1 Like
3

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

1 Like
4

Thanks, I have left some comments on the pr.

To your questions:

  1. 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
  2. What do you mean by less specific approach to module types?
1 Like
5

Thanks @kopykat.

  1. 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.

  2. 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

1 Like
6
  1. 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
  2. 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