ERC-7579 primary sources — 2026-05-07

Project status in this pass

• No standalone ERC-7579 whitepaper or litepaper surfaced.
• The clearest current source of truth was the draft ERC itself, supplemented by the project documentation site, Safe’s overview, and the reference implementation README.
• The sources consistently frame ERC-7579 as a portability and interoperability standard for modular smart accounts, not as a single wallet architecture.

Primary-source snapshots

1) Canonical ERC page

• URL: https://eips.ethereum.org/EIPS/eip-7579
• Key excerpt/signals:
  • The abstract says the proposal outlines the minimally required interfaces and behavior for modular smart accounts and modules to ensure interoperability across implementations.
  • The motivation says modular smart accounts are currently built in vastly different ways, creating module fragmentation and vendor lock-in.
  • The ERC explicitly says standardization should have minimal impact on implementation logic so vendors can keep innovating.
• Why it mattered:
  • This is the clearest evidence that ERC-7579 belongs in the corpus as shared interface infrastructure rather than as a product entry.

2) Account and execution surfaces in the ERC text

• URL: https://eips.ethereum.org/EIPS/eip-7579
• Key excerpt/signals:
  • The execution interface requires execute(bytes32 mode, bytes executionCalldata) and executeFromExecutor(bytes32 mode, bytes executionCalldata).
  • The ERC describes a structured bytes32 execution mode split into call type, execution type, reserved bytes, mode selector, and payload.
  • Accounts must expose accountId, supportsExecutionMode, and supportsModule.
• Why it mattered:
  • These details show ERC-7579 is standardizing the portable execution envelope and capability boundary, not merely naming a module concept.

3) Module taxonomy in the ERC text

• URL: https://eips.ethereum.org/EIPS/eip-7579
• Key excerpt/signals:
  • The spec fixes four module types with explicit IDs: validation (1), execution (2), fallback (3), and hooks (4).
  • It requires lifecycle hooks like onInstall and onUninstall, plus module-type introspection.
  • It also requires ERC-1271 support and describes forwarding signature checks to validators.
• Why it mattered:
  • This is the strongest signal that ERC-7579 is defining a shared module ABI and authority model across account implementations.

4) ERC-7579 documentation site

• URL: https://erc7579.com/
• Key excerpt/signals:
  • The docs say ERC-7579 outlines the minimally required interfaces and behavior for modular smart accounts and modules.
  • They say the goal is to be as minimal as possible to achieve interoperability while still allowing builders to innovate.
  • They point to a reference implementation and explicitly encourage extension ERCs for more specialized standardization.
• Why it mattered:
  • The docs reinforce the “minimal common boundary” framing and show the project sees itself as a base layer for further standardization, not the final word on smart-account design.

5) Safe overview and reference implementation README

• URLs:
  • https://docs.safe.global/advanced/erc-7579/overview
  • https://raw.githubusercontent.com/erc7579/erc7579-implementation/master/README.md
• Key excerpt/signals:
  • Safe says the primary consumers are module developers and gives the example that a module for Safe can work with Biconomy and ZeroDev wallets if they implement ERC-7579.
  • The reference implementation README says it includes one account flavor demonstrating the mandatory ERC-7579 features plus optional hook support.
  • The README also says the implementation must choose details the standard leaves open, such as validator encoding, and warns the contracts are not audited.
• Why it mattered:
  • Safe provides the practical interoperability claim; the reference implementation shows where the standard stops and implementation discretion begins.

Working conclusion

ERC-7579 is best cataloged as modular smart-account interoperability infrastructure. The decisive evidence in this pass was the draft ERC’s anti-fragmentation motivation, its standardized execution and module-management interfaces, its fixed module taxonomy, Safe’s explicit cross-wallet module-compatibility framing, and the reference implementation’s acknowledgment that many architectural choices remain intentionally out of scope.