What is Modular Account Abstraction?

Written by Logan Ross

Reviewed by Brady Werkheiser

Published on July 19, 20233 min read

---

Modular AA is a movement aimed at evangelizing modularized smart accounts. The goal is to make accounts customizable for users and allow developers to build context-rich and self-contained account features.

Modular smart contract accounts (SCAs) allow builders to create useful new extensions to accounts. Some examples include:

1. Social Recovery - Allow a trusted device or friends to help you recover your account in case you lose access

2. Spending Limits - Allow dapps to spend tokens on behalf of you up to a specified limit

3. Passkey Support - Login with your biometrics like FaceID

By standardizing modularity counter-party risk can be greatly reduced, leading to simple and secure web3 user experiences.

The ERC-4337 standard lays out the infrastructure components and coding standards which when implemented enables users to have a primary account type of a smart contract over a private key. Historically, the primary account type was an EOA (End User Account), which, unlike SCAs doesn't have custom validation and execution logic.

This article aims to provide you with an overview of Modular Account Abstraction, what it enables, and the existing standards and implementations.

What are the different types of modular Smart Contract Accounts?

Smart contract accounts are fundamentally smart contracts; they are upgradeable, extensible, and also inheritable. Depending on the SCA implementation it can either allow or disallow adding plugins/modules. There are two different concepts of modular AA this article will explore are: ERC-6900 and SAFE Modules.

1. ERC-6900: Modular Smart Contract Accounts and Plugins

The objective of ERC-6900 is to define a set of interfaces between a standard Account and Module implementation. The proposal hopes to improve the developer experience, Module interoperability, and data portability when switching between account implementations.

The standard is inspired by ERC-2535, however, it does not require developers to follow the Diamond pattern.

What are ERC-6900 Plugins for Modular Smart Contract Accounts?

What types of plugins does ERC-6900 define?

According to the standard, plugins can be of three types:

1. Validation Schemes - Define the circumstances under which the modular smart contract account (MSCA) will approve the transactions on its behalf‍

2. Execution Logic - Any arbitrary logic to be performed during the execution

3. Hooks - Hooks can trigger any logic to be executed, pre- and post-execution of the user operation

The standard also defines:

1. How to implement Validation, Execution, and Hook plugins for a MSCA.

2. How compliant account implementations should add, remove, update, and inspect plugins.

3. Helper types like FunctionReference.

What types of interfaces does ERC-6900 define?

The ERC-6900 specification defines three main interfaces: IPluginUpdate, IPluginLoupe and IStandardExecutor.

1. IPluginUpdate

The IPluginUpdate interface defines:

• Plugin actions ADD, REMOVE, and REPLACE

• Validator types and Hook types

• User defined structs to update various plugins types

• A standardized updatePlugins function to be called when updating plugins and the ExecutionPluginUpdate event to be emitted post update

2. IPluginLoupe

The IPluginLoupe is inspired by ERC-2535, and ERC-6900 defines how a dapp or other contracts can read the supported plugins by the MSCA.

3. IStandardExecutor

The IStandardExecutor interface modular smart contract accounts should implement to allow for open-ended execution.

2. SAFE Modules

All SAFE-based accounts have support for SAFE Modules. To maintain high-security standards, the SAFE team followed the separation of concerns pattern and implemented different module types.

• Modules - Whitelisted addresses that can execute transactions in the name of the Safe Smart Account.

• Guard - A contract that can be set to perform additional checks on transactions to be executed.

• Fallback Handler - A contract that can be set to handle arbitrary incoming (read) calls.

More information can be found in Safe's modular SCA architecture article.

What are SAFE SCA Modules?

SAFE's Modules are individual smart contracts that have permission to execute transactions on the user's SAFE smart contract account. Modules can execute arbitrary transactions on the SAFE account via the execTransactionFromModule function. Since the SAFE team decides how the SAFE accounts are implemented, the plugin developers must comply with the rules and guidelines. SAFE modules are only compatible with SAFE accounts.

There are major trust assumptions between the module developer and the user, and as such, modules that are battle-tested are more likely to continue being adopted.

What are SAFE SCA Guards?

Guards are smart contracts that can be set for a SAFE account to perform additional security checks on incoming transactions. Before the execution of a transaction, a

Guard is called with all the transaction parameters, and if the Guard does not revert then the transaction proceeds to execution.

The Guard is called again after execution to perform state change checks or execute arbitrary logic.

Guards can also be thought of as hooks as they are appropriate for pre and post-transaction state checks.

What is the SAFE SCA Fallback Handler?

The Fallback Handler executes all calls made to the SAFE account which can be handled by it. This can be useful to comply with industry-wide standards like contract signatures (EIP-1271). According to SAFE, “plugins are completely independent of the core SAFE contracts and maintain their own storage”.

Conclusion

Modular Account Abstraction as described by ERC-6900 and designed by Safe Modules aims to extend the capabilities of Smart Contract Accounts through plugins, which can be built by developers, and safely installed by smart contract wallet users.

For more information, explore our ERC-4337 education center, or check out our plug-and-play Embedded Accounts to start building today.