ERC-7579 Smart Accounts and Modular Wallets

Updated on Sep 16, 2026

11 min read

ERC-7579 smart accounts give wallet developers a common way to assemble account behavior from replaceable modules. Instead of implementing signature checks, recovery, spending limits, session keys, and transaction guards in one large contract, a wallet can expose a standard account interface and install modules for those jobs. This explainer is for Ethereum developers and technical product teams who already understand the basics of account abstraction and want to see how modularity fits into a smart-account architecture.

What is ERC-7579?

ERC-7579 is an Ethereum standard for minimal modular smart accounts. It defines interfaces and conventions that let an account support modules without prescribing one wallet implementation, signature scheme, or governance model. The ERC-7579 specification describes the required account and module behavior, including how an account advertises supported module types, installs and removes modules, and executes calls.

The distinction between a smart account and a modular smart account is important. A conventional smart account may contain one fixed validation and execution policy. An ERC-7579 account keeps a small core and delegates selected responsibilities to modules. A user might install a passkey validator, a spending-limit hook, and a session-key executor while keeping the same account address and core execution rules.

ERC-7579 is not a replacement for ERC-4337. ERC-4337 standardizes a transaction flow around UserOperation, bundlers, and an EntryPoint. ERC-7579 standardizes the internal account and module boundary that can be used inside that flow. The standards solve different layers of the wallet problem and can be used together.

The ERC-7579 project site provides the ecosystem context and implementation resources around this modular-account model. It is best treated as a coordination and discovery point; the EIP remains the normative reference for interface behavior.

The Problem ERC-7579 Solves

Smart accounts are more flexible than externally owned accounts, but flexibility can create fragmentation. Before a common modular interface, wallet teams often implemented similar features in incompatible ways:

one wallet embedded multisig and recovery logic directly in its account contract;
another used a custom plugin interface for session keys;
a third exposed a different execution API for automation;
applications had to integrate each wallet’s module system separately.

This creates two kinds of lock-in. Users become dependent on the account implementation chosen at deployment, while developers become dependent on a wallet-specific SDK and permission model. Adding a new security feature can require migrating funds to a new account or trusting a bespoke extension mechanism.

ERC-7579 addresses this by making the extension boundary explicit. The account remains responsible for core authorization and execution, while modules implement specialized behavior through recognizable interfaces. A module can be selected, inspected, initialized, and removed through standard operations rather than undocumented contract-specific calls.

The standard does not make every module safe. It makes the relationship between an account and its modules easier to inspect and integrate. Security still depends on who can install a module, what permissions it receives, whether it can be removed, and how its code is audited.

How ERC-7579 Works / Architecture

An ERC-7579 account has a core contract and a registry-like view of installed modules. A user or authorized management process installs a module by specifying its type, address, and initialization data. The account calls the module’s installation hook, then records enough information to answer whether that module is installed.

When an action arrives through an ERC-4337 UserOperation, the account’s validation path can delegate signature or policy checks to a validator module. If the operation passes, the account executes one or more calls using an encoded execution mode. Modules can also participate in execution directly, depending on their type and the account’s policy.

The architecture can be summarized as:

UserOperation or direct call
              |
              v
        ERC-7579 account
        /       |        \
 validator   execution   hooks/fallback
 module      core        modules
              |
              v
       target contract calls

The account interface separates three questions that are frequently mixed together:

Can this account support a module type? The account reports supported type IDs.
Is this particular module installed? The account exposes an installation check.
Can this execution mode be handled? The account reports whether it understands the encoded call format.

Execution modes are a compact way to describe how calls should be performed. They can distinguish a single call from a batch and can reserve space for more specialized execution behavior. This gives account implementations a common way to reject unsupported modes instead of silently interpreting calldata incorrectly.

Design concern	Fixed smart account	ERC-7579 modular account	Why it matters
Validation	Hard-coded in the account	Validator modules can provide policy	New authorization schemes do not require a new core
Recovery	Built into one implementation	Can be represented by a validator or management module	Recovery can evolve with explicit permissions
Execution	One account-specific call format	Standard execution modes and account interface	Wallet tooling has a predictable integration surface
Extensions	Custom plugins or upgrades	Typed modules with install and uninstall hooks	Capabilities are easier to inspect
Application integration	Wallet-specific adapters	Common module and account checks	Less bespoke integration work
Risk	Concentrated in core logic	Distributed across core and installed modules	Modularity improves reuse but expands review scope

The account is still the security boundary. A module does not become trustworthy merely because it implements the standard. The account must enforce module-type checks, initialization rules, authorization, and safe uninstall behavior.

Components / Key Concepts

Validator modules

A validator module decides whether an operation or signature is authorized. One validator might verify an ECDSA owner signature; another might verify a passkey, a multisignature, a session key, or a policy-specific proof. A modular account can support more than one validator strategy, but it must define how those validators are selected and whether multiple validators can be active at the same time.

Validation is particularly important in an ERC-4337 flow because the account is called during UserOperation validation. A malicious or poorly isolated validator can approve actions the owner did not intend. The account therefore needs clear rules for validator identity, nonce handling, and validation context.

Executor modules

An executor module can initiate execution through an account when the account authorizes that module type. This is useful for recurring tasks, automation, subscriptions, and session-based applications. Executor permissions are powerful: depending on the account implementation, an executor may be able to trigger arbitrary calls or only a constrained set of targets and functions.

Good designs narrow executor authority with allowlists, spending limits, time windows, or per-module policies. Removing an executor should also be an explicit and testable operation.

Fallback handlers

A fallback module handles function selectors or call patterns that the core account does not implement directly. This can make an account compatible with additional interfaces without putting every selector in the core contract. Fallback routing needs careful collision and authorization rules because a selector can expose a new external behavior.

Hook modules

Hooks run before or after selected execution paths. A hook can enforce a transfer policy, reject calls to a prohibited target, record activity, or apply a spending limit. Hooks are useful guardrails, but they also create hidden coupling: a hook that changes execution semantics can break applications that assume a call will always succeed in the same way.

Module lifecycle

Modules usually have installation and uninstallation callbacks. Initialization data may configure an owner, a public key, a target allowlist, or a policy threshold. Uninstallation data can be required to clean up module-specific state. A production account should ensure that initialization cannot be replayed, that only authorized callers can change modules, and that removing a module does not leave an unsafe partial state.

Execution modes

The execution mode describes how the account interprets execution calldata. A single-call mode might contain one target, value, and calldata tuple. A batch mode can contain several calls. The exact encoding is defined by the account implementation and the ERC-7579 mode conventions, so clients should query support rather than assume every account accepts every mode.

Real-World Use Cases

Wallet feature upgrades

A wallet can ship a small account core and add passkeys, social recovery, or multisignature support as separately reviewed modules. Users can adopt a new feature without migrating the account address, provided the account’s permission model allows the change.

Session keys and gaming

A game can issue a session key that may call only the game’s contracts, spend below a limit, and expire after a short period. The game does not need the user’s primary signing key for every action, and the account can remove the session module when the session ends.

Treasury controls

Organizations can combine a validator for multiple approvals with hooks for transfer limits and an executor for approved operational routines. The modules make the policy components visible, while the account remains the common execution surface.

Automated DeFi operations

An account can authorize a constrained executor to rebalance positions or perform scheduled actions. The important design question is not whether automation is possible, but whether its target contracts, assets, frequency, and maximum value are bounded.

Interoperable wallet tooling

Infrastructure providers can build module discovery, simulation, and policy tooling around common interfaces. This does not eliminate implementation differences, but it reduces the need to understand every wallet’s private extension API.

Getting Started / Practical Guide

Start by deciding which behavior belongs in the account core and which behavior can be a module. Authorization to install or remove modules should remain in a strongly protected management path. Then choose an implementation that supports the module types and execution modes your application needs.

A simplified view of the account interface looks like this:

interface IERC7579Account {
    function accountId() external view returns (string memory);

    function execute(
        bytes32 mode,
        bytes calldata executionCalldata
    ) external payable;

    function executeFromExecutor(
        bytes32 mode,
        bytes calldata executionCalldata
    ) external payable returns (bytes[] memory returnData);

    function supportsExecutionMode(bytes32 mode)
        external
        view
        returns (bool);

    function installModule(
        uint256 moduleTypeId,
        address module,
        bytes calldata initData
    ) external;

    function uninstallModule(
        uint256 moduleTypeId,
        address module,
        bytes calldata deInitData
    ) external;

    function supportsModule(uint256 moduleTypeId)
        external
        view
        returns (bool);
}

This is an interface sketch for explaining the boundary, not a complete account implementation. The canonical ERC-7579 EIP should be used when generating bindings and checking the current normative signatures.

For a deployed account, basic discovery can be performed with Foundry’s cast. Set the RPC endpoint and account address first:

export RPC_URL="https://your-rpc.example"
export ACCOUNT="0x0000000000000000000000000000000000000000"

cast call "$ACCOUNT" "accountId()(string)" --rpc-url "$RPC_URL"
cast call "$ACCOUNT" "supportsModule(uint256)(bool)" 1 --rpc-url "$RPC_URL"
cast call "$ACCOUNT" "supportsModule(uint256)(bool)" 2 --rpc-url "$RPC_URL"

The type IDs commonly map to validators and executors first, with fallback and hook modules represented by additional IDs in the standard. Always confirm the mapping against the specification and the implementation you are integrating.

Before installing a module, test at least these cases:

module_review:
  - account_rejects_unsupported_module_type
  - unauthorized_caller_cannot_install_or_remove
  - initialization_cannot_be_replayed
  - executor_cannot_escape_target_or_value_limits
  - hook_failure_reverts_the_intended_execution
  - uninstall_clears_module_specific_state
  - unsupported_execution_mode_is_rejected

Simulation matters because a module can be valid in isolation but unsafe in combination with another module. Test direct calls and ERC-4337 UserOperation execution, including failed validation, replayed nonces, malformed mode bytes, and removal of a module while an operation is pending.

Common Misconceptions

“ERC-7579 is a wallet implementation.”

It is an interface and behavior standard, not a single wallet product. Two accounts can both implement ERC-7579 while using different validators, storage layouts, upgrade controls, and governance.

“Every module can be installed by every account.”

No. The account decides which module types and addresses it supports, and its authorization policy decides who can install them. A client should query support and inspect the account’s management rules before attempting installation.

“Modularity automatically improves security.”

Modularity can make code easier to replace and review, but it also adds privilege boundaries and integration paths. A validator, executor, fallback, or hook may have significant authority. The complete installed module set is part of the account’s security configuration.

“ERC-7579 replaces ERC-4337.”

The standards are complementary. ERC-4337 describes how user operations reach an account through bundlers and an EntryPoint; ERC-7579 describes how a modular account exposes execution and extension behavior. A modular account can also support other transaction paths.

ERC-7579 makes modularity a discoverable contract boundary rather than a collection of wallet-specific conventions. Its value is greatest when the account core stays small, module permissions are explicit, and clients verify capabilities before relying on them. The standard improves interoperability, but safe smart accounts still depend on careful authorization, simulation, upgrade, and recovery design.

Changelog

Published as a canonical explainer on 2026-09-16.