We’re excited to introduce a whitepaper detailing the Safe{Core} Protocol. It’s a vision for a modular, open-source protocol aiming to advance smart account transition. Why is this significant? We believe it has the potential to promote a unified standard and build a community to accelerate smart accounts on the EVM.
The protocol addresses the following problems:
Fragmentation: Ensuring we maintain atomic composability for dApps and tooling through standardized modules namely, Plugins, Hooks, Function Handlers, Signature Validators etc
Vendor Lock-In: Ensuring we maintain interoperability and portability of accounts by being vendor agnostic, upholding the freedom of choice and discoverability for users among service providers
Security: Introducing Registries that ensure smart contract risk is reduced while providing sufficient security guarantees
The whitepaper features an un-opinionated core standard that is vendor agnostic, enables high component reuse and robust security while maintaining interoperability and smart account diversity.
Call for feedback
The key to unlocking complex problems lies in collaboration. In that spirit, the Safe{Core} Protocol whitepaper is just the first step towards our vision. We’re looking forward to community-driven insights that will shape the roadmap of the protocol. Join us. Share your thoughts. Together, let’s shape the next chapter of account abstraction and modular smart accounts.
This sounds exciting. Registries seem powerful and might act as bad actors by providing false/dangerous access to modules. Like, a register could, in theory, list modules that, at first glance, have no security risk, and as far as I know, modules (can) bypass the signature requirements of the safe?
Would it not be wise to add some slashing component to registers, or are there other methods in the thinking process? Then again, how much value would a register need to stake to ensure the security of the accounts it’s connected to, though question.
Even with Registries, users will have to actively enable a module. So it’s in any case additional security on top of how Safe worked so far.
And to your point, indeed there can be different additional security properties on top of just trusting the registry maintainers. In general there may be very different approaches to maintaining registries from a trusted team just leveraging its expertise and reputation, to a decentralised mechanism maintaining a registry using incentives / slashing, etc. The Safe{Core} Protocol is itself agnostic towards how the registries operate.
Congratulations to the core Safe team for beginning to build Safe protocol by publishing the whitepaper!
SAFE token usability
As I mentioned in the Exploring the SAFE token post, the Safe protocol Manager component creates many opportunities around SAFE token usability beyond only governance.
Safe implementation samples
It’d be cool to list samples of how the Safe core team might build proof-of-concepts with Safe protocols’ components, e.g. Registry for Safe apps and/or modules.
Decentralization
It’d be good for builders to start thinking about how the Safe protocol components can be incrementally decentralized, e.g., accounts, manager, modules. Perhaps there could be a section or incorporated within an existing section outlining how these components could be implemented in a current state and theorize strategies to be decentralized in the future.
This will a great step forward, I appreciate how the team is building for a standards based approach.
Will the modularisation enable extra long-waited for features such as dynamic signature thresholds? For example if the signature verification will now be delegated out to ‘Signature Validators’, could that be a custom sig validator contract per Account, where the number of signatures is determined within that contract?
What this paper doesn’t cover is the UX for Account owners, given this level of potential customisation, for example the above signing flow. How is Safe thinking about/anticipating for this? Will the Safe dapp try and cover these with a modularised/plugin based approach too, or will that need a custom web app (using a sdk) for the custom cases?
That’s a good point. We see this being a place where Metadata will be quite relevant to expose how Modules should be handled and exposed to users. But this is still an aspect where we need to make further research over the next months.
Yes that’s right, with Plugins or Signature Validators dApp or wallet developers could create custom verification schemes. To some extend that was possible before, but especially for off-chain signing schemes the new Signature Validator type will be opening up new opportunities.
Excited for the future opportunities that are created by a standardized registry and manager architecture!
Couple of open questions that I would like to hear Safe{Core} team’s opinion on:
Under the current design it seems that there is only one hook per safe address. Does this not limit the flexibility of the protocol in that case? Would it not be a more open design to allow to have post and pre hook both per module basis & per safe address?
Envision that hooks would be more an element containing specific checks that are specific to a module basis, rather than a safe address as whole
Needs modifications at the registry level to allow storage tracking of module<>hook relation
On some occasions, I can imagine a pre-hook being essential, but not necessarily a post-hook. Currently, the architecture seems to assume that always for each tx pre & post is essential? Do you think that always be the case that both checks are essential or a different architecture could be introduced that one or another are enforced for a specific set of txs?
What is the current view on implementing multiple managers and registries?
Is the vision to have a single official registry (similar to Google Play Store), or for every protocol to implement its own version?
The same goes for the manager. Would it be favorable to have a single manager enabled for all plugins, or can multiple managers co-exist?
Multiple registries and multiple managers?
Registry security profile to flag modules and its scalability:
Assuming initially that the Safe team/subteam would be in charge of being “owner” of the registry
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?
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?:
Opportunity for another layer of $SAFE token utilization
Intrinsic motivation for builders on top of a registry that legitimize modules and stickiness
Could present a race to zero-fee. How do you guys envision avoiding that and leveraging the network effect of Safe?
Polywrap’s “Safe AA wrap” may help improve the experience of Safe{Core} Protocol. The AA wraps allows interactions with the module smart contracts to be abstracted by allowing integrators to access custom actions for plugins/managers. For smart contractor developers, they’ll be able to wrap their smart contracts’ business logic once and have it be accessible in any programming language. This means less development and maintenance work for Safe’s developer ecosystem.
You can find the repo below, which is structured similarly to the official Safe{Core} SDK repo. Take a look!
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
Call for feedback
Protocol specs and implementation (WIP)
Give feedback below in the forum