0%
Overview page background
HomeOverviewsAccount Abstraction
What is Modular Account Abstraction?

What is Modular Account Abstraction?

Logan Ross headshot

Written by Logan Ross

Brady Werkheiser headshot

Reviewed by Brady Werkheiser

Published on 2023-07-193 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 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

ERC-6900 Module Diagram
ERC-6900 Module Diagram

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.

Diagram of how a transaction flows through the entry point to an ERC-6900 SCA
Diagram of how a transaction flows through the entry point to an ERC-6900 SCA

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.

Diagram of SAFE Account Module
Diagram of SAFE Account Module

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.

How SAFE SCA Guards Can Protect Accounts
How SAFE SCA Guards Can Protect Accounts

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”.

Diagram of how the SAFE SCA Fallback Handler works
Diagram of how the SAFE SCA Fallback Handler works

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 Account Kit Product to start building today.

Overview cards background graphic
Section background image

Build blockchain magic with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.