tldr:

Today, we are introducing a whitepaper for a modular, open-source Safe{Core} Protocol aiming to advance the smart account transition. We believe it has the potential to promote a unified standard and build a community to catapult smart accounts on the EVM. It features an un-opinionated core standard that is vendor agnostic, enables high component reuse and robust security while maintaining interoperability and smart account diversity.

EOAs are simple to use, but a flawed standard

Regular private key accounts/externally owned accounts (EOAs) are riddled with flawed UX that is unlikely to onboard the next billion users. According to some analysts, an estimated value of around $140 Billion has already been locked forever due to the bad UX of private keys. There is wide consensus that seed-phrases, costly hardware, and browser extensions are not going to unlock digital property rights for humanity.

But on the other hand, EOAs have been a beacon and have acted as the simplest solution in getting us this far. Creating an EOA happens free of gas fees, and can be repeated as often as new accounts are needed. They do not consume any storage in the network and can maintain the same addresses across networks. This mix of simplicity and flawed UX has made EOAs largely unusable for most users but also simple and usable enough to scale everywhere.

One overlooked and powerful feature of EOAs is that they create portable and composable accounts. This allows developers to build fast and create common tooling and components. Equally, it allows users to take their accounts with them without being locked into interfaces/platforms and their enforced policies.

This portability of accounts has already given the world a glimpse into a true sovereign ownership future. A future where for example, social media platforms cannot take away user handles arbitrarily. Furthermore, unlike in traditional finance where users have to register for one account per financial service provider, just one EOA account in web3 grants users access to a plethora of cross-chain DeFi products and services, regardless of provider.

The transition to smart accounts

Smart accounts have been determined as the solution to the UX problems of EOAs. Ethereum’s transition to smart accounts was recently highlighted as a non-negotiable by Vitalik Buterin in a blog post and re-emphasised during his history of account abstraction presentation at ETHCC 2023.

Safe, having built modular smart accounts since 2018, foresaw this need and has since been committed to making smart accounts the future of ownership. Over the past years, Safe has grown a huge ecosystem of 190+ projects and has become the most battle-tested account standard with over $56 Billion in self-custody. With new momentum behind account abstraction (AA) with ERC-4337 gaining adoption, and more projects like Rhinestone, Sequence, Argent, Gelato, and Biconomy advancing this transition, there seems to be an increasing movement to rapidly improve the UX of web3. While we all want to advance AA and the UX fast, there are still many challenges in our way that make a meaningful transition even harder.

The wicked problem of account abstraction

‘Wicked problems’ are ones with many interdependencies and intricacies. Solutions themselves reveal or create other problems. This makes holistic solutions much harder to find. We see the transition to smart accounts becoming such a kind of a wicked problem.

So far, we have seen novel solutions to UX problems such as chain abstraction, but these solutions have not considered the full security implications. We also see a wide number of projects that extend account functionality with different modular frameworks, but in which the modules/plugins themselves introduce new security challenges and break crucial interoperability.

Worst of all, in a race to solve parts of the problem and in a use-case specific manner, we may be missing the forest for the trees. We have already ended up with different smart account implementations that aren’t composable and introduce lock-in effects akin to web2. This stands fundamentally against the promise of web3 and digital ownership and arguably takes us to a place worse than EOAs.

Introducing Safe{Core} Protocol: The interoperability protocol for modular smart accounts

Safe has published a whitepaper with the first design of the Safe{Core} Protocol, creating a unified standard to help solve the wicked problem of transiting to smart accounts holistically. The protocol addresses the following problems:

• Fragmentation: Ensuring we maintain composability for dApps and tooling through standardised 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 service providers among users

• Security: Introducing Registries that ensure smart contract risk is reduced and providing sufficient security guarantees

In the design, we introduce a Manager as an abstraction layer to manage the interdependencies of these problems. The role of the Manager is to handle the complexities of fragmentation, interoperability, and security and the proposed solutions between Registries, Accounts, and Modules (see Fig.1).

A call for feedback and collaboration

The solutions to wicked problems are often found in collaboration, and so the Safe{Core} Protocol whitepaper is the first step in realising the next iteration of account abstraction with interoperable, modular smart accounts. Gathering community participation and feedback is where we truly have a chance of making the smart account transition happen and enabling more ownership for people.

Therefore, we are releasing our first draft version as an open invitation to the community and the wider public to contribute and refine the Safe{Core} Protocol. These will constitute the starting points for future iterations while building the implementation in the open.

The whitepaper can be accessed here and a work-in-progress of the protocol specs and implementation can be found here. All feedback is welcome in this forum thread.