Cowrie Research

erc-7579

3 min read

ERC-7579

  • Name: ERC-7579
  • URL: https://eips.ethereum.org/EIPS/eip-7579
  • Category: Ethereum smart-account interface standard / modular account interoperability specification / wallet authority infrastructure
  • Summary: ERC-7579 is best understood as interoperability infrastructure for modular smart accounts rather than as a wallet product, SDK, or one-vendor account design. Its core move is to standardize the minimum account and module interfaces needed for different smart-account implementations to share validators, executors, fallback handlers, and hooks without forcing every account to converge on the same internal architecture. The important categorization clue is that ERC-7579 is trying to make the module boundary portable across account vendors: it defines the attachment points and behavior contracts, not a single canonical smart-account implementation.
  • What it does:
    • Defines minimal execution interfaces for modular smart accounts, including execute and executeFromExecutor, plus optional ERC-4337 executeUserOp handling
    • Standardizes account configuration surfaces such as accountId, supportsExecutionMode, and supportsModule
    • Standardizes module installation and uninstallation flows, lifecycle hooks, and installed-module checks
    • Separates module roles into validator, executor, fallback handler, and hook types, with explicit type identifiers
    • Requires ERC-1271 support and allows signature-validation forwarding to validators under standardized constraints
    • Leaves internal implementation details intentionally open so account vendors can keep different internal architectures while still supporting shared module ecosystems
  • Key claims:
    • The draft ERC says it outlines the minimally required interfaces and behavior for modular smart accounts and modules so they can interoperate across implementations
    • The motivation section says the current modular smart-account landscape suffers from module fragmentation and vendor lock-in, which is the clearest signal that the standard should be treated as shared interoperability infrastructure rather than a product feature
    • The specification requires accounts to expose standardized execution, account-config, and module-config interfaces, but explicitly says the standard does not dictate how validator selection is implemented internally
    • The execution section defines a structured bytes32 execution mode with call type, execution type, mode selector, and payload fields, which shows ERC-7579 is standardizing a portable execution envelope rather than only naming interfaces
    • The module taxonomy fixes four module-type identifiers — validation, execution, fallback, and hooks — which creates a shared vocabulary for portable account extensions
    • The ERC-1271 forwarding section says a smart account MUST implement ERC-1271 and MAY forward signature checks to a validator, which is a strong clue that authority can be modularized without abandoning wallet-signature compatibility
    • The ERC-7579 documentation site says the goal is to be as minimal as possible while achieving interoperability, and points to a reference implementation plus an extension path for future ERCs rather than claiming this standard fully specifies smart-account behavior
    • Safe’s ERC-7579 overview says the primary consumers are module developers and gives the concrete example that a module for Safe can work with Biconomy or ZeroDev wallets when they implement the standard, which is the best short statement of why this belongs in the corpus
    • The reference implementation README says the implementation has to make choices the standard intentionally leaves open, such as validator encoding, reinforcing that ERC-7579 is a boundary/interface standard rather than a full wallet blueprint
  • Whitepaper: No standalone ERC-7579 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft ERC itself, the project documentation site, implementation notes from Safe, and the reference implementation README; see ../../whitepapers/erc-7579-primary-sources-2026-05-07.md.
  • Sources:

Internal linkages

  • Keep this on the sharpest portability cut: erc-6900, erc-4337, and safe.

  • Reusable lens: when a team claims modular account interoperability, ask whether modules really port or whether wallet vendors still own the meaningful defaults, validator encoding, and execution modes.

  • Last reviewed: 2026-06-05 UTC

Graph View

Backlinks