Sorry for the slow response, have been travelling.
Great questions!
The Safe{Core} Protocol aims to be ERC-6900 compliant, which also foresees hooks for plugins. It’s not yet part of the MVP specs to reduce complexity, but should be evaluated!
What is the current view on implementing multiple managers and registries?
I think this is not fully clear at this point as there are different benefits for each, often evolving around stronger security guarantees vs. flexibility. Generally there should be different registries though, as some may be focused on enfocing security, others to guaranteeing compatibility (e.g. to a specific UI) or are tied to e.g. an insurance solution that only covers certain modules. There are also reasons for having multiple managers (e.g. to be more tailored to the corresponding account implementation) but also to have a single manager (less fragmentation).
What’s your take?
- How does it scale the security<>monitoring when there are > 100s modules being added in the same registry interacting with each other and multitude of external protocols?
That’s a good point and something which I’m not sure there will be a single answer to it. I think there will be different registries applying different approaches (automated or manual) to this and may have as a result varying security guarantees.
Would it be fair/rational to embed a fee in the modules that are based on subscription and/or volume that flows through the module?:
As mentioned in the whitepaper, I think there should be ways for different participants in the protocol to charge fees easily and securely. This will be a larger research lift though to figure out what fee types should be prioritized and how they are facilitated in the protocol. But I think it will be required to make the ecosystem around the protocol sustainable. If you have thoughts on how the Safe Token could also provide utility in this context, would love to hear them. Potentially even as a submission here. Exploring The SAFE Token: Call For Input - INSTRUCTIONS - #15 by Steven