.png)
(Update: we published a follow-up blog post. Noam from Alchemy published a response.)
Account abstraction (AA) as a space has largely embraced the idea of "modular smart accounts" — smart accounts whose logic can be customized dynamically using plugins. To date, more than 90% of all smart accounts ever deployed are modular, with Kernel being the most popular choice.
However, the fact that different modular smart accounts are not compatible poses a great challenge for developers. For example, if you are building a DApp and want to use session keys, you need to choose a specific session key implementation that works only with a specific smart account implementation. If you use, say, OpenFort's session keys, your DApp won't work with Kernel-based wallets, and vice-versa. This is a big reason why AA so far has mostly only found PMF within the context of embedded wallets, where the DApp can tightly control what account implementation their users use.
To meet this challenge, Alchemy proposed ERC-6900 as a modular account standard back in April 2023. We were initially very enthusiastic about this effort and intended to support it. However, over time we have become pessimistic about the direction 6900 is headed, so we coauthored ERC-7579 with Rhinestone, Biconomy, and OKX, a standard that we believe better exemplifies the spirit of openness, interoperability, and innovation that we've come to associate with Web3.
In this post, we describe the issues we had with ERC-6900 and why we decided to build on ERC-7579 instead.
TLDR
If you don't have time, here's the takeaway:
- ERC-6900 is an implementation pretending to be a standard. Adopting ERC-6900 means adopting a number of implementation decisions made by Alchemy that are way beyond the scope of ensuring module compatibility.
- On the other hand, ERC-7579 is a minimal interface that solves one problem only: modules should be compatible across smart accounts. Beyond that, smart accounts are free to make their own design decisions.
If you don't believe us, simply compare the lengths of both ERC-6900 and ERC-7579.
A good analogy may be Mac OS vs Linux. While Mac OS is a great OS, it shouldn't be a standard. A standard should be minimal like Linux, so people can build different OS-es on top of it (including Mac OS), while remaining compatible with each other.
Now let's look at the issues we had with ERC-6900.
Technical Issues
Module Composability
One key goal with Kernel is to make it simple to develop modules securely. In other words, it should be as hard as possible for the module developer to screw up.
That's why Kernel is designed with module composability in mind. Module composability is the idea that a UserOp should be able to invoke multiple modules. As a result, module developers can keep their modules very simple, and achieve complex validation logic by putting simple modules together.
This is not possible with ERC-6900, however, due to the fact that each execution function has to be tied to a single validation module. Therefore, whereas with Kernel you can develop plugin A and plugin B, and to achieve A+B you just need to use A and B together, with ERC-6900 you have to develop a new plugin that combines the logic of A and B. This results in redundant code and complex, monolithic modules that are hard to audit.
Enabling Modules Off-Chain
One “killer feature” of Kernel is the ability to enable modules off-chain. For example, you can create a session key by just signing a message. No gas cost is actually paid to enable the session key until and unless the session key is actually used.
This is critical for use cases like limit orders. When I create a session key for a protocol to execute a limit order, I shouldn’t have to pay gas upfront if the order may never be executed.
To enable modules off-chain, ZeroDev packs both the “approval” for the module and the signature data inside the signature field of the first UserOp. However, this is not possible with ERC-6900, since it stipulates that the UserOp must be passed as is to the module. As a result, unless the module is explicitly programmed to ignore a part of the signature, it will fail to parse it, introducing a dependency between the module and the smart account implementation—which defeats the purpose of a modular standard.
That’s why session keys in ERC-6900 must be enabled explicitly on-chain, thus invalidating a large number of use cases that require session keys be created without guarantees of transaction execution.
Aggregators
"Aggregators" is a lesser-known feature in ERC-4337 for validating aggregate signatures (like BLS) or validation processes that involve global storage (like ZK-based recovery).
ERC-6900 however bans aggregators outright. The reasoning is not clear, but if there were issues with aggregators, the more reasonable approach would be to propose a spec change to ERC-4337 itself, as opposed to proposing an account standard that bans a part of ERC-4337.
Non-Technical Issues
ERC-7579 was driven by real experience; ERC-6900 was not
It shouldn't be a surprise that ERC-7579 is a more well-designed standard than ERC-6900, if we examine how these two standards came about.
- ERC-6900 was conceived by the Alchemy team when there was minimal traction for AA and modular smart accounts. While Alchemy engaged others, the overall architecture remains consistent with their initial design.
- ERC-7579 was conceived almost 8 months later. By that time, over two million modular smart accounts had been deployed, allowing the authors (ZeroDev/Kernel, Biconomy, OKX, and Rhinestone) to draw from the actual, diverse experience of both module and smart account developers.
Decisions Regarding ERC-6900 are Dominated by Alchemy
If we had so many issues with ERC-6900, why didn't we try to contribute to the standard instead of making a new one?
We did. We provided extensive feedback in the early days, but the response often indicated that Alchemy saw themselves as the ultimate arbitrator of the standard. Our opinions felt overruled, and the standard evolved to incorporate a specific set of design decisions made by one team. We do not believe this is the right way to build an open standard that enables interoperability while respecting different design decisions.
As much as it pains us to say it, pushing a "standard" that really just enshrines a particular product is unfortunately a common practice in Web3. While we are inclined to think that that's not the intention of ERC-6900, what we have seen doesn't give us strong confidence.
The Future for ERC-6900
Again, we respect ERC-6900 as an implementation—it makes a set of design decisions that are generally sound and logical. It just shouldn't be a standard.
If ERC-6900 is to stay as a standard, we hope to see it become an extension on top of ERC-7579 (note how this is possible, but not vice versa). That way, developers aligned with ERC-6900's specific design decisions can adopt it, but to achieve module compatibility, it would be enough to adopt the minimal, open standard that is ERC-7579.
Last Words
Standardization is a balancing act—one must seek to improve interoperability between different products, while allowing products to differentiate and innovate. The latter is particularly important because it’s still just the very early days of account abstraction. That’s why we are building our product on a minimal interoperability standard that is ERC-7579, so that we can continue shipping awesome products to the end users, which, ultimately, is all that matters.
