ERC-7579: Reviewing the Modules Inside an Agent Smart Account

A team already has a smart account and wants to add a restricted agent session without rebuilding the wallet. Later it may need recovery or scheduled actions. Modular accounts make these capabilities separable, but each added module can also change who is allowed to act for the account.

ERC-7579 is relevant at that boundary: how account implementations and modules communicate, and what an integration must inspect beyond an advertised compatibility label.

Research boundary: official specification and maintainer documentation reviewed November 1, 2026. ERC-7579 remains Draft. No module was installed, audited or exercised for this article.

Review authority by module type

The draft specification defines account execution and configuration interfaces and several module roles. Validators check authorization; executors can initiate account execution through a designated path; fallback handlers extend callable behavior; hooks provide checks around execution. These roles are different access surfaces, not interchangeable names for a plugin.

Conceptual view of selected module roles, not a universal implementation trace. Fallback handlers and installation paths need their own review.

For an agent wallet, identify every route capable of spending funds. A policy attached to one validator is not automatically evidence that an executor or another enabled validator is equally constrained.

A module catalogue is a starting point

The maintainer module catalogue lists examples such as scheduled transfers, recovery, call policies and timelock hooks. These illustrate the kinds of functionality modular accounts can expose. They do not establish that every listed module works with every account version or that combining them preserves the intended policy.

The account catalogue also shows distinct implementations and adapters, including Kernel, Safe7579 and Nexus. That distinction matters in procurement: an adapter for a particular account is an implementation choice, while ERC-7579 is the interface standard. Record the actual combination rather than writing only “7579 wallet” in an integration ticket.

Trace the whole lifecycle of one agent session

The maintained Smart Sessions guide provides a concrete integration path for session-based operation. Use such a guide to locate configuration and lifecycle steps, then test the combination your product will run.

Our proposed review sequence is:

1. Before installation: identify the module’s privileges and the account authority needed to install it. Keep recovery authority separate from the agent session.
2. During use: try a permitted action and deliberate violations of each required constraint. Check all supported call paths, not only the SDK’s happy path.
3. At removal: confirm new submissions through that module are rejected, then inspect what other modules and credentials remain active.
4. After replacement: verify old configuration does not leave a forgotten route to execute.

These are proposed acceptance checks, not results from a module test suite. A functioning uninstall button is useful evidence about the interface; it is not proof that every related authority has ended.

Decide how failures should compose

Execution-mode choices deserve product attention. The standard describes both reverting and non-reverting behavior for supported modes. A batch of unrelated actions may tolerate one failure; a payment followed by a business-state update may need a different treatment.

For example, consider a hypothetical batch that pays a supplier and records an internal invoice reference. If the second action fails, should the first be preserved? There is no universally correct answer. The integration should choose an execution mode consistent with the business process, expose partial results where applicable and avoid reporting “all done” from the outer batch alone.

Similarly, a protective hook can become an availability dependency. During review, establish what happens when it rejects an action or cannot complete its check, and how an authorized owner can recover without handing that same bypass to the agent.

What to require before adoption

A useful module inventory includes the chain, deployed address, code version, initialization data, installation authority, supported execution modes and removal procedure. Associate security-review evidence with that exact version rather than with the module’s name.

Our view is that modularity pays off when these dependencies remain legible. If the team cannot explain which installed component permits an agent action, adding more modules is unlikely to simplify operations. Start with the ERC-7579 reference and compare its account-level role with ERC-7715’s permission interface.