Building a modular future for account abstraction: ERC-6900

Account abstraction is core to Alchemy’s mission of bringing the next billion users onchain.

Anyone who has used a traditional crypto wallet has experienced the frustrations and poor UX that have until now been a major obstacle for onboarding new users to the space. By making smart accounts programmable, ERC-4337 is ushering in a new era of wallets with better UX for users and new features for developers like sponsored gas and social logins.

Impressive as these advances are, they’re only the beginning of what’s possible with account abstraction. ERC-4337 opens up a much larger opportunity for innovative wallet functionality, and developers are only beginning to explore here. This functionality is increasingly being built in the form of modules or plugins that can automate in-wallet operations ranging from dollar cost averaging to session keys and beyond (this list from Rhinestone gives a sense of the possibilities).

The future we’re building toward is one where developers and users can get the full benefit of this flexibility. Getting there will require going beyond building great developer tools and educational content — it also means building for and with a larger ecosystem of developers, and working toward consensus around the tools to get there.

Our commitment to this modular future of account abstraction led us to initiate ERC-6900, a set of universal standards for the design of plugins and their interactions with smart accounts. With the publication of the first reference implementation for the standard, we’re excited to bring 6900 to a larger audience of builders.

The rest of this post describes the structure, current status and roadmap for ERC-6900. To get there, we start with a brief detour into modularity and its importance to account abstraction.‍

Building modularity

Modularity at its most general is the concept of unbundling monolithic technologies into component pieces, or modules. In theory this is the best of all worlds - application builders aren’t locked into a single provider, and instead can choose the best providers for each component of their stack.

But modularity requires more than some arbitrary set of components - application developers need to be able to use and integrate modules into a coherent whole, and the builders of modules need to know that what they’re building can be used as widely as possible.

To see why, let’s consider two builders: Alice and Carol.

1. Alice is an application developer, and wants to build great applications that create value for her users

2. Carol builds modules, and wants to make sure that what she builds is both discoverable and usable by the largest number of application developers.

How do Alice and Carol work together?

First, effective modularity requires a rich ecosystem of plugins for application developers to choose from, expanding their toolkit and reducing potential lock-in to any single provider.

Second, Alice needs to be able to integrate Carol’s work, and Carol needs to know her work is compatible with Alice’s in order for each to have an incentive to build. The way to achieve this is through neutral standards that remove friction and enable integration for developers in the ecosystem.

Put another way, standards are how modular ecosystems strike a middle ground between monopolistic lockin and uncoordinated chaos.

Translating this back to account abstraction, building a modular future will require a rich ecosystem of plugins, which will in turn require a neutral standard that developers can coordinate their efforts around.

Building a neutral standard for modularity: ERC-6900

By standardizing basic functions and interfaces, ERC-6900 seeks to foster a growing ecosystem of both smart account and plugin developers. Plugin developers should be able to write one plugin that works with all smart accounts, rather than fragmenting their efforts across multiple different account implementations. And smart account builders should be able to access plugins with standardized interfaces that allow them to integrate with confidence.

How does 6900 work?

To realize these goals, ERC-6900 is designed to achieve two technical objectives:

• Provide standards for designing plugins for smart contract accounts.

• Provide standards for how compliant accounts should interact with plugins.

Plugin designers following the standard can work with three standardized components:

• Validation functions ensure the validity of external calls to the smart account.

• Execution functions are smart contracts that specify the execution logic for functions within a plugin.

• Hooks specify more fine-grained actions and validations that can be designed to occur pre- or post-validation, and pre- or post-execution.

ERC-6900 seeks to balance the benefits of open composability across plugins with the need to maintain security and interoperability. At a high level, it does this by standardizing how accounts and plugins interact with each other, as well as the pre-installation requirements for plugins.

The standard also builds on earlier work by the Android developer community to standardize the interface between smart accounts and plugins. Each compliant plugin will incorporate a manifest that establishes various functions and hooks that need to be added to the smart account on installation. It will also specify aspects of the plugin (metadata, dependencies and permissions) that are necessary to constrain the plugin’s ability to act on the smart account.

For more detailed information, see the modular account docs for Account Kit or the spec.

What’s next for ERC-6900?

ERC-6900 recently reached a significant milestone with the release of its reference implementation, accessible through a public Github repo. This release represents a pivotal moment in the standard's intended evolution from an Alchemy-initiated project to a genuine community standard. While it’s not yet audited or production-ready, the code provides developers a sample codebase to experiment with as a complement to the formal spec.

The spec itself has been improved across several revisions as a result of an active and ongoing dialogue with the community. It also has an expanded author set that includes Yoav Weiss from the Ethereum Foundation’s ERC-4337 team, and authors are already in active discussions with other potential stakeholders, including the developers of complementary standards such as Rhinestone's ERC-7484 and Safe’s ERC-7512, as well as other leading teams developing account abstraction.

The ERC-6900 team is also looking beyond these core stakeholders as part of this new phase of building in public. The authors are beginning a series of weekly community calls that are open to the public, beginning on November 7. Please reach out if you’d like to join these calls, connect with us on telegram, or keep an eye on the standard’s Twitter/X account for weekly updates.

As always - comments and feedback are welcome, whether in the form of a pull request to the Github repo, a comment to Ethereum Magicians or a question in the Modular Smart Contract Accounts telegram channel.