The transition to smart accounts is a critical step required to onboard mainstream users onchain. Over the past year, we’ve seen an explosion of innovation in smart accounts and the emergence of modular smart accounts that can extend onchain account functionality through plugin installation. Recently there’s been a lot of discussions on standards in the modular account space centered around two standards in ERC-6900 and ERC-7579. We think the underlying rationale for both are great and push the ecosystem forward, and wanted to share thoughts around further discussion from here as well as provide technical commentary on both standards.
We’ve noticed there have been many misconceptions around the standards, and wanted to start by trying to highlight some of the latest thinking there. Before we do so, a quick note. The discourse around these two standards is great and absolutely necessary to push the ecosystem forward, and we appreciate the breadth of perspectives and opinions here and they're facilitating great discussion. That said, as soon as it turns into teams punching at each other it becomes zero sum and not constructive. It is important to us, and hopefully to all of you, to keep the framing and discussion positive to continue to grow the pie.
As such, we were disappointed to see both the tone and content of the ZeroDev blog post that anecdotally has been driving many of these misconceptions. We think it's awesome to see so many teams iterating on this surface area and contributing resources and capital to furthering the public domain, and want to encourage and continue participating in that with a constructive attitude.
In this article, we cover:
Technical corrections to ZeroDev’s blog post.
A quick architecture overview of 7579 vs. 6900, looking beyond permissions.
A summary of ongoing efforts to streamline interfaces and approaches between 7579 and 6900 to minimize potential future work around adopting both standards - including open technical questions to the 7579 community.
A note on permissions, why they are important, and how they fit into a broader smart account security story.
Procedural corrections to ZeroDev’s blog post.
A summary in conclusion.
There were a few issues that might have been overlooked by the authors of the blog post that we want to clarify:
Aggregators are not banned in 6900, and validation functions may return them. The confusion may come from pre-validation hooks, which may not return these, because there is no well-defined way for an account to use multiple aggregators at once.
Implementing 6900 as an extension to 7579 is not possible with the current specification of 7579. ERC-6900 plugins depend on connecting execution functions with specific validation functions. ERC-7579 requires adherence to a specific installation flow but leaves the association of validation and execution functions ambiguous, which makes it impossible to atomically configure the associated validation and execution functions. There is more on this below in “No standard way to associate execution with validation”.
It is possible to install plugins during validation. The released ERC-6900 Multi-Owner Plugin does not do this by default, but performing plugin installation during validation is allowed by 6900. There are a series of unit tests demonstrating this, with one example here.
Because ERC-7579 is so focused on granting flexibility to account developers, it doesn’t standardize account behavior enough for plugins to generalize across different account implementations. That is, plugins developed for one 7579 account won’t necessarily work on other 7579 accounts which limits interoperability and doesn’t solve for vendor lock-in.
No standard way to associate execution with validation
7579 doesn’t say anything about how to decide which validators can be used to validate for which calls. So you could have two different 7579-compliant accounts where:
one account says that any installed validator can be used to approve any call (validators apply globally across any execution function).
the other account has some way of specifying that certain calls require certain validators, so it would be able to have, for example, an owner validator and a session key validator, where certain executions require certain validators.
The issue is that since 7579 doesn’t prescribe how validation and execution is associated, it’s impossible to write a module (plugin) that requires that a particular execution must be used with a particular validation in a way that works across all account implementations.
We view this a serious problem for interoperability. Every plugin we’ve written so far (multi-owner, session key, cold storage), has needed to associate validation with execution as part of its core functionality.
This cannot be left implementation-dependent per account: a plugin built to work with one account will not work with other accounts.
Two example scenarios to consider here:
A plugin wants to add execution behavior that can only occur after a validation it defines itself, e.g. session key validation.
A plugin wants to add execution behavior that can only occur after validation defined by some other plugin, e.g. owner key validation.
Trying to standardize a way that a plugin can specify each of these likely leads down a path similar to the execution function and dependency sections of the 6900 manifest.
No standard data format passed to hooks
No validation hooks
This makes implementing general-purpose gas limits difficult or impossible. Accounts that don’t carefully limit gas spending are highly vulnerable to having their funds drained if there’s any op that an attacker is able to validate. Under 7579, every validation function needs to build its own defenses against this.
It’s possible the intention is that you can add multiple validations to something and require that they all pass, basically treating validation like a validation hook. If so, there is no standardized means of doing this, which again means that a plugin that works for one account will not work for others.
To be fair, general-purpose gas limits aren’t fully possible in 6900 at the moment either, but it’s a lot closer (just need to add validation hooks that apply to any execution function).
No standard way for only certain hooks to run
There is a workstream working on streamlining interfaces between ERC-7579 and ERC-6900, so that plugins can be compatible with both standards in certain cases. Generally, the goal is to work together to grow what is an exciting, but small and nascent ecosystem around Modular Smart Accounts. Most of the conversation so far has centered around the permissions model. Regardless of permissions or no permissions, there are other ways to improve both proposals that might be worth pursuing. There is more on the permissions component in a section below.
We’d like to give Konrad from Rhinestone a shoutout for starting this workstream with a document highlighting existing differences here. See the continued discussion here.
Everyone has the same goal of maximally secure smart accounts with plugins for end users. Security is complicated and there is no silver bullet - no one solution is going to make an account system all of a sudden “secure”. As such, it’s useful to think about the overall security story ranging from application idea to runtime execution of UserOperations and everything in between.
ERC-6900 permissions are important to limit the scope of what a plugin has access to at runtime, and this limitation is defined as soon as the plugin is installed. This is not comprehensive, and only a part of - though a critical part of - the total security story because it limits what arbitrary third party software can execute on the users’ account.
This plugin installation flow onto an account is analogous to how applications are installed into operating systems like Android today. The plugin requests permissions from the account, just like an Android application requests permissions from the Android OS on the user’s device. For example, when I install an application like WhatsApp, the operating system requests permissions for a set of privileges that the application, WhatsApp, needs to properly execute, such as my location, access to my camera, access to my microphone, access to my contacts, etc. I, the user, care more about the application and think of it as coupled to the set of permissions granted. In ERC-6900 currently these are all permanent permissions (so long as the plugin is installed), but there is a proposal to support per-usage permissions as well (e.g. request to use my location every time I open WhatsApp).
In order to add plugins from different apps, you need to limit their trust requirement - otherwise, as mentioned above, they are able to execute arbitrary software on the user’s account which can result in total loss. Without some flavor of account-enforced permissions, minimizing this trust requirement is not possible. Each plugin could do anything in the account, so you only add the ones you really trust. With the permission model, you don't need to care much about what the plugin does, just as long as it can only interact with the contract you authorized for it. An account without a permissions system will require some form of a permissioned plugin store instead.
As we’ve seen with really any smart contract, there is always a litany of security considerations and unenumerable risk vectors. This only compounds when you’re dealing with user accounts and a multi-faceted security approach will always be required.
To this point, and for the foreseeable future, audits will be a major part of smart contract security. It’s been incredible to see top tier firms like Quantstamp and Spearbit ramp up their context on smart accounts generally. Their (and others’) context here layers over time to continually harden the whole ecosystem. Permissions do not at all negate the need for audits, especially for critical flows like ownership. Still, they layer nicely - a big reason to allow users to configure their own permissions is to allow them to confidently install plugins by choosing their own restrictive permissions for them. For example, I might be willing to install an unaudited plugin if I can enforce that it can only talk to one contract and spend at most $10.
Bug bounty programs have proved to be effective mechanisms for leveraging experienced, whitehack hackers to identify vulnerabilities and minimize threat exposure on an ongoing basis. It creates incentives for researchers to find and report issues before they have the potential to affect end users. We spun up a bug bounty program with HackerOne for Modular Account with payouts of up to $100,000 USD for critical vulnerabilities.
Augmenting audits with automated testing and tooling will speed up and cheapen the development process. There are many promising tools that enable developers to test for security invariants and analyze their code before shipping. Enumerating a few:
Slither is a static analysis tool with a suite of vulnerability detectors that enables quick checks of known antipatterns. We highly recommend all Solidity and Vyper devs include this in their CI pipelines.
Halmos is an open source formal verification tool from a16z. While not everything will be testable with formal verification, certain closed properties like state before/after install/uninstall are.
Octane provides security services by training AI models on existing codebases with training data that includes past exploits. The models are quite capable and from our experience detected many of the issues found under audit (and a few more).
Fuzz testing. We don’t have a tool of choice here yet, but the basic concept with fuzz testing is to try random or pseudo random inputs as arguments into transactions to see if we can reach an unexpected state. This is a nice complement to tools like formal verification in that it lets you probabilistically test open properties.
Plugin registries provide a “decentralized app store” model where teams and individuals can attest to plugin usage. These teams can range from auditors and security vendors (like those listed above) to users who have installed and used the plugin. User’s can install plugins if they decide to trust the attestors to its security. While none have been built yet (as far as we know) we’re excited to hopefully see a few in production this year. Learn more in Rhinestone’s ERC-7484 or check out Ditto Network who are working towards something similar.
There are many risk vectors at the point at which the user constructs, signs, and sends a transaction. Many companies today provide basic tooling to ensure that users can trust the messages they’re signing, which historically have been presented as unreadable hex strings. Today, companies like Blockaid provide sophisticated simulations leveraging onchain and offchain data to minimize the threat of fraud at runtime.
This too can be coupled with a plugin based system to enforce that the simulation results the user signs are the results executed onchain, with a postExecution hook to enforce equivalence.
If we’ve gotten this far and vulnerabilities still exist, it’s preferable to be able to detect them before any malicious adversary. Protocols like Forta monitor real time patterns to try to detect new risk vectors before they’re exploited. One can imagine a plugin here too, where protocols like Forta are able to temporarily “turn off” a users’ account if they notice it may be vulnerable.
Other approaches we want to see here are real-time fuzz testing, based on the users’ state onchain. This continually evolves the fuzzing model to only test against valid starting states.
Security is a notoriously difficult problem, and this is especially true with immutable smart contracts. If you’re thinking about or building in the security space, we’d love to chat with you!
To start tying things up, we wanted to circle back to ZeroDev’s blogpost and raise a few procedural corrections on statements that we disagree with.
Alchemy’s motivation in incubating ERC-6900 was to work with the ecosystem to help drive smart account adoption forward. To that end, both the standard and its contributor set have evolved significantly since then as the coauthors have built in public, and in collaboration with teams from the Ethereum Foundation, Circle, Quantstamp, Spearbit, Collab.Land, Maple Finance, Decipher, and countless others. To the point that this work can happen in public, we try our best to do so. Some of the discussions we have with customers and teams, such as those from the institutional or web2 sectors, often happen under NDA and while we need to incorporate their feedback into the design, we can’t publicly discuss where it originated. Just because it’s not visible does not mean it’s not happening. Regardless, if there is feedback, it’s more constructive to anchor these critiques on technical merit more so than perceived contributions.
The scaffolding around ERC-6900 has been have designed - including everything from the Github repo, the community calls, and the Standards TG channel, and the goals and guidelines enumerated as the first messages there - to promote open contributions and dialogue, and the criteria for becoming a coauthor have been objectively defined and public since June 2023. Multiple co-authors have onboarded, all of whom have meaningfully pushed the standard forward. The door always remains open until the standard finalizes.
To summarize all of the above: the discourse and various opinions on modular smart account architectures is great for the ecosystem. We’re really happy to see a range of ideas being discussed in a public forum, and want to support builders who are pushing the edge of what is possible to do onchain in order to onboard the next billion users. We’d love for these conversations to stay constructive and objective to make sure we focus on helping each other grow the pie. We’re excited about the quickly growing ERC-6900 ecosystem and continue to think that the permissions model is an important way to address a particular slice of the security spectrum. We also understand that everything has tradeoffs and are excited to see developers explore ERC-7579. Hopefully some of the above feedback can be useful in continuing to iterate on that specification as well. Lastly, we hope to streamline the interfaces so that developers can at some point maximally leverage learnings from both.
If you’re interested in getting started with Modular Account Abstraction, check out our quick get started guide here. If you want to chat, feel free to reach out on Telegram or X to @probablynoam, or on Farcaster/Warpcast to @noam - DMs always open.