Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
SEPOLIA FAUCET
Get free Sepolia ETH.
Start Building Today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Build with Alchemy's
Gas Manager & Bundler APIs
Learn
Solidity at
Alchemy
University
Get started today
Build with Alchemy's
Gas Manager & Bundler APIs
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Account Abstraction
MODULAR AA OVERVIEW

What is Modular Account Abstraction?

Learn How Different Smart Contract Account Concepts Use Modules and Plugins to Create New Extensions for Accounts
Last Updated:
July 19, 2023
Table of Contents
Table of Contents
Table of Contents

{{aa-cta}}

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
this is a diagram that shows how erc-6900 MCSAs communicate with plugins
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 explaining how smart contract accounts work according to the ERC-6900 specification.
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 how SAFE Module and Singleton State interact with the SAFE Accounta
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.

this diagram shows how SAFE smart contract accounts can leverage Guard plugin-types that help protect the account from authorizing dangerous transactions
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‚ÄĚ.

this diagram show how all calls made to the SAFE account which can be handled by it are forwarded to the Fallback Handler.
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, and check out our Account Abstraction developer tools including our Bundler and Gas Manager API (paymaster).

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Account Abstraction
MODULAR AA OVERVIEW

What is Modular Account Abstraction?

Learn How Different Smart Contract Account Concepts Use Modules and Plugins to Create New Extensions for Accounts
Last Updated:
July 19, 2023
Last Updated:
June 1, 2023
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Table of Contents

Talk to an Expert

Learn how Alchemy's blockchain developer tools can help your business succeed in web3!
Valid number
Thank you! An Alchemy expert will be in touch with you shortly!
Oops! Something went wrong while submitting the form.

{{aa-cta}}

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
this is a diagram that shows how erc-6900 MCSAs communicate with plugins
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 explaining how smart contract accounts work according to the ERC-6900 specification.
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 how SAFE Module and Singleton State interact with the SAFE Accounta
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.

this diagram shows how SAFE smart contract accounts can leverage Guard plugin-types that help protect the account from authorizing dangerous transactions
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‚ÄĚ.

this diagram show how all calls made to the SAFE account which can be handled by it are forwarded to the Fallback Handler.
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, and check out our Account Abstraction developer tools including our Bundler and Gas Manager API (paymaster).

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
this is a diagram that shows how erc-6900 MCSAs communicate with plugins
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 explaining how smart contract accounts work according to the ERC-6900 specification.
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 how SAFE Module and Singleton State interact with the SAFE Accounta
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.

this diagram shows how SAFE smart contract accounts can leverage Guard plugin-types that help protect the account from authorizing dangerous transactions
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‚ÄĚ.

this diagram show how all calls made to the SAFE account which can be handled by it are forwarded to the Fallback Handler.
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, and check out our Account Abstraction developer tools including our Bundler and Gas Manager API (paymaster).

{{aa-cta}}

Contact Us

Talk to an expert at Alchemy to answer all of your product questions.
Valid number
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Build blockchain magic with Alchemy

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

Get started for free