ERC-7579 Explained: How Modular Smart Accounts Work

ERC-7579 is an Ethereum draft standard that defines the minimum interfaces a modular smart account and its modules must share, so a module can run on any account that follows the same rules. The EIP was created on 14 December 2023, and as of 8 November 2026 its page still shows Draft status. The standard defines four module types, the functions accounts must expose, and a set of security risks that the EIP itself marks as unfinished. Teams building on smart accounts should read the interface and the risk section together.

What ERC-7579 standardizes

A modular smart account moves optional features, such as signature schemes, spending rules or recovery logic, out of the account contract and into separate contracts called modules. Without a shared standard, each account vendor defines its own module interface, which fragments the ecosystem and ties users to one wallet implementation. ERC-7579 does not prescribe how an account works internally. It defines the shared surface: what accounts must implement and what modules must implement.

The EIP lists six authors: zeroknots, Konrad Kopp, Taek Lee, Fil Makarov, Elim Poon and Lyu Min. The official documentation at erc7579.com states that Rhinestone led development and built the reference implementation.

The four module types

The EIP assigns each module type a fixed identifier. A single module can implement more than one type.

Type ID	Module type	What it does
1	Validation	Decides whether a user operation or an ERC-1271 signature is valid
2	Execution	Executes transactions on behalf of the account through a callback
3	Fallback	Extends the account's fallback function with additional handlers
4	Hooks	Runs logic before and after execution (an optional extension)

Validators implement validateUserOp for ERC-4337 flows and isValidSignatureWithSender for ERC-1271 signatures. Hooks implement preCheck, which can return context data, and postCheck, which receives that data back. Every module implements a base interface with onInstall, onUninstall and isModuleType.

What accounts must implement

The EIP sets three groups of account functions:

Execution: execute(bytes32 mode, bytes executionCalldata) for calls authorized by the EntryPoint or the account itself, and executeFromExecutor for executor modules. An account must revert on any execution mode it does not support.
Configuration: accountId, supportsExecutionMode and supportsModule. The EIP recommends an identifier in the form vendorname.accountname.semver.
Module management: installModule, which passes initData to the module's onInstall; a removal function; isModuleInstalled; and the ModuleInstalled and ModuleUninstalled events.

The 32-byte execution mode encodes a call type (single, batch, delegatecall or staticcall), an execution type (revert on failure or handle the error) and 22 bytes of custom payload. The EIP notes that this payload can carry data such as a hook address.

How ERC-7579 relates to ERC-4337

ERC-7579 has a strict dependency on ERC-4337 for its validation flow. The EIP lists EIP-165, EIP-1271, EIP-2771 and EIP-4337 as requirements. Its authors justify this by stating that the modular accounts being built at the time used ERC-4337. The EIP also says that, if modular accounts are later built on other account-abstraction designs, the ERC-4337 dependency could move into a separate extension.

For developers, the two standards are layers rather than alternatives. ERC-4337 defines how user operations are submitted and validated. ERC-7579 defines how an account's functions are extended through modules.

Where the standard stops

The EIP is explicit about unfinished areas. Its security section says the topic needs more discussion. The points below come from that section and define the work that remains for any team.

Keep module types separate. If an account treats validators and executors as the same kind of module, a validator could execute arbitrary transactions for the account, according to the EIP.
Treat delegatecall as high risk. An account that supports delegatecall must make sure the target contract is safe.
Expect callback risk. onInstall and onUninstall can trigger unexpected callbacks, including reentrancy. A malicious module can also revert in onUninstall to block its own removal.
Compliance is not an audit. An interface-compliant module can still request broad permissions, and the standard does not define which permissions are safe.

SignorCrypto analysis: the practical risk of modular accounts lies in permission design rather than in function signatures. Before installing third-party modules, teams should define which module type may call which functions, who may install or remove modules, and how a removal can be guaranteed when a module misbehaves.

Deployed accounts and migration

The EIP's backwards-compatibility section says that proxy-based accounts can upgrade to a compliant implementation. Non-upgradeable accounts may become compliant through a compliant adapter installed as a fallback handler, if the account supports that pattern. The EIP presents this as a possibility, not as a general migration path.

Frequently asked questions

Is ERC-7579 a final standard?

No. The EIP page shows Draft status as of 8 November 2026. A reference implementation is maintained by the Rhinestone-led project linked from erc7579.com. Because the standard is still a draft, teams should pin versions and follow the EIP discussion before depending on a specific interface.

Can a module run on any smart account?

Only on accounts that implement the standard and support the module's type. Safe's documentation states that a module written for Safe can work with other compliant wallets, such as those from Biconomy and ZeroDev. That is the documentation's claim, not an independent interoperability test.

Who is the main audience for ERC-7579?

Safe's documentation describes module developers as the primary consumers of the standard. Account implementers adopt it so that module developers can support their accounts.

Sources

Next step

For teams designing a modular smart account, a module permission model or an ERC-4337 integration, a technical architecture review can turn these risks into concrete design decisions. You can start the conversation at SignorCrypto contact page.