ERC-6900: Modular Smart Contract Accounts and Plugins

ERCs
55

Announcing ERC-6900 v0.8

We’re excited to announce the release of ERC-6900 v0.8! While we want to keep breaking changes to the minimum, the learnings of the past 2 years around modular smart accounts have required us to revisit some aspects. Generally, the design improvements can be classified into three categories: overall design changes, maintenance, and utility. The most important ones we would like to touch on are in the following section:

Overall Design Changes

We significantly reworked the permissions framework and decided to shift away from a static module-defined manifest (link), where the module used to define how and with which permissions a module was to be installed on an account. We found that this artificially limits the flexibility of modules in how they could be configured in accounts. While this added flexibility also comes with the tradeoff of possible misconfiguration, we deemed that the benefits are ultimately far too great. Now, users supply a custom ValidationConfig for Validation Module installations and an ExecutionManifest for Execution Module installations. We also added support for multi-validation (link), breaking up the pre-existing 1:1 relationship between an execution function and corresponding validation function as specified by the module manifest. Now, an execution can possibly be unlocked by multiple validations, possibly from different Validation Modules. This again offers vastly more flexibility and also enables simpler social recovery features. You can now also install the same validation module multiple times (link) with different validation config data. Furthermore, we’re introducing the concept of global validation (link). Any execution function being installed can optionally be unlocked by this so-called global validation. Global validation functions are essentially a pool of installed validation functions that are specifically marked as global. Each validation function marked as global can then unlock all execution functions that have global validation enabled. By introducing a “default” validation function pool, we can reduce plugin installation costs, particularly for ownership plugins, by allowing execution functions to opt-in to a default validation pool.

We also embedded ERC-1271 into validation modules link, which allows for routing ERC-1271 checks in cases of multiple signature validation plugins. We also added the possibility for signature validation hooks.

Maintenance

A simple overall design change is the renaming of plugins to modules (link) for consistency around the modular smart account ecosystem. Furthermore, we updated the account interface to comply with the EntryPoint v0.7 interface (link). This version of the standard no longer works with EntryPoint v0.6.

Furthermore, some interfaces got merged. The IStandardExecutor and IModuleManagergot merged into a new IModularAccount interface. We also split out the slightly convoluted IModule into the different interfaces for each of the different module types, namely the IValidationModule for validations for an account, the IValidationHookModule for hooks for validations, the IExecutionModule for execution functions and their installations on the account and finally the IExecutionHookModule interface for pre & post-execution hooks for execution functions.

Utility

We decided to add one more hook type to the standard that module developers can define, so-called permission hooks. These are execution hooks that are associated with a validation function instead of being associated with a selector. So depending on by what validation function a certain execution is unlocked, the permission hooks might or might not run. This addition makes it easier for accounts to configure execution hooks across multiple session keys. It’s also more efficient, since only the relevant hooks for a session key are loaded per use.

ERC-6900 v0.7 already offered a vast set of different hook types that tended to overwhelm devs getting started with the standard. The reason for that is that we think explicit definition and distinctions between hook types ultimately enables true interoperability and flexibility for module developers. Permission hooks were an important missing piece in our hook definitions, especially with the shift away from the manifest.

This change is part of our general overall change to the way we enforce permissions, away from the manifest-defined definitions, towards a more customizable approach via ValidationConfig and optional permission hooks to further keep the permissions of a validation module in check. A possible use case is native token spend limit permissions for specific validations or a session key for a DEX that is dollar cost averaging into some token in regular intervals, where we could enforce additional slippage checks via execution hooks, therefore keeping the permissions of the semi-trusted session key-validation module in check with an additional hook.

We also acknowledge the need of developers to have a pre-configured, more rigid account, which we coined semi-modular accounts. Semi-modular accounts are accounts that may have some module features built-in directly to the account instead of via installed plugins, which reduces the need to install them during account creation, reducing account creation costs significantly. For example, take a look at our semi-modular account with 7702 support in the reference implementation repository. As part of this release, we explicitly support these kinds of accounts in the standard.

Reference Implementation

We’ve updated the reference implementation to the v0.8 version of the standard. The reference implementation is an example to show how to build an ERC-6900-compliant modular account. It is NOT a production-ready implementation.

The implementation includes an upgradable modular account a set of permissions-enforcing hook modules and a validation module, which are fully compliant with ERC6900 v0.8:

Permission-enforcing hook modules:

Validation Module:

Important Callouts

The reference implementation is not audited and should NOT be used in production. Furthermore, it is not optimized in both deployments and execution. We’ve explicitly removed some optimizations for reader comprehension.

More Links

3 Likes