ERC-6900 Modular Smart Accounts Explained

Updated on Sep 17, 2026

11 min read

ERC-6900 modular smart accounts give Ethereum wallet developers a common way to assemble account behavior from reusable modules. Instead of putting signatures, recovery, spending limits, session keys, and transaction controls into one fixed contract, an account can install standardized components with explicit permissions. This guide is for developers and technical product teams who understand the basics of account abstraction and want to see how a modular account is structured.

What is ERC-6900?

ERC-6900 is an Ethereum standard for modular smart contract accounts, also called modular smart contract accounts (MSCAs). It defines interfaces and expected call flows for an account that can use external modules for validation, execution, and hooks. The ERC-6900 specification is the normative reference for those interfaces, manifests, installation rules, and security requirements.

The distinction between a smart account and a modular smart account matters. A smart account can contain programmable authorization and execution logic, but that logic may still be a single, tightly coupled implementation. An MSCA keeps a core account and delegates selected responsibilities to modules. A wallet might combine a single-signer validator, a passkey validator, an allowlist hook, and a token-spending limit without rebuilding the entire account.

ERC-6900 is designed to work with ERC-4337. An account still implements the ERC-4337 account interface and can receive a UserOperation through an EntryPoint, while ERC-6900 defines how the account discovers, installs, and invokes modules. The standards address different layers: ERC-4337 defines a user-operation transaction flow, while ERC-6900 defines a portable module architecture inside the account.

This fits the broader direction described in Ethereum’s account abstraction roadmap. As wallets become programmable, interoperability is no longer only about sending transactions. It also means that modules can be developed once and integrated with multiple compatible accounts instead of being rewritten for every wallet-specific plugin system.

The Problem ERC-6900 Solves

Smart accounts solve problems that externally owned accounts handle poorly: seed-phrase recovery, delegated permissions, fee sponsorship, batched actions, and application-specific authorization. However, custom account logic can create a new form of fragmentation. Each wallet team may invent its own plugin interface, storage layout, validation callbacks, and module lifecycle.

That fragmentation affects both sides of the ecosystem:

Users can become tied to an account implementation because moving to another wallet means migrating assets and permissions.
Applications must learn different APIs for session keys, spending limits, and account capabilities.
Module developers must choose which account implementations to support, duplicating work or accepting platform lock-in.
Security reviewers must reason about undocumented extension behavior and inconsistent permission boundaries.

ERC-6900 addresses this by defining a shared contract between account developers and module developers. It separates the account’s core responsibilities from modular functions, describes what a module intends to install through a manifest, and establishes validation and execution flows that compatible accounts can implement consistently.

The standard does not make arbitrary modules safe. A compatible account still has to control who can install a module, verify the module’s manifest, isolate storage, prevent selector conflicts, and enforce the permissions implied by hooks and validation functions. Standardization improves interoperability; it does not replace audits or governance.

How ERC-6900 Works / Architecture

An ERC-6900 account has native functions in its core and modular functions supplied by installed modules. A module is a deployed smart contract that can provide one or more of three broad capabilities:

Validation functions decide whether an action is authorized on behalf of the account.
Execution functions add approved ways for the account to perform custom work.
Hooks run before or after validation or execution to enforce conditions or perform accounting.

The account can be called directly by an EOA or another contract, or indirectly through the ERC-4337 EntryPoint. In both cases, the account must resolve the requested function and apply the correct validation path before executing a target call.

A simplified flow looks like this:

UserOperation or direct account call
                 |
                 v
       Modular smart account
          /       |        \
   validation  execution   hooks
     module      module    pre/post checks
                 |
                 v
          target contract call

The account does not simply accept every function exposed by a module. During installation, the module supplies a manifest describing its execution functions, interface IDs, and hooks. The account validates that manifest and records the selector and validation relationships, giving reviewers and tooling an inspectable capability surface.

Design concern	Fixed smart account	ERC-6900 modular account	Why it matters
Authorization	Logic is embedded in the account	Validation functions can be supplied by modules	New signer and policy schemes can be added explicitly
Execution	Core exposes a fixed API	Execution functions can be installed from a manifest	Applications get a more consistent extension boundary
Transaction controls	Hard-coded guards or upgrades	Validation and execution hooks	Policies can run around selected actions
Feature portability	Usually wallet-specific	Modules target a shared standard	Less duplicated integration work
Capability discovery	Custom documentation or APIs	Interfaces, manifests, and account identification	Clients can inspect supported behavior
Upgrade risk	Changes often affect the whole account	Modules can be added or removed independently	Smaller units can be reviewed, but privilege paths multiply

The modular design is related to, but not identical to, ERC-7579 modular smart accounts. ERC-7579 emphasizes a minimal account and module interface, while ERC-6900 defines a broader module model with manifests, validation entities, and explicit validation and execution flows. They should be evaluated as different standards rather than assumed to be interchangeable.

Components / Key Concepts

Modular account

The account is the security boundary. It holds assets, implements the ERC-4337 account interface, exposes native functions, and manages module installation and removal. It must enforce that only authorized callers can change its module set and that installed modules cannot bypass the account’s execution rules.

Validation functions

A validation function determines whether a user operation, runtime call, or other action is authorized. A module can implement a single-signer check, multisignature approval, passkey verification, session-key policy, or another authorization method. ERC-6900 represents a validation function as a module and entity combination, allowing one module to expose multiple independently configured validation functions.

Validation is not only a signature check. It may inspect the target, selector, value, nonce, time window, or policy data. The account must bind the chosen validator to the action being authorized so a permissive validator cannot approve unrelated calls.

Execution functions

An execution function adds custom logic that the account is allowed to invoke. Examples include a token receiver, a constrained automation routine, or a function that interacts with an application-specific protocol. The account should expose only the selectors described by the installed module’s manifest and reject collisions with protected native functions.

Execution modules can be powerful even when they do not validate signatures themselves. If an executor can initiate arbitrary calls, it may move assets or change account configuration. Production accounts should constrain executor targets, selectors, values, frequency, or installation authority where the use case requires it.

Validation hooks

A validation hook runs around a validation function. It can impose additional permission checks, reject a call outside a policy, or add context that the validator must respect. This lets a wallet combine a general signature method with a narrower policy such as an allowlist or a session expiration.

Execution hooks

Execution hooks run before and/or after an execution function. A pre-execution hook can check balances, targets, or limits. A post-execution hook can record state, settle a quota, or verify that an expected condition held. Hooks need careful failure handling because a post-hook that reverts can revert the entire user action and a pre-hook can become an unexpected dependency for every call it guards.

Module manifests and entities

A module manifest declares the functions and hooks that should be installed on the account. This is more precise than asking an account to trust an opaque plugin with an unknown set of selectors. Validation and execution functions are tracked with module-specific identifiers, so an account can distinguish multiple behaviors supplied by the same module contract.

The manifest is not a security certificate. The account must still verify claimed interfaces, safe initialization, and storage isolation between modules.

Module lifecycle

Installing a module can require initialization data such as an owner, public key, target allowlist, or spending limit. Uninstalling may require de-initialization data to clean up module state. A robust implementation prevents replayed initialization, emits installation and removal events, rejects unsupported module types, and handles failed cleanup explicitly.

Real-World Use Cases

Wallet feature composition

A wallet can use a small account core and add a passkey validator, social recovery policy, and transaction allowlist as separately reviewed modules. Users can change a supported policy without migrating to a new account address, as long as the account’s management rules permit the change.

Session keys and games

A game can issue a session key that is valid for a short time and can call only the game’s contracts. A validation module checks the session restrictions, while an execution hook can enforce a value limit. The primary wallet key does not need to sign every low-risk action.

Treasury controls

A treasury can combine a multisignature validator with an execution hook that caps transfers or blocks unapproved destinations. The policy is visible as an installed configuration rather than hidden in an application server that submits transactions on the treasury’s behalf.

Automated DeFi operations

An account can authorize a constrained automation module to rebalance a position or execute a recurring strategy. The safety question is the boundary: which contracts, assets, functions, time windows, and maximum values can the module use? ERC-6900 provides the extension model, but the account owner and module must define those limits.

Interoperable wallet tooling

Wallet infrastructure can build inspection, simulation, and module-management tools against standard interfaces instead of depending entirely on a vendor’s private SDK.

Getting Started / Practical Guide

Start by separating the account’s invariant security rules from optional features. Owner or guardian management, module installation authority, and asset custody protections usually belong in the core or in a tightly controlled management path. Features such as session keys, allowlists, and token receivers are candidates for modules when their permissions can be bounded.

The ERC-6900 reference implementation is useful for studying the interfaces, sample account implementations, module contracts, and tests. Its README explicitly warns that the contracts are not audited and should not be used in production without independent review.

To inspect the reference implementation locally:

git clone --branch develop https://github.com/erc6900/reference-implementation.git
cd reference-implementation
forge build
forge test -vvv

For a project integrating an existing account, the practical sequence is:

Identify the account implementation and its ERC-6900 support.
Read the module manifest before installing anything.
Confirm the account’s authorization path for installation and removal.
Simulate direct calls and ERC-4337 UserOperation calls.
Test module combinations, failure paths, and uninstall cleanup.

A review checklist can be kept alongside deployment configuration:

module_review:
  account:
    rejects_unsupported_manifest: true
    protects_native_selectors: true
    restricts_install_and_uninstall: true
  validation:
    binds_authorization_to_action: true
    prevents_replay: true
    handles_time_and_scope_limits: true
  execution:
    constrains_targets_and_values: true
    isolates_module_storage: true
  hooks:
    pre_and_post_failures_are_tested: true
    unexpected_reentrancy_is_reviewed: true
  lifecycle:
    initialization_cannot_be_replayed: true
    uninstall_cleans_module_state: true

Use a local node or testnet for verification, not a mainnet account containing funds. Test a valid call, an unauthorized caller, an unsupported selector, a malformed manifest, a repeated initialization, a replayed nonce, and a failing post-execution hook. Then inspect emitted installation and removal events so monitoring can detect unexpected changes to the account’s module set.

Common Misconceptions

“ERC-6900 is a wallet product.”

It is a standard for account and module behavior, not a single wallet implementation. Different accounts can use different storage, signer schemes, upgrade controls, and governance while implementing the same interfaces.

“Installing a standard module is automatically safe.”

No. Standard compliance does not prove that a module’s permissions are appropriate or that its implementation is free of bugs. The installed module set is part of the account’s security configuration and must be reviewed as a whole.

“ERC-6900 replaces ERC-4337.”

The standards solve different problems. ERC-4337 defines a user-operation flow using bundlers and an EntryPoint; ERC-6900 defines how a smart account composes and manages validation, execution, and hook modules. A modular account can use ERC-4337 without treating the standards as substitutes.

“More modules always mean better flexibility.”

Modules add choice, but they also add privilege boundaries, storage interactions, selector routing, and failure modes. A small, understandable module set is often safer than installing every available extension.

ERC-6900 makes modularity an explicit account boundary rather than an undocumented wallet feature. Its value is greatest when the account exposes a small, inspectable core and modules have narrowly defined permissions, lifecycle behavior, and failure handling.

Changelog

2026-09-17: Published the initial explanation of ERC-6900 modular smart accounts.